Yes, switching to Akka would almost certainly have solved the OoM problems. That's the whole point. We had to switch from the original code. The choices were: move to Akka, wait for 2.10 (when Akka replaces the default actors implementation - and whatever migration was involved), or rewrite. Given that we're getting heavily into Clojure, it seemed a worthwhile spike to create a Clojure version to see how it performed...
Was the original code bloated? I don't think so. I've written a LOT of code over 30+ years in dozens of languages. When the Scala code was written two years ago I was very impressed with its conciseness compared to Java (and other languages). My experience has been that Scala is 3-4x more concise than Java in general (and sometimes as much as 10x more concise) but Clojure is even more concise.
If you're learning Scala, don't let this put you off: Scala is an incredibly impressive language. Odersky and his team have done an amazing job.
I have a comparison too: a rather different kind, but no less reasonable for this sort of game, and with all source available -- http://www.hxa.name/minilight/#comparison
It says that languages do not vary by factors of 10. Considered as pure 'lexical structure' the range is about 2 or 3 between small and large. Anything more than that must have some reason -- most probably library support.
Of course, library support is important, and quite fair to be compared in lines -- it represents real work that has to be done. But it seems worth trying to distinguish it as a library matter -- or whatever else.
Scala is up to "10x more concise" as Java - your numbers suggest as they represent more or less the same structure in Scala and Clojure - a 4x reduction from Scala to Clojure (260 loc vs. 1000 loc).
This would result in a 12x (4x3) to (4x10) 40x reduction from Java to Clojure. Which is hard to believe.
Take this example where [edit] Python is compared to Java with a 1.7x size reduction:
Could you give an example to reduce this code by 12x, or even by 40x? The biggest reduction LOC would probably be the reduction in constructor size with Scala case clases.
Your math is a bit off: Scala can be _up to_ 10x more concise than Java. This specific Clojure code was either 3x or 4x more concise than this specific piece of Scala code (based on char count or line count).
My experience over the last few years suggests that Scala code can be anything from 2-3x to 10x more concise than Java. My experience also suggests that Clojure code can easily be up to 10x more concise than Java. I don't think too many people would argue with that as a general rule (or at least, not too many people who've programmed in all three languages :)
I'll take a look at the link you posted and respond in more detail later.
Could you elaborate on the point where my math is off?
You mentioned a range from 3-10x between Scala and Java, and we have a 4x multiplier with your code (260 LOC Clojure vs. 1000 LOC Scala). This would result in a 12 - 40x range which I quoted in my comment.
I also find it a little discomforting that "Scala is 3-4x more concise than Java in general" becomes "my experience over the last few years suggests that Scala code can be anything from 2-3x" in a matter of minutes.
You're sure about your numbers? Not wanting to be offensive, but it sounds a little like you pull them out of thin air.
I think you're striving for absolutes where only relatives exist.
You're right that I said 3-4x in one place and 2-3x in another. Sorry. It's a gut feeling. Is it 2x, 3x, 4x? One of those. Any of those depending on the code. Somewhere in the middle. It's going to depend on the specific code. You can't reasonably suggest that language X is always Nx more concise than language Y, surely?
So, somewhere in that space, Scala is a substantially more concise than Java (will you allow "substantially"?) and Clojure seems to be substantially more concise than Scala.
A little bit disappointed about the down votes, I'd hope we as an industry take numbers not so lightly and find "Is it 2x, 3x, 4x? One of those." no longer comfy.
I'd also hope we strive more towards "Extraordinary claims require extraordinary evidence" and more science than folklore.
1.7x is probably misleading here. The example in the post is less than 100 lines long, which makes it very difficult to tell how the python code could be shorter. For example, in this tiny example program he writes, the author creates a "artist" class:
class Artist:
def __init__(self, name):
self.name = name
def __str__(self):
return self.name
Anyone familiar with python will realize that if this is the only functionality you need, than a bare string could be used instead, eliminating this code entirely.
At the end of this article (Update 3), the author links to a blog post that describes a reduction in lines of code from 90,000 to 12,000 after a re-write [1]. He claims that this reduction is more the product of increased domain knowledge than any sort of language benefit.
I think that really gets at the crux of the issue. Rapid prototyping, ease of understanding, clarity, ease of modification, could not only be equally important to code size, but could also directly influence it.
"Anyone familiar with python will realize that if this is the only functionality you need, than a bare string could be used instead, eliminating this code entirely."
Your argument was: the LOC is too high compared to Java because a class is used instead of a String? Or is there a shorter syntax for constructors, methods and attributes?
Well, the only methods implemented in this class are the __init__ method, which is a constructor and the __str__ method which tells Python what to spit out when print is called.
Since Python has the capability of duck-typing, if I had an instance of an artist class, and a string with the artists name in it, I could use them in the exact same way with regards to the functionality implemented in the artist class. That is, I could type "print some_artist" and either would print out the name.
But, my larger point was that lines of code is tied in to a much more complex relationship that the developer has with their language and the problem domain. And that this is kind of a silly example to claim that Java is 1.7x more verbose than Python.
Exactly... in this case, the functionality of Artist() is a subset of the functionality of str(). In Python, you would just name the variable "artist", assign a string to it, and be done with it.
Yes, switching to Akka would almost certainly have solved the OoM problems. That's the whole point. We had to switch from the original code. The choices were: move to Akka, wait for 2.10 (when Akka replaces the default actors implementation - and whatever migration was involved), or rewrite. Given that we're getting heavily into Clojure, it seemed a worthwhile spike to create a Clojure version to see how it performed...
Was the original code bloated? I don't think so. I've written a LOT of code over 30+ years in dozens of languages. When the Scala code was written two years ago I was very impressed with its conciseness compared to Java (and other languages). My experience has been that Scala is 3-4x more concise than Java in general (and sometimes as much as 10x more concise) but Clojure is even more concise.
If you're learning Scala, don't let this put you off: Scala is an incredibly impressive language. Odersky and his team have done an amazing job.