5 ms·

What the the article seems to miss is that Scala can be used strictly as a "better Java" without using any of the advanced type features or idioms if that is wh

What the the article seems to miss is that Scala can be used strictly as a "better Java" without using any of the advanced type features or idioms if that is what you want. (Anecdotal)War Story: Once upon a time I worked with a team of scientists (not professional developers) who had some legacy research code in Java, had tried moving to Scala and got badly bitten by the advanced type theory bits and so were considering moving back to Java. When I joined the team I taught them how to use the "Scala as a better Java" approach, (which would correspond to approximately the L1 level in Martin Odersky's blog post at http://www.scala-lang.org/node/8610 http://www.scala-lang.org/node/8610) and to this day they are happily building new stuff in Scala (and Java). Just as you can use Common Lisp without completely mastering macros, the condition system etc, to get stuff done at the cost of some redundancy when compared to what the code would look like if an expert were to write it, so can you use subsets of Scala to get serious work done. I suspect problems arise when you have the attitude that you must completely master the language before you start using it to build stuff. This excludes all but the ultra simple languages from consideration. Reductio Ad Absurdum, Imagine a world where the only programming language in use is VB (or even C) ! I offer the hypothesis that when using any new and "large" language on a real life project you have to work with a subset. This is not a bad thing and "subset" is not a dirty word (as long as the subset is clearly identified and at least as good as the alternative languages). As you gain experience with the subset and actually build useful systems with it you can then go deeper into the language and learn more advanced features, which you can then use to refactor your code to use those advanced features where appropriate, in a virtuous cycle. Imagine you are learning a non programming language (say French) or even musical notation. If you wait till you have wrapped your head completely around whatever you are learning before you start using it, you are (a) going to wait a long time (b) very unusual in your approach. Is having an ultra simple syntax or a small surface area a virtue? Yes it is. It is one aspect of a design but not the only one. The lack of an IDE is a more valid complaint, (especially if you plan to have big teams of mediocre programmers) but then you restrict yourself to using only core mainstream languages with very strong vendor ecosystems (say Java, VC++, C# and VB). It would be nice if every new language sprang from their creators brows fully equipped with ultra functional IDEs but that maybe a tad unrealistic a wish ;-). I also suspect that most of the carping comes from people who haven't actually used Scala in any serious fashion. Complaints about "too complex a type system" from people who have never used Scala to actually build something have about as much legitimacy as people who refuse to use Lisp because it has "too many parantheses" and just "know" that parantheses are confusing.

Nitramp 16y ago
I think the "subsetting the language" approach is a red herring. Yes, you can decide you'll only use feature X, Y, and Z. Many people do that in similarly complex languages like C++. But the programmers will, one way or the other, get exposed to the features you considered esoteric. Be it through libraries, or sample code, or whatever. And then they have a piece of code in the language they use for daily work that they don't understand, can't debug, and are alienated by strange compiler errors - not good. It's IMHO also quite hard to come up with the subset you like. I mean, programmers like to have endless discussions about completely irrelevant topics, like brace placement; wait and see the discussions about actual language features to (not) use! Like I said in the other comment, most features are in themselves completely reasonable, so it's hard to make a cut here. I also think the 'mediocre programmer' is a red herring. Not that there aren't mediocre programmers that will have trouble to understand certain language features at all - there certainly are. But I'd wager that even for very good programmers, having many complex language features (that interact!) in a code base will be problematic. Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think". Having code in a code base that's complex and/or hard to understand is a really, really bad thing. People will shy away from reading and modifying it, and over time it'll grow into an unmaintained monstrosity. Again, this is about the complexity budget. Original Java code was dead easy to understand, now with generics it's a bit harder (but overall I think generics are less bad than you hear all the time). That was and still is one of the really killer Java features. Not only for mediocre programmers, but for general readability, and thus usability of the language.
- plinkplonk 16y ago
  "Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think"." By this logic no one would use the command line and Windows click thru wizards blow Unix away. I agree that guis are good for non programmers. Java is better than Scala for some subset of programmers. So is VB. The problem arises when that statement is modified to use the Universal Quantifier. The thing about a "powerful" programming language though (or for that matter a command line) is that it is a power tool. No one forces you to use it and you shouldn't if you feel it is too complex, but using some mythical "complexity budget" as if it were some kind of inviolable scientific fact is (imo) bogus. The "complexity budget" of anything is a function of the context of its use. As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine. "Again, this is about the complexity budget." There is no such thing independent of the intent of the language designer and the context of the use of the tool. Scala and Erlang and Haskell are not intended to occupy the same "complexity point" as Java 1.4. So what? Pascal has a lesser "complexity budget" than C. That doesn't make the former uncontestably "better" independent of context. And anyway my original point was only that once you choose a language which you can't grasp all at once, for whatever reason, you should start programming with the subset you do understand rather than wait till you completely grok it. You can always choose to work with "low complexity" languages if that is what you want.

Nitramp 16y ago

I think the "subsetting the language" approach is a red herring. Yes, you can decide you'll only use feature X, Y, and Z. Many people do that in similarly complex languages like C++. But the programmers will, one way or the other, get exposed to the features you considered esoteric. Be it through libraries, or sample code, or whatever. And then they have a piece of code in the language they use for daily work that they don't understand, can't debug, and are alienated by strange compiler errors - not good. It's IMHO also quite hard to come up with the subset you like. I mean, programmers like to have endless discussions about completely irrelevant topics, like brace placement; wait and see the discussions about actual language features to (not) use! Like I said in the other comment, most features are in themselves completely reasonable, so it's hard to make a cut here. I also think the 'mediocre programmer' is a red herring. Not that there aren't mediocre programmers that will have trouble to understand certain language features at all - there certainly are. But I'd wager that even for very good programmers, having many complex language features (that interact!) in a code base will be problematic. Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think". Having code in a code base that's complex and/or hard to understand is a really, really bad thing. People will shy away from reading and modifying it, and over time it'll grow into an unmaintained monstrosity. Again, this is about the complexity budget. Original Java code was dead easy to understand, now with generics it's a bit harder (but overall I think generics are less bad than you hear all the time). That was and still is one of the really killer Java features. Not only for mediocre programmers, but for general readability, and thus usability of the language.

plinkplonk 16y ago
"Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think"." By this logic no one would use the command line and Windows click thru wizards blow Unix away. I agree that guis are good for non programmers. Java is better than Scala for some subset of programmers. So is VB. The problem arises when that statement is modified to use the Universal Quantifier. The thing about a "powerful" programming language though (or for that matter a command line) is that it is a power tool. No one forces you to use it and you shouldn't if you feel it is too complex, but using some mythical "complexity budget" as if it were some kind of inviolable scientific fact is (imo) bogus. The "complexity budget" of anything is a function of the context of its use. As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine. "Again, this is about the complexity budget." There is no such thing independent of the intent of the language designer and the context of the use of the tool. Scala and Erlang and Haskell are not intended to occupy the same "complexity point" as Java 1.4. So what? Pascal has a lesser "complexity budget" than C. That doesn't make the former uncontestably "better" independent of context. And anyway my original point was only that once you choose a language which you can't grasp all at once, for whatever reason, you should start programming with the subset you do understand rather than wait till you completely grok it. You can always choose to work with "low complexity" languages if that is what you want.