A Critique On Lift

[Randinn]

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.

[jlist9]

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.

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

I'm just wondering why Scala has to be so complicated. 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.)
If the latter is true, I feel that I'd rather type a little more to make the
code easier to read.

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

[ngocdaothanh]

jlist9,
This is a Lift group, but I have to say I feel the same about Scala.

I had to ask for advice here:
http://groups.google.com/group/liftweb/browse_thread/thread/a588f997af842f93/60c378bb36d26030

Scala may help me to get my work done for the day. But I don't feel
happy with Scala. Scala makes me feel I'm a slave all the day to
machines (or Scala itself!).

On Oct 22, 2: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.
>
> 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 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.
>
> I'm just wondering why Scala has to be so complicated. 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.)
> If the latter is true, I feel that I'd rather type a little more to make the
> code easier to read.
>
> 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.)
>

[TylerWeir]

On Oct 22, 2:02 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
> jlist9,
> This is a Lift group, but I have to say I feel the same about Scala.
>

> I had to ask for advice here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...

>
> Scala may help me to get my work done for the day. But I don't feel
> happy with Scala. Scala makes me feel I'm a slave all the day to
> machines (or Scala itself!).

If it makes you feel like a slave, why are you using Scala at all
then?

[Viktor Klang]

Programming is not a simple task, that's why we haven't been replaced by machines.

Scala is a _very_ powerful language, and it _is_ a challenge to harness that power in addition to other languagues you have harnessed.

However, I do not feel that Scala has much non-explainable complexity, as is the case of javas many-a boilerplate.

From what I have seen, much of the barrier of going to Scala is that many people assume that going Java -> Scala-y Java | Java-y Scala -> Ideomatic Scala is the route to go.

But the problem there is that sample Scala code is never Java-y Scala, so beginners get confused from not having learned about first-class functions and their syntax.
(from my 2 years of Scala, what I've seen the pitfalls being)

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Timothy Perrett]

Guys,

Im confused - Scala is not Java. This my friends, is a very good
thing. You cant expect to start a language and be able to use all the
advanced features right away.... I doubt you were a meta-programming
ninja when learning ruby!

Getting back on topic, I read the original link and I admit, it made
me chuckle somewhat - the author kept referring to so-called "rails
bashing" and then quoted a performance benchmark statement as being
"rails bashing"; it is quite obviously a factual statement rather than
anything aggressive. When your a new framework, people want reasons to
entertain you and comparing against existing tools is the only way to
do this.

Regarding his comments on templating - perhaps its a personal
preference, but I cant help feeling that he slightly didnt get the
full picture as he only appears to have explored crudify rather than
the full binding possibilities.

Cheers, Tim

[ngocdaothanh]

Because Lift's ad is so good. For example:

"Lift is the only new framework in the last four years to offer fresh
and innovative approaches to web development. It's not just some
incremental improvements over the status quo, it redefines the state
of the art. If you are a web developer, you should learn Lift. Even if
you don't wind up using it everyday, it will change the way you
approach web applications."

Lift can't be used without Scala. Is there a plan to implement Lift in
Clojure, for example? :D

[Marius]

+1 Tim & Viktor.

Many people with this sort of background and Java web frameworks too
find difficult to accept that we don't do MVC. Also they find
difficult to accepts XML in Scala Snippets. When I presented Scala &
Lift at Transylvania JUG I got the same concerns ... "What? ... markup
in Scala code" ? ... I realized that snippets are very often
misunderstood. They are NOT "controllers" .. they are simple
constructs to allow dynamic markup to be injected in the template. Of
course one can abuse anything in any framework but this is besides the
point. Scala is not Java as Tim said and Scala + XML makes perfect
sense to me. Secondly people argue a lot having data models aware of
the representation of the view - such as a Field to know how to render
itself in a form etc. Personally I think that dumb objects holding
nothing but setter/getters/equals/hashcode just moves you away from
the OOP value. Having objects more context aware and hold the
knowledge on how to represent themselves makes a lot of sense to me,
and in practice I think this proved to be quite valuable. I accept
that many people think that MVC is the Holly Grail, but I don't
believe that ... and I think most people really using Lift don't
believe that either.

Br's,
Marius

On Oct 22, 11:21 am, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Guys,
>
> Im confused  - Scala is not Java. This my friends, is a very good  
> thing. You cant expect to start a language and be able to use all the  
> advanced features right away.... I doubt you were a meta-programming  
> ninja when learning ruby!
>
> Getting back on topic, I read the original link and I admit, it made  
> me chuckle somewhat - the author kept referring to so-called "rails  
> bashing" and then quoted a performance benchmark statement as being  
> "rails bashing"; it is quite obviously a factual statement rather than  
> anything aggressive. When your a new framework, people want reasons to  
> entertain you and comparing against existing tools is the only way to  
> do this.
>
> Regarding his comments on templating - perhaps its a personal  
> preference, but I cant help feeling that he slightly didnt get the  
> full picture as he only appears to have explored crudify rather than  
> the full binding possibilities.
>
> Cheers, Tim
>
> On 22 Oct 2009, at 07:02, ngocdaothanh wrote:
>
>
>
> > jlist9,
> > This is a Lift group, but I have to say I feel the same about Scala.
>
> > I had to ask for advice here:

> >http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...

[Timothy Perrett]

Well said that man! Couldn't agree more with this statement.

Cheers, Tim

[tiro]

> override def validations = validPriority _ :: super.validations

funny, I had stumbled on exactly the same line of code when beginning.
Took me more than a day to understand what's going on. Especially
because when you copied code from the PDF version of the Liftbook/Lift
getting started guide, it would mess up spaces, so I would keep
loooking for a "_::" operator.
The Scala guys have really pushed it a bit hard on the use of the
underscore. At least four different uses:
- "it" for defining anonymous functions like above
- default value
- matching placeholder whose value is ignored
- use for constructing setter method names boolean functions (empty_?)

[Timothy Perrett]

I think this is a bit of a running joke in the scala comunity right
now - your right, underscore really does have a number of meanings; I
think this will be changed in some future Scala release.

Your also forgetting:

import some.package._

Cheers, Tim

[jlist9]

Yes. Typically one will only see a couple of Java-y Scala samples in
the tutorials to show that you can write Scala the Java way
to encourage Java developers to pick up Scala. However, in any
real world applications and libraries you'll only see Scala-y Scala
and that's where the disconnect is.

I thought I could start reading some Scala code after reading a few
tutorials and chapters in a Scala book but that wasn't the case. :-)

However, I'm starting to see the power of Scala, while my head hurts
trying to fit itself to functional thinking and the rich and confusing syntax
(to a beginner at least.)

[David Pollak]

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 <ran...@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

[Timothy Perrett]

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. 

Cheers, Tim

[David Pollak]

On Thu, Oct 22, 2009 at 9:18 AM, Timothy Perrett <tim...@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.

[Timothy Perrett]

Right, no one likes mutable anything :-)

I kinda wondered why you haven't pushed forward any more with the
current record implementation... can one assume that is why - because
it didn't feel right?

Some of this stuff is going to be fundamental to how we move forward -
id love to perhaps discuss something that would be better than what we
have already. Even if its just pie in the sky talk...

Cheers, Tim

[Jim Barrows]

On Thu, Oct 22, 2009 at 9:22 AM, David Pollak <feeder.of...@gmail.com> wrote:

On Thu, Oct 22, 2009 at 9:18 AM, Timothy Perrett <tim...@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. 

--
James A Barrows

[Raoul Duke]

hi,

i take issue with the following:

> misunderstood. They are NOT "controllers" .. they are simple
> constructs to allow dynamic markup to be injected in the template. Of
> course one can abuse anything in any framework but this is besides the
> point.

my personal take is that if you are a responsible, caring, provider
then you will realize that anything can be abused, and you will do
your best to (a) reduce the chances for abuse and (b) give clear
explanations (documentation) for the raison d'etre, and for the
nuances, and for the do-not-do's.

sincerely.

[jlist9]

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.

jlist9

[Jim Barrows]

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? :) 

--
James A Barrows

[David Pollak]

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!

Thanks!
 

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

Yeah... that's a big problem for Scala.  If Scala were CAL (http://groups.google.com/group/cal_language) there'd be fewer ways to do stuff.  But Scala straddles Function and OO, Java libraries and Scala libraries, etc.

Personally (in my "library consumer mode"), I use very little of Scala.  I use List and Map and some XML stuff.  I use case classes and pattern matching.  I pass functions as parameters just like String and Long.  I use Tuples.  I think all that stuff is usable.  I think it's consumable.  Try using less of the language and libraries and see how it suits you.
 

[jlist9]

> Perl's motto is "There is more then one way to do it."

I remember reading somewhere that part of the the design goal
of Perl 6 was to make the language "more sane". That says
it all. For scripting language, I'd stick to Python, whose syntax
feels natural to me, and to stay sane as much as I can. :-)

> Each brings it's own strengths and weaknesses to the table.

True. But the same could be said if you had 10 ways to start a program.
You have to balance the downside and the benefit. I personally think
The confusion of 2 or 3 ways already out-weights the benefit in this
particular case :-)

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

In those cases you are not starting a program/process. You are
only loading a library - your code being the library, the framework being
the entry point of the process.

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

Thanks for the explanation. I'll try to understand it.

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

If you are talking about Java, that's true. Python is very concise, though.
People say if you are not able to do the same thing in 1/10 LoC in Python
as in Java, you are not coding Python right. I think it's exaggerating a little
bit but it's close. This is probably partially due to the dynamic nature of
Python..

> 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? :)

I guess it depends on the goal of driving. NASCAR is definitely more fun
but If the goal is to go from point A to B in time, safely and in a environment
friendly way, maybe the Prius driver :-) And I think these are Java developers
that Scala is also trying to appeal to.

[jlist9]

Just want to add to this. web.py is a Python web development framework
that I like a lot, for its simplicity. In about 10 lines of code you can have
a complete, albeit simple, web application. No XML whatsoever.

http://webpy.org/

Hope no one is offended by my mentioning a Python web framework on
Lift list. Just want to say that things can be short and simple as well
as easy to understand and easy to use.

Of course the dynamic languages have their known issues, which is
what drives me to Scala and Lift.

[Jim Barrows]

On Thu, Oct 22, 2009 at 2:27 PM, jlist9 <jli...@gmail.com> wrote:

> Perl's motto is "There is more then one way to do it."

I remember reading somewhere that part of the the design goal
of Perl 6 was to make the language "more sane". That says
it all. For scripting language, I'd stick to Python, whose syntax
feels natural to me, and to stay sane as much as I can. :-)

Eh.  Sanity is overrated :)
 

> Each brings it's own strengths and weaknesses to the table.

True. But the same could be said if you had 10 ways to start a program.
You have to balance the downside and the benefit. I personally think
The confusion of 2 or 3 ways already out-weights the benefit in this
particular case :-)

See my points about noob vs experienced programmer.  Also see: http://scala-blogs.org/2008/07/application-trait-considered-harmful.html

Also, Application is a trait, so any Object can be an application.  See.... multiple reasons :)

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

In those cases you are not starting a program/process. You are
only loading a library - your code being the library, the framework being
the entry point of the process.

Ayup.  The application trait is just an entry point in the process...
 

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

Thanks for the explanation. I'll try to understand it.

Good luck.  I have it bookmarked so I can re-read it regularly :)  Hopefully you're smarter then I am... :)
 

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

If you are talking about Java, that's true. Python is very concise, though.
People say if you are not able to do the same thing in 1/10 LoC in Python
as in Java, you are not coding Python right. I think it's exaggerating a little
bit but it's close. This is probably partially due to the dynamic nature of
Python..

Python's lack of operators vs GREP might have been better :)  GREP is a far better example of operator conciseness. :)

Java has way too much boiler plate code, and way to many code slingers who think the JEE Blueprint Patterns are to be followed dogmatically rather then by need... *SIGH* 
 

> 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? :)

I guess it depends on the goal of driving. NASCAR  is definitely more fun
but If the goal is to go from point A to B in time, safely and in a environment
friendly way, maybe the Prius driver :-) And I think these are Java developers
that Scala is also trying to appeal to.

You answered which is more fun, and analyzed the goals of each.  How about the which driver is more skilled (ie better)? :)
 We can even add, who has more understanding of what happens to make the car go? (which of course leads to the question, whose more fuel efficient, the NASCAR driver who knows the shortest way around a turn, and how to draft? or the prius driver? ) :)

--
James A Barrows

[Ross Mellgren]

Personally I think that Python is great for small simple things, but
as soon as you start to scale the lack of statically checked
guarantees starts to bite you. The larger and larger you get the more
often and more subtle the bites get. Conversely, with a rigorous
statically checked language, you can start to use the static checking
in your favor. And, the more you understand the nuances of the type
system the more and more you can form it to give you even stronger and
stronger guarantees.

Anecdotally, Haskell (which is perhaps one of the most advanced
functional programming languages on the planet, particularly in the
type system department) has regular reports in the mailing list from
newbies that usually go from "wtf" to "whenever I get the compiler to
accept my program, it usually just works" in a fairly short time.

The syntax of Scala is an interesting and convoluted beast straddling
an unusual line between more typical functional programming languages
(Haskell, O'Caml, etc) and Java, and overall I think it ends up doing
a fairly good job, though it does have its confusing parts.

The ability to define operators in particular is a very tricky
subject. I find, along with implicits, that I treat it as a power tool
that should only be used in cases where it really makes quite alot of
sense (used extremely frequently, coming from math concepts, etc).
Luckily, it is fairly easy to find out where operators are coming from
-- if it looks like an operator, then check to see if it has a :
(colon), if it does, the thing on the right is where the operator is
defined, so look in its doc. Otherwise, it's the thing on the left
that has the operator, so look there.

If neither place has the operator, then unfortunately you've just
strayed into implicit conversion territory, which is unfortunately
tricky to track down in many cases. Sometimes in that situation the
scala REPL will help, because it prints out the types of expressions.

Coming from a background of knowing Java and Haskell (along with
Python and many other languages, not apropos to this discussion) I
found the syntax of Scala to initially be inscrutable but I warmed to
it after a month or two and now I think it's pretty good.

Regarding () and {} BTW, you can replace a single-argument argument
list with {}, e.g.

def myFunction(a: String): Unit = println(a)

myFunction("foobar")
myFunction { "foobar" }

The two calls are equivalent. It makes more sense with the latter
format with multiple argument lists or DSL-like things. I could write
up an example if you're interested, but it might be somewhat involved
if you're not familiar with Scala or Lift.

Overall, my suggestion would be to stick with it and ask questions. I
think it's worth it, and the people here are really helpful.

-Ross

[johncch]

I know this is not the programming languages weblog but I'll still
like to chip in a bit..

I love Scala. I know it's confusing, sometimes (more often than not)
it makes my head hurts. But the language itself is so expressive. I
think it's kinda, well, maybe I'm machoistic, but there's often
instances when I run through a hard to understand Scala code and it
just struck me how concise the language is. I'm a relatively n00b
programmer, probably 5 to 7 years coding and most of them dealing with
c, php and all sorts of c spawn in various shallow degree, and at my
work I deal with Java, JavaScript and ActionScript. For me, the first
impression of Scala is that it far exceeds the awesomeness of JS
coding. I think JavaScript is really a very nice scripting language,
but there are certain quirks that makes it feel inadequate at times.
But Scala eliminates them, and adds in static typing, which is like
awesome. And well, far too many underscores.

I think a good mature language is poetic, which I find Scala kinda do
fit this criteria. When you read through a difficult routine you think
"wow, this is clever", instead of times when I read C code and go like
"wow, this is tedious" because a big portion of code ends up dealing
with lower level problems. I know it's not comparable because the
compiler abstracts out stuff, but speaking on a pure philosophical
level, I just like it how the language allows you to do clever things.
Unlike Java *sigh*.

As for lift, I find some things very interesting, and mainly there is
a big shift from the traditional php based or Java based frameworks (I
worked on Drupal before, while not exactly the same stuff, but). I get
the crux of it already, and am moving along and reading code as I go
along. The use of snippets as opposed to a monolithic C layer struck
me as odd, and xml spewing in snippets does feel a little wrong (oh
the darn mvc brainwashing). But overall I like what I see and hope to
do something useful with it. Will comment as I move in more.

Thanks for the good job guys. I think it's Scala and Lift at this
point of time that keeps my computing life exciting. Keep up the good
work.

regards,
CH

[Naftoli Gugenheim]

How hard can automatic save be?
But how would immutable DAOs work? There was a thread, I think on scala-user, a long time ago discussing it, that pretty much concluded it would be very problematic. David weighed in and said after a long time he concluded that databases represent state.


-------------------------------------

Timothy Perrett<tim...@getintheloop.eu> wrote:


Right, no one likes mutable anything :-)

I kinda wondered why you haven't pushed forward any more with the
current record implementation... can one assume that is why - because
it didn't feel right?

Some of this stuff is going to be fundamental to how we move forward -
id love to perhaps discuss something that would be better than what we
have already. Even if its just pie in the sky talk...

Cheers, Tim

[Naftoli Gugenheim]

The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.

-------------------------------------

tiro<tim.r...@googlemail.com> wrote:


> override def validations = validPriority _ :: super.validations

funny, I had stumbled on exactly the same line of code when beginning.
Took me more than a day to understand what's going on. Especially
because when you copied code from the PDF version of the Liftbook/Lift
getting started guide, it would mess up spaces, so I would keep
loooking for a "_::" operator.
The Scala guys have really pushed it a bit hard on the use of the

underscore. At least four different uses:
- "it" for defining anonymous functions like above
- default value
- matching placeholder whose value is ignored

- use for constructing setter method names boolean functions (empty_?)

[jlist9]

Ross,

> Personally I think that Python is great for small simple things, but
> as soon as you start to scale the lack of statically checked
> guarantees starts to bite you.

What you said about the problems with dynamically typed
scripting language is very true. Python is so powerful but the
code is so fragile. You need to write a lot of tests. This is
exactly why I'm trying to learn Scala.

Thanks for your explanation about operators.

> Regarding () and {} BTW, you can replace a single-argument argument
> list with {}, e.g.
>
> def myFunction(a: String): Unit = println(a)
>
> myFunction("foobar")
> myFunction { "foobar" }

I find the following three lines of code do the same thing.
Thanks for your explanation again. I now understand
why the first and second line are equivalent. (But why
does Scala allow {} here? Isn't () good enough?)

I'm not sure what the {} does in the third line, though.

args.foreach{ arg => greeting += (arg + " ") }
args.foreach( arg => greeting += (arg + " ") )
args.foreach( arg => { greeting += (arg + " ") } )

> The two calls are equivalent. It makes more sense with the latter
> format with multiple argument lists or DSL-like things. I could write
> up an example if you're interested, but it might be somewhat involved
> if you're not familiar with Scala or Lift.

Thanks. Let me finish the tutorials first :-)

> Overall, my suggestion would be to stick with it and ask questions. I
> think it's worth it, and the people here are really helpful.

Yes. I plan to bite the bullet and continue with my learning.
And indeed, this is a very friendly and helpful list.

jlist9

[Ross Mellgren]

On Oct 23, 2009, at 2:31 AM, jlist9 wrote:

Regarding () and {} BTW, you can replace a single-argument argument

list with {}, e.g.

def myFunction(a: String): Unit = println(a)

myFunction("foobar")

myFunction { "foobar" }

I find the following three lines of code do the same thing.
Thanks for your explanation again. I now understand
why the first and second line are equivalent. (But why
does Scala allow {} here? Isn't () good enough?)

I find it's good when you're doing a block-like thing where it really expects a single value. Most often I use this with functions that do something "scoped", e.g. acquire a resource and release it, or set some kind of semi-global variable temporarily (RequestVar.doWith, ThreadGlobal.doWith, for example).

I'm not sure what the {} does in the third line, though.

args.foreach{ arg => greeting += (arg + " ") }
args.foreach( arg => greeting += (arg + " ") )
args.foreach( arg => { greeting += (arg + " ") } )

The {}s in this case would allow you to have multiple statements there. To contrast:

args.map(arg => println(arg); arg.length)   // won't compile

args.map { arg => println(arg); arg.length }  // compiles

args.map(arg => { println(arg); arg.length }) // compiles

I personally prefer the last form because my editor will happily eat it and I get some consistency when there's arguments before the function argument. Of course, this is an aesthetic thing, I'm sure other people prefer the parenless form.

-Ross

[Jonas Bonér]

I love the _ operator.

2009/10/22 Timothy Perrett <tim...@getintheloop.eu>:

--
Jonas Bonér

twitter: @jboner
blog: http://jonasboner.com
work: http://scalablesolutions.se
code: http://github.com/jboner
code: http://akkasource.org
also: http://letitcrash.com

[Joni Freeman]

I love it too. While it is used in many different places it always
means "stuff that I do not care to name".

BTW. "high priest of the lambda calculus" loves it too :) It has its
roots in Haskell...

http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/

Cheers Joni

On 23 loka, 09:48, Jonas Bonér <jbo...@gmail.com> wrote:
> I love the _ operator.
>

> 2009/10/22 Timothy Perrett <timo...@getintheloop.eu>:

[Viktor Klang]

My personal interpretation is "sh!t I don't know here or don't care what it is"

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Chris Lewis]

I *think* you're referring to a thread I started some time ago:

http://www.nabble.com/functional-newbie,-domain-entities-td22957479.html

It turned out to be a lively discussion. On a related note, Jonas Boner
gisted this in August:

http://gist.github.com/173921

It's not full code, but it gives you an idea how an immutable data model
might be composed and backed with JPA. There are pain points (java
collections) and unanswered questions here (how will the JPA provider
initialize such a class), but there's what I feel is a language-level
issue. In Scala, if you want methods to immutably evolve an objects'
state, then you must, as Jonas did, write your own "setters" that yield
a new instance with the modification. Sounds like boilerplate to me,
that's another topic.

For the record, I'm not yet fully convinced of the gains in using
immutability in a domain model. Domain entities represent the state of
an application, and in many cases that changes frequently and naturally.
Period. How and why those changes occur are often the result of human
behavior (twitter, facebook). These behaviors are not functional in the
mathematical sense (at least, not that we've discovered), and so I'm not
clear on what we stand to gain in a typical domain model.

[Jeremy Day]

All,

the _ "name" is also used frequently in C++ for template-based lambdas.  At least it is in many of the Boost libraries.

Jeremy

[bob]

i believe that one of the best ways to learn a new programming
language is to read software written in it

when reading Scala code, I rarely say "i don't understand how that
works" and when I do, there's usually a good explanation of it
somewhere on the web.

usually I find myself asking "where is that defined?" or "what part of
the language is that?"

Scala is not like, for example, BASIC, where you can look up FOR, IF/
THEN/ELSE. there's lots of individual and compound punctuation marks
that are very difficult to search for online and in PDFs (try
searching for "!").

a lot of scala also relies on syntactic sugar, such as omitted types
(no ": T" after a val/var/def); the dreaded underbar; operator
overloading; and implicit conversions. you can hate on Java's
verbosity (i know i have), but brevity has its own difficulties.

On Oct 22, 11:44 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?.
>
> -------------------------------------
>

[Chris Lewis]

bob wrote:
> i believe that one of the best ways to learn a new programming
> language is to read software written in it
>
> when reading Scala code, I rarely say "i don't understand how that
> works" and when I do, there's usually a good explanation of it
> somewhere on the web.
>
> usually I find myself asking "where is that defined?" or "what part of
> the language is that?"
>
> Scala is not like, for example, BASIC, where you can look up FOR, IF/
> THEN/ELSE. there's lots of individual and compound punctuation marks
> that are very difficult to search for online and in PDFs (try
> searching for "!").

Indeed, but even cursory survey of scala will reveal that scala has no
operators, only methods. This leads the user to search for docs on type
of instance on which the punctuated invocation is made. I don't see the
confusion there. You could of course make an argument on implicits ...

[Chris Lewis]

My head just exploded. Twice.

ngocdaothanh wrote:
> Because Lift's ad is so good.

*boom*

For example:
>
> "Lift is the only new framework in the last four years to offer fresh
> and innovative approaches to web development. It's not just some
> incremental improvements over the status quo, it redefines the state
> of the art. If you are a web developer, you should learn Lift. Even if
> you don't wind up using it everyday, it will change the way you
> approach web applications."
>
> Lift can't be used without Scala. Is there a plan to implement Lift in
> Clojure, for example? :D

*BOOM*

>
>
> On Oct 22, 3:47 pm, TylerWeir <tyler.w...@gmail.com> wrote:
>> On Oct 22, 2:02 am, ngocdaothanh <ngocdaoth...@gmail.com> wrote:
>>
>>> jlist9,
>>> This is a Lift group, but I have to say I feel the same about Scala.
>>> I had to ask for advice here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
>>> Scala may help me to get my work done for the day. But I don't feel
>>> happy with Scala. Scala makes me feel I'm a slave all the day to
>>> machines (or Scala itself!).
>> If it makes you feel like a slave, why are you using Scala at all
>> then?

>>
>>
>>
>>> On Oct 22, 2: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.

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

>>>> I'm just wondering why Scala has to be so complicated. 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.)

>>>> If the latter is true, I feel that I'd rather type a little more to make the
>>>> code easier to read.

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

[Jim Barrows]

On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis <burning...@gmail.com> wrote:

My head just exploded. Twice.

That explains the wet face this morning when I woke up... thought it was the dog licking it... :)
 

ngocdaothanh wrote:
> Because Lift's ad is so good.

*boom*

It was good.  My first thought was "Yeah.... rIIIIIIIIIIIIIIIIIIIIIIIIIIIIIGHT!"  Let's see what they mean.....
And voila... here I am.. so it was good, if only because it was right :)
 

 For example:
>
> "Lift is the only new framework in the last four years to offer fresh
> and innovative approaches to web development. It's not just some
> incremental improvements over the status quo, it redefines the state
> of the art. If you are a web developer, you should learn Lift. Even if
> you don't wind up using it everyday, it will change the way you
> approach web applications."
>
> Lift can't be used without Scala. Is there a plan to implement Lift in
> Clojure, for example? :D

*BOOM*

Ummm.. ok.. This one I understand.
 

--
James A Barrows

[David Pollak]

On Fri, Oct 23, 2009 at 9:29 AM, Jim Barrows <jim.b...@gmail.com> wrote:

On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis <burning...@gmail.com> wrote:

My head just exploded. Twice.

That explains the wet face this morning when I woke up... thought it was the dog licking it... :)
 

ngocdaothanh wrote:
> Because Lift's ad is so good.

*boom*

It was good.  My first thought was "Yeah.... rIIIIIIIIIIIIIIIIIIIIIIIIIIIIIGHT!"  Let's see what they mean.....
And voila... here I am.. so it was good, if only because it was right :)
 

 For example:
>
> "Lift is the only new framework in the last four years to offer fresh
> and innovative approaches to web development. It's not just some
> incremental improvements over the status quo, it redefines the state
> of the art. If you are a web developer, you should learn Lift. Even if
> you don't wind up using it everyday, it will change the way you
> approach web applications."
>
> Lift can't be used without Scala. Is there a plan to implement Lift in
> Clojure, for example? :D

I've thought about it and even done some initial poking around with Clojure.  It could be done, but I really like static typing so don't want to spend a lot of time in Clojure's unityped land.
 

[jlist9]

It's often hard to describe some (I'd say most) of the Scala syntax
if you want to search for an answer online.

It would be great if the eclipse plugin can tell you what the code is
trying to do and what kind of syntax is that, for example, linking
an operator back to a method name.

[Chris Lewis]

jlist9 wrote:
> It's often hard to describe some (I'd say most) of the Scala syntax
> if you want to search for an answer online.

I can't relate with that. I've been coding scala for 3-4 months, and
I've never had any problem finding method definitions. Most of this
probably had to do with that fact that I was reading through several
language overviews and tutorials.

> It would be great if the eclipse plugin can tell you what the code is
> trying to do and what kind of syntax is that, for example, linking
> an operator back to a method name.

I'll repeat: there are no operators in scala. Not a single one. "linking
an operator back to a method name" doesn't make sense. Accept that
_everything_ in scala, except methods, is an object, and as such adheres
to its respective class contract. If you need to look up the meaning of
an "operator," all you need to know is the type on which it is being
invoked. The only real complexity in this resolution then is introduced
by implicits.

[bob]

>I'll repeat: there are no operators in scala

s/operators/methods-with-operator-like-names/

anywhere, here's a typical case:

import some.library.package.foo._

val a = bar 42
val b = a ~!~ 3.14159

you can't easily tell that bar is being imported via foo._ .
what is bar's return type?
what does ~!~ do?

i'm not saying its not possible to track all this down, but you can't
just print out a listing of a class and take it on the subway. you
have to have access to the scaladocs and possibly even the sources.

--b

[Viktor Klang]

But if you name your method: "ashiuahsdyasdasd" what does it do?

[Jim Barrows]

On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang <viktor...@gmail.com> wrote:

But if you name your method: "ashiuahsdyasdasd" what does it do?

Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read it....
 

--
James A Barrows

[Viktor Klang]

On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows <jim.b...@gmail.com> wrote:

On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang <viktor...@gmail.com> wrote:

But if you name your method: "ashiuahsdyasdasd" what does it do?

Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read it....

Chtuluh ftagn! ;D

[Jim Barrows]

On Fri, Oct 23, 2009 at 3:28 PM, Viktor Klang <viktor...@gmail.com> wrote:

On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows <jim.b...@gmail.com> wrote:

On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang <viktor...@gmail.com> wrote:

But if you name your method: "ashiuahsdyasdasd" what does it do?

Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read it....

Chtuluh ftagn! ;D

Huh.  Now he's 6 inches tall and has a red nose.... interesting.

Also I think we've made our point about cryptic method names whether there alphanumeric or not, whether you call them operators or not... are problematic.

Now excuse me... cthulu appears to be mucking with my code....

James A Barrows

[bob]

why, it reformats your hard drive

[Viktor Klang]

On Sat, Oct 24, 2009 at 8:18 PM, bob <rbpa...@gmail.com> wrote:

why, it reformats your hard drive

oh snap

[Randinn]

>
> Scala is not like, for example, BASIC, where you can look up FOR, IF/
> THEN/ELSE. there's lots of individual and compound punctuation marks
> that are very difficult to search for online and in PDFs (try
> searching for "!").
>

This is where I am coming from, coding after a 16 or so year hiatus
and my main language was basic so I guess I am one of the rare ones
here who doesn't have the OOP/Java hang-ups, I just have a whole
different set of hang-ups to deal with. I have been looking at Scala
for some months and have to admit it is starting to sink in, of course
having to learn everything else in order to learn it is making it take
a bit longer.

[Randinn]

This may not be it, but you can at least print out this list :)

http://jim-mcbeath.blogspot.com/2008/12/scala-operator-cheat-sheet.html

[bob]

seriously, if you're suggesting that since function/method names don't
have to have any relationship to the algorithm therein, so using
punctuation should be fine, then why not just use single letters,
followed by an optional digit, and be done.

`When I use a word,' Humpty Dumpty said, in rather a scornful tone,
`it means just what I choose it to mean -- neither more nor less.'

On Oct 24, 2:44 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:

[bob]

is that for Scala or Perl? :)