I find it rather amusing that people argue that being able to create methods that are familiar symbols (+,-,* etc) leads to code that is hard to understand. This is a false statement.
ANY word/symbol can be defined to work in a way that is not intuitive, it doesn't matter if we call a method "plus" or "+" if it's not doing addition, it'll be confusing anyway. On Sun, Aug 8, 2010 at 5:35 PM, Josh Berry <[email protected]> wrote: > It seems that the thing that is "off" in all of this discussion is > that we are trying to determine which is more complex between the > languages, when what we really care about are the programs written in > those languages. > > To that end, I really just want to simply point to something like > scalatest or squeryl to get an idea of the simplicity of some of the > client code that can be written against Scala. > > Take your example, though, "5 + 2." This works for simple numbers, > but what about the fun of matrix math? Or complex numbers math? Both > of which would undoubtedly look nicer --- one might say simpler --- > using the familiar symbols for addition, but this can not be done in > Java. Now, I would agree that this is a complexity of the language, > but it is a simplification in the program. > > > > On Aug 7, 6:32 pm, Reinier Zwitserloot <[email protected]> wrote: > > How's that a case for simplicity for scala? > > > > In java, "5 + 2" means just what you think it means, intuitively. If > > you want to know more still you'll have delve into the extensive JLS > > which confirms your suspicions. > > > > In scala you need to delve into the libraries, and you really have no > > idea what it could possibly do - every object can field its own > > definition of '+'. This isn't simple anymore; the drive to libraryize > > all complexity means that most seemingly atomic library operations are > > in fact not the lowest layer, but they build on a lower layer still, > > and in languages like scala, that lowest of layers is not all that > > natural. > > > > I continue to assert that claiming scala is simpler because the JLS is > > longer than the scala equivalent is the stupidest thing I've ever > > heard. > > > > On Aug 6, 10:59 am, Kevin Wright <[email protected]> wrote: > > > > > > > > > The idea that we can establish some sort of formal complexity > measurement > > > for documentation is... interesting. > > > Although I think there's more joy to be had in measuring EBNF, or the > size > > > of some other parser grammar considered complete for the language. > > > > > I'd also like to briefly explore one of the differences between the two > > > language specs... Consider the `+` operator. > > > > > In the JLS, this is covered in chapter 15, "expressions" > > > 15.18 - additive operators > > > 15.18.1 - string concatenation > > > 15.18.1.1 - string conversion > > > 15.18.1.2 - optimization of string concatenation > > > 15.18.1.3 - examples of string concatenation > > > 15.18.2 - additive operators for numeric types > > > Spanning pages 496-501 > > > > > It's a bit different in Scala, which doesn't have operators as quite > the > > > same way. They're just methods in infix/operator notation. > > > > > Everything in Scala is also an object (no primitives). Int, Float, > String > > > etc. are still optimised in the compiler, and will often use primitives > in > > > the generated bytecode, but within Scala code they are objects. So `+` > > > becomes a method on the String/Int/Float/etc. object. The Scala spec > > > doesn't list API methods any more than the JLS does. > > > > > What the spec *does* have is section 6.12.3, outlining how methods used > in > > > the infix position have a precedence determined by the first character > of > > > the operator name. One beauty of thie approach is that it effectively > gives > > > you operator overloading, allowing things like this: > http://www.scala-lang.org/api/current/scala/math/BigDecimal.html > > > > > This is sufficient to be able to duplicate Java's behaviour, by > building up > > > to it on the basis of a broader (and simpler) concept. > > > > > So "x" + 2 May look the same as Java, but it's actually achieved via > the > > > `+` method on a String instance, and not a dedicated special-case > operator > > > with 3 sections in the language spec. > > > > > On 6 August 2010 00:38, JodaStephen <[email protected]> wrote: > > > > > > Kevin Wright is fond of repeating: > > > > Java (3rd Edition): 649 pages, 7932 KB > > > > Scala (current in trunk): 191 pages, 1312 KB > > > > therefore Scala is less complex. > > > > > > But has anyone actually analysed the specs in detail? > > > > > > In code coverage terms, how many distinct "code paths" are there in > > > > each spec. That is surely a far better measure than number of pages. > > > > > > Volunteers for counting?!! > > > > > > Stephen > > > > > > -- > > > > 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. > > > > > -- > > > 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.tumbler.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.
