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 partition method. If you remove the part > > > regarding coding the partition method, the Java code pretty much look > like > > > the Scala code. > > > > The code behind partition: > http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/sr... > > > > def partition(p: A => Boolean): (Repr, Repr) = { > > val l, r = newBuilder > > for (x <- this) (if (p(x)) l else r) += x > > (l.result, r.result) > > > > > > > > > > > > } > > > > > A good example would be using the same set of provided functions on > Scala > > > and in Java to resolve an issue. > > > > > On 25 August 2010 11:24, Viktor Klang <[email protected]> wrote: > > > > >> I think we first need to define "complex", then we need to decide if > it's > > >> desirable or not. > > > > >> Complex != complicated > > > > >> The human body is _really_ complex, but I wouldn't want to trade that > to > > >> be something less complex, like a piece of wood. > > > > >> On Wed, Aug 25, 2010 at 11:16 AM, Kevin Wright < > [email protected]>wrote: > > > > >>> I think our principles actually agree here, if not our conclusions. > > >>> Scala truly does epitomise the idea that "less is more", a fact that > > >>> becomes ever-more obvious with repeated exposure to the language :) > > > > >>> Scala is surprisingly small, with many features actually being > > >>> implemented via the standard library and not as part of the core > language > > >>> spec. > > >>> This includes both "big" stuff, like actors, and "small" stuff, like > > >>> automatic conversion of Ints to Strings > > >>> Much of this is made possible by core language features that actually > > >>> *are* part of the spec: first class functions, case classes, > implicits, > > >>> mixins, operator notation, etc. > > > > >>> So it really, really doesn't have everything out of the box, or > rather it > > >>> has two boxes: the core spec and the standard libs. It's just that > the > > >>> extension points in the core spec are so good that standard lib stuff > can be > > >>> made to look like it's an internal part of the language. Better > still, you > > >>> can use the same techniques in your own code - just look at > ScalaTest, > > >>> scalaz or akka to see what's possible. > > > > >>> The only point I will disagree on (in absence of a particular use > case): > > >>> For *truly* performance-critical code, should you be using a > database at > > >>> all? The need to serialize/de-serialize everything via a magnetic > platter > > >>> can be a serious bottleneck! > > > > >>> On 25 August 2010 09:49, Fabrizio Giudici < > [email protected] > > >>> > wrote: > > > > >>>> -----BEGIN PGP SIGNED MESSAGE----- > > >>>> Hash: SHA1 > > > > >>>> On 8/25/10 10:25 , Kevin Wright wrote: > > >>>> > lombok hooks into the compiler, extending Java code to allow some > > >>>> > code generation. So it's not unreasonable to consider Java+Lombok > > >>>> > to be a distinct language from Java or even an extension/evolution > > >>>> > of Java. > > > > >>>> > Scala reuses Java syntax as much as possible, changing it where > > >>>> > necessary to add functional constructs and type inference. So > > >>>> > it's not unreasonable to consider Scala an extension/evolution of > > >>>> > Java. > > > > >>>> > So comparing Scala to JavaLombokLambdaJ (JLL) is emphatically > > >>>> > *not* the same as comparing Scala to Java. > > > > >>>> This is pretty much philosophy :-) while I think we're discussing > how > > >>>> to practically do things. My point is that Java is a *simple* > language > > >>>> with a reasonable set of extension points to tailor it to people's > > >>>> needs (and these extension points have been designed purportedly, > i.e. > > >>>> Lombok is not playing any "trick", it's just using a feature - > > >>>> annotations and compiler extensions - that has been put there for > that > > >>>> purpose). This means that different people can extend Java in > > >>>> different ways, if they want. Scala has got everything > out-of-the-box: > > >>>> right, that's why I'm saying that it's more *complex*. > > > > >>>> > However, if you do compare Scala to JLL, three things stand out: - > > >>>> > JLL is driven by annotations, so it's not a seamless integration > > >>>> > that looks like part of the language > > > > >>>> As I said, annotations are a natural part of the language. > > > > >>>> > - JLL does everything with reflection, adding a performance cost > > >>>> > that could be critical in some domains > > > > >>>> Lombok doesn't use annotations, but code generation at compile time. > > >>>> lambdaj is using some reflection and has some performance hit. It's > to > > >>>> be seen how strong it is, in any case, and we can't just decide > > >>>> without a case study. I'd also argue that complex list filtering > that > > >>>> are performance-critical are probably best to be done in the > database, > > >>>> rather than in the language (e.g. I don't think it's advisable in a > > >>>> common scenario to load 1,000,000 of persons in memory to pick those > > >>>> younger than 18). This is just a counter-example, of course. > > > > >>>> > - You still don't have pattern matching, or type classes, or etc, > > >>>> > etc... > > > > >>>> Yes. Maybe I don't need them? :-P Seriously, I've said multiple > times > > >>>> that Scala is more powerful. It's to be said if all that > > >>>> extra-complexity is really needed. I'm still on the side "Less is > More". > > > > >>>> - -- > > >>>> Fabrizio Giudici - Java Architect, Project Manager > > >>>> Tidalwave s.a.s. - "We make Java work. Everywhere." > > >>>> java.net/blog/fabriziogiudici -www.tidalwave.it/people > > >>>> [email protected] > > >>>> -----BEGIN PGP SIGNATURE----- > > >>>> Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > > >>>> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > > > >>>> iEYEARECAAYFAkx02RoACgkQeDweFqgUGxf4wACfTQ6jUiAUH/nb6Ieu4ccvDg+6 > > >>>> AZsAn1uf0JzS9L7u5wpOb95WBSM7+Vrr > > >>>> =j3kd > > >>>> -----END PGP SIGNATURE----- > > > > >>> -- > > >>> Kevin Wright > > > > >>> mail/google talk: [email protected] > > >>> wave: [email protected] > > >>> skype: kev.lee.wright > > >>> twitter: @thecoda > > > > >>> -- > > >>> 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]> > <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]<javaposse%[email protected]> > <javaposse%2bunsubscr...@googlegroups .com> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/javaposse?hl=en. > > > > > -- > > > Romain PELISSE, > > > "The trouble with having an open mind, of course, is that people will > > > insist on coming along and trying to put things in it" -- Terry > Pratchett > > >http://belaran.eu/ > > > > > -- > > > 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]> > <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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
