Ever since I watched a Java developer at a client give a rabid "Why Scala is OMFG AMAZING!!!!!" talk to a bunch of bemused Perl programmers ("and it has this thing called a map and it has this thing where you can execute some code for each element of a list inline and..."), I've been carrying around the following prejudice, which I'd like to be freed from, so help me out:
There are only two types of people who find Scala even vaguely interesting:
- Java programmers who have never used another reasonably powerful high-level programming language
- Programmers familiar with high-level programming languages who have a need (or want) to target the JVM
Don't doubt the power of 2. Java is so friggin' entrenched that having a pretty nice half-type-inferencing functional language that's at least a little competent is a breath of fresh air. Sure I'd rather be using Haskell, but the available integration tools between Haskell and Java are not widely used and a bit immature or otherwise nasty.
Maybe, one day, when the JVM finally keels over and dies and we're freed from the yoke of bad enterprise decisions, we'll all be able to use functional languages that were designed largely without compromise.
#2 is perfectly true, Scala for me is a basically acceptable ML that can interoperate with everything else JVM, given the choice I would be using OCaml or Haskell. Integrating these with C/C++ is straightforward but I have no experience of calling Java from OCaml. Hmm, I ought to write a blog post about that.
On .NET they have it much better, F# is much more MLy.
To your 2nd point it's not just targeting the JVM. It's really targeting the whole Java infrastructure: JVM/tools/libraries and (critically) a syntax that will be very familiar to the legions of Java developers out there in the world.
To me at least this is a very powerful and important thing.
PS: http://foursquare.jobs for anyone interested in working at a startup that does most of its work in Scala!
It's a hybrid OO-FP language that is statically typed with decent type inference. This has never been done before.
Perl is not statically typed. You might think that's a good thing, but I don't because I routinely refactor in a large code base. I can make one change and start propagating it around until everything compiles and unless I've made a mistake it will all work. I don't make very many mistakes so I can improve a code base at rapid speed.
Ahem, once you have used OCaml, which is a hybrid etc etc, you would never say Scala has decent type inference. I have to annotate my Scala a hell of a lot more than my OCaml to get it to compile. All function arguments for example, whereas OCaml just deals with it with no fuss.
I understand this is because Scala can't use Hindley-Milner due to some OO reason or other but still.
What about OCaml? I've never used it, but I was under the impression it is sort of OO combined with ISWIM FP. I've been poking about and reading about Standard ML and the module system seems like it supports some quite powerful OO stuff, but I also haven't really wrapped my head around it.
I'm a Lisper and I basically don't know what I'm talking about here when it comes to ML and Scala. I do find Scala interesting though.
I'm not an expert in either language, but from my expose to the two, it seems to me OCaml is much heavier on the FP than the OO. If you asked me to imagine a FP-OO hybrid language, it would be closer to Scala than OCaml. Scala is both pervasively object-oriented and pervasively functional.
Scala's static type system also seems to be quite a bit more sophisticated than OCaml (though its type inference is crippled as a compromise).
Nemerle is also a hybrid OO-FP, statically typed language, with subtyping-savvy type inference, targeting the CLI. Moreover, it allows metaprogramming using Lisp-style macros.
Nemerle has been available at least since 2005, but I can't blame you for not being aware of it. I probably wouldn't have heard about it, had I not attended the university where it was invented.
The research I'm doing as I wait for comments suggests that it's the power of Perl with some of the good parts of Java, and without having to lean on Moose to get decent OO...
Scala has a very interesting confluence of features. It's statically typed, which some people think is very desirable. It supports functional programming very well. It has strong concurrency support. It has an amazing breadth of libraries from the JVM. It has a lot of niceties that make your code shorter. Overall, it's a pleasantly practical language, aside from the fact that the type system makes Haskell's look benign and conservative.
That first claim, that it's as expressive as Ruby, just doesn't hold up to scrutiny. (I've never used Ruby much, but I know my Python, and I'm going to assume they're approximately equally expressive). In no sane Python codebase would you see copy-paste that looks like:
Well, all these tuples can be represented as a List[Any] object in Scala with no problems and it would be just like any other dynamically typed language. However, if you want static type checking of your code, then yes - it is useful to tell the compiler the constraint on the range of values that are valid for your object. This is generally not possible in dynamic languages and should not be surprising.
Ha. Well, Scala was designed by hardcore JVM people after all. You could count me in the second camp. It's possible that some fondness for the JVM is required to have much interest in Scala.
It is a unique language, though. Functional, yet lets you program in nouns, unlike verb-obsessed lisps. Powerful type system, but less stodgy than Haskell. Terse, but fancier than Python. Plus access to rich and well-documented libraries by virtue of the JVM.
I broadly agree - lots of hype and a bewildering array of features, but no reason to use it unless you are some kind of academic or lucky enough to be in the right kind of job for playing with general purpose high level languages.
In my world (job) you either have to squeeze every possible cycle out of the innermost loops or get new hardware land on your desk which has an assembler and C compiler, maybe even a buggy, unfinished C++ compiler if you are super lucky. This probably sways me heavily against having an especially deep interest in all of these newer languages... I guess there might be some appeal if you are stuck with having to write code which targets JVM.
Real programmers write Fortran anyway, right? (j/k obviously they write C++ [j/k]) :)
I'm not sure I agree with the article. Given that Scala has tried to encompass every paradigm except 'goto', it's hard to argue that Scala is a carefully tuned high performance machine (e.g. a specialty sports car, that Alfa romeo). Rather, Scala is a bit like a Java that had been 'improved' by the Windows Team. Lots of pieces of flair, plenty of buzz words and a very complicated UI/language. As a car, it seems more like a combination between the Alfa, a Zamboni and 18 wheeler.
If you compared Scala to C# you'd find that Scala has many features absent in C#, like a more powerful type inference engine, implicits, pattern matching, a better module system, and traits. C#, however, has many language features Scala doesn't, like dynamic blocks, unsafe code, unsigned arithmetic, a built-in events system, built-in LINQ syntax, real reified generics, and so on. Yet no one complains about C# being a kitchen sink language!,
It turns out, Scala isn't hard because of all its language features. There are other languages that easily comparable in size to it and also support multiple paradigms. It has some syntactic flexibility that some people find offensive, but it's certainly not the difficult part of learning Scala. Scala is difficult mainly because it is so well designed that it easily enables the use of functional patterns that most people aren't familiar with. This means that to use it you have to learn a new paradigm, and most people aren't willing to put in the effort to do so.
"Scala is difficult mainly because it is so well designed that it easily enables the use of functional patterns that most people aren't familiar with."
I hear this argument a lot, but I don't think it's true. I've done a fair amount of haskell, OZ, lisp in various forms, etc, etc. I often have a hard time reading scala code, more so than any of these other languages which are also FP. Maybe it's just me, but it sure seems like other people have had the same experience. I've begun calling it statically typed perl, because my experience with it is very similar.
I haven't used Oz at all, and don't feel like comparing Lisps to Scala right now, but I would agree with you that functional code that I've seen in Haskell looks a lot cleaner than it does in Scala. Haskell is, of course, in many ways a narrower language in scope. It doesn't support subtyping or an imperative style, and doesn't have to deal with the constraints of running on the JVM or Java interoperation. I would say that, in general, the Haskell community are much less interested in Haskell becoming a widespread or pragmatic language.
I feel like the compromises Scala makes are valid. I guess in the end though if you feel like Scala is unreadable then it is not the language for you. Since Scala is something I believe strongly in, I wish there were a way I could help make it more readable for you! As someone who knows both Perl and Scala well, I feel like there is a whole world of difference between the two.
It doesn't support subtyping or an imperative style
I would argue that monads are the ultimate imperative style.
I would also agree that Haskell users have very little interest in it becoming mainstream.
My main gripe with Scala (in which another developer in my compilers class used it, not me), was that when reading his code I saw a lot of "magic." I'm not sure if that was better or worse, just... different.
There are few things that seemed more magical to me at first glance than Haskell's point-free style! :)
I would explain the difference between Perl magic and Scala magic as being that Scala magic reduces down to a relatively few simple but flexible rules, whereas Perl magic reduces to a bunch of edge cases and special rules that lack any form of cohesion. Once you learn these rules, reading Scala code becomes very manageable.
I found the Haskell code I saw to be clearer because it's type system allows one to omit types much more frequently, its indentation and function declaration style let you avoid a lot of curly braces and parenthesis, it's type class system involved less syntactic ceremony than Scala's implicits, point-free style allows one to omit Scala's underscores, and so on. All of these things added up so that in the end, I felt like Haskell just looked a lot nicer, much more concise and like the math it was trying to express.
I'm sure some of the authors of Scalaz could do a much better job than me explaining Haskell's advantages over Scala when writing functional code, since I am by no means a Haskell expert.
Perl magic reduces to a bunch of edge cases and special rules that lack any form of cohesion.
I can think of two general philosophical premises which underlie most of those special rules in Perl: implicit variables and context. Most tutorials and books explain them poorly, which is why so many people never understand them.
Monads are definitely not the ultimate imperative style. I love Haskell, but once you use too much IO or Reader/Writer or anything like that everything gets messy and ugly.
Imperative style really benefits from loops and also several design patterns that really don't work or exist in monads.
FWIW, the main (only?) reason Scala needs "implicits" is to deal with polymorphism of generics while being screwed by the JVM's "type erasure": an implementation of Scala that targeted .NET would not need to deal with that, and would therefore also not need the implicits feature.
(That said, the port of Scala to .NET made the design decision to not fix this; however, the reason is not "we liked it", but "we don't want to be incompatible with Scala for the JVM": a decision I consider totally reasonable.)
> C#, however, has many language features Scala doesn't, like dynamic blocks, unsafe code, unsigned arithmetic, a built-in events system, built-in LINQ syntax, real reified generics, and so on. Yet no one complains about C# being a kitchen sink language!
Actually they do, and exactly for the reasons you just said. C# is one of the largest mainstream languages in terms of syntax. It's definitely a "kitchen sink" language.
Which is not to say it is a bad language. It has its uses like every language out there.
Speaking from experience? The reason why I am asking is because the post states "the fearful perception doesn’t map to the realities of the language experienced after consistent usage"
Since there are a lot of comments that disagree with the post, I'll say that I largely agree with its essential premise which is that a language's perceived difficulty shouldn't be based simply on the initial learning curve, but on how much it helps (or hinders) once it has been properly absorbed.
My only evidence for this statement is my own experience. I am well on the right side of the java curve as the article describes and over the first hump and well down it on the scala curve.
In support for your statement I'll add my own experience.
As a language expert, I've become more proficient with Perl the language than most people I know who program in the language daily. Perl has a tremendous number of nooks and crannies to explore and is so complex that as far as I know there are no other implementations of the language besides the original. However, having mastered Perl, I am still far less productive using it than any of the other several dynamic languages out there that let you accomplish the exact same things but without all the extra complexity.
Scala had the opposite effect for me. Having reached a certain level of proficiency with it, many times I feel like I can express my ideas in code faster in Scala than I can in any other language. If Scala had faster compile times and a more Unixy library (not likely, given its Java heritage), I would even replace my use of scripting languages with it for small tasks!
When you say you "can express my ideas in code faster in Scala than [you] can in any other language", I'd love to see you expand on this. Why is it more productive for you than say, F#, or Haskell, or Python, or Clojure?
I don't say this to dispute your findings -- as someone potentially interested in learning Scala, I'm genuinely interested in any specifics you can provide. Thanks!
Well, a lot of coding comes down to data structures and algorithms, and I feel that Scala has the best out-of-the-box collections library experience of any language I've used. This makes it easy for me to choose an appropriate data structure and write my code as a series of transformations on it. I also like to think in terms of objects and Scala has the best fusion of OO and functional that I've ever seen. Finally, for most problems I like having a type system to help catch errors and to help shape the design process, and I like the IDE and tooling support that comes with it.
That said, I've never written a line of F# and have written very little Haskell and Clojure. Clojure also seems like a fine language to get things done if it is more your cup of tea. If I were to pick a Lisp for development, Clojure would definitely be it.
I think Scala is a wonderful language, however it is one of many.
Data structure and collections support in scala is equivalent to any functional language. I would be interested in hearing where you think Scala offers more.
F# is another functional language that balances OOP in a way that works well. It is different to but homomorphic with Scala's OOP functional synthesis. Both allow a very unique style with algebraic types, matching objects, structural recursion and monad syntax.
What's worse than a blanket assertion that one language is hands down better than another? Defending that assertion with trite infographics and limp analogies.
If you're in a technical leadership role and convinced that Scala is better than Java then run your team on Scala and take a quantitative look at the results - bugs, developer happiness, velocity, etc - all the myriad dimensions of development.
Anything else is just anecdotal, an assertion, fluff.
Where did I say that? This post was about complexity curves observed during my experience. I can say I like Scala better than Java, but I wouldn't assert that is indicative of anything that you should believe. Decide for yourself. (although it sounds like you might have already)
Anything else is just anecdotal,
an assertion, fluff.
And what are the measurements that you describe? They're certain not science. But yes you're right that this is anecdotal. That was the entire point.
...Or you can tell the story of your own experience which may be useful. But I agree with you there are many generalizations in the article and it is presented in away that almost seems scientific.
What are these "incidental complexities" and "type system inconsistencies" the author speaks of as keeping Java from becoming second nature?
There are probably literally a million Java developers who have reached a point on the learning curve where it feels second nature, makes sense in the larger context, stays out of the way (except for a thing or two), and lets them focus on the problem at hand.
The latest argument I've heard for Scala is that its complexity and difficult to read code is a plus, because only really smart and dedicated programmers can handle it. It's a "filter". I like that one. It soothes egoes while simultaneously allowing results-oriented businesses to dismiss it.
Yikes! Did I say that? I have to say that this is a very black-or-white reading of the post. However, I apologize if I hurt feelings because I know some brilliant Java programmers and likewise brilliant people who hate Scala.
There are only two types of people who find Scala even vaguely interesting:
- Java programmers who have never used another reasonably powerful high-level programming language
- Programmers familiar with high-level programming languages who have a need (or want) to target the JVM
What am I missing here?