A brief aside here to explain how Scala works. `val prop1 : Int` would translated to a field `final int prop` plus the method `int prop()` `var prop2 : Int` would translated to a field `int prop2` plus methods `int prop2()` and `void prop2-_=(int newval)` this is why `def prop` can be overridden in a subclass with `val prop`
a function/closure gets translated into an apply method on an anonymous instance of `Function1`, `Function2`, etc. as appropriate methods get adapted to functions as needed This is exactly the same way that you'd have to do it explicitly in google-collections Pattern matching is a bit trickier, but in most cases the bytecode can still be successfully decompiled to Java code via jad etc. a singleton object `MyObj` compiles to a class named `MyObj$`, with a static member MODULE$ that holds the single instance. (also, static methods will also be generated on MyObj that forward to MyObj$.MODULE$ - this is done purely for the benefit of Java callers) This underpins the idea of companions - where a class and object have the same name. Behind the scenes, they're compiled to differently named classes The type system, one of Scala's crowning glories, gets erased - just as Java's does. So there's not much point making a comparison. There are articles online that explain how scala compiles to bytecode in far more depth I just did. Like this one: http://iamchrislewis.tumblr.com/post/239967776/a-look-at-how-scala-compiles-to-java So while the JVM is aware of objects (not functions) as first-class constructs, Scala is able to work around that constraint my making objects that *are* functions. It's a pretty useful thing to do in an object-functional hybrid language where everything is an object anyway... Scala has also benefited from type erasure. Adding a more advanced/powerful/flexible type system would have been *much* harder if types were already reified in the JVM On 8 August 2010 00:37, Alexey <[email protected]> wrote: > On Aug 7, 2:21 pm, Kevin Wright <[email protected]> wrote: > > On 7 August 2010 18:19, Alexey <[email protected]> wrote: > > > > > Something about the recent (not just this particular discussion) > > > debates about Scala and Java has been bothering me. Something isn't > > > sitting right. I think I may have figured it out. Scala is being > > > advertised as a functional language. That's all fine and good, except > > > one can't really compare it to languages like Erlang. Why? Because > > > the real functional benefits Erlang is famous for do not extend to > > > Scala, as far as I know. I may be wrong here, but given the fact that > > > Scala compiles into standard JVM bytecode and interoperates with > > > normal Java API (bidirectionally) tells me that even though one > > > programs in Scala in a functional manner, it's actually run the same > > > way as any other bytecode-based software on the JVM -- imperatively. > > > > Haskel, Erlang, Java, etc. all run the the same hardware. > > So why do you feel that a virtual machine would force a language to be > > imperative whereas a physical machine wouldn't? > > What's at issue here is that Erlang gets to run in its own > environment, where things like hot-deployment of modules and > parallelism is baked in from the get-go. I'm not familiar enough with > Erlang, but that is the impression I got from some of those cute '70's > demos I'm sure many of us have seen. Scala, on the other hand, gets > compiled to bytecode that's run on a standard JVM with high degree of > interoperability with Java and other bytecode-based libraries. In my > mind, this presents a limitation as to how much of those Erlang-like > features Scala can implement. This isn't language stuff. This is > implementation, runtime stuff. Yes, there are libraries available for > the JVM that try to achieve this, but they step outside your given > language (in fact they are language agnostic, aren't they, so long as > you can call bytecode API, yes?). In a sense then, both Java and > Scala programmers have to step outside their language's native > constructs and talk to these libraries their way in order to achieve > these runtime benefits. > > > For that matter, what does it even mean to "run imperatively"? > > Imperative and declarative are just different conceptual styles for > thinking > > about programming problems. > > Admittedly, most languages will tend to encourage one style over the > other, > > and will offer constructs and syntax support for that. > > Some languages will even make a particular style almost impossible > > (Okay, I guess you *could* write an entire imperative program using state > > Monads in Haskel, but why on earth would you?) > > > > Object-Oriented is no different. You can write OO in C by putting > function > > pointers in structs and calling them objects. > > It may not be elegant, but it works, and it's the basis for programming > > against Microsoft's COM. > > And Perl's OO. > > > This is analogous to taking an SAM interface in Java and calling it a > > function, you can even call it "Function" if you wish; Google does: > http://google-collections.googlecode.com/svn/trunk/javadoc/com/google... > > > > A functional language is therefore one with constructs allowing you to > treat > > functions as first class values. > > > > and yes, Scala *is* Functional: > http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-t... > > Then touting Scala's functional attributes is primarily about syntax. > There's nothing particularly wrong with that, but if one were to > compare Java to Scala, we then have to compare functional style > expressed in Java (perhaps using a variety of approaches, since there > is no single standard way as of yet) to Scala's, and then maybe > imperative style expressed in both languages as well. If it's not the > FP itself that solves problems, but rather the style that may adhere > better to some problems, then we should be ready to say: Scala's > functional style is better for solving X than Java's functional style; > as opposed to saying, "Look how elegant this functional bit is written > in Scala and look how ugly this imperative/OO style is in Java doing > the same thing!" > > > Just like we have to be careful about distinguishing between Java-the- > > > > > language and Java-the-virtual-machine, we need to understand the > > > reality of what "functional" means when it relates to Scala. I have > > > yet to see easy parallelism solutions coming from Scala out of the > > > box. Yes, we get to use lambda-oriented syntax and an arguably better > > > type system, but we're not really talking about a total shift in > > > thinking. > > > > I believe you mentioned Erlang earlier. A language widely praised for > > having actors, which help massively with concurrency. > > > > Scala has Actors - in fact, it was inspired by erlang > > > > All grant you that actors don't actually *need* functional programming > > (http://doc.akkasource.org/typed-actors-java) > > But it helps... > > There you go. Let's compare actor use in Java and Scala. I'm sure > Scala's way is cleaner, but I haven't tried this myself yet. > > > > Some people have already mentioned how familiarity with > > > Scala made them better Java programmers as they were able to bring > > > some of the good concepts/patterns into their Java code. It's > > > possible to program in a kind-of sort-of functional style in Java. > > > Plain and simple. And rightfully people say that doesn't make it a > > > real functional language. > > > > There's a saying: "cameras don't take photographs, people do" > > The same goes for FP. It's ultimately a paradigm, a style of thinking. > > The choice of language just affects how easy (or hard) that paradigm will > be > > to use. > > That means if we get too far into this argument (what's more complex? > which is the true functional language?), we run the risk of arguing > semantics, completely divorced from reality. If a person finds a way > to program functionally in Java, does that make Java a functional > language? Or is that we should focus more on how code is executed and > optimized at runtime and which style people employ to express their > algorithms in, rather than attributing these monikers to languages. > Maybe it's not that one language is FP and the other is OOP. Maybe > it's more about what people end up writing in it. And it's not just > about features. If there are some insanely complex type system > features in Scala (I'm just shooting from the hip here, not from > firsthand experience) and only 5% of people know how to author API > with them, and maybe 30% understand how to consume those API, then > what good is it? And how do you measure this kind of complexity at a > stage, where we still don't fully know how wide the audience for the > language is going to end up being? > > > Just look at joda-time, and google-collections, both are very obviously > > written in an FP style. > > Right, and as I mentioned above, we can use them in Java without > turning Java into a FP language. Or can we? Does it even matter? > I'd much rather talk about programming style than language style at > this point. To me, the JVM is the platform and can be the basis for > different languages to interoperate and allow one piece to be written > in one style and then another piece in another style -- whatever suits > the specific problem at hand. If we can come to that point with > relatively seamless integration of libraries and modules written in > different languages, that's just perfect. Then we don't need to argue > which language is better overall. We can just pick and choose; > literally the right tool for the job. > > > > Scala seems nice and I want to invest time > > > into it for my own personal betterment and maybe use it in the "real > > > world" as I better understand its strengths, but it's not a functional > > > language. At best, it's a functional mask on top of the same old > > > imperative bytecode-driven VM with the same old runtime advantages and > > > hiccups we've come to expect from Java code. At worst, it's a bunch > > > of performance sacrifice in order to achieve the above. > > > > End of the day, any language you care to name will be running on von > Neumann > > architecture (http://en.wikipedia.org/wiki/Von_Neumann_architecture) > once > > you get down to "the metal" > > Far from being a sacrifice, Scala chose the JVM in part because it was > > so performant, and heavily optimised. > > I would agree in general. But a part of me wonders if a virtual > machine that is geared specifically to FP style of code and API would > be better at optimizing FP-styled managed code. > > > > I fully admit that as a longtime Java developer, having achieved a > > > good level of proficiency, I can be intellectually lazy when > > > considering becoming a near-total newbie with a new language. But > > > that's not everything. I also am cautious about mixing up buzzwords > > > with facts and getting swept up in emotionally charged debates over > > > technology. On the one hand, emotions are important because sometimes > > > they are symptoms of real arguments we're not yet able to articulate > > > properly. On the other hand, there's evidence that sometimes people > > > are less than forthright when evangelizing technology (the recent Go! > > > article seems like a prime example of this). Complexity of a language > > > seems like a pretty tough thing to try to quantify. The best I could > > > do I think is to provide real-world examples like Dick's. Then people > > > can debate how well those examples fit their circumstances and whether > > > the way they were solves was indeed the simplest/fastest/best/whatever > > > way. Otherwise, we're just kind of pissing in the wind, if you pardon > > > the expression. > > > > I empathise 100%, examples are vital! > > > > So... there's an interesting discussion here: > http://scala-programming-language.1934581.n4.nabble.com/LOC-ratios-wr... > > about a small Java->Scala conversion. (it goes over 2 pages) > > > > The original Java is here: > http://github.com/cageface/brains/blob/0ee0bfce5bda549e7a3f778ba6a6ef... > > and the Scala here: > http://github.com/cageface/brains/blob/b93cacb3944c8af7a8aebfedebed31... > > > > Judge for yourself which seems simpler :) > > Looked at the examples. Haven't had a chance to read the discussion > yet. To me, the Java snippet is completely subpar. It's simply not a > good example. Consider the following: > > Java: > String line = null; > while ((line = movieFile.readLine()) != null) { > String[] parts = line.split(SEPARATOR); > movies.put(new Integer(parts[0]), parts[1]); > } > > > Scala: > val movies = movieFile.getLines.map { line => > val id :: title :: rest = line.split(SEPARATOR).toList > id.toInt -> title > }.toMap > > At first glance, one can clearly see that Scala is much more readable > and expressive of the intent. But look at the Java code carefully. > Much of the denseness of thought here comes from this line: > movies.put(new Integer(parts[0]), parts[1]); > Would it not be clearer if we did something similar to what's in > Scala: > String id = parts[0]; > String title = parts[1]; > movies.put(new Integer(id), title); > All of a sudden, the whole thing is a lot easier to read. I'm not > saying this was done on purpose, but I do think the two versions were > written by different people, likely at different times. This is > interesting to look at, but I can't take this as a fare contrast of > languages at face value. > > > > > > On Aug 6, 6:07 pm, Kevin Wright <[email protected]> wrote: > > > > You can't claim that the numbers I posted are subjective, I counted > > > > them fair and square! > > > > *this* post however, will be subjective. > > > > > > The idea that all kids go to "high school" and have a "grade 11" is > > > > also subjective :) > > > > I give you... Kojo!http://netbeans.dzone.com/learn-scala-with-kojo > > > > > > It's also subjective to simply discredit any methodology that happens > > > > to disagree with your gut feelings. > > > > > > Incidentally, the "few object-oriented features" in Scala amount to a > > > > more complete/purer OO language than the entirety of Java. > > > > i.e. > > > > all values are objects (no primitives) > > > > all members are defined on an *instance* of some class, and are > > > > capable of inheritance/overriding (no statics) > > > > > > The way I see it is that Scala = Java > > > > - the non-OO bits > > > > - other boilerplate > > > > - frustrating restrictions > > > > + FP > > > > + a world class type system > > > > > > and yes, that's subjective. At least until someone comes up with > > > > measurable criteria for "frustrating restrictions" :) > > > > > > On 06/08/2010, ADRA <[email protected]> wrote: > > > > > > > This whole topic is by its nature subjective. Its not like Scala > and > > > > > Java are exact language fits for one another. As I see it, Scala is > a > > > > > functional language that has some object oriented features. Java is > an > > > > > object oriented language with a few procedural features (baggage) > and > > > > > will eventually have a few functional features. If you want to ask > > > > > which one is easier, ask yourself if you like Wrox or Head start > > > > > books. Each book conveys the information to you in the end, but > each > > > > > person reading them will have wildly different takes on each style > of > > > > > presenting the content. > > > > > > > If you really want a quantifiable result, then get a pilot program > > > > > with two high school grade 11 classes and teach one class Java and > the > > > > > other Scala. Personally, I find Java vastly simpler understand and > use > > > > > vs Scala, but I come from a solid procedural foundation long before > I > > > > > touched java. To forget the educational background of the person in > > > > > question is a horrible mistake to make in this topic. > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "The Java Posse" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<javaposse%[email protected]> > <javaposse%[email protected]<javaposse%[email protected]> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/javaposse?hl=en. > > > > > > -- > > > > Kevin Wright > > > > > > mail/google talk: [email protected] > > > > wave: [email protected] > > > > skype: kev.lee.wright > > > > twitter: @thecoda > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%[email protected]> > <javaposse%[email protected]<javaposse%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > Kevin Wright > > > > mail/google talk: [email protected] > > wave: [email protected] > > skype: kev.lee.wright > > twitter: @thecoda > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
