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/src//library/scala/collection/TraversableLike.scala#L311 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]> >>> . >>> 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. >> > > > > -- > 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]> > . > 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.
