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.
> 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. > (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; 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 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. 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 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. 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. 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. 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. 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%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%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%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.
