Why Scala not groovy or Clojure?

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Why Scala not groovy or Clojure?

Aseem Bansal
Can someone give any inputs on https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/

Asked a similar question from Clojure community 
https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n


--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Oliver Ruebenacker

     Hello,

  "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy

  Clojure? Sure, if you like Lisp.

     Best, Oliver


On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <[hidden email]> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Rex Kerr-2
In reply to this post by Aseem Bansal
I think the comments you've already got are mostly fair, with the obvious caveat that people who really like Clojure like its relatively singleminded approach.  It is true that Scala gives you several different powerful paradigms (imperative, OO, FP/typeclasses) and although each is relatively easy to use in the language, the combination of them is conceptually difficult at times.  But in exchange, you mostly get to use the best paradigm for your task, and because it's strongly typed the compiler will do a lot of work for you to help you ensure your program is not broken in obvious ways.

(As an example, I've been using Julia recently for data analysis, and it is a pretty nice language in its domain, but the larger my programs get the more they break because I have gotten the types wrong, or, even worse, do the wrong thing because what I ask for is defined on the wrong type and the wrongness propagates.  Yes, yes, unit tests--this is what slips through because my unit tests are not infinitely extensive.)

  --Rex


On Wed, Nov 4, 2015 at 6:29 AM, Aseem Bansal <[hidden email]> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Alan Burlison
On 04/11/2015 17:22, Rex Kerr wrote:

> But in exchange, you mostly get to use the best paradigm for your
> task, and because it's strongly typed the compiler will do a lot of
> work for you to help you ensure your program is not broken in obvious
> ways.

On the subject of Scala use cases, someone pointed me to this (oldish)
paean of praise for Scala:

http://bellringers.net/pipermail/ringing-theory_bellringers.net/2012-July/010619.html

For those of you who don't know a Helixoid-based extent from a hole in
the ground, the subject area is English Change Ringing, which despite
being 300+ years old and involving the contents of dusty church bell
towers, is mathematically-based (it's an application of group theory)
and Scala is a good fit as a result.

https://en.wikipedia.org/wiki/Change_ringing

Eat your heart out Haskell ;-)

--
Alan Burlison
--

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Eric Kolotyluk
In reply to this post by Oliver Ruebenacker
Interesting claim by James Strachan. Very honest and sensible.

After playing around with Java FX Script for a while I was astonished that the team at Sun Microsystems invented 'yet another language' that had many of the features of Scala, but was far less well developed than Scala. I, and others, complained about this openly, and now Java FX Script has expired, while Scala FX is a better replacement.

Years before when I learned Groovy, my sense was that it was a better Java, and I really enjoyed it. After that I tried to learn Scala, and hurt myself so badly, it took over a year to take another try at it. Since then, I find that Scala is like a better Groovy, and a much better Java in many ways, but...

At the same time, Scala is very similar to my experiences with C++ where C++ was supposed to be a better C. When Java first came out, I immediately abandoned C++ as being a waist of time, realizing that Java was a much better C than C++ could ever be. After 20 years of using Java I am still convinced that Java is astonishingly better than C++, but almost glacial in its evolution.

My ultimate hope is some new language will come along that replaces Scala the way Java replaced C++. The most valuable thing about C++ was that it was full of lessons on how not to design a language. Similarly, Scala has many good lessons on how not to design a language. My sense of Scala is that it is the 'Kitchen Sink' language that James Gosling once talked about. My other sense is that Martin Odersky was quite brilliant in the original intent of Scala, far better than Bjarne Stroustrup was at C++, but there have been so many other cooks in that kitchen since then that Scala is now a very disturbing 'kitchen sink' indeed.

While I personally enjoy writing code in Scala, I thoroughly hate reading most other people's Scala code. While I love many of the APIs in Scala, I thoroughly hate most of the others. Scala takes me to the extremes of my emotions like no other programming language I have ever used. The main problem I see with the Scala community these days is most people are too focused on adding new and 'clever' features, and too few are focused on actually cleaning up the mess.

I have seen advances in Computing Science through Scala like no other language before it, but there really needs to be a new language to replace it. Scala is a really awesome playground for ideas and innovation, but I have recently concluded that it is too dangerous and unwieldy for practical software engineering solutions.

I really look forward to the next new language to replace Scala. If anyone has any recommendations, please let me know.

- Eric

On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:

     Hello,

  "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy

  Clojure? Sure, if you like Lisp.

     Best, Oliver


On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <[hidden email]> wrote:
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Alan Burlison
On 04/11/2015 20:02, Eric Kolotyluk wrote:

> I really look forward to the next new language to replace Scala. If
> anyone has any recommendations, please let me know.

https://github.com/lampepfl/dotty

--
Alan Burlison
--

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Martin Odersky
In reply to this post by Eric Kolotyluk
On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk <[hidden email]> wrote:

> Interesting claim by James Strachan. Very honest and sensible.
>
> After playing around with Java FX Script for a while I was astonished that
> the team at Sun Microsystems invented 'yet another language' that had many
> of the features of Scala, but was far less well developed than Scala. I, and
> others, complained about this openly, and now Java FX Script has expired,
> while Scala FX is a better replacement.
>
> Years before when I learned Groovy, my sense was that it was a better Java,
> and I really enjoyed it. After that I tried to learn Scala, and hurt myself
> so badly, it took over a year to take another try at it. Since then, I find
> that Scala is like a better Groovy, and a much better Java in many ways,
> but...
>
> At the same time, Scala is very similar to my experiences with C++ where C++
> was supposed to be a better C. When Java first came out, I immediately
> abandoned C++ as being a waist of time, realizing that Java was a much
> better C than C++ could ever be. After 20 years of using Java I am still
> convinced that Java is astonishingly better than C++, but almost glacial in
> its evolution.
>
> My ultimate hope is some new language will come along that replaces Scala
> the way Java replaced C++. The most valuable thing about C++ was that it was
> full of lessons on how not to design a language. Similarly, Scala has many
> good lessons on how not to design a language. My sense of Scala is that it
> is the 'Kitchen Sink' language that James Gosling once talked about. My
> other sense is that Martin Odersky was quite brilliant in the original
> intent of Scala, far better than Bjarne Stroustrup was at C++, but there
> have been so many other cooks in that kitchen since then that Scala is now a
> very disturbing 'kitchen sink' indeed.
>
> While I personally enjoy writing code in Scala, I thoroughly hate reading
> most other people's Scala code. While I love many of the APIs in Scala, I
> thoroughly hate most of the others. Scala takes me to the extremes of my
> emotions like no other programming language I have ever used. The main
> problem I see with the Scala community these days is most people are too
> focused on adding new and 'clever' features, and too few are focused on
> actually cleaning up the mess.
>
> I have seen advances in Computing Science through Scala like no other
> language before it, but there really needs to be a new language to replace
> it. Scala is a really awesome playground for ideas and innovation, but I
> have recently concluded that it is too dangerous and unwieldy for practical
> software engineering solutions.
>
> I really look forward to the next new language to replace Scala. If anyone
> has any recommendations, please let me know.
>

Thanks for the frank assessment, Eric! I do hope that with Dotty, the
"Scala.next" effort, we can clean up some of the more contentious
points of Scala. If you have some specific input what you think we
should address, I'd like to read it!

 - Martin

> - Eric
>
>
> On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:
>
>
>      Hello,
>
>   "I can honestly say if someone had shown me the Programming in Scala book
> by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably
> have never created Groovy." -- James Strachan, inventor of Groovy
>
>   Clojure? Sure, if you like Lisp.
>
>      Best, Oliver
>
>
> On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <[hidden email]> wrote:
>>
>> Can someone give any inputs on
>> https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/
>>
>> Asked a similar question from Clojure community
>>
>> https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "scala-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Oliver Ruebenacker
> Senior Software Engineer, Diabetes Portal, Broad Institute
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Rex Kerr-2
In reply to this post by Eric Kolotyluk
That's funny because my chief regret with Scala is that it's not rapidly exploring _more_ territory in language design.  If things were as I wished, it'd probably seem even worse to you.

In particular, I have the sense that FP is an overly constraining response to the fact that mutability is hard to reason about.  Mutability is hard to reason about because there are too many things to keep in mind.  But computers are _awesome_ at keeping _zillions_ of things in mind.  Not altering old values seems a clunky way indeed to solve the whole problem, though there are certainly domains where it is just the ticket (e.g. when you _actually_ want both old and new values).

For example, when you write (x map f), that x isn't changed isn't really what saves you, if you never use x again.  It's mostly that all the indexing and looping and building is taken care of for you.  And if you don't mean to use x again,  just having to assign the result to y isn't good enough--you might forget and use x.  Better would be to retire the variable, but that only works if your variables' durations nest (so you can use scope to delimit lifetime).  Being able to say things like "x must change in this block" or "x shouldn't change any more" or "now we're done with x" or "this operation mutates x so much that if you call it you must not use it again without a rename" seem pretty fundamental to how to think about algorithms, but communicating such things to any compiler that I know of is an exercise in writing stifling masses of types.

Anyway, this is off-topic enough so it should go to scala-debate if continued.  But the bigger point is just that tastes differ with regard to languages.  Simpler is not always preferable when not all things are equal.  Simpler with all else equal is awesome, though!

  --Rex

On Wed, Nov 4, 2015 at 12:02 PM, Eric Kolotyluk <[hidden email]> wrote:
Interesting claim by James Strachan. Very honest and sensible.

After playing around with Java FX Script for a while I was astonished that the team at Sun Microsystems invented 'yet another language' that had many of the features of Scala, but was far less well developed than Scala. I, and others, complained about this openly, and now Java FX Script has expired, while Scala FX is a better replacement.

Years before when I learned Groovy, my sense was that it was a better Java, and I really enjoyed it. After that I tried to learn Scala, and hurt myself so badly, it took over a year to take another try at it. Since then, I find that Scala is like a better Groovy, and a much better Java in many ways, but...

At the same time, Scala is very similar to my experiences with C++ where C++ was supposed to be a better C. When Java first came out, I immediately abandoned C++ as being a waist of time, realizing that Java was a much better C than C++ could ever be. After 20 years of using Java I am still convinced that Java is astonishingly better than C++, but almost glacial in its evolution.

My ultimate hope is some new language will come along that replaces Scala the way Java replaced C++. The most valuable thing about C++ was that it was full of lessons on how not to design a language. Similarly, Scala has many good lessons on how not to design a language. My sense of Scala is that it is the 'Kitchen Sink' language that James Gosling once talked about. My other sense is that Martin Odersky was quite brilliant in the original intent of Scala, far better than Bjarne Stroustrup was at C++, but there have been so many other cooks in that kitchen since then that Scala is now a very disturbing 'kitchen sink' indeed.

While I personally enjoy writing code in Scala, I thoroughly hate reading most other people's Scala code. While I love many of the APIs in Scala, I thoroughly hate most of the others. Scala takes me to the extremes of my emotions like no other programming language I have ever used. The main problem I see with the Scala community these days is most people are too focused on adding new and 'clever' features, and too few are focused on actually cleaning up the mess.

I have seen advances in Computing Science through Scala like no other language before it, but there really needs to be a new language to replace it. Scala is a really awesome playground for ideas and innovation, but I have recently concluded that it is too dangerous and unwieldy for practical software engineering solutions.

I really look forward to the next new language to replace Scala. If anyone has any recommendations, please let me know.

- Eric


On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:

     Hello,

  "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy

  Clojure? Sure, if you like Lisp.

     Best, Oliver


On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <[hidden email]> wrote:
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Raoul Duke
> In particular, I have the sense that FP is an overly constraining response
> to the fact that mutability is hard to reason about. Mutability is hard to
> reason about because there are too many things to keep in mind.

Humans are not computers. So the things need to be debuggable by
humans. So they need to be less complicated. That is, until the day
when the complicated solutions to things can be wrapped up into a
language / library and then stupid humans can use them w/out having to
worry about ever needing to look inside them to debug. But the
external behaviour still has to be something simple we can reason
through in our stupid human ways. (Until we leverage ourselves up into
using automated tools to do more reasoning/checking for us.) That is
e.g. what hardware designers do for us all when they make some
out-of-order supporting monster.

There are other language paradigms out there delving into other
possibilities. Maybe they can even be written up as libraries for
Scala to some degree.

* FRP (e.g. Elm)
* RDP
* linear types (e.g. ATS)
* STM (e.g. Haskell, Clojure)
* Sean McDirmid's stuff :-)
* etc.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Eric Kolotyluk
In reply to this post by Martin Odersky


On 2015-11-04 1:32 PM, martin odersky wrote:
On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk [hidden email] wrote:
Interesting claim by James Strachan. Very honest and sensible.

After playing around with Java FX Script for a while I was astonished that
the team at Sun Microsystems invented 'yet another language' that had many
of the features of Scala, but was far less well developed than Scala. I, and
others, complained about this openly, and now Java FX Script has expired,
while Scala FX is a better replacement.

Years before when I learned Groovy, my sense was that it was a better Java,
and I really enjoyed it. After that I tried to learn Scala, and hurt myself
so badly, it took over a year to take another try at it. Since then, I find
that Scala is like a better Groovy, and a much better Java in many ways,
but...

At the same time, Scala is very similar to my experiences with C++ where C++
was supposed to be a better C. When Java first came out, I immediately
abandoned C++ as being a waist of time, realizing that Java was a much
better C than C++ could ever be. After 20 years of using Java I am still
convinced that Java is astonishingly better than C++, but almost glacial in
its evolution.

My ultimate hope is some new language will come along that replaces Scala
the way Java replaced C++. The most valuable thing about C++ was that it was
full of lessons on how not to design a language. Similarly, Scala has many
good lessons on how not to design a language. My sense of Scala is that it
is the 'Kitchen Sink' language that James Gosling once talked about. My
other sense is that Martin Odersky was quite brilliant in the original
intent of Scala, far better than Bjarne Stroustrup was at C++, but there
have been so many other cooks in that kitchen since then that Scala is now a
very disturbing 'kitchen sink' indeed.

While I personally enjoy writing code in Scala, I thoroughly hate reading
most other people's Scala code. While I love many of the APIs in Scala, I
thoroughly hate most of the others. Scala takes me to the extremes of my
emotions like no other programming language I have ever used. The main
problem I see with the Scala community these days is most people are too
focused on adding new and 'clever' features, and too few are focused on
actually cleaning up the mess.

I have seen advances in Computing Science through Scala like no other
language before it, but there really needs to be a new language to replace
it. Scala is a really awesome playground for ideas and innovation, but I
have recently concluded that it is too dangerous and unwieldy for practical
software engineering solutions.

I really look forward to the next new language to replace Scala. If anyone
has any recommendations, please let me know.

Thanks for the frank assessment, Eric! I do hope that with Dotty, the
"Scala.next" effort, we can clean up some of the more contentious
points of Scala. If you have some specific input what you think we
should address, I'd like to read it!

 - Martin

I tried following Dotty, but it is hard to see how to get started as everything is still very raw (uncooked). In particular, what is the difference between a Dotty program and a Scala one? Is there a Dotty primmer?

I will think more about specific input, but for now here is my general sense.

From an Architecture Astronaut perspective, the challenges mere mortals face in using Scala reminds me very much of "The Inmates Are Running The Asylum" by Alan Cooper. Largely the design and implementation of Scala and the accompanying ecosystem has been intended by Scala experts for Scala experts, and this pattern has tended to recurse upon itself like microphone feedback at a concert, producing some horrible noise at times.

This was also much of the failing of C++ where Bjarne Stroustrup et al just seemed to feed off of ever more innovative and clever design tricks without regard for real world programmers. The real genius that James Gosling and crew brought to Java was simplifying things enormously, while adding to Java the important things missing from C, well aware of the dangers of C++. In part their goal was to bring programming to the masses, the way Steve Jobs brought personal computers to the masses. While Steve Jobs democratized computers, James Gosling democratized programming. This is really the heart of what Alan Cooper is getting at:
Software engineers try very hard to make their software easy to use. They believe that their products are as easy to use as is
technically possible.  As engineers, their belief is in technology.  They see power and flexibility, richness of features and functionality in their software.  What they don’t see is how difficult their software is to use for people who use it on a daily basis.  As such, it is hard for them to see clearly the nature of the problems plaguing the software industry. The result is what Cooper calls “Dancing Bearware”.  If one saw a dancing bear on the street, we would be amazed not because the bear dances well, but that the bear dances at all.  Cooper likens this to software today in that people will overlook interaction problems because the software performs its function, albeit problematically and inefficiently.
-- Tim Renczes
In essence, some of the people driving the evolution of Scala are building what they want, without clear evidence of what the end users actually need.

When I was at Kodak I did a lot of User Interface Design and Implementation in Java/Swing. I think I was above average at it, but eventually I discovered other people (outside our team) who were recognizably much better than I. The point was, even though I tried to provide a lot of design leadership for our particular product, it was a lot like herding cats. Too often, other developers (like cooks in the kitchen) invented their own patterns, beaming with pride over their innovations, regardless of established principles, norms and conventions. Generally, developers designed and implemented what they liked rather than what our customers needed. I myself fell prey to this indulgence from time to time.

We did some usability testing before finalizing a few important designs. I myself conducted some tests. They were very time consuming to set up and run, but they did reveal some bad patterns in our design attempts. There in lies the problem. It is way more fun and less expensive to just write code than to go to all the trouble to understand user's actual needs.

The mathematical basis for Scala is remarkably beautiful at times, but most humans cannot appreciate the beauty of mathematics, especially at the higher levels, let alone use it. What Scala is lacking is the psychological basis for normal human cognition, rather than the cognition of a small group of computing science savants.

After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally learned Pascal I was in shock. While Pascal did not have all the bells and whistles of other languages, it was so much easier to write good code, and understand other people's code. When I finally had to start using C in production, I felt it was a huge step backwards from Pascal. Much of the success of Pascal was because Niklaus Wirth intended it to promote good programming practices, where Dennis Ritchie was more intent on other issues than good programming practices.

It is fair to say that many of the Scala design features do promote good programming practices, most notably functional programming. However, my sense is that many other features of not only the Scala language, but the Scala ecosystem are more intended to satisfy the hacking desire of some people more intent on just having fun, without the sense of what normal software developers really need. My recent excursions into Reactive Streams has been a nightmare of WTF experiences.

My experience when I am writing Scala code is that I am constantly referring to reference materials. The language, features, and concepts are so much bigger than Java, I simply do not have enough RAM in my old brain to write code without constant paging. When I read some other people's Scala code, or worse their APIs, then my cognitive paging system starts thrashing, resulting in WTF paralysis, and my verbal synthesis framework executes the 'halt and catch fire' instruction.

I think what is needed is a new language, Scala-like perhaps, but designed more from a software engineering and human psychology perspective. There should be psychological and engineering, or ergonomics testing of critical ideas and concepts. By all means, all that has been learned from Scala should be considered, but the goal should be to consider the 'normal' end user (software developer) first.

Advances in programming language design are like a pendulum that swings between radically innovative to the pragmatically safe, and back. Scala has become a little too radical for practical use.

Cheers, Eric


- Eric


On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:


     Hello,

  "I can honestly say if someone had shown me the Programming in Scala book
by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably
have never created Groovy." -- James Strachan, inventor of Groovy

  Clojure? Sure, if you like Lisp.

     Best, Oliver


On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal [hidden email] wrote:
Can someone give any inputs on
https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/

Asked a similar question from Clojure community

https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n


--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Simon Ochsenreither-3
I think you should not despair. Scala has always been a bit ahead of times, and while there are always steps back, the larger ecosystem of languages and libraries catches up.

In the beginning, Scala shipped with traits, uniform access to values/methods, (companion) objects, and the claim that a language can have good support for both OO and FP.
All of this could have been considered experimental, eccentric or exotic, but if we look at the new crop of languages as well as many old ones, they are all picking these things up.
While I have many disagreements with Martin, he has been an excellent steward of the language, and always keeps the practical application in mind, not only the academic purity.

Although much of the work now, and in the immediate future looks researchy and academic, but has an profound impact on practical engineering:
Take the work on TASTY as an example: Scala is one of the few languages and the only one on the JVM which invests a lot of thought into making compatibility and cross-compilation feasible. No other language has this even on their radar right now!
Take the work on macros and scala.meta: People are pushing the boundaries pretty hard in Scala to make these things practical, whereas many earlier attempts in other languages fell short of having a worthwhile impact.
Take the work on dotty: I didn't believe that the fusion of compiler phases was possible in practice, and people pulled it off. This is a huge advance in compiler design outside of compilers for toy languages.
Take the work on the SBT server: Lots of fancy flow charts and indirections, but in the end it will allow people to have multiple clients like IDEs, build tools, manual input via the SBT console working concurrently without getting into each others way.

I think in ten years people will say that all of this was obvious, but it took some determined Scala people to work hard to bring these new advances into a shape usable by developers.

Of course there are issues:
I think JavaDoc/ScalaDoc style documentation is a lot less useful in Scala than in other languages. This is a problem.
The rapid development causes a lot of churn, because people figure out new ways to make their libraries safer/faster/easier to use.
Standardization can only help so much, because ossification of APIs shipped in the standard library is a huge issue if you apply the standards most Scala developers have.
There is a mismatch in expectations; many people look for a slightly nicer Java, and while Scala certainly provides this, it has so many more improvements that it can cause irritation, because most Scala people think that we can do much better and need to do much better than just having a slightly nicer Java.

If you had issues with Reactive Streams, I think the people working on it would be happy to hear the experience you had with it!

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Martin Odersky
In reply to this post by Eric Kolotyluk
Thanks for your input, Eric. It's interesting to me because some parts
of it match my experience and others don't.

I believe the fundamental issue we are grappling with is abstraction.

In terms of features, core Scala is actually not that big a language.
Core Scala means: excluding things that are experimental or require a
special language import. And Dotty will further shrink the footprint.
If you do think that there are features we could do without, I'd like
to hear about them.

But Scala is a language with powerful abstraction and composition
capabilities. And these are used a lot, and undoubtedly they are also
sometimes overused.

Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.

Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.

But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.

Best,

 - Martin



On Thu, Nov 5, 2015 at 6:50 AM, Eric Kolotyluk <[hidden email]> wrote:

>
>
> On 2015-11-04 1:32 PM, martin odersky wrote:
>
> On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk <[hidden email]>
> wrote:
>
> Interesting claim by James Strachan. Very honest and sensible.
>
> After playing around with Java FX Script for a while I was astonished that
> the team at Sun Microsystems invented 'yet another language' that had many
> of the features of Scala, but was far less well developed than Scala. I, and
> others, complained about this openly, and now Java FX Script has expired,
> while Scala FX is a better replacement.
>
> Years before when I learned Groovy, my sense was that it was a better Java,
> and I really enjoyed it. After that I tried to learn Scala, and hurt myself
> so badly, it took over a year to take another try at it. Since then, I find
> that Scala is like a better Groovy, and a much better Java in many ways,
> but...
>
> At the same time, Scala is very similar to my experiences with C++ where C++
> was supposed to be a better C. When Java first came out, I immediately
> abandoned C++ as being a waist of time, realizing that Java was a much
> better C than C++ could ever be. After 20 years of using Java I am still
> convinced that Java is astonishingly better than C++, but almost glacial in
> its evolution.
>
> My ultimate hope is some new language will come along that replaces Scala
> the way Java replaced C++. The most valuable thing about C++ was that it was
> full of lessons on how not to design a language. Similarly, Scala has many
> good lessons on how not to design a language. My sense of Scala is that it
> is the 'Kitchen Sink' language that James Gosling once talked about. My
> other sense is that Martin Odersky was quite brilliant in the original
> intent of Scala, far better than Bjarne Stroustrup was at C++, but there
> have been so many other cooks in that kitchen since then that Scala is now a
> very disturbing 'kitchen sink' indeed.
>
> While I personally enjoy writing code in Scala, I thoroughly hate reading
> most other people's Scala code. While I love many of the APIs in Scala, I
> thoroughly hate most of the others. Scala takes me to the extremes of my
> emotions like no other programming language I have ever used. The main
> problem I see with the Scala community these days is most people are too
> focused on adding new and 'clever' features, and too few are focused on
> actually cleaning up the mess.
>
> I have seen advances in Computing Science through Scala like no other
> language before it, but there really needs to be a new language to replace
> it. Scala is a really awesome playground for ideas and innovation, but I
> have recently concluded that it is too dangerous and unwieldy for practical
> software engineering solutions.
>
> I really look forward to the next new language to replace Scala. If anyone
> has any recommendations, please let me know.
>
> Thanks for the frank assessment, Eric! I do hope that with Dotty, the
> "Scala.next" effort, we can clean up some of the more contentious
> points of Scala. If you have some specific input what you think we
> should address, I'd like to read it!
>
>  - Martin
>
>
> I tried following Dotty, but it is hard to see how to get started as
> everything is still very raw (uncooked). In particular, what is the
> difference between a Dotty program and a Scala one? Is there a Dotty
> primmer?
>
> I will think more about specific input, but for now here is my general
> sense.
>
> From an Architecture Astronaut perspective, the challenges mere mortals face
> in using Scala reminds me very much of "The Inmates Are Running The Asylum"
> by Alan Cooper. Largely the design and implementation of Scala and the
> accompanying ecosystem has been intended by Scala experts for Scala experts,
> and this pattern has tended to recurse upon itself like microphone feedback
> at a concert, producing some horrible noise at times.
>
> This was also much of the failing of C++ where Bjarne Stroustrup et al just
> seemed to feed off of ever more innovative and clever design tricks without
> regard for real world programmers. The real genius that James Gosling and
> crew brought to Java was simplifying things enormously, while adding to Java
> the important things missing from C, well aware of the dangers of C++. In
> part their goal was to bring programming to the masses, the way Steve Jobs
> brought personal computers to the masses. While Steve Jobs democratized
> computers, James Gosling democratized programming. This is really the heart
> of what Alan Cooper is getting at:
>
> Software engineers try very hard to make their software easy to use. They
> believe that their products are as easy to use as is
> technically possible.  As engineers, their belief is in technology.  They
> see power and flexibility, richness of features and functionality in their
> software.  What they don’t see is how difficult their software is to use for
> people who use it on a daily basis.  As such, it is hard for them to see
> clearly the nature of the problems plaguing the software industry. The
> result is what Cooper calls “Dancing Bearware”.  If one saw a dancing bear
> on the street, we would be amazed not because the bear dances well, but that
> the bear dances at all.  Cooper likens this to software today in that people
> will overlook interaction problems because the software performs its
> function, albeit problematically and inefficiently.
> -- Tim Renczes
>
> In essence, some of the people driving the evolution of Scala are building
> what they want, without clear evidence of what the end users actually need.
>
> When I was at Kodak I did a lot of User Interface Design and Implementation
> in Java/Swing. I think I was above average at it, but eventually I
> discovered other people (outside our team) who were recognizably much better
> than I. The point was, even though I tried to provide a lot of design
> leadership for our particular product, it was a lot like herding cats. Too
> often, other developers (like cooks in the kitchen) invented their own
> patterns, beaming with pride over their innovations, regardless of
> established principles, norms and conventions. Generally, developers
> designed and implemented what they liked rather than what our customers
> needed. I myself fell prey to this indulgence from time to time.
>
> We did some usability testing before finalizing a few important designs. I
> myself conducted some tests. They were very time consuming to set up and
> run, but they did reveal some bad patterns in our design attempts. There in
> lies the problem. It is way more fun and less expensive to just write code
> than to go to all the trouble to understand user's actual needs.
>
> The mathematical basis for Scala is remarkably beautiful at times, but most
> humans cannot appreciate the beauty of mathematics, especially at the higher
> levels, let alone use it. What Scala is lacking is the psychological basis
> for normal human cognition, rather than the cognition of a small group of
> computing science savants.
>
> After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally
> learned Pascal I was in shock. While Pascal did not have all the bells and
> whistles of other languages, it was so much easier to write good code, and
> understand other people's code. When I finally had to start using C in
> production, I felt it was a huge step backwards from Pascal. Much of the
> success of Pascal was because Niklaus Wirth intended it to promote good
> programming practices, where Dennis Ritchie was more intent on other issues
> than good programming practices.
>
> It is fair to say that many of the Scala design features do promote good
> programming practices, most notably functional programming. However, my
> sense is that many other features of not only the Scala language, but the
> Scala ecosystem are more intended to satisfy the hacking desire of some
> people more intent on just having fun, without the sense of what normal
> software developers really need. My recent excursions into Reactive Streams
> has been a nightmare of WTF experiences.
>
> My experience when I am writing Scala code is that I am constantly referring
> to reference materials. The language, features, and concepts are so much
> bigger than Java, I simply do not have enough RAM in my old brain to write
> code without constant paging. When I read some other people's Scala code, or
> worse their APIs, then my cognitive paging system starts thrashing,
> resulting in WTF paralysis, and my verbal synthesis framework executes the
> 'halt and catch fire' instruction.
>
> I think what is needed is a new language, Scala-like perhaps, but designed
> more from a software engineering and human psychology perspective. There
> should be psychological and engineering, or ergonomics testing of critical
> ideas and concepts. By all means, all that has been learned from Scala
> should be considered, but the goal should be to consider the 'normal' end
> user (software developer) first.
>
> Advances in programming language design are like a pendulum that swings
> between radically innovative to the pragmatically safe, and back. Scala has
> become a little too radical for practical use.
>
> Cheers, Eric
>
>
>
> - Eric
>
>
> On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:
>
>
>      Hello,
>
>   "I can honestly say if someone had shown me the Programming in Scala book
> by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably
> have never created Groovy." -- James Strachan, inventor of Groovy
>
>   Clojure? Sure, if you like Lisp.
>
>      Best, Oliver
>
>
> On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal <[hidden email]> wrote:
>
> Can someone give any inputs on
> https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/
>
> Asked a similar question from Clojure community
>
> https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Oliver Ruebenacker
> Senior Software Engineer, Diabetes Portal, Broad Institute
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Viktor Klang
In reply to this post by Simon Ochsenreither-3

Yep, Simon's right, that RS feedback would be really useful, let me know if you have any additional questions too.

--
Cheers,

On 5 Nov 2015 07:25, "Simon Ochsenreither" <[hidden email]> wrote:
I think you should not despair. Scala has always been a bit ahead of times, and while there are always steps back, the larger ecosystem of languages and libraries catches up.

In the beginning, Scala shipped with traits, uniform access to values/methods, (companion) objects, and the claim that a language can have good support for both OO and FP.
All of this could have been considered experimental, eccentric or exotic, but if we look at the new crop of languages as well as many old ones, they are all picking these things up.
While I have many disagreements with Martin, he has been an excellent steward of the language, and always keeps the practical application in mind, not only the academic purity.

Although much of the work now, and in the immediate future looks researchy and academic, but has an profound impact on practical engineering:
Take the work on TASTY as an example: Scala is one of the few languages and the only one on the JVM which invests a lot of thought into making compatibility and cross-compilation feasible. No other language has this even on their radar right now!
Take the work on macros and scala.meta: People are pushing the boundaries pretty hard in Scala to make these things practical, whereas many earlier attempts in other languages fell short of having a worthwhile impact.
Take the work on dotty: I didn't believe that the fusion of compiler phases was possible in practice, and people pulled it off. This is a huge advance in compiler design outside of compilers for toy languages.
Take the work on the SBT server: Lots of fancy flow charts and indirections, but in the end it will allow people to have multiple clients like IDEs, build tools, manual input via the SBT console working concurrently without getting into each others way.

I think in ten years people will say that all of this was obvious, but it took some determined Scala people to work hard to bring these new advances into a shape usable by developers.

Of course there are issues:
I think JavaDoc/ScalaDoc style documentation is a lot less useful in Scala than in other languages. This is a problem.
The rapid development causes a lot of churn, because people figure out new ways to make their libraries safer/faster/easier to use.
Standardization can only help so much, because ossification of APIs shipped in the standard library is a huge issue if you apply the standards most Scala developers have.
There is a mismatch in expectations; many people look for a slightly nicer Java, and while Scala certainly provides this, it has so many more improvements that it can cause irritation, because most Scala people think that we can do much better and need to do much better than just having a slightly nicer Java.

If you had issues with Reactive Streams, I think the people working on it would be happy to hear the experience you had with it!

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Rich Oliver
In reply to this post by Martin Odersky
On Thursday, 5 November 2015 08:02:47 UTC, martin wrote:


Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.

I'm reminded of the spoof interview with Bjarne Stroustrup where he says that he created C++ to create work for programmers. I think part of the popularity of Java is that people to get to create monstrous quasi languages on top called frameworks. If someone really created the perfect general purpose programming language, it would rather spoil all the other would be language designers fun.

Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.

C# is part of the .Net Visual Studio eco system, so it has a huge budget, which really helps for documentation and testing. It shouldn't be surprising that C# can keep its user base happy. Its inevitable that the bar for Scala is going to be a lot higher. Early adopters are inevitably far more self opinionated. However I do think Scala has made some wrong choices notably in the collections library, which has created extra complexity. But I see no reason to apologise for this. Things can only be learnt through experimentation. But not just experimentation, there needs to be a certain pig headedness. An approach might seem like a mistake, but requires someone to keep banging at it before it finally gets to to be really usable. Sometimes a break though happens because someone keeps pushing their intuition long after everyone else had written it off.
But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.

Best,

 - Martin

Well Said!

I could be wrong but my sense is that Spark is the long awaited Scala killer App. I see Scala is up to 24 on Tiobe. If I'm right then love it or hate it Scala is about to arrive.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Eric Kolotyluk
In reply to this post by Martin Odersky
It would be odd if all our experiences matched Martin, and it is serendipitous that some do :-)

I would agree that abstraction can be a fundamental problem at times. Not everyone handles abstraction with equal skill and ease. There is much we could do to make it easier for more people to deal with the abstraction better.

For example, it made sense in Scala to replace the for-loop with the for-comprehension, but it is very much harder for some of us to keep our heads wrapped around the for-comprehension. The for-comprehension is an abstraction of map and flatmap. There is a lot more going on behind the scenes that a for-loop. While I can write code with correct for-comprehensions, it still takes me significantly more mental effort that writing a for-loop in Java.

The problem with abstraction is that, often too much of the actual mechanism is being hidden by elegant looking code, that it becomes harder to reason about the code. For example, one of my pet peeves is using for-comprehensions to deal with future values. Not only are the map and flatmap mechanisms hidden, but all of the concurrent mechanisms are too. It becomes hard to wrap your head around it without significant practice, and if your are new to the concept, well then you have no practice at all. For example, it is really easy for a novice to accidentally try to assign the expressions generating the future values within the for-comprehension itself. You 'just have to know' to assign the expressions to future vals before the for-comprehension because there is nothing in the code to show any problem, the Scala compiler will too happily do what you say and not what you want.

In particular, what I find too often challenging in reading Scala code and APIs is these 'you just have to know' moments. This is especially true when dealing with futures, promises, and other reactive mind puzzles.

There are various ways you could go. You could create a language that is more 'feature rich' to reduce the abstraction, but I am not advocating that.
  1. You could improve the training materials, but this requires scarce resources.
    • Sadly the Scaladoc is generally of little help in understanding important APIs, and I do not sense any urgency in the community to produce better Scaladoc.
    • While the first Coursera course I took was excellent, the second Coursera course was especially frustrating because Erik Meijer is simply not as good at explaining things as Martin and Roland are. I am sure Erik is a wonderful person, but he is not great at explaining things.
    • When I went to other web sites to trying to understand reactive streams, the explanations were just as atrocious.
    • In the course I actually had to experiment with some code to understand what was really going on in Assignment 4. I published my example in the discussion group. Several other students thanked me because it really helped them understand what was mechanically going on. Basically I solved the problem of poorly explained abstraction by creating an example to clearly demonstrate the concrete mechanics. This is something that Erik or someone else should have done before the course. I wish I could find someone to pay me to write Scala training materials.
  2. You could build more diagnostic intelligence into Scalac to perform better static analysis. For example:
    • Warning, you have written a for-comprehension with expressions producing Future values that should probably be computed prior to the for-comprehension. For example (followed by a clear example what to do).
  3. You could even change scalac to do the right thing in the first place, but I am not enough of a compiler expert to know how hard that would be to do, and the other dangers it would create.

Basically I am not asking anyone to abandon their design philosophy around using abstraction, but only to think more about the problems that are created and finding solutions to those problems too. Think more like Alan Cooper did.

I will leave you with this. When the automobile was invented, few really cared about the problems it created. Millions of people have died in automobile accidents, and now our entire planet is in peril because of climate change. Many of the automobile's problems were finally addressed when Ralph Nader came on the scene, and many more have not been addressed. Computing Science and Software Engineering have not seen their Ralph Nader yet, and we continue to forge ahead without really appreciating the unintended consequences of our actions.

Cheers, Eric

P.S. Implicit really should be removed from the language. It causes more problems than it solves by creating even more of those 'you just have to know' moments. I really hate reading examples people write because you generally cannot copy and paste them to get a working example as they almost never declare the hidden implicits the example depends on. It is generally impossible to convince everyone to actually test their code examples before publishing them. IMHO, implicit was one of the worse features added to Scala, and I hope it gets removed from Dotty.


On 2015-11-05 12:02 AM, martin odersky wrote:
Thanks for your input, Eric. It's interesting to me because some parts
of it match my experience and others don't.

I believe the fundamental issue we are grappling with is abstraction.

In terms of features, core Scala is actually not that big a language.
Core Scala means: excluding things that are experimental or require a
special language import. And Dotty will further shrink the footprint.
If you do think that there are features we could do without, I'd like
to hear about them.

But Scala is a language with powerful abstraction and composition
capabilities. And these are used a lot, and undoubtedly they are also
sometimes overused.

Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.

Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.

But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.

Best,

 - Martin



On Thu, Nov 5, 2015 at 6:50 AM, Eric Kolotyluk [hidden email] wrote:

On 2015-11-04 1:32 PM, martin odersky wrote:

On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk [hidden email]
wrote:

Interesting claim by James Strachan. Very honest and sensible.

After playing around with Java FX Script for a while I was astonished that
the team at Sun Microsystems invented 'yet another language' that had many
of the features of Scala, but was far less well developed than Scala. I, and
others, complained about this openly, and now Java FX Script has expired,
while Scala FX is a better replacement.

Years before when I learned Groovy, my sense was that it was a better Java,
and I really enjoyed it. After that I tried to learn Scala, and hurt myself
so badly, it took over a year to take another try at it. Since then, I find
that Scala is like a better Groovy, and a much better Java in many ways,
but...

At the same time, Scala is very similar to my experiences with C++ where C++
was supposed to be a better C. When Java first came out, I immediately
abandoned C++ as being a waist of time, realizing that Java was a much
better C than C++ could ever be. After 20 years of using Java I am still
convinced that Java is astonishingly better than C++, but almost glacial in
its evolution.

My ultimate hope is some new language will come along that replaces Scala
the way Java replaced C++. The most valuable thing about C++ was that it was
full of lessons on how not to design a language. Similarly, Scala has many
good lessons on how not to design a language. My sense of Scala is that it
is the 'Kitchen Sink' language that James Gosling once talked about. My
other sense is that Martin Odersky was quite brilliant in the original
intent of Scala, far better than Bjarne Stroustrup was at C++, but there
have been so many other cooks in that kitchen since then that Scala is now a
very disturbing 'kitchen sink' indeed.

While I personally enjoy writing code in Scala, I thoroughly hate reading
most other people's Scala code. While I love many of the APIs in Scala, I
thoroughly hate most of the others. Scala takes me to the extremes of my
emotions like no other programming language I have ever used. The main
problem I see with the Scala community these days is most people are too
focused on adding new and 'clever' features, and too few are focused on
actually cleaning up the mess.

I have seen advances in Computing Science through Scala like no other
language before it, but there really needs to be a new language to replace
it. Scala is a really awesome playground for ideas and innovation, but I
have recently concluded that it is too dangerous and unwieldy for practical
software engineering solutions.

I really look forward to the next new language to replace Scala. If anyone
has any recommendations, please let me know.

Thanks for the frank assessment, Eric! I do hope that with Dotty, the
"Scala.next" effort, we can clean up some of the more contentious
points of Scala. If you have some specific input what you think we
should address, I'd like to read it!

 - Martin


I tried following Dotty, but it is hard to see how to get started as
everything is still very raw (uncooked). In particular, what is the
difference between a Dotty program and a Scala one? Is there a Dotty
primmer?

I will think more about specific input, but for now here is my general
sense.

From an Architecture Astronaut perspective, the challenges mere mortals face
in using Scala reminds me very much of "The Inmates Are Running The Asylum"
by Alan Cooper. Largely the design and implementation of Scala and the
accompanying ecosystem has been intended by Scala experts for Scala experts,
and this pattern has tended to recurse upon itself like microphone feedback
at a concert, producing some horrible noise at times.

This was also much of the failing of C++ where Bjarne Stroustrup et al just
seemed to feed off of ever more innovative and clever design tricks without
regard for real world programmers. The real genius that James Gosling and
crew brought to Java was simplifying things enormously, while adding to Java
the important things missing from C, well aware of the dangers of C++. In
part their goal was to bring programming to the masses, the way Steve Jobs
brought personal computers to the masses. While Steve Jobs democratized
computers, James Gosling democratized programming. This is really the heart
of what Alan Cooper is getting at:

Software engineers try very hard to make their software easy to use. They
believe that their products are as easy to use as is
technically possible.  As engineers, their belief is in technology.  They
see power and flexibility, richness of features and functionality in their
software.  What they don’t see is how difficult their software is to use for
people who use it on a daily basis.  As such, it is hard for them to see
clearly the nature of the problems plaguing the software industry. The
result is what Cooper calls “Dancing Bearware”.  If one saw a dancing bear
on the street, we would be amazed not because the bear dances well, but that
the bear dances at all.  Cooper likens this to software today in that people
will overlook interaction problems because the software performs its
function, albeit problematically and inefficiently.
-- Tim Renczes

In essence, some of the people driving the evolution of Scala are building
what they want, without clear evidence of what the end users actually need.

When I was at Kodak I did a lot of User Interface Design and Implementation
in Java/Swing. I think I was above average at it, but eventually I
discovered other people (outside our team) who were recognizably much better
than I. The point was, even though I tried to provide a lot of design
leadership for our particular product, it was a lot like herding cats. Too
often, other developers (like cooks in the kitchen) invented their own
patterns, beaming with pride over their innovations, regardless of
established principles, norms and conventions. Generally, developers
designed and implemented what they liked rather than what our customers
needed. I myself fell prey to this indulgence from time to time.

We did some usability testing before finalizing a few important designs. I
myself conducted some tests. They were very time consuming to set up and
run, but they did reveal some bad patterns in our design attempts. There in
lies the problem. It is way more fun and less expensive to just write code
than to go to all the trouble to understand user's actual needs.

The mathematical basis for Scala is remarkably beautiful at times, but most
humans cannot appreciate the beauty of mathematics, especially at the higher
levels, let alone use it. What Scala is lacking is the psychological basis
for normal human cognition, rather than the cognition of a small group of
computing science savants.

After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally
learned Pascal I was in shock. While Pascal did not have all the bells and
whistles of other languages, it was so much easier to write good code, and
understand other people's code. When I finally had to start using C in
production, I felt it was a huge step backwards from Pascal. Much of the
success of Pascal was because Niklaus Wirth intended it to promote good
programming practices, where Dennis Ritchie was more intent on other issues
than good programming practices.

It is fair to say that many of the Scala design features do promote good
programming practices, most notably functional programming. However, my
sense is that many other features of not only the Scala language, but the
Scala ecosystem are more intended to satisfy the hacking desire of some
people more intent on just having fun, without the sense of what normal
software developers really need. My recent excursions into Reactive Streams
has been a nightmare of WTF experiences.

My experience when I am writing Scala code is that I am constantly referring
to reference materials. The language, features, and concepts are so much
bigger than Java, I simply do not have enough RAM in my old brain to write
code without constant paging. When I read some other people's Scala code, or
worse their APIs, then my cognitive paging system starts thrashing,
resulting in WTF paralysis, and my verbal synthesis framework executes the
'halt and catch fire' instruction.

I think what is needed is a new language, Scala-like perhaps, but designed
more from a software engineering and human psychology perspective. There
should be psychological and engineering, or ergonomics testing of critical
ideas and concepts. By all means, all that has been learned from Scala
should be considered, but the goal should be to consider the 'normal' end
user (software developer) first.

Advances in programming language design are like a pendulum that swings
between radically innovative to the pragmatically safe, and back. Scala has
become a little too radical for practical use.

Cheers, Eric



- Eric


On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote:


     Hello,

  "I can honestly say if someone had shown me the Programming in Scala book
by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably
have never created Groovy." -- James Strachan, inventor of Groovy

  Clojure? Sure, if you like Lisp.

     Best, Oliver


On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal [hidden email] wrote:

Can someone give any inputs on
https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/

Asked a similar question from Clojure community

https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n


--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Oliver Ruebenacker
Senior Software Engineer, Diabetes Portal, Broad Institute

--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups
"scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Eric Kolotyluk
In reply to this post by Rich Oliver


On 2015-11-05 6:55 AM, Rich Oliver wrote:
On Thursday, 5 November 2015 08:02:47 UTC, martin wrote:


Abstraction is a tricky business because it gives us the power to
create new things and often one person might not like the things
another person creates. So, it seems to me the only way to avoid the
misuses you refer to is to remove abstraction capabilities from the
language. Turn it into a pre-generics Java, so to speak. But that is
difficult, because almost everyone craves abstraction capabilities;
witness that pre-generics Java which did not have much of it, where
people resorted to horrible XML-based frameworks to get the
abstraction capabilities they needed. So, people abstract anyway, the
only question is whether they do it in the language or outside.

I'm reminded of the spoof interview with Bjarne Stroustrup where he says that he created C++ to create work for programmers. I think part of the popularity of Java is that people to get to create monstrous quasi languages on top called frameworks. If someone really created the perfect general purpose programming language, it would rather spoil all the other would be language designers fun.

Maybe a possible path would be to have a language with only modest
abstraction capabilities but lots of features. That way, users would
not bother to write their own abstractions because there already was a
well-supported feature that did the same thing. That's sort of like
C#: In terms of feature count it is much larger than Scala, but its
users seem to complain a lot less about complexity; it seems they are
quite happy with the plethora of features they are given.

C# is part of the .Net Visual Studio eco system, so it has a huge budget, which really helps for documentation and testing. It shouldn't be surprising that C# can keep its user base happy. Its inevitable that the bar for Scala is going to be a lot higher. Early adopters are inevitably far more self opinionated. However I do think Scala has made some wrong choices notably in the collections library, which has created extra complexity. But I see no reason to apologise for this. Things can only be learnt through experimentation. But not just experimentation, there needs to be a certain pig headedness. An approach might seem like a mistake, but requires someone to keep banging at it before it finally gets to to be really usable. Sometimes a break though happens because someone keeps pushing their intuition long after everyone else had written it off.

This is an excellent insight. Java was created by a well funded team at Sun Microsystems, and now has the resources of Oracle behind it. C#/.NET has the resources of Microsoft behind it.

What I find interesting is that even though Microsoft has all the experience of Java to learn from, they still botched a lot of things in C#/.NET because Microsoft has a very different philosophy than Sun did. Some things in C# were better than Java, but overall I still find Java a more productive development environment.

Scala suffers from the fact it does not have entities like Oracle or Microsoft funding it.

But it won't be me designing such a language, because trading
abstraction capabilities for basic features is exactly the opposite of
my design philosophy. My design philosophy is more like free speech.
We protect it even if it is abused. In fact free speech would be a
fiction if there were no abuses. In the same way, abstraction
capabilities would be a fiction if there was no over-abstraction. I
completely agree this approach comes with challenges. It is our
responsibility as good engineers to realize that abstractions have
benefits as well as costs, and to collectively develop designs where
the benefits exceed the costs.

Best,

 - Martin

Well Said!

I could be wrong but my sense is that Spark is the long awaited Scala killer App. I see Scala is up to 24 on Tiobe. If I'm right then love it or hate it Scala is about to arrive.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Eric Kolotyluk
In reply to this post by Simon Ochsenreither-3
Usually my despair is when I am trying to understand some new Scala-based thing, that is poorly tested, poorly documented, poorly explained, etc.

I agree we have learned many useful things in the laboratory that is Scala, but sooner or later it would be nice if these things were repackaged in a form that is practical and not only experimental.

My main problem with reactive streams is that they are poorly explained. People are too focused on building, and not putting enough effort into explaining things that well. As I said in another post: During the Scala Reactive course, I was able to build example code that demonstrated the mechanisms much better than the course materials. It's not that it's hard to explain reactive streams, it just not a priority. Someone really needs to pay for some good tech writers to build better training materials, and to challenge the designers to create better designs.

Cheers, Eric

On 2015-11-04 10:25 PM, Simon Ochsenreither wrote:
I think you should not despair. Scala has always been a bit ahead of times, and while there are always steps back, the larger ecosystem of languages and libraries catches up.

In the beginning, Scala shipped with traits, uniform access to values/methods, (companion) objects, and the claim that a language can have good support for both OO and FP.
All of this could have been considered experimental, eccentric or exotic, but if we look at the new crop of languages as well as many old ones, they are all picking these things up.
While I have many disagreements with Martin, he has been an excellent steward of the language, and always keeps the practical application in mind, not only the academic purity.

Although much of the work now, and in the immediate future looks researchy and academic, but has an profound impact on practical engineering:
Take the work on TASTY as an example: Scala is one of the few languages and the only one on the JVM which invests a lot of thought into making compatibility and cross-compilation feasible. No other language has this even on their radar right now!
Take the work on macros and scala.meta: People are pushing the boundaries pretty hard in Scala to make these things practical, whereas many earlier attempts in other languages fell short of having a worthwhile impact.
Take the work on dotty: I didn't believe that the fusion of compiler phases was possible in practice, and people pulled it off. This is a huge advance in compiler design outside of compilers for toy languages.
Take the work on the SBT server: Lots of fancy flow charts and indirections, but in the end it will allow people to have multiple clients like IDEs, build tools, manual input via the SBT console working concurrently without getting into each others way.

I think in ten years people will say that all of this was obvious, but it took some determined Scala people to work hard to bring these new advances into a shape usable by developers.

Of course there are issues:
I think JavaDoc/ScalaDoc style documentation is a lot less useful in Scala than in other languages. This is a problem.
The rapid development causes a lot of churn, because people figure out new ways to make their libraries safer/faster/easier to use.
Standardization can only help so much, because ossification of APIs shipped in the standard library is a huge issue if you apply the standards most Scala developers have.
There is a mismatch in expectations; many people look for a slightly nicer Java, and while Scala certainly provides this, it has so many more improvements that it can cause irritation, because most Scala people think that we can do much better and need to do much better than just having a slightly nicer Java.

If you had issues with Reactive Streams, I think the people working on it would be happy to hear the experience you had with it!
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Simon Ochsenreither-3

I agree we have learned many useful things in the laboratory that is Scala, but sooner or later it would be nice if these things were repackaged in a form that is practical and not only experimental.

How would that look like? Sadly what I see is that most languages just adopt either whatever Scala did or something worse (usually 10 years after Scala shipped it).
Do you have an example where an experimental feature in Scala shipped in a more practical form somewhere else?

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Naftoli Gugenheim
In reply to this post by Eric Kolotyluk


On Thu, Nov 5, 2015, 6:25 PM Eric Kolotyluk <[hidden email]> wrote:

It would be odd if all our experiences matched Martin, and it is serendipitous that some do :-)

I would agree that abstraction can be a fundamental problem at times. Not everyone handles abstraction with equal skill and ease. There is much we could do to make it easier for more people to deal with the abstraction better.

For example, it made sense in Scala to replace the for-loop with the for-comprehension, but it is very much harder for some of us to keep our heads wrapped around the for-comprehension. The for-comprehension is an abstraction of map and flatmap. There is a lot more going on behind the scenes that a for-loop. While I can write code with correct for-comprehensions, it still takes me significantly more mental effort that writing a for-loop in Java.

The problem with abstraction is that, often too much of the actual mechanism is being hidden by elegant looking code, that it becomes harder to reason about the code. For example, one of my pet peeves is using for-comprehensions to deal with future values. Not only are the map and flatmap mechanisms hidden, but all of the concurrent mechanisms are too. It becomes hard to wrap your head around it without significant practice, and if your are new to the concept, well then you have no practice at all. For example, it is really easy for a novice to accidentally try to assign the expressions generating the future values within the for-comprehension itself. You 'just have to know' to assign the expressions to future vals before the for-comprehension because there is nothing in the code to show any problem, the Scala compiler will too happily do what you say and not what you want.

While it is indeed a common mistake, and documentation should be improved, I don't agree that it's a "you just have to know." If the value produced by previous future is in scope, that's proof that it has completed.
I think part of the reason people don't think of that, it's they're trying to use something without a clear understanding of it. Which is fine, but let's recognize that.

In particular, what I find too often challenging in reading Scala code and APIs is these 'you just have to know' moments. This is especially true when dealing with futures, promises, and other reactive mind puzzles.

There are various ways you could go. You could create a language that is more 'feature rich' to reduce the abstraction, but I am not advocating that.
You could improve the training materials, but this requires scarce resources.Sadly the Scaladoc is generally of little help in understanding important APIs, and I do not sense any urgency in the community to produce better Scaladoc.
While the first Coursera course I took was excellent, the second Coursera course was especially frustrating because Erik Meijer is simply not as good at explaining things as Martin and Roland are. I am sure Erik is a wonderful person, but he is not great at explaining things.When I went to other web sites to trying to understand reactive streams, the explanations were just as atrocious.In the course I actually had to experiment with some code to understand what was really going on in Assignment 4. I published my example in the discussion group. Several other students thanked me because it really helped them understand what was mechanically going on. Basically I solved the problem of poorly explained abstraction by creating an example to clearly demonstrate the concrete mechanics. This is something that Erik or someone else should have done before the course. I wish I could find someone to pay me to write Scala training materials.
You could build more diagnostic intelligence into Scalac to perform better static analysis. For example:Warning, you have written a for-comprehension with expressions producing Future values that should probably be computed prior to the for-comprehension. For example (followed by a clear example what to do). You could even change scalac to do the right thing in the first place, but I am not enough of a compiler expert to know how hard that would be to do, and the other dangers it would create.

There's no way to know that. Very often you specifically *want* it to run subsequently.

Basically I am not asking anyone to abandon their design philosophy around using abstraction, but only to think more about the problems that are created and finding solutions to those problems too. Think more like Alan Cooper did.

I will leave you with this. When the automobile was invented, few really cared about the problems it created. Millions of people have died in automobile accidents, and now our entire planet is in peril because of climate change. Many of the automobile's problems were finally addressed when Ralph Nader came on the scene, and many more have not been addressed. Computing Science and Software Engineering have not seen their Ralph Nader yet, and we continue to forge ahead without really appreciating the unintended consequences of our actions.

Cheers, Eric

P.S. Implicit really should be removed from the language. It causes more problems than it solves

How many problems does it solve?

by creating even more of those 'you just have to know' moments. I really hate reading examples people write because you generally cannot copy and paste them to get a working example as they almost never declare the hidden implicits the example depends on. It is generally impossible to convince everyone to actually test their code examples before publishing them. IMHO, implicit was one of the worse features added to Scala, and I hope it gets removed from Dotty.

On 2015-11-05 12:02 AM, martin odersky wrote:

Thanks for your input, Eric. It's interesting to me because some parts of it match my experience and others don't. I believe the fundamental issue we are grappling with is abstraction. In terms of features, core Scala is actually not that big a language. Core Scala means: excluding things that are experimental or require a special language import. And Dotty will further shrink the footprint. If you do think that there are features we could do without, I'd like to hear about them. But Scala is a language with powerful abstraction and composition capabilities. And these are used a lot, and undoubtedly they are also sometimes overused. Abstraction is a tricky business because it gives us the power to create new things and often one person might not like the things another person creates. So, it seems to me the only way to avoid the misuses you refer to is to remove abstraction capabilities from the language. Turn it into a pre-generics Java, so to speak. But that is difficult, because almost everyone craves abstraction capabilities; witness that pre-generics Java which did not have much of it, where people resorted to horrible XML-based frameworks to get the abstraction capabilities they needed. So, people abstract anyway, the only question is whether they do it in the language or outside. Maybe a possible path would be to have a language with only modest abstraction capabilities but lots of features. That way, users would not bother to write their own abstractions because there already was a well-supported feature that did the same thing. That's sort of like C#: In terms of feature count it is much larger than Scala, but its users seem to complain a lot less about complexity; it seems they are quite happy with the plethora of features they are given. But it won't be me designing such a language, because trading abstraction capabilities for basic features is exactly the opposite of my design philosophy. My design philosophy is more like free speech. We protect it even if it is abused. In fact free speech would be a fiction if there were no abuses. In the same way, abstraction capabilities would be a fiction if there was no over-abstraction. I completely agree this approach comes with challenges. It is our responsibility as good engineers to realize that abstractions have benefits as well as costs, and to collectively develop designs where the benefits exceed the costs. Best, - Martin On Thu, Nov 5, 2015 at 6:50 AM, Eric Kolotyluk [hidden email][hidden email][hidden email] wrote:

On 2015-11-04 1:32 PM, martin odersky wrote: On Wed, Nov 4, 2015 at 9:02 PM, Eric Kolotyluk [hidden email][hidden email][hidden email] wrote: Interesting claim by James Strachan. Very honest and sensible. After playing around with Java FX Script for a while I was astonished that the team at Sun Microsystems invented 'yet another language' that had many of the features of Scala, but was far less well developed than Scala. I, and others, complained about this openly, and now Java FX Script has expired, while Scala FX is a better replacement. Years before when I learned Groovy, my sense was that it was a better Java, and I really enjoyed it. After that I tried to learn Scala, and hurt myself so badly, it took over a year to take another try at it. Since then, I find that Scala is like a better Groovy, and a much better Java in many ways, but... At the same time, Scala is very similar to my experiences with C++ where C++ was supposed to be a better C. When Java first came out, I immediately abandoned C++ as being a waist of time, realizing that Java was a much better C than C++ could ever be. After 20 years of using Java I am still convinced that Java is astonishingly better than C++, but almost glacial in its evolution. My ultimate hope is some new language will come along that replaces Scala the way Java replaced C++. The most valuable thing about C++ was that it was full of lessons on how not to design a language. Similarly, Scala has many good lessons on how not to design a language. My sense of Scala is that it is the 'Kitchen Sink' language that James Gosling once talked about. My other sense is that Martin Odersky was quite brilliant in the original intent of Scala, far better than Bjarne Stroustrup was at C++, but there have been so many other cooks in that kitchen since then that Scala is now a very disturbing 'kitchen sink' indeed. While I personally enjoy writing code in Scala, I thoroughly hate reading most other people's Scala code. While I love many of the APIs in Scala, I thoroughly hate most of the others. Scala takes me to the extremes of my emotions like no other programming language I have ever used. The main problem I see with the Scala community these days is most people are too focused on adding new and 'clever' features, and too few are focused on actually cleaning up the mess. I have seen advances in Computing Science through Scala like no other language before it, but there really needs to be a new language to replace it. Scala is a really awesome playground for ideas and innovation, but I have recently concluded that it is too dangerous and unwieldy for practical software engineering solutions. I really look forward to the next new language to replace Scala. If anyone has any recommendations, please let me know. Thanks for the frank assessment, Eric! I do hope that with Dotty, the "Scala.next" effort, we can clean up some of the more contentious points of Scala. If you have some specific input what you think we should address, I'd like to read it! - Martin I tried following Dotty, but it is hard to see how to get started as everything is still very raw (uncooked). In particular, what is the difference between a Dotty program and a Scala one? Is there a Dotty primmer? I will think more about specific input, but for now here is my general sense. From an Architecture Astronaut perspective, the challenges mere mortals face in using Scala reminds me very much of "The Inmates Are Running The Asylum" by Alan Cooper. Largely the design and implementation of Scala and the accompanying ecosystem has been intended by Scala experts for Scala experts, and this pattern has tended to recurse upon itself like microphone feedback at a concert, producing some horrible noise at times. This was also much of the failing of C++ where Bjarne Stroustrup et al just seemed to feed off of ever more innovative and clever design tricks without regard for real world programmers. The real genius that James Gosling and crew brought to Java was simplifying things enormously, while adding to Java the important things missing from C, well aware of the dangers of C++. In part their goal was to bring programming to the masses, the way Steve Jobs brought personal computers to the masses. While Steve Jobs democratized computers, James Gosling democratized programming. This is really the heart of what Alan Cooper is getting at: Software engineers try very hard to make their software easy to use. They believe that their products are as easy to use as is technically possible. As engineers, their belief is in technology. They see power and flexibility, richness of features and functionality in their software. What they don’t see is how difficult their software is to use for people who use it on a daily basis. As such, it is hard for them to see clearly the nature of the problems plaguing the software industry. The result is what Cooper calls “Dancing Bearware”. If one saw a dancing bear on the street, we would be amazed not because the bear dances well, but that the bear dances at all. Cooper likens this to software today in that people will overlook interaction problems because the software performs its function, albeit problematically and inefficiently. -- Tim Renczes In essence, some of the people driving the evolution of Scala are building what they want, without clear evidence of what the end users actually need. When I was at Kodak I did a lot of User Interface Design and Implementation in Java/Swing. I think I was above average at it, but eventually I discovered other people (outside our team) who were recognizably much better than I. The point was, even though I tried to provide a lot of design leadership for our particular product, it was a lot like herding cats. Too often, other developers (like cooks in the kitchen) invented their own patterns, beaming with pride over their innovations, regardless of established principles, norms and conventions. Generally, developers designed and implemented what they liked rather than what our customers needed. I myself fell prey to this indulgence from time to time. We did some usability testing before finalizing a few important designs. I myself conducted some tests. They were very time consuming to set up and run, but they did reveal some bad patterns in our design attempts. There in lies the problem. It is way more fun and less expensive to just write code than to go to all the trouble to understand user's actual needs. The mathematical basis for Scala is remarkably beautiful at times, but most humans cannot appreciate the beauty of mathematics, especially at the higher levels, let alone use it. What Scala is lacking is the psychological basis for normal human cognition, rather than the cognition of a small group of computing science savants. After learning BASIC, FOCAL, FORTRAN, PL/1, APL, etc., when I finally learned Pascal I was in shock. While Pascal did not have all the bells and whistles of other languages, it was so much easier to write good code, and understand other people's code. When I finally had to start using C in production, I felt it was a huge step backwards from Pascal. Much of the success of Pascal was because Niklaus Wirth intended it to promote good programming practices, where Dennis Ritchie was more intent on other issues than good programming practices. It is fair to say that many of the Scala design features do promote good programming practices, most notably functional programming. However, my sense is that many other features of not only the Scala language, but the Scala ecosystem are more intended to satisfy the hacking desire of some people more intent on just having fun, without the sense of what normal software developers really need. My recent excursions into Reactive Streams has been a nightmare of WTF experiences. My experience when I am writing Scala code is that I am constantly referring to reference materials. The language, features, and concepts are so much bigger than Java, I simply do not have enough RAM in my old brain to write code without constant paging. When I read some other people's Scala code, or worse their APIs, then my cognitive paging system starts thrashing, resulting in WTF paralysis, and my verbal synthesis framework executes the 'halt and catch fire' instruction. I think what is needed is a new language, Scala-like perhaps, but designed more from a software engineering and human psychology perspective. There should be psychological and engineering, or ergonomics testing of critical ideas and concepts. By all means, all that has been learned from Scala should be considered, but the goal should be to consider the 'normal' end user (software developer) first. Advances in programming language design are like a pendulum that swings between radically innovative to the pragmatically safe, and back. Scala has become a little too radical for practical use. Cheers, Eric - Eric On 2015-11-04 6:50 AM, Oliver Ruebenacker wrote: Hello, "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." -- James Strachan, inventor of Groovy Clojure? Sure, if you like Lisp. Best, Oliver On Wed, Nov 4, 2015 at 9:29 AM, Aseem Bansal [hidden email] wrote: Can someone give any inputs on https://www.reddit.com/r/scala/comments/3rhu5n/why_scala_not_groovy_or_clojure/ Asked a similar question from Clojure community https://www.reddit.com/r/Clojure/comments/3rcjus/new_clojurians_ask_anything/cwmue2n -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email][hidden email]. For more options, visit https://groups.google.com/d/optout. -- Oliver Ruebenacker Senior Software Engineer, Diabetes Portal, Broad Institute -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email][hidden email][hidden email]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email][hidden email]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email][hidden email]. For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email][hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why Scala not groovy or Clojure?

Alan Burlison
In reply to this post by Eric Kolotyluk
On 05/11/2015 23:25, Eric Kolotyluk wrote:

> P.S. Implicit really should be removed from the language. It causes more
> problems than it solves by creating even more of those 'you just have to
> know' moments. I really hate reading examples people write because you
> generally cannot copy and paste them to get a working example as they
> almost never declare the hidden implicits the example depends on. It is
> generally impossible to convince everyone to actually test their code
> examples before publishing them. IMHO, implicit was one of the worse
> features added to Scala, and I hope it gets removed from Dotty.

I utterly disagree. Much of the power of Scala comes from the
(appropriate) use of implicits. Yes they can be abused, but that's the
same as any other language feature.

--
Alan Burlison
--

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
123