Fwd: Scala, Scala you got me worried

On Friday March 13 2009, Raoul Duke wrote:
> > But there is enough that remains. In an ideal world,
> > I'd throw out classes and keep only traits, maybe throw out
> > generics and keep only abstract types. But the resulting language
> > would be an island...
>
> I might misunderstand what is being talked about here, but what would
> you say about Clojure in this regard?

You'd have to give it even higher parsimony marks than Scala (and I
don't agree with Eric that Scala scores poorly in parsimony), but then,
Clojure has several things contributing to that advantage:

- S-expression-based
- No type system of its own
- No object system of its own

The second two make the comparison unfair, I believe. Clearly there's a
sharp divide between those who like object-oriented languages and those
who don't. I know what I like. There's a similar divide regarding
static vs. dynamic typing, and I know where I come down on that, too.

As for Scala's parsimony, I think the relatively high proportion of
punctuation (non-alphanumeric) characters may lend an initial air of
inscrutability to Scala and that may get confused with a lack of
parsimony, while in fact it's part of how Scala's parsimony is
enhanced.

> sincerely.

Randall Schulz

First of all, I don't understand your example, since hasAny seems to
check the collection itself for non-emptiness, whereas the scala code
checks whether the collection has a nonempty element.

Even if our utility function would be equivalent to the scala code, I
prefer a short succint scala sequences to houndreds of small utility
functions for the following reasons:

1) It's hard to memorize a lot of function names. If I want to use
them, I'll have to look them up.
2) If I want to check the code, I have to check first whether the code
works as expected, then I have to check whether it applied correctly.
3) Psychologically, it seems easier to get it right to make trivial
mistakes in shorter code.
4) It is more pleasing aesthetically.

On 3/13/09, John Nilsson wrote:
>
> As an example in our Java project we have lots of small utility
> methods like "has" "hasAll" "hasAny" that can be used instead of x !=
> null && !x.isEmpty() or what ever mechanics most succintly express the
> need.
>
> Compare
>
> hasAny(var1,var2,var3)
>
> with
>
> List(var1,var2,var3) exists {! empty _ } // If this is valid Scala
>
> I'd say the first one is preferred because it communicates the intent
> at a higher abstraction.
>
> BR,
>
> John
>
>
> On Fri, Mar 13, 2009 at 9:24 PM, Christian Szegedy
> wrote:
>
> > I disagree.
> >
> > Just think of mathematics: it was a revolution in the 16-17th century when
> > algebra was invented. It might look cryptic at first, but just compare
> > the following two
> >
> > (-b +|- sqrt(b^2-4ac ) )/(2a)
> >
> > with:
> >
> > "Let the discriminant denote the square of the of coefficient of the
> > linear term minus
> > four times the product of the coefficients of the linear and the
> > quadratic terms.
> >
> > First take the coeffiecient of the linear term of the equation,
> > multiply it by minus one,
> > then both add and substract the square root of the discriminant.
> >
> > You get two (possibly different) results. Divide both values by two
> > times the coefficient
> > of the quadratic term to get the roots of the equation."
> >
> > It maybe easier to read for someone who has *no idea*, but try to do
> > the same thing
> > e.g. for the Cardano formula, and then try to manipulate or reason
> > about anything like
> > that formally. All that is possible, but it is error-prone and
> > extremely cumbersome.
> >
> > Nowadays nobody would argue the a professional book about physics, economics,
> > chemistry, engineering, etc. contains too many formulas. All of them have their
> > own operators, naming conventions etc. and looks abstract gibberish to anyone
> > not familiar with the domain. But that's fine, these books are written
> > for those that
> > *are* familiar and they would not tolerate a verbose salad of words.
> >
> > Actually my sentiment is very close to that of Paul Graham's expressed in
> > http://www.paulgraham.com/noop.html
> > where he argues:
> >
> > "Object-oriented programming generates a lot of what looks like work.
> > Back in the days of fanfold, there was a type of programmer who would
> > only put five or ten lines of code on a page, preceded by twenty lines
> > of elaborately formatted comments. Object-oriented programming is
> > like crack for these people: it lets you incorporate all this
> > scaffolding right into your source code. Something that a Lisp hacker
> > might handle by pushing a symbol onto a list becomes a whole file of
> > classes and methods. So it is a good tool if you want to convince
> > yourself, or someone else, that you are doing a lot of work."
> >
> >
> > On 3/13/09, John Nilsson wrote:
> >> I think one of the major problem with Scala (which isn't catuall a
> >> "problem" in the languge, but maybe some feature can be added to help)
> >> is that the boiler plate code is terser than the non-boiler plate
> >> code.
> >>
> >> What I mean is that in Java you get rid of boilerplate by naming
> >> stuff. You don't do anonymous functions because its to verbose, and
> >> thus you create something, with a name, that implements the required
> >> stuff. F.ex. I've found that for "map" to be usable at all in Java i
> >> have to prepare a bunch of often needed mapping functions, and even
> >> add special mapToFoo methods.
> >>
> >> But in scala it's so easy to write theese low level things that you
> >> just string them together in place and are content with that. That's
> >> how you end up with non-sense code talking about functors, maps, folds
> >> and lambdas, all in one line. When what the code _REALLY_ should be
> >> talking about is customers, names, html strings, money amounts and
> >> other things that the application is supposed to be about.
> >>
> >> So my 2 cents to the Effective Scala books: Name things! Measure code
> >> quality in "domain terms" per "programming term".
> >>
> >>
> >> My second problem with reading some Scala code is the complete lack of
> >> white space and strucure hinting braces and such. The Scala guideline
> >> of two space indents and braces on the same line is in my view
> >> dangerous. Code should not be a dense block of logic. It should be a
> >> carefully formatted text describing the idea of the problem domain and
> >> it's solution.
> >>
> >>
> >> BR,
> >>
> >> John
> >>
> >>
> >>
> >> On Fri, Mar 13, 2009 at 4:19 PM, Robert Fischer
> >> wrote:
> >> > One major difficulty with learning scala is the wide range of structures
> >> > available: Classes, Case Classes, Traits, Objects, ... (I'm missing
> >> > something there, I know it) -- they're kinda-sorta orthogonal, and there's
> >> > not a lot of accessible documentation about how they interact. When you
> >> > want a val and a def, and when you need to override or not, and when to seal
> >> > things, and how implicit interacts with all of this...there's just a lot of
> >> > bookkeeping in the type system, all of which needs to be understood to make
> >> > sense out of the Scala API.
> >> >
> >> > Speaking of which, consider type signatures like this:
> >> > def reduceLeft[B >: A](op : (B, A) => B) : B
> >> > def orElse[A1 <: A, B1 >: B](that : PartialFunction[A1, B1]) :
> >> > PartialFunction[A1, B1]
> >> > def acceptSeq[ES](es : ES)(implicit view$2 : (ES) => Iterable[Elem]) :
> >> > Parser[List[Elem]]
> >> > case class ~[+a, +b](val _1 : a, val _2 : b) extends Product
> >> >
> >> > These are extremely daunting for anyone who doesn't already fully grok the
> >> > Scala API: it's pretty much impossible to come from outside of a Scala
> >> > library and pick it up without starting by stealing examples of working code
> >> > from somewhere else.
> >> >
> >> > That's what people mean when they say that it's "too academic": it's got
> >> > this high barrier to entry requiring lots of smarts before you can even
> >> > really get rolling.
> >> >
> >> > ~~ Robert.
> >> >
> >> > Carsten Saager wrote:
> >> >>
> >> >> Apart from trolling and the unverifable code-critism his view is not so
> >> >> far off from what I hear when people come back to me after I told them about
> >> >> Scala:
> >> >>
> >> >> Most common problems
> >> >>
> >> >> * Whatever IDE you use (and beginners can't simply go with vi or
> >> >> emacs) - either you have to use a beta where your milage may vary
> >> >> or you'll miss many things Java people take for granted
> >> >> * Looking for examples usually turns up "very concise solutions" -
> >> >> the Effective Scala is really needed
> >> >> * Actors are nice, but the documentation is poor
> >> >> * Same for ScalaSwing
> >> >> * Too academic - it is just perception, but as Scala allows you to
> >> >> do interesting things, thus a higher proportion of "exploratory
> >> >> programming" is made in Scala than in Java or VB
> >> >> It must be said that the Scala book does a very good job in explaining how
> >> >> Scala works and how its libaries can be used efficasiously, we need more and
> >> >> as well deeper texts like this.
> >> >>
> >> >> The points above are for many enough reason to leave Scala - today it
> >> >> isn't job-relevant so if you want to do programming on your own time you
> >> >> might not search for extra frustrations. I can well imagine that if you get
> >> >> forced to work on a pile of code that is "Worst-practices in Scala" isn't
> >> >> perhaps enchanting neither
> >> >>
> >> >>
> >> >> -Carsten
> >> >> On Fri, Mar 13, 2009 at 3:44 PM, Miles Sabin >> >> > wrote:
> >> >>
> >> >> On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday >> >> > wrote:
> >> >> > It was your message in the first place which was discourteous...
> >> >>
> >> >> Come on folks ... you surely recognize a troll when you see one ...
> >> >> don't feed him ... he'll just keep going if you do.
> >> >>
> >> >> Cheers,
> >> >>
> >> >>
> >> >> Miles
> >> >>
> >> >> --
> >> >> Miles Sabin
> >> >> tel: +44 (0)1273 720 779
> >> >> mobile: +44 (0)7813 944 528
> >> >> skype: milessabin
> >> >>
> >> >>
> >> >
> >> > --
> >> > ~~ Robert Fischer.
> >> > Grails Training http://GroovyMag.com/training
> >> > Smokejumper Consulting http://SmokejumperIT.com
> >> > Enfranchised Mind Blog http://EnfranchisedMind.com/blog
> >> >
> >> > Check out my book, "Grails Persistence with GORM and GSQL"!
> >> > http://www.smokejumperit.com/redirect.html
> >> >
> >>
> >
>

Sorry about the hasAll implementation. A brain farton my part. It was
supposed to check the elements...

Regarding your other points: I guess we just have to agree to disagree ;)

On Sat, Mar 14, 2009 at 12:12 AM, Christian Szegedy
wrote:
> First of all, I don't understand your example, since hasAny seems to
> check the collection itself for non-emptiness, whereas the scala code
> checks whether the collection has a nonempty element.
>
> Even if our utility function would be equivalent to the scala code, I
> prefer a short succint scala sequences to houndreds of small utility
> functions for the following reasons:
>
> 1) It's hard to memorize a lot of function names. If I want to use
> them, I'll have to look them up.
> 2) If I want to check the code, I have to check first whether the code
> works as expected, then I have to check whether it applied correctly.
> 3) Psychologically, it seems easier to get it right to make trivial
> mistakes in shorter code.
> 4) It is more pleasing aesthetically.
>
> On 3/13/09, John Nilsson wrote:
>>
>>  As an example in our Java project we have lots of small utility
>>  methods like "has" "hasAll" "hasAny" that can be used instead of x !=
>>  null && !x.isEmpty() or what ever mechanics most succintly express the
>>  need.
>>
>>  Compare
>>
>>  hasAny(var1,var2,var3)
>>
>>  with
>>
>>  List(var1,var2,var3) exists {! empty _ } // If this is valid Scala
>>
>>  I'd say the first one is preferred because it communicates the intent
>>  at a higher abstraction.
>>
>>  BR,
>>
>> John
>>
>>
>>  On Fri, Mar 13, 2009 at 9:24 PM, Christian Szegedy
>>   wrote:
>>
>> > I disagree.
>>  >
>>  > Just think of mathematics: it was a revolution in the 16-17th century when
>>  > algebra was invented. It might look cryptic at first, but just compare
>>  > the following two
>>  >
>>  > (-b +|- sqrt(b^2-4ac ) )/(2a)
>>  >
>>  > with:
>>  >
>>  > "Let the discriminant denote the square of the of coefficient of the
>>  > linear term minus
>>  > four times the product of the coefficients of the linear and the
>>  > quadratic terms.
>>  >
>>  > First take the coeffiecient of the linear term of the equation,
>>  > multiply it by minus one,
>>  > then both add and substract the square root of the discriminant.
>>  >
>>  > You get two (possibly different) results.  Divide both values by two
>>  > times the coefficient
>>  > of the quadratic term to get the roots of the equation."
>>  >
>>  > It maybe easier to read for someone who has *no idea*, but try to do
>>  > the same thing
>>  > e.g. for the Cardano formula, and then try to manipulate or reason
>>  > about anything like
>>  > that formally. All that is possible, but it is error-prone and
>>  > extremely cumbersome.
>>  >
>>  > Nowadays nobody would argue the a professional book about physics, economics,
>>  > chemistry, engineering, etc. contains too many formulas. All of them have their
>>  > own operators, naming conventions etc. and looks abstract gibberish to anyone
>>  > not familiar with the domain. But that's fine, these books are written
>>  > for those that
>>  > *are* familiar and they would not tolerate a verbose salad of words.
>>  >
>>  > Actually my sentiment is very close to that of Paul Graham's expressed in
>>  > http://www.paulgraham.com/noop.html
>>  > where he argues:
>>  >
>>  > "Object-oriented programming generates a lot of what looks like work.
>>  > Back in the days of fanfold, there was a type of programmer who would
>>  > only put five or ten lines of code on a page, preceded by twenty lines
>>  > of elaborately formatted comments.  Object-oriented programming is
>>  > like crack for these people: it lets you incorporate all this
>>  > scaffolding right into your source code.  Something that a Lisp hacker
>>  > might handle by pushing a symbol onto a list becomes a whole file of
>>  > classes and methods.  So it is a good tool if you want to convince
>>  > yourself, or someone else, that you are doing a lot of work."
>>  >
>>  >
>>  > On 3/13/09, John Nilsson wrote:
>>  >> I think one of the major problem with Scala (which isn't catuall a
>>  >>  "problem" in the languge, but maybe some feature can be added to help)
>>  >>  is that the boiler plate code is terser than the non-boiler plate
>>  >>  code.
>>  >>
>>  >>  What I mean is that in Java you get rid of boilerplate by naming
>>  >>  stuff. You don't do anonymous functions because its to verbose, and
>>  >>  thus you create something, with a name, that implements the required
>>  >>  stuff. F.ex. I've found that for "map" to be usable at all in Java i
>>  >>  have to prepare a bunch of often needed mapping functions, and even
>>  >>  add special mapToFoo methods.
>>  >>
>>  >>  But in scala it's so easy to write theese low level things that you
>>  >>  just string them together in place and are content with that. That's
>>  >>  how you end up with non-sense code talking about functors, maps, folds
>>  >>  and lambdas, all in one line. When what the code _REALLY_ should be
>>  >>  talking about is customers, names, html strings, money amounts and
>>  >>  other things that the application is supposed to be about.
>>  >>
>>  >>  So my 2 cents to the Effective Scala books: Name things! Measure code
>>  >>  quality in "domain terms" per "programming term".
>>  >>
>>  >>
>>  >>  My second problem with reading some Scala code is the complete lack of
>>  >>  white space and strucure hinting braces and such. The Scala guideline
>>  >>  of two space indents and braces on the same line is in my view
>>  >>  dangerous. Code should not be a dense block of logic. It should be a
>>  >>  carefully formatted text describing the idea of the problem domain and
>>  >>  it's solution.
>>  >>
>>  >>
>>  >>  BR,
>>  >>
>>  >> John
>>  >>
>>  >>
>>  >>
>>  >>  On Fri, Mar 13, 2009 at 4:19 PM, Robert Fischer
>>  >>   wrote:
>>  >>  > One major difficulty with learning scala is the wide range of structures
>>  >>  > available: Classes, Case Classes, Traits, Objects, ... (I'm missing
>>  >>  > something there, I know it) -- they're kinda-sorta orthogonal, and there's
>>  >>  > not a lot of accessible documentation about how they interact.  When you
>>  >>  > want a val and a def, and when you need to override or not, and when to seal
>>  >>  > things, and how implicit interacts with all of this...there's just a lot of
>>  >>  > bookkeeping in the type system, all of which needs to be understood to make
>>  >>  > sense out of the Scala API.
>>  >>  >
>>  >>  > Speaking of which, consider type signatures like this:
>>  >>  > def reduceLeft[B >: A](op : (B, A) => B) : B
>>  >>  > def orElse[A1 <: A, B1 >: B](that : PartialFunction[A1, B1]) :
>>  >>  > PartialFunction[A1, B1]
>>  >>  > def acceptSeq[ES](es : ES)(implicit view$2 : (ES) => Iterable[Elem]) :
>>  >>  > Parser[List[Elem]]
>>  >>  > case class ~[+a, +b](val _1 : a, val _2 : b) extends Product
>>  >>  >
>>  >>  > These are extremely daunting for anyone who doesn't already fully grok the
>>  >>  > Scala API: it's pretty much impossible to come from outside of a Scala
>>  >>  > library and pick it up without starting by stealing examples of working code
>>  >>  > from somewhere else.
>>  >>  >
>>  >>  > That's what people mean when they say that it's "too academic": it's got
>>  >>  > this high barrier to entry requiring lots of smarts before you can even
>>  >>  > really get rolling.
>>  >>  >
>>  >>  > ~~ Robert.
>>  >>  >
>>  >>  > Carsten Saager wrote:
>>  >>  >>
>>  >>  >> Apart from trolling and the unverifable code-critism his view is not so
>>  >>  >> far off from what I hear when people come back to me after I told them about
>>  >>  >> Scala:
>>  >>  >>
>>  >>  >> Most common problems
>>  >>  >>
>>  >>  >>    * Whatever IDE you use (and beginners can't simply go with vi or
>>  >>  >>      emacs) - either you have to use a beta where your milage may vary
>>  >>  >>      or you'll miss many things Java people take for granted
>>  >>  >>    * Looking for examples usually turns up "very concise solutions" -
>>  >>  >>      the Effective Scala is really needed
>>  >>  >>    * Actors are nice, but the documentation is poor
>>  >>  >>    * Same for ScalaSwing
>>  >>  >>    * Too academic - it is just perception, but as Scala allows you to
>>  >>  >>      do interesting things, thus a higher proportion of "exploratory
>>  >>  >>      programming" is made in Scala than in Java or VB
>>  >>  >> It must be said that the Scala book does a very good job in explaining how
>>  >>  >> Scala works and how its libaries can be used efficasiously, we need more and
>>  >>  >> as well deeper texts like this.
>>  >>  >>
>>  >>  >> The points above are for many enough reason to leave Scala - today it
>>  >>  >> isn't job-relevant so if you want to do programming on your own time you
>>  >>  >> might not search for extra frustrations. I can well imagine that if you get
>>  >>  >> forced to work on a pile of code that is "Worst-practices in Scala" isn't
>>  >>  >> perhaps enchanting neither
>>  >>  >>
>>  >>  >>
>>  >>  >> -Carsten
>>  >>  >> On Fri, Mar 13, 2009 at 3:44 PM, Miles Sabin >  >>  >> > wrote:
>>  >>  >>
>>  >>  >>    On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday >  >>  >>    > wrote:
>>  >>  >>     > It was your message in the first place which was discourteous...
>>  >>  >>
>>  >>  >>    Come on folks ... you surely recognize a troll when you see one ...
>>  >>  >>    don't feed him ... he'll just keep going if you do.
>>  >>  >>
>>  >>  >>    Cheers,
>>  >>  >>
>>  >>  >>
>>  >>  >>    Miles
>>  >>  >>
>>  >>  >>    --
>>  >>  >>    Miles Sabin
>>  >>  >>    tel:    +44 (0)1273 720 779
>>  >>  >>    mobile: +44 (0)7813 944 528
>>  >>  >>    skype:  milessabin
>>  >>  >>
>>  >>  >>
>>  >>  >
>>  >>  > --
>>  >>  > ~~ Robert Fischer.
>>  >>  > Grails Training        http://GroovyMag.com/training
>>  >>  > Smokejumper Consulting http://SmokejumperIT.com
>>  >>  > Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>>  >>  >
>>  >>  > Check out my book, "Grails Persistence with GORM and GSQL"!
>>  >>  > http://www.smokejumperit.com/redirect.html
>>  >>  >
>>  >>
>>  >
>>
>

I strongly agree that giving meaningful descriptive variable names is
the best form of source documentation, wherever a variable is
*necessary*.

What I don't believe is that programmers should be forced to rewrite
the same function with different names over and over again (due to
lack of suitable abstraction mechanisms in the language).

On 3/13/09, Randall R Schulz wrote:
> On Friday March 13 2009, Christian Szegedy wrote:
> > I disagree.
> >
> > Just think of mathematics: it was a revolution in the 16-17th century
> > when algebra was invented. It might look cryptic at first, but just
> > compare the following two
> >
> > (-b +|- sqrt(b^2-4ac ) )/(2a)
> >
> > with:
> >
>
> > "..."
>
> >
> > Nowadays nobody would argue the a professional book about physics,
> > economics, chemistry, engineering, etc. contains too many formulas.
> > All of them have their own operators, naming conventions etc. and
> > looks abstract gibberish to anyone not familiar with the domain. But
> > that's fine, these books are written for those that
> > *are* familiar and they would not tolerate a verbose salad of words.
>
>
> There is a reverse phenomenon in programming. People write code with
> absolutely minimalistic names but without the supporting prose that
> would be present in a textbook surrounding such a minimalist symbolic
> presentation. That renders code incomprehensible without meticulous,
> expression-by-expression scrutiny of the tersely written code.
>
>
>
> > Actually my sentiment is very close to that of Paul Graham's
> > expressed in http://www.paulgraham.com/noop.html
> > where he argues:
> >
> > "Object-oriented programming generates a lot of what looks like work.
> > Back in the days of fanfold, there was a type of programmer who would
> > only put five or ten lines of code on a page, preceded by twenty
> > lines of elaborately formatted comments. Object-oriented programming
> > is like crack for these people: it lets you incorporate all this
> > scaffolding right into your source code. Something that a Lisp
> > hacker might handle by pushing a symbol onto a list becomes a whole
> > file of classes and methods. So it is a good tool if you want to
> > convince yourself, or someone else, that you are doing a lot of
> > work."
>
>
> That is somewhere between a caricature and an extreme exaggeration.
> Programmers who just want to generate maximum line count to get a given
> job done aren't going to go far in today's world, I don't think. Nor,
> do I think, that given the apparent popularity of "lean" and "agile"
> methods, that this is even the general trend direction in contemporary
> software practice.
>
>
>
> Randall Schulz
>

becomes
  floor(7) isEnteredBy Person("Peter")
  floor(3) isEnteredBy Person("Hanna")

becomes
  Person("Peter")  ->:  floor(7)
  Person("Hanna")  ->:  floor(3)

I always wonder why anyone would want to perform this ultimate step.
It just isn't as readable as the version above it.

I know that people will point at that "in mathematics we deal with symbols like this all the time" and they are completely right of course. I'm not doubting the fact that as humans we are more than capable to use symbols to think about certain problems. I'm even convinced that in certain cases it's much easier, more efficient and just plain better to do so.

I'm just not convinced that you can compare the two situations.

Why? Because mathematics are a pretty fixed field of science, once somebody comes up with a certain notation that everybody likes that's the one that will be used. Yes, depending on the field the same concept might be represented in different ways, but within the field almost anyone will be able to understand what you're writing, no matter if you from India or Australia. You also know they will stay the same for many years to come. And you also know that if you haven't been using them for a couple of years and your memory of them has become a bit hazy you can just pick up any text book on the matter or just Google for it and you'll have your answers right there.

But domain languages almost by definition will be very limited in scope, limited in time, very specific to the problem being solved and almost certainly specific to the persons or organization developing them.

The same people might be working in different projects at the same time and over the years be involved in many more. I just cannot imagine that anyone that doesn't have prodigious memory won't have big problems understanding the above code (I am assuming here that there are more symbols, not just one, and that the concepts are not so basic that even a 5-year old would understand them).

The example that I always run into personally is Perl. Perl is extremely good at some things and you can write certain code very succinctly and in a very short time. Great. The problem I have is that I only need once in a VERY long time. So whenever I finally need it I just can't remember anymore how things worked, even code I wrote myself I can't even READ anymore because I can't remember what all the different symbols do.

So back to the above example, thinking about the poor guy that wasn't on the original project, who in 3 years time has to jump into the code to fix some bugs, I just wouldn't advise code like that.

What do ya'll think?

--

Tako