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