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]> > > . > > > > 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.
