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. 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 <viktor.kl...@gmail.com> 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 > <kev.lee.wri...@gmail.com>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 >> <fabrizio.giud...@tidalwave.it>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 >>> fabrizio.giud...@tidalwave.it >>> -----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: kev.lee.wri...@gmail.com >> wave: kev.lee.wri...@googlewave.com >> 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 javapo...@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscr...@googlegroups.com<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 javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
