On Thu, Oct 22, 2009 at 9:18 AM, Timothy Perrett <timo...@getintheloop.eu>wrote:

> David,
> I think your response was well measured and appropriate. The analogy of
> linguistics is a good one :-)
> Without wanting to diverge this thread, can I ask why it is your unhappy
> with Record? Its been fairly fun to use so far and appears to work well.

I don't like mutable fields.  I don't like manual saving.  Dunno... it's
hard to articulate... it just feels wrong in my tummy.  Also, I want to be
clear that I think Marius did a great job of cleaning up some of the
problems with Mapper when he did Record... my comments are not a negative to
him... there's just something unsatisfying about the whole approach.

Bet that was less than helpful.

> Cheers, Tim
> On 22 Oct 2009, at 17:04, David Pollak 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
> >

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