I thought you were looking for arguments; I did not know you were just going to troll java programmers. Not trying to make a low blow here, but the way you're deflecting every argument, you're not trying to have an argument at all, this is just a (bad) attempt at trying to win more souls for scala. I suggest you take a deep breath, a step back, and refrain from such exercises in the future. You're far more likely to get three cheers and a pat on the back if you post stuff like this in a scala oriented forum.
On Aug 26, 1:53 am, Kevin Wright <[email protected]> wrote: > On 25 August 2010 23:56, Reinier Zwitserloot <[email protected]> wrote: > > > Shows pretty much exactly what's wrong with scala, doesn't it? Short, > > yes. Complicated? You bet. This partition method is absolutely > > horrible. Let's dissect it. Note that I renamed l and r to left and > > right for clarity, l looks like a pipe. Also, using 'l' as a variable > > name shows someone has taken 'shorter code is better' FAR too > > literally. Only a minor nit in this case, as with methods that are > > this short, confusion about variable names isn't going to be a big > > issue. > > So true, the meaning is instantly obvious with anyone with sufficient > brain-cells to be a programmer, and avoids cluttering up the essential logic > of the method, which is really what counts here. > > > val left, right = newBuilder > > > Hmm, this is really weird. In java, this would mean "left" is > > unassigned and cannot be used until it has been. Apparently in scala > > this is short for val l = newBuilder, r = newBuilder. It is NOT > > equivalent to val l, r; l = r = newBuilder; either, because clearly l > > and r do not end up with the same object reference, but two separate > > ones. This is highly confusing to me (read: Not at all what I expected > > would happen, I'm only deducing it by starting with the assumption > > that this code works). If this is how scala ends up with shorter code, > > I don't want it. > > Again, it must have taken you at least a second to infer the correct meaning > from the context. > > newBuilder is a function, each of l and r get assigned a value based on > calling that function. > What if, instead of `newBuilder` it was `newBuilder()` or something like > `builderStack.pop`, what would your intuition then lead you to expect? > > I'd argue that Scala's convention is both more logical and practical, not > that having different conventions is really a just basis for comparing any > two programming languages. > > > > (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; > > Interestingly, I don't. In the Scala example, I see that we're adding x, > it's just a question of what we're adding x to. > In your Java example, I'm seeing that you might add x to l > > then a line break > > oh, and if not then you'll add x to r > > > Using ifs as expression is a nice gimmick that tends to lead, IMO, to > > hard to read code. > > and the need to introduce the ?: ternary operator as a workaround because > control blocks don't evaluate as an expression. > Is that not more of a gimmick? (with its own section in the language spec) > > This whole idea of everything evaluating to a value is deep in the core of > Scala, it also applies to pattern matching (like switch statements), if/else > blocks, etc. > > Even assignment evaluates, but to Unit, which is a bit like void but > represents more than just the lack of a method return type. > > > > > > > Just like assignment-as-expression. Yet again, a > > source of making your code smaller which only hurts readability (i.e. > > nice for code golfing, but a bad idea otherwise). This form of if > > statement is of course perfectly legal in java code. The += part of it > > is not, but, that's up next: > > > list += x; > > > This is where scala shows how complex does equal complicated. In java, > > such a statement means either (A) string concatenation, (B) floating > > point arithmetic addition, or (C) integer arithmetic addition. I find > > the idea that it could mean string concatenation unelegant, but B and > > C work together nicely: It's all arithmetic addition. I'd love for > > java to add a feature that you can use the + symbol to add up two > > BigIntegers or two BigDecimals, as, yet again, its arithmetic > > addition. Scala allows operator overloading and started with the best > > of intentions (this way the authors of BigInteger and BigDecimal can > > fix it themselves!) and screwed it up by now apparently letting "+=" > > mean list appending. What a silly notion. How the heck does this > > improve readability? It only detracts. And you save exactly 3 > > 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. > > Actually, use of + and += on Lists is deprecated for this very reason. > Why? because + and += had to do weird things in other places to allow Scala > code to behave more like Java, specifically with regards to Java's coercion > of objects/primitives to strings when adding them to an existing string. > > This led to conundrums such as: Given the existence of an implicit > conversion from String to Seq[Char], what does it then mean when you add a > Seq[Char] to a String, what's the expected return type? > > Sure, there's complexity here, and room for misunderstanding - but it's > inherited from Java's Spec, and is a cost of trying to behave like Java as > much as possible without good reason to do otherwise. > > FWIW, contemporary code now favours the :+ and :+= operators to disambiguate > when appending to a list > > > At the same time there are some legitimately nice features here. "val" > > is nice, and could easily be added to java, with "final" taking its > > role: "final x = 10;" would then be legal and infer 'int' as x's type. > > Also, returning tuples is borderline nice, though it does lead to a > > suspicious lack of named types. Not that convinced personally about > > 'last expression is return statement', but that's clearly a purely > > stylistic concern. > > It's essential when writing in a functional style, with logic being seen as > a sequence of transformations and no internal mutation of state. This isn't > just about methods, but about all control blocks. > > > It is, however, worth noting that sticking a return > > in front of that really doesn't hurt readability, it might even > > improve it, though this is again the shortest possible way you could > > go. i.e. Martin Odersky is in love with code golfing, and equating > > code golfing to elegant language design seems misguided to me. > > This is the same Martin Odersky who designed the Java 1.5 reference > compiler, the vast majority of which you are still happily using :) > > > Conclusion: Scala will never be the next big thing, because along with > > the nice syntactical cleanups, it's falling into the academia trap: > > 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. > > As opposed to what? > Making out code that's 5x longer than it really ought to be, where the true > intent is buried in endless loops, preceded by countless identical type > declarations, surrounded every side by getter and setter definitions, and > maybe implemented inside the single abstract method of some interface, just > for good measure. > > I'll favour the version where I can clearly see those bug fixes and the > domain knowledge, instead of having to trawl through boilerplate for it. > > > > > > > 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 > > > 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. > > > 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. > > It's all about concurrency, functional programming, and the practices > surrounding FP, is inherently more suitable for being scaled up to massively > parallel hardware. Almost all the design choices you see in Scala are > driven by the desire to stay as close to Java as was reasonably possible, > whilst also adding full FP support. > > > 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. > > How do you feel about just making the method express its intent more > cleanly, with less clutter? > There's something far deeper here than mere character-counting... > > > > > On Aug 25, 11:39 am, Viktor Klang <[email protected]> wrote: > > > On Wed, Aug 25, 2010 at 11:29 AM, Romain Pelisse <[email protected]> > > wrote: > > > > I'm suprised that nobody notice that this example is pretty much > > irrelevant > > > > (if not plain stupid). > > > > > Basically, you can write this in a very small manner in Scala just > > because > > > > list object in Scala has a "partition" method). Most of the extra code > > in > > > > Java is just about code the > > ... > > read more » -- 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.
