On Thu, Oct 22, 2009 at 1:29 PM, jlist9 <jli...@gmail.com> wrote:
>
> Hi David,
>
> Appreciate your reply. It's definitely helpful in clearing some of my
> thoughts,
> as well as in my process of learning Scala down the road. I also think your
> book is very well paced and organization of the content is well thought
> out.
> Great job!
>
> I'd like to explain a little bit where my frustration is coming from
> (and I don't
> want to waste people's time reading further for those who aren't
> interested.)
>
> I come from Java and Python background. When learning these two languages
> I didn't have a problem with the syntax. I think Java's syntax is well
> defined
> although verbose, and Python's is clear and concise. There is a small
> number
> of operators and data types and it's pretty clear which is for what
> purpose.
> "Zen of Python" says it well:
>
> "There should be one-- and preferably only one --obvious way to do it."
>
Except that sometimes, there isn't. In fact for any non-trivial case, there
can be multiple ways to do anything.
Sorting is an excellent example. There isn't just one way to sort. Which
way you do it depends on the data, and your
expectations.
> and I think this reflects well in the language design of Python.
>
> It's also generally discouraged to use too much "black magic" when coding
> in Python so that the code is easier to understand and maintain, although
> Python, being a powerful dynamic language, is very capable of black magics.
>
> These two things helped a lot in my learning of Python. It's a much smaller
> set of syntax to learn and it can be learned in a very short time, maybe
> through
> one or two online tutorials. The rest of it is just libraries, which
> are very rich
> in functionality, but the source code is easy to understand, because of the
> small set of clearly defined elements in the language - syntax and
> data types, etc..
>
> However, I don't feel the same about Scala. In Scala, I often see multiple
> ways
> of doing the same thing, or very similar things, and this is confusing.
>
Tell me about it.... If you find Scala confusing, never go look at Perl or
Lisp....
Perl's motto is "There is more then one way to do it."
>
> For example, there are multiple ways of running a program. You can have a
> script, or an application. To run an application, you can write an "object"
> and
> implement the main method, or you can extend Application class and write
> the code right in the body of the class. It took me a while to figure out
> how
> it works. What's wrong with having only one of them? Python only start as a
> script and Java only need a main method but either way works.
>
Each brings it's own strengths and weaknesses to the table.
And Java only needs a main isn't true.... in web development there is no
main. There is no main if you write an eclipse plugin, and there is no main
if you use a Swing based framework. (note if it's just swing, you do.)
>
> Another example is that in some scenarios ( ) and { } are
> interchangable in Scala
> code, although I haven't figured out in what occasions they are, and
> in what occasions
>
they are not. This puzzles me more because ( ) and { } are the basic
> elements
> in a language and the language allows such flexible usage of them. Although
> I
> think there should be a good reason for this but it still struck me as odd.
>
Wish I could articulate this better. Using the for comprehension as an
example... it's the way it gets compiled into code. There is no for loop in
Scala. A for comprehension gets boiled down to method calls. The curly
braces get converted into an anonymous function.
See
http://creativekarma.com/ee.php/weblog/comments/the_scala_for_comprehension_from_a_java_perspective/
>
> In contrast to Python's short list of operators, because operators are
> actually functions
> in Scala, it's easy for Scala to have a new operator, or have
> functions that works
> like operators. This is a powerful feature and it is good news for
> people who want to
> create DSLs. However I think a plethora of operators make code much harder
> to
> read before people can make it a habit to convert operators as
> functions in their mind.
>
And too few operators leads to a whole lot of words, which leads to a whole
lot of typing, or a whole lot of ctrl-space completions. It's a toss up.
The wordy way is definitely noob friendly, while the operator way is more
expert friendly.
Which do you design a language for? Let me know when that particular
religious war dies down please.
As someone who slings code for a living.... the less I type the happier I
am..... YMMV
>
> To summarize, the more I learn Scala the more I realize how powerful
> it is. Meanwhile,
> I think Scala imposes this mind tweaking that people have to go
> through in learning
> this language, the difficulty that I didn't feel when I learned
> Python, or Java, C or C++.
> I like many of the features provided by Scala but I hope some of the
> things can be
> simplified/demystified to make it easier to pick up and use.
>
Interestingly, I heard a lot of the exact same type of comments when people
went from learning the DOS command line to the Unix command line. I suppose
that the snarky answer there is similar to the one here: Unix is user
friendly, it's just picky about who it's friends are. Scala is also user
friendly.. :)
Which has always meant to me, that the only people who bother to use
something as complex and powerful as Scala, are the good ones. It is, like
the Unix command line, self selecting for quality. I've always given more
credence to a Unix Sys Admin then Windows Sys Admin. I'll always give more
credence to a Scala/Lisp/Clojure/Perl coder then I will anyone from other
languages.
Or, if I may wax metaphorical (and deep into my own opinion)once more... who
do you think is the better driver, a NASCAR driver or a Prius driver? Which
is more expensive to learn to do? Which is more fun? :)
>
> jlist9
>
> On Thu, Oct 22, 2009 at 9:04 AM, David Pollak
> <feeder.of.the.be...@gmail.com> wrote:
> > I've drafted a couple of different versions of a response to this message
> > and they all seem somewhat mean and/or condescending... that is not at
> all
> > my intent... here's another draft and please read it as acknowledging the
> > challenges you are articulating, but suggesting a different perspective
> on
> > the issue.
> > Lisp/Scheme/Clojure is syntactically the simplest language around. Yet,
> > when I look at Clojure code, it to a great degree seems complex to me,
> even
> > though I know it's not. I believe this is because the patterns are
> > different than those I've rehearsed through my journey of asm, Basic, C,
> > ObjC, C++, Java, Ruby, and Scala. Rehearsing a different paradigm is
> part
> > of making that paradigm part of you.
> > When I studied French in grade school and high school, I
> was flummoxed and
> > quite angered by gendered nouns. As a native English speaker, a table is
> an
> > it, not a she (or he.) But fluent French speakers make gendered nouns a
> > normal part of the language, and once skilled can use these subtleties
> with
> > great skill.
> > My 2 year learning curve for Scala can be summed up in the first 4 (or
> maybe
> > 5) chapters of Beginning Scala. I sought to present my painful learning
> > curve in < 150 pages that could be reasonably consumed by a Java or Ruby
> or
> > Python coder in a week or two. Yeah, it still takes a fair amount of
> > practice, rehearsal, to be proficient, but if someone had led me down the
> > path that I led my readers down, I think my pain-curve would have been
> 3-4
> > months, not two years.
> > Put a different way, the Programming in Scala folks passed a couple of
> > drafts of the first chapters of their book by me early on. I think PinS
> is
> > a tredmendously awesome work, but I objected strongly to the "show
> > imperative first and gently migrate to functional" approach they took. I
> > thought it did a significant disservice to their readers. I took the
> > opposite approach in BegSca... the second substantive example covers a
> broad
> > spectrum of functional programming.
> > So, getting to some of the substance of your post, as Tim pointed out,
> the
> > "_" is a running joke in Scala-land. Yep, it's way overloaded. Every
> time
> > (and this happened at both Scala Lift Offs) Martin tries to justify the
> > "_"'s use, people roll their eyes.
> > On the other hand, the example that you gave is one of my proudest
> moments
> > in Lift. Specifically, I think Mapper is a steaming pile of something.
> I
> > am really dissatisfied with it (although we followed the same paradigm
> with
> > Record and I'm unhappy with that as well... mostly from the mutability
> > standpoint). On the other hand, the graceful way that Mapper deals with
> > validators (they are functions and they are declared as a List that can
> be
> > dynamically generated) is something that I look at and remember it being
> the
> > first time I really felt like I "got" the power of Scala. When I
> developed
> > that paradigm, I genuinely felt like Lift was going to be something
> > different and better.
> > So, I am truly sorry that you and others are struggling with Scala (yeah,
> > everyone other than Martin and Adriaan and a few others struggle with
> > Scala's type system, but most people didn't get General Relativity early
> on
> > either) and I hope that we can present materials to you in a way that
> helps
> > minimize the struggle.
> > Thanks for sharing your thoughts and I hope this message has struck the
> tone
> > I intend it to.
> > David
> >
> > On Wed, Oct 21, 2009 at 10:13 PM, jlist9 <jli...@gmail.com> wrote:
> >>
> >> override def validations = validPriority _ :: super.validations
> >>
> >> This is a more of a comment about Scala than one about Lift - this does
> >> look cryptic to me. And this is just one of the simpler syntax that
> >> confuses
> >> people, who are new to the language. And I'm one of them.
> >
> > Interesting... this is one of the constructs in Lift that I find simple
> (and
> > almost always have found simple). It's adding a validator to a list of
> > validators. Having validators as functions was an early (while my mind
> was
> > still mostly Java/Ruby) construct that, when I look at it says, "this was
> > something that still works." Mapper's general use of mutability, on the
> > other hand, is something that very much does not work (although the
> > syntactic cost of doing something else is still too high.)
> >
> >>
> >> I understand that you don't have to learn all the tricks/syntax to start
> >> coding in Scala but you do have to understand it when you read
> >> source code of libraries written by someone with much more advanced
> >> language skills.
> >>
> >
> > In this particular case, building an immutable list of of a new element
> and
> > a prior element and the syntax for turning a method into a function are
> both
> > very core concepts in Scala (and pretty core in Ruby as well, although
> the
> > syntax is different). I do not view these as any more advanced than
> > overriding methods in Java.
> > The Scala skills needed to understand and consume most of Lift's APIs
> should
> > not be part of the advanced piece of Scala. The advanced piece of Scala
> has
> > to do with the type system and its interaction with OO. You can see the
> > challenges that these advanced pieces of Scala pose to folks in the way
> the
> > new collections are being re-written. This is the hard stuff in Scala.
> > Cons cells, immutable lists, and promoting methods to functions are not
> > tough concepts.
> >
> >>
> >> In David's book he says "After more than two years of coding Scala, ...
> >> My brain has finally stopped hurting." This sounds like a very high
> >> barrier to entry.
> >
> > Yeah... that was more of a statement about the change in thought
> processes.
> > I distilled most of the painful concepts into the first 4 chapters of
> the
> > book. It took a very, very long time to unlearn beans/getters/setter
> (this
> > was my default way of programming from age 12 to age 42). If the first 4
> > chapters of the book resonate with you, if you can practice them
> > comfortably, then you are over the part where my brain hurt a lot.
> > To be fair, my brain started hurting when I started coding in Ruby and I
> > discovered closures. Ruby's syntax for dealing with closures sucks (a
> max
> > of one per method call, it may or may not be a method parameter, etc.)
> But
> > it was a sea change in the way I approached programming. But if you're
> > already a Ruby coder, you're familiar with passing functions... much of
> my
> > painful switch-over is something you've already experienced.
> >
> >>
> >> I'm just wondering why Scala has to be so complicated.
> >
> > There are two Scalas. The Library Consumer part of Scala which is less
> > complex conceptually an syntactically than either Ruby or Java. The
> Library
> > Producer (types, type bounds, path dependent types, implicits, view
> bounds)
> > that are complex, but I've tried to shield most of that from the casual
> > users of Lift. From a syntax perspective, Scala is less complex that
> Java
> > and far, far less complex than Ruby (just talk to Charlie Nutter who
> > re-implemented Ruby's parser in JRuby.)
> >
> >>
> >> I'm sure a lot
> >> of things in Scala have their reasons but at the mean time I also
> >> suspect that many of the odd things are there to reduce
> >> typing, which is advertised as one of the advantages of this language -
> >> conciseness. (I could be very wrong due to my lack of understanding.)
> >
> > It depends on what strikes you as odd. Please see my next comment.
> >
> >>
> >> If the latter is true, I feel that I'd rather type a little more to make
> >> the
> >> code easier to read.
> >
> > Interesting... I find Clojure hard to read. It's mostly because I don't
> > have a Lisp/Scheme background and I don't know the common function names
> > ("my other car is a cdr"). To me, that's not complexity,
> that's rehearsal.
> > I had the same problems going from Java to Ruby. The syntax, common
> method
> > names, etc. were different and needed to be learned (I can't tell you how
> > many times I was bitten by not being able to do: "Hello " + 33
> (TypeError:
> > can't convert Fixnum into String)... for a dynamic language that ain't so
> > dynamic). Ruby's terrifically complex syntax requires year and years to
> > master, although most of it is simple enough to pick up in a few weeks.
> > Ruby's meta-programming
> >
> >>
> >> Just feeling a little frustrated learning Scala. I think it's much
> >> easier learning
> >> Java. Not much surprise. Not sure if anyone shares my experience
> >> (and opinion, if there is one.)
> >>
> >> On Wed, Oct 21, 2009 at 3:56 PM, Randinn <rand...@gmail.com> wrote:
> >> >
> >> > http://localhost3000.de/2009/10/a-quick-glance-at-lift/
> >> >
> >> > The site above is a blog post from a Rails developer, he had some good
> >> > and bad things to say about Lift and since I do not know enough to
> >> > debate with him I thought I'd post it here.
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
> > >
> >
>
> >
>
--
James A Barrows
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
