Scala as long-term replacement for Java(macstrac.blogspot.com)
macstrac.blogspot.com
Scala as long-term replacement for Java
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
39 comments
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?
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?
Take a look at what Jonas Boner is doing with Scala OTP:
http://jonasboner.com/2008/12/11/real-world-scala-fault-tole...
and
http://github.com/jboner/scala-otp/tree/master
Stealing some of the great ideas of Erlang and re-implementing them in Scala.
Stealing some of the great ideas of Erlang and re-implementing them in Scala.
There are a couple of nice articles about Scala vs. Erlang, although they take a more nults-and-bolts view:
http://www.infoq.com/news/2008/06/scala-vs-erlang http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/
-m
http://www.infoq.com/news/2008/06/scala-vs-erlang http://yarivsblog.com/articles/2008/05/18/erlang-vs-scala/
-m
Yeah, Yariv points at what I suspected, that the Erlang model is a bit more robust. However, I wonder if Scala is, in practice, 'good enough'.
Twitter backend processing was rewritten in Scala.. Though I dont have specific opinion yet about Scala, that is a point to be noted.
While we're at it: the backend of the Facebook chat is coded in Erlang. 1-1.
No peculiar opinion about any of them either, btw.
No peculiar opinion about any of them either, btw.
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:-)
BTW, in terms of noting points, high end phone systems having N nines uptime is definitely a point for Erlang:-)
I've written tons of Java over the last decade or so & think its been a great evolutionary step from C++ and Smalltalk
Did anyone else go wtf?
Did anyone else go wtf?
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.
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.
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.
A later comment clarifies his bias:
"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.
http://www.c2.com/cgi/wiki?BondageAndDisciplineLanguage
"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.
http://www.c2.com/cgi/wiki?BondageAndDisciplineLanguage
Is it just me hoping against hope, or does it look like the world really could start shifting into a more functional paradigm?
Or at least the parts of the world that doesn't bill by the hour/LOC..
Or at least the parts of the world that doesn't bill by the hour/LOC..
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.
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.
...and my impression is that FP and OOP are complementary rather than mutually exclusive. But I only have basic understanding of FP.
Yes. Alas, most of the automagic type inferences we are used to in FP languages (Hindley-Milner) does not play too nice with OOP's class members.
What if class members had to be typed?
They are (in Scala).
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 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.
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.
Let's see:
- immutable types - lambdas and closures - tail recursion optimization - first order functions
... Sounds a lot like an FPL to me!
- immutable types - lambdas and closures - tail recursion optimization - first order functions
... Sounds a lot like an FPL to me!
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.
Haskell has also been around 13 years longer than Scala.
It's no wonder it's more polished.
It's no wonder it's more polished.
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.
* 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.
What are these different circumstances or different kinds of jobs for which an OO language is a better fit than a functional language or vice versa?
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.
-m
-m
I asked this at reddit as well, but I think HN may have some better insights.
What does this say for Groovy (the language) that one of its co-creators is out advocating Scala?
What does this say for Groovy (the language) that one of its co-creators is out advocating Scala?
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.
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.
Confirming your second point, Indeed's job trends suggest that groovy has more jobs, and that it's growing faster: http://www.indeed.com/jobtrends?q=groovy%2Cscala%2Cclojure&#...
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.
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.
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.
Scala is to Java as C++ is to C.
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.
-m
-m
[deleted]
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.
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).
If you like point-free, you want Haskell. Scala can do it, but it's not as pretty.
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.