Fwd: Scala, Scala you got me worried

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

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 personally like a middle ground, use a lambda for one offs, pull out
a named function if you find yourself using it more than three times.

It would be a pretty cool ide feature, like extract constant only
doing full tree manipulation. (Miles if you are reading this, I'm
cool with delivery in 3 or so years :-> )

On Sat, Mar 14, 2009 at 12:20 AM, John Nilsson wrote:
> 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
>>>  >>  >
>>>  >>
>>>  >
>>>
>>
>

On 3/13/09, Chris Twiner wrote:
> I personally like a middle ground, use a lambda for one offs, pull out
> a named function if you find yourself using it more than three times.

BTW my experience with large C++ projects is that people tend to write
the same or very similar utility functions over and over again, since
it is very hard to look them up. For example, I would never thought
the hasAny would have the semantics of finding a nonempty element in a
list, I would have called hasNonempty. Then, someone else would could
called it includesNotEmpty or flatConcHasSome... In a project with
several 100KLOC how should I know what to grep for?

Additionally, if I find something that looks like covering the
functionality I need, there is still
significant chance that the original author has slightly different
assumption, so I will need to
understand the existing code first, before I can use it.

All that hassle just for a simple thing that takes 20 characters to
write in scala?

>
> It would be a pretty cool ide feature, like extract constant only
> doing full tree manipulation. (Miles if you are reading this, I'm
> cool with delivery in 3 or so years :-> )
>
>
> On Sat, Mar 14, 2009 at 12:20 AM, John Nilsson wrote:
> > 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
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >
>

You need to 'grep' on the parameter and return types. See Hoogle.

2009/3/14 Christian Szegedy :
> On 3/13/09, Chris Twiner wrote:
>> I personally like a middle ground, use a lambda for one offs, pull out
>>  a named function if you find yourself using it more than three times.
>
> BTW my experience with large C++ projects is that people tend to write
> the same or very similar utility functions over and over again, since
> it is very hard to look them up. For example, I would never thought
> the hasAny would have the semantics of finding a nonempty element in a
> list, I would have called hasNonempty. Then, someone else would could
> called it includesNotEmpty or flatConcHasSome... In a project with
> several 100KLOC how should I know what to grep for?
>
> Additionally, if I find something that looks like covering the
> functionality I need, there is still
> significant chance that the original author has slightly different
> assumption, so I will need to
> understand the existing code first, before I can use it.
>
> All that hassle just for a simple thing that takes 20 characters to
> write in scala?
>
>>
>>  It would be a pretty cool ide feature, like extract constant only
>>  doing full tree manipulation.  (Miles if you are reading this, I'm
>>  cool with delivery in 3 or so years :-> )
>>
>>
>>  On Sat, Mar 14, 2009 at 12:20 AM, John Nilsson wrote:
>>  > 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
>>  >>>  >>  >
>>  >>>  >>
>>  >>>  >
>>  >>>
>>  >>
>>  >
>>
>

On Sat, Mar 14, 2009 at 3:14 AM, Christian Szegedy
wrote:
> BTW my experience with large C++ projects is that people tend to write
> the same or very similar utility functions over and over again, since
> it is very hard to look them up.

So? I don't see that as a problem. Yes it's desireable to follow DRY
but for components of this type I actually thinks there is something
to be gained from not coupling modules to much to global utilites if
you are not sure that the semantic requirements of the utility is
equally global.

The great thing with Scala is that you can write theese utilities as a
nested function. To reaaly keep them isolated from other code if you
don't intend for the seamtics to be stable.

> In a project with
> several 100KLOC how should I know what to grep for?

It's just an API. If you have a global library with utilites. Why not
keep them there and make sure to have some kind of naming convention?
FYI we manage to do just that in a project with a few hundred KLOC.

But as I wrote above. I don't think DRY is the correct principle in
all instances of small utilities like this. In Java I frequantly put
theese kinds of things in private static methods until I'm sure that
there will be some real value in promoting it to a global API
according to DRY.

> Additionally, if I find something that looks like covering the
> functionality I need, there is still
> significant chance that the original author has slightly different
> assumption, so I will need to
> understand the existing code first, before I can use it.
>
> All that hassle just for a simple thing that takes 20 characters to
> write in scala?

Like I said, either put utilities for MyClass it in your very own
MyClassUtilities trait or isolate it as nested function in the places
you'll need it.

BR,
John

On Saturday March 14 2009, John Nilsson wrote:
> On Sat, Mar 14, 2009 at 3:14 AM, Christian Szegedy
>
> wrote:
> > BTW my experience with large C++ projects is that people tend to
> > write the same or very similar utility functions over and over
> > again, since it is very hard to look them up.
>
> So? I don't see that as a problem. Yes it's desireable to follow DRY
> but for components of this type I actually thinks there is something
> to be gained from not coupling modules to much to global utilites if
> you are not sure that the semantic requirements of the utility is
> equally global.
>
> The great thing with Scala is that you can write theese utilities as
> a nested function. To reaaly keep them isolated from other code if
> you don't intend for the seamtics to be stable.

I'd be more willing to accept this reasoning if the overhead of
functions / blocks / closures in Scala were mitigated. I expect this
will happen, but right now, it's a bit cavalier to shrug off this
overhead in the form of a multiplicity of Java classes needed to
capture all these Scala source-level entities.

> ...
>
> BR,
> John

Randall Schulz

On Sat, Mar 14, 2009 at 3:32 PM, Randall R Schulz wrote:
> it's a bit cavalier to shrug off this
> overhead in the form of a multiplicity of Java classes needed to
> capture all these Scala source-level entities.

Intuitively I kind of agree with you. But at the same time I'm trying
to distrust my intutition of theese matters. I've found that my
intutition is often wrong when you actually measure.

So regarding this issue. Are there measurements available that
illustrates the real costs of this overhead? How is performance
impacted by all objects instantiations involved in Scala? How is
memory requirements affected? What other things are affected?

BR,
John

On Saturday March 14 2009, John Nilsson wrote:
> On Sat, Mar 14, 2009 at 3:32 PM, Randall R Schulz wrote:
> > it's a bit cavalier to shrug off this
> > overhead in the form of a multiplicity of Java classes needed to
> > capture all these Scala source-level entities.
>
> Intuitively I kind of agree with you. But at the same time I'm trying
> to distrust my intutition of theese matters. I've found that my
> intutition is often wrong when you actually measure.

It's true that with nanosecond-scale instruction execution (and now,
multiple parallel execution threads), it's easy to overestimate time
costs, but space is another matter that is, in my experience, harder to
alleviate if you don't exercise forethought. Specifically, time
problems are usually localized to "hot spots" which are readily
identified by profiling and addressed locally. Excessive space
overheads tend to spread themselves all over and are less amenable to
focused ameliorization.

> So regarding this issue. Are there measurements available that
> illustrates the real costs of this overhead? How is performance
> impacted by all objects instantiations involved in Scala? How is
> memory requirements affected? What other things are affected?

I was referred to this:

> BR,
> John

Randall Schulz

On Saturday March 14 2009, John Nilsson wrote:
> On Sat, Mar 14, 2009 at 4:08 PM, Randall R Schulz wrote:
> > I was referred to this:
> >
> > >anonymous-function-td20826275.html>
>
> But what is the actual cost? Bandwidth requirements for jar
> distribution may be an issue if that is something you have to keep
> down. RAM requirements may be an issue in the embedded space.

I thought that message was quite clear about the cost incurred for each
closure or block.

> In my view both those requirements are so specialized that the people
> worrying about that should take measures of their own to manage it,
> not something the general platform should worry about.

What can a user do? We're not in control of how Scala constructs are
rendered into JVM classes and bytecode. Only at the language level can
measures be effected to mitigate this overhead.

Anyway, apparently some think I'm "upset" about this matter. I'm not.
I just think that this is something that needs to be addressed at some
point, whether that means exploiting changes in next-generation JVMs or
a capability of folding repeated class content or other techniques.

Java program start-up times are pretty bad as it is, and this
multiplicity of Java classes only makes that worse.

> BR,
> John

Randall Schulz

On Sat, Mar 14, 2009 at 4:08 PM, Randall R Schulz wrote:
> I was referred to this:
>
>

But what is the actual cost? Bandwidth requirements for jar
distribution may be an issue if that is something you have to keep
down. RAM requirements may be an issue in the embedded space.

In my view both those requirements are so specialized that the people
worrying about that should take measures of their own to manage it,
not something the general platform should worry about.

BR,
John

> The code for frameworks will be more complex in order to
> simplify "consumer" code.

Yes, that's right. (I am framework developer in an
ERP size app project).

But OTOH this distinction is an illusion.
During the time -and especially after meddling with Ruby, Groovy, and
a bit of Scala- I got the notion, that the border between 'framework'
and 'app code' is a mental factor, not a component structure.

Means: even in one more elaborated Java class (say e.g. a Unit test
class)
you can distinguish between more "frameworky" and more "domainy"
parts.

If you start thinking this way, you end with classes which have
some technical private or public methods providing a domain
abstraction level such that the implementation of the domain
oriented methods become more declarative or spec like.

And some time you refactor that methods out into utility classes
or even libraries.
This way some simple helper methods in one code generator test class
eventually became a model builder DSL.

If you are led by the wish-language question ("how should a language
look, which would let me describe my domain here?") this solutions
emerge
naturally.

> If I understand John correctly he's simply stating that one
> perhaps shouldn't forget to give names to things when it
> makes sense to do so.

Well, has NOTHING to do with Scala IMHO.
I have colleagues that write lines and lines of imperative
code in Java, putting in some comments about what the next
bunch of lines does.
They have never got the routine to think in wish-language terms,
so they simply forget, that a comment could easily become a method
name and that the next lines perhaps should better go in such
a method.

The result would be a better abstraction of _what_ is done,
and not _how_.

But if you can teach your colleagues to think in that way,
Scala is a far better tool for this approach.

>On 3/13/09, John Nilsson wrote:
>> What I mean is that in Java you get rid of
>> boilerplate by naming stuff.

That is only true for some kind of boilerplate, the one
I spoke about above ("frameworky").

Other type of boilerplate you do not so easily "get rid of"
in Java but must now be searched for on different places,
where the name is defined.
So if you are engaged in maintaining said code, you are
always confronted with the boilerplate, the naming advantage
is for others.

>> You don't do anonymous functions because its
>> to verbose,

That is wrong. We experienced this in our app with
some filters. We have filter classes that also provide
a good bunch of constant filters as they are used again
and again.
But OTOH there are enough one-time-filters which never
got into this "named" collection but were created
in-place, and that is good so.
A good lambda expression or closure syntax would help.
(BTW: Funny enough in eclipse the lambda4jdt folding
plugin does a nice job).

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

A style question valid for any language ... see above.

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

Well, what is "text" ? Natural language? A clear formula?

In mathematics and with western reading style it is far better
to write:
x = ( 3 * 5 ) + ( 8 / 2 )
than

x =
(
3 * 5
)
+
(
8 / 2
)

But Java often ends in such constructs, and sometimes it involves
even scrolling.

BTW: Scala supports both: Better natural language and
better formula.

So
floor.get(7).enteredBy(person("Peter"))
floor.get(3).enteredBy(person("Hanna"))

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

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

which is a "carefully formatted text" in an expressive
domain language. (Domain: An elevator simulation).

KR
Det

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

I space don apostrophe t space think space that space what space you
space say space is universally space correct full stop space space But
comma space it space is space always space worth space considering
space carefully space how space you space use space symbolic space
identifiers full stop

2009/3/16 Tako Schotanus :
> Warning: Off-topic
>
> On Mon, Mar 16, 2009 at 09:57, Detering Dirk
> wrote:
>>
>> 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
>
>

On Monday March 16 2009, Ricky Clarkson wrote:
> I space don apostrophe t space think space that space what space you
> space say space is universally space correct full stop space space
> But comma space it space is space always space worth space
> considering space carefully space how space you space use space
> symbolic space identifiers full stop

So... Do you likewise ridicule the use of XML?

Of course languages of any sort have to be designed with their users
needs foremost. There's no one-size-fits-all rule for whether
punctuation is superior to names, whether infix is superior to prefix,
whether full parenthesization is superior, etc.

Randall Schulz

Yes, I ridicule the use of XML, though I appreciate that it has a lot
of momentum and tool support, and do use it myself from time to time.

I would rather read: (person (name "Bob") (age 42)) than
"Bob"42, and if I reasonably
have a choice I will plump for the former.

My point amongst all that was that it is not wise to universally ban
symbolic names, but we should exercise care when defining them. I'm
quite glad we don't write 3 plus 4, or list append otherList.
Alphabetic names get in the way of understanding code. Compare
Scala's for-comprehensions and C#'s LINQ:

for { x <- xs; y <- ys; if x != y} yield x * y

from x in xs from y in ys where x != y select x * y

Not a wildly convincing example, but I hope you can see the point from
it. (actually, where is a better keyword name than if, for that use,
imo).

2009/3/16 Randall R Schulz :
> On Monday March 16 2009, Ricky Clarkson wrote:
>> I space don apostrophe t space think space that space what space you
>> space say space is universally space correct full stop space space
>> But comma space it space is space always space worth space
>> considering space carefully space how space you space use space
>> symbolic space identifiers full stop
>
> So... Do you likewise ridicule the use of XML?
>
>
> Of course languages of any sort have to be designed with their users
> needs foremost. There's no one-size-fits-all rule for whether
> punctuation is superior to names, whether infix is superior to prefix,
> whether full parenthesization is superior, etc.
>
>
> Randall Schulz
>

Oops, I obviously misinterpreted what you were getting at hahaha

I was so busy trying to set right what had gone wrong that I didn't
really let your message sink in :)

On Mon, Mar 16, 2009 at 15:01, Randall R Schulz wrote:
> On Monday March 16 2009, Ricky Clarkson wrote:
>> I space don apostrophe t space think space that space what space you
>> space say space is universally space correct full stop space space
>> But comma space it space is space always space worth space
>> considering space carefully space how space you space use space
>> symbolic space identifiers full stop
>
> So... Do you likewise ridicule the use of XML?
>
>
> Of course languages of any sort have to be designed with their users
> needs foremost. There's no one-size-fits-all rule for whether
> punctuation is superior to names, whether infix is superior to prefix,
> whether full parenthesization is superior, etc.
>
>
> Randall Schulz
>

If what you received before was formatted strangely (which I assume is
what you're trying to get at with all the spaces and full stops) it's
probably because by accident I had only sent it to Dirk so I copied
and pasted the text to resend it. Probably something went wrong along
the way (although it looks fine here).

Of course I was not saying that what I said applies universally, in
fact I would limit it to the use of one-off domain languages (that use
lots of symbols) that are only used for one specific project. But the
example given here about an elevator simulation would apply in my
opinion.

Of course it would already be more generally useful if we were talking
about some public project with lots of people working on it worldwide,
but even then it's probably not something you could rely on because
the same project translated to a different language would probably use
a completely different API.

So even knowing the ElevSim Java version, or the Ruby version or
whatever, won't necessarily prepare you for the Scala version, so in
that way it's not directly comparable to the use of symbols in
mathematics.

I do agree that sometimes the use of symbols brings so many advantages
that you just accept the cost that comes with it. The parser stuff
that's included with Scala is probably a good example, but I don't
worry so much about that one because it's "built into" Scala, it's
generally available to everyone and it's defined the same for
everybody who uses Scala. So within those limits it will probably work
fine.

What I refer to has more to do with those in-house projects where
somebody decides that:

Person("Peter") ->: floor(7)

reads better than:

floor(7) isEnteredBy Person("Peter")

but forgets that probably most people that have to read his code
probably aren't domain experts.

Of course, if all you do is make elevator simulators that might very
well be true, but if it's something that you've made for a client 3
years ago things change.

So I'm NOT saying people shouldn't use symbols, but that they think
about it carefully, because like they like to say in the Java-world,
you're code will probably be read dozens, hundreds or even thousands
of times more than it will be written. So the ease with which it can
be picked up by another is often very important.

Just my €0.02 :)

On Mon, Mar 16, 2009 at 14:52, Ricky Clarkson wrote:
>
> I space don apostrophe t space think space that space what space you
> space say space is universally space correct full stop space space But
> comma space it space is space always space worth space considering
> space carefully space how space you space use space symbolic space
> identifiers full stop
>
> 2009/3/16 Tako Schotanus :
> > Warning: Off-topic
> >
> > On Mon, Mar 16, 2009 at 09:57, Detering Dirk
> > wrote:
> >>
> >> 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
> >
> >

--

-Tako

Hello all,

I already answered Tako's mail but as the discussion
started privately by accident, my answer did not go
into the list.
I now repost it here. (Sorry for being late, Tako).

KR
Det

> -----Original Message-----
> From: Detering Dirk
> Sent: Monday, March 16, 2009 1:18 PM
> To: 'Tako Schotanus'
> Subject: RE: [scala-user] Scala, Scala you got me worried
>
> Hello Tako,
>
> I understand your concern, especially as I once wrote some
> perl scripts myself and was eager to replace that by Python
> and then Ruby for exactly that reason (although both are not
> free from specific symbolic terms).
>
> I know the effect you are talking about by my own experience
> to grok the expression patterns of Scala's parser combinators.
> But after you once get it, I assume it to be very reasonable,
> like with entering a new topic in arithmetic lessons.
>
> But there is an "other hand" ;-) .
>
> > 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.
>
> This is not fully true.
>
> 1.) It seems less readable to you, as you look at
> the code examples from outside the context.
>
> 2.) The latter expression is better, as the first reflexive expression
> is textually correct, but the latter expresses the intention much
> better: Person is the subject, not floor.
> Unfortunately it is much easier in Scala to write a right
> associated symbolic function than a named method.
>
> So the correct textual term would be:
> Person("Peter") enters floor(7) .
>
> But this would involve to make 'enters' a method of Person,
> thus inverting the dependency relationship of Person and Floor,
> which is not wanted from domain model view.
> Or making 'Person' a function which returns an intermediate object
> knowing the Person object and declaring the method 'enters'.
>
> This would be a technical object, and would lead to more
> effort to create the DSL, which is simply not necessary.
> (Beside that Person() now could only be used in context where
> this intermediate object makes sense).
>
>
> 3.) The latter version IS indeed at least likewise readable
> for the ones involved in the context ("domain experts"), as
> that is in ascii-form the way one describes the domain on a
> whiteboard :
> Person named "Peter", an arrow drawn to Floor number seven.
>
> So the "perl-effekt" is no matter here.
>
> > 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.
>
> Yes, I know and use that argument too, but not limited to
> mathematics as it is valid also to chemistry (H2O), music
> (G°,c#-, Ab7+/9, ♪♫ ), economy ($£¢¥(c)(R)%§) electricians and
> laundries, car drivers, and even software people
> ( ..\ , http:// , "[a-zA-Z].*").
>
> > But domain languages almost by definition will be very
> > limited in scope,
>
> Yes. The domain. Or what do you mean with scope?
>
> > limited in time,
>
> No. Limit in time is in no way a definition of DSL.
> How should that be?
>
> >very specific to the problem being solved
>
> That is the reason for their existence, yes.
>
> > and almost certainly specific to the
> > persons or organization developing them.
>
> This *may* be true and is ok, if it becomes a tool
> for communication and reasoning about the domain within
> this group.
>
> This *may* not be true, as the DSL can be part of
> a commonly known domain an can become widely used in it.
> E.g. PostScript: a printer configuration language,
> a web content markup language known as html, and well, regex.
>
> > 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).
>
> Currently there are indeed not much more symbols, and I think
> it is indeed important that the symbolic use contains some
> "common sense". So I cannot see the difficulty in understanding
> the right arrow between a person and a floor in a building simulation.
> The context simply determines the meaning.
>
> This would be other, if the same relationship had been expressed like
> this:
> Person("Peter") $_: floor(7)
>
> This would much more imply "Peter misses some dollars on
> floor 7" ;-) .
>
>
> And if the domain concepts are not so basic as 'enters', it
> may be likewise
> difficult for someone who is only for short time in the
> domain space, to grep
> the textually written method's meaning after a while.
> Even the words have special meaning in special domains, and
> here in my company
> alone we detect evolution of specific languages in different
> departments.
> They need that for clear but terse internal communication.
> Even acronyms like PL and AL mean other things on management
> level than on
> framework-dev level.
> The difference is the context: a management schedule or a
> feature table.
>
> BTW: If you do not work with Regex on a day by day basis, you may have
> to lookup things again if you have to write/maintain code
> involving regexes.
> That does not mean that it makes things simpler for the ones
> daily working
> with it if you replace Regex-language with textual constructs.
>
> > 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?
>
> I think he will grok it right from context :-) .
>
> DSLs, as I understand them, are not so temporary or localised that
> they hang around somewhere in the code, almost forgotten, until
> maintenance time, when the developer involved has something like
> an archaeolocigal task.
>
> DSLs are an instrument to find clear formal expressions for
> the problem domain and its solutions, and serve the people
> working within this domain to clearly express themselves.
>
> KR
> Det

No problem, Dirk (Det?)

the examples you gave for chemistry and economy and such are all
completely valid of course, but like I said in an another message they
are all very long-lived international definitions known by almost
everyone, it takes time to learn them (sometimes a long time) but it
is all worth it in the end.

And I think it's this "worth" that you have to take into account.
Maybe I'm just looking at it from a very restrictive point of view:
the one where the domain language is created for a specific project
and has no meaning outside it. If somebody new comes along they will
have to learn it. If that same person works on 5 other projects all
with their own symbols it might start to get complicated.

Remember what I said about the "worth", it's worthwhile to learn the
language of chemistry when you are a chemist or when you'll be working
a lot with them, but to learn a new one for each IT project you're
going to work on would be a bit too much.

So that's why I said before that I can grok the parser DSL, it's part
of Scala so can can be expected to know (about) it. In some other
cases the symbols might make such a big difference that it really IS
worth the trouble of learning them, or they might be so simple that
you'd be dense not to understand hem.

And of course you'd expect to deal with more or less knowledgable
people here, but as one who had to dive into other people's code often
enough (especially when they're not around to help you anymore) I'd
rather wish they'd think more about others when they write their code.
Very often code that seems completely obvious to you now is very hard
to understand for another (or even yourself 2 years down the road).

The regular expression you mention is a great example, this is what I
wrote 3 years ago:

http://www.palacio-cristal.com/blogs/java/index.jsp?article=2006/11/19.xml

and a couple of hours later:

http://www.palacio-cristal.com/blogs/java/index.jsp?article=2006/11/19b.xml

Regular expressions are great but they result in completely unreadable
gibberish most of the time. I'd rather use something more structured
and more readable even though the end result is 10 times as long. Of
course if there was a way somebody would probably have found it
already :)

On Mon, Mar 16, 2009 at 16:48, Detering Dirk wrote:
> Hello all,
>
> I already answered Tako's mail but as the discussion
> started privately by accident, my answer did not go
> into the list.
> I now repost it here. (Sorry for being late, Tako).
>
> KR
> Det
>
>> -----Original Message-----
>> From: Detering Dirk
>> Sent: Monday, March 16, 2009 1:18 PM
>> To: 'Tako Schotanus'
>> Subject: RE: [scala-user] Scala, Scala you got me worried
>>
>> Hello Tako,
>>
>> I understand your concern, especially as I once wrote some
>> perl scripts myself and was eager to replace that by Python
>> and then Ruby for exactly that reason (although both are not
>> free from specific symbolic terms).
>>
>> I know the effect you are talking about by my own experience
>> to grok the expression patterns of Scala's parser combinators.
>> But after you once get it, I assume it to be very reasonable,
>> like with entering a new topic in arithmetic lessons.
>>
>> But there is an "other hand" ;-) .
>>
>> >     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.
>>
>> This is not fully true.
>>
>> 1.) It seems less readable to you, as you look at
>> the code examples from outside the context.
>>
>> 2.) The latter expression is better, as the first reflexive expression
>> is textually correct, but the latter expresses the intention much
>> better:  Person is the subject, not floor.
>> Unfortunately it is much easier in Scala to write a right
>> associated symbolic function than a named method.
>>
>> So the correct textual term would be:
>>    Person("Peter") enters floor(7) .
>>
>> But this would involve to make 'enters' a method of Person,
>> thus inverting the dependency relationship of Person and Floor,
>> which is not wanted from domain model view.
>> Or making 'Person' a function which returns an intermediate object
>> knowing the Person object and declaring the method 'enters'.
>>
>> This would be a technical object, and would lead to more
>> effort to create the DSL, which is simply not necessary.
>> (Beside that Person() now could only be used in context where
>> this intermediate object makes sense).
>>
>>
>> 3.) The latter version IS indeed at least likewise readable
>> for the ones involved in the context ("domain experts"), as
>> that is in ascii-form the way one describes the domain on a
>> whiteboard :
>> Person named "Peter",   an arrow drawn to  Floor number seven.
>>
>> So the "perl-effekt" is no matter here.
>>
>> > 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.
>>
>> Yes, I know and use that argument too, but not limited to
>> mathematics as it is valid also to  chemistry (H2O), music
>> (G°,c#-, Ab7+/9, ♪♫ ), economy ($£¢¥(c)(R)%§)  electricians and
>> laundries, car drivers, and even software people
>> ( ..\ , http:// , "[a-zA-Z].*").
>>
>> > But domain languages almost by definition will be very
>> > limited in scope,
>>
>> Yes. The domain. Or what do you mean with scope?
>>
>> > limited in time,
>>
>> No. Limit in time is in no way a definition of DSL.
>> How should that be?
>>
>> >very specific to the  problem being solved
>>
>> That is the reason for their existence, yes.
>>
>> > and almost certainly specific to the
>> > persons or organization developing them.
>>
>> This *may* be true and is ok, if it becomes a tool
>> for communication and reasoning about the domain within
>> this group.
>>
>> This *may* not be true, as the DSL can be part of
>> a commonly known domain an can become widely used in it.
>> E.g. PostScript: a printer configuration language,
>> a web content markup language known as html, and well, regex.
>>
>> > 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).
>>
>> Currently there are indeed not much more symbols, and I think
>> it is indeed important that the symbolic use contains some
>> "common sense".  So I cannot see the difficulty in understanding
>> the right arrow between a person and a floor in a building simulation.
>> The context simply determines the meaning.
>>
>> This would be other, if the same relationship had been expressed like
>> this:
>>        Person("Peter") $_: floor(7)
>>
>> This would much more imply "Peter misses some dollars on
>> floor 7" ;-) .
>>
>>
>> And if the domain concepts are not so basic as 'enters', it
>> may be likewise
>> difficult for someone who is only for short time in the
>> domain space, to grep
>> the textually written method's meaning after a while.
>> Even the words have special meaning in special domains, and
>> here in my company
>> alone we detect evolution of specific languages in different
>> departments.
>> They need that for clear but terse internal communication.
>> Even acronyms like PL and AL mean other things on management
>> level than on
>> framework-dev level.
>> The difference is the context:  a management schedule or  a
>> feature table.
>>
>> BTW: If you do not work with Regex on a day by day basis, you may have
>> to lookup things again if you have to write/maintain code
>> involving regexes.
>> That does not mean that it makes things simpler for the ones
>> daily working
>> with it if you replace Regex-language with textual constructs.
>>
>> > 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?
>>
>> I think he will grok it right from context :-) .
>>
>> DSLs, as I understand them, are not so temporary or localised that
>> they hang around somewhere in the code, almost forgotten, until
>> maintenance time, when the developer involved has something like
>> an archaeolocigal task.
>>
>> DSLs are an instrument to find clear formal expressions for
>> the problem domain and its solutions, and serve the people
>> working within this domain to clearly express themselves.
>>
>> KR
>> Det
>
> --
> ***********************************************************************
>
> Die Information in dieser E-Mail ist vertraulich und ist ausschliesslich
> fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
> E-Mail durch andere Personen als den/die benannten Adressaten ist
> nicht gestattet. Sollten Sie nicht der benannte Adressat sein, loeschen
> Sie bitte diese E-Mail.
>
> ***********************************************************************
>
>
> BITMARCK SOFTWARE GMBH
> Paul-Klinger-Strasse 15, 45127 Essen
>
> Amtsgericht Essen HRB 20680
> Geschaeftsfuehrer: Frank Krause, Andreas Prenneis
>

I am a mathematician an my experience with math literature are a bit
different. Almost every paper starts with an introduction explaining
the notation. It typically consist both of widely known symbolics and
also some (or a lot of) very special notation used only by the author
or a very small circle.

OTOH, if you could explain me how do you google for mathematical
notation, I'd be really grateful. ;)

On 3/16/09, Tako Schotanus wrote:
>
> 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.
>
>

Detering Dirk schrieb:
>> But this would involve to make 'enters' a method of Person,
>> Or making 'Person' a function which returns an intermediate object

Or big bad evil magic:

implicit def person2FloorEnterer(p: Person) = {
new {
def enters(f: Floor) = f isEnteredBy p
}
}

Now you can do something like:

scala> Person("Peter") enters Floor(2)
Peter entered floor 2

scala> <

Of course, implicits, maintainability, bla...

- Florian