Why Java Developers Should Check Out Scala
techrepublic.com
techrepublic.com
However, as much as it may surprise, most developers of this world, as much as they would like to work in a startup, work in a gray, corporate enterprise, write Java, Spring and Hibernate, or .NET, and have no clue about anything beyond that.
Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone.
There are many Enterprise developers who are amazing developers and architects, and can benefit any startup, the more they get close to newer "trends" the more likely the connection will happen.
Young startups will benefit, 40+ enterprise Java architects will benefit, and perhaps the talent wars will have a cease fire.
I'm pushing everyone I know to take a look at Scala, it's here to stay, and if you take a look at play framework, it's looking even more like the next big thing.
It all comes down to the community, if the ruby / rails community will be scala / play friendly, and endorse it as a "ok it's Java but we hate it less", it will help it take off.
As an enterprise developer, I really need something like scala / play to take off, as I won't be able to get ruby on rails / django in the same way I could get play / lift. as much as I think they are great frameworks, it's hard to sell to the enterprise crowd.
I spent some time deciding if your first sentence was a parody (Look at us new vim mac users with functional languages and git and startups).
Very sorry that I am a C++ programmer, working in visual studio, as opposed to writing the latest to-do app in scala using vim.
No parody was intended, I have all respect to all developers where ever they are and what ever IDE / non-IDE they chose to work with.
I use IntelliJ IDEA with the Scala plugin and you get code-complete and type aware tooling.
In fact every developer I know that writes production Scala code uses an IDE.
I have fuckall of a clue what an IDE has to do with Scala except for some sort of lifestyle statement.
Groovy does the same thing with less friction and switching overhead.
Groovy is great to Websites and fast development they remove the code complexity and verbosity of java using type inference, some functional goodies like closures and add DSL capabilities,I use it everyday and it's a very nice tool.
Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example) and is way closer to the functional paradigm than Groovy, but it's more complex.
So you gotta choose wisely so you don't end up with the hammer to a screw kind of problem.
My view:
Groovy is for fast development and WEB stuff mainly because of Grails which is an awesome tool as well.
Scala is more a backend tool when you need Horse Power, but that's because the lang is more complex, I don't like Play and Lift is not as easy to understand as Grails.
Again no Flamewars please.
"it (scala) allows enterprise developers to taste some of the goodies of Ruby / Python"
Groovy fits that bill far better than Scala if you're primarily looking for a taste, without having to adopt the complexity of a new worldview.
Your answer was not the flamewars kind at all.
And yes Groovy fits perfectly in that statement.
I believe Groovy also supports actor concurrency via gPars. That said, I still haven't seen anything like Akka on any other language, specifically its distributed processing p2p feature. To me Akka is Scala's 'killer app'. I agree I don't like the new Play framework. I didn't mind the magic being taken away but with taking the magic out, they also killed any form of convenience without providing a replacement.
You can use Akka from java but the messages are effectively dynamically typed which isn't a big deal. However, as Rich Hickey said, a queue is simpler than an actor (Go understands this also). Java has excellent blocking queue implementations. In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
I still like Scala though (and really like Go but my work is on the jvm)
True, but I just got sick of Java being a 2nd class citizen on Akka.
> In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
hmmm does java have a distributed concurrent solution that isn't complex? Aside from Akka, I am not aware of any.
He made the scala statement in 2009. He's certainly entitled to his opinion. But I find the title "Author" or "Creator" a little harsh to people like Guillaume Laforge and others who have really brought the project from beta to 2.0 in the 7 years since he quit.
Jochen Theodorou led the technical effort on Groovy since then. Other major committers over the last 5 years include Paul King, Alex Tkachman, Cedric Champeau, and Jeremy Rayner. I don't know for sure about before that. Guillaume Laforge's main technical effort was writing some utility functions very early on.
Although Guillaume has the title "Project Manager", he's really No.2 to the real management force behind Groovy, i.e. Graeme Rocher, who leads the Grails development. If Grails switched languages, Groovy would disappear almost overnight as it's not used much in anything else significant. OReilly's total worldwide book sales of Groovy (all titles) over 12 months is 1205 books (http://radar.oreilly.com/2012/04/computer-book-market-2011-p...).
> really brought the project from beta to 2.0 in the 7 years since
A few weeks before Groovy 2.0's "final release" in June this year, Grales 2.1, Griffon 1.0 and Gradle 1.0 were all released, bundling Groovy 1.8. Listen to what Groovy's users are doing, not what its fanboys are saying. Groovy 2.0 is nothing more than beta-quality software offered to production users so they'll "unit test" it in their workplaces. No-one should be using Groovy 2.x until Grails bundles it.
Unlike, of course, every other piece of software's x.0 release, which are always 110% battle hardened and tested through years of rigorous process, ensuring no downtime, data loss or corruption, and smooth sailing. Yea, groovy's totally unique in that. I bet they just made some random commits during the final 2.0 bundling without even looking at the keyboard while they typed as well.
Groovy book sales were down. So what? Maybe groovymag has had an adverse impact on oreilly? :)
Groovy 2.0 bundles two jars, one for Groovy scripts using Java 7's invoke-dynamic, the other for scripts using type-checking and static compilation available via optional annotations. Invoke-dynamic and type-checking/compilation _can't_ be used together: you need to choose only one jar to use. The roadmap plan is for them to be merged together in Groovy 2.1. Groovy 2.0 should never have been released until it was a single functioning jar.
Are you the same M.Kimsal who sells subscriptions to "groovymag" ?
I don't understand what you've said here. The two terms are entirely orthogonal. There are functional langauges which are dynamically "typed", and there are functional languages which are statically typed. Lumping the two terms together is misleading and useless.
Static typing (done correctly) is just straight up better than dynamic typing. End sentence. I cannot count the number of times I have had errors at runtime working in python that simply would not have existed at all if I was using a statically typed language. With a sufficiently expressive type system, the types do not get in the way, but you still get compile-time enforced correct static semantics.
At some point I just got tired of seeing the same types of errors and wanted my tools to work a lot better. Python / PHP / Ruby aren't improved by lacking static types. How hard would it be to add static types into PHP, Ruby, or Python?
http://stackoverflow.com/questions/1365333/will-php-become-a...
A good static typed language that the only difference between it and Ruby / Python is the type system, has a good chance in being accepted by a larger audience of developers, both enterprise and startups.
People prefer dynamic as they don't like to compile, and it provides rapid code / refresh cycles, I don't think anyone would say no to less bugs and better refactoring, and to self explanatory APIs using content assist.
(If the code does typecheck, then I have guaranteed a lot of static properties of my code, but it may still be incorrect in terms of dynamic semantics.)
Scala is a great statically typed functional, object oriented language, which allows most people to enjoy both worlds.
rpearl already made a similar objection, but I think you're confusing things a bit here. How much of Scala is influenced by Ruby and Python? Aren't the main goodies in Scala related to the type system?
Programmers using those "mainstream" dynamically typed languages don't have terribly much to be smug about, sure they're less verbose than Java, but I'd suggest they should also invest in learning a functional language or two, like Scala.
scala: List(54,2,46).filter(x => x == 2) ruby: [54,2,46].select{|x| x == 2}
Here is the actual paper: http://www.rz.uni-karlsruhe.de/~kb95/papers/pankratius-Scala...
Quote from the conclusion: With respect to effort, this study refutes the claim that Scala programs are faster to develop: in comparison to Java, Scala requires more effort, and especially more testing and debugging effort.
I guess everyone has encountered the C++ is 'C with better strings and arrays'-type of programmer who doesn't use RAII or the STL. Or the template-fanatic programmer that wants to drag in template meta-programming into every corner of the project. Or the STL fanatic that wants to replace every for-loop by a function in std::algorithm, even if there is no appropriate fit or it requires building a bunch of stateful function objects (thank god we have closures now). Etc.
If projects do not impose serious restrictions, such a broad language will quickly become an incomprehensible mess.
Being a recovering C++ fanatic myself, I believe more in smaller languages try to solve a particular problem now. For instance, take Prolog, it's a beautiful language for what it is aimed at: logic programming. All the weird object-oriented Prolog experiments have died out by now, and it's a language that you use when you want to solve a particular kind of problem.
There are also languages that do Hindley–Milner type inference (ML, Haskell) with good compile times.
1. Examples using outdated low level concurrency primitives such as wait and notify. Use of java.util.concurrent would have made the code much more terse and safe
2. Java performance affected by use of the outdated java.util.Stack class. It is well known that this class uses redundant synchronization. The docs recommend using a Deque implementation instead.
Even so, I run into the infuriating aspects of Java from time to time, and that's when Scala comes in. I see it to Java as Coffeescript is to Javascript.
Better: Why Language Developers Should Stop Making Languages on Top of the JVM.
Imagine if Ruby or Python were only available on top of the JVM... There may be a need for versions of a language that live in the JVM, but don't make the entire ecosystem dependent on it.
If enough people care about Scala they'll make it work independently of the JVM. JVM-based Scala is perhaps a good way to bootstrap the language, but I don't see how it's a great long-term strategy.
Tons of similar and true examples. What about: If enough people cared about java they'd make it run without the jvm.
the JVM is still here to stay, and many Ruby web apps move to JRuby when they need to scale, and this is a fact.
If we want to close the gap between enterprise and startups, Scala is a great way to go. and I'm sure it will have non JVM versions in the future, if not already.
My language of choice at the moment, I like Ruby and Python, but I like a static typed language, I got used to it.
Which is part of why it's so mature despite being so young. Open-source languages that don't target a managed environment have historically needed a lot longer to marinate than Scala did.
Marination is generally a good thing. Things come out tastier. Same for new languages. The robust Python / Ruby / PHP ecosystems seem to be working just fine without the JVM.
Me too. After all, Scala's engineers weren't looking to create a whole new platform; they were just looking to create a new language. And a good engineer won't waste enormous amounts of time working on out-of-scope tangents unless there's a good reason to do so.
NIH doesn't count as a good reason.
Not sure how that's going to work out much better than all the great tools that were built on top of Microsoft's MFC framework. People didn't realize that it was a bad idea until it was too late to change.
Sometimes in CS it really makes sense to build things slower and more carefully to avoid issues that may only come up years down the road.
Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice).
(To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds).
Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.
Sure it does.
object f {
def apply(x: String) = s + " - foo"
}
val t = f("bar")EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code:
class F(object): def __init__(self): pass
def x(self, s):
return s + 'hi'
Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
"When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
So it's much closer to:
class F(object):
# you can't actually do this in Python, because F() isn't bound at this
# point, but that's close to what Scala does.
__name__.f = F()
def __call__(cls, s):
return s + "bar"
f("foo")
> "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
Now I've lost track of what you're quoting from, but that's by definition very OO. It's a modified form of the messaging pattern employed by Smalltalk.
Scala isn't a functional/object-oriented hybrid; it's purely object-oriented (even more so than Java) because it has one single kind[1]: the object (Java pretends to have one, but it really has five, if you really wanted to get pedantic).
So we shouldn't be celebrating Scala for being a functional hybrid - we should celebrate as being 'OO done right' (well, mostly right), which was the stated and failed intent of Java.
The distinction is subtle, but the important thing to remember is that I'm operating on the premise that proper OO is essentially a subset/extension of FP, not an alternative. So what I'm saying is that this doesn't show that Scala is 'more functional' (vs. 'less functional') - rather, it shows that Scala is good OO (vs. bad OO, ie Java). I agree that it's a bit like the 'white horse is not a horse' argument, but it becomes important when we start talking about non-white horses; ie, functional languages that aren't OO).
[1] I'm kind-of (no pun intended) abusing the term 'kind', but I can't think of a non-overloaded synonym as the moment, other than 'type' which would be worse.
Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)
It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects.
In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions.
> the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me
Which probably means that most of this discussion may be irrelevant to your interests too. :-)
That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value.
But if you really care, let me try and explain the following:
> If module-level functions are important to the question I would like to know why. :)
Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object.
In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type
psuedocode:
type Object
type ScalaFunction extends Object
type NonFunctionObject extends Object
Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen.
For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.
Agreed - that's my whole point. It's better to think of object-oriented programming as a construction within FP. Of course, some (badly-designed) OO languages like Java sandbox you and restrict your access to some of the more powerful, higher-order concepts, which is why they seem to be 'in conflict', when in reality, one is just a more abstractly implemented, whereas the other's more specifically implemented.
> Scala is a perfect example of a language which is both.
No, it's not - for example, functions have to exist within an instantiation of a class (a singleton object counts). By providing true first-class objects (unlike Java), you get many of the same benefits as first-class functions, but it's fundamentally not the same thing.
Really, an easy way to create a language which supports both is to start with a very basic language with true first-class functions and closures (like Lisp) and then define a few closures that encapsulate state (objects), and then add a couple of basic macros that turn generic functions into bound methods (ie, automatically provide the implicit parameter instead of calling it explicitly).
...which is why I agree that they're not in conflict - a well-designed OO system can be easily implemented within a well-designed functional system!
(The reverse doesn't work so well because you can easily add an implicit parameter to generic functions, but you can't completely remove an implicit parameter from a bound method, even if you pretend it doesn't exist - ie, treat all methods as static methods).
object Foo {
def f1(x : Int) : (Int => Int) = {
return { y : Int => x + y }
}
def f2(f : Int => Int) : Int = { return f(5) }
val f3 = f1(1)
val f4 = List(f1(2), f1(3), f1(4))
}
But function objects are not on equal footing with non-function objects. You can nest function objects or non-function objects inside other function/non-function objects, but at the root, you need an object that isn't a function.
At the end of the day, yes, you can do the same things, but my original point was that this doesn't make Scala functional: it makes Scala object-oriented (Java, by contrast, is not properly object-oriented, because it has four kinds that aren't objects).
Some wikipedia: "JRuby supports interpreted mode, AOT mode, and JIT mode (the last two modes are available since version 1.1[19]). JRuby evolved from being several times slower than Ruby Reference implementation[32], to being several times faster.[33] [34]."
I learned a bit of Scala and I think it's a awesome lang, if you have time to learn it properly otherwise it might to pull your blanket, because it's a little trick at some things.
I would definetly like to work with it, in fact I plan use it in my next side project together with Backbone.js
The JVM is very fast and ubiquitous. Targeting the JVM allows the language developers to focus on the language rather than re-inventing a runtime (which is a monster project)
http://www.infoworld.com/d/application-development/scala-the-android-programming-language-you-didnt-know-you-had-170999
Admittedly, that's an article from 2011, and it's probably on hacker news somewhere already, but still...
This is why I tell folks to avoid Scala and pick one of two other great options which offer a fundamental change from Java:
* Groovy (dynamic lang, easy to pick up _and_ master) * Clojure (the power of LISP, steeper learning curve)
There's a bunch of stuff out there which explain why NOT Scala, so I won't regurgitate it here.
http://www.amazon.com/Scala-Depth-Joshua-Suereth-D/dp/193518...