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 <reini...@gmail.com> 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 <viktor.kl...@gmail.com> wrote: > > On Thu, Aug 26, 2010 at 3:10 PM, Reinier Zwitserloot <reini...@gmail.com > >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 <rus...@russel.org.uk> 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: > > > > > > Machine code > > > > Assembly language > > > > Fortran / Cobol / Lisp > > > > Pascal > > > > C > > > > C++ / Smalltalk / Perl > > > > Java / Python > > > > > > A lot of syntax going on there. Almost all of it related to making a > > > > simple looking statement carry a very large amount of meaning. > > > > > > > This is why I firmly believe the next big programming language has > yet > > > > > to be invented, and will involve a similarly crappy syntax, but > offers > > > > > language-level module systems, language evolvability, AST-based > > > > > editing, compiler plugin based DSL enabling, extensive static > > > > > analysis, and other such features that aren't intricately involved > > > > > with Martin Odersky managing to remove another character from the > > > > > partition method. > > > > > > Point 1, you owe Martin Odersky an apology for the slurs on his > > > > character you have made in this posting. > > > > > > Point 2, you are describing Scala, Groovy, JRuby on the JVM and > Python, > > > > Ruby, D, Go, etc. off it. Well except for the static analysis in > Groovy > > > > JRuby, Python, and Ruby. You are making the assumption that > statically > > > > compiled programming languages are of more merit than dynamic ones. > > > > This may be your opinion, but I bet the majority of people have a > > > > different one, more along the lines of statically types and > dynamically > > > > typed languages both have their place in developing a system. > > > > > > AST-based editing is a completely different issue. There were > systems > > > > doing this available in 1985, but they were not deemed to be > appropriate > > > > enough for proper software development environments, everything had > to > > > > be files based. So the whole IDE industry rejected exactly that > which > > > > was available and they are now having to reconstruct ASTs based on > plain > > > > text files. Bizarre. > > > > > > I had thought of trying to write a shorter reply, but it is too early > in > > > > the morning. > > > > > > -- > > > > Russel. > > > > > > =========================================================================== > > > == > > > > Dr Russel Winder t: +44 20 7585 2200 voip: > > > sip:russel.win...@ekiga.net <sip%3arussel.win...@ekiga.net> < > sip%3arussel.win...@ekiga.net <sip%253arussel.win...@ekiga.net>> > > > > 41 Buckmaster Road m: +44 7770 465 077 xmpp: > rus...@russel.org.uk > > > > London SW11 1EN, UK w:www.russel.org.ukskype: russel_winder > > > > > > signature.asc > > > > < 1KViewDownload > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "The Java Posse" group. > > > To post to this group, send email to javapo...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > <javaposse%2bunsubscr...@googlegroups .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > > > -- > > Viktor Klang, > > Code Connoisseur > > Work: www.akkasource.com > > Code: github.com/viktorklang > > Follow: twitter.com/viktorklang > > Read: klangism.tumblr.com > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: kev.lee.wri...@gmail.com wave: kev.lee.wri...@googlewave.com 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
