What really gets my goat though... It's the pro-java/anti-scala crowd who are pushing the claim that "Scala is only for smart people".
Myself, and the rest of the Scala evangelists on this list are going to great pains to point out that: no, actually, Scala is for everyone. I don't think that anyone here disagrees about how nasty SAM's are :) On 27/08/2010, 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]. >>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. > > -- 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.
