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.
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. 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. 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, this choice is good, because the > > benefits of picking the best option available outweigh the burden of > > having the choice. In all other situations, though, this choice is not > > useful at all. It makes sharing code harder (because Joe likes 'each', > > but Jack likes 'for'). This is like spaces v. tabs: The flexibility of > > using either really isn't helping. We'd have been better off if back > > in the day someone put their foot down and declared some indent style > > to be the only one compilers will accept from here on out. Deviation > > from this one rule results in compiler warnings. I can't claim to be > > very scientific about it, but to me it feels like Scala has gone > > waaaay too far down the "give the programmers the flexibility" path. > > Where the flexibility helps me make code do different things, that's > > fantastic. Where this flexibility boils down to the exact same end > > result, and I just have many different ways of expressing the same > > concept, usually, it's just a bother. It's needless complication. > > > The python folks differentiated themselves from the Perl folks early > > by turning Larry Wall's "There Are Many Ways To Do It" around into > > "There Is Only One Way To Do It" and I subscribe to the theory. > > Introducing stylistic choice needlessly is always bad. But yet again > > there's a dichotomy here: Where stylistic choice turns from pointless > > to useful is a moving target, there isn't a single answer to the > > question. > > > Perhaps I was unclear about my comment in regards to using java > > libraries in scala code: If you're going to write scala, then... write > > scala. Which means you use THEIR collection APIs. If you stick with > > java.util.List, then interopping with other scala code is going to be > > a nightmare, and even if most scala programmers are familiar with the > > java APIs (which is clearly an argument that can't scale: If scala > > outgrows java in popularity, or gets even remotely close to it, how > > can that possibly be true?), its like not following the camelcasing > > conventions in java code. It throws people off, makes your code > > ridiculously hard to understand. Just don't do it. There's no going > > halfway, and there's not much point (as you said too) in trying to > > stay up to date with both java and scala. Pick one. That's your go-to > > language for larger projects where static typing is nice, and/or speed > > is not unimportant. If you want to learn more languages, fantastic. > > But don't pick java and scala. That's a silly combination, the problem > > domains where these 2 languages shine overlap far too much. > > > On Sep 17, 10:42 am, Ricky Clarkson <[email protected]> wrote: > > > Reinier, > > > > You want a definition of simple? Ok, some code is more simple than some > > > other code if it contains fewer tokens that are outside the domain. > > E.g., > > > Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++. Java's > > > SwingUtilities.invokeLater(new Runnable() { public void run() { > > > button.doClick(); } }) is not as simple as Scala's: > > doLater(button.doClick). > > > > Staying cutting edge on Scala is easier as it does not require a cutting > > > edge runtime. > > > > In my opinion, for tasks for which Java is a reasonable option, so is > > Scala, > > > as it is typed and runs in the same environment. I wouldn't look at > > Groovy, > > > JRuby or Jython for those, because they are untyped. > > > > Regarding writing in DSLs, pretty much all code unless > > ... > > 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
