I'm really pleased to read this blog post. I went to JavaOne this year (free ticket, I wouldn't have paid or asked my employer to pay), and it was kind of depressing. I hadn't been there since the early 2000s, and there just wasn't much spirit in the room. I'm sure the down economy and Oracle takeover had people down a bit, but I also think "Java programmers" (meaning folks who do a lot of work in Java) no longer feel excited about the future. It's starting to feel like you're at a conference for legacy systems.
I got out of my funk by attending absolutely ever session on Scala I could find, and it really did lift my spirits (I swear I didn't intend the pun). I've been learning Ruby (and I'll stay on that path for a while), but the Scala talks gave me what I ultimately go to conferences for - the opportunity to get excited about the future again.
Despite having invested a bit of time and brainpower in Erlang, I have a suspicion that Scala is more likely to be a better bet over the long haul. It's fast, piggybacks on all the software out there for Java, and seems to be reasonable to use.
I do have some questions about its concurrency abilities though (not rhetorical ones, real ones): I know that Erlang deals really well with concurrency, because of its internal scheduler. It's fairly difficult to completely wedge Erlang, in other words. How does Scala work out from that point of view?
Either one obviously can be used for a great deal of things, that's not what I'm questioning. Mine is more a question of how the theoretical limits of Scala actually impact its real world usage and in what situations.
BTW, in terms of noting points, high end phone systems having N nines uptime is definitely a point for Erlang:-)
No, wondered why he was restating the obvious. There are certainly features of both C++ and Smalltalk which would be nice to have in it, but Java is, on the whole, an advancement over them.
In particular, GC and a great standard library for C++, and file-based and more performant (yes, yes, hotspot is based on a smalltalk derived vm, blah blah, the numbers still grossly favor java) and a more conventional interaction with the host system over smalltalk. The last is bizarre as java still absurdly sandboxes away the CRT. Oh well. Less of an advancement on Smalltalk, more of a more palatable branch of evolution, maybe.
I think it was Paul Graham who said Java was an evolutionary dead end (which doesn't mean dead so much as that branch of the tree won't continue).
It seems now at least the JVM, or the best bits of it will spawn other branches.
As for the java language (which is probably what pg was referring to?) - I agree it is probably a dead end. Except in some shallow basic syntactic sense - javascript and so on (the continuation of the "curly braces") - not sure if that means anything though. In any cases, certainly the lessons learned will continue (what worked well, what didn't) into a whole lot of other languages and has been.
"No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time."
This may be why he didn't even mention Clojure; too open, not enough B&D for his taste.
It's just the way cycles work. Few years of over exaggerated OOP hype, then few years of over exaggerated functional hype.
Some people just like taking things to extremes and seeing things in completely polarized viewpoints - good vs evil - rather than recognizing that both are great in different circumstances.
It's a lot less tiring (and more productive) to use whatever tool fits the job best, rather than whatever tool is currently in fashion IMHO.
I think it's overloading (punning on static type of the same function, operator, or method name) that makes explicit type declarations more often necessary in Scala than in Haskell or ML.
I agree 100%. Despite Scala's hype and functional influences, it's most exciting to me simply as another option for the JVM, and another "tool in the toolbox."
Assuming you consider something JVM-based an eligible tool for a job, you have a wide variety of programming languages on a common platform to pick from. While it's probably not a good idea to apply them all in a project, it's nice to know that in the future the probability of you being able to reuse code in disparate languages increases.
Scala isn't really all that FP. Marginally more so than, say, Perl. It's more like: most of the advantages of Ruby, Java and Erlang in one place, with very extensible syntax.
You're not going to get "most of the advantages" of Erlang in a language that includes imperative OOP and runs on the JVM. The reliability of Erlang is built around features like:
* Upgrading code while it's running. In Erlang, this works because all program state is explicitly passed as parameters to a tail-recursive main loop, so there's a clear place where one version of the code can cleanly take over the state from a previous version. This won't work in a language with singletons, and mutable objects that mix code and data.
* Modularizing a program into tens or even thousands of lightweight shared-nothing processes. Erlang can do this efficiently because of key properties of the language and VM. For example, the entire language and all of its libraries use persistent or copy-on-write data structures, so that processes can share memory without sharing mutable state. This won't work in a language that's interoperating with Java libraries, and whose own data structures aren't 100% immutable.
That's my issue with Clojure as well. A language that provides and encourages use of a foundational feature X doesn't seem ideally coherent if it depends on usability provided from (Java) libraries which are unable to make use of that feature X.
Yes, but Scala is a less polished FPL than Haskell. If you're using Scala instead, it's because you love OO, want convenient global mutable state, aren't interested in the purity (read: B&D) of Haskell's effect system, or want to use Java libraries.
I like to think the shift is occurring, but at times I feel like my view comes from spending most of my time in an insular community that finds FP exciting. When I meet with other programmers I become less hopeful.
Well, Groovy has never been "sexy" (in a CS sense) in the way Scala or Clojure are perceived to be.
Despite that (or perhaps because of it) my experience has indicated it's in wider use than either, and it has some enterprise-y backing (SpringSource) so I expect it's not going away.
Both Scala and Clojure are attracting people who weren't originally on the JVM though, which (again anecdotally) I don't think you can say of Groovy.
Caveat: some of these jobs might be talking about how groovy they are. On the first two pages of http://www.indeed.com/q-groovy-jobs.html there were 19 groovy-lang jobs and one false positive.
The idea that Groovy attracts more people who are currently working in Java seems to mesh with my experience. Coming from very little experience with Java, I have a hard time choosing Groovy over something like Scala (or Clojure).
I don't think there's anything necessarily wrong with Groovy. I don't personally care for it; but as far as I'm concerned the more languages the better when it comes to the JVM.
Debateable -- but in any case one strike against your theory is that C can be made to compile using a C++ compiler, but no amount of contortions will make your Java do the same for Scalac. C++ has a lot of baggage in the form of source-level compatibility with C while Scala does not. It is API compatible, but that is one of its great strengths.
I have to say that I find scala's syntax supremely ugly. I think Ruby's niceness comes from being to look at several lines of Ruby and say "I get that, that's nice". My reaction, looking at lines of scala, is "WTF, that's obscure yet verbose". I don't know what all the dynamics are for language acceptance but I hope to God that that scala's ugliness works to its disadvantage.
I think this has to do a lot with how people expect to think and not being able to reuse the parsers you've built up in your brain.
For example, Ruby goes for the "English" approach. E.g. the "foo.double.addOne" means "take foo, double it, then add one". You can sort of use the parts of your brain that parse natural language to read the code.
Other languages are based on various mathematical construct, such as the more functional languages where a function application is done in the opposite order of natural reading, e.g. in "1 + (2 * foo)" the "1 + " application is actually the last thing you evaluate, though it is the first thing you read. This requires you to store a lot of scope information in your mind as you parse complex expressions.
However, if you have a very strong functional language I believe it can be quite pretty in its own right as you start to think in terms of higher-order operations. For example, point-free function composition frees you from having to read additional and lengthy function declarations with their own variables and scope and lets you simply see that this composition is just a way of applying multiple functions to obtain a higher-order operation.
In short, I think it's largely about how comfortable you are to think with various mathematical abstractions that determine how ugly a language is. Note that it's possible to write ugly code in any language.
I think Ruby is great for writing code that reads like English and communicates its intent clearly, but when you need to read what the code actually does instead of what the author intended it to do, then Ruby is just as difficult to read as Scala.
I think scala partly achieves some of that "beauty" you describe, but it has made (or had to make) some compromises that make it perhaps less pure then the ideal (that means people can write things in the more imperative style just fine - not sure if thats a good things or not, but thats the way it is).
I got out of my funk by attending absolutely ever session on Scala I could find, and it really did lift my spirits (I swear I didn't intend the pun). I've been learning Ruby (and I'll stay on that path for a while), but the Scala talks gave me what I ultimately go to conferences for - the opportunity to get excited about the future again.