Oh, sorry, I wasn't bashing your point, I was agreeing! On Mon, Aug 9, 2010 at 2:43 PM, Josh Berry <[email protected]> wrote:
> 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%[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]> > <javaposse%[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]<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.
