Follow Slashdot stories on Twitter


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Scala? (Score 1) 623

by dcs (#35807896) Attached to: Red Hat Uncloaks 'Java Killer': the Ceylon Project

I hear that argument often enough. What I never heard of is someone who consider himself one of these "Schmucks" -- the Schmucks are always "others".

In fact, it's my belief they don't exist. Not that there aren't bad programmers who write bad programs in any language they come in contact with -- just that there really isn't this mythical threshold beyond which some programmers can't write any program at all -- instead of just producing the bad programs they have always written.

And to write any enterprise Java program nowadays means a knowledge of application servers, annotations and annotation processors, JNDI, and, more likely than not, half a dozen frameworks such as hibernate, a web framework, testing framework and mocking library. Compared to learning all that, closures is a non-issue, currying and currying a curiosity. Path dependent types might be equivalent magic to stuff such as GUICE dependency injection -- something to be repeated by rote learning instead of truly understood (and one is way less likely to stumble on a path dependent type than on a smart annotation).

Much on the contrary of what is claimed here, Scala gains ease acceptance on Java shops that try it out. Take a look at INFOQ's recent interview about The Guardian's introduction of Scala for an example of that.

I have only ever heard of two persons who tried out Scala and didn't like it, one of whom was as much turned off by a bad experience with IDE support than anything else.

Simplicity does not precede complexity, but follows it.