On Thu, Oct 22, 2009 at 9:22 AM, David Pollak <feeder.of.the.be...@gmail.com
> wrote:
>
>
> 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.
>
I've worked with an OODBMs systems before, and of course ORM. OODBMs takes
care of the manual saving, and could probably take care of the mutable
fields too.
The problem with OODBMs is that every object has "strings" attached to it to
make the persistence mechanism work. Even the systems that don't require
you to inherit a special class have these "strings". The problem is that in
a web based framework, the tags don't have this string. So you deliver an
unattached field to the browser, then have to reattach it later. This is
actually uglier then it sounds (or was when I was doing it). It's the
de-tached vs attached issues that make things entertaining.
However, AJAX/Comet and the other dynamic stuff wasn't around in 2001, and
so we may be able to solve some of those issues. Whether we can do that and
persist to a RDMS is the real question, and I don't think that will ever be
anything but ugly. I hope I'm proven wrong.
I think Hibernate and JPA are steps in the right direction. JPA being a
half-step back from Hibernate. I think if you could convert the XML to a
real DSL, it would be another step. Annotations are a step there. Another
step would be to create an object sans-setters and getters of any kind.
Just magically deal with the internal object state.
>
>>
>> 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
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
