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-limits-of-the-java-type-system/
http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/
> 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]<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.
