> We need, at minimum, compilers (not new languages) which> parallelize linear client code. We need, fully, a new> hardware architecture which accepts linear code and> executes it in a parallel fashion. So far, no volunteers.

This isn't going to amount to much. There's not enough information in the code to allow for large increases in speed. In addition, many algorithms that are commonly used cannot be parallelized. Different algorithms are required. This is even true for FP.

To the last comment. It is already over 25 years since parallel computers emerged as the means of solving complex tasks that can be split into parallel processes (finite element techniques, for example). There is not much progress in this area since then. We still do not have any decent languages, compilers, debuggers, etc. We still struggle with tasks to determine whether they can be concurrent, etc. It seems that all this is still in the early stages of understanding and development and is more for college professors and post-graduates than for real software practitioners. Same thing seems to be the statements that Scala will eventually take over.

- "Java's designers were consciously designing a product for people not as smart as them."

Scala seems to have the goal of providing the developer with a lot more power, and with it the responsibility to learn how to use that power effectively, so in some ways it's a bit like a Jedi training school...

The truth is that Scala presents a learning curve, but many programmers don't much care for learning outside of university, and simply want to get their job done and go home to see the kids. Fortunately for me, coders of this sort tend not read Artima :)

By integrating so closely with Java, Scala will readily lend itself to writing libraries, system-level code, and in situations where FP is obviously the right approach. This functionality can then be easily consumed by the non-Jedi Java coders that still make up the bulk of the IT industry.

I'm sure that Scala will have a growing place on the JVM, and that it will continue to draw the brightest, most driven and most passionate developers away from Java. But as a replacement? That would likely only happen if it was taught more than Java in colleges and universities.

> Doesn't Haskell cover all the parallelism issues, plus it> provides the very best FP out there?> > Is there something more that it is required than Haskell?

Haskell is mind-bogglingly well architected, but it won't run on existing virtual machines, or make use of OSGi for runtime management, or be amenable to existing techniques that the operations team have already learned for dealing with Java deployments.

The barrier is in the ecosystem, and the steep steep learning curve, and the support infrastructure, and the available optimised database connectors, and vendor support. Everything that's needed for a large-scale enterprise deployment basically. The actual language syntax is a minor consideration.

Scala can be deployed and managed as though it was Java (after all, it's just classfiles and bytecode by the time it hits a server).

Compatibility is considered paramount. Although this has caused some challenges in designing the language, it must surely also be the greatest strength in terms of encouraging adoption.

> To quote from: http://www.paulgraham.com/javacover.html> > - "Java's designers were consciously designing a product> for people not as smart as them."> > Scala seems to have the goal of providing the developer> with a lot more power, and with it the responsibility to> learn how to use that power effectively, so in some ways> it's a bit like a Jedi training school...

I think the idea that Java is for 'not as smart' people is really wrong-headed. I would rephrase it this way: Java's designers were consciously designing a product for people with different priorities than them.

Java is far from perfect, even for the target audience but the above idea was a stroke of genius. The main reason so much software is unusable garbage is that the designers don't think about what the users need. They dismiss everyone who doesn't think like them as stupid. If they think of the users at all, they treat them like children.

I agree with you in general. Scala addresses some major flaws in Java but isn't designed for the same target audience as Java. That doesn't make it bad, it just makes it less than a full replacement for Java.

> Haskell is mind-bogglingly well architected, but it won't> run on existing virtual machines,

Why does that matter? Haskell has its own runtime environment.

> or make use of OSGi for runtime management,

I have no idea if such a beast exists for Haskell, but remote installation/uninstallation/start/stop/update of services may not be that difficult; certainly no more difficult than native services, since Haskell code is compiled to native executables.

But why is this important? I don't know anyone that uses OSGi.

> or be amenable to existing techniques> that the operations team have already learned for dealing> with Java deployments.

Maybe these techniques are redundant with Haskell.

> The barrier is in the ecosystem,

Haskell, despite what you or I think, has a lot of libraries.

> and the steep steep learning curve

It's actually easier than Java.

> and the support infrastructure,

I think the support infrastructure argument is overestimated for its importance.

>and the available optimised database connectors

I think Haskell can use the native ones. I have no idea if there are connectors in Haskell.

You have a point, but the things you mention are not that critical for most businesses. It's not that every business has that big needs.

> Compatibility is considered paramount. Although this has> caused some challenges in designing the language, it must> surely also be the greatest strength in terms of> encouraging adoption.

I think it depends on the task at hand. If you write a module that only communicates with other modules via messages, then you can do it in any language. In this case, the language is more important than the infrastructure.

> > Scala addresses some major> > flaws in Java but isn't designed for the same target> > audience as Java. That doesn't make it bad, it just> makes> > it less than a full replacement for Java.> > Oh yes, I agree with you 100% on this!> > It's a companion, and a strong and necessary one at that,> but I think it would be foolish to push for a full> replacement :)

I actually think that the idea of one language for all purposes is a very naive idea. In my current role, I can't see us using Scala but in a different context, it would probably be at the top of my list.