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.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]<javaposse%[email protected]> > . > 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.
