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.
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)
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.
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.
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.
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).