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."

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.

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.

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.

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.

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.


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
> >

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 
For more options, visit this group at 

Reply via email to