I also would like to point out that the Java vs Scala debate is quite pointless.
Scala is Java. It runs on a JVM, the language itself is coded with Java and you can even directly use Java object inside a Scala program. Opposing Scala to Java is a bit like opposing Java to C. Last time I check, the JVM is coded in C and if you need to do something very low level, you'll use JNDI and you'll write C code. And with Scala, this is the same. Do you see people comparing C to Java ? No ! Java to C++, perhaps, but here again the scope of C++ does match the one of Java... C# versus Java, or Python vers Java, OK, but Scala versus Java seems to be pointless. A debates on what Scala *brings* to Java is (I agree) far more relevant... On 27 August 2010 17:19, Alexey Zinger <[email protected]> wrote: > Those are very noble goals, but I think there's a much easier way to > promote Scala on the basis of its functional programming merits to Java > programmers. Simply isolate a few examples of Java expressing functional > style (easy to find with event-driven stuff), admit that it works, and then > show comparable code in Scala that appears more expressive of the intent. > Now the Java people are looking at another language to learn that might have > some nice in-roads for certain applications or circumstances. To close the > deal, showcase Java-Scala API interoperability and address performance. > That's all you need. If people take up the language in a way that they > eventually transition to it fully, fine, if not, fine too. But hearing > "Scala is for smart people, Java is for everyone else" or "if you're good > enough, you should move to Scala and abandon all your previous work" or > whatever else is simply a turn-off. > > Alexey > > > ------------------------------ > *From:* Kevin Wright <[email protected]> > *To:* [email protected] > *Sent:* Fri, August 27, 2010 4:22:07 AM > *Subject:* Re: [The Java Posse] Re: So Scala is too Complex? > > I'm going to take a tangent here, and open state my reasons for defending > Scala so strongly: > > 1. The majority of Java programmers haven't even heard of Scala, let alone > looked at it. Hopefully a heated debate will encourage people to think > "What's all this fuss about..." > > 2. To break the preconceptions that FP = academic, FP = hard (usually via > FP=unfamiliar, unfamiliar=hard), etc. > > 3. To demonstrate to people who think they can't deal with hard stuff that, > actually, wee all do so in Java, every day. It's so depressing to hear > someone say "but it's too difficult, I'm not good enough". Total nonsense, > of course you're good enough! > > 4. To point out that many quoted examples of FP being difficult are > actually examples of mutability and side effects being difficult, it's a > refreshing paradigm shift! > > 5. To drag a lot of smart talented programmers into the beautiful world of > FP, kicking and screaming if necessary :) > I wouldn't expect world-class programmers to use inferior tools and > techniques, any more than I'd expect an orchestra to be using violins from > wall-mart > > > > On 27 August 2010 09:02, Reinier Zwitserloot <[email protected]> wrote: > >> Ah, yes, we've come full circle. Scala fan defends poor language >> design choice by saying that it wouldn't have happened if you >> programmed purely functional. >> >> Newsflash, Kevin: If you want to stick to pure programming, there are >> far better languages than scala out there, such as Haskell or Clojure. >> Scala is in my opinion a lot more realistic for a large array of >> projects exactly because it gives you decent support for non-pure >> programming where its needed. >> >> For example, in this partition example, a pure version could have >> _EASILY_ been written using conslists, but I'm guessing partition uses >> a listbuilder instead because its significantly faster. >> >> On Aug 26, 11:23 pm, Kevin Wright <[email protected]> wrote: >> > Scala generally tries to "do the right thing" >> > It's a nebulous concept, of course, but it usually means "do what Java >> does" >> > Unless there's a good reason to state that what Java does is just plain >> > wrong, or that it's seriously inconsistent with other goals of Scala >> > >> > This particular example is interesting, insofar as it meets both >> criteria :) >> > >> > Within functional programming, it's generally accepted that functions >> should >> > be pure. i.e. that they should always return the same result if given >> the >> > same input. If nothing else, it does wonders for unit testing! >> > >> > Constructors, OTOH, are about as far away as you can get from functional >> > purity >> > >> > Therein lies the rub! In order to accept the majority of Java syntax, >> it's >> > also necessary to sacrifice functional purity, and therefore the >> elegance >> > and simple reasoning that are natural consequences of the ideal >> > >> > So yes, the following is potentially confusing: >> > >> > val left, right = newBuilder >> > >> > But.. the confusion is perhaps based not so much in the concepts behind >> FP, >> > as it is in the inherent complexity of methods with side effects >> (including >> > constructors). If `newBuilder` was a pure function, then it really >> wouldn't >> > matter if `left` and `right` were assigned the same value, or the result >> of >> > two subsequent evocations of `newBuilder` >> > >> > As is so often the case, the root cause of any possible misunderstanding >> > here can be traced back to imperative code, and to mutability >> > >> > On 26 August 2010 21:48, Reinier Zwitserloot <[email protected]> >> wrote: >> > >> > >> > >> > > Right, this is possible the worst one of all in partition. This must >> > > mean that, translitering to java which we're all presumable a little >> > > more familiar with, that: >> > >> > > List<String> left, right = new ArrayList<String>(); >> > >> > > results in 2 separate calls to the ArrayList constructor? >> > >> > > Also, another WTF that came to me later, showing that even this tiny >> > > snippet is not trivial to understand: Am I to assume that "a += b", >> > > where a is a list builder, does not reassign a at all, but is instead >> > > syntax sugar for a.add(b)? The suggestion that in modern scala, :+= is >> > > used is really not an excuse for this bad choice of operator >> > > overloading. The = surely suggests a will get reassigned here, when >> > > that doesn't happen. >> > >> > > It's either that, or newBuilder just returns nil, and this is a >> > > conslist. In which case the terminology "newBuilder" is very strange. >> > >> > > partition is just bad code. >> > >> > > On Aug 26, 3:48 pm, Viktor Klang <[email protected]> wrote: >> > > > On Thu, Aug 26, 2010 at 3:10 PM, Reinier Zwitserloot < >> [email protected] >> > > >wrote: >> > >> > > > > So, val l, r = newBuilder works because newBuilder is a method, >> and >> > > > > this method returns a tuple? >> > >> > > > No, that was just misinformation, it is assignment. >> > >> > > > scala> val l,r = 5 >> > > > l: Int = 5 >> > > > r: Int = 5 >> > >> > > > scala> l >> > > > res0: Int = 5 >> > >> > > > scala> r >> > > > res1: Int = 5 >> > >> > > > > Good lord. I rest my case! >> > >> > > > I am glad that there are people like you, who are embracing Java as >> a >> > > > language to it's full extent. >> > >> > > > > On Aug 26, 10:03 am, Russel Winder <[email protected]> wrote: >> > > > > > On Wed, 2010-08-25 at 15:56 -0700, Reinier Zwitserloot wrote: >> > >> > > > > > [ . . . ] >> > >> > > > > > > that this code works). If this is how scala ends up with >> shorter >> > > code, >> > > > > > > I don't want it. >> > >> > > > > > Tuple assignment works brilliantly in Python and seems to in >> Scala as >> > > > > > well. Tuple assignment solves so many problems that lead to >> clumsy, >> > > > > > often unreadable and incomprehensible code in those languages >> that do >> > > > > > not support it. You may not want it, but I do. >> > >> > > > > > > > (if p(x) left else right) += x; >> > >> > > > > > > In java there's a more or less long-standing hatred of using >> > > > > > > assignments, which are legally expressions, as anything but a >> > > > > > > statement. i.e. folks frown on this kind of thing: int x = 5 + >> y = >> > > 10; >> > > > > > > even though it is technically legit java code. This feels >> similar, >> > > > > > > using the result of an if expression as the target of an >> > > assignment. >> > > > > > > For example, while its a few characters longer, I find this >> much >> > > more >> > > > > > > readable: >> > >> > > > > > > if (p(x)) l += x; >> > > > > > > else r += x; >> > >> > > > > > You may do so but I do not, I think it looks truly archaic. >> And >> > > where >> > > > > > has this "hatred of using assignments. . .[as expressions]" in >> Java >> > > come >> > > > > > from, I don't see it, exactly the opposite, there is an >> increasing >> > > use >> > > > > > of expression-based and value-based working. >> > >> > > > > > > Using ifs as expression is a nice gimmick that tends to lead, >> IMO, >> > > to >> > > > > > > hard to read code. Just like assignment-as-expression. Yet >> again, a >> > >> > > > > > Exactly, in your opinion. In my opinion you are looking back >> fondly >> > > to >> > > > > > the days of assembly language programming. There is a crucial >> > > > > > difference between simplicity of expression and expressivity. >> > > > > > Simplicity of expression is important for readability -- there >> are >> > > > > > experiments happening to show this, it's not research by >> expounding >> > > > > > opinion. Similarly there is experimentation to show that having >> the >> > > > > > simple expression express high-level algorithmic things rather >> than >> > > > > > low-level algorithmic things leads to faster code writing and >> easier >> > > > > > maintainability. Again there is experiment, this is not just >> > > attempting >> > > > > > to create facts by writing opinion often enough that people >> think >> > > it's >> > > > > > fact. The keywords to search for are "psychology of >> programming", >> > > > > > "program comprehension", etc., etc. >> > >> > > > > > [ . . . ] >> > >> > > > > > > characters compared to .add(x). Big whoop. This is EXACTLY why >> some >> > > > > > > people think operator overloading causes more trouble than its >> > > worth. >> > > > > > > For the third time in a row: If this is how scala leads to >> shorter >> > > > > > > code, count me out. >> > >> > > > > > "Some people think": so this could be a very small minority. >> Just >> > > > > > because Java eschewed operator overloading doesn't make it >> right. >> > >> > > > > > OK so after a count of three you are counted out. Fine. Let >> the >> > > rest >> > > > > > of us move on and become better programmers by using more modern >> and >> > > > > > appropriate techniques than you think is good for us. >> > >> > > > > > [ . . . ] >> > >> > > > > > > go. i.e. Martin Odersky is in love with code golfing, and >> equating >> > > > > > > code golfing to elegant language design seems misguided to me. >> > >> > > > > > Presenting you opinion as though it were fact or even the >> majority >> > > > > > opinion seems misguided to me. As is attributing opinions to >> other >> > > > > > people. >> > >> > > > > > > Conclusion: Scala will never be the next big thing, because >> along >> > > with >> > > > > > > the nice syntactical cleanups, it's falling into the academia >> trap: >> > >> > > > > > So academic is now a synonym for bad. This is what really riles >> me >> > > up, >> > > > > > the implicit view that a language that comes out of academic is >> of >> > > less >> > > > > > value than a language developed in a company. >> > >> > > > > > Programming languages can be developed in companies (C, Java, >> Go) or >> > > in >> > > > > > academia (Lisp, Scheme, Scala) or a mix of both (Fortran, C++, >> Cobol, >> > > > > > Smalltalk, Self). The important point is that whatever their >> > > genesis, a >> > > > > > language has a supportive community and is maintained >> professionally. >> > >> > > > > > Academics generally have the freedom to be more experimental, >> > > certainly >> > > > > > there are more new languages emanating from academia, most of >> which >> > > > > > rapidly fall by the wayside, but where one catches on, as long >> as it >> > > > > > performs the transition from academic experiment, to >> professionally >> > > > > > maintained product that is good and fine. Afterall technology >> > > transfer >> > > > > > of ideas from academia into industry and commerce is what most >> > > venture >> > > > > > funding is all about. >> > >> > > > > > So can we have less of "academic == bad". >> > >> > > > > > > It's been so focused on making such trivial little code >> snippets >> > > look >> > > > > > > good at a casual glance, it completely forgot that in >> practice, >> > > code >> > > > > > > reading is about trying to make sense of 500kloc filled with >> > > obscure >> > > > > > > bug fixes, domain specific knowledge, and the occasional WTF >> code. >> > > And >> > > > > > > that's not fixable by peddling the old "just hire really good >> > > > > > > programmers" spiel. I fully agree with that, but even the >> biggest >> > > > > > > genius has off days. That must be true because even I >> sometimes >> > > look >> > > > > > > back at code I wrote a few months ago and get the sudden urge >> to >> > > punch >> > > > > > > myself for being such an idiot :P >> > >> > > > > > To be honest you just made the argument for Scala and against >> Java. >> > >> > > > > > > A language that cleans up a few things without falling into >> that >> > > trap >> > > > > > > might fare better but I fear the difference won't be >> convincing >> > > enough >> > > > > > > to make folks switch. Crappy catch 22 situation, that. >> > >> > > > > > In your opinion. Many other people have a very different >> opinion. >> > > If I >> > > > > > can write what takes 500kloc of Java in 100kloc of Scala, then >> it is >> > > > > > far more likely that the latter will be more comprehensible and >> > > > > > therefore more maintainable. If it takes 50kloc of Python it is >> > > > > > probably even better. >> > >> > > > > > > NB: Also worth considering: No language EVER has become truly >> > > gigantic >> > > > > > > by offering nice syntax. Instead, the languages that won >> tended to >> > > > > > > offer really crappy syntax but provided something else, not >> related >> > > to >> > > > > > > syntax, that caused mass conversion. C did not attempt to >> abstract >> > > > > > > away the bare metal too much but did offer standardization >> across >> > > > > > > platforms. Java brought the garbage collector, very nice (at >> the >> > > time, >> > > > > > > at any rate) portable multithreading, and seamless freedom of >> > > moving >> > > > > > > to different hardware, "seamless" defined as relative to your >> > > options >> > > > > > > before it came out, all WITHOUT a radical new syntax. >> > >> > > > > > I think you should re-evaluate your knowledge of programming >> history: >> > >> > ... >> > >> > read more » >> >> -- >> 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. > > -- > 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. > -- Romain PELISSE, "The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett http://belaran.eu/ -- 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.
