Scala's great, if you have a gorgeous Haskell program and you want to port it to the JVM. Unfortunately, by itself, that may be a niche market.
If you want a dynamic language, you have lots of great choices. If you want powerful syntactic abstractions, you have Clojure, Lisp or Racket. You can win big with any of these tools.
But some problems benefit from powerful mathematical abstractions, and that's where Haskell and Scala start to shine. For example, if you need to do Bayesian filtering, you can bury all the math in a monad, and make Bayes' rule as easy as an 'if' statement. (I've got a blog post for the curious: http://www.randomhacks.net/articles/2007/02/22/bayes-rule-an... ) And when your library designs start involving generalizations of linear algebra, even Ruby-lovers may learn to appreciate a strong type system.
But this raises the real question: How useful is Scala if you don't need to do functional programming with a strong type system? Most people don't, at least today, and the jury's still out on whether it will ever be mainstream. Certainly, some smaller companies will use Scala and win big in specialized domains. But if Java hackers want to claim that Scala's an inappropriate tool for their jobs, who am I to argue? I write far more Ruby than Haskell, because I encounter lots of work that's well-suited to Ruby. (Of course, there's also Akka and a lot of other useful Scala features, which may appeal to people who don't need FP.)
So if Scala becomes seriously popular, I'll be delighted. But a large fraction of Scala's complexity is devoted to niche use cases, and that may make some people unhappy if they're merely looking for a "better Java".
> How useful is Scala if you don't need to do functional programming with a strong type system?
Functional programming with a strong type system, IMO, has much wider applicability than just the esoteric mathematical abstractions (e.g. Haskell/scalaz) that you're asserting is a niche for Scala.
I can think of many non-scalaz uses of Scala, but even for non-Scala uses, look at Jane Street's evangelism of OCaml (functional + strong type system) for financial systems.
(Note that, personally, while I like the benefits of FP, I admittedly still think in/like aspects of OO, even if just out of habit, so I find Scala's blend particularly nice.)
I get and have built Probability monads often enough. They seem really cool since keeping normalization around is theoretically nice, but they seem broken in "real" applications.
Everything I do with probability ends up looking mathematically dissimilar to probability. Most algorithms go far out of their way to avoid on-the-fly normalization because it's so expensive. An EM update monad is just the State monad.
I love Haskell (never used Scala) but I find the very things you're marketing it with abhorrent to use.
I don't see how Haskell or Scala are better in mathematical abstractions. I guess it would be equally easier (or even much easier) to abstract away this kind of thing in clojure, you could generate all the checking that you would get in Haskell/Scala. The only real diffrence I see is the compiletime checking, right?
I think the reason why Scala is often used for these niche applications is that:
A) The language doesn't fall apart as soon as you try something not imagined by the original language creators.
B) Pushing the boundaries actually returns useful results.
C) Java isn't able to solve the given task or at least not productively.
That doesn't make Scala a non-general-purpose language.
Probably the majority out there is using Scala as a better Java and is perfectly happy with it.
firstly it is never good when you start out a discussion by saying now I know people will disagree but thats because their bigoted zelots. Its kind of disingenuous to attempt to post a technical dissent filled with personal opinion and preface it with that kind of clause inevitability allowing you to label any dissent as "See those scala zelots are at it again"
That being said this is an article that attempts to raise technical problems with scala but really just list a few of the authors own personal gripes with the language. In order here are his complaints
1. Scala doesn't have a rigid versioned module system
2. The functional way of doing concurrency isn't how I like to do concurrency
3. The scala community isn't helpful enough for me
4. The type system is too powerfull
5. The syntax is too flexable
6. There aren't enough tests in the compiler test suite
Its alot of the same thing I have seen when people try to list "The" problems with the language and not "Their" problems with the language. Technically there is only one argument that could even hold water thats about the module system . Which if he really needs a module system for his work then that is a technical limitation of the language and he might consider using a better tool for his job. The rest of it however is just nonsense and personal opinion pretending to be technical dissent.
Steve's remarks on concurrency seem a totally fair observation to me, don't a large number of functional languages deal with concurrency through immutability and support that at the language level - I can think of Clojure, Erlang, Haskell, F# for example. The fact that it was possible to send a mutable message to a Scala actor made me extremely suspicious when I first used the language.
I've been picking up Scala on-and-off for the past few months. "Programming in Scala: Second Edition" is one of the best tech books I've ever read. The authors assume you already know how to program, offer mutable & immutable approaches to nearly everything, anticipate esoteric questions in the footnotes, and even have a good sense of humor.
The book also weighs in at 883 pages and I was astonished how much of it I needed to read to even get started. Once I did, I very much like what I saw. But I was a big fan of ML back in grad school.
I do share some of the blog author's gripes though. Most of the popular Scala libraries are just a mess of DSL operators that have no real world association. I'm constantly having to look up what an operator means. I still have no clue how to use the Dispatch library, since the concepts it encapsulates are about 400 pages deeper into the book than I'm currently at. This, just to issue an HTTP GET request. I really thought there might be something on the lines of Ruby's rest-client library.
Additionally, my issues with versioning occur at a much simpler level. The release notes of any given Scala release are devoid of anything useful. Usually it's just a list of JIRA issue numbers (not the issue titles). And then there was this whole debacle around 2.9.0.1 and how SBT called the version. That took me 4 hours longer to work than was really necessary.
So, anyway, I do have some Scala projects. Incidentally they're all Java interop because I just can't wrap my head around how to use most of the Scala-specific libraries. But I've found it works really well in those situations. Deep down I really do like the language. The Scala ecosystem leaves a lot to be desired, but fortunately I can pull in stuff from elsewhere on the JVM.
Most of the comments here talk about how whatever useful can be done in Scala can be done in some other language. That is not the point, Scala is a good language because
- Compatible with JVM
- Strong type system
- Linear Typing
- Substructal Types
- Local Type inference
- Concurrency constructs built in as actors (Akka)
- Integration of OO and functional paradigms
- Supports Higher Order Programming
- defn-site Variance based Parametric Polymorphism
- Mixin Class Composition for finer grain reuse
- Traits provide stackable behaviors (aspect-oriented style)
- Embedded Polymorphic Domain Specific Language (DSL)
using dependent path types
Every language design is a trade off, but Scala is more expressive and concise than Java. Sometimes that may look to you as code which is unreadable. Other languages like clojure make some other trade offs. But Scala tries to bring some of the benefits of functional programming (in say Haskell) to Java.
It's unfortunate that there a number of very smart people from the Haskell community that are trying to mold Scala in Haskell's image that also appear to be very prominent and active in the community. Other than having some negative effect on Scala's public image, however, there's nothing wrong with what they are doing. People work on open source projects that interest them, and it is an interesting exercise for some to find out how different Haskell constructs can be encoded in Scala.
However, the rest of us lesser mortals use Scala very differently, and we far outnumber these people. If you pay attention to Martin Odersky, the creator of the language, you'll notice that he is more interested in serving our needs than those of the Haskellites. He's outright refused to make IO monads a core part of the language, for instance, even though they have pushed for it. He's also said that scalaz is on another planet entirely, and he's asked publicly that people stop using symbolic method names in their libraries unless they have external meaning beyond the library. This guy gets it. He really has created a language that is powerful, but also practical, an excellent language for writing code that is readable, maintainable, efficient, and concise.
The author of this article admits that Scala doesn't feel right to him. He then proceeds to try to justify that feeling in his mind with some very weak arguments. For instance, his module argument oh so coincidentally happens to play into fantom's strengths alone, as No other JVM language is trying to tackle this problem right now. He is right about the lack of tests and binary incompatibility, but these are known issues that already have been addressed to some extent and are continuing to be addressed. They are not core issues with the language itself.
Scala is lightyears ahead of Fantom and Fantom will probably never catch up. If Fantom can't win on technical merit, then apparently the next best strategy involves negative blogging!
Disclaimer I like Fantom and it is my language of choice. That said, I agree he (Stephen) for every fault he finds Scala finds a way to recommend Fantom. That strikes me as dubious.
Nevertheless I find this statement:
> Scala is lightyears ahead of Fantom and Fantom will probably never catch up. If Fantom can't win on technical merit, then apparently the next best strategy involves negative blogging!
Baseless at best.
In what aspect is Scala lightyears ahead?
Also what are you implying by saying 'if it can't win on technical merit then best strategy involves negative blogging!'
First Stephen is just one guy.
Second I think Stephen just likes Fantom for the same reasons he dislikes Scala and wanted to blog about it.
The authors and the community have overall been quite ambivalent to Scala. As witnessed by this blog from one of Fantom's authors: http://fantom.org/sidewalk/topic/675
After struggling through using sbt and Maven/Ivy I can say it is categorically worse than what I have used in other languages including ruby-gem python-pip clojure-leiningen (a jvm language) and node-npm. When I say worse I mean doing what the majority of developers want from a module system: easily install modules, not provide a complicated mess of configuration and versions.
This isn't to say scala couldn't adopt a better system, but I don't think the community has an incentive because scala's main appeal is that it has a steep learning curve, but after you get over the hump you can do everything you want and more. I just think that high barrier to entry, as indicated by the post, may not be worth the benefits.
Where I worked, we switched from Java to Scala a few months ago, and we're all loving it. I really don't understand Stephen Colebourne's criticisms. Well, actually, sure I understand every one of his criticisms, but I could make equally damning or more damning criticisms of just about every programming language. No programming language is perfect. On the other hand, we find Scala to be much more expressive than Java. In Scala, I can write code in a natural way, rather than the way that Java wants to force me to write it. The result is cleaner, more elegant code, that is significantly shorter with much less boilerplate and code repetition, and easier to understand.
Sure the type system is complicated, but I don't really have to understand all its nuances in order to get my program to compile and work. When you use Scala, after a short while you just develop an intuition for it.
The comparison to EJB 2 is a bit nutty, if you ask me, since writing code in Scala tends to be the antithesis of all the terrible Java monster enterprise library crap. The libraries that people use in Scala tend to be much simpler and more straight-forward.
I do agree that there's a contingent of the Scala community who seem to want to rub their fluency with category theory in your face. This is hardly representative of the entire community, however, and I'm sure they must exist in the communities for almost every functional programming language these days. The solution for this is for people to come up with more intuitive explanations for the powerful tools that category-theory inspired abstractions provide. I know that this can be done, and it will be done, when functional programming become mainstream enough that it attracts better writers.
(I, myself, have been thinking of writing up a little essay called "The Mapcat is the state monad of Massachusetts" to try to explain monads in a better way than comparing them to space suits, or whatever. Okay, okay... mapcat isn't a state monad, but I think the title's funny anyway.)
“Sure the type system is complicated, but I don't really have to understand all its nuances in order to get my program to compile and work.”
This is key. People sometimes look at the type signature of the map method (as above) and freak out. It's good to try and understand everything, mind you, and eventually you probably will. The key here is that the crazy signature of the map method simply means the map method will do what you expect. That's it! “But I would write X to do it in my language” is irrelevant, because you don't write the map method. It's provided. There's a paper that describes why the signature is how it is and everything, but you don't care, because it's complicated so that when you're actually using it, it just works.
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
All this complexity to allow for automatic conversions (the following will return a Set[String]) ...
BitSet(1, 2, 3).map { _.toString + "!" }
In a dynamic language, the signature of map is simply this: (a → b) → [a] → [b]
The big difference is that the language doesn't care about types "a" and "b" until runtime. You're the one that cares about it, only on a need-to-know basis. Hence the implicit conversions become explicit (although conversions are less necessary) and code correctness is guarded by unit tests, which you need with Scala anyway. Also, the implementation of "map" in a dynamic language is something that a junior developer can come up with.
So the biggest problems I have with Scala:
1) it is not readable
2) it separates developers in two camps:
library designers and users
3) it does not provide clear benefits
over dynamic languages (Haskell does)
Not only dynamically typed languages, the signature would also look remarkably close to (a → b) → [a] → [b] in ML and Haskell. Your ML and Haskell compiler would also make check that it was called correctly at compile time without extra unit tests.
The article seems very fear driven, many of his arguments simply do not gel with my experience.
We have been using Scala for 4 months now and have the first cut of our product released:
The Scala community have been great - we have had insightful answers on the Lift, Akka, Dispatch and Scala users list and on stack exchange.
We have used parallel collections and Akka actors to get good scalability without the usual pain. We do have some mutable data structures where it makes sense - we appreciate the flexibility to do that. The distinction between mutable and immutable data structures is pretty easy to read in the code.
Our code base is very concise, and i think readable for the breath of functionality we have implemented. We have not used type level programming, simple Scala constructs like pattern matching, collections and closures make a huge difference.
You can write obtuse code in Scala - we choose not to.
In short we see Scala as a competitive advantage going forward.
Everything's unreadable until one learns to read it. This is a classic non-argument that people buy into for reasons I can't comprehend. Is Scala harder to read than other languages? Perhaps, but then just say that.
As Rich Hickey pointed out recently, "I can't read German; does that mean it's unreadable?"
I disagree. While I don't know German, I can read German and even will understand some words and in some contexts even the general meaning of the sentence (i.e. restaurant menu or technical texts with large amount of English loanwords/terms).
You don't need to know Python, to understand it on the level of pseudo-code. You don't need to know Clojure to understand it on the level of S-expressions, etc.
There are those who say scala is complicated, and there are those who actually learn it and once they do they love it more than anything out there. So yeah, I love scala.
[edit: also, you're inferring the experience of people from the complaints that they make. that means that you are automatically dismissing anyone who makes certain kinds of complaints simply because you know that some people who make those complaints have little experience of scala. so, for a very simple example, you might find that only people with a very high tolerance for type system induced pain can tolerate scala - then you would be dismissing the majority of people, presumably with valid criticisms of scala, just because they are not part of your (self-selected, exceptional - and not necessarily in a good way) clique.]
For the past few years, I've used Scala every time I need to do something on JVM (which isn't too often). Otherwise I use Python or C++. I don't blog about it.
Scala is clearly an improvement over Java (although I wish they'd kept a C-style for loop). I happen to slightly prefer it to Clojure (which is also better than Java for my purposes).
In the non-Java JVM ecosystem, there are always these angry bucket-of-crabs posts from enthusiasts. Ignore them.
Scala is awesome, when combined with AKKA it's even better. We're much more efficient then we ever were in Java. Also, ops doesn't know it's not java since they can use all the same jvm tools.
val myList = "Jim" :: "Bob" :: Nil
myList(println)
Heh to a Java programmer, the answer would be - everything.
Here are my thoughts on it.
- I get val myList is some sort of list...
- Seems to be a list of Strings. But what is ::?
- Nil means list is nullable. Wait is one of the parts of list 'myList(println)' (looks a bit like Smalltalk)?
- Why is println the argument and not the method? Is that syntax correct?!
Compare same thing in Fantom. Note ; is only used as a separator and is equal in all respects to '\n'.
i.e. reorder those and add a semicolon or put it on the next line
and I agree with pivo that "Jim" :: "Bob" :: Nil should be List("Jim", "Bob"). I'm not sure if these are the same as _Y_'s Fantom code, but both of these print out "List(Jim, Bob)" in Scala.
Umm, I'd say Scala is to Java what C# was to Java. It cleared some things at expense of come other things. Overall it's pretty cool language (I rarely use :P).
They were an early Java attempt to "save" programmers from the complexities of writing actual systems by adding all sorts of abstractions and supporting server software. They were an abomination, used mainly by "enterprise" shops that were willing to spend money on everything but programmers who knew what they were doing.
As far as I could tell, they were a classic example of the architecture astronaut's tendency to inflict blue-sky designs on others before actually using them in the real world. They sounded great in the marketing brochures, but were hideous in practice, both for development and run-time use.
The EJB3 transition he mentions came about because EJB as a product was getting its ass kicked by Hibernate and related open-source, field-tested software. Eventually they just threw out EJB2 and said, "Hey, EJB3 is a bold, innovative approach that just happens to look exactly like Hibernate."
i used scala for a few months. it sounded very promising, java without the verbosity. but in the end i decided to stop using it.
The biggest problem for me was readabilty. Scala is the first language that i've learned where at first i couldn't just read code and immediately guess what it does.
I think the prime reason for this is that scala permits operator overloading; more than that, in fact, almost every character can be an identifier. This results in often very cryptic code and libraries, because you can't guess what that function does without reading its definition. quick, what's the difference between +++ and ::: ? what's /: and /:\ ? You can't even google it!
The other big problem for me was the type system. At first it sounded really great, and in fact the amount of compile-time code verification that you can achieve is indeed impressive. But in practice, i found myself fighting with the type system a lot, for example when trying to reuse a function with generic type restrictions that I had't written: some time these can get very long and your only choice is to copy-paste them from the original definition.
Also, how do you test that your type constraints are correct? you can't, by definition, write compilable code that would invalidate them.
Finally, it turns out that a lot of the bad stuff that's in java ends up in scala also, because of runtime compatibility concerns. in particular, scala's generics are an extension of java's. so, for example, almost all generic type information is lost at runtime, except for some extra metadata that scala stores in the object. this results in pretty ugly code when you have a dynamic object and you need to use it with a generic method.
>I think the prime reason for this is that scala permits operator overloading; more than that, in fact, almost every character can be an identifier.
I've been toying with the idea of trying scala for a serious project for a few months, and this part scares me. It's so obviously a bad idea it makes me wonder what other dumb things are in there.
[+] [-] ekidd|14 years ago|reply
If you want a dynamic language, you have lots of great choices. If you want powerful syntactic abstractions, you have Clojure, Lisp or Racket. You can win big with any of these tools.
But some problems benefit from powerful mathematical abstractions, and that's where Haskell and Scala start to shine. For example, if you need to do Bayesian filtering, you can bury all the math in a monad, and make Bayes' rule as easy as an 'if' statement. (I've got a blog post for the curious: http://www.randomhacks.net/articles/2007/02/22/bayes-rule-an... ) And when your library designs start involving generalizations of linear algebra, even Ruby-lovers may learn to appreciate a strong type system.
But this raises the real question: How useful is Scala if you don't need to do functional programming with a strong type system? Most people don't, at least today, and the jury's still out on whether it will ever be mainstream. Certainly, some smaller companies will use Scala and win big in specialized domains. But if Java hackers want to claim that Scala's an inappropriate tool for their jobs, who am I to argue? I write far more Ruby than Haskell, because I encounter lots of work that's well-suited to Ruby. (Of course, there's also Akka and a lot of other useful Scala features, which may appeal to people who don't need FP.)
So if Scala becomes seriously popular, I'll be delighted. But a large fraction of Scala's complexity is devoted to niche use cases, and that may make some people unhappy if they're merely looking for a "better Java".
[+] [-] stephen|14 years ago|reply
Functional programming with a strong type system, IMO, has much wider applicability than just the esoteric mathematical abstractions (e.g. Haskell/scalaz) that you're asserting is a niche for Scala.
I can think of many non-scalaz uses of Scala, but even for non-Scala uses, look at Jane Street's evangelism of OCaml (functional + strong type system) for financial systems.
(Note that, personally, while I like the benefits of FP, I admittedly still think in/like aspects of OO, even if just out of habit, so I find Scala's blend particularly nice.)
[+] [-] tel|14 years ago|reply
Everything I do with probability ends up looking mathematically dissimilar to probability. Most algorithms go far out of their way to avoid on-the-fly normalization because it's so expensive. An EM update monad is just the State monad.
I love Haskell (never used Scala) but I find the very things you're marketing it with abhorrent to use.
[+] [-] nickik|14 years ago|reply
[+] [-] soc88|14 years ago|reply
A) The language doesn't fall apart as soon as you try something not imagined by the original language creators.
B) Pushing the boundaries actually returns useful results.
C) Java isn't able to solve the given task or at least not productively.
That doesn't make Scala a non-general-purpose language. Probably the majority out there is using Scala as a better Java and is perfectly happy with it.
[+] [-] dkhenry|14 years ago|reply
firstly it is never good when you start out a discussion by saying now I know people will disagree but thats because their bigoted zelots. Its kind of disingenuous to attempt to post a technical dissent filled with personal opinion and preface it with that kind of clause inevitability allowing you to label any dissent as "See those scala zelots are at it again"
That being said this is an article that attempts to raise technical problems with scala but really just list a few of the authors own personal gripes with the language. In order here are his complaints
1. Scala doesn't have a rigid versioned module system 2. The functional way of doing concurrency isn't how I like to do concurrency 3. The scala community isn't helpful enough for me 4. The type system is too powerfull 5. The syntax is too flexable 6. There aren't enough tests in the compiler test suite
Its alot of the same thing I have seen when people try to list "The" problems with the language and not "Their" problems with the language. Technically there is only one argument that could even hold water thats about the module system . Which if he really needs a module system for his work then that is a technical limitation of the language and he might consider using a better tool for his job. The rest of it however is just nonsense and personal opinion pretending to be technical dissent.
[+] [-] timclark|14 years ago|reply
[+] [-] nirvdrum|14 years ago|reply
The book also weighs in at 883 pages and I was astonished how much of it I needed to read to even get started. Once I did, I very much like what I saw. But I was a big fan of ML back in grad school.
I do share some of the blog author's gripes though. Most of the popular Scala libraries are just a mess of DSL operators that have no real world association. I'm constantly having to look up what an operator means. I still have no clue how to use the Dispatch library, since the concepts it encapsulates are about 400 pages deeper into the book than I'm currently at. This, just to issue an HTTP GET request. I really thought there might be something on the lines of Ruby's rest-client library.
Additionally, my issues with versioning occur at a much simpler level. The release notes of any given Scala release are devoid of anything useful. Usually it's just a list of JIRA issue numbers (not the issue titles). And then there was this whole debacle around 2.9.0.1 and how SBT called the version. That took me 4 hours longer to work than was really necessary.
So, anyway, I do have some Scala projects. Incidentally they're all Java interop because I just can't wrap my head around how to use most of the Scala-specific libraries. But I've found it works really well in those situations. Deep down I really do like the language. The Scala ecosystem leaves a lot to be desired, but fortunately I can pull in stuff from elsewhere on the JVM.
[+] [-] noelwelsh|14 years ago|reply
[+] [-] codelion|14 years ago|reply
- Compatible with JVM
- Strong type system
- Concurrency constructs built in as actors (Akka)- Integration of OO and functional paradigms
- Supports Higher Order Programming
- defn-site Variance based Parametric Polymorphism
- Mixin Class Composition for finer grain reuse
- Traits provide stackable behaviors (aspect-oriented style)
- Embedded Polymorphic Domain Specific Language (DSL) using dependent path types
Every language design is a trade off, but Scala is more expressive and concise than Java. Sometimes that may look to you as code which is unreadable. Other languages like clojure make some other trade offs. But Scala tries to bring some of the benefits of functional programming (in say Haskell) to Java.
[+] [-] timclark|14 years ago|reply
Will I still understand my own code in 9 months time?
I think that their is more to being a good language than a list of features.
[+] [-] trurl|14 years ago|reply
I suspect you are thinking of structural subtyping, which is a completely different concept.
[+] [-] sreque|14 years ago|reply
However, the rest of us lesser mortals use Scala very differently, and we far outnumber these people. If you pay attention to Martin Odersky, the creator of the language, you'll notice that he is more interested in serving our needs than those of the Haskellites. He's outright refused to make IO monads a core part of the language, for instance, even though they have pushed for it. He's also said that scalaz is on another planet entirely, and he's asked publicly that people stop using symbolic method names in their libraries unless they have external meaning beyond the library. This guy gets it. He really has created a language that is powerful, but also practical, an excellent language for writing code that is readable, maintainable, efficient, and concise.
The author of this article admits that Scala doesn't feel right to him. He then proceeds to try to justify that feeling in his mind with some very weak arguments. For instance, his module argument oh so coincidentally happens to play into fantom's strengths alone, as No other JVM language is trying to tackle this problem right now. He is right about the lack of tests and binary incompatibility, but these are known issues that already have been addressed to some extent and are continuing to be addressed. They are not core issues with the language itself.
Scala is lightyears ahead of Fantom and Fantom will probably never catch up. If Fantom can't win on technical merit, then apparently the next best strategy involves negative blogging!
[+] [-] _Y_|14 years ago|reply
Nevertheless I find this statement:
> Scala is lightyears ahead of Fantom and Fantom will probably never catch up. If Fantom can't win on technical merit, then apparently the next best strategy involves negative blogging!
Baseless at best. In what aspect is Scala lightyears ahead?
Also what are you implying by saying 'if it can't win on technical merit then best strategy involves negative blogging!'
First Stephen is just one guy. Second I think Stephen just likes Fantom for the same reasons he dislikes Scala and wanted to blog about it.
The authors and the community have overall been quite ambivalent to Scala. As witnessed by this blog from one of Fantom's authors: http://fantom.org/sidewalk/topic/675
[+] [-] jethroalias97|14 years ago|reply
This isn't to say scala couldn't adopt a better system, but I don't think the community has an incentive because scala's main appeal is that it has a steep learning curve, but after you get over the hump you can do everything you want and more. I just think that high barrier to entry, as indicated by the post, may not be worth the benefits.
[+] [-] timclark|14 years ago|reply
[+] [-] nessus42|14 years ago|reply
Sure the type system is complicated, but I don't really have to understand all its nuances in order to get my program to compile and work. When you use Scala, after a short while you just develop an intuition for it.
The comparison to EJB 2 is a bit nutty, if you ask me, since writing code in Scala tends to be the antithesis of all the terrible Java monster enterprise library crap. The libraries that people use in Scala tend to be much simpler and more straight-forward.
I do agree that there's a contingent of the Scala community who seem to want to rub their fluency with category theory in your face. This is hardly representative of the entire community, however, and I'm sure they must exist in the communities for almost every functional programming language these days. The solution for this is for people to come up with more intuitive explanations for the powerful tools that category-theory inspired abstractions provide. I know that this can be done, and it will be done, when functional programming become mainstream enough that it attracts better writers.
(I, myself, have been thinking of writing up a little essay called "The Mapcat is the state monad of Massachusetts" to try to explain monads in a better way than comparing them to space suits, or whatever. Okay, okay... mapcat isn't a state monad, but I think the title's funny anyway.)
[+] [-] shadowfiend|14 years ago|reply
This is key. People sometimes look at the type signature of the map method (as above) and freak out. It's good to try and understand everything, mind you, and eventually you probably will. The key here is that the crazy signature of the map method simply means the map method will do what you expect. That's it! “But I would write X to do it in my language” is irrelevant, because you don't write the map method. It's provided. There's a paper that describes why the signature is how it is and everything, but you don't care, because it's complicated so that when you're actually using it, it just works.
[+] [-] bad_user|14 years ago|reply
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
All this complexity to allow for automatic conversions (the following will return a Set[String]) ...
BitSet(1, 2, 3).map { _.toString + "!" }
In a dynamic language, the signature of map is simply this: (a → b) → [a] → [b]
The big difference is that the language doesn't care about types "a" and "b" until runtime. You're the one that cares about it, only on a need-to-know basis. Hence the implicit conversions become explicit (although conversions are less necessary) and code correctness is guarded by unit tests, which you need with Scala anyway. Also, the implementation of "map" in a dynamic language is something that a junior developer can come up with.
So the biggest problems I have with Scala:
[+] [-] timclark|14 years ago|reply
[+] [-] jzoidberg|14 years ago|reply
We have been using Scala for 4 months now and have the first cut of our product released:
The Scala community have been great - we have had insightful answers on the Lift, Akka, Dispatch and Scala users list and on stack exchange.
We have used parallel collections and Akka actors to get good scalability without the usual pain. We do have some mutable data structures where it makes sense - we appreciate the flexibility to do that. The distinction between mutable and immutable data structures is pretty easy to read in the code.
Our code base is very concise, and i think readable for the breath of functionality we have implemented. We have not used type level programming, simple Scala constructs like pattern matching, collections and closures make a huge difference. You can write obtuse code in Scala - we choose not to.
In short we see Scala as a competitive advantage going forward.
[+] [-] michaelcampbell|14 years ago|reply
As Rich Hickey pointed out recently, "I can't read German; does that mean it's unreadable?"
[+] [-] nivertech|14 years ago|reply
You don't need to know Python, to understand it on the level of pseudo-code. You don't need to know Clojure to understand it on the level of S-expressions, etc.
[+] [-] krookoo|14 years ago|reply
[+] [-] andrewcooke|14 years ago|reply
- http://en.wikipedia.org/wiki/Commitment_bias
- http://en.wikipedia.org/wiki/Endowment_effect
- http://en.wikipedia.org/wiki/Sunk_costs
- http://en.wikipedia.org/wiki/Herd_behavior
[edit: also, you're inferring the experience of people from the complaints that they make. that means that you are automatically dismissing anyone who makes certain kinds of complaints simply because you know that some people who make those complaints have little experience of scala. so, for a very simple example, you might find that only people with a very high tolerance for type system induced pain can tolerate scala - then you would be dismissing the majority of people, presumably with valid criticisms of scala, just because they are not part of your (self-selected, exceptional - and not necessarily in a good way) clique.]
[+] [-] jongraehl|14 years ago|reply
Scala is clearly an improvement over Java (although I wish they'd kept a C-style for loop). I happen to slightly prefer it to Clojure (which is also better than Java for my purposes).
In the non-Java JVM ecosystem, there are always these angry bucket-of-crabs posts from enthusiasts. Ignore them.
[+] [-] codelion|14 years ago|reply
[+] [-] twp|14 years ago|reply
If Java is CVS, then Scala is Subversion and Clojure is git.
[+] [-] silon3|14 years ago|reply
[+] [-] timf|14 years ago|reply
[+] [-] beagledude|14 years ago|reply
val myList = "Jim" :: "Bob" :: Nil myList(println)
what's hard about that?
[+] [-] _Y_|14 years ago|reply
Here are my thoughts on it. - I get val myList is some sort of list... - Seems to be a list of Strings. But what is ::? - Nil means list is nullable. Wait is one of the parts of list 'myList(println)' (looks a bit like Smalltalk)? - Why is println the argument and not the method? Is that syntax correct?!
Compare same thing in Fantom. Note ; is only used as a separator and is equal in all respects to '\n'.
[+] [-] tvorryn|14 years ago|reply
; println(myList)
i.e. reorder those and add a semicolon or put it on the next line
and I agree with pivo that "Jim" :: "Bob" :: Nil should be List("Jim", "Bob"). I'm not sure if these are the same as _Y_'s Fantom code, but both of these print out "List(Jim, Bob)" in Scala.
[+] [-] eweise|14 years ago|reply
[+] [-] ajuc|14 years ago|reply
[+] [-] _Y_|14 years ago|reply
[+] [-] Maven911|14 years ago|reply
[+] [-] wpietri|14 years ago|reply
As far as I could tell, they were a classic example of the architecture astronaut's tendency to inflict blue-sky designs on others before actually using them in the real world. They sounded great in the marketing brochures, but were hideous in practice, both for development and run-time use.
The EJB3 transition he mentions came about because EJB as a product was getting its ass kicked by Hibernate and related open-source, field-tested software. Eventually they just threw out EJB2 and said, "Hey, EJB3 is a bold, innovative approach that just happens to look exactly like Hibernate."
[+] [-] adabsurdo|14 years ago|reply
The biggest problem for me was readabilty. Scala is the first language that i've learned where at first i couldn't just read code and immediately guess what it does.
I think the prime reason for this is that scala permits operator overloading; more than that, in fact, almost every character can be an identifier. This results in often very cryptic code and libraries, because you can't guess what that function does without reading its definition. quick, what's the difference between +++ and ::: ? what's /: and /:\ ? You can't even google it!
The other big problem for me was the type system. At first it sounded really great, and in fact the amount of compile-time code verification that you can achieve is indeed impressive. But in practice, i found myself fighting with the type system a lot, for example when trying to reuse a function with generic type restrictions that I had't written: some time these can get very long and your only choice is to copy-paste them from the original definition.
Also, how do you test that your type constraints are correct? you can't, by definition, write compilable code that would invalidate them.
Finally, it turns out that a lot of the bad stuff that's in java ends up in scala also, because of runtime compatibility concerns. in particular, scala's generics are an extension of java's. so, for example, almost all generic type information is lost at runtime, except for some extra metadata that scala stores in the object. this results in pretty ugly code when you have a dynamic object and you need to use it with a generic method.
[+] [-] tsotha|14 years ago|reply
I've been toying with the idea of trying scala for a serious project for a few months, and this part scares me. It's so obviously a bad idea it makes me wonder what other dumb things are in there.
[+] [-] Runar|14 years ago|reply