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.
