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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
