No amount of tooling in the world is going to fix scala's uncanny ability to throw tantrums the moment you make some typos.
Scala is like an older ferrari or lamborghini. Very very cool, but the thing will bite your head off unless you're a trained expert. Until scala makes some steps to address this issue, it'll never, ever, ever, take java's throne amongst the larger enterprises where, between the lack of 'cool' that chases away superstar programmers, and the simple vast amount of people they hire; making sure they're all entrenched programming geeks is simply infeasible. The 'this is just another job' programmer simply will not enjoy actual scala usage. They might like the demo, they might like the talks, but once you leave them alone with scala, a bug report, and a few hours to fix it, they'll start whining, and fast. That's possibly good news - not having to worry about that segment of the programmer market is a relief, I'm sure. I'm just posting to make sure no one makes the mistake of confusing scala for an enterprise development language. I'm not sure if Odersky had this in mind when he says that 'scala' stands for 'Scalable Language', but if he is under the same misunderstanding as Michael Neale, that Scala is quite close to being enterprise ready, he'll be in for a surprise. Even python can easily claim to be an enterprise development language. If you screw up, its easy to fix it, and there's plenty of introspection stuff that any intro-level programmer can follow. It might not lead to code thats as stable (jury's still out on that), but at least the folks on the line know what the next step is, instead of spending 5 hours fiddling with scala itself and delving into the Scala specs just to figure out why in the world the compiler isn't doing what they think it ought to do. The first case (bugs) can be modelled and planned for to some extent. Wrestling the compiler isn't something you can even write down on a timesheet without getting laughed out of the room. Enterprise? No. Absolutely not going to happen. Incidentally, this doesn't mean I put any faith in the 'dumbing down' arguments either. But for a slightly different reason: If you take a good look at the virtualization-by-default strategy that java has used to find the class with the 'right' implementation of a called method, which has been there since day 1, it's actually very very complicated. A good number of suggestions that are often denigrated against with a 'the masses will not get this' argument actually tend to simplify class structures somewhat and/or allow you to do things which are otherwise not possible without using a far more complicated solution, or using a carefully constructed class hierarchy (which brings back the virtualization complexities). Simple case in point: The oft stated whine that extension methods mean that you no longer know which method is actually called. Yeah. So?. That's ALWAYS the case in java - you NEVER know. Unless the method (or the entire class) of the type of your reference is final, it's always a mystery. Getting back to the topic of scala: Scala is 'academic' - and I mean this in the sense that scala will go to a great length to ensure that pretty much everything in the standard handbook of 'stuff that might throw some programming languages for a loop' isn't just possible with scala, but actually looks great. This is a fine goal for any language, but in its attempt to be like this, it has numerous features which make compilation a fundamentally complex ordeal that unnecessarily gets in the way of intelligent tools. A cross between java and scala with a big helping of tooling awareness would be perfect: A language that runs on the JVM, has no qualms about breaking the mold (and backwards compatibility), adds far more support for semantic awareness of what your code is supposed to do (such as the notion that scala has far -more- typing than java does), and is based on the notion that you program in it using a fairly intelligent environment instead of a dumb text terminal*. *) That presumption is the downfall of many programming languages. Java can't really gloat here; java's relative friendliness to IDEs is more serendipitous than a design goal by the original oak crew. I'm still baffled that virtually nobody in the academic programming language world accepts that IDEs are not just a fact of modern programming life, but actually the next evolution in programming languages: there are fundamental limits to the concept of passively waiting for the user to fill a dumb terminal with characters, then taking over from the user and parsing these characters into a process that eventually leads to the code's execution. These limits are simply not neccessary anymore. On Dec 16, 4:10 am, Michael Neale <[email protected]> wrote: > Indeed. > > Barely related, but I have been meaning to post: the current state of > the scala tools is really quite good. > > I looked at IntelliJ 8 with the scala plug in - amazing. You can even > mix java and scala source, and the maven plug in support is phenominal > as well. > > So the path is open to do incremental porting of an app from java to > scala. > > You can even run the regular unit tests you have from IntelliJ (that > got me very excited - being able to keep runing unit tests as you port > is awesome). > > I see no reason scala could not be used if nothing else, as a much > much better java, in the same situations. > I don't buy the whole "dumbing down cause all the people I work with > are idiots" implication in that a language is too complex. > > You don't have to be too clever if you don't want to or don't need > to. > > A lot of the baroque patterns that are used in java apps to work > around things (and heavy use of external config languages and XML) > could be replaced if you use something like scala, if you want. > > On Dec 15, 9:28 pm, "Viktor Klang" <[email protected]> wrote: > > > Jonas also happens to be a really great guy. > > > But back on topic, > > > I think it's fairly wrong approach to apply the same solution to two totally > > different languages. > > The questions we've got to ask ourselves are: > > > 1) What purpose did the JEE containers serve for Java? > > 2) What purposes needs to be served for Scala? > > > Because I _know_ that alot of frameworks and patterns in Java only exist > > because of fallacies in the Java language itself. > > > Cheers, > > Viktor > > > On Mon, Dec 15, 2008 at 11:08 AM, Frederic Simon > > <[email protected]>wrote: > > > > In the latest Java Posse Round Up their was a session about how to > > > make scala catch up with JEE. The need for DI, AOP and so on. > > > Basically what's needed to have a clean container API in Scala. > > > > Just found out that Jonas Boner just did it :) > > > First the DI: > > >http://tinyurl.com/6jvxzh > > > Then the AOP: > > >http://tinyurl.com/6saxv4 > > > > Did not read it all but looks great. > > > -- > > Viktor Klang > > Senior Systems Analyst --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
