1 : 3 is quite conservative. 1 : 5 is more realistic. You only need to
look at your own examples of Java+Lombok to appreciate that case classes
make a massive LOC difference.
Type inference ends up removing a few imports per file, too, as you don't
need to import a type if all you would use it for is to declare a variable.
Importing n types from 1 package uses 1 line in Scala, compared to n lines
in Java. import java.util.{ArrayList, List, Map, HashMap}
The lack of checked exceptions also makes a difference to LOC.
Lest I be named disingenuous, I should point out that for loops often take
more lines in Scala.
On Sat, Sep 18, 2010 at 9:25 AM, Reinier Zwitserloot <[email protected]>wrote:
> A 1 : 3 reduction in LOC? Don't make preposterous claims.
>
> 1 : 3 rates is what happens when you rewrite a project, from scratch,
> now knowing exactly what you've learned. That's obviously not a fair
> comparison.
>
> In my own experience, Scala code tends to be about ~85% to ~90% of the
> lines that java source code is. But LOC is an extremely flawed measure
> of code complexity, so I'm not sure this is a useful construct.
>
> The answer to your question is much, much simpler: Your 1 : 3 rate is
> bullpuckey.
>
> On Sep 18, 9:54 am, Kevin Wright <[email protected]> wrote:
> > 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..
> ..
> > > ..
> >
> > > > > 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
> >
> > ...
> >
> > 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.
>
>
--
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.
