From Scala, back to Java

[ranjith]

OK I did not say it -
(Sorry to post a link, but it is worth it.)
http://alarmingdevelopment.org/?p=562

Dick, I am looking at you too..
Here is what Cedric beust said..
http://beust.com/weblog/2011/02/23/from-scala-back-to-java/

[Phil]

I read Jonathan's and Cedric's posts (and many of the comments) and
both to be balanced and informative (in contrast to some of the
comments). I don't think anybody would argue that a functional
language can be more complex than an OO one, but it is a shame that
the tools still seem to be lacking - something Cedric added more
detail around. Java was better served inside seven years but there are
still areas where the tooling is neglected or less than perfect.
Demand will elicit supply, so as any new language (it feels a bit
strange to refer albeit indirectly to Scala as a new language) gains
traction more people go looking for tools and a percentage of those
people will contribute to the tools themselves.

All said, Scala is still the functional language I will turn to when I
have the time to look at one in more detail. But sorry, Dick, I'm on
the wrong continent for training!

On Mar 21, 4:44 pm, ranjith <sen...@gmail.com> wrote:
> OK I did not say it -

> (Sorry to post a link, but it is worth it.)http://alarmingdevelopment.org/?p=562

[Casper Bang]

If Fantom gains true generics, hopefully it can attract some of those
that wants something more powerful than Java but not as advanced as
Scala. There's clearly a missing hybrid piece which Java/Oracle won't
fill and thus people jump to Scala - funny enough many of the same
people who have been claiming C# is too advanced.

[Reinier Zwitserloot]

I've never run into anyone that is holding off on Fantom because it lacks 'true' generics.

Scala's problem is that it tries to change too much, but Fantom's problem is that it doesn't change enough; no matter what people tell you, its fairly obvious (to me anyway, YMMV) that changing something as fundamental as the programming language, especially if that language prefers use of alternative (fantom / scala versions of) crucial java runtime classes such as ArrayList, is a gigantic step that will never be taken lightly. So, you need a lot of convincers, but at the same time, the _vast_ majority of programmers do not want to learn more than 1 language so have to feel like another language can make a new home for them based on some simplistic snippets and without knowing much about said language. So, the language has to be both filled with convincing arguments that it feels like real, meaningful progress, whilst at the same time looking like it'll be such a minor change that they'll know for sure they'll adapt easily to this new language.

Screwed if you do, screwed if you don't.

I've said it before, but if any contender to java's throne is to show up, it needs to come up with "leightweight" convincers, just like java did to C: Java took just about the entire C syntax, warts and all, and imported that part wholesale to lower the bar (i.e. to 'be like fantom'). It then added things that were worth a lot but didn't have a high impact on the language itself in order to convince C programmers to switch to it (i.e. to 'be like scala'): A garbage collector, write-once-run-anywhere, threading, networking, and many other fairly standard tasks all supplied by a universal standard library thus truly delivering on the 'platform independent' promise. As an encore, java simplified a number of things, including removing the preprocessor. Not sure if that made a real difference in the end, but keeping things simple (in fact, now we might argue java was a little _too_ simple) never hurt language uptake, unlike the reverse of course. Something as simple as looking at scala's collections API makes people run for the hills even though in practice those crazy type variables do work fine (.toMap(implicit) on the other hand....)

So, high impact stuff that doesn't complicate the language, that's what'll make java.next. What should this look like? Don't know - but I guess at least one of these will be involved:

 - A language that caters to DSLs not by making the syntax flexible but by standardizing the AST and Parser and making these pluggable, with a meta-notation to define which plugins are to be used for the sources itself. May or may not be paired by the notion that AST editing is the basic form (instead of 'stream of characters' like 99.99% of all programming today), and most likely will require adapting these plugins to be written with IDEs in mind.

 - A marriage between OSGi (i.e. runtime modularity), maven central (i.e. module repository), and gradle/ivy/maven (i.e. buildtime modularity) and better than all 3 combined, built into the language syntax. i.e. all you need to do is write "import guava.* from jigsaw://guava.google.com/guava/r8;" at the top of the file and the IDE will use one of the basic commands of the language's toolkit (just as basic as 'java' and 'jar') to resolve and download this dependency, and link it all up, sources included, in your IDE.

 - Be quite close at least at-a-glance to java syntax, just like java syntax looked virtually 100% the same as C code if you didn't look too close and picked examples that fit well, such as algorithms.

 - Yes, most likely this language _will_ have closures, even if only because excluding them means all the discussion will be about a perceived negative. Personally I do think java 1.1's anonymous inner classes were a mistake and should have been closures instead. It'll most likely also have collection literals and do away with a few annoyances.

 - A solution for sharing objects/structs provided by one library, between 2 libraries that each are dependent on a different version of that library. i.e. you want to share a guava ImmutableList between 2 libraries, but library one is at r7, the other is at r8. May involve some sort of nifty 'view' concept where an API can also export a bunch of wrapper methods that make it look like different API, while being represented 'under the hood' by the same batch of fields/struct so it can be transferred. Could be used to fix collections API while remaining compatible with that same API well enough to be able to pass (java.next) lists around to methods that want java.util.Lists without hassle.

 - Possibly will ship WITHOUT most of what we now consider a standard library, instead embracing the modularity concept fully and shipping instead with the knowledge that there's boatloads of libraries out there for you to import.... though I wonder if this will hit the right notes of trivially understood simplicity and power that are needed to become a new great language. I'm sure this part IS typically simple+powerful to fit, but it might not be obvious enough. Same goes for features to sanely upgrade libraries. If anything annoys me personally about the search for a new language is that the vast majority of them are blaming java for things that will happen to them in 10 years time too: Libraries that looked good then don't look so great now but changing it won't work because you really can NOT break backwards compatibility when you're that established. I can point at many scala libraries that seem like fine candidates to look downright "what the heck were they thinking". Not now, but in 10 years time. Just like java.util.Date, and the implicit mutability of java.util's collections, etc. Again a point which definitely leads to a simple+powerful language but might not be obvious enough. Would at least require some serious campaigning to make this point stick in the minds of the masses. (Probably with placations of "The only language ready for the future!" or some such).

 - I _really_ doubt this is in practice simple+powerful, but it might look like it: parallelism and other fine-grained concurrency control built straight in the language. Some mix of parallel-by-default loops and Software Transactional Memory perhaps. It'll certainly look like a lightweight convincer even if it isn't, and looks is worth a lot.

 - Ships out of the box with full IDE support. The vast majority of rank and file java programmers use Eclipse, IDEA, Oracle's builderwhatsit thing, or netbeans (in that order). Shows people you understand how they work.

Looking at that list, Gosu is a lot closer than fantom or scala... though probably not good enough either.

[Kevin Wright]

On 22 March 2011 09:51, Phil <ph...@surfsoftconsulting.com> wrote:

I don't think anybody would argue that a functional

language can be more complex than an OO one.

People *will* argue that, but it's like arguing that JSP can be more complex than hibernate.  The two things are completely distinct and can be used together or independently as you wish.  The real comparison is between functional and imperative languages, OO is simply a layer of architecture that can be used with either.

 

All said, Scala is still the functional language I will turn to when I
have the time to look at one in more detail. But sorry, Dick, I'm on
the wrong continent for training!

Oh, where are you then?  We certainly have plenty of training available in the UK, I also know of good people in Sweden, Germany and Australia.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Phil]

I'm in the UK, my spare time and energies are currently elsewhere,
perhaps in the autumn I will be looking to do something - before
Devoxx so that I can also get the maximum benefit of the Scala
presentations there too.

On Mar 22, 11:05 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:

> On 22 March 2011 09:51, Phil <p...@surfsoftconsulting.com> wrote:
>
> > I don't think anybody would argue that a functional
> > language can be more complex than an OO one.
>
> People *will* argue that, but it's like arguing that JSP can be more complex
> than hibernate.  The two things are completely distinct and can be used
> together or independently as you wish.  The real comparison is between
> functional and imperative languages, OO is simply a layer of architecture
> that can be used with either.
>
> > All said, Scala is still the functional language I will turn to when I
> > have the time to look at one in more detail. But sorry, Dick, I'm on
> > the wrong continent for training!
>
> Oh, where are you then?  We certainly have plenty of training available in
> the UK, I also know of good people in Sweden, Germany and Australia.
>
> --
> Kevin Wright
>

> gtalk / msn : kev.lee.wri...@gmail.com
> <kev.lee.wri...@gmail.com>mail: kevin.wri...@scalatechnology.com

[Kevin Wright]

On 22 March 2011 11:02, Reinier Zwitserloot <rein...@gmail.com> wrote:

I've never run into anyone that is holding off on Fantom because it lacks 'true' generics.

Scala's problem is that it tries to change too much, but Fantom's problem is that it doesn't change enough; no matter what people tell you, its fairly obvious (to me anyway, YMMV) that changing something as fundamental as the programming language, especially if that language prefers use of alternative (fantom / scala versions of) crucial java runtime classes such as ArrayList, is a gigantic step that will never be taken lightly. So, you need a lot of convincers, but at the same time, the _vast_ majority of programmers do not want to learn more than 1 language so have to feel like another language can make a new home for them based on some simplistic snippets and without knowing much about said language. So, the language has to be both filled with convincing arguments that it feels like real, meaningful progress, whilst at the same time looking like it'll be such a minor change that they'll know for sure they'll adapt easily to this new language.

Screwed if you do, screwed if you don't.

I've said it before, but if any contender to java's throne is to show up, it needs to come up with "leightweight" convincers, just like java did to C: Java took just about the entire C syntax, warts and all, and imported that part wholesale to lower the bar (i.e. to 'be like fantom'). It then added things that were worth a lot but didn't have a high impact on the language itself in order to convince C programmers to switch to it (i.e. to 'be like scala'): A garbage collector, write-once-run-anywhere, threading, networking, and many other fairly standard tasks all supplied by a universal standard library thus truly delivering on the 'platform independent' promise. As an encore, java simplified a number of things, including removing the preprocessor. Not sure if that made a real difference in the end, but keeping things simple (in fact, now we might argue java was a little _too_ simple) never hurt language uptake, unlike the reverse of course. Something as simple as looking at scala's collections API makes people run for the hills even though in practice those crazy type variables do work fine (.toMap(implicit) on the other hand....)

I have to disagree with this evaluation of Java, it most certainly DID remove a lot from C/C++ instead of simply porting the syntax wholesale.

Pointers and reference types spring immediately to mind, as do macros and templates.  C++ pointers allow you to create higher-kinded functions and write in a much more functional style, Java abandoned this ability.  You'll also find that Scala's collections are far more interoperable and closer to Java's than Java's are to collections in the STL.

 

So why did Scala not simply adopt Java's collections (which it can happily use, by the way).  Simple, to drop the inherent mutability that pervades the Java collections API, to allow for declaration-site variance (instead of wildcards throughout your code), and to make it easy to add all the juicy higher-kinded methods that make the library so damned powerful

So, high impact stuff that doesn't complicate the language, that's what'll make java.next. What should this look like? Don't know - but I guess at least one of these will be involved:

 - A language that caters to DSLs not by making the syntax flexible but by standardizing the AST and Parser and making these pluggable, with a meta-notation to define which plugins are to be used for the sources itself. May or may not be paired by the notion that AST editing is the basic form (instead of 'stream of characters' like 99.99% of all programming today), and most likely will require adapting these plugins to be written with IDEs in mind.

Scala.

It has a standard ASL, and all the IDE plugins are migrating to use the presentation compiler (written with IDEs in mind) following the 2.9 release.  The meta-notation is annotations; for an example of this, look at the @BeanProperty annotation which automatically generates getters and setters on fields, and is recognised by all current Scala IDE plugins.

 - A marriage between OSGi (i.e. runtime modularity), maven central (i.e. module repository), and gradle/ivy/maven (i.e. buildtime modularity) and better than all 3 combined, built into the language syntax. i.e. all you need to do is write "import guava.* from jigsaw://guava.google.com/guava/r8;" at the top of the file and the IDE will use one of the basic commands of the language's toolkit (just as basic as 'java' and 'jar') to resolve and download this dependency, and link it all up, sources included, in your IDE.

Take a look at Scala-Modules, this is all very doable via standard DSL approaches.  There are also ongoing efforts to modularise the language and core libraries.

 

 - Be quite close at least at-a-glance to java syntax, just like java syntax looked virtually 100% the same as C code if you didn't look too close and picked examples that fit well, such as algorithms.

Scala.  Though most algorithms change significantly in appearance once you have closures available.  This will be true of any Java successor.

 

 - Yes, most likely this language _will_ have closures, even if only because excluding them means all the discussion will be about a perceived negative. Personally I do think java 1.1's anonymous inner classes were a mistake and should have been closures instead. It'll most likely also have collection literals and do away with a few annoyances.

Make the syntax clean enough, and you don't need collection literals.  This also makes it far, far easier to write new collection types that look natural.  History is littered with examples of things being standardised in syntax and later discovered to be a bad practice, but impossible to then remove from the language.  Such as checked exceptions...

 

 - A solution for sharing objects/structs provided by one library, between 2 libraries that each are dependent on a different version of that library. i.e. you want to share a guava ImmutableList between 2 libraries, but library one is at r7, the other is at r8. May involve some sort of nifty 'view' concept where an API can also export a bunch of wrapper methods that make it look like different API, while being represented 'under the hood' by the same batch of fields/struct so it can be transferred. Could be used to fix collections API while remaining compatible with that same API well enough to be able to pass (java.next) lists around to methods that want java.util.Lists without hassle.

Interesting... How would you propose such a mechanism should work?  Sounds more like a requirement for library authors to me.

 

 - Possibly will ship WITHOUT most of what we now consider a standard library, instead embracing the modularity concept fully and shipping instead with the knowledge that there's boatloads of libraries out there for you to import.... though I wonder if this will hit the right notes of trivially understood simplicity and power that are needed to become a new great language. I'm sure this part IS typically simple+powerful to fit, but it might not be obvious enough. Same goes for features to sanely upgrade libraries. If anything annoys me personally about the search for a new language is that the vast majority of them are blaming java for things that will happen to them in 10 years time too: Libraries that looked good then don't look so great now but changing it won't work because you really can NOT break backwards compatibility when you're that established. I can point at many scala libraries that seem like fine candidates to look downright "what the heck were they thinking". Not now, but in 10 years time. Just like java.util.Date, and the implicit mutability of java.util's collections, etc. Again a point which definitely leads to a simple+powerful language but might not be obvious enough. Would at least require some serious campaigning to make this point stick in the minds of the masses. (Probably with placations of "The only language ready for the future!" or some such).

 

Scala again :)

 - I _really_ doubt this is in practice simple+powerful, but it might look like it: parallelism and other fine-grained concurrency control built straight in the language. Some mix of parallel-by-default loops and Software Transactional Memory perhaps. It'll certainly look like a lightweight convincer even if it isn't, and looks is worth a lot.

Scala: Parallel collections in 2.9 (soon to be released)

But this is all done as part of the standard library and not the core language syntax (as per your previous point...)

 

 - Ships out of the box with full IDE support. The vast majority of rank and file java programmers use Eclipse, IDEA, Oracle's builderwhatsit thing, or netbeans (in that order). Shows people you understand how they work.

The 2.9 Eclipse plugin for Scala is looking very sexy, and IntelliJ is already at full production strength.  I can't comment on Netbeans.

 

Looking at that list, Gosu is a lot closer than fantom or scala... though probably not good enough either.

Gosu certainly looks interesting and lightweight, offering many of Scala's nicer qualities.  I think, though, that the killer feature in the future is going to be parallelism, given current trends in core counts.  Scala's support for default immutability, delimited continuations, parallel collections, and (following work funded by the EU grant) library-driven AST transformations absolutely give it the edge here.

 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

[Kevin Wright]

On 22 March 2011 11:20, Phil <ph...@surfsoftconsulting.com> wrote:

I'm in the UK, my spare time and energies are currently elsewhere,
perhaps in the autumn I will be looking to do something - before
Devoxx so that I can also get the maximum benefit of the Scala
presentations there too.

You should check out these guys: http://skillsmatter.com/go/scala

The Scala Exchange on June 15/16 looks to be especially interesting

Also the London Scala Users Group:

Meetup site - http://skillsmatter.com/go/scala

Google Groups - https://groups.google.com/group/scala-london?hl=en

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

[Reinier Zwitserloot]

Wow, that's some raving scala fanboyism again, Kevin. At the end you resort to outright lies. You didn't understand most of my points, apparently, so I'll attempt to clarify where I can.

On Tuesday, March 22, 2011 12:35:15 PM UTC+1, KWright wrote:

I have to disagree with this evaluation of Java, it most certainly DID remove a lot from C/C++ instead of simply porting the syntax wholesale.

But it did port the _SYNTAX_ wholesale, even down to the weird postfix array brackets and screwed up switch statements. It got rid of pointers, but at least in algorithmic examples you don't even see that, and no pointers was a clear bid for simplicity, and my theory is that making stuff seemingly simpler in an obvious way (regardless of what actually happens, its all about what it looks like) helps a lot.

Same goes for macros and templates which are primarily preprocessor concepts, and something generally considered overly complicated. In other words, if you're going to change, you should change in a way that includes a promise of "We've made this way simpler, just look at this snippet, isn't it obvious?". Whether or not it'll actually work out that way in practice. For java, it clearly did, at least in regards to preprocessor (not really needed due to a single standard platform) and pointers (that one's obvious).

You can take for example some example crypto algorithm and copy it into a text file, rename it to java, fix main up so it returns void and not int, and clear out the header import, and it'll probably compile just like that with javac. There's absolutely no way the same treatment is going to end up making a scala-valid file when you start with either java or C code.

 

Pointers and reference types spring immediately to mind, as do macros and templates.  C++ pointers allow you to create higher-kinded functions and write in a much more functional style, Java abandoned this ability.  You'll also find that Scala's collections are far more interoperable and closer to Java's than Java's are to collections in the STL.

Yes, but java already broke ALL pretense of being even remotely compatible with anything C related, that was one 'easy to switch' barrier they decided to forego. You don't have to be perfect, just good enough. Scala is missing a point here, because unlike java, it _COULD_ have attempted to be compatible (as its built on the JVM the option was there), but it isn't. (Programming to java.util.* is possible in Scala but then you're in a no-mans land where you get zero community support and leaky interop with both java and scala, i.e. the worst of both worlds. At best you can enter this nomans land to program up some bridges, but that's not exactly simple and hassle free).

See for example gosu, which has heavily invested in a language feature that amongst other things, at least in theory, can give you compatibility with java.util.* while also fixing some of those API's warts. They scored a point with that.

 

So why did Scala not simply adopt Java's collections (which it can happily use, by the way).  Simple, to drop the inherent mutability that pervades the Java collections API, to allow for declaration-site variance (instead of wildcards throughout your code), and to make it easy to add all the juicy higher-kinded methods that make the library so damned powerful

That doesn't matter. They point is: They DIDNT copy them. Nor they did choose some middle road where scala takes a vanilla j.u.List and attempts to craft higher-kinded methods on top of that using some sort of extension mechanism. Unlike pointers and the preprocessor, java collections are not generally considered as overcomplicated. Possibly the API is considered a little underpowered, but fixing that is not nearly as convincing as simplifying matters.

The reason this is so important is because it makes it virtually impossible for scala to get a foot in the door of a normal programming shop. If vanilla scala straight out of the tutorials could be easily combined with existing java programs, then some enterprising early adopter could write some new feature in scala and stripe it into the build bundled up with java files. Someone else catches on and does the same thing. 4 years later, half the code base total and 99% of the code base under active development is scala code, and the java legacy bits at some point just get scrubbed out and there was much rejoicing. New projects or rewrites are done in scala.

Except none of that will happen because you can't get that all-important foot in the door. Because nobody really used it 'in production', when the decision is made to from-scratch rewrite something or start a new project, scala is not seriously considered.

 

Scala. [in reference to: DSL features via compiler plugins instead of language features]

Don't make me laugh. Scala is hardly pluggable (if you think so, you haven't seen anything yet), and even if the few improvements it has made over java are taken as acceptable on this front, then that would make it suck more; scala caters to DSLs via flexible language constructs (optional semicolons, dots, and parens for method calls and the like, implicits, and so on and so forth), but these language constructs have disadvantages, mostly they complicate matters. A language that implements every single different route to the same end result is obviously going to be far too complicated for anyone to use. You have to make a choice here: Either DSL the language, or DSL the compiler via plugin architecture. You can do both but that doesn't get you to the next language. In passing you're also insinuating scala was designed with IDEs in mind - Which is so obviously false I'm not going to bother quoting. Also, plugging the compiler is never shown as example on any scala example I've ever seen, which means its completely irrelevant insofar as convincing the masses go.

 

 - A marriage between OSGi (i.e. runtime modularity), maven central (i.e. module repository), and gradle/ivy/maven (i.e. buildtime modularity) and better than all 3 combined, built into the language syntax. i.e. all you need to do is write "import guava.* from jigsaw://guava.google.com/guava/r8;" at the top of the file and the IDE will use one of the basic commands of the language's toolkit (just as basic as 'java' and 'jar') to resolve and download this dependency, and link it all up, sources included, in your IDE.

Take a look at Scala-Modules, this is all very doable via standard DSL approaches.  There are also ongoing efforts to modularise the language and core libraries.

There's no scala-centralized module download service shared by all consumers of anything scala related (compilers, IDE, programs written in scala). There's also no repository, there's no runtime modularity, and most of all its not built into the language, right there from the very first tutorial. Unlike, say, java's garbage collection or everything-with-OO-never-pointers nature. How the heck is anyone casually inspecting what this scala hubbub is all about going to figure out that it's going to magically solve all modularization problems (which it doesn't, but lets roll with your hypothetical fair weather scala fanboy outlook here and say that it'l all ponies and rainbows).

 

 

Scala.  Though most algorithms change significantly in appearance once you have closures available.  This will be true of any Java successor. [re: scala looks just like java]

That's just not true at all. Scala code does not look like java code. All sorts of things have fundamentally changed. No 'return', no semicolons, no dots, no parens, different way of declaring methods, constructors changed completely, many syntax nooks and crannies updated. Contrast to java which knowingly went with inferior syntax constructs just because they would be familiar to C programmers, i.e. the 'switch' and 'for' syntax as well as postfix arrays. Gosling and co. didn't include that because they liked their styles, they did it because they prioritized being familiar above being more consistent.

If you think scala went through as many hoops as it could to be as familiar to java programmers as it could possibly be, you're... delusional. There are literally hundreds of syntax constructs in scala which are different from java, probably for its own consistency's sake better, but could have easily been written in a more java-like way.

 

Make the syntax clean enough, and you don't need collection literals.  This also makes it far, far easier to write new collection types that look natural.  History is littered with examples of things being standardised in syntax and later discovered to be a bad practice, but impossible to then remove from the language.  Such as checked exceptions...

Such as Scala's XML literals? Zing!

Checked exceptions can actually be removed from java in a heartbeat, without breaking backwards compatibility, so clearly not a valid example. Also, a syntax where you can make virtually every construct you can think of now or in the future a reality sounds great and nicely forward compatible, but in practice it also means its virtually impossible to tell, at a glance, what any code could possibly do. Flexible DSLy language features go hand in hand with confusing compiler errors and libraries that are utter rocket science to even journeyman programmers (lift, anybody?).

It's all very powerful, but not the kind of 'simple' that has immediate appeal to would-be switchers. Worse, these constructs give those who'd prefer more caution ample ammunition to point out problems. Such as trying to turn 2 lists of objects into a map, which is utter gobbledygook in scala. You can either do:

Map((listA zip listB).toArray:_*)

That's not a smiley at the end, that's cartoon swearing to make it work (specifically, to tell scala to treat that map as the full array of all varargs, not as the first vararg of an array of array of A,B tuples.

Alternatively:

(listA zip listB) toMap;

With the semicolon all of a sudden mandatory, because otherwise the statement on the next line, if it is a valid expression (and virtually everything in scala is), is likely to be interpreted as the parameter to toMap, which is implicit and thus is not actually necessary.

Getting this wrong results in extremely obtuse compiler errors which no one but a scala expert is going to figure out. This is a problem that seems to be invisible to the scala experts.

That's the kind of 'complicated' that beginners are going to run into and is going to cause them to abandon it in favour of well-known java, wondering what could possibly have bewitched all those language experts that said switching would be a good idea.

 

 - A solution for sharing objects/structs provided by one library, between 2 libraries that each are dependent on a different version of that library. i.e. you want to share a guava ImmutableList between 2 libraries, but library one is at r7, the other is at r8. May involve some sort of nifty 'view' concept where an API can also export a bunch of wrapper methods that make it look like different API, while being represented 'under the hood' by the same batch of fields/struct so it can be transferred. Could be used to fix collections API while remaining compatible with that same API well enough to be able to pass (java.next) lists around to methods that want java.util.Lists without hassle.

Interesting... How would you propose such a mechanism should work?  Sounds more like a requirement for library authors to me.

Look at gosu, for example. Basically, you canonize wrappers as language features. Basically you say: Anytime anyone uses the type named "X", compile it down to type "Y", but make it look like it has a different API. Here's a bunch of methods that should be the API, and they all get access to the underlying type Y. For example, I could make a new java.util.Properties wrapper that is a real Properties under the hood but which actually acts as if it has a cleaned up simplified API, i.e. delete the deprecated methods, make it a proper Map<String, String>, add a print routine, and more. Even if a method is called that takes a CleanedupProperties and is handed a _subclass_ of Properties, this wrapper can still get the job done. You can probably add this to scala without too much hassle, but you have to choose: Either most of the scala-standard API is built as these wrappers, and authors are taught early in the process of learning the language how to build these, or you run into the usual problem with offering many ways to solve the same problem: The community chose way X, so all other ways are effectively useless and serve only to complicate matters.

It gets more complicated if you want to change the underlying structural data (i.e. the fields). For example, envisioning a way to make java.awt.Point immutable requires a lot more crazy stunts, but at least you could make a Point 'class' that is mostly immutable, i.e. will only end up changing if you pass it into code that uses the old API and that code makes changes to it.

 

 

 - Possibly will ship WITHOUT most of what we now consider a standard library, 

 

Scala again :)

Pure lies. Scala ships with a large and growing standard library. There is no way to import other libraries without writing up an sbt or maven pom.

 

 - I _really_ doubt this is in practice simple+powerful, but it might look like it: parallelism and other fine-grained concurrency control built straight in the language. Some mix of parallel-by-default loops and Software Transactional Memory perhaps. It'll certainly look like a lightweight convincer even if it isn't, and looks is worth a lot.

Scala: Parallel collections in 2.9 (soon to be released)

But this is all done as part of the standard library and not the core language syntax (as per your previous point...)

For once scala delivers, sort of, on this. But it's not endemic to scala, for example foldLeft remains completely sequential, cannot at all be parallelized. Also, scoring 1 point here doesn't really weigh up to the tens of points lost for making it all look far too complicated.

 

 

 - Ships out of the box with full IDE support. The vast majority of rank and file java programmers use Eclipse, IDEA, Oracle's builderwhatsit thing, or netbeans (in that order). Shows people you understand how they work.

The 2.9 Eclipse plugin for Scala is looking very sexy, and IntelliJ is already at full production strength.  I can't comment on Netbeans.

This helps, but its taken way too long. The last time I used the scala plugin (which admittedly wasn't 2.9), it still didn't work right so often I usually dropped down to the command line and compiled with scalac to be 100% certain this obscure illegible compiler error I was getting was truly a problem in my code and not a plugin bug. That's not a good sign.

Gosu certainly looks interesting and lightweight, offering many of Scala's nicer qualities.  I think, though, that the killer feature in the future is going to be parallelism,

See other thread of a while ago where I suggested parallelism is not a killer feature at all. Also, if that's the only serious convincer scala has, scala is in trouble, as its one of the most complicated ones on the docket, requiring massive changes to language style and APIs.... which scala indeed does have.

 

[Josh Berry]

I think you're kidding yourselves if you think you can make a bullet
list that will explain the next big language. At best, you can make
one that explains what you would like to see. Unless you have the
power of someone like Jobs, than getting the rest of the world to
agree is a non-starter. (That is to say, I hear more interest in
obj-c than I do in any of the languages that have ever been mentioned
here as "the next big thing.")

[Casper Bang]

> (That is to say, I hear more interest in
> obj-c than I do in any of the languages that have ever been mentioned
> here as "the next big thing.")

I think we can all agree that Obj-C would be dead a buried if it had
not been for Apple's disrespect for developers, often caught in a
variation of the Battered Woman's Syndrome and the Stockholm Syndrome
that will

[Josh Berry]

How does that dispute what I said, though? I think many would agree
that Java would have died had a few heavy weights in the industry not
backed it and kept it going. Isn't the most popular Java web
framework still struts?

[Phil]

> I think you're kidding yourselves if you think you can make a bullet
> list that will explain the next big language.  

I'm not sure the discussion here is trying to do that although I agree
with your point.

> At best, you can make
> one that explains what you would like to see.  Unless you have the
> power of someone like Jobs, than getting the rest of the world to
> agree is a non-starter.

Where do languages come from? Thinking of Occam and Ada, they were
languages crafted to serve specific purposes. If a language is well
crafted for its intended purpose you don't need to get people to
agree. Over time people will gravitate towards the 'successful'
language as it proves itself, leaving the unsuccessful to wither on
the vine, in a somewhat Darwinian fashion.

I think pulling Jobs in to the discussion is at best a bit misleading
and at worst a red herring. After all, even Apple have produced duff
products (buttonless iPod Shuffle for one, underwhelming and overly
restricting AppleTV - both versions - for another).

Further, Apple have *not* been successful in getting the world to
agree. I give you FireWire. An excellent tech that people not using
Apple hardware rarely come into contact with. I love it for its
ability to sustain consistently high data transfer speeds (as opposed
to USB's 'best effort') and choose FireWire plus USB over USB only
external hard drives every time.

In short, the rest of the world will agree with Apple when it is in
their interest to do so. If objectives don't align, it isn't going to
happen, regardless of the company, unless a true monopoly exists and
is being abused.

> (That is to say, I hear more interest in
> obj-c than I do in any of the languages that have ever been mentioned
> here as "the next big thing.")

That's because Objective C is earning people money and this is an
entirely reasonable position. It doesn't make discussions of new
languages invalid, any more than it makes the creation of new
languages invalid. Many will be created, most will fall quickly by the
wayside, and those that can be quickly and cheaply applied to bring
commercial advantage will gain traction quicker than those that can't.
I've heard enough to know that Scala will fit well in certain niches,
especially on the computation side (time to throw out the Fortran
compiler!).

As far as this thread goes I'd have to say that my current view is
"functional is definitely a good thing" whilst remaining unconvinced
that "Scala will be the one". But I'll still take a look - just not a
£500-a-day training course.

[Kevin Wright]

On 22 March 2011 13:46, Reinier Zwitserloot <rein...@gmail.com> wrote:

Wow, that's some raving scala fanboyism again, Kevin. At the end you resort to outright lies. You didn't understand most of my points, apparently, so I'll attempt to clarify where I can.

On Tuesday, March 22, 2011 12:35:15 PM UTC+1, KWright wrote:

I have to disagree with this evaluation of Java, it most certainly DID remove a lot from C/C++ instead of simply porting the syntax wholesale.

But it did port the _SYNTAX_ wholesale, even down to the weird postfix array brackets and screwed up switch statements. It got rid of pointers, but at least in algorithmic examples you don't even see that, and no pointers was a clear bid for simplicity, and my theory is that making stuff seemingly simpler in an obvious way (regardless of what actually happens, its all about what it looks like) helps a lot.

I know, Scala largely did the same with Java.  You have no idea the challenges involved in maintaining compatibility with some of Java's features, such as unary negation of floating point values, and concatenation of objects/primitives to Strings, this has been a permanent thorn in the side of designing a sane collections framework that also recognises strings as a sequence of characters.

 

Same goes for macros and templates which are primarily preprocessor concepts, and something generally considered overly complicated. In other words, if you're going to change, you should change in a way that includes a promise of "We've made this way simpler, just look at this snippet, isn't it obvious?". Whether or not it'll actually work out that way in practice. For java, it clearly did, at least in regards to preprocessor (not really needed due to a single standard platform) and pointers (that one's obvious).

You can take for example some example crypto algorithm and copy it into a text file, rename it to java, fix main up so it returns void and not int, and clear out the header import, and it'll probably compile just like that with javac. There's absolutely no way the same treatment is going to end up making a scala-valid file when you start with either java or C code. 

Likewise, a trivial Java->Scala conversion is usually little more than adding java.lang/util imports, moving type declarations to a postfix notation, and fixing up any switch statements or enhanced for-loops (usually by removing boilerplate, such as break statements.

 

Pointers and reference types spring immediately to mind, as do macros and templates.  C++ pointers allow you to create higher-kinded functions and write in a much more functional style, Java abandoned this ability.  You'll also find that Scala's collections are far more interoperable and closer to Java's than Java's are to collections in the STL.

Yes, but java already broke ALL pretense of being even remotely compatible with anything C related, that was one 'easy to switch' barrier they decided to forego. You don't have to be perfect, just good enough. Scala is missing a point here, because unlike java, it _COULD_ have attempted to be compatible (as its built on the JVM the option was there), but it isn't. (Programming to java.util.* is possible in Scala but then you're in a no-mans land where you get zero community support and leaky interop with both java and scala, i.e. the worst of both worlds. At best you can enter this nomans land to program up some bridges, but that's not exactly simple and hassle free).

 

The community is very supportive of this kind of thing actually, though you rarely need to do it as the standard lib provides some very good scala/java collection conversion.  Even implicity, if you so desire.

If you haven't looked at Scala since 2.8, then you're almost certainly over-estimating the extent of what little leakiness remains here.  Seriously, strong Java interop remains a core design goal of Scala, so long as this doesn't mean directly implementing features known to represent bad practices.

See for example gosu, which has heavily invested in a language feature that amongst other things, at least in theory, can give you compatibility with java.util.* while also fixing some of those API's warts. They scored a point with that.

 

So why did Scala not simply adopt Java's collections (which it can happily use, by the way).  Simple, to drop the inherent mutability that pervades the Java collections API, to allow for declaration-site variance (instead of wildcards throughout your code), and to make it easy to add all the juicy higher-kinded methods that make the library so damned powerful

That doesn't matter. They point is: They DIDNT copy them. Nor they did choose some middle road where scala takes a vanilla j.u.List and attempts to craft higher-kinded methods on top of that using some sort of extension mechanism. Unlike pointers and the preprocessor, java collections are not generally considered as overcomplicated. Possibly the API is considered a little underpowered, but fixing that is not nearly as convincing as simplifying matters.

Being underpowered is the least of the problems, of far greater concern is the baked-in mutability - something that just HAD to be removed in order to "simplify matters".  Repeated case studies have shown time and time again that imperative code is harder to reason about, I defy you to find me a single person who's seriously looked into the question who won't also claim that this aspect of Java's collections is unnecessary complexity.

Don't make the mistake of thinking Java's collection framework is good design simply because of your own familiarity.  Times have changed and problems have been discovered, but backward compatibility has become a ball-and-chain, preventing Java from removing problematic features, other JVM languages don't have this burden.

 

The reason this is so important is because it makes it virtually impossible for scala to get a foot in the door of a normal programming shop. If vanilla scala straight out of the tutorials could be easily combined with existing java programs, then some enterprising early adopter could write some new feature in scala and stripe it into the build bundled up with java files. Someone else catches on and does the same thing. 4 years later, half the code base total and 99% of the code base under active development is scala code, and the java legacy bits at some point just get scrubbed out and there was much rejoicing. New projects or rewrites are done in scala.

Except none of that will happen because you can't get that all-important foot in the door. Because nobody really used it 'in production', when the decision is made to from-scratch rewrite something or start a new project, scala is not seriously considered.

 

Scala. [in reference to: DSL features via compiler plugins instead of language features]

Don't make me laugh. Scala is hardly pluggable (if you think so, you haven't seen anything yet), and even if the few improvements it has made over java are taken as acceptable on this front, then that would make it suck more; scala caters to DSLs via flexible language constructs (optional semicolons, dots, and parens for method calls and the like, implicits, and so on and so forth), but these language constructs have disadvantages, mostly they complicate matters. A language that implements every single different route to the same end result is obviously going to be far too complicated for anyone to use. You have to make a choice here: Either DSL the language, or DSL the compiler via plugin architecture. You can do both but that doesn't get you to the next language. In passing you're also insinuating scala was designed with IDEs in mind - Which is so obviously false I'm not going to bother quoting. Also, plugging the compiler is never shown as example on any scala example I've ever seen, which means its completely irrelevant insofar as convincing the masses go.

infix method call notation and implicits are wildly different features, and absolutely not alternative routes to the same end, though they do often combine very nicely in DSL design.  For example, the === method (to assert equality) in ScalaTest is added to objects via an implicit conversion as used as though it were an operator.

 

Having written several compiler plugins myself, I can testify as to how much better this experience is than the equivalent in Java.

 

 - A marriage between OSGi (i.e. runtime modularity), maven central (i.e. module repository), and gradle/ivy/maven (i.e. buildtime modularity) and better than all 3 combined, built into the language syntax. i.e. all you need to do is write "import guava.* from jigsaw://guava.google.com/guava/r8;" at the top of the file and the IDE will use one of the basic commands of the language's toolkit (just as basic as 'java' and 'jar') to resolve and download this dependency, and link it all up, sources included, in your IDE.

Take a look at Scala-Modules, this is all very doable via standard DSL approaches.  There are also ongoing efforts to modularise the language and core libraries.

There's no scala-centralized module download service shared by all consumers of anything scala related (compilers, IDE, programs written in scala). There's also no repository, there's no runtime modularity, and most of all its not built into the language, right there from the very first tutorial. Unlike, say, java's garbage collection or everything-with-OO-never-pointers nature. How the heck is anyone casually inspecting what this scala hubbub is all about going to figure out that it's going to magically solve all modularization problems (which it doesn't, but lets roll with your hypothetical fair weather scala fanboy outlook here and say that it'l all ponies and rainbows). 

Maven is the de-facto standard for repositories, OSGi is the de-facto standard to modularisation.  This is the Java interop you asked for in action, I fail to see the problem.

 

Scala.  Though most algorithms change significantly in appearance once you have closures available.  This will be true of any Java successor. [re: scala looks just like java]

That's just not true at all. Scala code does not look like java code. All sorts of things have fundamentally changed. No 'return', no semicolons, no dots, no parens, different way of declaring methods, constructors changed completely, many syntax nooks and crannies updated. Contrast to java which knowingly went with inferior syntax constructs just because they would be familiar to C programmers, i.e. the 'switch' and 'for' syntax as well as postfix arrays. Gosling and co. didn't include that because they liked their styles, they did it because they prioritized being familiar above being more consistent.

return: Scala has it, though it's optional, you can even use multiple returns from a method if you desire.  You can also simply allow the result of the last expression in a block to be the return value, usually this is much cleaner.

no semicolons: Scala has semicolons, they're just optional when it's obvious what's going on

no dots: Eh, since when?  Scala uses dot notation for calling methods exactly as Java does

no parens: Same as dots.

different way of declaring methods:  Actually, it's a different way of declaring anything with a type (including methods, params and variables), this was necessary to allow for type inference.  Try taking the expression "int x = 2" and allowing the type to be inferred without having it look like an assignment, with the Scala approach "val x: Int = 2" it's suddenly a lot more obvious how this can be done.

Yes, of course you also have infix notation available in Scala, and it's considered idiomatic.  But it certainly isn't compulsory; many new adopters start with a syntax very close to that of Java.

constructors: Do you seriously enjoy having to specify the same name and type three times (constructor, field and getter)?

nooks and crannies updated: finally!

Scala code *can* look very, very similar to Java.  As such it's usually a very bad example of how Scala should be written, but it's handy when migrating to the language, or trying to migrate large chunks of code.

 

If you think scala went through as many hoops as it could to be as familiar to java programmers as it could possibly be, you're... delusional. There are literally hundreds of syntax constructs in scala which are different from java, probably for its own consistency's sake better, but could have easily been written in a more java-like way. 

Internal consistency was absolutely another driving force, and rightly so.  Evolution has to happen somehow, though at every point in Scala's design where a decision was taken, Java consistency was always chosen unless there was some other overriding consideration.  Of all the people currently involved in Scala, Marting is the one who perhaps feels most strongly about this, consistently standing his ground on the issue despite the requests of others to drop some Java compatibility feature known to cause other issues.

 

Make the syntax clean enough, and you don't need collection literals.  This also makes it far, far easier to write new collection types that look natural.  History is littered with examples of things being standardised in syntax and later discovered to be a bad practice, but impossible to then remove from the language.  Such as checked exceptions...

Such as Scala's XML literals? Zing!

Good example, and already publicly stated as being a bad design choice.  XML was all the rage when Scala was first designed, and such literals would never be in the language if created from scratch now.

 

Checked exceptions can actually be removed from java in a heartbeat, without breaking backwards compatibility, so clearly not a valid example. Also, a syntax where you can make virtually every construct you can think of now or in the future a reality sounds great and nicely forward compatible, but in practice it also means its virtually impossible to tell, at a glance, what any code could possibly do. Flexible DSLy language features go hand in hand with confusing compiler errors and libraries that are utter rocket science to even journeyman programmers (lift, anybody?).

I personally wouldn't put Lift forward as a good example of Scala DSLs, and agree that it contains many confusing features (Not unlike the Java DateTime API, you don't need a powerful language to write confusing stuff).  For far better examples, I'd encourage you to look at Akka, Specs, ScalaTest, SBT, or the scalatra web framework

 

It's all very powerful, but not the kind of 'simple' that has immediate appeal to would-be switchers. Worse, these constructs give those who'd prefer more caution ample ammunition to point out problems. Such as trying to turn 2 lists of objects into a map, which is utter gobbledygook in scala. You can either do:

Map((listA zip listB).toArray:_*)

That's not a smiley at the end, that's cartoon swearing to make it work (specifically, to tell scala to treat that map as the full array of all varargs, not as the first vararg of an array of array of A,B tuples.

Alternatively:

(listA zip listB) toMap;

With the semicolon all of a sudden mandatory, because otherwise the statement on the next line, if it is a valid expression (and virtually everything in scala is), is likely to be interpreted as the parameter to toMap, which is implicit and thus is not actually necessary.

idiomatically, I'd write this:

  (listA zip listB).toMap

It's also fairly common to see your second example used with a blank line following, or at the end of a block, though it's generally considered bad practice to use infix notation for a method that doesn't take an argument, just as it's bad practice to write code where indentation doesn't match up with scope.

Incidentally, the toArray in your first example is completely pointless, and would slow down performance with no good cause.  Scala varargs use Seq instead of Arrays.  In part, this is due to known issues with the variance of Arrays when also used with the forwarder methods necessary for covariant return types from overridden methods (see the "Java Puzzlers - scraping the bottom of the barrel" talk)

Getting this wrong results in extremely obtuse compiler errors which no one but a scala expert is going to figure out. This is a problem that seems to be invisible to the scala experts.

As opposed to more insidious runtime errors I suppose...  I once again invite you to look at a recent release of Scala, I think you'll be pleasantly surprised at quite how much many error messages have improved.

 

That's the kind of 'complicated' that beginners are going to run into and is going to cause them to abandon it in favour of well-known java, wondering what could possibly have bewitched all those language experts that said switching would be a good idea.

Read through "Java Puzzlers" again, look at how many of those problems no longer apply to Scala...

 

 

 - A solution for sharing objects/structs provided by one library, between 2 libraries that each are dependent on a different version of that library. i.e. you want to share a guava ImmutableList between 2 libraries, but library one is at r7, the other is at r8. May involve some sort of nifty 'view' concept where an API can also export a bunch of wrapper methods that make it look like different API, while being represented 'under the hood' by the same batch of fields/struct so it can be transferred. Could be used to fix collections API while remaining compatible with that same API well enough to be able to pass (java.next) lists around to methods that want java.util.Lists without hassle.

Interesting... How would you propose such a mechanism should work?  Sounds more like a requirement for library authors to me.

Look at gosu, for example. Basically, you canonize wrappers as language features. Basically you say: Anytime anyone uses the type named "X", compile it down to type "Y", but make it look like it has a different API. Here's a bunch of methods that should be the API, and they all get access to the underlying type Y. For example, I could make a new java.util.Properties wrapper that is a real Properties under the hood but which actually acts as if it has a cleaned up simplified API, i.e. delete the deprecated methods, make it a proper Map<String, String>, add a print routine, and more. Even if a method is called that takes a CleanedupProperties and is handed a _subclass_ of Properties, this wrapper can still get the job done. You can probably add this to scala without too much hassle, but you have to choose: Either most of the scala-standard API is built as these wrappers, and authors are taught early in the process of learning the language how to build these, or you run into the usual problem with offering many ways to solve the same problem: The community chose way X, so all other ways are effectively useless and serve only to complicate matters.

Isn't that exactly what interfaces are?

 

It gets more complicated if you want to change the underlying structural data (i.e. the fields). For example, envisioning a way to make java.awt.Point immutable requires a lot more crazy stunts, but at least you could make a Point 'class' that is mostly immutable, i.e. will only end up changing if you pass it into code that uses the old API and that code makes changes to it.

Ahh, yes.  Such as the ability to change a public field into a method, for example.  This is known as the universal access principal, and was another core design goal of Scala,

 - Possibly will ship WITHOUT most of what we now consider a standard library, 

 

Scala again :)

Pure lies. Scala ships with a large and growing standard library. There is no way to import other libraries without writing up an sbt or maven pom.

Rats, would it be that pesky Java compatibility again, by any chance?

How else could this work, exactly, while also allowing for seamless reuse of existing Java libraries as well? (all of which are largely released via maven repositories)

Scala is, above all, a JVM language.  Once the JVM acquires a framework, such as jigsaw, able to handle such modules at runtime, you can be sure that Scala will be taking full advantage of it.  A great deal of work has already gone into modularising the Scala standard libs in anticipation of such an event.

 

 

 - I _really_ doubt this is in practice simple+powerful, but it might look like it: parallelism and other fine-grained concurrency control built straight in the language. Some mix of parallel-by-default loops and Software Transactional Memory perhaps. It'll certainly look like a lightweight convincer even if it isn't, and looks is worth a lot.

Scala: Parallel collections in 2.9 (soon to be released)

But this is all done as part of the standard library and not the core language syntax (as per your previous point...)

For once scala delivers, sort of, on this. But it's not endemic to scala, for example foldLeft remains completely sequential, cannot at all be parallelized. Also, scoring 1 point here doesn't really weigh up to the tens of points lost for making it all look far too complicated.

Actually, foldLeft *can* in theory be made parallel, so long as the compiler knows you're folding over a monoid, and I expect much more of this sort of thing in the future.

You repeatedly bring up the presence of folds as your main argument for the claim that Scala isn't ready for concurrency, but the truth of the matter is that folds aren't actually used very much at all in a great deal of Scala programming.  As with mutable collections, folds are a useful and pragmatic feature to have around for operations that are inherantly not themselves parallelisable, but anybody needing to write highly concurrent code will be aware of the pitfalls and not use such constructs.

Nobody ever claimed that folds were *supposed* to be parallelisable in Scala. At best, such a claim is simply mis-informed, at worst, it's intentional FUD.

 

 - Ships out of the box with full IDE support. The vast majority of rank and file java programmers use Eclipse, IDEA, Oracle's builderwhatsit thing, or netbeans (in that order). Shows people you understand how they work.

The 2.9 Eclipse plugin for Scala is looking very sexy, and IntelliJ is already at full production strength.  I can't comment on Netbeans.

This helps, but its taken way too long. The last time I used the scala plugin (which admittedly wasn't 2.9), it still didn't work right so often I usually dropped down to the command line and compiled with scalac to be 100% certain this obscure illegible compiler error I was getting was truly a problem in my code and not a plugin bug. That's not a good sign.

I'm in full agreement, which is why the entirety of Scala Solutions (Martin Odersky's company) are focussed on getting it right for the imminent 2.9 release.  Prepare to be impressed :)

 

Gosu certainly looks interesting and lightweight, offering many of Scala's nicer qualities.  I think, though, that the killer feature in the future is going to be parallelism,

See other thread of a while ago where I suggested parallelism is not a killer feature at all. Also, if that's the only serious convincer scala has, scala is in trouble, as its one of the most complicated ones on the docket, requiring massive changes to language style and APIs.... which scala indeed does have. 

I'll leave you with a great snippet from Glen Vanderberg: http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc

What was alarming and depressing about those Java projects I was reviewing was not that they were poorly designed. I expected that; design is, after all, difficult. No, the surprising thing was that somehow, against all odds, the developers had managed to wrestle these monstrous designs over the finish line. The sheer dogged determination it took to do so was impressive and horrifying. I would have given up in despair long before.

The experience taught me a valuable lesson:

Weak developers will move heaven and earth to do the wrong thing. You can’t limit the damage they do by locking up the sharp tools. They’ll just swing the blunt tools harder.

[Cédric Beust ♔]

On Tue, Mar 22, 2011 at 9:29 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

Repeated case studies have shown time and time again that imperative code is harder to reason about

Come on now. I was going to ask you for some evidence to back up this claim but the fact that there are millions of lines of code written in imperative style today is enough to prove this claim completely wrong.

Can we improve over the imperative style? Of course. But assuming that the only way to do so is by switching to a functional, actor based or asynchronous style is just the illustration of how blinded by your Scala love you are.

Personally, I find Actors and asynchronous/CP style much, much harder to reason about. It has some benefits and using such techniques is occasionally the best way to solve certain problems, but again, arguing that these techniques are an improvement over the current state of affairs with no drawbacks whatsoever is delusional.

 

, I defy you to find me a single person who's seriously looked into the question who won't also claim that this aspect of Java's collections is unnecessary complexity.

Don't make the mistake of thinking Java's collection framework is good design simply because of your own familiarity.  Times have changed and problems have been discovered, but backward compatibility has become a ball-and-chain, preventing Java from removing problematic features, other JVM languages don't have this burden.

Overall, I think the Java collections are a pretty impressive piece of work, considering the constraints in which they were designed. They are easy to use, effective and fairly versatile. Java's accidental verbosity sometimes leads to more lines of code than I'd like to see, but I would definitely call Collections a resounding success overall (they even survived their retroactive generification, which is quite a feat).

Scala's collections have some very interesting properties too but they haven't been out for an entire major version yet and they are already coming under heavy fire (read Tony Morris' blog or his rants on #scala to get an idea). That's not a good sign. The parallel collections also feature some interesting stuff but I think they have crossed the academic threshold too far to be of interest to mainstream Scala programmers.

I also find it interesting that for a language that claims to have embraced the next killer feature, parallelism (something I completely disagree with, by the way, just like Rainier), it's necessary to resort to libraries to actually get some juice out of the nice properties of immutability instead of leveraging the language. I already mentioned in a couple of previous messages to this mailing-list that Scala-the-language does close to nothing to enforce immutability, and the new collections prove this point.

In effect, we're not in a very different situation from Java's "ImmutableList.of()".

 

no semicolons: Scala has semicolons, they're just optional when it's obvious what's going on

Do you even see the problem with this kind of statement?

 

no dots: Eh, since when?  Scala uses dot notation for calling methods exactly as Java does

No it doesn't. Come on Kevin, seriously? You need to improve on the objectivity side of your statements if you want to be taken seriously.

Here is Martin's "Scala tip of the day" from yesterday:

" tip of the day: Avoid postfix operators except in a DSL. Use f.op, not f op. Much safer for semicolon inference"

 

no parens: Same as dots.

Here is another tip from Martin, from a few days ago:

"tip of the day: Never omit ()'s for methods that have side-effects."

Kevin, I'm seriously beginning to wonder if you know Scala as well as you think you do. 

Read through "Java Puzzlers" again, look at how many of those problems no longer apply to Scala...

Do you seriously think that a book called "Scala Puzzlers" could not exist?

I could write one just by taking random commits from the scalaz project.

 

It gets more complicated if you want to change the underlying structural data (i.e. the fields). For example, envisioning a way to make java.awt.Point immutable requires a lot more crazy stunts, but at least you could make a Point 'class' that is mostly immutable, i.e. will only end up changing if you pass it into code that uses the old API and that code makes changes to it.

Ahh, yes.  Such as the ability to change a public field into a method, for example.  This is known as the universal access principal, and was another core design goal of Scala,

Yes, this is great. As are traits and compact class declarations.

You repeatedly bring up the presence of folds as your main argument for the claim that Scala isn't ready for concurrency, but the truth of the matter is that folds aren't actually used very much at all in a great deal of Scala programming.

Tying the concept of folds to a programming language is quite baffling. Folding is an algorithmic concept and it's something that you have to do on a regular basis, regardless of what kind of code you are writing or what language you are using. You iterate over a collection and you perform an operation that has some sort of side effect. Some people enjoy trying to wrap the operation in a monoid so they can say that their code is pure, others just use an accumulator and move on with their life.

The bottom life is that from a practical standpoint, 1) folds are not parallelizable and 2) they are pretty easy to write in a non functional style.

 

I'll leave you with a great snippet from Glen Vanderberg: http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc

That's a horrifyingly condescending quote making fun of people who actually ship software.

--
Cédric

[Kevin Wright]

2011/3/22 Cédric Beust ♔ <ced...@beust.com>

On Tue, Mar 22, 2011 at 9:29 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

Repeated case studies have shown time and time again that imperative code is harder to reason about

Come on now. I was going to ask you for some evidence to back up this claim but the fact that there are millions of lines of code written in imperative style today is enough to prove this claim completely wrong.

Can we improve over the imperative style? Of course. But assuming that the only way to do so is by switching to a functional, actor based or asynchronous style is just the illustration of how blinded by your Scala love you are.

Personally, I find Actors and asynchronous/CP style much, much harder to reason about. It has some benefits and using such techniques is occasionally the best way to solve certain problems, but again, arguing that these techniques are an improvement over the current state of affairs with no drawbacks whatsoever is delusional.

Neither actors nor cp are actually functional programming.  Most implementations in production are actors that send messages to each other and internally mutate state.  It's a good way to handle concurrency and locking, but also still very imperative.  Not that it has to be, actors can also be completely immutable, just acting on a received message by sending another one.

This is not to dissimilar to the logical fallacy that OO and FP are diametrically opposed.

 

 

, I defy you to find me a single person who's seriously looked into the question who won't also claim that this aspect of Java's collections is unnecessary complexity.

Don't make the mistake of thinking Java's collection framework is good design simply because of your own familiarity.  Times have changed and problems have been discovered, but backward compatibility has become a ball-and-chain, preventing Java from removing problematic features, other JVM languages don't have this burden.

Overall, I think the Java collections are a pretty impressive piece of work, considering the constraints in which they were designed. They are easy to use, effective and fairly versatile. Java's accidental verbosity sometimes leads to more lines of code than I'd like to see, but I would definitely call Collections a resounding success overall (they even survived their retroactive generification, which is quite a feat).

Scala's collections have some very interesting properties too but they haven't been out for an entire major version yet and they are already coming under heavy fire (read Tony Morris' blog or his rants on #scala to get an idea). That's not a good sign. The parallel collections also feature some interesting stuff but I think they have crossed the academic threshold too far to be of interest to mainstream Scala programmers.

I also find it interesting that for a language that claims to have embraced the next killer feature, parallelism (something I completely disagree with, by the way, just like Rainier), it's necessary to resort to libraries to actually get some juice out of the nice properties of immutability instead of leveraging the language. I already mentioned in a couple of previous messages to this mailing-list that Scala-the-language does close to nothing to enforce immutability, and the new collections prove this point.

In effect, we're not in a very different situation from Java's "ImmutableList.of()".

Google Guava's... and yes, that particular library has also drawn heavily from FP ideas, and its very necessity demonstrates some of the weaknesses of Java's default collections.  Though it continues to propagate the lie at compile time that such collections can be mutated - only to risk a potential runtime error at some point in the future.

This is a requirement imposed by the pretty impressive Java collection API, and unavoidable unless you wish to represent everything as an Iterable (as clojure does)

Create a new List in Scala, try it right now, open up a REPL and type "val xs = List(1,2,3)", don't import anything first.

Now try and find the methods to mutate it.

This is the standard List implementation, as supplied by predefined imports.  The language may not "enforce" immutability, but it certainly makes it the default and demands you to take explicit steps if you want anything different.

 

 

no semicolons: Scala has semicolons, they're just optional when it's obvious what's going on

Do you even see the problem with this kind of statement?

 

no dots: Eh, since when?  Scala uses dot notation for calling methods exactly as Java does

No it doesn't. Come on Kevin, seriously? You need to improve on the objectivity side of your statements if you want to be taken seriously.

Here is Martin's "Scala tip of the day" from yesterday:

" tip of the day: Avoid postfix operators except in a DSL. Use f.op, not f op. Much safer for semicolon inference"

 

Exactly, so it's a lie to claim that Scala doesn't have dot notation.  It does, though this doesn't preclude the alternate infix notation.

You'll also note the example in my previous reply when I pointed out exactly the same avoidance of postfix operators.

 

no parens: Same as dots.

Here is another tip from Martin, from a few days ago:

"tip of the day: Never omit ()'s for methods that have side-effects."

Kevin, I'm seriously beginning to wonder if you know Scala as well as you think you do. 

Again, it's also a lie to claim that Scala doesn't use parentheses in method calls. 

Reinier didn't claim it's a problem that you can leave out dots and parentheses and semicolons in Scala, he claimed that the language doesn't have these things, that claim is false.

Just because a language will allow you to leave a thing out, it does not mean that it doesn't have that thing at all.

Read through "Java Puzzlers" again, look at how many of those problems no longer apply to Scala...

Do you seriously think that a book called "Scala Puzzlers" could not exist?

I could write one just by taking random commits from the scalaz project.

Scalaz has always been a rich source of controversy, you won't see me arguing the point :)

Though please don't use it as an example of idiomatic or typical Scala, this is a library that's truly pushing the boundaries of what the language can do.  To use scalaz as an example would be like evaluating Java based on this: http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/

 

 

It gets more complicated if you want to change the underlying structural data (i.e. the fields). For example, envisioning a way to make java.awt.Point immutable requires a lot more crazy stunts, but at least you could make a Point 'class' that is mostly immutable, i.e. will only end up changing if you pass it into code that uses the old API and that code makes changes to it.

Ahh, yes.  Such as the ability to change a public field into a method, for example.  This is known as the universal access principal, and was another core design goal of Scala,

Yes, this is great. As are traits and compact class declarations.

and case classes, can't get enough of them :)

 

You repeatedly bring up the presence of folds as your main argument for the claim that Scala isn't ready for concurrency, but the truth of the matter is that folds aren't actually used very much at all in a great deal of Scala programming.

Tying the concept of folds to a programming language is quite baffling. Folding is an algorithmic concept and it's something that you have to do on a regular basis, regardless of what kind of code you are writing or what language you are using. You iterate over a collection and you perform an operation that has some sort of side effect. Some people enjoy trying to wrap the operation in a monoid so they can say that their code is pure, others just use an accumulator and move on with their life.

The bottom life is that from a practical standpoint, 1) folds are not parallelizable and 2) they are pretty easy to write in a non functional style.

Nobody ever claimed they were parallelizable, nobody ever claimed you had to use them, nobody even ever claimed they were a particularly common practice.  I can guarantee that, at no point, is any use of folds ever demanded by the Scala compiler.

I personally find folds to be be to imperative in nature for my liking, they state *how* you are doing something and not *what* you're doing.

This is a fold:

val total = xs.foldLeft(0)(_+_)

This is idiomatic Scala

val total = xs.sum

folds are are red herring, they exist, but so what?  Reflection also exists, does that make Java a dynamically typed language because you can, optionally, do everything by passing raw objects into invoke methods?

 

 

I'll leave you with a great snippet from Glen Vanderberg: http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc

That's a horrifyingly condescending quote making fun of people who actually ship software.

Why, do you genuinely believe that Java prevents anyone from ever writing bad code by removing access to capabilities that would allow some people to write better code?

 

--
Cédric

[Cédric Beust ♔]

2011/3/22 Kevin Wright <kev.lee...@gmail.com>

I'll leave you with a great snippet from Glen Vanderberg: http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc

That's a horrifyingly condescending quote making fun of people who actually ship software.

Why, do you genuinely believe that Java prevents anyone from ever writing bad code by removing access to capabilities that would allow some people to write better code?

I can't even begin to understand how your response has anything to do with the observation I made about this quote.

I expressed my concern that you like a quote calling programmers who ship software and who don't give up "weak".

If anything, knowing that this guy would have given up long ago is what makes him weak in my eyes. Obviously, his attitude and condescension over others would be enough to put him instantly on my "no hire" list.

--
Cédric

[Kevin Wright]

2011/3/22 Cédric Beust ♔ <ced...@beust.com>

2011/3/22 Kevin Wright <kev.lee...@gmail.com>

I'll leave you with a great snippet from Glen Vanderberg: http://www.vanderburg.org/blog/Software/Development/sharp_and_blunt.rdoc

That's a horrifyingly condescending quote making fun of people who actually ship software.

Why, do you genuinely believe that Java prevents anyone from ever writing bad code by removing access to capabilities that would allow some people to write better code?

I can't even begin to understand how your response has anything to do with the observation I made about this quote.

I expressed my concern that you like a quote calling programmers who ship software and who don't give up "weak".

Okay, so I read that as:

"the developers had managed to wrestle these monstrous designs over the finish line. The sheer dogged determination it took to do so was impressive and horrifying. I would have given up [on such designs] in despair long before."

With "weak" developers being those who are set in their ways, and don't change tactics even though they can see they're experiencing problems.

If you were to interpret that statement as "I would have given up [on the overall project]", then we're in complete agreement. It *is* condescending when read that way.

 

If anything, knowing that this guy would have given up long ago is what makes him weak in my eyes. Obviously, his attitude and condescension over others would be enough to put him instantly on my "no hire" list.

--
Cédric

[Cédric Beust ♔]

2011/3/22 Kevin Wright <kev.lee...@gmail.com>

With "weak" developers being those who are set in their ways, and don't change tactics even though they can see they're experiencing problems.

If you were to interpret that statement as "I would have given up [on the overall project]", then we're in complete agreement. It *is* condescending when read that way.

This guy is a piece of work, by the way. More select pieces from his bio:

"I was fortunate enough to be one of the first few people outside Sun Microsystems to write a Java program"

"I believe that chapter to be the first mention of Java in book form, and one of the earliest mentions of the language in any print medium."

Quite a role model.

--
Cédric

[phil swenson]

I don't see the big deal.  I've seen all sorts of code that I wonder how people ever got it to work.  Some messes are actually impressive in that way.

His point was that the power of the language is not the problem, it's the coding practices.  The notion that Java being a very constrained language prevents people from creating messes is flawed.  

I don't completely buy this btw, but the point has some merit.

2011/3/22 Kevin Wright <kev.lee...@gmail.com>

--

[matthew...@gmail.com]

I've seen some very impressive messes too. What's the phrase? Ah yes:

You can program FORTRAN in any language.

I've seen some superb VB/Java/Scala/C code, and some completely crap VB/Java/Scala/C.

The quality of code is usually nothing to do with the language, but with the quality of the programmer.

Matthew.

[Ricky Clarkson]

Let me rephrase part of that exchange for a subject probably none of us is emotional about:

  "Repeated case studies have shown time and time again that driving on the left is safer"

"The fact that there are millions of cars driving on the right is enough to prove this claim completely wrong"

Is the fallacy easier to see now?

Incidentally, it is my theory that driving on the left is in general safer in manual-shift cars, as one always has their right hand on the steering wheel.  Given that most people are right-handed, that should make steering better.  This was countered by an Argentinian who pointed out that if you drive on the right your right hand is free to use a mobile phone.  Erm..

2011/3/22 Cédric Beust ♔ <ced...@beust.com>

[Cédric Beust ♔]

2011/3/22 Ricky Clarkson <ricky.c...@gmail.com>

Let me rephrase part of that exchange for a subject probably none of us is emotional about:

  "Repeated case studies have shown time and time again that driving on the left is safer"

"The fact that there are millions of cars driving on the right is enough to prove this claim completely wrong"

Is the fallacy easier to see now?

It's not exactly similar to the analogy I was making, but we can reuse yours to show the point: take all the people who drive on the right side, make them drive left. And the other way around. Then ask everyone how easy it was.

You will find that 90% of people will find that driving on the right side is easier. Of course, it's silly because it's just because 90% of the population is driving on the right side, but that's also exactly the point: everybody learns to program imperatively these days, so I find the claim that it's "hard to reason about" ludicrous.

I can assure you that a vast majority of developers today have no problem reasoning about imperative programming and they will most likely have a harder time reasoning about functional styles.

That's just what I wanted to point out.

-- 

Cédric

[Kevin Wright]

On 22 Mar 2011 21:37, "Ricky Clarkson" <ricky.c...@gmail.com> wrote:
>
> Let me rephrase part of that exchange for a subject probably none of us is emotional about:
>
>   "Repeated case studies have shown time and time again that driving on the left is safer"
>

It's true!
http://en.wikipedia.org/wiki/Right-_and_left-hand_traffic

I find the reasons for left vs. right to be especially fascinating, it all goes back to horses...

[Kevin Wright]

The unfamiliar always seems harder. But once familiar with both styles, it becomes a real pain having to read all the code between a variable's declaration and some usage, just in case it was mutated in the middle.

Declarative code is easier because it makes very obvious the bits you're interested in, allowing you to safely disregard the rest.

[Reinier Zwitserloot]

Read The post you're referring to. I never claimed this list was exhaustive, it was just meant as an example of the kinds of features that I expect the real java.next must have in order to gain enough appeal.

[Josh Berry]

On Tue, Mar 22, 2011 at 7:08 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:
> Read The post you're referring to. I never claimed this list was exhaustive,
> it was just meant as an example of the kinds of features that I expect the
> real java.next must have in order to gain enough appeal.

Right, and I'm claiming that the "next java" will have amusingly few
of the features you are calling out in your list. Not that they will
just be a subset.

And don't think I'm trying to downplay the features you listed. I
think that it is a good list. (I happen to side with Kevin in
thinking scala does a better job at them than you concede, but I agree
that it is debatable.) I just think market is more important than any
technical merits that many of us care about.

I guess my list would be this: The "next Java will be whichever JVM
language is used by a killer app backed by some heavy names."
Currently, it looks like the best bet for this is whatever you would
call the Android programming language. Failing that, I'm not sure I
see a "next java" ever happening, honestly.

[Reinier Zwitserloot]

Yes, you're right, I should have mentioned market push. It's rather likely (to me, anyway) that java gained quite a bit of traction due to Sun's cheerleading of it, along with the uptake by i.e. IBM relatively early on.

Google adopts or makes a new programming language to replace java for android development to avoid some lawsuits, and via that route we'll get a java.next. Huh. Cool theory.

[Phil]

On Mar 22, 6:08 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> That's a horrifyingly condescending quote making fun of people who actually
> ship software.
>

Worse still it is making the assumption that the people who have to
implement the design are able to influence it. There are people out
there who can write bad Java in the face of good design. They are far
outnumbered by the people who are not in a position to influence the
design in the first place, are forced to implement it and then take
the heat when it fails to deliver (usually on the non-functional
requirements, the hardest to fix once the software ships).

[Phil]

Regarding the post as discussing only low-level design I don't
completely disagree. At a low level (decomposition of components into
classes, getting assignment of responsibilities and encapsulation
correct, and so on) it doesn't matter how good the higher level design
is. To produce bad code is one thing (given the low level of training
many companies provide these days it's almost unavoidable to some
degree or other).

To allow poor low-level design to go unchallenged is indicative of a
process failure, if the post went on to say as much I'd be much more
comfortable with it - it offers an opinion but doesn't explore the
underlying cause (the process failure). Software craftmanship is at
least as important as raw coding skills, and the practices it
encompasses contribute to better low-level design.

If we include high-level design... well bad design at a high level
doesn't dictate that the low-level design of components, by default,
will be bad (even when the same person is responsible for both).

Bad high-level design will contribute to problems satisfying non-
functional requirements though (that's almost a null statement - a
high level design that allows both functional and non-functional
requirements to be met must by definition be regarded as good at some
level).

And going back to Cedric's point, a 'badly designed' product that
ships, satisfies the customer and makes money... well, from a
commercial perspective it's a success no matter how much we might
wince when we look at the code.

[Phil]

I'm left-biased ambidextrous (except for writing) and the only problem
I have driving on the right is remembering to go to the right car door
first thing in the morning ;-)

On Mar 22, 10:01 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> 2011/3/22 Ricky Clarkson <ricky.clark...@gmail.com>

[Phil]

On Mar 22, 10:06 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:

> On 22 Mar 2011 21:37, "Ricky Clarkson" <ricky.clark...@gmail.com> wrote:
>
>
>
> > Let me rephrase part of that exchange for a subject probably none of us is
> emotional about:
>
> >   "Repeated case studies have shown time and time again that driving on
> the left is safer"
>
> It's true!http://en.wikipedia.org/wiki/Right-_and_left-hand_traffic
>

Erm... I can't agree with that assertion:

1. Quoting wikipedia
2. Quoting a wikipedia article with several issues flagged at the top
3. There is no 3.

There are so many variables... quality of driver training, quality of
roads, maintenance state of vehicles, cultural issues (you have to
experience driving in Italy to understand that one), contributing
factors to accidents... you'd need several very well conducted
studies, with statistically significant volumes of data, to move
beyond correlation to cause and effect.

[Ricky Clarkson]

Italy?  I'm nowhere near there but let's just say that yesterday I saw a diversion around roadworks.. onto the pavement.

[Josh Berry]

On Wed, Mar 23, 2011 at 2:43 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:
> Yes, you're right, I should have mentioned market push. It's rather likely
> (to me, anyway) that java gained quite a bit of traction due to Sun's
> cheerleading of it, along with the uptake by i.e. IBM relatively early on.

This been my belief for a while. I, of course, have nothing to back
this up. :)

> Google adopts or makes a new programming language to replace java for
> android development to avoid some lawsuits, and via that route we'll get a
> java.next. Huh. Cool theory.

I simply meant more that I feel like Android is pulling in more new
"java" developers than any other technology out there at the moment.
For a long time, web development seemed to be the big pull to any
technology. Now, it appears that "app" development is the big pull
and that appears dominated by obj-c and java for Android. If someone
were to release a compelling dev kit for Android that had a different
language, I would imagine it would gain traction rather quickly.

[Phil]

I drove a hire car there for two weeks. Italians have two speeds - one
of them is 'stationary'. As a foreigner you either crawl along the
side of the road or drive at their speed. I had never seen ambulances
so frequently outside a town before or since. I was overtaken on
numerous occasions in the mountains... around blind corners. Once,
memorably, by a brace of Ferraris. Oh, and our Italian holiday rep
nearly crashed into our car when he came to visit us... instead he
slowed down against a dry stone wall.

On Mar 23, 1:52 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> Italy?  I'm nowhere near there but let's just say that yesterday I saw a
> diversion around roadworks.. onto the pavement.
>

[Kevin Wright]

c'mon people, please at least *try* and make it hard for me!

https://github.com/jberkel/android-plugin

Okay, so SBT doesn't exactly meet the definition of "dev kit", but it does work rather nicely to create IntelliJ projects that can happily make use of the IDE's Android plugin. :)

 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Wed, Mar 23, 2011 at 7:32 AM, Josh Berry <tae...@gmail.com> wrote:

I simply meant more that I feel like Android is pulling in more new
"java" developers than any other technology out there at the moment.

You have no idea how happy it makes me to read this.

In the early days of Android, I remember sitting at the lunch table with the (then very small) team and saying something like "If we get this right, I bet that people will start learning Java just to develop on Android". It seemed like a total pipe dream at the time.

--
Cédric

[mP]

Dont forget that left v right only exists in cars, for planes and ships everything drives on the left side of the "road" etc. Perception is everything.

[Moandji Ezana]

It seems only fair to include the Guardian's experience of switching one of their services from Java to Scala: http://www.infoq.com/articles/guardian_scala

It's an interesting report.

Moandji

On Mon, Mar 21, 2011 at 5:44 PM, ranjith <sen...@gmail.com> wrote:

OK I did not say it -
(Sorry to post a link, but it is worth it.)
http://alarmingdevelopment.org/?p=562

Dick, I am looking at you too..
Here is what Cedric beust said..
http://beust.com/weblog/2011/02/23/from-scala-back-to-java/