9 ms·

Switching to Plan J (From Scala back to Java)

95 points by cfontes 16y ago

rst 16y ago
You don't know what Scala code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. You don't know what Ruby code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. Heck, you don't know what annotated Java code is doing unless you're familiar with the build tooling that processes the annotations, and the libraries it invokes; syntax isn't much of a guide. There's a pattern here. I'm not sure it has much to do with the language.
- fedd 16y ago
  > You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. i'd say this about Perl or Ruby, but C++?
  - vilya 16y ago
    Yeah. With operator overloading, automatic type conversions, template expansions and so on it's a fair criticism.
  - stonemetal 16y ago
    C = A + B; In C++ what does this line do? The list of things that can effect what this line of code does are: Types of A,B, and C, single arg constructors, explicit conversion operators, operator +, operator =, and copy constructors might come into play. I more than likely have forgotten something from that list.
    - VMG 16y ago
      Macros.
- beza1e1 16y ago
  That's essentially the argumentation of Torvalds, why i likes C. In C you know, what the code does. Higher macro magic is rare.
  - fogus 16y ago
    And his point (among other things) is that the lack of namespacing is a win in this respect because it fosters the practice of explicit naming like: `smtp_connect()` rather than `connect()`.
- Almaviva 16y ago
  This is a silly excluded middle argument, no?
- jimbokun 16y ago
  Left out Lisp macros.
- lyudmil 16y ago
  Isn't this to be expected when you add abstraction? I'll argue that not "knowing what [the] code is doing" isn't such a bad thing. In fact, I don't think we can have advances in language design without relaxing the constraint you're alluding to. Consider an extreme scenario where I've designed a language where the following line of code does what you'd expect: ask for an input, assume it is a number, calculate its factorial, and display it Notice that you have never seen this language before and you have no idea what's going on under the hood to make this happen. However, you know what the code is expected to accomplish. I think that's a worthwhile tradeoff. It's what all of these languages are trying to do - to allow the programmer to write down their thoughts as close to human language as possible. You only need to care about how things work at the lower level of abstraction when the abstraction has a bug or needs changing. If I can work 80% of my time at the level of abstraction of the "code sample" above (diving into the nasty internals 20% of the time) I'd start using that language immediately.
dochtman 16y ago
I did some research (but not actual programming) to compare Java to Scala, specifically in the area of generics. If you are hoping for some language to make static typing palatable again, Scala is not it: it's so good at static typing that it can statically type anything, but it takes intricate details and more knowledge of its type system than most would want to care about to get it right. In general, I felt there were too many niggly little details in the syntax to be a nice language to use. Of course, I'm used to Python, so I may well be spoiled.
- jfager 16y ago
  I agree with the characterization of Scala's generics as complicated, but I disagree that that ends up making its static typing unpleasant or day-to-day programming difficult. Type inference is a big win, and other language features add enough that I find myself not reaching for generics for my own code anywhere near as often as I did with Java. Aside from the occasional container type missing from the standard API, I just pretty much don't use generics in Scala except as a consumer, and I don't miss them.
- micrypt 16y ago
  I actually do programming in Scala and I'd have to disagree. While there's the freedom to build a "type castle", you don't have to. For the most part Scala gets things right. When you do need/want to get fancy with types, you get some of the best tools out there to do it.
thurn 16y ago
If you need Eclipse-level tools to be productive, you probably shouldn't be trying new programming languages. It takes hundreds or thousands of man-years of effort to replicate those features for a new language. Python and Ruby only really got there recently.
- foljs 16y ago
  > It takes hundreds or thousands of man-years of effort to replicate those features for a new language. Exaggerate much? C# had a great IDE when it appeared, and it sure didn't take Microsoft "hundreds of thousands of man-years of effort" to add C# support to Visual Studio. Heck, it didn't even take the Eclipse team "hundreds of thousands of man-years of effort" to build Eclipse's Java IDE support. Since Eclipse took around 5 years to mature enough from its inception circa 2000, "100,000 man years of effort" would suggest it was build by a team of 100,000/5 = 20,000 programmers. That's a couple of orders of magnitude removed from the actual number. > Python and Ruby only really got there recently. Actually, IMHO, Python and Ruby never got there. There is no Python/Ruby IDE with as much support for the languages and their features as Eclipse JAVA IDE has for Java. And there might never be one, due to their dynamic nature, unless a team puts real effort in and reuses the actual AST of the language for syntax support and other such tricks...
- pnathan 16y ago
  I've really had to play with enough languages in the last few years that IDEs are just more trouble than they are worth to me. The editing isn't great, the tools are sketch, and the design of visual space tends to be poor. And always being on the tool learning-curve gets old... So I stick with emacs and my primary IDE-esque tools are syntax highlighting and hippie-expand. The only time I break out of my emacs world is to run debuggers.
  - zeugma 16y ago
    you should give GUD a try (M-x gdb).
meowzero 16y ago
I've been doing my scala stuff using sbt and vim. So far, it's working out quite nicely. I haven't played with sbt plugins for various IDEs (I'm too used to vim), I would assume it should still work.
lsd5you 16y ago
Scala subsetting (as mentioned in the comments) sounds like a promising avenue. Especially if it were to result in better performing tools. Unfortunately for all the great features scala does have, Java has a few killer features that it lacks i.e. fast (instantaneous) and reliable compilation and debugging.
fab13n 16y ago
One of the key design principles behind Java was to be a cleaner C++: remove all the hippie stuff which make programs too hard to read back, which makes one thing look like it's something else entirely, etc. The result is a boring but reliable language, which gave birth to a wide ecosystem of good quality libraries. Scala puts back all the hippie stuff into Java. Together with them, it brings back the associated problems which plagued C++. OK, some stuff are done in a less broken way in Scala, largely because they don't try to be a superset of C. But still, we end up with a language hard to read, hard to trust, hard to support for IDEs... not something you want to use for big teams or long-term programming.
- fogus 16y ago
  And my natural question is: have you actually used Scala for real work, or are you just theorizing?
  - fab13n 16y ago
    I had to make some evolutions in an Eclipse plug-in which was written in Scala (the module wasn't intended to manipulate Scala code, it just happened to be the implementation language). I initially had a positive prejudice, as a OCaml enthusiast who used to get paid for developping in OCaml; moreover, as someone who's been exposed to languages with serious abtraction power, I easily get irritated by Java. The code was a true pain in the ass to work with: integration with OSGi was cumbersome, lots of black magic features were used gratuitously, the possibility to define stuff-which-look-like-methods-yet-aren't-in-the-class made quite a mess of code exploration, and of course tooling support was abysmally bad. I know the usual rebuttal: it's the bad developer's fault, not the language's. I don't buy this, a "good" language for which you can't find decent coders isn't any good. - Scala-like languages tend to attract guys who will mess with all the quirky features of the language; - In real life, developers are a given and the language is the adjustment variable, not the other way around. Most people don't have the luxury of only working with rockstars, and most of the cornerstones of the Internet haven't been developed by rockstars anyway. - The average developer will do an average job of writing maintainable Java, and an awful job of writing acceptable Scala, if only because there's no widespread consensus ov what it means for Scala code to be acceptable. Java is dull and uneventful, and I'd rather take over a syntactically dull and uneventful code base than an "interesting" one. - I've heared several times that "you can use Scala as a Java with closures". It's a variant of the argument that there's a 5 times smaller language hidden in C++ that's beautiful: nobody ever agreed over which 20% should be selected. The two languages which gave me the impression of trying to support every feature ever invented, and of making it very difficult for people to acquire and share a notion of standard, maintainable code are C++ and Scala. An iconic counter-example would be Python. More anecdotically, I spent a couple of days studying how Lift works, for personal curiosity. I found the code hard to navigate into. due to too many non-orthogonal ways of composing code together. A good tooling support would have helped, but if it doesn't exist after all those years, I might mean that there's something wrong with the language: it's not as if the need wasn't clearly perceived.
Nitramp 16y ago
This is what the Java designers always talk about: languages have a "complexity budget". You can choose to spend your complexity budget on different features (static typing, generics, closures, manual memory management, auto casts, overloaded operators, ...). Some features can take away complexity (GC). But once you've overdrawn your budget, the language gets creaky to use and everybody starts talking about "subsetting" the language. C.f. C++ - all those features do serve a purpose, and looking at the feature alone, it might be reasonable. I think Scala has way blown its complexity budget. They've innovated on too many different fronts. I'd been happy to have Java with closures, first class functions, and maybe better generics. There was a lot of buzz around DSLs at some point of time, and they decided to go all in with implicits, which I think was a bad idea. I guess they were trying to market the language...
- jfager 16y ago
  I don't understand what you mean when you say they went all-in on DSLs with implicits. I far more often use implicits for integrating Java libraries or papering over clunky apis than for putting together DSLs.
  - Nycto 16y ago
    Just take a look at how specs [1] works: "Some element" should { "behave in some way" in { // ... } } According to this, the String type has a "should" method and an "in" method, but it really doesn't. Instead, there is an implicit conversion from a string to another type that actually has those methods. They idea here is to make the DSLs more fluent by removing the need to worry about complex type interactions while designing the interface. It lets the users use the pre-existing types they're already familiar with. [1] http://code.google.com/p/specs/ http://code.google.com/p/specs/
    - fizx 16y ago
      These DSLs in Scala can be awful. I mean: val ivySvn = "ivysvn" % "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Oh, but if you use a different maven convention, just double up the first percent sign: val ivySvn = "ivysvn" %% "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Readable, yes; intuitive, no.
dan00 16y ago
Scala seems to be the academic kitchen sink of programming languages.
plinkplonk 16y ago
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.
kokoloko 16y ago
In this same thread Martin Odersky announces he is working in a new version of the Scala plugin for Eclipse, to be released with Scala 2.9. A statically typed language really shines within an IDE.
cemerick 16y ago
The disaffection of ex-Java-devs towards these newer JVM languages is only really surprising if you were expecting any other language to overtake Java for Java developers. I used to think that would come to pass, but I've been convinced otherwise. By the time Java 8 comes around (don't expect Oracle to drag their heels on releases as prior regimes have), there will be little inherent reason for the typical Java developer to use Scala or Clojure. Only the biggest vendors (Oracle, Microsoft, IBM, et al.) have the firepower and perspective to produce/support whole-solution languages and ecosystems that go mainstream with tooling, training, and general-purpose facilities approachable for the vast middle. That is, the next Java is Java′. Of course, none of those typical devs are reading this or TFA. The real question is, which language is most applicable to particular problem domains and usable within particular organizations by atypical devs solving atypical problems? (Added bonus goes to the language that makes bidirectional interop with that vast middle of Java devs a piece of cake, for those atypical devs looking to provide libraries, tools, and products to be used by those Java devs.)
- kumarshantanu 16y ago
  Few points I can recollect (without answering "which language is most applicable...."): 1. Future of Java-the-language is limited by backward compatibility. This imposes a barrier on the scope of innovation in the language. 2. #1 can be helped by the newer JVM languages. 3. Current trend to increasingly adopt Ruby, Python or PHP for turnaround time is the result of a momentum and has to mean something. There is clearly demand for faster turnaround time in some segments. 4. The JVM languages that can reach feature parity with Ruby/Python/PHP ecosystem and tooling will have a better chance of adoption IMO. 5. The next Java is certainly not Java alone. Probably a mix of languages, depending upon which ones have a better VM, tooling, libraries, turnaround time etc.
timtadh 16y ago
I successfully used Scala as prototyping language for the first time recently. It was nice. I kinda liked it. But, I will have rewrite what I did in it soon because the VM startup cost for scala is too high for what I want to do. The lack of IDE support that the OP complained about didn't really bother me as I am more a vi/kate{+vi mode} kinda guy. That said, I could definitely see how really good IDE support would be nice to have when integrating with large Java libraries. EDIT: I forgot to mention the one thing that is nice about Java from a research perspective is it is a really easy language to work with. It's syntax is relatively easy to deal with, it doesn't have a preprocessor. Its semantics are straight forward. It has type annotations. There is a lot of code in it so you can test your research on real code bases. This makes Java the best language to conduct research on languages in. Even if it is not the best language to write it.
- noidi 16y ago
  Nailgun might help you with the startup time: http://martiansoftware.com/nailgun/ http://martiansoftware.com/nailgun/
  - jbellis 16y ago
    (Last changelog entry: 2005.)
- narrator 16y ago
  JRebel is a must when doing Scala web development. It's not free but it definitely speeds up the development process as it eliminates almost all instances where one would have to restart the app server for code changes.
  - heiflo 16y ago
    Actually, you can get a free JRebel license for Scala development: http://sales.zeroturnaround.com/ http://sales.zeroturnaround.com/
  - owhite 16y ago
    Thanks, Heiflo, I was going to say the same thing!
nickik 16y ago
Thats the reason Clojure is so great. Its an simple language. The only complex things (if you get FP) are the macros and in the clojure world macros aren't used often. The Clojure Community learnd from the old lisp makro overuse. Everybody talks about not using makros if you don't really have to. Look at this talk by C.Grand: (not= DSL macros)http://clojure.blip.tv/file/4522250/ http://clojure.blip.tv/file/4522250/ If you really want to see what happens with your code just expand it. Its extremly transparent and easy (most IDEs should be able to to this). In a talk Simon Peyton-Jones once said something like: "Macros are like missile. You don't need them often but if you want to destroy a small village nothing can be better."
- technomancy 16y ago
  > "Macros are like missile. You don't need them often but if you want to destroy a small village nothing can be better." I'm partial to "Macros are like second amendment rights. You hope you never have to use them, but if you've got no other choice then you will be very glad you have them."
joshhart 16y ago
I program in Scala because it's my pseudocode. Filter this. Transform that. Collect these. I need an object that does such and such. I'd like some new functions on an object from another library. For the most part, Scala has an immediate, direct way to do whatever task I need in a type-safe manner. The type safety is important - it really does catch bugs and makes refactoring code a lot easier than in a dynamic language. This matters when the project is larger than 2 developers. Some others liken Scala to C++. I don't think Scala is as dangerous as C++ because of immutability and garbage collection, but I'll readily admit it's a complex language. You can write Scala as Java with some nice stuff (done at http://sna-projects.com/kafka/ http://sna-projects.com/kafka/, a distributed pub/sub messaging queue) or you can go full on with the Scala like Norbert (http://sna-projects.com/norbert/ http://sna-projects.com/norbert/), an RPC/cluster management system used for search and the social graph at LinkedIn. I don't think there's a problem with either.
brendano 16y ago
This exactly summarizes why I stopped using Scala. All I wanted was a cleaned up Java, but it's much more and riskier than that.
- ehsanul 16y ago
  Maybe you'd like Mirah? http://www.mirah.org/ http://www.mirah.org/
bad_user 16y ago
I get this sentiment a lot ... Secondly, it is the ultimate language to date for writing libraries and embedded DSL’s with static types. ... These abilities go way beyond any prior statically typed language. The author conveniently left out dynamic languages; but regardless of that, I don't like Scala because: 1) you can't override the method dispatching mechanism to make use of those types in interesting ways (e.g. multimethods are possible with DLR in .NET) 2) You can't get the syntax-tree of a block of code, then recompile it to something else (e.g. LINQ - and F# supports this as a general construct). There was a compiler-plugin at some point, but it's deprecated and incomplete and full of bugs 3) All OOP languages should have optional dynamic typing; OOP just doesn't blend with static types, being one reason why Haskell is not OOP (while providing other similar tools for polymorphism) What you do get in Scala is a flexible syntax, that can lead to awkward behavior (I often find myself asking whether some line needs a semicolon). And the type-system, while better than the one in Java, is also too complex, too verbose and definitely not elegant. You know what would be elegant? Being able to test if some object is an instance of List[String] (and yes, I know about manifests and implicit parameters: it's still an ugly hack that doesn't solve all problems). One could say that Scala is a pragmatic language, but so is C++; and C++ has no replacement, while Scala does have many.
mryall 16y ago
Groovy is good alternative JVM language if you just want some improvements on Java without a completely new language to learn. It addresses many of the small frustrations I have with Java (lack of list and map literals, lack of anonymous functions) without introducing many new paradigms or complexities. I'd recommend it to anyone wanting a quick prototyping language on the JVM.
Peaker 16y ago
I never understood why anyone would want a hybrid of OO and functional programming. I see OO as basically: Encapsulation, Inheritance and Polymorphism. Functional programming provides better facilities for encapsulation and polymorphism. Interface inheritance is pretty much a subset of implicit traits or type-classes. I don't think implementation inheritance is ever the right thing. So if you have the full power of FP (including existential types and type-classes), what is it in OO that you would yearn for?

95 points by cfontes 16y ago

rst 16y ago

You don't know what Scala code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. You don't know what Ruby code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. Heck, you don't know what annotated Java code is doing unless you're familiar with the build tooling that processes the annotations, and the libraries it invokes; syntax isn't much of a guide. There's a pattern here. I'm not sure it has much to do with the language.

fedd 16y ago
> You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. i'd say this about Perl or Ruby, but C++?
- vilya 16y ago
  Yeah. With operator overloading, automatic type conversions, template expansions and so on it's a fair criticism.
- stonemetal 16y ago
  C = A + B; In C++ what does this line do? The list of things that can effect what this line of code does are: Types of A,B, and C, single arg constructors, explicit conversion operators, operator +, operator =, and copy constructors might come into play. I more than likely have forgotten something from that list.
  - VMG 16y ago
    Macros.
beza1e1 16y ago
That's essentially the argumentation of Torvalds, why i likes C. In C you know, what the code does. Higher macro magic is rare.
- fogus 16y ago
  And his point (among other things) is that the lack of namespacing is a win in this respect because it fosters the practice of explicit naming like: `smtp_connect()` rather than `connect()`.
Almaviva 16y ago
This is a silly excluded middle argument, no?
jimbokun 16y ago
Left out Lisp macros.
lyudmil 16y ago
Isn't this to be expected when you add abstraction? I'll argue that not "knowing what [the] code is doing" isn't such a bad thing. In fact, I don't think we can have advances in language design without relaxing the constraint you're alluding to. Consider an extreme scenario where I've designed a language where the following line of code does what you'd expect: ask for an input, assume it is a number, calculate its factorial, and display it Notice that you have never seen this language before and you have no idea what's going on under the hood to make this happen. However, you know what the code is expected to accomplish. I think that's a worthwhile tradeoff. It's what all of these languages are trying to do - to allow the programmer to write down their thoughts as close to human language as possible. You only need to care about how things work at the lower level of abstraction when the abstraction has a bug or needs changing. If I can work 80% of my time at the level of abstraction of the "code sample" above (diving into the nasty internals 20% of the time) I'd start using that language immediately.

dochtman 16y ago

I did some research (but not actual programming) to compare Java to Scala, specifically in the area of generics. If you are hoping for some language to make static typing palatable again, Scala is not it: it's so good at static typing that it can statically type anything, but it takes intricate details and more knowledge of its type system than most would want to care about to get it right. In general, I felt there were too many niggly little details in the syntax to be a nice language to use. Of course, I'm used to Python, so I may well be spoiled.

jfager 16y ago
I agree with the characterization of Scala's generics as complicated, but I disagree that that ends up making its static typing unpleasant or day-to-day programming difficult. Type inference is a big win, and other language features add enough that I find myself not reaching for generics for my own code anywhere near as often as I did with Java. Aside from the occasional container type missing from the standard API, I just pretty much don't use generics in Scala except as a consumer, and I don't miss them.
micrypt 16y ago
I actually do programming in Scala and I'd have to disagree. While there's the freedom to build a "type castle", you don't have to. For the most part Scala gets things right. When you do need/want to get fancy with types, you get some of the best tools out there to do it.

thurn 16y ago

If you need Eclipse-level tools to be productive, you probably shouldn't be trying new programming languages. It takes hundreds or thousands of man-years of effort to replicate those features for a new language. Python and Ruby only really got there recently.

foljs 16y ago
> It takes hundreds or thousands of man-years of effort to replicate those features for a new language. Exaggerate much? C# had a great IDE when it appeared, and it sure didn't take Microsoft "hundreds of thousands of man-years of effort" to add C# support to Visual Studio. Heck, it didn't even take the Eclipse team "hundreds of thousands of man-years of effort" to build Eclipse's Java IDE support. Since Eclipse took around 5 years to mature enough from its inception circa 2000, "100,000 man years of effort" would suggest it was build by a team of 100,000/5 = 20,000 programmers. That's a couple of orders of magnitude removed from the actual number. > Python and Ruby only really got there recently. Actually, IMHO, Python and Ruby never got there. There is no Python/Ruby IDE with as much support for the languages and their features as Eclipse JAVA IDE has for Java. And there might never be one, due to their dynamic nature, unless a team puts real effort in and reuses the actual AST of the language for syntax support and other such tricks...
pnathan 16y ago
I've really had to play with enough languages in the last few years that IDEs are just more trouble than they are worth to me. The editing isn't great, the tools are sketch, and the design of visual space tends to be poor. And always being on the tool learning-curve gets old... So I stick with emacs and my primary IDE-esque tools are syntax highlighting and hippie-expand. The only time I break out of my emacs world is to run debuggers.
- zeugma 16y ago
  you should give GUD a try (M-x gdb).

meowzero 16y ago

I've been doing my scala stuff using sbt and vim. So far, it's working out quite nicely. I haven't played with sbt plugins for various IDEs (I'm too used to vim), I would assume it should still work.

lsd5you 16y ago

Scala subsetting (as mentioned in the comments) sounds like a promising avenue. Especially if it were to result in better performing tools. Unfortunately for all the great features scala does have, Java has a few killer features that it lacks i.e. fast (instantaneous) and reliable compilation and debugging.

fab13n 16y ago

One of the key design principles behind Java was to be a cleaner C++: remove all the hippie stuff which make programs too hard to read back, which makes one thing look like it's something else entirely, etc. The result is a boring but reliable language, which gave birth to a wide ecosystem of good quality libraries. Scala puts back all the hippie stuff into Java. Together with them, it brings back the associated problems which plagued C++. OK, some stuff are done in a less broken way in Scala, largely because they don't try to be a superset of C. But still, we end up with a language hard to read, hard to trust, hard to support for IDEs... not something you want to use for big teams or long-term programming.

fogus 16y ago
And my natural question is: have you actually used Scala for real work, or are you just theorizing?
- fab13n 16y ago
  I had to make some evolutions in an Eclipse plug-in which was written in Scala (the module wasn't intended to manipulate Scala code, it just happened to be the implementation language). I initially had a positive prejudice, as a OCaml enthusiast who used to get paid for developping in OCaml; moreover, as someone who's been exposed to languages with serious abtraction power, I easily get irritated by Java. The code was a true pain in the ass to work with: integration with OSGi was cumbersome, lots of black magic features were used gratuitously, the possibility to define stuff-which-look-like-methods-yet-aren't-in-the-class made quite a mess of code exploration, and of course tooling support was abysmally bad. I know the usual rebuttal: it's the bad developer's fault, not the language's. I don't buy this, a "good" language for which you can't find decent coders isn't any good. - Scala-like languages tend to attract guys who will mess with all the quirky features of the language; - In real life, developers are a given and the language is the adjustment variable, not the other way around. Most people don't have the luxury of only working with rockstars, and most of the cornerstones of the Internet haven't been developed by rockstars anyway. - The average developer will do an average job of writing maintainable Java, and an awful job of writing acceptable Scala, if only because there's no widespread consensus ov what it means for Scala code to be acceptable. Java is dull and uneventful, and I'd rather take over a syntactically dull and uneventful code base than an "interesting" one. - I've heared several times that "you can use Scala as a Java with closures". It's a variant of the argument that there's a 5 times smaller language hidden in C++ that's beautiful: nobody ever agreed over which 20% should be selected. The two languages which gave me the impression of trying to support every feature ever invented, and of making it very difficult for people to acquire and share a notion of standard, maintainable code are C++ and Scala. An iconic counter-example would be Python. More anecdotically, I spent a couple of days studying how Lift works, for personal curiosity. I found the code hard to navigate into. due to too many non-orthogonal ways of composing code together. A good tooling support would have helped, but if it doesn't exist after all those years, I might mean that there's something wrong with the language: it's not as if the need wasn't clearly perceived.

Nitramp 16y ago

This is what the Java designers always talk about: languages have a "complexity budget". You can choose to spend your complexity budget on different features (static typing, generics, closures, manual memory management, auto casts, overloaded operators, ...). Some features can take away complexity (GC). But once you've overdrawn your budget, the language gets creaky to use and everybody starts talking about "subsetting" the language. C.f. C++ - all those features do serve a purpose, and looking at the feature alone, it might be reasonable. I think Scala has way blown its complexity budget. They've innovated on too many different fronts. I'd been happy to have Java with closures, first class functions, and maybe better generics. There was a lot of buzz around DSLs at some point of time, and they decided to go all in with implicits, which I think was a bad idea. I guess they were trying to market the language...

jfager 16y ago
I don't understand what you mean when you say they went all-in on DSLs with implicits. I far more often use implicits for integrating Java libraries or papering over clunky apis than for putting together DSLs.
- Nycto 16y ago
  Just take a look at how specs [1] works: "Some element" should { "behave in some way" in { // ... } } According to this, the String type has a "should" method and an "in" method, but it really doesn't. Instead, there is an implicit conversion from a string to another type that actually has those methods. They idea here is to make the DSLs more fluent by removing the need to worry about complex type interactions while designing the interface. It lets the users use the pre-existing types they're already familiar with. [1] http://code.google.com/p/specs/ http://code.google.com/p/specs/
  - fizx 16y ago
    These DSLs in Scala can be awful. I mean: val ivySvn = "ivysvn" % "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Oh, but if you use a different maven convention, just double up the first percent sign: val ivySvn = "ivysvn" %% "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar" Readable, yes; intuitive, no.

dan00 16y ago

Scala seems to be the academic kitchen sink of programming languages.

plinkplonk 16y ago

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.

kokoloko 16y ago

In this same thread Martin Odersky announces he is working in a new version of the Scala plugin for Eclipse, to be released with Scala 2.9. A statically typed language really shines within an IDE.

cemerick 16y ago

The disaffection of ex-Java-devs towards these newer JVM languages is only really surprising if you were expecting any other language to overtake Java for Java developers. I used to think that would come to pass, but I've been convinced otherwise. By the time Java 8 comes around (don't expect Oracle to drag their heels on releases as prior regimes have), there will be little inherent reason for the typical Java developer to use Scala or Clojure. Only the biggest vendors (Oracle, Microsoft, IBM, et al.) have the firepower and perspective to produce/support whole-solution languages and ecosystems that go mainstream with tooling, training, and general-purpose facilities approachable for the vast middle. That is, the next Java is Java′. Of course, none of those typical devs are reading this or TFA. The real question is, which language is most applicable to particular problem domains and usable within particular organizations by atypical devs solving atypical problems? (Added bonus goes to the language that makes bidirectional interop with that vast middle of Java devs a piece of cake, for those atypical devs looking to provide libraries, tools, and products to be used by those Java devs.)

kumarshantanu 16y ago
Few points I can recollect (without answering "which language is most applicable...."): 1. Future of Java-the-language is limited by backward compatibility. This imposes a barrier on the scope of innovation in the language. 2. #1 can be helped by the newer JVM languages. 3. Current trend to increasingly adopt Ruby, Python or PHP for turnaround time is the result of a momentum and has to mean something. There is clearly demand for faster turnaround time in some segments. 4. The JVM languages that can reach feature parity with Ruby/Python/PHP ecosystem and tooling will have a better chance of adoption IMO. 5. The next Java is certainly not Java alone. Probably a mix of languages, depending upon which ones have a better VM, tooling, libraries, turnaround time etc.

timtadh 16y ago

I successfully used Scala as prototyping language for the first time recently. It was nice. I kinda liked it. But, I will have rewrite what I did in it soon because the VM startup cost for scala is too high for what I want to do. The lack of IDE support that the OP complained about didn't really bother me as I am more a vi/kate{+vi mode} kinda guy. That said, I could definitely see how really good IDE support would be nice to have when integrating with large Java libraries. EDIT: I forgot to mention the one thing that is nice about Java from a research perspective is it is a really easy language to work with. It's syntax is relatively easy to deal with, it doesn't have a preprocessor. Its semantics are straight forward. It has type annotations. There is a lot of code in it so you can test your research on real code bases. This makes Java the best language to conduct research on languages in. Even if it is not the best language to write it.

noidi 16y ago
Nailgun might help you with the startup time: http://martiansoftware.com/nailgun/ http://martiansoftware.com/nailgun/
- jbellis 16y ago
  (Last changelog entry: 2005.)
narrator 16y ago
JRebel is a must when doing Scala web development. It's not free but it definitely speeds up the development process as it eliminates almost all instances where one would have to restart the app server for code changes.
- heiflo 16y ago
  Actually, you can get a free JRebel license for Scala development: http://sales.zeroturnaround.com/ http://sales.zeroturnaround.com/
- owhite 16y ago
  Thanks, Heiflo, I was going to say the same thing!

nickik 16y ago

Thats the reason Clojure is so great. Its an simple language. The only complex things (if you get FP) are the macros and in the clojure world macros aren't used often. The Clojure Community learnd from the old lisp makro overuse. Everybody talks about not using makros if you don't really have to. Look at this talk by C.Grand: (not= DSL macros)http://clojure.blip.tv/file/4522250/ http://clojure.blip.tv/file/4522250/ If you really want to see what happens with your code just expand it. Its extremly transparent and easy (most IDEs should be able to to this). In a talk Simon Peyton-Jones once said something like: "Macros are like missile. You don't need them often but if you want to destroy a small village nothing can be better."

technomancy 16y ago
> "Macros are like missile. You don't need them often but if you want to destroy a small village nothing can be better." I'm partial to "Macros are like second amendment rights. You hope you never have to use them, but if you've got no other choice then you will be very glad you have them."

joshhart 16y ago

I program in Scala because it's my pseudocode. Filter this. Transform that. Collect these. I need an object that does such and such. I'd like some new functions on an object from another library. For the most part, Scala has an immediate, direct way to do whatever task I need in a type-safe manner. The type safety is important - it really does catch bugs and makes refactoring code a lot easier than in a dynamic language. This matters when the project is larger than 2 developers. Some others liken Scala to C++. I don't think Scala is as dangerous as C++ because of immutability and garbage collection, but I'll readily admit it's a complex language. You can write Scala as Java with some nice stuff (done at http://sna-projects.com/kafka/ http://sna-projects.com/kafka/, a distributed pub/sub messaging queue) or you can go full on with the Scala like Norbert (http://sna-projects.com/norbert/ http://sna-projects.com/norbert/), an RPC/cluster management system used for search and the social graph at LinkedIn. I don't think there's a problem with either.

brendano 16y ago

This exactly summarizes why I stopped using Scala. All I wanted was a cleaned up Java, but it's much more and riskier than that.

ehsanul 16y ago
Maybe you'd like Mirah? http://www.mirah.org/ http://www.mirah.org/

bad_user 16y ago

I get this sentiment a lot ... Secondly, it is the ultimate language to date for writing libraries and embedded DSL’s with static types. ... These abilities go way beyond any prior statically typed language. The author conveniently left out dynamic languages; but regardless of that, I don't like Scala because: 1) you can't override the method dispatching mechanism to make use of those types in interesting ways (e.g. multimethods are possible with DLR in .NET) 2) You can't get the syntax-tree of a block of code, then recompile it to something else (e.g. LINQ - and F# supports this as a general construct). There was a compiler-plugin at some point, but it's deprecated and incomplete and full of bugs 3) All OOP languages should have optional dynamic typing; OOP just doesn't blend with static types, being one reason why Haskell is not OOP (while providing other similar tools for polymorphism) What you do get in Scala is a flexible syntax, that can lead to awkward behavior (I often find myself asking whether some line needs a semicolon). And the type-system, while better than the one in Java, is also too complex, too verbose and definitely not elegant. You know what would be elegant? Being able to test if some object is an instance of List[String] (and yes, I know about manifests and implicit parameters: it's still an ugly hack that doesn't solve all problems). One could say that Scala is a pragmatic language, but so is C++; and C++ has no replacement, while Scala does have many.

mryall 16y ago

Groovy is good alternative JVM language if you just want some improvements on Java without a completely new language to learn. It addresses many of the small frustrations I have with Java (lack of list and map literals, lack of anonymous functions) without introducing many new paradigms or complexities. I'd recommend it to anyone wanting a quick prototyping language on the JVM.

Peaker 16y ago

I never understood why anyone would want a hybrid of OO and functional programming. I see OO as basically: Encapsulation, Inheritance and Polymorphism. Functional programming provides better facilities for encapsulation and polymorphism. Interface inheritance is pretty much a subset of implicit traits or type-classes. I don't think implementation inheritance is ever the right thing. So if you have the full power of FP (including existential types and type-classes), what is it in OO that you would yearn for?