The right tool

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The right tool

Niels Hoogeveen
James MacIver started a programming language comparison, based on an internet survey containing many questions. Given the number of responses (more than 10,000 for Scala at this time of writing), I must assume many on this list have already found the survey.

While most of the responses are not at all surprising (Scala ranks high on the coolness axes), there were a few outcomes I found hard to place.

Scala scores relatively high on the statement: "This language is large". I would think a language like COBOL is large. Scala may have a very sophisticated type system, but by itself is not that big a language, yet it is perceived to be one. Likewise Scala scores low on the statement "This language is minimal".

Another striking outcome to me was the high ranking on the statement: "This language is unusually bad for beginners", and the low ranking on the statement: "This language is good for beginners".
Again I tend to see this more as a perception of the language, other than an actual fact about the language.

Scala scores poorly on the statement: "Programs written in this language will usually work in future versions of the language". While growing the language to version 2.8 needed several breaking changes, this is certainly one of the perceptions that, in my opinion, needs to change for Scala to become widely adopted.
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Paul Phillips-3
On Mon, May 17, 2010 at 01:30:04PM -0700, Niels Hoogeveen wrote:
> Another striking outcome to me was the high ranking on the statement:
> "This language is unusually bad for beginners", and the low ranking on
> the statement: "This language is good for beginners". Again I tend to
> see this more as a perception of the language, other than an actual
> fact about the language.

Scala is unusually bad for beginners.  The only way I can kid myself
otherwise is if I imagine a significantly more mature implementation.  
As it stands, languages which have been around much longer are likely to
have far superior error messages and documentation and fewer bugs and
corner cases: all things which greatly impact the beginner experience.

Ignoring specifics, the intersection between "research language pushing
the boundaries of type systems and programming paradigms" and "better
than average for beginners" is objectively tiny at best.

> Scala scores poorly on the statement: "Programs written in this
> language will usually work in future versions of the language". While
> growing the language to version 2.8 needed several breaking changes,
> this is certainly one of the perceptions that, in my opinion, needs to
> change for Scala to become widely adopted.

I don't think we should worry about this perception.  We should worry
about this reality!

--
Paul Phillips      | Adultery is the application of democracy to love.
Stickler           |     -- H. L. Mencken
Empiricist         |
i pull his palp!   |----------* http://www.improving.org/paulp/ *----------
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Erik Engbrecht
In reply to this post by Niels Hoogeveen
I think Scala is very large compared to languages like Python or Java, but smaller than C++.
 
By "large" I mean there are a lot of concepts in the language.  Just to list a few that aren't in Java...
  • Higher kinded types
  • objects (as in the scala object construct)
  • by-name method parameters
  • companion objects
  • case classes
  • structural types
  • closures / first-class functions
  • for comprehensions
  • mixin composition / multiple inheritence
  • self types
  • type inference
  • currying
  • pattern matching (and associated unapply etc support machinery)
  • loose syntax for some language constructs, e.g. dropping parenthesis
  • specialization
  • operator overloading
  • multiple parameter lists for methods
  • parameter lists that come before the method name (colon prefixed operators)
  • implicits (parameters, conversions, values)
  • stable ids vs non-stable ids
  • default arguments
  • lazy values
  • added access qualifiers (e.g. private[this])
  • XML as-a-language construct
  • ...and I'm probably forgeting some...
So what does it drop from Java:
  • static members
  • field / method dichotomy
  • object / primitive dichotomy
Someone is probably going to find issues with my list, but the truth is Scala is a big language.  And if you look at it from the point-of-view of a Java developer, all the functional aspects of the collections and XML library are going to seem like new, big language constructs, even if they aren't really.
 
On Mon, May 17, 2010 at 4:30 PM, Niels Hoogeveen <[hidden email]> wrote:

James MacIver started a  http://therighttool.hammerprinciple.com/ programming
language comparison , based on an internet survey containing many questions.
Given the number of responses (more than 10,000 for Scala at this time of
writing), I must assume many on this list have already found the survey.

While most of the responses are not at all surprising (Scala ranks high on
the coolness axes), there were a few outcomes I found hard to place.

Scala scores relatively high on the statement: "This language is large". I
would think a language like COBOL is large. Scala may have a very
sophisticated type system, but by itself is not that big a language, yet it
is perceived to be one. Likewise Scala scores low on the statement "This
language is minimal".

Another striking outcome to me was the high ranking on the statement: "This
language is unusually bad for beginners", and the low ranking on the
statement: "This language is good for beginners".
Again I tend to see this more as a perception of the language, other than an
actual fact about the language.

Scala scores poorly on the statement: "Programs written in this language
will usually work in future versions of the language". While growing the
language to version 2.8 needed several breaking changes, this is certainly
one of the perceptions that, in my opinion, needs to change for Scala to
become widely adopted.
--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/The-right-tool-tp2220305p2220305.html
Sent from the Scala mailing list archive at Nabble.com.



--
http://erikengbrecht.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala] The right tool

Michael Fogus
> James MacIver

Is that an amalgam of David MacIver and James Iry? Now that is a truly awesome beast! ;-)

> Scala scores relatively high on the statement: "This language is large".

Having a background in Lisp languages followed by C++, into Java, then Scala and Python I have to say that Scala is easily the "largest" language that I've used. I'm not sure if the survey consensus views that as a negative or not. It definitely can be a negative to a newcomer as conceptual load is a valid concern.

> would think a language like COBOL is large. Scala may have a very
> sophisticated type system, but by itself is not that big a language, yet it

I would view COBOL as large -> unwieldy. Scala is large -> comprehensive. Again, to the neophyte the distinction may be blurred.

> is perceived to be one. Likewise Scala scores low on the statement "This
> language is minimal".

Understanding how Scala is put together, I can see that this statement is only half true. While much of the big functionality lays in libs, to a user there is very little difference between language features and libs that look like language features.

> Another striking outcome to me was the high ranking on the statement: "This
> language is unusually bad for beginners", and the low ranking on the
> statement: "This language is good for beginners".

I guess it depends on the beginners' background. Coming from a Java/Lisp background most of the basics of Scala were pretty agreeable. I can't speak for someone else though.

> Again I tend to see this more as a perception of the language, other than an
> actual fact about the language.

Maybe you're right, but what's the difference?

> Scala scores poorly on the statement: "Programs written in this language
> will usually work in future versions of the language".

Having built a fairly large project starting with 2.7.1 (maybe 2.7.2... I'd have to check) and up to the current, I'd have to agree with this one. It's at times not been pretty for us.
:f
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Colin Howe-2
In reply to this post by Erik Engbrecht
I agree that Scala is large. But, I think most of it isn't used every day. Many features are useful in niche situations - most of the time you use a core set of features. Maybe we could do more to highlight core features - people can then be productive quickly and afterwards learn more features to make themselves more awesome.

Discovery could be a problem. It's hard to google what unfamiliar code is doing if you don't know the magic words. A tool to help with this might be valuable:
  • Paste a snippet of code in to the tool
  • The tool tells you what magic is happening and gives links to more information - e.g. it will highlight self-types, colon-prefixed operators, etc.

We shouldn't beat ourselves up too much - we're 3rd in top languages for enjoyment :-)


Cheers,
Colin


On Mon, May 17, 2010 at 9:49 PM, Erik Engbrecht <[hidden email]> wrote:
I think Scala is very large compared to languages like Python or Java, but smaller than C++.
 
By "large" I mean there are a lot of concepts in the language.  Just to list a few that aren't in Java...
  • Higher kinded types
  • objects (as in the scala object construct)
  • by-name method parameters
  • companion objects
  • case classes
  • structural types
  • closures / first-class functions
  • for comprehensions
  • mixin composition / multiple inheritence
  • self types
  • type inference
  • currying
  • pattern matching (and associated unapply etc support machinery)
  • loose syntax for some language constructs, e.g. dropping parenthesis
  • specialization
  • operator overloading
  • multiple parameter lists for methods
  • parameter lists that come before the method name (colon prefixed operators)
  • implicits (parameters, conversions, values)
  • stable ids vs non-stable ids
  • default arguments
  • lazy values
  • added access qualifiers (e.g. private[this])
  • XML as-a-language construct
  • ...and I'm probably forgeting some...
So what does it drop from Java:
  • static members
  • field / method dichotomy
  • object / primitive dichotomy
Someone is probably going to find issues with my list, but the truth is Scala is a big language.  And if you look at it from the point-of-view of a Java developer, all the functional aspects of the collections and XML library are going to seem like new, big language constructs, even if they aren't really.
 
On Mon, May 17, 2010 at 4:30 PM, Niels Hoogeveen <[hidden email]> wrote:

James MacIver started a  http://therighttool.hammerprinciple.com/ programming
language comparison , based on an internet survey containing many questions.
Given the number of responses (more than 10,000 for Scala at this time of
writing), I must assume many on this list have already found the survey.

While most of the responses are not at all surprising (Scala ranks high on
the coolness axes), there were a few outcomes I found hard to place.

Scala scores relatively high on the statement: "This language is large". I
would think a language like COBOL is large. Scala may have a very
sophisticated type system, but by itself is not that big a language, yet it
is perceived to be one. Likewise Scala scores low on the statement "This
language is minimal".

Another striking outcome to me was the high ranking on the statement: "This
language is unusually bad for beginners", and the low ranking on the
statement: "This language is good for beginners".
Again I tend to see this more as a perception of the language, other than an
actual fact about the language.

Scala scores poorly on the statement: "Programs written in this language
will usually work in future versions of the language". While growing the
language to version 2.8 needed several breaking changes, this is certainly
one of the perceptions that, in my opinion, needs to change for Scala to
become widely adopted.
--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/The-right-tool-tp2220305p2220305.html
Sent from the Scala mailing list archive at Nabble.com.



--
http://erikengbrecht.blogspot.com/



--
Website: http://www.colinhowe.co.uk
Twitter: http://twitter.com/colinhowe
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

James Iry-2
In reply to this post by Niels Hoogeveen
That would be David.  While he credits a conversation with me as being part of the inspiration, the vast majority of the inspiration and certainly 100% of the perspiration are his. 

Also, contrary to any rumors you may have heard, he and I are not planning to have any children.

On Mon, May 17, 2010 at 1:30 PM, Niels Hoogeveen <[hidden email]> wrote:

James MacIver started a  http://therighttool.hammerprinciple.com/ programming
language comparison ,
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Niels Hoogeveen
Oops...
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Niels Hoogeveen
In reply to this post by Paul Phillips-3
Scala is unusually bad for beginners.  The only way I can kid myself otherwise is if I imagine a significantly more mature implementation. As it stands, languages which have been around much longer are likely to have far superior error messages and documentation and fewer bugs and corner cases: all things which greatly impact the beginner experience.

Ignoring specifics, the intersection between "research language pushing the boundaries of type systems and programming paradigms" and "better than average for beginners" is objectively tiny at best.


I think there are two aspects to the notion of being unusually bad for beginners.

1) the implementation
2) the language itself

I agree with your observation that the implementation is not in a mature enough state that all corner cases are ironed out and all error messages make complete sense.

In that sense the perception that Scala is not a good "beginners" language makes perfect sense and is something that can be improved upon.

When looking at those languages that are considered good "beginners" languages, the top positions are all taken by languages with a dynamic type system. So it's my contention a good "beginners" language is mostly perceived as a language that has a shallow initial learning curve.

The simplicity of the language is not necessarily something that can easily be improved upon. Some of the Scala concepts (contra-variant subtyping comes to mind) are not that easy to grasp, but at the same time many applications can be written without the explicit use of some of the higher level features.

It's my experience that it is actually pretty easy to write relatively simple code in Scala. It may be hugely difficult to write something like the collection class library, requiring all advanced features in the book, but it is relatively simple to use them, something most programmers in the field actually do.

With lots of blogs and articles dealing with advanced features the impression may have grown that Scala is a difficult language with a steep learning curve. It's my experience that the learning curve is not necessarily steep, but mostly long. Understanding all features is a daunting task, but for most programmers not all these features are necessary to write perfectly functional code.

So maybe the Scala community could do itself a favour and present Scala as much as an easy to use language as well as a language that has advanced features worthy of academic study.



I don't think we should worry about this perception.  We should worry about this reality!

Agreed, and fortunately it is a perception that can be improved by improving reality.
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Michael Fogus
> When looking at those languages that are considered good "beginners"
> languages, the top positions are all taken by languages with a dynamic type
> system. So it's my contention a good "beginners" language is mostly
> perceived as a language that has a shallow initial learning curve.

I think this is the most poignant comment that can be made about this.
 I would content that dynamic /= simple, but I don't think that was
the crux of your point.  Scala code can be made to look and work
almost exactly like Java so in that respect for a large population of
programmers it has a very small initial learning curve.  However, I
think people experience confusion as they learn more about it!
Writing Java-flavored Scala is not writing Scala and people learn that
as they come across people actually writing Scala.  In some ways I
think that Scala is a victim of its own fantastic interop story.

:f
Reply | Threaded
Open this post in threaded view
|

[scala] Re: The right tool

ob-2
In reply to this post by Paul Phillips-3
* Paul Phillips <[hidden email]> [2010-05-17 22:48 CEST]:
> On Mon, May 17, 2010 at 01:30:04PM -0700, Niels Hoogeveen wrote:
>> Another striking outcome to me was the high ranking on the statement:
>> "This language is unusually bad for beginners", and the low ranking on
>> the statement: "This language is good for beginners". Again I tend to
>> see this more as a perception of the language, other than an actual
>> fact about the language.

> Scala is unusually bad for beginners.  The only way I can kid myself
> otherwise is if I imagine a significantly more mature implementation.  
> As it stands, languages which have been around much longer are likely to
> have far superior error messages and documentation and fewer bugs and
> corner cases: all things which greatly impact the beginner experience.

I don't think Scala is that bad for beginners. We are teaching Java at
the moment for first-year university students "Business Informatics".
But I am considering switching to Scala. What they should learn in the
first year are things like:

- what is a variable
- what is if-then-else
...
- what is a function
...
- what is an object
- what is a class
...
- what is inheritence
- what is polymorphism
...

I think that Scala would serve in a much better way, didactically, in these
fields, because:

- there is a interactive shell (REPL)
- you don't have to write class Bla { public ... main { System... in
  order to print "Hello World", just println("Hello World") as single
  line in a file is enough
- there are no primitive datatypes, no static members, a unified object
  model
...
and a lot more.

And the key feature for my students: Programming in Scala is much more
fun than programming in Java.

And in the end it is a comparatively small step to Java for them.

Just my 2ct

Regards
         Oliver

--
Prof. Dr. Oliver Braun -- http://pads.fh-schmalkalden.de/

Reply | Threaded
Open this post in threaded view
|

Re: [scala] Re: The right tool

Colin Bullock

I don't think Scala is that bad for beginners. We are teaching Java at
the moment for first-year university students "Business Informatics".
But I am considering switching to Scala. What they should learn in the
first year are things like:

Having recently reread The Little Schemer and thumbed through a bit of SICP just this morning, I can't help but wish longingly that my first introduction to programming had been a Lisp dialect.

Just my personal 2¢.
 
- Colin

dpp
Reply | Threaded
Open this post in threaded view
|

Re: [scala] Re: The right tool

dpp


On Tue, May 18, 2010 at 1:09 PM, Colin Bullock <[hidden email]> wrote:

I don't think Scala is that bad for beginners. We are teaching Java at
the moment for first-year university students "Business Informatics".
But I am considering switching to Scala. What they should learn in the
first year are things like:

Having recently reread The Little Schemer and thumbed through a bit of SICP just this morning, I can't help but wish longingly that my first introduction to programming had been a Lisp dialect.

FWIW, I tried to have a mostly-REPL experience in the first 5 chapters of Beginning Scala.  I also tried to stay away from "scary" concepts as much as possible in the first 5 chapters.  I was trying to write these chapters to make the library consumer side of Scala feel a lot like Ruby/Python.
 

Just my personal 2¢.
 
- Colin




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Reply | Threaded
Open this post in threaded view
|

[scala] Re: The right tool

ob-2
In reply to this post by Colin Bullock
Well, I started with Haskell and that is still my main language ;-)

* Colin Bullock <[hidden email]> [2010-05-18 22:09 CEST]:
> --0016367b6c724335bd0486e3ecd3
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

>> I don't think Scala is that bad for beginners. We are teaching Java at
>> the moment for first-year university students "Business Informatics".
>> But I am considering switching to Scala. What they should learn in the
>> first year are things like:


> Having recently reread The Little Schemer and thumbed through a bit of SICP
> just this morning, I can't help but wish longingly that my first
> introduction to programming had been a Lisp dialect.

> Just my personal 2=A2.

> - Colin

> --0016367b6c724335bd0486e3ecd3
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

><br>
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde=
> r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
> ft: 1ex;">I don&#39;t think Scala is that bad for beginners. We are teachin=
> g Java at<br>

> the moment for first-year university students &quot;Business Informatics&qu=
> ot;.<br>
> But I am considering switching to Scala. What they should learn in the<br>
> first year are things like:<br></blockquote><div><br>Having recently reread=
>  The Little Schemer and thumbed through a bit of SICP just this morning, I =
> can&#39;t help but wish longingly that my first introduction to programming=
>  had been a Lisp dialect. <br>
><br>Just my personal 2=A2.<br>=A0<br>- Colin<br></div></div><br>

> --0016367b6c724335bd0486e3ecd3--



--
Prof. Dr. Oliver Braun -- http://pads.fh-schmalkalden.de/

Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Martin Odersky
In reply to this post by Erik Engbrecht


On Mon, May 17, 2010 at 10:49 PM, Erik Engbrecht <[hidden email]> wrote:
I think Scala is very large compared to languages like Python or Java, but smaller than C++.
 
By "large" I mean there are a lot of concepts in the language.  Just to list a few that aren't in Java...

... I am always a bit uneasy when reading a list like this and arguing with it. Yes, Scala has a lot of features but it tries very hard to make them facets of a uniform core which is not that large. I realize that for a newcomer, in particular someone brought up in the C/Java tradition, Scala might look large. For instance, objects/companion objects which you mention. If you do an in-depth study of language specs, these are actually significantly simpler then Java's static class members. But static class members are known whereas companion objects are less well known, so they look more complex for most people.

Here's a discussion of the other features you mention, in comparison to Java.
  • Higher kinded types
Yes, that's definitely beyond Java. This is the one feature where for a long time I was not sure whether it is worth the weight. I have been leaning recently more towards believing that it will probably turn out to be quite useful.
  • by-name method parameters
vs special treatment of ||, &&, assert.
  • companion objects
vs statics (see above).
  • case classes
vs enums (arguably at least as complicated in both syntax and type checking).
  • structural types
Yes.
  • closures / first-class functions
Yes, until Java gets them, in which case Java's will be more complex, due to throws clauses.
  • for comprehensions
vs extended for-loops, looks like pretty much the same thing to me.
  • mixin composition / multiple inheritence
vs extends/implements. Again, you might argure that traits simply drop some restrictions in interfaces.
  • self types
yes, sort of. Again we simply drop a restriction in Java on the type of `this'.
  • type inference
Not sure that adds complexity per se. Java does it as well, but more clumsily. Have you looked at the
<> notation in Java 7? How is that simpler?
  • currying
You might say, we just drop a restriction that functions have only one parameter list...
OK I concede, it's a yes.
  • pattern matching (and associated unapply etc support machinery)
vs switches, which are getting more complex, and I always forget to put a break at the end of a case.
  • loose syntax for some language constructs, e.g. dropping parenthesis
Yes, but Java programmers have to learn that it's array.length, but string.length(). Not sure what is better.
  • specialization
That's an annotation-driven optimization. I don't think we should count that
  • operator overloading
Compared to the large number of synactically defined operators in Java I think that's a net win.
  • multiple parameter lists for methods
That's a duplicate of currying.
  • parameter lists that come before the method name (colon prefixed operators)
You mean colon-suffixed, right? yes.
  • implicits (parameters, conversions, values) 
Yes, but they let us avoid a lot of special cases.
  • stable ids vs non-stable ids
Linked to abstract types, yes.
  • default arguments
Yes.
  • lazy values
Vs special static member initialization, which also has lazy semantics.
  • added access qualifiers (e.g. private[this])
Vs dropping package level visibility.
  • XML as-a-language construct
Yes. That's the second extension where in retrospect I am not sure it was a good thing overall. When we started out with Scala, XML was the showcase where functional programming could be clearly shown to be useful. At the time most people thought you could do everything with pure OOP. So we added XML.. Today, the case for FP is much stronger, and the case for XML has gotten weaker. So maybe the inclusion of XML in Scala was a historical accident. But anyway, it's in, and will stay in.
  • ...and I'm probably forgeting some...
So what does it drop from Java:
  • static members
  • field / method dichotomy
  • object / primitive dichotomy
I think you seriously underestimate the complexities in Java. Just some points, it's far from an exhaustive list

- 4 namespaces (methods/fields/types/packages) instead of two.
- different name resolution rules for each namespace.
- enums
- annotations (yes Scala has them as well but they are much, much simpler than Java's)
- some tricky syntactic corner cases to disambiguate between casts and expressions.
- nasty explicit parameterization. Does anyone even know how to pass a type parameter to a method in Java?
- over-reliance on wildcards, leading to very hard to diagnose type errors.
- restrictions on arrays with generics.
- raw types(!)
- restrictions that inner classes can only acces final members.
- super constructors.
- dataflow analyses for definite assigment and termination (these are actually useful, but burn about 20 pages in the spec).
- throws clauses and the rules governing them
- auto-boxing
- complicated rules what kind of casts are allowed where

A lot of these points look simple, but start to read up on their precise rules, they are anything but.

I don't want to get into a feature to feature comparison between languages. My main point is, that, if you draw up a list of bullet points you can make any language look forbiddingly complex.
 
I certainly agree that if Java is your point of departure, then there is a lot of new stuff to learn in Scala. My argument is that there is also a lot of stuff in Java that people take more or less for granted but that is pretty complicated under the covers (and I argue from quite intimate experience here).

Some measures: The grammar of Scala is actually smaller than the grammar of Java. The typechecker of Scala is about the same length in lines of code as the type checker for Java, or the type checker for Haskell. Of course, every type checker is written in its own language, so you can draw an infinite number of conclusions form that, all of the form:

  Scala's type system is X-times more complicated than Java's or Haskell's, but code written in the language
  is X-times more compact

where X ranges from 0 to infinity.

Cheers

 -- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Tony Morris
martin odersky wrote:
>    - Higher kinded types
>
> Yes, that's definitely beyond Java. This is the one feature where for a long
> time I was not sure whether it is worth the weight. I have been leaning
> recently more towards believing that it will probably turn out to be quite
> useful.
>  
Get rid of this and you get rid of me!

Higher kinds and implicits are the only reasons I use Scala over Java.
The rest is superficial and/or unnecessary afaic.

Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Randall R Schulz-2
On Tuesday May 18 2010, Tony Morris wrote:
> martin odersky wrote:
> >    - Higher kinded types
> >
> > Yes, that's definitely beyond Java. This is the one feature where
> > for a long time I was not sure whether it is worth the weight. I
> > have been leaning recently more towards believing that it will
> > probably turn out to be quite useful.
>
> Get rid of this and you get rid of me!

Never tip your hand like this.


> ...


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Dave Griffith
In reply to this post by Martin Odersky

>
>    - for comprehensions
>
> vs extended for-loops, looks like pretty much the same thing to me.

Well, that's clearly nonsense, by about a factor of 10.  General monadic constructions vs a simple bit of Iterable sugar.  I'm not saying that Scala's aren't also a factor of 10 better, but certainly much more difficult to deeply understand.   (Shallow understanding makes them look like SQL.  They aren't, but nonetheless things still work.  An excellent pun.)

>    - pattern matching (and associated unapply etc support machinery)
>
> vs switches, which are getting more complex, and I always forget to put a
break at the end of a case.

Again, much more complex and powerful, particularly with extractors, but it's worth it.
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Dave Griffith
>dataflow analyses for definite assigment and termination (these are actually useful, but burn about 20 pages in the spec).

Sad to say, but Scala really does need these.  It's a noticable gap in Scala that I can't say

val foo;
x match {
  bar => println("bar"); foo = 3; baz = foo+1
  _ => foo = 4; baz  = foo +2
}

or

def bar:Nothing = {
   while true{
     // do something imperative, with no returns but possibly throws or recursion
   }
}

In both these cases, the semantics is clear and precise, but the type system can't quite hack it.  That's fine if there's no reason to accept better, but this is the rare case where Java actually does it better.

--Dave
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Mark Harrah
On Tuesday 18 May 2010, Dave Griffith wrote:

>
> >dataflow analyses for definite assigment and termination (these are actually
> useful, but burn about 20 pages in the spec).
>
> Sad to say, but Scala really does need these.  It's a noticable gap in Scala
> that I can't say
>
> val foo;
> x match {
>   bar => println("bar"); foo = 3; baz = foo+1
>   _ => foo = 4; baz  = foo +2
> }

val (foo, add) =
  x match {
    case Bar => println("bar"); (3, 1)
    case _ => (4, 2)
  }
val baz = foo + add

> or
>
> def bar:Nothing = {
>    while true{
>      // do something imperative, with no returns but possibly throws or
> recursion
>    }
> }

def bar: Nothing = {
  // do something imperative
  bar
}

> In both these cases, the semantics is clear and precise, but the type system
> can't quite hack it.  That's fine if there's no reason to accept better, but
> this is the rare case where Java actually does it better.

That I've never missed either construct might not be representative, but regardless, I haven't missed them.

-Mark
Reply | Threaded
Open this post in threaded view
|

Re: [scala] The right tool

Andreas Kollegger
In reply to this post by Dave Griffith
As a new arrival to the scala party and run-of-the-mill coder, I'd
just like to comment that the language features may be daunting and
complex when read aloud but I dance a little dance every time
I run into a "well, how do I express this in scala" problem and then
discover the happy little answer.

For me, the ideas are natural and the challenge is just familiarizing
myself with the pedantic terminology. Currying? Fire up the tandoor.

We need a "Why the lucky stiff" to shout out how cool all this stuff is.

On May 18, 2010, at 8:51 PM, Dave Griffith wrote:

>
>
>>
>>   - for comprehensions
>>
>> vs extended for-loops, looks like pretty much the same thing to me.
>
> Well, that's clearly nonsense, by about a factor of 10.  General monadic
> constructions vs a simple bit of Iterable sugar.  I'm not saying that
> Scala's aren't also a factor of 10 better, but certainly much more difficult
> to deeply understand.   (Shallow understanding makes them look like SQL.
> They aren't, but nonetheless things still work.  An excellent pun.)
>
>>   - pattern matching (and associated unapply etc support machinery)
>>
>> vs switches, which are getting more complex, and I always forget to put a
> break at the end of a case.
>
> Again, much more complex and powerful, particularly with extractors, but
> it's worth it.
>
> --
> View this message in context: http://scala-programming-language.1934581.n4.nabble.com/The-right-tool-tp2220305p2222132.html
> Sent from the Scala mailing list archive at Nabble.com.

123