8 ms·
Scala is actually a better Ruby. All the messy fun stuff that we all love with Ruby like duck typing and monkey patching can be done easily with Scala, except
by narrator 16y ago
Scala is actually a better Ruby. All the messy fun stuff that we all love with Ruby like duck typing and monkey patching can be done easily with Scala, except it's all statically typed so it keeps the whole mess under control.
For instance, you can have a duck type as a function argument that's contract is it implements a particular method signature. In Ruby there is no type type enforcement so you can get runtime errors when you pass in an object that doesn't have the right method, while in Scala the compiler catches it.
You can monkey patch by doing implicit conversions in Scala to a rich type, allowing one to add methods to the Integer class, for example, but if you have to libraries that do the same monkey patch Scala will alert you to ambiguous situations. In Ruby this depends on load order and can cause all kinds of screwy bugs.
- cageface 16y agoScala is brilliant in a way in that it hides all the incredible complexity you incur when you try to statically type a programming style evolved in dynamic languages. That is, it hides it to a point. It's easy enough to get started writing simple scripts and sprucing up old Java code but before long you get a compiler error that sends you scurrying away to the reference books and then it hits you that you really are going to have to come to grips with the type system and it's a doozy. I'm still not persuaded that all the gymnastics Scala has to do to allow Ruby-like flexibility really result in a more productive language overall. I need to spend more time with it to be sure but at first blush it really feels like the faustian bargain Scala has had to strike to merge expressive, Ruby-like syntax with strong, static type-checking and java compatibility has resulted in a language too complex for most working programmers. Clojure seems a lot more elegant and comprehensible.
- narrator 16y agoWhen I get a compiler error in Scala it's almost always something that would cause a runtime error in a non statically typed language. The downside is that the error messages can be difficult to parse and resolve for beginners. Once I got over the learning curve, I realized that in almost all cases the compiler was trying to tell me something very useful. I do get a little annoyed at all the Haskell/OCaml type nerds trying to do things with the type system that are not particularly practical, for instance: http://apocalisp.wordpress.com/2010/06/16/type-level-programming-in-scala-part-4a-peano-number-basics/ http://apocalisp.wordpress.com/2010/06/16/type-level-program...
- kscaldef 16y agoIt's not really any different from C++ nerds doing the same with the template system.
- viraptor 16y agoAnnoyed? These are just fun things to do. Just like Quines. Of course anyone trying to introduce type-level computations into production code should be shot on sight (unless you're using a language where type-level "computations" are somehow expected... like Haskell), but that doesn't mean we shouldn't do it just for amusement. Just as the linked article ends: "Match is the only operation that we need for HLists. We’ll continue by defining comparisons, addition, multiplication, modulus, and exponentiation just for fun anyway."
- sreque 16y agoI agree that Scala will never be a good replacement for languages Ruby both because of its complexity and the fact that dynamic languages are always going to be more flexible than statically typed languages. The fact that majority of new languages are in fact dynamic ones is also a good indication of the inherent difficulty in designing a good statically typed language. Scala is a much grander project in scope than Clojure, Ruby, Python, Groovy, or pretty much any of the dynamic languages sprouting up on the JVM probably ever will be. For instance, because these languges are dynamic, they don't care to deal directly with things like the cost of autoboxing, the price of type erasure, the ugly hackery that is java arrays, and so on. Life is simple when everything is of type Object! Of course, this grander scope comes with a cost, and that cost is language complexity. In my opinion, Scala's aim is to take on Java by providing a much more overall productive language than Java while still maintaining Java's performance. I feel it's very much akin to the goals of C++ versus C. Fortunately, the people behind Scala are well versed in PL theory and make sensible language design decisions, so at this point Scala is in little danger of someone writing an FQA on it any time soon.
- vorg 16y agoA language can be both static and dynamic. C# introduced the 'dynamic' keyword, and perhaps they'll go further with that idea in the next version. The Java 7 JVM will have the 'invokedynamic' instruction, plus a new Java API to manage it. Perhaps Scala will extend the language syntax at that time to allow dynamic typing, with that API underneath, for those few cases where dynamic typing's better. A language that was dynamic first, then added the static, is Groovy and Groovy++.
- gfodor 16y agoSorry, but this comment is pretty misinformed. Clojure has numerous facilities to address the performance issues you mentioned. You can, for example, annotate parameters to a function with type information to use primitives, java arrays, and remove the need for reflection. Additionally, JRuby has had a JIT that attempts to do smart things to avoid unnecessary boxing and reflection. They've been rather impeded by the JVM on this front, but JVM 7 looks to open a lot of doors for the JRuby team to remove a lot of unnecessary dynamic dispatch in the execution of Ruby code. The problem I see with Scala is it reeks of Perl 6's "everything and the kitchen sink" language feature-a-thon. Having learned Clojure and started Scala recently I'm constantly asking myself why Scala code has so much incidental complexity compared to the equivalent Clojure code. Often, it is due to the type system or the excessive number of constructs and syntax available in the language.