You twisted my point. My point is that you can make code that reads more like the domain you are modeling. Consider, if you are trying to implement an algorithm for processing data that is in a matrix. Which do you find more readable, one that can look very similar to the paper from which you acquired the algorithm, or the one that you had to first translate to java land?
The valid counter to operator overloading is that it can be misused. But, you counter that in your second paragraph. So... what are the complaints of this style of programming? On Aug 9, 3:07 am, Viktor Klang <[email protected]> wrote: > 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.
