The truth about Scala(cakesolutions.net)
cakesolutions.net
The truth about Scala
http://www.cakesolutions.net/teamblogs/2012/03/01/truth-about-scala/
83 comments
I think I've figured Scala out. It's a statically typed JVM language meant to be more powerful and at the same time easier to use than Java. It's a functional language. Though, it's also imperative. And object-oriented. It favors immutability, except that mutability is just as easy (or hard). It has adopted the actor model. But it has also adopted all of Java's concurrency constructs. It was designed as a very practical language. And it's also a research language with some experimental features. Oh, I almost forgot: it is meant to be a high-performance language. But it's also designed to build DSLs. It's a very opinionated language in the sense that it's opinion is that all opinions are valid.
So I must say that any difficulty you may have understanding what Scala is trying to be is due to no fault of Scala itself. It's very simple, really (well, to be precise, there are different tiers of simplicity in Scala, but I can assure you that each tier is quite simple once you've mastered all the design decisions, and category theory, that fully, consistently and self-sufficiently define the simplicity of the respective tier).
So I must say that any difficulty you may have understanding what Scala is trying to be is due to no fault of Scala itself. It's very simple, really (well, to be precise, there are different tiers of simplicity in Scala, but I can assure you that each tier is quite simple once you've mastered all the design decisions, and category theory, that fully, consistently and self-sufficiently define the simplicity of the respective tier).
I explain why I think Scala will be giant to people by saying it is Java's C++. It's as painful or nice as you want it, one company's use looks nothing like another's and it is building on years of pain points to solve problems in a different way while still using the current ecosystem(s).
I explain why I think Scala will be giant to people by saying it is Java's C++.
You know, back when Java was getting huge and I was still in grad school, Java was supposed to cure everything that was wrong with C++.
In the same grad school -- an old timer professor (so old, he actually wrote the very first commercial implementation of Merge Sort -- on paper punch tape, no less) looked at some C++ that used templates and commented, "C++ must be the new Cobol."
The C++ code I like is minimalist. The languages I like the best are minimalist. It's just my personal taste, but I don't see the point of making things more complicated than they have to be.
You know, back when Java was getting huge and I was still in grad school, Java was supposed to cure everything that was wrong with C++.
In the same grad school -- an old timer professor (so old, he actually wrote the very first commercial implementation of Merge Sort -- on paper punch tape, no less) looked at some C++ that used templates and commented, "C++ must be the new Cobol."
The C++ code I like is minimalist. The languages I like the best are minimalist. It's just my personal taste, but I don't see the point of making things more complicated than they have to be.
Java's C++
I would sell it that way to non-technical executives but not to anyone else.
I worked with someone who's a personal friend of Odersky and he's confident that Scala won't turn into C++. He described him as "way more scrupulous than Stroustrup".
I would sell it that way to non-technical executives but not to anyone else.
I worked with someone who's a personal friend of Odersky and he's confident that Scala won't turn into C++. He described him as "way more scrupulous than Stroustrup".
I agree, but use that as a sell for why I think it's reasonable to use for business. It usually follows a technical discussion of it's benefits.
It is too late for that.
I have this sneaking suspicion that Scala has blown past C++ and is taking aim on Perl.
I'm noting with some relief that the Scala hype is over. Definitely.
The Scala hype, if there ever was one, started because for a long while Scala was the only high-performance alternative to Java on the JVM. Groovy was too slow, and many people prefer static typing. But then a large gap started to emerge between what most Scala users needed (and the reasons they turned to Scala in the first place) and what the language designers decided to give them. There were all sorts of funny operators and then implicits, meant to support DSLs. Then came all sorts of nifty tricks like type constructors, whose purpose, I think, was to simply prove that it's possible to build a statically typed language that has inheritence, yet does not require casting, ever. That is, if you're willing to put in the time to learn the intricacies of the type system. Well, they've proven it's possible alright. It is truly a great achievement in PL research, only it came at the price of making the language more annoying with each release. Who cares if you need to cast now and then if it makes the type system simpler and compilation times shorter?
Now there are other alternatives. For those wishing to see the light of a new, better, way to program modern machines there's Clojure. For the more timid of heart, Kotlin has been/is being released. It is everything Scala's original users wanted from the language.
I think your warnings about complexity in the type system are prudent, but your comment about casting is off. Casting (with the exception of primitive types) is a very blunt hammer to bash your way out of a type system. The MLs have a simple type system, yet you almost never need to cast. It's worthwhile from a language design perspective to try to eliminate the need to cast entirely, and I believe you don't have to complicate your type system to do so.
Also, you note that "many people prefer static typing", but then you suggest Clojure...
Also, you note that "many people prefer static typing", but then you suggest Clojure...
Well, avoiding casts AND supporting inheritance AND having a simple type system is pretty hard. You can usually just pick two of the three.
Many prefer static typing, and many don't. BTW, Clojure is indeed dynamically typed, but it has a "type philosophy" that keeps things nice and orderly, namely no encapsulation and uniform data access.
Many prefer static typing, and many don't. BTW, Clojure is indeed dynamically typed, but it has a "type philosophy" that keeps things nice and orderly, namely no encapsulation and uniform data access.
Java avoids casts in most cases with generics, it supports inheritance, and it has a simple type system. Ditto with C#. (I also haven't heard people complain about the complexity of F#'s type system, so I'd point to it, but I don't know F# enough to be able to say whether it's a good point or bad point in the space here.) OCaml also supports inheritance, although its object system is kinda weird (in that it doesn't really fit with the rest of the language; I wouldn't say it's overly complex though).
Basically I don't think that Scala's complexity should burn us on type safety in general. I think Go and Dart, for example, are an overreaction to the complexities of type systems like those of Scala (no generics and null pointers in the former, and unsound covariant generics and null pointers in the latter). There is room for a statically typed language that brings the benefits of type safety that make programming easier without the complexities that make programming harder; the fact that we haven't found that sweet spot yet doesn't mean that we should just throw up our hands. I'm not convinced that the sweet spot is either unsound or requires casts.
Basically I don't think that Scala's complexity should burn us on type safety in general. I think Go and Dart, for example, are an overreaction to the complexities of type systems like those of Scala (no generics and null pointers in the former, and unsound covariant generics and null pointers in the latter). There is room for a statically typed language that brings the benefits of type safety that make programming easier without the complexities that make programming harder; the fact that we haven't found that sweet spot yet doesn't mean that we should just throw up our hands. I'm not convinced that the sweet spot is either unsound or requires casts.
It's a statically typed JVM language meant to be more powerful and at the same time easier to use than Java.
Yes, I would agree with this.
Yes, I would agree with this.
Why not just use Java?
Java was designed as a reaction to the complexity of C++. Scala was, in turn, designed as a reaction to the simplistic nature of Java. It sounds like you prefer minimalism, and in that sense Java is a better choice for you. That's what it was designed for: simplicity.
Java was designed as a reaction to the complexity of C++. Scala was, in turn, designed as a reaction to the simplistic nature of Java. It sounds like you prefer minimalism, and in that sense Java is a better choice for you. That's what it was designed for: simplicity.
> I guess I'm not terribly impressed. It actually makes me long for the simplicity of C.
You might want to try Go. One of the great things about Go is that is almost completely devoid of 'magic', and what it says is what it does, and what does what it says.
The syntax is much simpler than C's, and it lacks the (very good at obfuscating) preprocessor.
Once you read the spec (is short and sweet) is very easy to know what a piece of code does by just looking at it.
At the same time Go code is not verbose and manages to be very concise.
You might want to try Go. One of the great things about Go is that is almost completely devoid of 'magic', and what it says is what it does, and what does what it says.
The syntax is much simpler than C's, and it lacks the (very good at obfuscating) preprocessor.
Once you read the spec (is short and sweet) is very easy to know what a piece of code does by just looking at it.
At the same time Go code is not verbose and manages to be very concise.
I'm a C fan as well but really like Scala for certain domains. There is complexity in Scala but it's layered in a way that I think is able to support that complexity long term.
I think a lot of this is addressed in the "Programming in Scala" book.
I think a lot of this is addressed in the "Programming in Scala" book.
At first glance the 'almost any method can behave like an operator' stuff is really cool
I dislike operators and all the unspoken, must-be-remembered complexity they impose with regard to associativity and order. I actually think the S-expression syntax of Lisps is a lot better.
A lot of these "weird" decisions were made in the interest of backward compatibility (in the ideological sense, not character-for-character) with Java. If Odersky hadn't supported these infix operators, which have a lot of weird-seeming rules about first characters and what it means when it ends with a ':', the language wouldn't be nearly as palatable.
ETA: It really seems like the language designer merely looked at Java and tried to create an interoperable language that was as "un-java-like" as possible.
I think Scala was designed to use the good parts of Java while throwing out the cruft. It's designed to be a "meeting point" between Java, Erlang, and Haskell.
Clojure, I feel, has disowned its Java heritage more than Scala has.
I dislike operators and all the unspoken, must-be-remembered complexity they impose with regard to associativity and order. I actually think the S-expression syntax of Lisps is a lot better.
A lot of these "weird" decisions were made in the interest of backward compatibility (in the ideological sense, not character-for-character) with Java. If Odersky hadn't supported these infix operators, which have a lot of weird-seeming rules about first characters and what it means when it ends with a ':', the language wouldn't be nearly as palatable.
ETA: It really seems like the language designer merely looked at Java and tried to create an interoperable language that was as "un-java-like" as possible.
I think Scala was designed to use the good parts of Java while throwing out the cruft. It's designed to be a "meeting point" between Java, Erlang, and Haskell.
Clojure, I feel, has disowned its Java heritage more than Scala has.
It's designed to be a "meeting point" between Java, Erlang, and Haskell.
Plus, a DSL building language. I actually think that the features Scala introduced to enable DSLs were the harbingers of the Scala insanity. Why did the designers of a high-performance statically-typed language think that it would be a good idea to support DSLs?
Plus, a DSL building language. I actually think that the features Scala introduced to enable DSLs were the harbingers of the Scala insanity. Why did the designers of a high-performance statically-typed language think that it would be a good idea to support DSLs?
DSL support is tricky business. Consider Greenspun's Tenth Law. I think it's generally assumed in modern languages that it's better to allow this sort of thing than not do so and risk that people roll their own.
On Greenspun: why are large Java programs hard to read? The language itself is simple. The problem is that most Java (or C++) programs devolve into shitty DSLs after about 2000 LoC.
On Greenspun: why are large Java programs hard to read? The language itself is simple. The problem is that most Java (or C++) programs devolve into shitty DSLs after about 2000 LoC.
The biggest reason for supporting DSL's, as far as I understand it, is so that, as with Lisp, much of the functionality of the language can be moved out of the compiler and into libraries. This will make the language proper actually rather simple, though, of course, great complexity can come out of simple, orthogonal rules.
I agree with this 100%. Maybe it was an attempt to ride the DSL fad that Rails ushered in, but it really feels like Scala incurs a lot of extra complexity to support this feature. The Scala code I've written is pretty straightforward but I've made a point of resisting the temptation to build DSLs.
It's an April fools joke:
"Happy April Fools’ Day!"
Scala is far more object oriented than Java. So + is a method of the Int object and you can write 2.+(3) instead of 2+3. Methods are allowed to be operators, so that you can write 2+3 instead of 2.+(3). If _ is a separate token it represents an unnamed parameter, no more no less. In your specific case some_obj open_! translates to some_obj.open_.! It is not too difficult, you are just at week 1 of Scala.
As for language comparisons
1. C is simple/readable
It is way better than C in terms of readability. All constructs in C are simple, but it takes a lot of C code to accomplish simple things. Also, how readable is while(<star>d++ = <star>s++);
2. Python is explicit
The advantage of Scala here is static typing and performance and much better IDE support. Python code typically looks cleaner than Scala code, but I have been told that closures in Python are less than perfect. Python OTOH has no build time issues.
3. Clojure is more functional
Clojure is not more or less functional than Scala. There are varying definitions of "functional"-ness. However, the gold standard of a functional programming language is widely recognized as Haskell. Scala is far closer to Haskell than Clojure in this respect. Again the significant difference between Clojure and Scala is static typing, not functional-ness.
As for language comparisons
1. C is simple/readable
It is way better than C in terms of readability. All constructs in C are simple, but it takes a lot of C code to accomplish simple things. Also, how readable is while(<star>d++ = <star>s++);
2. Python is explicit
The advantage of Scala here is static typing and performance and much better IDE support. Python code typically looks cleaner than Scala code, but I have been told that closures in Python are less than perfect. Python OTOH has no build time issues.
3. Clojure is more functional
Clojure is not more or less functional than Scala. There are varying definitions of "functional"-ness. However, the gold standard of a functional programming language is widely recognized as Haskell. Scala is far closer to Haskell than Clojure in this respect. Again the significant difference between Clojure and Scala is static typing, not functional-ness.
"There are varying definitions of "functional"-ness."
I wonder if there are varying definitions of "object-oriented"-ness.
Also, I hear clojure is a true scotsman while scala is not.
I wonder if there are varying definitions of "object-oriented"-ness.
Also, I hear clojure is a true scotsman while scala is not.
There certainly are varying definitions of "object-oriented"-ness, just contrast C++ and Smalltalk!
And then contrast Smalltalk with CLOS.
(CLOS is the Common Lisp Object System. If Smalltalk is more OO than C++, and I think most people see it that way, then CLOS is ... sideways OO than Smalltalk. It's not quite on the same spectrum, but it is still OO.)
(CLOS is the Common Lisp Object System. If Smalltalk is more OO than C++, and I think most people see it that way, then CLOS is ... sideways OO than Smalltalk. It's not quite on the same spectrum, but it is still OO.)
Yes, OOP is not clearly defined: http://beza1e1.tuxen.de/articles/oop.html
this mirrors my experience with scala, except we had about 100+ maven dependencies and build times were closer to 10 minutes.
This has been the opposite from my experience with Scala. Rather than build a single system with a large codebase, it allows us to build small, compartmentalized systems and compose them together. Then again, we don't use maven, instead using ant for building and git submodules to handle dependencies.
Reading through these comments I would like to point out this is an Aprils fools day post. Its funny because if you didn't read to the end you might very well believe it.
> Reading through these comments I would like to point out this is an Aprils fools day post. Its funny because if you didn't read to the end you might very well believe it.
You know that Scala has gone off the deep end when somebody makes a parody post of how complex it is and several people comment and say "Yup, that totally matches my experience with Scala".
You know that Scala has gone off the deep end when somebody makes a parody post of how complex it is and several people comment and say "Yup, that totally matches my experience with Scala".
90 seconds is a build time issue? Kids these days don't know how good they have it. It used to be time to go and grab a smoke to just login to a box with X-Windows. If our project always compiled in less than 300 seconds, we were golden!
And yes, sounds like I'm imitating a hackneyed SNL skit, but everything here is factual. I am indeed getting that old.
And yes, sounds like I'm imitating a hackneyed SNL skit, but everything here is factual. I am indeed getting that old.
On a serious note, is anything true from the post - if so, what parts? I find the post funny but, I've started to learn Scala (I think it has some pretty awesome features!) but if some of it is true, I might cancel my Scala-learning mission.. :p
Scala is awesome–you should definitely learn it.
Scala does provide you with enough rope to hang yourself with. What's the solution to this? A. Don't hang yourself. New Scala shops should definitely abide by the style guide that is provided at scala-lang.org to help with this.
Also, use implicits and multiple inheritance very judiciously. One thing that is quite true from the OP, is that the "cake pattern" is indeed "the bakery of doom". If you have to use dependency injection, use something sane, like Guice. Or just ol' constructor injection.
My only big gripe with Scala is that OO syntax is a blight on the world. They should have provided multi-methods instead, so everything could be done with functional syntax.
Scala does provide you with enough rope to hang yourself with. What's the solution to this? A. Don't hang yourself. New Scala shops should definitely abide by the style guide that is provided at scala-lang.org to help with this.
Also, use implicits and multiple inheritance very judiciously. One thing that is quite true from the OP, is that the "cake pattern" is indeed "the bakery of doom". If you have to use dependency injection, use something sane, like Guice. Or just ol' constructor injection.
My only big gripe with Scala is that OO syntax is a blight on the world. They should have provided multi-methods instead, so everything could be done with functional syntax.
>My only big gripe with Scala is that OO syntax is a blight on the world. They should have provided multi-methods instead, so everything could be done with functional syntax.
I actually disagree. Functional syntax means that you need to start using qualified names or polluting your namespace (think of module/import usage in Python, but without OOP dot-notation). I like being able to say:
I actually disagree. Functional syntax means that you need to start using qualified names or polluting your namespace (think of module/import usage in Python, but without OOP dot-notation). I like being able to say:
val herp: Option[Derp] = hurr()
herp.getOrElse(Darpity)
Do you find that's a problem with CLOS or Clojure multimethods? Because I never noticed much of what you seem to be talking about.
As I said above, think about a method like map.
In Scala, rather than doing that, we would just define Functor[A] as a trait:
map :: [a] -> (a -> b) -> [b]
class Functor f where
fmap :: f a -> (a -> b) -> f b
method fmap<a,b>(as: Functor<a>,f: a -> b): Functor<b>
override fmap<a,b>(as: List<a>,f: a -> b): List<b>
In Scala, rather than doing that, we would just define Functor[A] as a trait:
trait Functor[A] self => {
def map[B](f: A => B): self[A]
}
I do not see why your worries cannot be addressed. In fact, IIRC (it's been a while), the programming language Cecil does just that.
http://www.cs.washington.edu/research/projects/cecil/www/cec...
http://www.cs.washington.edu/research/projects/cecil/www/cec...
Well, let me take a deeper look at the material. I've based most of my own language work on multimethod systems like those of Cecil, but there's a few things I immediately see on the page:
* Cecil divides its type system from its object-inheritance-overriding system. Huh?
* Cecil is dynamically typed with static sprinkles on top. So we have dynamic vtables, and also F-bounded polymorphism.
* Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!
* Cecil offers nothing for dealing with ad-hoc polymorphism (ie: operator overloading). Admittedly, when Cecil was published, type-classes didn't even exist yet.
* Cecil divides its type system from its object-inheritance-overriding system. Huh?
* Cecil is dynamically typed with static sprinkles on top. So we have dynamic vtables, and also F-bounded polymorphism.
* Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!
* Cecil offers nothing for dealing with ad-hoc polymorphism (ie: operator overloading). Admittedly, when Cecil was published, type-classes didn't even exist yet.
Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!
Method dispatching is done symmetrically on the arguments in Cecil.
Method dispatching is done symmetrically on the arguments in Cecil.
OK, I've read their doc now. And what I can say is, they don't solve the problem I've mentioned at all. Their dot-notation is just syntactic sugar for an "ordinary" multimethod call. It does nothing for module selection.
This means you've got to either use qualified module names, make sure never to import two modules that export an identically-named method, or (if the methods have similar signatures) resort to a type-class.
This means you've got to either use qualified module names, make sure never to import two modules that export an identically-named method, or (if the methods have similar signatures) resort to a type-class.
So??? This is how things work in Clojure. And that's just fine.
I guess I just don't understand where you are coming from. It's been pointed out to you that Clojure hackers don't mind importing the generic functions. You replied that then your worry is that it would be hard to preserve type information in a statically typed language that works like Clojure. I mentioned that Cecil is statically typed and preserves type information, with a multi-method system that is somewhat similar to Clojure's. At least as I understand it.
If your entire worry is that you have to import every generic function you want to use, then I guess you and I just don't worry about the same things at all. To me, importing the functions that you use is a feature, not a bug! In fact, when I program in Python, I generally program a lot more with functions than with classes, and yes, in every module I explicitly import every single externally defined function that that module needs. Again, I consider this a feature, not a bug.
What I would object to is having to explicitly import all the method definitions that implement the generic functions used in a multi-method system. That would be insanity, but that's a moot point, as that is never required, as far as I am aware.
Also, common generic functions, however, such as map(), could clearly be automatically imported by the language. E.g., in Predef in Scala, or in built-ins in Python. In fact, in Python, map() is in built-ins, and you don't have to import it. Though, in Python's case, map() doesn't preserve the original container type
I guess I just don't understand where you are coming from. It's been pointed out to you that Clojure hackers don't mind importing the generic functions. You replied that then your worry is that it would be hard to preserve type information in a statically typed language that works like Clojure. I mentioned that Cecil is statically typed and preserves type information, with a multi-method system that is somewhat similar to Clojure's. At least as I understand it.
If your entire worry is that you have to import every generic function you want to use, then I guess you and I just don't worry about the same things at all. To me, importing the functions that you use is a feature, not a bug! In fact, when I program in Python, I generally program a lot more with functions than with classes, and yes, in every module I explicitly import every single externally defined function that that module needs. Again, I consider this a feature, not a bug.
What I would object to is having to explicitly import all the method definitions that implement the generic functions used in a multi-method system. That would be insanity, but that's a moot point, as that is never required, as far as I am aware.
Also, common generic functions, however, such as map(), could clearly be automatically imported by the language. E.g., in Predef in Scala, or in built-ins in Python. In fact, in Python, map() is in built-ins, and you don't have to import it. Though, in Python's case, map() doesn't preserve the original container type
I'm not talking about importing the generic functions themselves at all. I'm talking about importing the modules that export those generic functions, so that I'll have the modules in my namespace to be able to name the generic functions.
Again: dot-notation lets me write:
You cannot define map() as a generic function, at least not in the sense that Common Lisp and Clojure use the term "generic function".
It can be conveniently expressed as a type-class method of a class 'Functor f :: * -> * ' or a trait method for a Functor[A]. Not a generic function.
Again: dot-notation lets me write:
import scala.collection.immutable.List
def addn(n: Int) = (list: List[Int]) => list.map(_ + n)
import scala.collection.immutable.List
def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n)
You cannot define map() as a generic function, at least not in the sense that Common Lisp and Clojure use the term "generic function".
It can be conveniently expressed as a type-class method of a class 'Functor f :: * -> * ' or a trait method for a Functor[A]. Not a generic function.
> I'm not talking about importing the generic functions themselves at all.
> I'm talking about importing the modules that export those generic functions,
> so that I'll have the modules in my namespace to be able to name
> the generic functions.
I don't see how this is either here or there. I can import modules and then qualify functions within the modules, or I can import functions directly from the modules, renaming then if I want to. There's no difference, between these options, other than a minor difference in what name I use to refer to the function once its been imported.
> Again: dot-notation lets me write:
> import scala.collection.immutable.List
> def addn(n: Int) = (list: List[Int]) => list.map(_ + n)
> Instead of:
> import scala.collection.immutable.List
> def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n)
It isn't dot notation that lets you do that; it's the semantics of how functions are located that lets you do that. Many languages support statically overloaded functions using functional notation. It's also quite easy to imagine a language which uses the syntax f(a) to mean what a.f() means in Scala.
Also, why is this to be considered so desirable? For the performance gain that comes from eliminating dynamic dispatch? In that case, it is certainly possible for a language that supports multiple dispatch to dispatch statically when it can infer that it is safe to do.
> See the difference?
Yes, I quite understand the concept, but it has nothing intrinsically to do with dot notation.
> And then, remember that map() is not a multimethod.
> It doesn't actually do dynamic dispatch on its first argument,
> or on any other argument. It's a type-class method; it does static dispatch
> on the functor type List[].
In Scala? I don't believe that this is correct. As far as I understand, there's a single implementation of map for the entire collection library in TraversableLike, which uses virtual functions provided by the concrete class (and a builder object which gets passed in implicitly) to construct the new container, loop over the old container, and add elements to the new container.
This is similar to how map() works in Python and Clojure, where there is a single implementation of map() which uses dynamic dispatch to loop over the elements of the container. The downside to the way that Python and Clojure doing things is that you get iterators or streams back, not the original container type. But they could return the original container type if containers in Python and Clojure were to have virtual constructors. Then map() could call these virtual constructors to return a container of the same type.
> You cannot define map() as a generic function, at least not in the sense that
> Common Lisp and Clojure use the term "generic function".
Clearly in a statically typed language, you also need some form of parametric polymorphism in addition to what Common Lisp and Clojure provide in order to preserve types. I see no reason why this should be insurmountable.
I've often done things in C++ that wrapped dynamic lookup in a generic function or class, to achieve the types of things that you say require type classes. Another thing you can easily do in C++ is to write template adapter classes to provide something similar to Scala's structural types.
Also, type classes surely don't require dot notation. Haskell is from where type classes originate, and Haskell doesn't have dot notation.
> I'm talking about importing the modules that export those generic functions,
> so that I'll have the modules in my namespace to be able to name
> the generic functions.
I don't see how this is either here or there. I can import modules and then qualify functions within the modules, or I can import functions directly from the modules, renaming then if I want to. There's no difference, between these options, other than a minor difference in what name I use to refer to the function once its been imported.
> Again: dot-notation lets me write:
> import scala.collection.immutable.List
> def addn(n: Int) = (list: List[Int]) => list.map(_ + n)
> Instead of:
> import scala.collection.immutable.List
> def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n)
It isn't dot notation that lets you do that; it's the semantics of how functions are located that lets you do that. Many languages support statically overloaded functions using functional notation. It's also quite easy to imagine a language which uses the syntax f(a) to mean what a.f() means in Scala.
Also, why is this to be considered so desirable? For the performance gain that comes from eliminating dynamic dispatch? In that case, it is certainly possible for a language that supports multiple dispatch to dispatch statically when it can infer that it is safe to do.
> See the difference?
Yes, I quite understand the concept, but it has nothing intrinsically to do with dot notation.
> And then, remember that map() is not a multimethod.
> It doesn't actually do dynamic dispatch on its first argument,
> or on any other argument. It's a type-class method; it does static dispatch
> on the functor type List[].
In Scala? I don't believe that this is correct. As far as I understand, there's a single implementation of map for the entire collection library in TraversableLike, which uses virtual functions provided by the concrete class (and a builder object which gets passed in implicitly) to construct the new container, loop over the old container, and add elements to the new container.
This is similar to how map() works in Python and Clojure, where there is a single implementation of map() which uses dynamic dispatch to loop over the elements of the container. The downside to the way that Python and Clojure doing things is that you get iterators or streams back, not the original container type. But they could return the original container type if containers in Python and Clojure were to have virtual constructors. Then map() could call these virtual constructors to return a container of the same type.
> You cannot define map() as a generic function, at least not in the sense that
> Common Lisp and Clojure use the term "generic function".
Clearly in a statically typed language, you also need some form of parametric polymorphism in addition to what Common Lisp and Clojure provide in order to preserve types. I see no reason why this should be insurmountable.
I've often done things in C++ that wrapped dynamic lookup in a generic function or class, to achieve the types of things that you say require type classes. Another thing you can easily do in C++ is to write template adapter classes to provide something similar to Scala's structural types.
Also, type classes surely don't require dot notation. Haskell is from where type classes originate, and Haskell doesn't have dot notation.
Also, the way that you apparently like things, because it is ad hoc, has the "draw problem", where you think that you're telling a shape to draw itself on the screen, but actually you've told your robotic cowboy to shoot your friend in the head.
I know that many people think that this is not a problem worth worrying about, but I think that in a large program it is. Accidentally calling a method that means something completely different from what you thought it meant is much less of a problem if you have to explicitly import the interface that the method you aim to call is supposed to be implementing.
I know that many people think that this is not a problem worth worrying about, but I think that in a large program it is. Accidentally calling a method that means something completely different from what you thought it meant is much less of a problem if you have to explicitly import the interface that the method you aim to call is supposed to be implementing.
think of module/import usage in Python, but without OOP dot-notation
I don't find that to be a problem. In fact, I love Python's module and import system. And the worst thing about Python is it's OO dot notation. I wish that Python had multi-methods too, and no OO-style method calls.
I don't find that to be a problem. In fact, I love Python's module and import system. And the worst thing about Python is it's OO dot notation. I wish that Python had multi-methods too, and no OO-style method calls.
So instead of writing
herp.getOrElse(Darpity)
you'd write
getOrElse(herp, Darpity)
Polymorphism doesn't need to be tied to the first argument's type, it can depend on any number of properties of any number of arguments (see CL's and Clojure's multimethods).
Polymorphism doesn't need to be tied to the first argument's type, it can depend on any number of properties of any number of arguments (see CL's and Clojure's multimethods).
I'm not talking about polymorphism at all. I'm just talking about namespacing, name look-up for the method. Think of a world in which any number of classes might have a `getOrElse()` method, and they don't all do the same thing (so they're not just all methods of a single generic function). Now, how does the compiler know which one you're calling?
We could use some form of static overload resolution (like type-classes). However, it really does seem (to me) to be easier to just resolve the static overload based on the static type of the first argument, and then throw the rest of the overloading problems at dynamic dispatch.
When you think of a class as both a type and a module, it gets clearer. Many classes in the Scala collections library have a `map()` method. We could code `map()` as a single, universal generic function that dynamically dispatches on its first argument type... but nobody ever cared to override map as a virtual method anyway and that doesn't give us a consistent return-type at all. All we really want to say is that calling map over a `[a]` with a function `a -> b` returns a `[b]`.
We could use some form of static overload resolution (like type-classes). However, it really does seem (to me) to be easier to just resolve the static overload based on the static type of the first argument, and then throw the rest of the overloading problems at dynamic dispatch.
When you think of a class as both a type and a module, it gets clearer. Many classes in the Scala collections library have a `map()` method. We could code `map()` as a single, universal generic function that dynamically dispatches on its first argument type... but nobody ever cared to override map as a virtual method anyway and that doesn't give us a consistent return-type at all. All we really want to say is that calling map over a `[a]` with a function `a -> b` returns a `[b]`.
So, what you're saying is that we all of parametric polymorphism, ad hoc polymorphism, and subtype polymorphism, right?
You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.
You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.
The above should read, "So, what you're saying is that we need all of [...]".
Sorry about that!
Sorry about that!
I'm saying, what happens if more than one module provides a getOrElse() method?
In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.
If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).
In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.
If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).
As I understand it, in statically typed languages that support multi-methods, you import the generic function declaration for a multi-method. This multi-method can be defined in zillion different modules. You only have to import the generic function declaration, not any of the function definitions. The generic function declaration can be parameterized, just like parameterized declarations in Scala. Single or multiple dispatch may be used to locate a method definition.
So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.
So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.
You would have to qualify the call with the module where the generic function is defined. Otherwise, you could import two modules that both define a generic function named foo() -- but whose foo() functions do completely different things.
Yes. I consider this a feature, not a bug.
I enjoy Scala but I would say there is truth to 3 (phantom menace). Although tool support has improved markedly over the last couple of years I still get cases where the IDE is complaining about an error and I go nuts trying to fix it only to give up, run it anyway, and have the error just disappear.
If you spend too much time reading Scala blogs, you may get the impression that 6 (the type babel) is how many people write scala. A lot Scala bloggers like to write articles that exploit or examine clever aspects of the type system but it can be pretty impenetrable at times. At least to a blub like me.
If you spend too much time reading Scala blogs, you may get the impression that 6 (the type babel) is how many people write scala. A lot Scala bloggers like to write articles that exploit or examine clever aspects of the type system but it can be pretty impenetrable at times. At least to a blub like me.
Scala is definitely worthwhile learning, particularly if you're coming from a Java background. If you're using it as a "better" Java it can make your code much more succinct through type inference, pattern matching, traits etc and short code is usually easier to understand and debug. It's also a great way to start learning about functional programming since Scala supports both imperative and function programming styles.
The things to be careful of are the advanced features such as implicit conversions, they seem like a great feature and in a small code base they work great. But if your code base grows at all it can be next to impossible to be sure what your code is going to do.
Not trying to repeat a cliche but as with most things, "With great power comes great responsibility," and Scala gives you a lot of power but it also puts the onus on you to know how and when to use it.
The things to be careful of are the advanced features such as implicit conversions, they seem like a great feature and in a small code base they work great. But if your code base grows at all it can be next to impossible to be sure what your code is going to do.
Not trying to repeat a cliche but as with most things, "With great power comes great responsibility," and Scala gives you a lot of power but it also puts the onus on you to know how and when to use it.
Scala is definitely worth learning. Learned it as a (much) better Java and have never looked back.
One thing is true: implicits. Do not let new scalable programmers use them. When used with type classes, magic. When used as "helper" or "convenience" convertions, disaster.
Pretty much. I've honestly never seen why implicit conversions are even in the language, but implicit parameters are a godsend. They're type-classes done right for an OOP language.
Its an April Fools joke.
3) was true until a few months ago. Or maybe its because I switched from a remote source repo mounted via Samba to a local flash HDD :-) I have been using Eclipse trouble free for a few months now, no issues whatsoever, except for some magic required during the initial maven setup.
4) Is an issue Scala outsiders complain about, but I have never seen this as an issue with people actually using Scala.
Build times are high compared to Java projects, though this could simply be because I am using scalac instead of fsc to build projects via maven. However, compilaton is incremental, so crazy build times should never occur in practice and the IDE highlights mistakes in less than a second.
3) was true until a few months ago. Or maybe its because I switched from a remote source repo mounted via Samba to a local flash HDD :-) I have been using Eclipse trouble free for a few months now, no issues whatsoever, except for some magic required during the initial maven setup.
4) Is an issue Scala outsiders complain about, but I have never seen this as an issue with people actually using Scala.
Build times are high compared to Java projects, though this could simply be because I am using scalac instead of fsc to build projects via maven. However, compilaton is incremental, so crazy build times should never occur in practice and the IDE highlights mistakes in less than a second.
For all means — learn the language — you can only profit from it whether you decide to use it or not.
In my experience, the language is built by people who really want to make things work. They do all the painful work to make even the most exotic corner cases work as people would expect it. So developers can be confident that the language doesn't break down suddenly, like when you overuse Generics in Java and just hit the wall where the compiler decides that it won't let you do that for no good reason.
The best thing about Scala imho is that they deliver. People are constructive and when valid issues are brought up, they will be fixed. (Better IDE support, more documentation, faster compilation, smaller standard library, better performance ...)
In my experience, the language is built by people who really want to make things work. They do all the painful work to make even the most exotic corner cases work as people would expect it. So developers can be confident that the language doesn't break down suddenly, like when you overuse Generics in Java and just hit the wall where the compiler decides that it won't let you do that for no good reason.
The best thing about Scala imho is that they deliver. People are constructive and when valid issues are brought up, they will be fixed. (Better IDE support, more documentation, faster compilation, smaller standard library, better performance ...)
Tying a new language to the JVM is basically like helping a drowning man by throwing him an anchor. Scala the language is decent, but the JVM-induced clusterfuck of complex stdlib/IDE reliance/maven makes for a non-starter.
> Scala the language is decent, but the JVM-induced clusterfuck of complex stdlib/IDE reliance/maven makes for a non-starter.
I see things the other way around: the JVM is a very impressive piece of technology that has been aging impressively well for more than fifteen years while Scala is a C++-like monstrosity that will probably be all but forgotten in a few years.
Personally, I'm more interested in the new crop of JVM languages such as Kotlin.
I see things the other way around: the JVM is a very impressive piece of technology that has been aging impressively well for more than fifteen years while Scala is a C++-like monstrosity that will probably be all but forgotten in a few years.
Personally, I'm more interested in the new crop of JVM languages such as Kotlin.
It's also possible to write Scala in Vim or Emacs and using commandline tools like SBT, conscript, and giter8. It's not that bad.
Why the JVM hate?
Use it on the CLR then.
http://www.scala-lang.org/node/10299
http://www.scala-lang.org/node/10299
Some could be taking this article a bit too serious. I self taught myself to code 6 months ago and like enjo stated it seems very littered and perhaps too flexible.
Why does a scala centric company publishes such a poor flame bait article against scala? I think this is just a joke and not to be taking seriously in any way
well it does say "happy april fools day the end" :)
Yeah, but... it's not funny. It seems like some of it might be true.
that's my point is not funny at all and as serious criticism is pointless and destructive
You're not allowed to point out deficiencies in something you like and advocate? That's a fairly dense position..
The nice thing about Open Source is that it tends to be a little bit more immune to that corporate drum beat since there are less full time salesmen and marketeers. The void seems to fill with fanbois though.
The nice thing about Open Source is that it tends to be a little bit more immune to that corporate drum beat since there are less full time salesmen and marketeers. The void seems to fill with fanbois though.
I would have loved to see what these guys have to say about Scala critically, but that's not what they are doing, this is a half baked unfunny joke that does not inspire any debate, only flaming and bashing. Is good that you talk about fanboyism because that's what this article is about, clojure fanboyism to be precise
The article is funny BECAUSE it's true.
I love Scala and have been using it for a couple of years but I've been through nearly all the stages described in the article. Eventually I got so frustrated I gave up and learned Clojure !!
I love Scala and have been using it for a couple of years but I've been through nearly all the stages described in the article. Eventually I got so frustrated I gave up and learned Clojure !!
You just don't have much of a sense of humor.
"Verbal and situational irony are often used for emphasis in the assertion of a truth."
Did you ever mock something or exaggerated a fact to make it funny, but in reality, you meant it like that? ;)
Did you ever mock something or exaggerated a fact to make it funny, but in reality, you meant it like that? ;)
I think my biggest issue is that the language is so syntactically flexible (verbose?) that I simply have no idea what is a language construct and what isn't.
For instance the code is littered with stuff that looks like:
val something = some_obj open_!;
Is open_! just a method (literally some_obj.open_!) or is "_!" some sort of language construct, because underscores are special sometimes, like with unary_ for instance (or not.. it really just depends).
At first glance the 'almost any method can behave like an operator' stuff is really cool, although as I learned about alarm bells where ringing all over the place. In the hands of even an actually competent programmer it's going to be abused well beyond the utility you get out of it.
It took 30 seconds of looking at existing code to find obvious examples of it. Why is it so evil to clearly denote a method as being an actual method?
Then there is the whole "is this functional or not" madness. It reminds of PERL in that respect. You can accomplish the same tasks in a bunch of different ways.
I guess I'm not terribly impressed. It actually makes me long for the simplicity of C. If you want static typing Scala (and readability adverse type inference system) seems like a really bad choice. At least at the point I'm at about a week into this stuff.
At the end of the day give me the beauty of C, the explicitness of Python, or a much more complete functional language like Clojure. I don't want a hybrid of all of those that seems to create a whole new set of weaknesses and big-time issues. It really seems like the language designer merely looked at Java and tried to create an interoperable language that was as "un-java-like" as possible.