Fwd: Scala, Scala you got me worried

OK, clearly a troll ...

I suggest refraining from further feeding ...

Cheers,

Miles

It's not very polite to forward private messages to a public list.



On Fri, Mar 13, 2009 at 12:04, sss fredo <sssfredo@gmail.com> wrote:

---------- Forwarded message ----------
From: sss fredo <sssfredo@gmail.com>
Date: Fri, Mar 13, 2009 at 10:03 PM
Subject: Re: [scala-user] Scala, Scala you got me worried
To: Ricky Clarkson <ricky.clarkson@gmail.com>


 Ricky, my point are mainly general but I mentioned code from a specific coder twice. Frankly, you and some other forum members defend your precious language like its some sort of religion with Martin as a demi God - its pretty sickening when you act like that!
On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then complain about it in private, or find some equivalent code.
Can't be hard, if we all suck.

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Sorry, Ricky it not accessible by the public and not my code to post.
>
> On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Can you point at the code that you find difficult to understand?
>> Perhaps one of us can help.
>>
>> 2009/3/13 sss fredo <sssfredo@gmail.com>:
>> > Scala, I know you quite well now but our relationship is on the rocks.
>> > Scala doesn't give enough guidance to the programmer on whether to adopt
>> > a
>> > functional or object orientated programming style. I know choice is
>> > sometimes good - but its not for many programmers - they need guidance
>> > not a
>> > plethora of arbitrary options.
>> > Scala is a write once, then throw away and re-write for the next person.
>> > Yup, Im looking at a senior Scala expert's code right now and its not
>> > pretty
>> > or understandable, nor am I a Scala beginner.
>> > Scala implicits are a failed experiment. I like to know whats going on
>> > in a
>> > program. With implicits, I have no idea until I guess and track down the
>> > implicit. I think languages that optionally drop strong typing
>> > (Objective C,
>> > Groovy) are more honest, in that the don't purport to achieve strong
>> > typing
>> > when there is none.
>> > Scala imports of methods using import x.ClassName._ means I have to rely
>> > on
>> > yet unwritten IDE support to know where a method came from.
>> > Scala and its forum are confused as to whether a language should be
>> > quick to
>> > write, terse, verbose or easy to read. Yup you know what I'm talking
>> > about,
>> > things like using "_" or "/:" or how about leaving off the return type
>> > on a
>> > complex function.
>> > Scala functional programming is not as good as Haskell. I know only a
>> > little
>> > Haskell, but when I read it, it makes sense. When Scala is written in a
>> > functional style it looks more verbose and much less readable.
>> > Scala functional programming is spaghetti code. Im reading a senior,
>> > well
>> > known, Scala functional programmer's code and it reminds me of the worst
>> > rubbish I saw from procedural programming 10-20 years ago. Do all
>> > functional
>> > programmers have a need to stuff as much logic in two lines as possible.
>> > Who
>> > said vertical space is bad?
>> > Scala forum members have very big heads. I am sick of hearing how much
>> > above
>> > Java life Scala life is - I've waited and waited but you guys still
>> > haven't
>> > produced enough to back this assertion up.
>
>

--

-Tako

Actually you can make an exception for me. I always intend to make
the message public, unless I change the subject of the mail. I just
hit the wrong button this time.

sss fredo,

Are you related to Jon Harrop? You could learn a few things from him.

2009/3/13 Tako Schotanus :
> It's not very polite to forward private messages to a public list.
>
>
>
> On Fri, Mar 13, 2009 at 12:04, sss fredo wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: sss fredo
>> Date: Fri, Mar 13, 2009 at 10:03 PM
>> Subject: Re: [scala-user] Scala, Scala you got me worried
>> To: Ricky Clarkson
>>
>>
>>  Ricky, my point are mainly general but I mentioned code from a specific
>> coder twice. Frankly, you and some other forum members defend your precious
>> language like its some sort of religion with Martin as a demi God - its
>> pretty sickening when you act like that!
>> On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson
>> wrote:
>>>
>>> Then complain about it in private, or find some equivalent code.
>>> Can't be hard, if we all suck.
>>>
>>> 2009/3/13 sss fredo :
>>> > Sorry, Ricky it not accessible by the public and not my code to post.
>>> >
>>> > On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson
>>> >
>>> > wrote:
>>> >>
>>> >> Can you point at the code that you find difficult to understand?
>>> >> Perhaps one of us can help.
>>> >>
>>> >> 2009/3/13 sss fredo :
>>> >> > Scala, I know you quite well now but our relationship is on the
>>> >> > rocks.
>>> >> > Scala doesn't give enough guidance to the programmer on whether to
>>> >> > adopt
>>> >> > a
>>> >> > functional or object orientated programming style. I know choice is
>>> >> > sometimes good - but its not for many programmers - they need
>>> >> > guidance
>>> >> > not a
>>> >> > plethora of arbitrary options.
>>> >> > Scala is a write once, then throw away and re-write for the next
>>> >> > person.
>>> >> > Yup, Im looking at a senior Scala expert's code right now and its
>>> >> > not
>>> >> > pretty
>>> >> > or understandable, nor am I a Scala beginner.
>>> >> > Scala implicits are a failed experiment. I like to know whats going
>>> >> > on
>>> >> > in a
>>> >> > program. With implicits, I have no idea until I guess and track down
>>> >> > the
>>> >> > implicit. I think languages that optionally drop strong typing
>>> >> > (Objective C,
>>> >> > Groovy) are more honest, in that the don't purport to achieve strong
>>> >> > typing
>>> >> > when there is none.
>>> >> > Scala imports of methods using import x.ClassName._ means I have to
>>> >> > rely
>>> >> > on
>>> >> > yet unwritten IDE support to know where a method came from.
>>> >> > Scala and its forum are confused as to whether a language should be
>>> >> > quick to
>>> >> > write, terse, verbose or easy to read. Yup you know what I'm talking
>>> >> > about,
>>> >> > things like using "_" or "/:" or how about leaving off the return
>>> >> > type
>>> >> > on a
>>> >> > complex function.
>>> >> > Scala functional programming is not as good as Haskell. I know only
>>> >> > a
>>> >> > little
>>> >> > Haskell, but when I read it, it makes sense. When Scala is written
>>> >> > in a
>>> >> > functional style it looks more verbose and much less readable.
>>> >> > Scala functional programming is spaghetti code. Im reading a senior,
>>> >> > well
>>> >> > known, Scala functional programmer's code and it reminds me of the
>>> >> > worst
>>> >> > rubbish I saw from procedural programming 10-20 years ago. Do all
>>> >> > functional
>>> >> > programmers have a need to stuff as much logic in two lines as
>>> >> > possible.
>>> >> > Who
>>> >> > said vertical space is bad?
>>> >> > Scala forum members have very big heads. I am sick of hearing how
>>> >> > much
>>> >> > above
>>> >> > Java life Scala life is - I've waited and waited but you guys still
>>> >> > haven't
>>> >> > produced enough to back this assertion up.
>>> >
>>> >
>>
>>
>
>
>
> --
>
> -Tako
>

I do not accept personal messages from this formum

On Fri, Mar 13, 2009 at 10:10 PM, Tako Schotanus <scala@codejive.org> wrote:

It's not very polite to forward private messages to a public list.



On Fri, Mar 13, 2009 at 12:04, sss fredo <sssfredo@gmail.com> wrote:

---------- Forwarded message ----------
From: sss fredo <sssfredo@gmail.com>
Date: Fri, Mar 13, 2009 at 10:03 PM
Subject: Re: [scala-user] Scala, Scala you got me worried
To: Ricky Clarkson <ricky.clarkson@gmail.com>


 Ricky, my point are mainly general but I mentioned code from a specific coder twice. Frankly, you and some other forum members defend your precious language like its some sort of religion with Martin as a demi God - its pretty sickening when you act like that!
On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then complain about it in private, or find some equivalent code.
Can't be hard, if we all suck.

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Sorry, Ricky it not accessible by the public and not my code to post.
>
> On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Can you point at the code that you find difficult to understand?
>> Perhaps one of us can help.
>>
>> 2009/3/13 sss fredo <sssfredo@gmail.com>:
>> > Scala, I know you quite well now but our relationship is on the rocks.
>> > Scala doesn't give enough guidance to the programmer on whether to adopt
>> > a
>> > functional or object orientated programming style. I know choice is
>> > sometimes good - but its not for many programmers - they need guidance
>> > not a
>> > plethora of arbitrary options.
>> > Scala is a write once, then throw away and re-write for the next person.
>> > Yup, Im looking at a senior Scala expert's code right now and its not
>> > pretty
>> > or understandable, nor am I a Scala beginner.
>> > Scala implicits are a failed experiment. I like to know whats going on
>> > in a
>> > program. With implicits, I have no idea until I guess and track down the
>> > implicit. I think languages that optionally drop strong typing
>> > (Objective C,
>> > Groovy) are more honest, in that the don't purport to achieve strong
>> > typing
>> > when there is none.
>> > Scala imports of methods using import x.ClassName._ means I have to rely
>> > on
>> > yet unwritten IDE support to know where a method came from.
>> > Scala and its forum are confused as to whether a language should be
>> > quick to
>> > write, terse, verbose or easy to read. Yup you know what I'm talking
>> > about,
>> > things like using "_" or "/:" or how about leaving off the return type
>> > on a
>> > complex function.
>> > Scala functional programming is not as good as Haskell. I know only a
>> > little
>> > Haskell, but when I read it, it makes sense. When Scala is written in a
>> > functional style it looks more verbose and much less readable.
>> > Scala functional programming is spaghetti code. Im reading a senior,
>> > well
>> > known, Scala functional programmer's code and it reminds me of the worst
>> > rubbish I saw from procedural programming 10-20 years ago. Do all
>> > functional
>> > programmers have a need to stuff as much logic in two lines as possible.
>> > Who
>> > said vertical space is bad?
>> > Scala forum members have very big heads. I am sick of hearing how much
>> > above
>> > Java life Scala life is - I've waited and waited but you guys still
>> > haven't
>> > produced enough to back this assertion up.
>
>

--

-Tako

No, I'm related to the same monkey as you are.
You got upset because I won't post an example but my example is a whole application with 1000's of line of code. If I cut bits of code, I would lose the mess of the whole application.

On Fri, Mar 13, 2009 at 10:22 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Actually you can make an exception for me.  I always intend to make
the message public, unless I change the subject of the mail.  I just
hit the wrong button this time.

sss fredo,

Are you related to Jon Harrop?  You could learn a few things from him.

2009/3/13 Tako Schotanus <scala@codejive.org>:
> It's not very polite to forward private messages to a public list.
>

On Fri, Mar 13, 2009 at 8:08 AM, Miles Sabin <miles@milessabin.com> wrote:

OK, clearly a troll ...

While I agree on the trolling charges, I think there are some interesting points in the mail.


One thing I find challenging in Scala is that you have a lot of options on how to do something. Specially when you are learning this can be a problem. With 10 different ways to implement the same thing I some times have to wonder what is the best option. You can go for both the OO Design Patterns and the FP design patterns. I think these options are great, I feel personally more productives, and my refactoring tend to clean the code, make it more consice and IMHO readable.

However, I have got stuck several times thinking what would be the best way? How will I scale better? Will the highly functional part look in one year? How do I document it? Guidelines is this sense would be great. I have to say the "Programming in Scala" is a great help for people that are in these tight spots.

My first look a Lift had me both amazed and overwhelmed. It is so compact that until you have played with it a little everything looks magical. I'm sure in this case more experience will help a lot.

Don't want to rise the flames, just point out some opinions.

Thomas

Miles Sabin wrote:
> OK, clearly a troll ...
>
> I suggest refraining from further feeding ...
>
>

not taking sides, i think it would be more useful for the general
audience to have the *complaints* and not the *complainer* addressed.
if he's wrong, show why. people like me, with little experience but
large interest in scala, won't learn much from 'ok, clearly a troll',
and the chances are even lower if negative opinions are simply ignored.

it's understandable that offensive critique is not warmly welcome, but
focusing on the critique part and not the offensive part may help avoid
a war and have a constructive discussion instead.

cheers,
vQ

On Fri, Mar 13, 2009 at 11:43 AM, Wacek Kusnierczyk
wrote:
> not taking sides, i think it would be more useful for the general
> audience to have the *complaints* and not the *complainer* addressed.

That would be the case if the complaints were presented in a way
conducive to constructive debate. But they're not: the guy is clearly
pissed off with a co-worker and wants to vent. This isn't helpful
either to him or to the Scala community.

If you want to try and tease out issues and discuss them, then please
do. But please start those discussions in a fresh thread where they
can be kept clear of the flamage.

Cheers,

Miles

That's okay, you've convinced me.

On Fri, Mar 13, 2009 at 12:17 PM, sss fredo <sssfredo@gmail.com> wrote:

I do not accept personal messages from this formum

On Fri, Mar 13, 2009 at 10:10 PM, Tako Schotanus <scala@codejive.org> wrote:

It's not very polite to forward private messages to a public list.



On Fri, Mar 13, 2009 at 12:04, sss fredo <sssfredo@gmail.com> wrote:

---------- Forwarded message ----------
From: sss fredo <sssfredo@gmail.com>
Date: Fri, Mar 13, 2009 at 10:03 PM
Subject: Re: [scala-user] Scala, Scala you got me worried
To: Ricky Clarkson <ricky.clarkson@gmail.com>


 Ricky, my point are mainly general but I mentioned code from a specific coder twice. Frankly, you and some other forum members defend your precious language like its some sort of religion with Martin as a demi God - its pretty sickening when you act like that!
On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then complain about it in private, or find some equivalent code.
Can't be hard, if we all suck.

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Sorry, Ricky it not accessible by the public and not my code to post.
>
> On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Can you point at the code that you find difficult to understand?
>> Perhaps one of us can help.
>>
>> 2009/3/13 sss fredo <sssfredo@gmail.com>:
>> > Scala, I know you quite well now but our relationship is on the rocks.
>> > Scala doesn't give enough guidance to the programmer on whether to adopt
>> > a
>> > functional or object orientated programming style. I know choice is
>> > sometimes good - but its not for many programmers - they need guidance
>> > not a
>> > plethora of arbitrary options.
>> > Scala is a write once, then throw away and re-write for the next person.
>> > Yup, Im looking at a senior Scala expert's code right now and its not
>> > pretty
>> > or understandable, nor am I a Scala beginner.
>> > Scala implicits are a failed experiment. I like to know whats going on
>> > in a
>> > program. With implicits, I have no idea until I guess and track down the
>> > implicit. I think languages that optionally drop strong typing
>> > (Objective C,
>> > Groovy) are more honest, in that the don't purport to achieve strong
>> > typing
>> > when there is none.
>> > Scala imports of methods using import x.ClassName._ means I have to rely
>> > on
>> > yet unwritten IDE support to know where a method came from.
>> > Scala and its forum are confused as to whether a language should be
>> > quick to
>> > write, terse, verbose or easy to read. Yup you know what I'm talking
>> > about,
>> > things like using "_" or "/:" or how about leaving off the return type
>> > on a
>> > complex function.
>> > Scala functional programming is not as good as Haskell. I know only a
>> > little
>> > Haskell, but when I read it, it makes sense. When Scala is written in a
>> > functional style it looks more verbose and much less readable.
>> > Scala functional programming is spaghetti code. Im reading a senior,
>> > well
>> > known, Scala functional programmer's code and it reminds me of the worst
>> > rubbish I saw from procedural programming 10-20 years ago. Do all
>> > functional
>> > programmers have a need to stuff as much logic in two lines as possible.
>> > Who
>> > said vertical space is bad?
>> > Scala forum members have very big heads. I am sick of hearing how much
>> > above
>> > Java life Scala life is - I've waited and waited but you guys still
>> > haven't
>> > produced enough to back this assertion up.
>
>

--

-Tako

--
Viktor Klang
Senior Systems Analyst

On Fri, Mar 13, 2009 at 11:04 AM, sss fredo <sssfredo@gmail.com> wrote:

---------- Forwarded message ----------
From: sss fredo <sssfredo@gmail.com>
Date: Fri, Mar 13, 2009 at 10:03 PM
Subject: Re: [scala-user] Scala, Scala you got me worried
To: Ricky Clarkson <ricky.clarkson@gmail.com>


 Ricky, my point are mainly general but I mentioned code from a specific coder twice. Frankly, you and some other forum members defend your precious language like its some sort of religion with Martin as a demi God - its pretty sickening when you act like that!

This comment is way out of bounds.  Making a personal attach on Martin and/or people who have a healthy respect for Martin does not belong on any of the Scala community mailing lists.  If you find it sickening, please find someplace else to spend your time.
While your original post raises some interesting points and I will respond to them later (and I will agree with some of them and disagree with others), I will state categorically that Martin listens to feedback.  He has been the driving vision behind Scala, but his vision is influenced strongly by the feedback that he receives about the language from people in this community, including newbies.  The folks on the list, me included, who will ultimately say, "you know, I don't quite get what Martin's going for, but I'll buy in anyway" do that precisely because Martin listens, Martin is very often right, and Martin admits when he isn't.  This is not god-like or worship on our part, it is the healthy respect for an extremely accomplished person who has over and over again demonstrated an understanding of academic rigor and real world needs.  

On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then complain about it in private, or find some equivalent code.
Can't be hard, if we all suck.

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Sorry, Ricky it not accessible by the public and not my code to post.
>
> On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Can you point at the code that you find difficult to understand?
>> Perhaps one of us can help.
>>
>> 2009/3/13 sss fredo <sssfredo@gmail.com>:
>> > Scala, I know you quite well now but our relationship is on the rocks.
>> > Scala doesn't give enough guidance to the programmer on whether to adopt
>> > a
>> > functional or object orientated programming style. I know choice is
>> > sometimes good - but its not for many programmers - they need guidance
>> > not a
>> > plethora of arbitrary options.
>> > Scala is a write once, then throw away and re-write for the next person.
>> > Yup, Im looking at a senior Scala expert's code right now and its not
>> > pretty
>> > or understandable, nor am I a Scala beginner.
>> > Scala implicits are a failed experiment. I like to know whats going on
>> > in a
>> > program. With implicits, I have no idea until I guess and track down the
>> > implicit. I think languages that optionally drop strong typing
>> > (Objective C,
>> > Groovy) are more honest, in that the don't purport to achieve strong
>> > typing
>> > when there is none.
>> > Scala imports of methods using import x.ClassName._ means I have to rely
>> > on
>> > yet unwritten IDE support to know where a method came from.
>> > Scala and its forum are confused as to whether a language should be
>> > quick to
>> > write, terse, verbose or easy to read. Yup you know what I'm talking
>> > about,
>> > things like using "_" or "/:" or how about leaving off the return type
>> > on a
>> > complex function.
>> > Scala functional programming is not as good as Haskell. I know only a
>> > little
>> > Haskell, but when I read it, it makes sense. When Scala is written in a
>> > functional style it looks more verbose and much less readable.
>> > Scala functional programming is spaghetti code. Im reading a senior,
>> > well
>> > known, Scala functional programmer's code and it reminds me of the worst
>> > rubbish I saw from procedural programming 10-20 years ago. Do all
>> > functional
>> > programmers have a need to stuff as much logic in two lines as possible.
>> > Who
>> > said vertical space is bad?
>> > Scala forum members have very big heads. I am sick of hearing how much
>> > above
>> > Java life Scala life is - I've waited and waited but you guys still
>> > haven't
>> > produced enough to back this assertion up.
>
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

"If I cut bits of code, I would lose the mess of the whole application."

Are you sure it's language-related? Either you can show snippits that show what is wrong with the language, asking us to extrapolate an obvious minor problem shown in 3 lines to 1000s of lines of code because if you need 1000s of lines of code to show the problem I would be inclined to say it's a problem of bad design on part of the coder.

I do agree that things like "_" or "/:" can make code pretty hard to read or even understand. Personally I would advise against the use of "symbolic language" like that except in very specific and obvious situations, but obviously many disagree.


On Fri, Mar 13, 2009 at 12:34, sss fredo <sssfredo@gmail.com> wrote:

No, I'm related to the same monkey as you are.
You got upset because I won't post an example but my example is a whole application with 1000's of line of code. If I cut bits of code, I would lose the mess of the whole application.

On Fri, Mar 13, 2009 at 10:22 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Actually you can make an exception for me.  I always intend to make
the message public, unless I change the subject of the mail.  I just
hit the wrong button this time.

sss fredo,

Are you related to Jon Harrop?  You could learn a few things from him.

2009/3/13 Tako Schotanus <scala@codejive.org>:
> It's not very polite to forward private messages to a public list.
>

--

-Tako

>>>>> "sss" == sss fredo writes:

sss> No, I'm related to the same monkey as you are. You got upset
sss> because I won't post an example but my example is a whole
sss> application with 1000's of line of code. If I cut bits of code, I
sss> would lose the mess of the whole application.

Someone wrote thousands of lines of messy code in language X? Yeah,
it's the first time *that* ever happened. Give me a break...

I agree with many of your criticisms if they are reinterpreted simply as
cautions, rather than as mistakes in the language design. So: don't
overuse implicits; don't overuse wildcard imports; declare return types
for functions of more than 1 or 2 lines; and so on. Be conscious of
which parts of the language are there primarily for library designers
and which parts make sense to use liberally in ordinary code.

As for the mix of FP and OO styles, well, it's only because Scala
permits this that I am free to use it at all on my project. I imagine
other Scala users are in the same boat. If are free to write pure FP
code on your project(s), in Haskell or whatever, then more power to you.

> Miles Sabin wrote:
> > OK, clearly a troll ...
> >
> > I suggest refraining from further feeding ...
> >
> >
>
> not taking sides, i think it would be more useful for the general
> audience to have the *complaints* and not the *complainer* addressed.
> if he's wrong, show why. people like me, with little experience but
> large interest in scala, won't learn much from 'ok, clearly a troll',
> and the chances are even lower if negative opinions are
> simply ignored.

+1 !

> it's understandable that offensive critique is not warmly welcome, but
> focusing on the critique part and not the offensive part may
> help avoid a war and have a constructive discussion instead.

Right.
Often I found people claiming that some statements are not
"good communication" due to some aggressive or slightly offensive
sounds, so they rejected from the "bad communcator".

Well, being human involves emotions, sometimes as reactions to
some sort of frustrations, and we cannot expect from all others
that they always "do it the right way" (which is sometimes in the
eye of the beholder anyway) for us. Aggression and offence (often
only taken as such by the *listener* btw) may be a revelation of
a bad experience.

So it is indeed a sign of "good communication" if one is able to
actively listen, sort things out and bring a thread with a bad start
to solid ground again. (In some areas known as de-escalation).

Such is social life ...

More to the content than the voice:

Scala is a very young language, sounds quite interesting to me as
an enterprise Java developer and so I am eager to hear things of
the meta-level to ponder a bit about the future this new influence
may bring to us. What are the different experiences? What are the
different approaches? How does it help, how hinder ?
I see Scala currently in a kind of pilot phase, taken by early adopters,
and I like to hear the field success stories, but even the critics
(may they be factual or a self-expression of frustration).

How shall we use it? What shall we better try to avoid?
This is the best way to approach to new experiences IMO.

KR
Det

PS: Scala, although I haven't done any more than some simple scripts,
has already changed the way I look at my Java programs. And that alone
was it worth. Now I'm longing to see the time when that or a similar
language
bounces into our development projects.

On that point, is there a reason why this list doesn't reply to the list
by default? I don't mind particularly, I just thought it a bit odd...

Kieron

> -----Original Message-----
> From: Ricky Clarkson [mailto:ricky.clarkson@gmail.com]
> Sent: 13 March 2009 11:22
> To: Tako Schotanus
> Cc: scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Scala, Scala you got me worried
>
> Actually you can make an exception for me. I always intend to make
> the message public, unless I change the subject of the mail. I just
> hit the wrong button this time.

============================
A BNY Mellon Company(SM). Pareto Investment Management Limited is authorised and regulated by the Financial Services Authority (Firm Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message.

"Kieron Wilkinson" writes:

> On that point, is there a reason why this list doesn't reply to the list
> by default? I don't mind particularly, I just thought it a bit odd...

Some lists do, some don't. Last time it was asked it turned out this
is the way that EPFL runs all their lists, so that's that.

[...]

On Fri, Mar 13, 2009 at 10:52 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Fri, Mar 13, 2009 at 11:04 AM, sss fredo <sssfredo@gmail.com> wrote:

---------- Forwarded message ----------
From: sss fredo <sssfredo@gmail.com>
Date: Fri, Mar 13, 2009 at 10:03 PM
Subject: Re: [scala-user] Scala, Scala you got me worried
To: Ricky Clarkson <ricky.clarkson@gmail.com>


 Ricky, my point are mainly general but I mentioned code from a specific coder twice. Frankly, you and some other forum members defend your precious language like its some sort of religion with Martin as a demi God - its pretty sickening when you act like that!

This comment is way out of bounds.  Making a personal attach on Martin and/or people who have a healthy respect for Martin does not belong on any of the Scala community mailing lists.  If you find it sickening, please find someplace else to spend your time.

DavidYou are not the Scala police. I have seen you be rude to people time and time again in the Lift forum and here, and I dislike your behavior. I do not wish to be rude to Martin, but Ricky was rude to me and I defended myself.  

While your original post raises some interesting points and I will respond to them later (and I will agree with some of them and disagree with others), I will state categorically that Martin listens to feedback.  He has been the driving vision behind Scala, but his vision is influenced strongly by the feedback that he receives about the language from people in this community, including newbies.  The folks on the list, me included, who will ultimately say, "you know, I don't quite get what Martin's going for, but I'll buy in anyway" do that precisely because Martin listens, Martin is very often right, and Martin admits when he isn't.  This is not god-like or worship on our part, it is the healthy respect for an extremely accomplished person who has over and over again demonstrated an understanding of academic rigor and real world needs.  

On Fri, Mar 13, 2009 at 9:53 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Then complain about it in private, or find some equivalent code.
Can't be hard, if we all suck.

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Sorry, Ricky it not accessible by the public and not my code to post.
>
> On Fri, Mar 13, 2009 at 9:23 PM, Ricky Clarkson <ricky.clarkson@gmail.com>
> wrote:
>>
>> Can you point at the code that you find difficult to understand?
>> Perhaps one of us can help.
>>
>> 2009/3/13 sss fredo <sssfredo@gmail.com>:
>> > Scala, I know you quite well now but our relationship is on the rocks.
>> > Scala doesn't give enough guidance to the programmer on whether to adopt
>> > a
>> > functional or object orientated programming style. I know choice is
>> > sometimes good - but its not for many programmers - they need guidance
>> > not a
>> > plethora of arbitrary options.
>> > Scala is a write once, then throw away and re-write for the next person.
>> > Yup, Im looking at a senior Scala expert's code right now and its not
>> > pretty
>> > or understandable, nor am I a Scala beginner.
>> > Scala implicits are a failed experiment. I like to know whats going on
>> > in a
>> > program. With implicits, I have no idea until I guess and track down the
>> > implicit. I think languages that optionally drop strong typing
>> > (Objective C,
>> > Groovy) are more honest, in that the don't purport to achieve strong
>> > typing
>> > when there is none.
>> > Scala imports of methods using import x.ClassName._ means I have to rely
>> > on
>> > yet unwritten IDE support to know where a method came from.
>> > Scala and its forum are confused as to whether a language should be
>> > quick to
>> > write, terse, verbose or easy to read. Yup you know what I'm talking
>> > about,
>> > things like using "_" or "/:" or how about leaving off the return type
>> > on a
>> > complex function.
>> > Scala functional programming is not as good as Haskell. I know only a
>> > little
>> > Haskell, but when I read it, it makes sense. When Scala is written in a
>> > functional style it looks more verbose and much less readable.
>> > Scala functional programming is spaghetti code. Im reading a senior,
>> > well
>> > known, Scala functional programmer's code and it reminds me of the worst
>> > rubbish I saw from procedural programming 10-20 years ago. Do all
>> > functional
>> > programmers have a need to stuff as much logic in two lines as possible.
>> > Who
>> > said vertical space is bad?
>> > Scala forum members have very big heads. I am sick of hearing how much
>> > above
>> > Java life Scala life is - I've waited and waited but you guys still
>> > haven't
>> > produced enough to back this assertion up.
>
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

He is not the Scala police, but he echoes many my sentiments, at least.

You're raising a lot of important issues, and your email has already initiated what could turn out to be a very healthy discussion about coding in Scala. I think this discussion is important, but it's also important to keep civility in discourse.

I think this list is capable of critical discussion of the merits Scala, and even of the merits of Martin's technical decisions regarding Scala. However, I would hope that any such discussion would be kept civil.

--j

DavidYou are not the Scala police. I have seen you be rude to people time and time again in the Lift forum and here, and I dislike your behavior. I do not wish to be rude to Martin, but Ricky was rude to me and I defended myself.

Bruce Stephens wrote:
> "Kieron Wilkinson" writes:
>
>> On that point, is there a reason why this list doesn't reply to the list
>> by default? I don't mind particularly, I just thought it a bit odd...
>
> Some lists do, some don't. Last time it was asked it turned out this
> is the way that EPFL runs all their lists, so that's that.

For what it's worth, I have the following procmail snippet inserted to
handle it for me:

# Auto-mogrify scala lists
:0 fhw
* ^List-Post:.*scala-user@listes.epfl.ch
|formail -f -a "Reply-To: scala-user@listes.epfl.ch"

:0 fhw
* ^List-Post:.*scala-debate@listes.epfl.ch
|formail -f -a "Reply-To: scala-debate@listes.epfl.ch"

You can duplicate and/or modify to your taste. I'm not sure if there's
an easy way to do the same thing with standard email clients.

Derek

Jorge
From what I read of your posts, you are helpful and courteous. I appreciate this, but as you are a lift committer, I would expect you to defend David. Unfortunately, David just waded in the same way he did to someone who threatened to take his own life. I read that series of emails and I found David uncourteous, uncivil and I think he should apologize. 
I meant my original email to be constructive and useful. 

On Sat, Mar 14, 2009 at 12:30 AM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

He is not the Scala police, but he echoes many my sentiments, at least.

You're raising a lot of important issues, and your email has already initiated what could turn out to be a very healthy discussion about coding in Scala. I think this discussion is important, but it's also important to keep civility in discourse.

I think this list is capable of critical discussion of the merits Scala, and even of the merits of Martin's technical decisions regarding Scala. However, I would hope that any such discussion would be kept civil.

--j

DavidYou are not the Scala police. I have seen you be rude to people time and time again in the Lift forum and here, and I dislike your behavior. I do not wish to be rude to Martin, but Ricky was rude to me and I defended myself.

There was some extra context to those emails that never made it to the
public eye.

I'm not a lift committer, I've never discussed anything with David,
and I fully agree with what he said here.

2009/3/13 sss fredo :
> Jorge
> From what I read of your posts, you are helpful and courteous. I appreciate
> this, but as you are a lift committer, I would expect you to defend David.
> Unfortunately, David just waded in the same way he did to someone who
> threatened to take his own life. I read that series of emails and I found
> David uncourteous, uncivil and I think he should apologize.
> I meant my original email to be constructive and useful.
>
> On Sat, Mar 14, 2009 at 12:30 AM, Jorge Ortiz wrote:
>>
>> He is not the Scala police, but he echoes many my sentiments, at least.
>>
>> You're raising a lot of important issues, and your email has already
>> initiated what could turn out to be a very healthy discussion about coding
>> in Scala. I think this discussion is important, but it's also important to
>> keep civility in discourse.
>>
>> I think this list is capable of critical discussion of the merits Scala,
>> and even of the merits of Martin's technical decisions regarding Scala.
>> However, I would hope that any such discussion would be kept civil.
>>
>> --j
>>
>>> David
>>> You are not the Scala police. I have seen you be rude to people time and
>>> time again in the Lift forum and here, and I dislike your behavior. I do not
>>> wish to be rude to Martin, but Ricky was rude to me and I defended myself.
>
>

sss fredo wrote:
> Jorge
> >From what I read of your posts, you are helpful and courteous. I appreciate
> this, but as you are a lift committer, I would expect you to defend David.
> Unfortunately, David just waded in the same way he did to someone who
> threatened to take his own life. I read that series of emails and I found
> David uncourteous, uncivil and I think he should apologize.
>
>

you'd probably expect people on this list to respond to the content, not
form, of your posts; in exchange, try to focus on the content and not
form of their answers ;)

personal dis/courtesy is mostly uninteresting for the general audience.
unless you admire the developers, that is.

vQ

Count the number of discourteous responses to me and note the initiator of the initial discourteous message.
Ricky wanted an argument in the first place. He, Miles and David appeared determined to defend their religion. They don't give any reasons for their viewpoint, just attack. 
Its their intention to dilute any meaningful discussion! They won - Scala is safe in their hands.
The last time I saw something like this was when Ruby was "discussed"
On Sat, Mar 14, 2009 at 1:30 AM, Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk@idi.ntnu.no> wrote:

sss fredo wrote:
> Jorge
> >From what I read of your posts, you are helpful and courteous. I appreciate
> this, but as you are a lift committer, I would expect you to defend David.
> Unfortunately, David just waded in the same way he did to someone who
> threatened to take his own life. I read that series of emails and I found
> David uncourteous, uncivil and I think he should apologize.
>
>

you'd probably expect people on this list to respond to the content, not
form, of your posts;  in exchange, try to focus on the content and not
form of their answers ;)

personal dis/courtesy is mostly uninteresting for the general audience.
unless you admire the developers, that is.

vQ

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

Show, in my initial post, what was disourteous

On Sat, Mar 14, 2009 at 1:42 AM, Gergely Buday <gbuday@gmail.com> wrote:

2009/3/13 sss fredo <sssfredo@gmail.com>:
> Count the number of discourteous responses to me and note the initiator of
> the initial discourteous message.

It was your message in the first place which was discourteous...

- G

Scala doesn't give enough guidance to the programmer on whether to adopt a functional or object orientated programming style. I know choice is sometimes good - but its not for many programmers - they need guidance not a plethora of arbitrary options.
Here's my initial post with two paragraphs cut out - explain where I am trolling?
implicits are a failed experiment. I like to know whats going on in a program. With implicits, I have no idea until I guess and track down the implicit. I think languages that optionally drop strong typing (Objective C, Groovy) are more honest, in that the don't purport to achieve strong typing when there is none.  I'll cut out two paragraphs
Scala imports of methods using import x.ClassName._ means I have to rely on yet unwritten IDE support to know where a method came from.
Scala and its forum are confused as to whether a language should be quick to write, terse, verbose or easy to read. Yup you know what I'm talking about, things like using "_" or "/:" or how about leaving off the return type on a complex function.
Scala functional programming is not as good as Haskell. I know only a little Haskell, but when I read it, it makes sense. When Scala is written in a functional style it looks more verbose and much less readable. 
Scala forum members have very big heads. I am sick of hearing how much above Java life Scala life is - I've waited and waited but you guys still haven't produced enough to back this assertion up.
On Sat, Mar 14, 2009 at 1:44 AM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday <gbuday@gmail.com> 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

2009/3/13 sss fredo :
> Count the number of discourteous responses to me and note the initiator of
> the initial discourteous message.

It was your message in the first place which was discourteous...

- G

"Frankly, you and some other forum members defend your precious
language like its some sort of religion with Martin as a demi God -
its pretty sickening when you act like that!"

And you wonder that you get a storm in response?

- G

sss fredo wrote:
> Scala doesn't give enough guidance to the programmer on whether to adopt a
> functional or object orientated programming style. I know choice is
> sometimes good - but its not for many programmers - they need guidance not a
> plethora of arbitrary options.
>
> Here's my initial post with two paragraphs cut out - explain where I am
> trolling?
>

sss fredo, miles, gergely, and others involved: can you stop this
metatalk? it's really uninteresting. i'm just an observer here and
it's not my competence to say that, but why wouldn't you discuss these
things offline?

vQ

If the scala minds have harvested what little of this was useful criticism, then let's allow this remarkably low signal-to-noise ratio thread to wither away.

Thanks,
Jon


On Fri, Mar 13, 2009 at 10:57 AM, Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk@idi.ntnu.no> wrote:

sss fredo wrote:
> Scala doesn't give enough guidance to the programmer on whether to adopt a
> functional or object orientated programming style. I know choice is
> sometimes good - but its not for many programmers - they need guidance not a
> plethora of arbitrary options.
>
> Here's my initial post with two paragraphs cut out - explain where I am
> trolling?
>

sss fredo, miles, gergely, and others involved:  can you stop this
metatalk?  it's really uninteresting.  i'm just an observer here and
it's not my competence to say that, but why wouldn't you discuss these
things offline?

vQ

On Fri, Mar 13, 2009 at 2:50 PM, Gergely Buday wrote:
> And you wonder that you get a storm in response?

No, he doesn't wonder ... that's exactly the reaction he's after ...

Cheers,

Miles

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

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 <miles@milessabin.com> wrote:

On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday <gbuday@gmail.com> 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

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

I would have to agree on these points. The IDE support has improved
greatly (thanks Miles and Caoyun (sp)! ), but still has a long way to go
to reach the maturity of what we have for Java. Having use some truly
atrocious Java IDEs back in the early days (VisualAge comes to mind), I
have every confidence that this will eventually be a non-issue.
Documentation is also a sore point for me; The Scala API docs are still
terse and somewhat incomplete, but I think that this, too, will improve
with time. The recent growth in Scala programming books should help this
as well, and I would definitely appreciate an "Effective Scala" book.

Things like Code style, implicits, wildcard imports, etc, are more of a
gray area. I prefer languages that err on the side of giving me
flexibility and power over constraining me for my own good up to a
point, but I agree that these facilities can be used for evil as well as
good. I've done some template metaprogramming in C++ and it's the same
thing there: you have a lot of power but you can also render your code
incomprehensible pretty quickly if you're not diligent. Perhaps we need
a @HereBeDragons annotation and associated compiler warning?

Derek

Cute Kitten + Emoticon Deluge!!!!!!!!!!!!!!!!!!




http://www.swapmeetdave.com/Humor/Cats/Kitten-Duck.jpg

http://www.funnydog.net/images/cocktail-kitten.jpg


http://kittydoom.wordpress.com/2008/07/23/this-cat-is-pushing-a-watermelon-out-of-a-lake/


Please move this to scala-debate!

On Fri, Mar 13, 2009 at 11:21 AM, Derek Chen-Becker <java@chen-becker.org> wrote:

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

I would have to agree on these points. The IDE support has improved
greatly (thanks Miles and Caoyun (sp)! ), but still has a long way to go
to reach the maturity of what we have for Java. Having use some truly
atrocious Java IDEs back in the early days (VisualAge comes to mind), I
have every confidence that this will eventually be a non-issue.
Documentation is also a sore point for me; The Scala API docs are still
terse and somewhat incomplete, but I think that this, too, will improve
with time. The recent growth in Scala programming books should help this
as well, and I would definitely appreciate an "Effective Scala" book.

Things like Code style, implicits, wildcard imports, etc, are more of a
gray area. I prefer languages that err on the side of giving me
flexibility and power over constraining me for my own good up to a
point, but I agree that these facilities can be used for evil as well as
good. I've done some template metaprogramming in C++ and it's the same
thing there: you have a lot of power but you can also render your code
incomprehensible pretty quickly if you're not diligent. Perhaps we need
a @HereBeDragons annotation and associated compiler warning?

Derek

On Fri, Mar 13, 2009 at 4:21 PM, Derek Chen-Becker wrote:
> 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
>
> I would have to agree on these points. The IDE support has improved
> greatly (thanks Miles and Caoyun (sp)! ), but still has a long way to go
> to reach the maturity of what we have for Java. Having use some truly
> atrocious Java IDEs back in the early days (VisualAge comes to mind), I
> have every confidence that this will eventually be a non-issue.
> Documentation is also a sore point for me; The Scala API docs are still
> terse and somewhat incomplete, but I think that this, too, will improve
> with time. The recent growth in Scala programming books should help this
> as well, and I would definitely appreciate an "Effective Scala" book.
>
> Things like Code style, implicits, wildcard imports, etc, are more of a
> gray area. I prefer languages that err on the side of giving me
> flexibility and power over constraining me for my own good up to a
> point, but I agree that these facilities can be used for evil as well as
> good. I've done some template metaprogramming in C++ and it's the same
> thing there: you have a lot of power but you can also render your code
> incomprehensible pretty quickly if you're not diligent. Perhaps we need
> a @HereBeDragons annotation and associated compiler warning?
>
> Derek
>

+1 for @HereBeDragons :->

The only thing is knowing where to put the annotation :-) I think its
safe to say that the Monad / Functor / Arrow / Control structures of
scalaz could be labelled with such if its from a "changing may cause
unexpected ripples in the type system" perspective but I'm not sure
the same could be said for using it. So perhaps:

@HereBeDragons(type=apiConsumer | apiProvider | threads |
otherOnesThatIcantQuiteThink of; authorOfWarning=)

Actually this is prime territory for a plugin to parse these into
usable warnings...

Joking aside this is the only problem I truly see in Scala, that its
not too easy to seperate the parts of the language that should / could
be used for api writing and that for normal consumption. I see that
the mythical Effective Scala book could help to address this.

My own personal approach : if you need your api user to specify more
than one or two types for a given function use it better have a damn
good explanation and examples with it. But I've held that for C++ as
well, and I was quite fond of using the fc++ and boost libraries.

On Friday March 13 2009, 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.

From my perspective, the underlying truth of these observations is that
these concepts are always in play in all programming languages.
Obscuring, blurring or even eradicating the distinctions they represent
may allow quicker comprehension of the restricted cases they
accommodate, but where the fully general set of programming language
concepts is in play, you're only hampering yourself to be presented
with a language that pretends those concepts or distinctions don't
exist.

Programming isn't easy, but there are quite a few people who can do OK
at it within bounds. Simpler programming languages such as Java make
programming within those bounds manageable and straightforward. Trying
to transcend those bounds in Java is possible (as it is, technically,
in assembly or on a Turing machine), but far more challenging than is
necessary. Scala is several steps closer to the fundamentals of
computing (typed lambda calculus, e.g.) than is Java and thus once
comprehended, opens new vistas. But that freedom doesn't come cheap in
terms of mental effort. I guess for those chafing at the limits or
tedium of programming in Java, Scala is worth the work. For those who
don't (yet?) see the value, clearly the effort is without payoff.

As far as a the plethora of operator notations, naturally an
S-expression counterpart is possible, and (separately) the language
could be framed without symbols—using only keywords—but that sort of
verbosity only hampers users once they're over the hump of learning the
language's vocabulary. (Though my offhand perception is that a
language-integrated metaprogramming capability is easier with
S-expressions.)

All in all, it's just comes down to being another case of the "no free
lunch" or "no silver bullets" aphorisms.

> ~~ Robert.

Randall Schulz

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 Fri, Mar 13, 2009 at 7:22 PM, John Nilsson <john@milsson.nu> 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.

I fully agree, but have to add that it's also vital to avoid the dirty condition.
 

BR,
John


On Fri, Mar 13, 2009 at 4:19 PM, Robert Fischer
<robert.fischer@smokejumperit.com> 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 <miles@milessabin.com
>> <mailto:miles@milessabin.com>> wrote:
>>
>>    On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday <gbuday@gmail.com
>>    <mailto:gbuday@gmail.com>> 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
>

--
Viktor Klang
Senior Systems Analyst

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 believe that there is a rather big differance between system programming and application progrimming.
Or rather, API development and app development.

The code for frameworks will be more complex in order to simplify "consumer" code.
But what John is saying here is that in Scala it's oftentimes easier to write the crufty code than to make it a named function in it's own scope. (Wether this is "good" or "bad" is up to the reader to decide)

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.

Cheers,
Viktor

On Fri, Mar 13, 2009 at 9:24 PM, Christian Szegedy <christian.szegedy@gmail.com> 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 <john@milsson.nu> 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
>  <robert.fischer@smokejumperit.com> 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 <miles@milessabin.com
>  >> <mailto:miles@milessabin.com>> wrote:
>  >>
>  >>    On Fri, Mar 13, 2009 at 2:42 PM, Gergely Buday <gbuday@gmail.com
>  >>    <mailto:gbuday@gmail.com>> 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
>  >
>

--
Viktor Klang
Senior Systems Analyst

On Friday March 13 2009, Christian Szegedy wrote:
> I disagree.
>
> Just think of mathematics: it was a revolution in the 16-17th century
> when algebra was invented. It might look cryptic at first, but just
> compare the following two
>
> (-b +|- sqrt(b^2-4ac ) )/(2a)
>
> with:
>
> "..."
>
> Nowadays nobody would argue the a professional book about physics,
> economics, chemistry, engineering, etc. contains too many formulas.
> All of them have their own operators, naming conventions etc. and
> looks abstract gibberish to anyone not familiar with the domain. But
> that's fine, these books are written for those that
> *are* familiar and they would not tolerate a verbose salad of words.

There is a reverse phenomenon in programming. People write code with
absolutely minimalistic names but without the supporting prose that
would be present in a textbook surrounding such a minimalist symbolic
presentation. That renders code incomprehensible without meticulous,
expression-by-expression scrutiny of the tersely written code.

> Actually my sentiment is very close to that of Paul Graham's
> expressed in http://www.paulgraham.com/noop.html
> where he argues:
>
> "Object-oriented programming generates a lot of what looks like work.
> Back in the days of fanfold, there was a type of programmer who would
> only put five or ten lines of code on a page, preceded by twenty
> lines of elaborately formatted comments. Object-oriented programming
> is like crack for these people: it lets you incorporate all this
> scaffolding right into your source code. Something that a Lisp
> hacker might handle by pushing a symbol onto a list becomes a whole
> file of classes and methods. So it is a good tool if you want to
> convince yourself, or someone else, that you are doing a lot of
> work."

That is somewhere between a caricature and an extreme exaggeration.
Programmers who just want to generate maximum line count to get a given
job done aren't going to go far in today's world, I don't think. Nor,
do I think, that given the apparent popularity of "lean" and "agile"
methods, that this is even the general trend direction in contemporary
software practice.

Randall Schulz

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

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

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

On Friday March 13 2009, Christian Szegedy wrote:
> I strongly agree that giving meaningful descriptive variable names is
> the best form of source documentation, wherever a variable is
> *necessary*.
>
> What I don't believe is that programmers should be forced to rewrite
> the same function with different names over and over again (due to
> lack of suitable abstraction mechanisms in the language).

One would certainly hope not, but it seems that Scala would be very
salutary in that respect.

Randall Schulz

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.
>
I think this (and some of the original criticism) gets at a principle of
good language design that I've heard described as The Law of Parsimony.
That is, it is desirable for a language (or any sort of system or model)
to have as few constructs as possible for expressing its target domain.
Parsimony can perhaps be thought of the ratio between how many
constructs a language has and how many "things" you can do with it. Of
course the number of constructs tends to increase as abilities (for lack
of a better word) do, but some languages do more with less. Constructing
a language to maximize parsimony is a rare and difficult art.

Anyway, I think it is a valid question, how well does Scala score on
Parsimony? I'm a Scala beginner, so I don't attach great confidence to
my subjective opinion on this, but my gut impression is that it does
not, particularly in the important area of the type system. It has more
abilities than most other languages, but at the cost of a large number
of constructs. I'd be interested to hear the opinions of other more
experienced users.

Eric

Anyway, I think it is a valid question, how well does Scala score on
Parsimony? I'm a Scala beginner, so I don't attach great confidence to
my subjective opinion on this, but my gut impression is that it does
not, particularly in the important area of the type system. It has more
abilities than most other languages, but at the cost of a large number
of constructs. I'd be interested to hear the opinions of other more
experienced users.

Eric

The type system may perhaps be too verbose in the global vision of type systems in general, however I'd say a lot of scala concepts are very nice.  I have what I call the "power triads" of scala ->
Type Triad - Class, Object, trait
Member Triad - def, val, var
Control Traid - Pattern Matching, Closures, For Expressions

These tend to be the things I use most often. The scala type system may be verbose, but it does let me express most of the things I need for daily development (that Java can't necessarily do).   However the 9 things listed above are fairly powerful, and can be used in many places.  I believe they are the "core" concepts in scala (+ it's type system).  There are a few extraneous pieces here or there to get around issues and be "practical", but in general I find scala to be far more parsimonious? than java (and much more so than C++).

I'd say scala's type system is relatively simple and well designed,
(especially when compared to C++, which is the worst trade-off
between complexity and abstraction capabilities)

For example in Scala, everything is object and has a class, even
functions. Scala unifies variant types with classes, whereas in ocaml
there are classes/variants and open variants all completely different
mechanisms. In Scala there are only classes with some syntactic sugar
for matchability and run-type (type) matching.

The generic (template) support is straightforward, but general enough
for most purposes.

There are traits, but they are organically embedded into the class
hierarchy, so they are mostly indistinguishable from classes, apart
for a small (but important) set of useful additional features.

The class hierarchy is general and flexible enough to act as a
replacement of ML/Ocaml's module system without introducing any new
language constructs.

In ML/Ocaml/Haskell, there are also records. Needless to say scala
does not need them (it has classes).

All-in-all, scala may look a bit baroque on surface, but if one strips
the sugar, the core is more compact and carefully designed than almost
everything around I can think of.

Compared to Haskell: if you want to have similar functionality to
scala (e.g.late binding) you need to use a lot non-standard extensions
like existential types. For side effects, you'll need monads. For
overloading: type classes, and strictness annotations for somewhat
predictible memory consumption. After all that magic, you still won't
have a reasonable module system, inheritance, functors etc.

I would not say scala is without flaws: e.g. type removal is really
an amazingly bad idea IMO and I tend to agree the implicit conversions
seem to do more harm than good, but I am just a beginner, I may will
see things in a different light in a month or so.

On 3/13/09, Eric Schwarzenbach wrote:
> 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.
> >
>
> I think this (and some of the original criticism) gets at a principle of
> good language design that I've heard described as The Law of Parsimony.
> That is, it is desirable for a language (or any sort of system or model)
> to have as few constructs as possible for expressing its target domain.
> Parsimony can perhaps be thought of the ratio between how many
> constructs a language has and how many "things" you can do with it. Of
> course the number of constructs tends to increase as abilities (for lack
> of a better word) do, but some languages do more with less. Constructing
> a language to maximize parsimony is a rare and difficult art.
>
> Anyway, I think it is a valid question, how well does Scala score on
> Parsimony? I'm a Scala beginner, so I don't attach great confidence to
> my subjective opinion on this, but my gut impression is that it does
> not, particularly in the important area of the type system. It has more
> abilities than most other languages, but at the cost of a large number
> of constructs. I'd be interested to hear the opinions of other more
> experienced users.
>
>
> Eric
>
>
>
>
>

On Fri, Mar 13, 2009 at 10:36 PM, Eric Schwarzenbach
wrote:
> 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.
>>
> I think this (and some of the original criticism) gets at a principle of
> good language design that I've heard described as The Law of Parsimony.
> That is, it is desirable for a language (or any sort of system or model)
> to have as few constructs as possible for expressing its target domain.
> Parsimony can perhaps be thought of the ratio between how many
> constructs a language has and how many "things" you can do with it. Of
> course the number of constructs tends to increase as abilities (for lack
> of a better word) do, but some languages do more with less. Constructing
> a language to maximize parsimony is a rare and difficult art.
>
> Anyway, I think it is a valid question, how well does Scala score on
> Parsimony? I'm a Scala beginner, so I don't attach great confidence to
> my subjective opinion on this, but my gut impression is that it does
> not, particularly in the important area of the type system. It has more
> abilities than most other languages, but at the cost of a large number
> of constructs.

It's a bit sad to read that you have this impression. Because
parsimony, in particular wrt to the type system was one of the more
important goals in the design of Scala. We did face some tough
constraints related to Java interoperability. We worked very hard not
to have to duplicate all of Java's type system in Scala; for instance,
there are no enumerations, or raw types, or wildcard types, or
primitive types. But there is enough that remains. In an ideal world,
I'd throw out classes and keep only traits, maybe throw out generics
and keep only abstract types. But the resulting language would be an
island...

Cheers

> But there is enough that remains. In an ideal world,
> I'd throw out classes and keep only traits, maybe throw out generics
> and keep only abstract types. But the resulting language would be an
> island...

I might misunderstand what is being talked about here, but what would
you say about Clojure in this regard?

sincerely.

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

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

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

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

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

> sincerely.

Randall Schulz

I think you completley missed my point. I think the mathematical
notation is perfectly acceptable to express mathematical fomulas.

I menat that the code should express things in a language suitable to
the level of abstraction relevant for the module. In your example the
mathematical fomula may be the suitable language.

Whith "naming thing" I really meant abstract the lower abstraction mechanics.

I guess a suitable way to do this in scala would be to express the
plumbing needed for a piece of domain logic in a trait that forms a
mini DSL used to implement that logic. And then express the higher
level thoughts using that trait.

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