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: > > > > 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] <sip%[email protected]> > > > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > > > 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<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 [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.
