Every summary I've seen for a project converted from Java to Scala reports, at minimum, a 1 : 3 reduction in LOC.
If this isn't from making invisible / automating trivial detail (as per your definition of higher level) then where's all the code going? It can't *all* be in the semicolons! On 18 September 2010 04:03, Reinier Zwitserloot <[email protected]> wrote: > Ah, that was it; variable declarations are expressions but their value > isn't what you might think. I knew there was some reason for not > trying to use them as one. > > Your extends example doesn't make any sense to me. It's the same in > java: > > interface X { > int property(); > } > > class Y implements X { > public int property() { > return 32; > } > } > > I gave you a useful definition of 'higher level'. I don't really see > how saying "But I think scala IS higher level" without either defining > what you mean or giving examples that fit my particular definition is > a good idea, given that we just got into a 200+ post mess due to > confusion about the term "complexity". > > On Sep 17, 5:50 pm, Kevin Wright <[email protected]> wrote: > > On 17 September 2010 16:18, Reinier Zwitserloot <[email protected]> > wrote: > > > > > Correction: In java, as in scala, all expressions "return" a value > > > (not really the right term, that. Expressions *have* a value is closer > > > to the mark). It's just that in scala more things are expressions. > > > Like "if": Expression in scala, statement in java. Not ALL things in > > > scala are expressions. Variable declarations aren't, for example. > > > > Hot from the Scala REPL: > > > > scala> val x = { val y = 32 } > > x: Unit = () > > > > So even variable assignments evaluate to a value. > > > > > In any java library that isn't completely worthless, the code is > > > "getField()". If you get annoyed at writing out the accessor, use > > > lombok. Claiming that as a benefit to scala seems like you're grasping > > > for reasons. > > > > It's a major benefit: > > > > trait X { > > def property : Int > > > > } > > > > class Y extends X { > > val property = 32 > > > > } > > > > When I use `property` from an object of type X, it really doesn't matter > if > > it's implemented via a field of if it's computed. > > That freedom from having to know (or care) is a simplification to me. > > > > > > > > > > > > > A useful definition for "higher level" is that it makes invisible / > > > automated whatever's trivial detail. This is a double-edged knife, > > > though: Whether or not a detail is trivial depends on the problem. For > > > example, C conveniently abstracts away the concept of stack, but in > > > the process of doing so, removes the ability to store stacks. The JVM > > > abstracts away memory management, but in the process of doing so > > > introduces non-determinism due to gc runs. > > > > > However, with that definition scala isn't much higher than java. There > > > aren't many things that you can no longer do in scala but which you > > > can do in java, and on the flipside, there aren't many things that are > > > orders of magnitude simpler in scala than java because something has > > > been abstracted away. Scala is more a sideways step: It's operating at > > > the same general level of abstraction as java, but with a different > > > syntax, which includes more emphasis on function objects (something > > > java CAN do, but not with particularly nice syntax), as well as a less > > > rigid syntax structure, and a general more functional outlook. > > > > Function objects are just a tiny part of it, not only does Scala have > > functions that are objects, but also any arbitrary object can be made > into a > > function. > > On top of this there's pattern matching, implicits (which allow for type > > classes), higher-kinded types and by-name params. > > Closures alone don't make a language higher level than Java, but Scala > > really isn't about just closures... > > > > Just compare the implementation of a heterogenous list in both languages: > http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the...http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-s. > .. > > > > > > > > > On Sep 17, 3:28 pm, Kevin Wright <[email protected]> wrote: > > > > I'm recently taking the position that it's impossible to state which > of > > > two > > > > languages is "simpler", the term is just too heavily overloaded. > > > > > > Just pick your definition and it's trivial to show that assembly is > > > simpler > > > > than LISP, or vice-versa, but you've still achieved nothing. If we > use > > > the > > > > term "higher-level" instead of "simpler", then this difficulty > > > evaporates. > > > > > > Personally I feel that Scala is simpler than Java, but that statement > > > means > > > > nothing without also explaining the particular definition of the term > > > that > > > > matters to me. In this case, it's two features of that language that > > > really > > > > stand out, and show Scala to be the higher-level language.. > > > > > > 1. It has constructs that closely match the way I think about > problems. > > > > When I have to mangle the design in my head so that it matches the > > > features > > > > of the target language, I perceive that as an unneccessary > complication > > > in > > > > the design+implementation process. > > > > 2. Scala has a smaller general-purpose syntax that I can use accross > a > > > wide > > > > range of problems, instead of a larger number special-case > constructs. > > > For > > > > example: > > > > > > - Java has the ?: operator, but Scala has the much more general idea > that > > > > all expressions return a value. > > > > > > - Java has a switch statement over numbers, enums and (soon) Strings, > > > wheras > > > > Scala has pattern matching that isn't limited to any type. > > > > > > - Java has primitives, and operators are limited to only working with > > > > primitives. Everything in Scala is an object, and operators are just > > > > methods. > > > > > > - Java has special behaviour for concatenating an object or primitive > to > > > a > > > > string, Scala can do this with implicit conversions - a feature > that's > > > > useful in many more situations. > > > > > > - To fetch a value from an object in Java, I must first know if it's > a > > > fixed > > > > value or if it'll be calculated, and so use field or getField() as > > > > appropriate, Scala doesn't force this distinction and so it's enough > to > > > know > > > > I'm fetching a value, the underlying logic could even be changed in > the > > > > future without breaking my code. > > > > > > The ability to work with general concepts and not have to chose > exactly > > > > which special feature I need in a given situation... I see that as > > > > simplifying the task of programming. > > > > I could say more, but it's probably just "simpler" to point here: > > >http://stackoverflow.com/questions/727078/whats-so-great-about-scala/. > .. > > > > > > On 17 September 2010 11:30, Reinier Zwitserloot <[email protected]> > > > wrote: > > > > > > > That just sounds like equating "simple" to "less verbose". > > > > > > > For example, with optional () for args-less method calls, you get a > > > > > number of things which one might deem "simpler": > > > > > > > - Less characters to type and read > > > > > - The ability to not have to care about whether the doClick member > is > > > > > a method or a field > > > > > > > On the other hand, you also get a few things which are decidedly > more > > > > > complicated: > > > > > > > - A stylistic choice about whether or not you add the (). Having > to > > > > > make an irrelevant choice of any sort clearly seems like a lack of > > > > > simplicity to me. > > > > > - The INability to tell if doClick is a field or a method. In > certain > > > > > circumstances it matters, and having to look it up is more > complicated > > > > > than being able to tell at a casual glance. > > > > > > > These are clearly conflicting requirements. Forcing you to care > > > > > whether doClick is a field or a method is needless complexity.... > > > > > unless it isn't, in which case not being able to tell is needless > > > > > complexity. Offering the programmer the choice doesn't help, > because > > > > > the choice in it self is needless complexity, and by existing we > still > > > > > can't tell, given "foo.doClick", if doClick is a field or a method. > > > > > We'd have to rely on a programmer following the local style > guidelines > > > > > (if, say, these state that non-fields ought to be called with > parens), > > > > > which you can' even unit test. Now we're introducing needless > > > > > complexity there. > > > > > > > Oh, how complicated. > > > > > > > There's also the issue of moving complexity around to the problem > > > > > domain. My usual retort to those complaining about the complexity > of > > > > > generics is simply this: Co- and Contravariance is _inherently_ > > > > > complicated. When you have a problem where generics is required or > > > > > seems quite useful, then the problem has this complexity, > inherently. > > > > > You can choose not to use generics, but then the complexity is just > > > > > hidden away in javadocs and a bunch of casts. You can tweak > generics a > > > > > bit, declaration-site generics probably being the most drastic, but > a > > > > > truly "simple" generics will never be, because co/contravariance > isn't > > > > > simple. > > > > > > > So, did java become more complex when 1.5 was introduced? Yes. Does > > > > > this mean java 1.5 is worse than 1.4? No - in fact, it's better. > > > > > > > So, in certain ways, a more complex language is actually a good > thing. > > > > > > > Hence my conclusion that all this talk about "complexity" is not > going > > > > > to convince anybody one way or another, because its very very easy > for > > > > > anyone reading the word "complexity" and imagine whatever situation > is > > > > > least likely to convince them. > > > > > > > So, to try and mitigate this, here's where I believe scala has > added > > > > > needless complexity: > > > > > > > Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean > by > > > > > DSLish features (yet another vague term that can mean just about > > > > > anything). Should I put () after an args-less method call? There's > a > > > > > stylistic choice there. dots to dereference? Another stylistic > choice. > > > > > Use operator overloading, or not, and if I do, left-associative or > > > > > right-associative? There's also boatloads of semantic choice in > scala. > > > > > If I need to iterate over a map and, say, produce a list containing > > > > > the concatenation of each key and associated value, in java there's > > > > > really only two obvious ways to do it. Both involve looping, and > the > > > > > only difference is whether I iterator over entrySet() or keySet(). > In > > > > > scala, there's _way_ more choices. I can do a java-style loop, or I > > > > > can use an each construct that fills the list, or I can turn the > keys > > > > > and the values into two sets, and then zip them up, functional > style, > > > > > or I could use a comprehension of some sort. > > > > > > > Why is this bad: > > > > > > > Well, obviously a language can't eliminate _all_ stylistic choice. > At > > > > > the very least you have to pick a name for your methods, and naming > is > > > > > clearly up to you, the API author. But, scala goes _way_ too far in > my > > > > > opinion. While it seems like a nice idea, give an API designer, and > an > > > > > API user, the ability to write in whatever feels most natural (i.e. > > > > > readable, easy to maintain), that's great! Except when it isn't: By > > > > > introducing all these stylistic choices, you're forcing the API > user > > > > > to pick at every stage. Sometimes, > > > > ... > > > > read more » > > -- > 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. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
