So, val l, r = newBuilder works because newBuilder is a method, and this method returns a tuple?
Good lord. I rest my case! 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: > > 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:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w:www.russel.org.uk skype: 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 [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.
