What is Scala?
This is yet another blog to demystify a technology. Scala is yet another experiment may/may not survive in the long run. I do see that there is some level of interest in this language. I was trying to find out what is it & what is not. More specifically, why it got the attention it deserves.
Ruby is Out. In comes Scala:
Twitter is using Scala now because it fell flat on the face with Ruby. (do a Google search if you want more explanation).
Ok, fine.
What is Scala?
It's Java!
What?
Yes, it gives you a different syntax but it compiles into Java byte-code (.class file) and runs on top of Java Virtual Machine.
Then, why can't I use Java itself?
I don't know. My head hurts if i start reading the list about Scala over Java. How can it be? Scala just produces Java class file. Sure, there may be some convenience factor in the syntax. There is no technical or business merit.
So, what is Scala? (technical-definition)
Scala = Object Oriented Programming + Functional Programming.
I don''t like it. This is like combining Ice Cream with Hot Coffee. If a technology/product combines 2 different discrete things then it has no merit. It's merely trying to justify it's existence.
Add to the confusion, i read about it's compatibility with C#. Good luck!
What is Scala one more time?
It's like driving to San Francisco from Sunnyvale. You can take Highway 101 or Highway 280. You have a choice but end result is same. It's SF!
Pl don't get me wrong- i may end up using Scala, sorry Java!
posted by Uday Subbarayan @ 6:55 AM
9 comments
9 Comments:
First of all, Ruby is not out. If you research the news about Twitter moving to Scala, you will find out that they have only migrated one component to Scala. Actually, they are currently actively hiring Ruby programmers.
Second, Scala is not Java. Don't mix up bytecode on the JVM with Java syntax. Saying that "There is no technical or business merit" in writing 2-5 times less code if the result is the same is akin to saying writing straight bytecode is the same as writing Java source, no?
Saying that combining paradigms has no merit is controversial, to put it mildly. Let me just say that most programming languages support many styles of programming.
Finally, it might be the same if you take highway 101 or 280, but it sure makes a difference if you use the car or walk.
I appreciate your comments and healthy debates are good for everyone in the industry.
Ruby is 99% out, the 1% is for the front end-spitting HTML to browsers. This is mostly because of their legacy. You may want to read here-
http://www.theregister.co.uk/2009/04/01/twitter_on_scala/
Java is a platform -like an airport. Initially it allowed only 'javac' compiled airplanes.Then it allowed many other(JRuby,Jython,Scala,etc) to land on it. So don't complain about the airport which you requested to land on it. Java is not just the syntax which you see, it's a complete platform. JVM forms the basis. Finally you are going to deploy your web app to Jetty or Tomcat or even WebLogic! (You just took a different route and no problem, if you find it convenient)
I repeat- combining OOP + FP has no merit. It adds confusion.
I think your coffee analogy is extremely telling...
There's a dessert called an affogato that is ice cream with hot coffee, or more precisely gelato with a hot espresso shot over it. It sounds a little odd at first, but it's actually quite good.
Thanks Erik. Let me try it :-)
If your line of argument is taken to its logical extreme then there was never any need to use anything but assembly - or maybe raw naked machine code. Why? Because whether you're using Java, Scala, Ruby, Haskell, or C++ end the end it's always machine code.
Your argument is commonly called the "Turing Tar Pit." It's the argument that since most programming languages are Turing complete it doesn't matter which one you use.
Yet somehow assembly is very, very rarely the tool of choice.
Programming languages provide a set of abstractions over and above the machine. Different languages support different abstractions well.
Let me give one example.
Algebraic data types and pattern matching are a fundamentally different way of approaching a problem than subclasses and method dispatch. The two have very different trade offs in terms of modularity and extensibility.
Java supports one well but to do the requires a lot of boilerplate, and so it is rarely chosen even in cases where it would make sense. Scala allows either approach to be expressed reasonably succinctly so they quickly choose one or the other (or some combination of both) as appropriate for the problem at hand.
That's just one example and it doesn't go into the differences in the type system, where Scala lets me say things in a type safe fashion that are impossible to express in Java without type casts.
So, if a language is the same as what it compiles down to (Scala must be the same as Java because they both compile down to JVM byte-code), that would mean that C is the same as x86 assembly language. Guess we can all throw out of C compilers. And I guess C++ is the same as C and the same as x86 assembly language because C++ was originally implemented as a C pre-processor... so we throw C++ out the window too. Wait... wait... the JVM's JIT compiles byte-code down to machine code, so that must mean that Java and Scala are both the same as machine code, so we should get rid of those languages too.
So, Uday, you've made a compelling argument for me to throw away all the tools I've been using since I hand-coded 6800 machine code back in 1976.
Or, maybe, each language above adds a layer of power on top of the language it supersedes. C is richer and more powerful than assembler. C++ is richer and more powerful than C. Scala is richer and more powerful than Java. My Scala code is typically 4x-10x more compact than my Java code. I can express more with Scala than I can with Java. That makes me more productive and it means that people who maintain my code wade through less boilerplate to get to the intent of the given method.
James & David: I appreciate your passion for Scala and also support the fwd-looking dev. community. There is no question about the need for different languages/frameworks for different problems.
I am not against any languages/frameworks(including Scala). I choose right frameworks for right problems. Also, I am not wedded to Java/any other languages.
But this Java vs Scala comparison throws me out- especially when Scala itself runs on top of java-virtual-machine and then says it's better than Java! Sure, like any other language Java has its own problem. No disagreement.
This Scala complaining about Java is like, renting an office in Empire State building and then complaining about the building itself. If you don't like Empire State building, rent a different building better yet build something your own from the ground. Just because JVM is open & friendly, doesn't mean that you sit on top of it & keep complaining about it.
Current Scala is like a patch-work, trying to fix some Java syntax problem. (David clearly explained about the shrinking of code and is good thing) This is why I said, I may even use it if there is a business case for it. It just going to run on Jetty or Tomcat containers.
Pl count me in when someone is out-to-design SVM(Scala Virtual Machine) for 2nd generation web. We can truly build a new web platform.
Cheers!
The problems with Java that Scala addresses are not merely syntactic; there are a whole host of constructs that simply cannot be expressed in the Java language as it currently exists. Declaration site type variances and higher-kinded types are two obvious shortcomings, and obviously the ability to do destructuring during pattern matching would be so hideously verbose in Java that it sort of doesn't count as being possible.
The JVM has millions of man-hours of work into it; what facilities does it not provide that you think a hypothetical Scala VM should be able to take advantage of?
@Kris: You answered your own question. "Millions of man-hours" are not just spend on design/development of JVM but on the complete Java ecosystem. (JVM, core J2SE libraries, J2EE,etc)
Question: Is it "that" hard to add the few things you mentioned in the next version of Java language itself?
What is it preventing from adding it?
I don't know the answer. You tell me.
Cheers!
Post a Comment
<< Home