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
Description: This is a digitally signed message part
