11–20 of 57 posts
This is really, Scala (and any of those extra JVM languages) considered a harmful addition for large java projects which makes a lot a sense. It surprises me a bit that it needs to be said, and said in such fashion.
The obvious comeback being large Java projects considered harmful.
The author has a set of views about the benefits of hobbling programmers on large projects, which he takes as axiomatic. He espouses Java as a language suitable for performing said hobbling. He convincingly argues that permitting programmers to add Scala code to large Java projects undoes the hobbling provided by the Java language.
I can't argue with his conclusions, but I'll fight his premises to the death.
By his argument, Ruby is really bad for large-scale projects, due to its "language flexibility". (Lisp is just as bad, and Python not much better.) All I can say is that this hasn't been my experience. It's not just that Rails makes good use of Ruby to define and use several internal DSLs (for validations, associations, etc.), or that many plugins do the same for other purposes (HAML for markup). The large rails app…
My experience is that inexpressive or hobbling languages encourage good programmers to make a mess as well! To give an absurd example, I remember working with a dialect of BASIC that did not support recursion (this would have been the 1970s). To write a "Towers of Hanoi" solver, I had to greenspun my own procedure argument stack. While this is a useful learning exercise, greenspunning your own language features in an inexpressive language inevitably leads to half-baked implementations.
And that is what I see with modern Java: lots and lots of things greenspun on top of the language in half-baked ways. There is just as much functionality code in a complex Java application as there is in a complex Scala application, but in the Java application the domain-specific code sits on top of a rickety tower of awkward implementations and work-arounds.
I think I can do better than that.
"I am just saying for a large project you shouldn't willy-nilly do X". You fill in the X.
The "willy nilly" weasel word takes care of all possibilities and prevents counter argument. What a dumb blog post (and argument).
> Ultimately, a programming language that's useful for large-scale programming projects needs to have clear, unambiguous grammar and syntax so that any developer familiar with the project and the language can instantly figure out what's going on.
Wow. There are just so many things wrong with this statement. Let me enumerate them:
1. Scala does have a clear, unambiguous grammar. If it didn't there wouldn't be a Scala compiler. I think what the author means to say is that languages need to have less flexible grammars (like Java does).
2. Just because you can use all kinds of wild things to obscure your code doesn't mean you should. If you prefer the "boring" way of doing something, then go for it. You just have to understand that just like anything else in programming, it's about tradeoffs. Does the benefit gained from using a DSL or operator overloading outweigh the costs? Sometimes it does, sometimes it doesn't.
3. The idea that a programmer (even one who's familiar with a project) can look at any given piece of code and instantly understand what's going on is a myth. Even if that snippet of code makes perfect sense, you also need to understand the state the program is in before that piece of code executes. Again, it's about tradeoffs. You need to choose the method that allows programmers to understand code more quickly. Sometimes using metaprogramming is the way to do that.
I will grant the author that there are valid reasons not to choose Scala, but I don't think he's hit them.
Neither Geir nor I consider Scala inherently harmful to a large-scale programming project.
I would argue here that adding any language to an existing project would have at least some of the drawbacks that the author mentioned (developers not familiar with the language, added complexity...).
That's heartening to me. C++ is a great language for people who 1) know the language, and 2) use it sensibly (which often means humbly.) There's all kinds of stuff you can do with C++, including metaprogramming magic that gives you DSL-like capabilities a la Boost Spirit.
I can't imagine using Boost Spirit in production code myself. Maybe there's a good use for it somewhere -- probably so -- but I really don't care if Boost Spirit is every a good idea anywhere. Maybe it's just an abomination; I don't care! All I care about is that I can make a good judgment about allowing it into my codebase.
I'm going to approach Scala with the same attitude.
I really disagree with the author in terms of metaprogramming. One thing in particular jumps out at me: > Ultimately, a programming language that's useful for large-scale programming projects needs to have clear, unambiguous grammar and syntax so that any developer familiar with the project and the language can instantly figure out what's going on. Wow. There are just so many things wrong with this statement. Let me…
What you want to avoid is invisible side-effects. Aspects for instance have their place, but if someone has tried to be too clever for their own good the program may be breaking in a way that is completely invisible when you look at the code.
"Ultimately, a programming language that's useful for large-scale programming projects needs to have clear, unambiguous grammar and syntax so that any developer familiar with the project and the language can instantly figure out what's going on." I have a hard time swallowing the necessity to rely on restricting the expressive power of the language to prevent people from creating code that is hard to understand. My c…
Well, take a look at this sample ( http://dispatch.databinder.net/Common_Tasks ) and see if you can figure out what all those operators do just by looking at them :) Thats the kind of abuse possible with languages such as Scala, Haskell or c++ templates.
That's the kind of abuse possible with languages such as Java.
---
Seriously. Every new API that you intend to use has a learning curve, some more significant than others. Every new API is a new "language".