So Scala is too Complex?

[Kevin Wright]

http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/

I'm curious, does anyone have an example of the same problem being solved in both Java and Scala, with Java offering the simplest solution?

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/25/10 08:55 , Kevin Wright wrote:
>
> http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/
>
> I'm curious, does anyone have an example of the same problem being
> solved in both Java and Scala, with Java offering the simplest
> solution?
>

Copying the response I posted to that blog:

If you used e.g. Lombok which auto-generates all the
getter/setter/toString plumbing code via annotations and e.g. lambdaj
that allows to use closure-like filtering on collections, the Java
listing would be just a bit longer than the Scala listing. Which
proves how often people asserting Scala being better than Java aren't
completely aware of all the possibilities that Java offers. :-)

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx0z1wACgkQeDweFqgUGxdA7ACgsWGCS+pU0lWGPCX/T+5DPk1o
8tAAniDG7uNVDSPYTKRSKjHdBMnjZ/2p
=DZB/
-----END PGP SIGNATURE-----

[Kevin Wright]

lombok hooks into the compiler, extending Java code to allow some code generation.  So it's not unreasonable to consider Java+Lombok to be a distinct language from Java or even an extension/evolution of Java.

Scala reuses Java syntax as much as possible, changing it where necessary to add functional constructs and type inference.  So it's not unreasonable to consider Scala an extension/evolution of Java.

So comparing Scala to JavaLombokLambdaJ (JLL) is emphatically *not* the same as comparing Scala to Java.

However, if you do compare Scala to JLL, three things stand out:

- JLL is driven by annotations, so it's not a seamless integration that looks like part of the language

- JLL does everything with reflection, adding a performance cost that could be critical in some domains
- You still don't have pattern matching, or type classes, or etc, etc...

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/25/10 10:25 , Kevin Wright wrote:
> lombok hooks into the compiler, extending Java code to allow some
> code generation. So it's not unreasonable to consider Java+Lombok
> to be a distinct language from Java or even an extension/evolution
> of Java.
>
> Scala reuses Java syntax as much as possible, changing it where
> necessary to add functional constructs and type inference. So
> it's not unreasonable to consider Scala an extension/evolution of
> Java.
>
> So comparing Scala to JavaLombokLambdaJ (JLL) is emphatically
> *not* the same as comparing Scala to Java.

This is pretty much philosophy :-) while I think we're discussing how
to practically do things. My point is that Java is a *simple* language
with a reasonable set of extension points to tailor it to people's
needs (and these extension points have been designed purportedly, i.e.
Lombok is not playing any "trick", it's just using a feature -
annotations and compiler extensions - that has been put there for that
purpose). This means that different people can extend Java in
different ways, if they want. Scala has got everything out-of-the-box:
right, that's why I'm saying that it's more *complex*.

>
>
> However, if you do compare Scala to JLL, three things stand out: -
> JLL is driven by annotations, so it's not a seamless integration
> that looks like part of the language

As I said, annotations are a natural part of the language.

> - JLL does everything with reflection, adding a performance cost
> that could be critical in some domains

Lombok doesn't use annotations, but code generation at compile time.
lambdaj is using some reflection and has some performance hit. It's to
be seen how strong it is, in any case, and we can't just decide
without a case study. I'd also argue that complex list filtering that
are performance-critical are probably best to be done in the database,
rather than in the language (e.g. I don't think it's advisable in a
common scenario to load 1,000,000 of persons in memory to pick those
younger than 18). This is just a counter-example, of course.

> - You still don't have pattern matching, or type classes, or etc,
> etc...

Yes. Maybe I don't need them? :-P Seriously, I've said multiple times
that Scala is more powerful. It's to be said if all that
extra-complexity is really needed. I'm still on the side "Less is More".

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx02RoACgkQeDweFqgUGxf4wACfTQ6jUiAUH/nb6Ieu4ccvDg+6
AZsAn1uf0JzS9L7u5wpOb95WBSM7+Vrr
=j3kd
-----END PGP SIGNATURE-----

[Kevin Wright]

I think our principles actually agree here, if not our conclusions.

Scala truly does epitomise the idea that "less is more", a fact that becomes ever-more obvious with repeated exposure to the language :)

Scala is surprisingly small, with many features actually being implemented via the standard library and not as part of the core language spec.

This includes both "big" stuff, like actors, and "small" stuff, like automatic conversion of Ints to Strings

Much of this is made possible by core language features that actually *are* part of the spec: first class functions, case classes, implicits, mixins, operator notation, etc.

So it really, really doesn't have everything out of the box, or rather it has two boxes: the core spec and the standard libs.  It's just that the extension points in the core spec are so good that standard lib stuff can be made to look like it's an internal part of the language.  Better still, you can use the same techniques in your own code - just look at ScalaTest, scalaz or akka to see what's possible.

The only point I will disagree on (in absence of a particular use case):  For *truly* performance-critical code, should you be using a database at all?  The need to serialize/de-serialize everything via a magnetic platter can be a serious bottleneck!

[Viktor Klang]

I think we first need to define "complex", then we need to decide if it's desirable or not.

Complex != complicated

The human body is _really_ complex, but I wouldn't want to trade that to be something less complex, like a piece of wood.

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
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.tumblr.com

[Romain Pelisse]

I'm suprised that nobody notice that this example is pretty much irrelevant (if not plain stupid).

Basically, you can write this in a very small manner in Scala just because list object in Scala has a "partition" method). Most of the extra code in Java is just about code the partition method. If you remove the part regarding coding the partition method, the Java code pretty much look like the Scala code.

A good example would be using the same set of provided functions on Scala and in Java to resolve an issue. 

Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

[Viktor Klang]

On Wed, Aug 25, 2010 at 11:29 AM, Romain Pelisse <bel...@gmail.com> wrote:

I'm suprised that nobody notice that this example is pretty much irrelevant (if not plain stupid).

Basically, you can write this in a very small manner in Scala just because list object in Scala has a "partition" method). Most of the extra code in Java is just about code the partition method. If you remove the part regarding coding the partition method, the Java code pretty much look like the Scala code.

The code behind partition: http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/src//library/scala/collection/TraversableLike.scala#L311

def partition(p: A => Boolean): (Repr, Repr) = {
  val l, r = newBuilder
  for (x <- this) (if (p(x)) l else r) += x
  (l.result, r.result)
}
 

[Romain Pelisse]

The code behind partition: http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/src//library/scala/collection/TraversableLike.scala#L311

def partition(p: A => Boolean): (Repr, Repr) = {
  val l, r = newBuilder
  for (x <- this) (if (p(x)) l else r) += x
  (l.result, r.result)
}

Well, this brings a new twist into it, isn't it ? Clearly this code is shorted than Java - no arguing here, but one could definitely argue that it is more complex than the rather plain Java code we saw on the example...

IMO, I think the question behind is more about culture. If you show the Java example to a C programmer from the 80's he would probably find it difficult to read and understand - as it is right now for people not well versed in Scala to break down this piece of code... 

[Kevin Wright]

I think the one of the points here is that you can never write equivalent APIs.  Many of the operations available on Scala collections will take a function as an argument, the closest that Java can manage is a SAM interface, which very quickly becomes overwhelming when you need to define more than 2 or 3.

[Ben Schulz]

Sure, how about this:

var y = -1; // why the initialization?? so complicated
if(x > 5)
y = x;
else
y = 5;

versus

final int y; // ahh, definite assignment, so simple (*)
if (x > 5) {
y = x;
} else {
y = 5;
}

Then there's the security aspect.

private[yourscopehere] def getRootAccess() = {
// this better not be public
}

I'm sure there's more, but I'm also sure the rules are about to shift
in Scala's favor. Again.

With kind regards
Ben

(*) Generally I would list definite assignment as making Java more
complicated, but sine the code is more concise and closer to the
intent....

On 25 Aug., 08:55, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/

>
> <http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/>I'm
> curious, does anyone have an example of the same problem being solved in
> both Java and Scala, with Java offering the simplest solution?
>
> --
> Kevin Wright
>

> mail/google talk: kev.lee.wri...@gmail.com
> wave: kev.lee.wri...@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda

[Kevin Wright]

It's a better analogy than you think: The active DNA of a tree (call it the spec, or source code, if you wish) is actually larger and more complex than that for a human!

Why?  Because humans (in common with all other warm-blooded creatures) are able to assume that everything will happen at a nice stable temperature, right from the moment of conception.  Plants, on the other hand, need to encode multiple variants of enzymes in order that they can choose one that will operate at the correct rate for any given temperature.  This is not unlike boilerplate.

Humans may well have more essential complexity, but for total (accidental+essential) complexity, the tree definitely takes home the prize.

Make of this what you will :)

[Kevin Wright]

Scala:

val y = Math.max(5,x)

Java:

final int y = Math.max(5,x)

Pretty much the same, except that Java is a tiny bit more verbose, and the Java code would need extra maintenance if you wanted to change x to be e.g. a double.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

[Viktor Klang]

On Wed, Aug 25, 2010 at 12:05 PM, Ben Schulz <ya...@gmx.net> wrote:

Sure, how about this:

var y = -1; // why the initialization?? so complicated
if(x > 5)
 y = x;
else
 y = 5;

versus

final int y; // ahh, definite assignment, so simple (*)
if (x > 5) {
 y = x;
} else {
 y = 5;
}

This is somewhere Java actually beats Scala in terms of chars:

int y = x > 5 ? x : 5;

vs:

val y = if(x > 5) x else 5

But then Scala comes in and wins the day:

val y = 5 max x

Then there's the security aspect.

private[yourscopehere] def getRootAccess() = {
 // this better not be public
}

I'm sure there's more, but I'm also sure the rules are about to shift
in Scala's favor. Again.

With kind regards
Ben

(*) Generally I would list definite assignment as making Java more
complicated, but sine the code is more concise and closer to the
intent....

On 25 Aug., 08:55, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/
>
> <http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/>I'm
> curious, does anyone have an example of the same problem being solved in
> both Java and Scala, with Java offering the simplest solution?
>
> --
> Kevin Wright
>

> mail/google talk: kev.lee.wri...@gmail.com
> wave: kev.lee.wri...@googlewave.com

> 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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Ben Schulz]

Oh my god, it was an example and supposed to illustrate the hypocrisy
of the argument. I even added a footnote.

With kind regards
Ben

> > javaposse+...@googlegroups.com<javaposse%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>

[Viktor Klang]

On Wed, Aug 25, 2010 at 12:43 PM, Ben Schulz <ya...@gmx.net> wrote:

Oh my god, it was an example and supposed to illustrate the hypocrisy
of the argument. I even added a footnote.

Better luck next time. ;)
 

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[B Smith-Mannschott]

On Wed, Aug 25, 2010 at 08:55, Kevin Wright <kev.lee...@gmail.com> wrote:

http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/

I'm curious, does anyone have an example of the same problem being solved in both Java and Scala, with Java offering the simplest solution?

The Scala solution really is nice. I'd be learning Scala if I wasn't busy learning Clojure. Someday, I'll speak both, but for now: http://gist.github.com/549408 , though my solution is perhaps a little code-golfy. 

// Ben

[Kevin Wright]

Yeah, love Clojure

It's definitely elegant, and it's hard to argue against homoiconicity as a desirable quality in any programming language.

OTOH, I'm even more convinced about the benefits of static typing...

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Paul King]

Groovy isn't too bad for this example:

@Immutable class Person { String name; Integer age }

def people = [new Person("Boris", 40), new Person("Betty", 32), new Person("Bambi", 17)]

def (minors, majors) = people.split{ it.age <= 18 }

[minors, majors].each{ println it.join(", ") }

Cheers, Paul.

[Mario Fusco]

IMHO the provided example is too small to be meaningful. It is not
possible to generalize and infer a reliable comparison between two
languages from a so trivial task, so it doesn't prove anything.

More in general, I think yes: scala is more complex than java and
exactly because it is more concise and powerful. I don't understand
why people confuse conciseness with simplicity. Actually it is true
far more often the opposite: do more with less implies that the bigger
thing you do in a lesser verbose way is achived with a more powerful
and then more complex tool.

To give an analogy, I remember one of the most difficult exam I did at
university was theory of signals (I hope the translation from italian
is correct) and the book hadn't more than 200 pages. In the same
period my sister, who is a lawyer, was studying for an exam of ancient
roman right. She had 2 books with about 2000 pages each, but her exam
went far more smoothly than mine. And I don't think (or I am too proud
to admit :) ) that she is more intelligent than me. I hope it is clear
what I mean to say.

So yes, Scala is less verbose and then more complex. And? Where is the
problem with that? I am not scared of complexity and I think the
biggest part of people who do our job isn't scared as well. If I can
trade that complexity with more power, less verbosity and in the end
more productivity I am actually happy of that.

In the end I am sorry, but I have to partially disagree with Fabrizio
when he said that Java has a "reasonable set of extension points to
tailor it to people's needs". I suppose it can be true (maybe) for
Lombok, but my personal experience while developing lambdaj is not on
the same page. I actually had to implement tons of (awful) hacks and
workarounds and that just to obtain a library that works (slowly) only
on a subset of the cases I would have cover.

The current Java situation will probably get even worse with Java 7. I
guess many of the people participating to Java Posse is also
subscribed to the lambda-dev mailing list like me. If so what do you
think about what it is coming along? My personal opinion is that Java
is going to become at least as complex as Scala but only with a small
fraction of the Scala's expressiveness, power and conciseness. If that
is true this is the worst scenario I can imagine: complexity +
verbosity.

Cheers,
Mario Fusco
twitter.com/mariofusco

[Carl Jokl]

Sometimes as the endless debate about relative complexity of different
languages goes on and on and on I just want to bake everyone a cake
made out of smiles and rainbows and we would all eat it and be oh so
happy and get on with our lives... *sigh*

But it is not going to happen is it.

Never mind...back to Grails programming.

[Josh Suereth]

Maybe if it was a delicious pie.... mmmmmmmm pie.

[Reinier Zwitserloot]

I think the idea is that where code in java is equal to or not much
longer than its scala equivalent, the java version wins because java
is simpler to understand. There also some pragmatic concerns, for
example, interopping java 1.1-targeted library code with code written
against java 1.6 isn't all that difficult, whereas writing scala 2.8
and using a library written in scala 1.0 is not going to work very
well.

On Aug 25, 8:55 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/
>

> <http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/>I'm
> curious, does anyone have an example of the same problem being solved in
> both Java and Scala, with Java offering the simplest solution?
>
> --
> Kevin Wright
>

[Reinier Zwitserloot]

Shows pretty much exactly what's wrong with scala, doesn't it? Short,
yes. Complicated? You bet. This partition method is absolutely
horrible. Let's dissect it. Note that I renamed l and r to left and
right for clarity, l looks like a pipe. Also, using 'l' as a variable
name shows someone has taken 'shorter code is better' FAR too
literally. Only a minor nit in this case, as with methods that are
this short, confusion about variable names isn't going to be a big
issue.

> val left, right = newBuilder

Hmm, this is really weird. In java, this would mean "left" is
unassigned and cannot be used until it has been. Apparently in scala
this is short for val l = newBuilder, r = newBuilder. It is NOT
equivalent to val l, r; l = r = newBuilder; either, because clearly l
and r do not end up with the same object reference, but two separate
ones. This is highly confusing to me (read: Not at all what I expected
would happen, I'm only deducing it by starting with the assumption
that this code works). If this is how scala ends up with shorter code,
I don't want it.

> (if p(x) left else right) += x;

In java there's a more or less long-standing hatred of using
assignments, which are legally expressions, as anything but a
statement. i.e. folks frown on this kind of thing: int x = 5 + y = 10;
even though it is technically legit java code. This feels similar,
using the result of an if expression as the target of an assignment.
For example, while its a few characters longer, I find this much more
readable:

if (p(x)) l += x;
else r += x;

Using ifs as expression is a nice gimmick that tends to lead, IMO, to
hard to read code. Just like assignment-as-expression. Yet again, a
source of making your code smaller which only hurts readability (i.e.
nice for code golfing, but a bad idea otherwise). This form of if
statement is of course perfectly legal in java code. The += part of it
is not, but, that's up next:

list += x;

This is where scala shows how complex does equal complicated. In java,
such a statement means either (A) string concatenation, (B) floating
point arithmetic addition, or (C) integer arithmetic addition. I find
the idea that it could mean string concatenation unelegant, but B and
C work together nicely: It's all arithmetic addition. I'd love for
java to add a feature that you can use the + symbol to add up two
BigIntegers or two BigDecimals, as, yet again, its arithmetic
addition. Scala allows operator overloading and started with the best
of intentions (this way the authors of BigInteger and BigDecimal can
fix it themselves!) and screwed it up by now apparently letting "+="
mean list appending. What a silly notion. How the heck does this
improve readability? It only detracts. And you save exactly 3
characters compared to .add(x). Big whoop. This is EXACTLY why some
people think operator overloading causes more trouble than its worth.
For the third time in a row: If this is how scala leads to shorter
code, count me out.


At the same time there are some legitimately nice features here. "val"
is nice, and could easily be added to java, with "final" taking its
role: "final x = 10;" would then be legal and infer 'int' as x's type.
Also, returning tuples is borderline nice, though it does lead to a
suspicious lack of named types. Not that convinced personally about
'last expression is return statement', but that's clearly a purely
stylistic concern. It is, however, worth noting that sticking a return
in front of that really doesn't hurt readability, it might even
improve it, though this is again the shortest possible way you could
go. i.e. Martin Odersky is in love with code golfing, and equating
code golfing to elegant language design seems misguided to me.

Conclusion: Scala will never be the next big thing, because along with
the nice syntactical cleanups, it's falling into the academia trap:
It's been so focused on making such trivial little code snippets look
good at a casual glance, it completely forgot that in practice, code
reading is about trying to make sense of 500kloc filled with obscure
bug fixes, domain specific knowledge, and the occasional WTF code. And
that's not fixable by peddling the old "just hire really good
programmers" spiel. I fully agree with that, but even the biggest
genius has off days. That must be true because even I sometimes look
back at code I wrote a few months ago and get the sudden urge to punch
myself for being such an idiot :P

A language that cleans up a few things without falling into that trap
might fare better but I fear the difference won't be convincing enough
to make folks switch. Crappy catch 22 situation, that.

NB: Also worth considering: No language EVER has become truly gigantic
by offering nice syntax. Instead, the languages that won tended to
offer really crappy syntax but provided something else, not related to
syntax, that caused mass conversion. C did not attempt to abstract
away the bare metal too much but did offer standardization across
platforms. Java brought the garbage collector, very nice (at the time,
at any rate) portable multithreading, and seamless freedom of moving
to different hardware, "seamless" defined as relative to your options
before it came out, all WITHOUT a radical new syntax.

This is why I firmly believe the next big programming language has yet
to be invented, and will involve a similarly crappy syntax, but offers
language-level module systems, language evolvability, AST-based
editing, compiler plugin based DSL enabling, extensive static
analysis, and other such features that aren't intricately involved
with Martin Odersky managing to remove another character from the
partition method.

On Aug 25, 11:39 am, Viktor Klang <viktor.kl...@gmail.com> wrote:

> On Wed, Aug 25, 2010 at 11:29 AM, Romain Pelisse <bela...@gmail.com> wrote:
> > I'm suprised that nobody notice that this example is pretty much irrelevant
> > (if not plain stupid).
>
> > Basically, you can write this in a very small manner in Scala just because
> > list object in Scala has a "partition" method). Most of the extra code in
> > Java is just about code the partition method. If you remove the part
> > regarding coding the partition method, the Java code pretty much look like
> > the Scala code.
>

> The code behind partition:http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/sr...

>
> def partition(p: A => Boolean): (Repr, Repr) = {
>   val l, r = newBuilder
>   for (x <- this) (if (p(x)) l else r) += x
>   (l.result, r.result)
>
>
>
>
>
> }
>
> > A good example would be using the same set of provided functions on Scala
> > and in Java to resolve an issue.
>

> > On 25 August 2010 11:24, Viktor Klang <viktor.kl...@gmail.com> wrote:
>
> >> I think we first need to define "complex", then we need to decide if it's
> >> desirable or not.
>
> >> Complex != complicated
>
> >> The human body is _really_ complex, but I wouldn't want to trade that to
> >> be something less complex, like a piece of wood.
>

> >> On Wed, Aug 25, 2010 at 11:16 AM, Kevin Wright <kev.lee.wri...@gmail.com>wrote:
>
> >>> I think our principles actually agree here, if not our conclusions.
> >>> Scala truly does epitomise the idea that "less is more", a fact that
> >>> becomes ever-more obvious with repeated exposure to the language :)
>
> >>> Scala is surprisingly small, with many features actually being
> >>> implemented via the standard library and not as part of the core language
> >>> spec.
> >>> This includes both "big" stuff, like actors, and "small" stuff, like
> >>> automatic conversion of Ints to Strings
> >>> Much of this is made possible by core language features that actually
> >>> *are* part of the spec: first class functions, case classes, implicits,
> >>> mixins, operator notation, etc.
>
> >>> So it really, really doesn't have everything out of the box, or rather it
> >>> has two boxes: the core spec and the standard libs.  It's just that the
> >>> extension points in the core spec are so good that standard lib stuff can be
> >>> made to look like it's an internal part of the language.  Better still, you
> >>> can use the same techniques in your own code - just look at ScalaTest,
> >>> scalaz or akka to see what's possible.
>
> >>> The only point I will disagree on (in absence of a particular use case):
> >>>  For *truly* performance-critical code, should you be using a database at
> >>> all?  The need to serialize/de-serialize everything via a magnetic platter
> >>> can be a serious bottleneck!
>

> >>> On 25 August 2010 09:49, Fabrizio Giudici <fabrizio.giud...@tidalwave.it

> >>>> Fabrizio.Giud...@tidalwave.it

> >>>> -----BEGIN PGP SIGNATURE-----
> >>>> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

> >>>> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

>
> >>>> iEYEARECAAYFAkx02RoACgkQeDweFqgUGxf4wACfTQ6jUiAUH/nb6Ieu4ccvDg+6
> >>>> AZsAn1uf0JzS9L7u5wpOb95WBSM7+Vrr
> >>>> =j3kd
> >>>> -----END PGP SIGNATURE-----
>
> >>> --
> >>> Kevin Wright
>

> >>> mail/google talk: kev.lee.wri...@gmail.com
> >>> wave: kev.lee.wri...@googlewave.com

> >>> 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 java...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> >>> .

> >>> 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.tumblr.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 java...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > Romain PELISSE,
> > "The trouble with having an open mind, of course, is that people will
> > insist on coming along and trying to put things in it" -- Terry Pratchett
> >http://belaran.eu/
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Kevin Wright]

On 25 August 2010 23:36, Reinier Zwitserloot <rein...@gmail.com> wrote:

I think the idea is that where code in java is equal to or not much
longer than its scala equivalent, the java version wins because java
is simpler to understand.

To whom?  I'm sure a programmer who only knew Lisp, or Haskell, or Scheme, or OCaml, or Scala would have a different opinion on which was easier to understand.  Speaking for myself, I now struggle for a while when attempting to understand code that relies on objects with mutable state, it adds a whole extra level of complexity to my mental model that makes the logic harder to reason about.

 

There also some pragmatic concerns, for
example, interopping java 1.1-targeted library code with code written
against java 1.6 isn't all that difficult, whereas writing scala 2.8
and using a library written in scala 1.0 is not going to work very
well.

It's a fair cop!  And a known problem.

getting binary compatibility sorted is top of the priority list, after the 2.8.1 point release comes out.

 

On Aug 25, 8:55 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/
>
> <http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/>I'm
> curious, does anyone have an example of the same problem being solved in
> both Java and Scala, with Java offering the simplest solution?
>
> --
> Kevin Wright
>

> mail/google talk: kev.lee.wri...@gmail.com
> wave: kev.lee.wri...@googlewave.com

> 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 java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

[Kevin Wright]

On 25 August 2010 23:56, Reinier Zwitserloot <rein...@gmail.com> wrote:

Shows pretty much exactly what's wrong with scala, doesn't it? Short,
yes. Complicated? You bet. This partition method is absolutely
horrible. Let's dissect it. Note that I renamed l and r to left and
right for clarity, l looks like a pipe. Also, using 'l' as a variable
name shows someone has taken 'shorter code is better' FAR too
literally. Only a minor nit in this case, as with methods that are
this short, confusion about variable names isn't going to be a big
issue.

So true, the meaning is instantly obvious with anyone with sufficient brain-cells to be a programmer, and avoids cluttering up the essential logic of the method, which is really what counts here.

 

> val left, right = newBuilder

Hmm, this is really weird. In java, this would mean "left" is
unassigned and cannot be used until it has been. Apparently in scala
this is short for val l = newBuilder, r = newBuilder. It is NOT
equivalent to val l, r; l = r = newBuilder; either, because clearly l
and r do not end up with the same object reference, but two separate
ones. This is highly confusing to me (read: Not at all what I expected
would happen, I'm only deducing it by starting with the assumption
that this code works). If this is how scala ends up with shorter code,
I don't want it.

Again, it must have taken you at least a second to infer the correct meaning from the context.

newBuilder is a function, each of l and r get assigned a value based on calling that function.

What if, instead of `newBuilder` it was `newBuilder()` or something like `builderStack.pop`, what would your intuition then lead you to expect?

I'd argue that Scala's convention is both more logical and practical, not that having different conventions is really a just basis for comparing any two programming languages.

 

> (if p(x) left else right) += x;

In java there's a more or less long-standing hatred of using
assignments, which are legally expressions, as anything but a
statement. i.e. folks frown on this kind of thing: int x = 5 + y = 10;
even though it is technically legit java code. This feels similar,
using the result of an if expression as the target of an assignment.
For example, while its a few characters longer, I find this much more
readable:

if (p(x)) l += x;
else r += x;

Interestingly, I don't.  In the Scala example, I see that we're adding x, it's just a question of what we're adding x to.

In your Java example, I'm seeing that you might add x to l

then a line break

oh, and if not then you'll add x to r

 

Using ifs as expression is a nice gimmick that tends to lead, IMO, to
hard to read code.

and the need to introduce the ?: ternary operator as a workaround because control blocks don't evaluate as an expression.

Is that not more of a gimmick? (with its own section in the language spec)

This whole idea of everything evaluating to a value is deep in the core of Scala, it also applies to pattern matching (like switch statements), if/else blocks, etc.

Even assignment evaluates, but to Unit, which is a bit like void but represents more than just the lack of a method return type.

 

Just like assignment-as-expression.  Yet again, a
source of making your code smaller which only hurts readability (i.e.
nice for code golfing, but a bad idea otherwise). This form of if
statement is of course perfectly legal in java code. The += part of it
is not, but, that's up next:

list += x;

This is where scala shows how complex does equal complicated. In java,
such a statement means either (A) string concatenation, (B) floating
point arithmetic addition, or (C) integer arithmetic addition. I find
the idea that it could mean string concatenation unelegant, but B and
C work together nicely: It's all arithmetic addition. I'd love for
java to add a feature that you can use the + symbol to add up two
BigIntegers or two BigDecimals, as, yet again, its arithmetic
addition. Scala allows operator overloading and started with the best
of intentions (this way the authors of BigInteger and BigDecimal can
fix it themselves!) and screwed it up by now apparently letting "+="
mean list appending. What a silly notion. How the heck does this
improve readability? It only detracts. And you save exactly 3
characters compared to .add(x). Big whoop. This is EXACTLY why some
people think operator overloading causes more trouble than its worth.
For the third time in a row: If this is how scala leads to shorter
code, count me out.

Actually, use of + and += on Lists is deprecated for this very reason.

Why?  because + and += had to do weird things in other places to allow Scala code to behave more like Java, specifically with regards to Java's coercion of objects/primitives to strings when adding them to an existing string.

This led to conundrums such as: Given the existence of an implicit conversion from String to Seq[Char], what does it then mean when you add a Seq[Char] to a String, what's the expected return type?

Sure, there's complexity here, and room for misunderstanding - but it's inherited from Java's Spec, and is a cost of trying to behave like Java as much as possible without good reason to do otherwise.

FWIW, contemporary code now favours the :+ and :+= operators to disambiguate when appending to a list

 

At the same time there are some legitimately nice features here. "val"
is nice, and could easily be added to java, with "final" taking its
role: "final x = 10;" would then be legal and infer 'int' as x's type.
Also, returning tuples is borderline nice, though it does lead to a
suspicious lack of named types. Not that convinced personally about
'last expression is return statement', but that's clearly a purely
stylistic concern.

It's essential when writing in a functional style, with logic being seen as a sequence of transformations and no internal mutation of state.  This isn't just about methods, but about all control blocks.

 

It is, however, worth noting that sticking a return
in front of that really doesn't hurt readability, it might even
improve it, though this is again the shortest possible way you could
go. i.e. Martin Odersky is in love with code golfing, and equating
code golfing to elegant language design seems misguided to me.

This is the same Martin Odersky who designed the Java 1.5 reference compiler, the vast majority of which you are still happily using :)

 

Conclusion: Scala will never be the next big thing, because along with
the nice syntactical cleanups, it's falling into the academia trap:
It's been so focused on making such trivial little code snippets look
good at a casual glance, it completely forgot that in practice, code
reading is about trying to make sense of 500kloc filled with obscure
bug fixes, domain specific knowledge, and the occasional WTF code.

As opposed to what?

Making out code that's 5x longer than it really ought to be, where the true intent is buried in endless loops, preceded by countless identical type declarations, surrounded every side by getter and setter definitions, and maybe implemented inside the single abstract method of some interface, just for good measure.

I'll favour the version where I can clearly see those bug fixes and the domain knowledge, instead of having to trawl through boilerplate for it.

 

And
that's not fixable by peddling the old "just hire really good
programmers" spiel. I fully agree with that, but even the biggest
genius has off days. That must be true because even I sometimes look
back at code I wrote a few months ago and get the sudden urge to punch
myself for being such an idiot :P

A language that cleans up a few things without falling into that trap
might fare better but I fear the difference won't be convincing enough
to make folks switch. Crappy catch 22 situation, that.

NB: Also worth considering: No language EVER has become truly gigantic
by offering nice syntax. Instead, the languages that won tended to
offer really crappy syntax but provided something else, not related to
syntax, that caused mass conversion. C did not attempt to abstract
away the bare metal too much but did offer standardization across
platforms. Java brought the garbage collector, very nice (at the time,
at any rate) portable multithreading, and seamless freedom of moving
to different hardware, "seamless" defined as relative to your options
before it came out, all WITHOUT a radical new syntax.

It's all about concurrency, functional programming, and the practices surrounding FP, is inherently more suitable for being scaled up to massively parallel hardware.  Almost all the design choices you see in Scala are driven by the desire to stay as close to Java as was reasonably possible, whilst also adding full FP support.

 

This is why I firmly believe the next big programming language has yet
to be invented, and will involve a similarly crappy syntax, but offers
language-level module systems, language evolvability, AST-based
editing, compiler plugin based DSL enabling, extensive static
analysis, and other such features that aren't intricately involved
with Martin Odersky managing to remove another character from the
partition method.

How do you feel about just making the method express its intent more cleanly, with less clutter?

There's something far deeper here than mere character-counting...

 

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Josh Berry]

On Aug 25, 6:56 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> NB: Also worth considering: No language EVER has become truly gigantic
> by offering nice syntax. Instead, the languages that won tended to
> offer really crappy syntax but provided something else, not related to
> syntax, that caused mass conversion. C did not attempt to abstract
> away the bare metal too much but did offer standardization across
> platforms. Java brought the garbage collector, very nice (at the time,
> at any rate) portable multithreading, and seamless freedom of moving
> to different hardware, "seamless" defined as relative to your options
> before it came out, all WITHOUT a radical new syntax.

I think it is disingenuous to compare languages today with the likes
of C. Especially when your argument is "C did not attempt to abstract
away the bare metal" and then go to use this to somehow argue for a
language that completely abstracted away the "bare metal" by being a
VM targeted language. (There is something rather amusing about
claiming that Java is somehow the first language that offered portable
anything. Hell, I think SCUMM succeeds at that goal.)

I find it a much more compelling story to say that Java managed to
take the familiarity with C and expose people to non "bare metal"
programming. Once there, people should start to wonder what other ill
conceived notions they could drop, such as "all languages should be
closer to c."

[Russel Winder]

On Wed, 2010-08-25 at 15:56 -0700, Reinier Zwitserloot wrote:
[ . . . ]

> that this code works). If this is how scala ends up with shorter code,
> I don't want it.

Tuple assignment works brilliantly in Python and seems to in Scala as
well. Tuple assignment solves so many problems that lead to clumsy,
often unreadable and incomprehensible code in those languages that do
not support it. You may not want it, but I do.

> > (if p(x) left else right) += x;
>
> In java there's a more or less long-standing hatred of using
> assignments, which are legally expressions, as anything but a
> statement. i.e. folks frown on this kind of thing: int x = 5 + y = 10;
> even though it is technically legit java code. This feels similar,
> using the result of an if expression as the target of an assignment.
> For example, while its a few characters longer, I find this much more
> readable:
>
> if (p(x)) l += x;
> else r += x;

You may do so but I do not, I think it looks truly archaic. And where
has this "hatred of using assignments. . .[as expressions]" in Java come
from, I don't see it, exactly the opposite, there is an increasing use
of expression-based and value-based working.

> Using ifs as expression is a nice gimmick that tends to lead, IMO, to
> hard to read code. Just like assignment-as-expression. Yet again, a

Exactly, in your opinion. In my opinion you are looking back fondly to
the days of assembly language programming. There is a crucial
difference between simplicity of expression and expressivity.
Simplicity of expression is important for readability -- there are
experiments happening to show this, it's not research by expounding
opinion. Similarly there is experimentation to show that having the
simple expression express high-level algorithmic things rather than
low-level algorithmic things leads to faster code writing and easier
maintainability. Again there is experiment, this is not just attempting
to create facts by writing opinion often enough that people think it's
fact. The keywords to search for are "psychology of programming",
"program comprehension", etc., etc.

[ . . . ]

> characters compared to .add(x). Big whoop. This is EXACTLY why some
> people think operator overloading causes more trouble than its worth.
> For the third time in a row: If this is how scala leads to shorter
> code, count me out.

"Some people think": so this could be a very small minority. Just
because Java eschewed operator overloading doesn't make it right.

OK so after a count of three you are counted out. Fine. Let the rest
of us move on and become better programmers by using more modern and
appropriate techniques than you think is good for us.

[ . . . ]

> go. i.e. Martin Odersky is in love with code golfing, and equating
> code golfing to elegant language design seems misguided to me.

Presenting you opinion as though it were fact or even the majority
opinion seems misguided to me. As is attributing opinions to other
people.

> Conclusion: Scala will never be the next big thing, because along with
> the nice syntactical cleanups, it's falling into the academia trap:

So academic is now a synonym for bad. This is what really riles me up,
the implicit view that a language that comes out of academic is of less
value than a language developed in a company.

Programming languages can be developed in companies (C, Java, Go) or in
academia (Lisp, Scheme, Scala) or a mix of both (Fortran, C++, Cobol,
Smalltalk, Self). The important point is that whatever their genesis, a
language has a supportive community and is maintained professionally.

Academics generally have the freedom to be more experimental, certainly
there are more new languages emanating from academia, most of which
rapidly fall by the wayside, but where one catches on, as long as it
performs the transition from academic experiment, to professionally
maintained product that is good and fine. Afterall technology transfer
of ideas from academia into industry and commerce is what most venture
funding is all about.

So can we have less of "academic == bad".

> It's been so focused on making such trivial little code snippets look
> good at a casual glance, it completely forgot that in practice, code
> reading is about trying to make sense of 500kloc filled with obscure
> bug fixes, domain specific knowledge, and the occasional WTF code. And
> that's not fixable by peddling the old "just hire really good
> programmers" spiel. I fully agree with that, but even the biggest
> genius has off days. That must be true because even I sometimes look
> back at code I wrote a few months ago and get the sudden urge to punch
> myself for being such an idiot :P

To be honest you just made the argument for Scala and against Java.

> A language that cleans up a few things without falling into that trap
> might fare better but I fear the difference won't be convincing enough
> to make folks switch. Crappy catch 22 situation, that.

In your opinion. Many other people have a very different opinion. If I
can write what takes 500kloc of Java in 100kloc of Scala, then it is
far more likely that the latter will be more comprehensible and
therefore more maintainable. If it takes 50kloc of Python it is
probably even better.

> NB: Also worth considering: No language EVER has become truly gigantic
> by offering nice syntax. Instead, the languages that won tended to
> offer really crappy syntax but provided something else, not related to
> syntax, that caused mass conversion. C did not attempt to abstract
> away the bare metal too much but did offer standardization across
> platforms. Java brought the garbage collector, very nice (at the time,
> at any rate) portable multithreading, and seamless freedom of moving
> to different hardware, "seamless" defined as relative to your options
> before it came out, all WITHOUT a radical new syntax.

I think you should re-evaluate your knowledge of programming history:

Machine code
Assembly language
Fortran / Cobol / Lisp
Pascal
C
C++ / Smalltalk / Perl
Java / Python

A lot of syntax going on there. Almost all of it related to making a
simple looking statement carry a very large amount of meaning.

> This is why I firmly believe the next big programming language has yet
> to be invented, and will involve a similarly crappy syntax, but offers
> language-level module systems, language evolvability, AST-based
> editing, compiler plugin based DSL enabling, extensive static
> analysis, and other such features that aren't intricately involved
> with Martin Odersky managing to remove another character from the
> partition method.

Point 1, you owe Martin Odersky an apology for the slurs on his
character you have made in this posting.

Point 2, you are describing Scala, Groovy, JRuby on the JVM and Python,
Ruby, D, Go, etc. off it. Well except for the static analysis in Groovy
JRuby, Python, and Ruby. You are making the assumption that statically
compiled programming languages are of more merit than dynamic ones.
This may be your opinion, but I bet the majority of people have a
different one, more along the lines of statically types and dynamically
typed languages both have their place in developing a system.

AST-based editing is a completely different issue. There were systems
doing this available in 1985, but they were not deemed to be appropriate
enough for proper software development environments, everything had to
be files based. So the whole IDE industry rejected exactly that which
was available and they are now having to reconstruct ASTs based on plain
text files. Bizarre.

I had thought of trying to write a shorter reply, but it is too early in
the morning.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Mario Fusco]

I published my opinion on this argument here:

http://java.dzone.com/articles/scala-complex-yes-and

Anyway my advice is mostly to give a look at what Martin Odersky wrote
about this debate:

http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

I guess this could easily become the manifest of the Scala
programmers. His arguments look quite similar to mine, but he
presented them in a less complex and verbose (and somewhat more
enjoyable) way. Could you expect something less from the father of
Scala? :)

[Viktor Klang]

And Haskell is Mindstorms? ;-)

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Casper Bang]

Lego Technic kits are usually from around 9 years and up, so at least
we all agree that Scala is NOT for noobs. :)

On Aug 26, 2:04 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:
> And Haskell is Mindstorms? ;-)
>
>
>
>
>
> On Thu, Aug 26, 2010 at 1:20 PM, Mario Fusco <mario.fu...@gmail.com> wrote:
> > I published my opinion on this argument here:
>
> >http://java.dzone.com/articles/scala-complex-yes-and
>
> > Anyway my advice is mostly to give a look at what Martin Odersky wrote
> > about this debate:
>

> >http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html<http://lamp.epfl.ch/%7Eodersky/blogs/isscalacomplex.html>

>
> > I guess this could easily become the manifest of the Scala
> > programmers. His arguments look quite similar to mine, but he
> > presented them in a less complex and verbose (and somewhat more
> > enjoyable) way. Could you expect something less from the father of
> > Scala? :)
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Reinier Zwitserloot]

I thought you were looking for arguments; I did not know you were just
going to troll java programmers. Not trying to make a low blow here,
but the way you're deflecting every argument, you're not trying to
have an argument at all, this is just a (bad) attempt at trying to win
more souls for scala. I suggest you take a deep breath, a step back,
and refrain from such exercises in the future. You're far more likely
to get three cheers and a pat on the back if you post stuff like this
in a scala oriented forum.

On Aug 26, 1:53 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:

> ...
>
> read more »

[Reinier Zwitserloot]

What's confusing about that? Folks switched from C to java in fairly
large droves, and my entire argument is that this happened not because
java was C with nicer syntax, but because java was very much not C at
all: It did NOT let you program to the bare metal and give you
entirely different features instead.

Scala lets you do everything java does, with slightly nicer syntax.
I'm trying to explain that this is historically not a formula for
creating the next big thing programming language. Scala could of
course be the first language in history to become a 15%er based on
only nice syntax, but that would be rather surprising. (15%er = a
language which, at some point in time, was being used for at least 15%
of all coding going on worldwide. Only a select few languages can make
this claim, and there are usually only 2 at a time. Right now this is
C and java, and you'd have to go back more than a decade to find
another).

[Reinier Zwitserloot]

So, val l, r = newBuilder works because newBuilder is a method, and
this method returns a tuple?

Good lord. I rest my case!

> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net

> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@russel.org.uk
> London SW11 1EN, UK   w:www.russel.org.uk skype: russel_winder
>

>  signature.asc
> < 1KViewDownload

[Viktor Klang]

On Thu, Aug 26, 2010 at 3:10 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

So, val l, r = newBuilder works  because newBuilder is a method, and
this method returns a tuple?

No, that was just misinformation, it is assignment.

scala> val l,r = 5
l: Int = 5
r: Int = 5

scala> l
res0: Int = 5

scala> r
res1: Int = 5

 

Good lord. I rest my case!

I am glad that there are people like you, who are embracing Java as a language to it's full extent.
 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Josh Berry]

On Aug 26, 9:09 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> What's confusing about that? Folks switched from C to java in fairly
> large droves, and my entire argument is that this happened not because
> java was C with nicer syntax, but because java was very much not C at
> all: It did NOT let you program to the bare metal and give you
> entirely different features instead.

I still think this is a wrong history. Java took off in large part
because it was the intro programming class at colleges. It got there
by having a nice corporate backing. To dismiss this, I think, is a
large mistake. Not to mention the joy that was JNI. (I guess still
is.)

> Scala lets you do everything java does, with slightly nicer syntax.

Actually, unless you are taking the "Turing complete" argument, then
there are many things I can do in Scala I couldn't do in Java.
Pattern matching springs to mind rather quickly. Lazy vals, trait
mixins, etc. Can you reproduce the behavior elsewhere? Yeah.
Definitely. Doesn't mean I want to, personally.

> I'm trying to explain that this is historically not a formula for
> creating the next big thing programming language. Scala could of
> course be the first language in history to become a 15%er based on
> only nice syntax, but that would be rather surprising. (15%er = a
> language which, at some point in time, was being used for at least 15%
> of all coding going on worldwide. Only a select few languages can make
> this claim, and there are usually only 2 at a time. Right now this is
> C and java, and you'd have to go back more than a decade to find
> another).

I think the big problem here is that Scala has opened it up so that
learning the language has very little to offer by itself now.
Instead of finding strictly language tricks to solve problems, we are
left with learning the actual abstractions to build solutions. For
myself, I think I am better for learning them. Even if they do have
scary names.

[Oscar Hsieh]

Really??? Then why did not .NET enjoy the same treatment???  Microsoft was much much more powerful than Sun micro   

I agree with Reinier, Java won because it provides much more than just syntax fix.  By having a VM and

garbage collector Java provides a platform that is more secure and less likely to shoot your own foot.  By the way,

I graduate 1997 Java already start to flourish, even my school - one of the best CS in Canada, never teaches Java. 

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Josh Berry]

I think you would be surprised the inroads .NET is making, for one.
Second, it is a lot easier to get people using something they can just
download and start using. This (I believe) is the case with .NET now,
but it has not always been that way. Not by a long shot. (And, even
now, actually deploying a JVM based solution is much much cheaper than
a .NET one.)

> > javaposse+...@googlegroups.com<javaposse%2Bunsu...@googlegroups.com>
> > .

[Casper Bang]

> deploying a JVM based solution is much much cheaper than a .NET one.

But then the cost is just spent on figuring out Java frameworks
instead! The amount of stuff you have to know and master in the Java
ecosystem to get anything done, is mind blowing. I pity all the
architects who put stacks together only to find out a few years later,
that several of the concrete frameworks are now legacy and replaced by
slightly superior ones.

[Kevin Wright]

I think this sums it up nicely:

http://lukewelling.com/2006/08/03/java-programmers-are-the-erotic-furries-of-programming/

Scala clearly belongs at the top of that list, alongside Lisp...

To demonstrate, lets take the list of features suggested for a "next-gen" language

will involve a similarly crappy syntax

Yes, Scala inherits lots from Java, including String coercion, not to mention some truly awful handling of Numbers.

 

offers language-level module systems

Such as Singleton Objects, implicits and type classes?

 

language evolvability

Well... Scala *has* often been criticised for evolving too quickly 

AST-based editing

Ahh, got me on that one!  What you really need is homoiconicity if you're truly passionate about such a goal.

http://en.wikipedia.org/wiki/Homoiconicity

So you'll probably want to be looking at Clojure...

 

compiler plugin based DSL enabling

Not required, most DSLs can be implemented entirely in the language, without a plugin

 

extensive static analysis

Though the tools haven't yet been written, Scala's stronger type system (compared to Java) makes it far more suitable for Static analysis.  In fact, you can encode many concepts in the type system such that the very act of compiling becomes analysis.

 

and other such features that aren't intricately involved with Martin Odersky managing to remove another character from the
partition method.

Such as removing another unjustified and ill-informed insult from an email.

You'll find it very, very hard to critically compare the authors of the Java and Scala compilers here with a clean conscience.

Not least, because they're one and the same.  I'll say it again: "Odersky wrote the Java compiler"

 

--
Kevin Wright

[martin]

On Aug 25, 11:48 am, Romain Pelisse <bela...@gmail.com> wrote:
> > The code behind partition:
> >http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_final/sr...
>
> > def partition(p: A => Boolean): (Repr, Repr) = {

> >   val l, r = newBuilder

> >   for (x <- this) (if (p(x)) l else r) += x
> >   (l.result, r.result)
> > }
>

> Well, this brings a new twist into it, isn't it ? Clearly this code is
> shorted than Java - no arguing here, but one could definitely argue that it
> is more complex than the rather plain Java code we saw on the example...
>
IMO this argument is beside the point. The code was presented as an
answer to the argument that you could write the partition method in
Java, and that therefore the original comparison was unfair. The code
demonstrates that you cannot write generic partition in Java, for
three reasons:

1. Partition takes a closure as argument, which is as of today
unavailable in Java.
2. Partition returns a pair as result (and this pair is decomposed by
a pattern match in user code). Neither is available in Java.
3. Partition resides in a trait so that it can be uniformly reusable
for any Scala collection. Traits are not available in Java either.

So the point is that you could not have written partition with
reasonable syntactic overhead in Java. And that means that the OP's
comparison of Scala's user code

val (minors, adults) = people partition (_.age < 18)

with the longer Java loop is valid. How partition is implemented is
irrelevant. It's like complaining about the code style of the author
of the compiler you are using. And, I accept the argument that
idiomatic Scala does break with quite a few Java conventions; it's not
the same language, after all.

Cheers

-- Martin

[Casper Bang]

> You'll find it very, very hard to critically compare the authors of the Java
> and Scala compilers here with a clean conscience.
> Not least, because they're one and the same.  I'll say it again: "Odersky
> wrote the Java compiler"

OTOH being a great hacker/implementer vs. a great language designer,
requires a very different set of skills. One could almost argue that,
for mass adoption, a language can NOT first and foremost appeal to the
elite. That's kind of what I hear Reinier say, and if that's the case,
I sorta agree with him.

[Kevin Wright]

Which leads to some * very* slippery ground

If followed to a logical conclusion, you seem to suggest that architects are somehow smarter than mere developers, and therefore entitled to develop in a more advanced language.

oops...

I refuse to accept any philosophy that is fundamentally based on the premise that people are stupid

Moreso, I personally believe that programmers are smart enough to be programmers,  if not, then the solution is for them to find a more appropriate career, not to dumb down the entire profession.

What's the alternative, to allow for accountants who can't add numbers?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

Right, this is possible the worst one of all in partition. This must
mean that, translitering to java which we're all presumable a little
more familiar with, that:

List<String> left, right = new ArrayList<String>();

results in 2 separate calls to the ArrayList constructor?

Also, another WTF that came to me later, showing that even this tiny
snippet is not trivial to understand: Am I to assume that "a += b",
where a is a list builder, does not reassign a at all, but is instead
syntax sugar for a.add(b)? The suggestion that in modern scala, :+= is
used is really not an excuse for this bad choice of operator
overloading. The = surely suggests a will get reassigned here, when
that doesn't happen.

It's either that, or newBuilder just returns nil, and this is a
conslist. In which case the terminology "newBuilder" is very strange.

partition is just bad code.

On Aug 26, 3:48 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:

> > sip:russel.win...@ekiga.net <sip%3Arussel.win...@ekiga.net>

> > > 41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@russel.org.uk

> > > London SW11 1EN, UK   w:www.russel.org.ukskype: russel_winder

>
> > >  signature.asc
> > > < 1KViewDownload
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsubscribe@googlegroups .com>
> > .

[Reinier Zwitserloot]

If you think "Pattern Matching" counts as something you can do in
scala but can't in java, I must not have made my argument clear.
That's just syntax sugar. Nice syntax sugar, surely, but syntax sugar
nonetheless. What I'm talking about, is things like:

- do multithreading in a platform independent fashion.
- enjoy the use of a garbage collector.
- compile once then deploy where-ever you feel like it. You can even
switch both the OS and the CPU of your hardware platform without
missing a beat.
- Have at least a halfway workable set of basic libraries to rely on
without futzing about with further downloads, without breaking the
above rules.

These are mostly things C couldn't give you. What feature of this
caliber does scala have that java lacks? Nothing. However, being JVM
targetted does not mean its hopeless. Here are some truly amazing
features that would, I predict, cause programmers to move in droves
and gives you a shot at being the next 15%er language:

- ast based editing.
- built in versioning, of everything, including the language itself.
- pluggable compiler based language.
- AST editing and in general a language that ties the entire
development environment together*

*) Has been done before, but in a walled garden, for-pay, corporate
environment. This traditionally hasn't worked particularly well, and
hasn't produced many 15%ers in history. Also, most implementations I
know of weren't very good. i.e: VB.

[Kevin Wright]

Scala generally tries to "do the right thing"

It's a nebulous concept, of course, but it usually means "do what Java does"

Unless there's a good reason to state that what Java does is just plain wrong, or that it's seriously inconsistent with other goals of Scala

This particular example is interesting, insofar as it meets both criteria :)

Within functional programming, it's generally accepted that functions should be pure.  i.e. that they should always return the same result if given the same input.  If nothing else, it does wonders for unit testing!

Constructors, OTOH, are about as far away as you can get from functional purity

Therein lies the rub!  In order to accept the majority of Java syntax, it's also necessary to sacrifice functional purity, and therefore the elegance and simple reasoning that are natural consequences of the ideal

So yes, the following is potentially confusing:

val left, right = newBuilder

But.. the confusion is perhaps based not so much in the concepts behind FP, as it is in the inherent complexity of methods with side effects (including constructors).  If `newBuilder` was a pure function, then it really wouldn't matter if `left` and `right` were assigned the same value, or the result of two subsequent evocations of `newBuilder`

As is so often the case, the root cause of any possible misunderstanding here can be traced back to imperative code, and to mutability

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Ben Schulz]

Isn't this just as slippery a slope? Why are you not advocating Coq or
some other dependently typed language? Surely all the developers the
world really needs are smart enough to learn them and be productive
with them?

With kind regards
Ben

On 26 Aug., 21:28, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Which leads to some * very* slippery ground
>
> If followed to a logical conclusion, you seem to suggest that architects are
> somehow smarter than mere developers, and therefore entitled to develop in a
> more advanced language.
>
> oops...
>
> I refuse to accept any philosophy that is fundamentally based on the premise
> that people are stupid
>
> Moreso, I personally believe that programmers are smart enough to be
> programmers,  if not, then the solution is for them to find a more
> appropriate career, not to dumb down the entire profession.
>
> What's the alternative, to allow for accountants who can't add numbers?
>

> On 26 August 2010 19:34, Casper Bang <casper.b...@gmail.com> wrote:
>
>
>
> > > You'll find it very, very hard to critically compare the authors of the
> > Java
> > > and Scala compilers here with a clean conscience.
> > > Not least, because they're one and the same.  I'll say it again: "Odersky
> > > wrote the Java compiler"
>
> > OTOH being a great hacker/implementer vs. a great language designer,
> > requires a very different set of skills. One could almost argue that,
> > for mass adoption, a language can NOT first and foremost appeal to the
> > elite. That's kind of what I hear Reinier say, and if that's the case,
> > I sorta agree with him.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to java...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > javaposse+...@googlegroups.com<javaposse%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>

[Ben Schulz]

On 26 Aug., 23:23, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> If `newBuilder` was a pure function, then it really wouldn't
> matter if `left` and `right` were assigned the same value, or the result of
> two subsequent evocations of `newBuilder`

That's only true in a referentially transparent language which,
correct me if I'm wrong, Scala is not.

With kind regards
Ben

[Ben Schulz]

This is actually horribly put. What I mean is that object identity
(which Scala inherits from the JVM) tends to break referential
transparency because two invocations (in the general case) return
different instances of the same value.

With kind regards
Ben

[Josh Berry]

On Aug 26, 4:53 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> If you think "Pattern Matching" counts as something you can do in
> scala but can't in java, I must not have made my argument clear.
> That's just syntax sugar. Nice syntax sugar, surely, but syntax sugar
> nonetheless. What I'm talking about, is things like:

What else is a language, but the niceties the syntax gives you? You
go on to list a ton of features that, yes I can get with Java. But
using them doesn't suck with Scala.

I think the analogies here have been wrong. Instead of comparing to
other tools or toys, why not instruments? The JVM could be something
akin to the guitar. Most people playing it are actually really good
at reading tablature music, but not so much at reading sheet music.
This actually works mostly well, as there is little that I think can't
be written this way. In programming speak, tablature would be the
typical boilerplate that Java requires with a very verbose "your
finger goes here" kind of style.

Some of us, though, want to move beyond tablature. To a place where
we understand the intricacies of the abstractions we have in fact
always been using. Hopefully to the point that we don't have to keep
implementing these abstractions, but can instead simply describe
them. (Instead of saying where the fingers go, as it were, simply
describe what note should be played.)

Does this mean that some people will have to learn more to read what
we wrote? Almost undoubtedly. Just as to read a symphony I would
have to learn to read sheet music. I can not see why this is a
problem. I am not saying that it is beyond anyone. Just that they
may have to learn a few things along the way. Hopefully I'll learn
with them. :)

[Oscar Hsieh]

Gosh .. I am sorry but are you saying that Scala is for the experts and Java for regular people like me???

Do you think that is the good way to promote Scala???  I hope you are wrong otherwise the future

of Scala looks very grim.

And of course a language can give you ALOT MORE than syntax sugar.  Just read Reinier's email

Now I have been trying to avoid Scala vs Java argument for a while but same people keep looking for same 

arguments over and over (its getting really annoyed).  So let me ask you ... why on earth do you people think you need to trash 

Java in order to promote Scala?????  Scala runs on JVM damn it so even Scala does things better

does not mean Java cannot do it.   Boiler plate is not much of a problem when you use something like lombok to

remove most of them.  I am learning Scala at home and at work I use Java and Erlang.  I never feel using one language 

over another can give me that much of an advantage, though the abundance of Java libraries and tools does make difference.

I heard people saying Java is the next cobol or is dead, to me those are just fanboy talks and no offense but I hate any kind of fanboy.

As far as I see Java is still dominating the dev world and will not be changed in the foreseeable future.

By the way, before you think Scala will take over the world someone please fix the tools first.   They suck bad

and please dont tell me tools dont matter unless you want to go back to the stone age.

Sorry Josh, the last paragraph is not targeted you

Kind Regards

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Viktor Klang]

On Fri, Aug 27, 2010 at 9:21 AM, Oscar Hsieh <zen...@gmail.com> wrote:

Gosh .. I am sorry but are you saying that Scala is for the experts and Java for regular people like me???

Do you think that is the good way to promote Scala???  I hope you are wrong otherwise the future

of Scala looks very grim.

And of course a language can give you ALOT MORE than syntax sugar.  Just read Reinier's email

Now I have been trying to avoid Scala vs Java argument for a while but same people keep looking for same 

arguments over and over (its getting really annoyed).  So let me ask you ... why on earth do you people think you need to trash 

Java in order to promote Scala?????  Scala runs on JVM damn it so even Scala does things better

does not mean Java cannot do it.   Boiler plate is not much of a problem when you use something like lombok to

remove most of them.  I am learning Scala at home and at work I use Java and Erlang.  I never feel using one language 

over another can give me that much of an advantage, though the abundance of Java libraries and tools does make difference.

I heard people saying Java is the next cobol or is dead, to me those are just fanboy talks and no offense but I hate any kind of fanboy.

As far as I see Java is still dominating the dev world and will not be changed in the foreseeable future.

By the way, before you think Scala will take over the world someone please fix the tools first.   They suck bad

and please dont tell me tools dont matter unless you want to go back to the stone age.

Sorry Josh, the last paragraph is not targeted you

Hello Oscar,

for me it's all about productivity. I am more productive in Scala and I remain productive in Scala over time.

It's a write less - do more - language for me.

Also, learning Scala made me a better programmer overall, independent of language, because I learned new, different, ways of thinking and different ways of solving problems.

It's not about the language, it's about you - you'll want a language that makes you a better you.
 

[Casper Bang]

> Do you think that is the good way to promote Scala???

It's certainly a very popular approach, although if you want to be
insulted, listen to Ted Neward digressing that there will always be a
need for people flipping burgers.

[Reinier Zwitserloot]

Ah, yes, we've come full circle. Scala fan defends poor language
design choice by saying that it wouldn't have happened if you
programmed purely functional.

Newsflash, Kevin: If you want to stick to pure programming, there are
far better languages than scala out there, such as Haskell or Clojure.
Scala is in my opinion a lot more realistic for a large array of
projects exactly because it gives you decent support for non-pure
programming where its needed.

For example, in this partition example, a pure version could have
_EASILY_ been written using conslists, but I'm guessing partition uses
a listbuilder instead because its significantly faster.

On Aug 26, 11:23 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Scala generally tries to "do the right thing"
> It's a nebulous concept, of course, but it usually means "do what Java does"
> Unless there's a good reason to state that what Java does is just plain
> wrong, or that it's seriously inconsistent with other goals of Scala
>
> This particular example is interesting, insofar as it meets both criteria :)
>
> Within functional programming, it's generally accepted that functions should
> be pure.  i.e. that they should always return the same result if given the
> same input.  If nothing else, it does wonders for unit testing!
>
> Constructors, OTOH, are about as far away as you can get from functional
> purity
>
> Therein lies the rub!  In order to accept the majority of Java syntax, it's
> also necessary to sacrifice functional purity, and therefore the elegance
> and simple reasoning that are natural consequences of the ideal
>
> So yes, the following is potentially confusing:
>
> val left, right = newBuilder
>
> But.. the confusion is perhaps based not so much in the concepts behind FP,
> as it is in the inherent complexity of methods with side effects (including
> constructors).  If `newBuilder` was a pure function, then it really wouldn't
> matter if `left` and `right` were assigned the same value, or the result of
> two subsequent evocations of `newBuilder`
>
> As is so often the case, the root cause of any possible misunderstanding
> here can be traced back to imperative code, and to mutability
>

> ...
>
> read more »

[Reinier Zwitserloot]

If this is your interpretation of what "programming language" means,
then my argument becomes quite a bit simpler:

No programming language has ever become popular because of its
featureset. They lucked into it based on the features of platforms
which peddle that language as preferred language.

Scala is not currently the official primary language for any platform.
Hence, history says it'll never become a 15%er.

Your further music analogy made absolutely no sense to me. Do you not
understand me when I talk about how no truly popular language (>15%
worldwide usage at some point in time) has ever had nice syntax? I
have been highlighting a number of scala syntax features which I feel
are misguided, but that's a different argument altogether: Let's
hypothetically state that Scala syntax is awesome. I'm trying to tell
you that history indicates this does not meaningfully relate to scala
ever becoming a 15%er.

[Kevin Wright]

I'm going to take a tangent here, and open state my reasons for defending Scala so strongly:

1. The majority of Java programmers haven't even heard of Scala, let alone looked at it.  Hopefully a heated debate will encourage people to think "What's all this fuss about..."

2. To break the preconceptions that FP = academic, FP = hard (usually via FP=unfamiliar, unfamiliar=hard), etc.

3. To demonstrate to people who think they can't deal with hard stuff that, actually, wee all do so in Java, every day.  It's so depressing to hear someone say "but it's too difficult, I'm not good enough".  Total nonsense, of course you're good enough!

4. To point out that many quoted examples of FP being difficult are actually examples of mutability and side effects being difficult, it's a refreshing paradigm shift!

5. To drag a lot of smart talented programmers into the beautiful world of FP, kicking and screaming if necessary :)

I wouldn't expect world-class programmers to use inferior tools and techniques, any more than I'd expect an orchestra to be using violins from wall-mart

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

I think Scala has the potential to become a 15% language, by superceeding Java:

• It does everything Java does, usually better, and with less boilerplate
• It can be written very much like Java at first, so the transition is easy
• It adds type inference and closures, the two most heavily demanded features in Java
• Defaults are far closer to currently accepted best practices; public by default, immutability, constructor injection, etc.
• Great support for internal DSLs
• Lots of work is being done on using Scala for concurrency, and our machines certainly aren't getting less concurrent!

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Miroslav Pokorny]

Most of the successful languages of today and yesterday, made it by accident. Who would have thought a language for toasters and similar mini devices would have become the leader in Enterprise (aka Java). Look at PHP, its best described as a mess, but somehow its simplicity seemed to have won a league of followers. Most developers dont know what type inf or closures are, my guess is most people think they sound kool when they say them but dont really know what they are. Its always interesting how most discussions about languages focus on key strokes rather than something a little more concrete, eg defaults - personally i think defaults are evil everything should be explicit.

 Ubiquity and success is not related to being the best. This argument has been demonstrated many times in the past - its VHS vs BETA, left hand v right hand drive cars, in both cases the inferior and unnatural (the later) case lost out

[Fabrizio Giudici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hell, I didn't receive updates from this thread for a couple of days...

I'd like to comment this point from Kevin:

"I refuse to accept any philosophy that is fundamentally based on the
premise that people are stupid"

There's a serious flaw in this statement, and it's the use of the
"stupid" word. It might be intentional or not, but that statement
seems to put the counterpart in an unease position. Indeed, in a
general discussion I would have no problems in replying "well, Kevin,
people are stupid indeed and you're not realistic" :-) but the
discussion would drift off and not converge in any way, because we
can't measure stupidity being a subjective point.

So, I instead re-write the statement to more precisely describe my
philosophy as a Scala skeptic:

"I refuse to accept any philosophy that is fundamentally based on the

premise that people are unexperienced".

Now, experience can be measured and I can safely assert that indeed
most of developers are unexperienced. This is because most of school /
universities don't prepare them, and mostly because corporates don't
spend enough on continuous learning. Developers are the first ones to
agree with this position, expressing their frustration for being
forced to face with problems that they weren't prepared to solve. This
is a fact and if you don't agree, well you're lucky and live in a very
privileged niche of the world.

I think that the very big problem of the Scala community is
evangelism. Independently from the technical merit or demerits of the
language, I'm constantly seeing every try to promote the language
being contextualized in an unrealistic world. It's a sort of reality
distortion field � la Jobs. No big surprise that most people who're in
charge of making decisions in a corporate quit any interest in Scala
after a few minutes of discussion (for instance, this has been my
personal experience a couple of years ago - I don't recall whether it
was JavaOne or Devoxx - after a few of those people that I knew were
attending with me a speech by Odersky). This is confirmed by the
typical evangelism by Odersky, when I read things such as the ones
posted in the blog that Mario referred to. Re: that, I'm just copying
a comment that I posted to Mario's points at Dzone (see below). Until
the Scala community doesn't change the evangelism style they're
following, Scala will stay confined where it is.

I think that Odersky arguments are blatantly biased, as usual. Take
the smartphone example. In the world the choice is not restricted to
the two extrema, a morse equipment and a smartphone. There are many
intermediate phones in the middle, such as those only with a set of
fundamental set of features and a decluttered user interface.

Now, what's a phone for? To call people and speak. Compare two
persons, one enjoying his smartphone and one enjoying his normal
phone, and see them calling a friend. I don't see but marginal
differences in how they place the call; after that, what matters is
what they have to say to their friends (a metaphor for good
architecture and design practices).

Of course, smart users will enjoy the many things that a smartphone
offers. No doubt on that. But they are just a minority. Average users
will instead be confused by the more complex user interface. My
parents - and a lot of other people I know - find it very hard - if
not impossible - to place a call with a smartphone.

Not to say that a big deal of people are buying a smartphone for
fashion, and don't use but a fraction of the features it offers - a
waste of complexity.

So, the smartphone example is perfect for my point: Scala is more
powerful and fit for a minority of experienced programmers that can
handle its complexity; Java is simpler, less powerful and fit for the
average programmer.

- --
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx3i7cACgkQeDweFqgUGxctlwCdGxdmtGvlXb6JHuXsUVjbpOPH
rSoAoICxnD15u1ELKEi169wCAg/mHROU
=3WMh
-----END PGP SIGNATURE-----

[Josh Berry]

On Aug 27, 4:07 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> If this is your interpretation of what "programming language" means,
> then my argument becomes quite a bit simpler:
>
> No programming language has ever become popular because of its
> featureset. They lucked into it based on the features of platforms
> which peddle that language as preferred language.

You could probably go further and say that they lucked into it by
having a really successful implementation carry them forward first.
This doesn't do any good for this conversation, though. (Unless you
think you can argue that you know what they next "from luck"
successful language will look like.)


So... I'm fine dropping the "next successful" language debate. I had
not actually intended on being a part of it, as I think it is a bad
argument to be in. Who cares which is the next fully successful
language? My concern is which language can I be more productive in.

> Your further music analogy made absolutely no sense to me.

I got rushed on the music analogy. Should have held off on posting.

My point is that I am in line with everyone else that says something
to the effect of "scala has made me a better programmer." Yes, there
are some "language" tricks that crop up. But, more than not, I have
simply been exposed to other ways of doing things. Most often, I have
been shown a generalization of something I had been stabbing at myself
for some time.

Usually I can bring these techniques back with me into the land of
Java. Sometimes, I can not. It is akin to learning some fundamental
ideas of music, as best as I can relate it. Sure, you don't need to
know scales and such to play the guitar (or any instrument), but for
many many people it will help. Further, if you are trying to
communicate to someone else such that they can adapt something you
did, learning the core concepts helps a ton. (This feeds in to my
other rant, that it seems we programmers try to share implementations,
not ideas. Seemingly because we think they are one and the same.)

It seems that many people defend Java, not because they actually like
it better, but because they are content "playing by feel and
imitation." (And I don't mean this as an insult. There are many very
good individuals out there working this way.)

[Josh Suereth]

I now know which thread to start a good troll on.  Yay for JavaPosse mailing lists...  Where I find most of my amusement throughout the week.

In any case, It seems like we should just stop arguing and start doing amazing things in our language of choice.   I know I get paid to write applications that are amazing (or at least useful).

- Josh

[Alexey Zinger]

Those are very noble goals, but I think there's a much easier way to promote Scala on the basis of its functional programming merits to Java programmers.  Simply isolate a few examples of Java expressing functional style (easy to find with event-driven stuff), admit that it works, and then show comparable code in Scala that appears more expressive of the intent.  Now the Java people are looking at another language to learn that might have some nice in-roads for certain applications or circumstances.  To close the deal, showcase Java-Scala API interoperability and address performance.  That's all you need.  If people take up the language in a way that they eventually transition to it fully, fine, if not, fine too.  But hearing "Scala is for smart people, Java is for everyone else" or "if you're good enough, you should move to Scala and abandon all your previous work" or whatever else is simply a turn-off.

 

Alexey

---

From: Kevin Wright <kev.lee...@gmail.com>
To: java...@googlegroups.com
Sent: Fri, August 27, 2010 4:22:07 AM
Subject: Re: [The Java Posse] Re: So Scala is too Complex?

[Romain Pelisse]

I also would like to point out that the Java vs Scala debate is quite pointless. 

Scala is Java. It runs on a JVM, the language itself is coded with Java and you can even directly use Java object inside a Scala program.

Opposing Scala to Java is a bit like opposing Java to C. Last time I check, the JVM is coded in C and if you need to do something very low level, you'll use JNDI and you'll write C code.  And with Scala, this is the same. Do you see people comparing C to Java ? No ! Java to C++, perhaps, but here again the scope of C++ does match the one of Java...

C# versus Java, or Python vers Java, OK, but Scala versus Java seems to be pointless. A debates on what Scala *brings* to Java is (I agree) far more relevant...

Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/

[Kevin Wright]

What really gets my goat though... It's the pro-java/anti-scala crowd
who are pushing the claim that "Scala is only for smart people".

Myself, and the rest of the Scala evangelists on this list are going
to great pains to point out that: no, actually, Scala is for everyone.

I don't think that anyone here disagrees about how nasty SAM's are :)

[Reinier Zwitserloot]

I think virtually everybody disagrees with you; SAMs aren't nasty.
Whatever makes you think they are?

On Aug 27, 9:03 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> What really gets my goat though... It's the pro-java/anti-scala crowd
> who are pushing the claim that "Scala is only for smart people".
>
> Myself, and the rest of the Scala evangelists on this list are going
> to great pains to point out that: no, actually, Scala is for everyone.
>
> I don't think that anyone here disagrees about how nasty SAM's are :)
>

> On 27/08/2010, Alexey Zinger <inline_f...@yahoo.com> wrote:
>
>
>
> > Those are very noble goals, but I think there's a much easier way to promote
> > Scala on the basis of its functional programming merits to Java programmers.
>
> > Simply isolate a few examples of Java expressing functional style (easy to
> > find
> > with event-driven stuff), admit that it works, and then show comparable code
> > in
> > Scala that appears more expressive of the intent.  Now the Java people are
> > looking at another language to learn that might have some nice in-roads for
> > certain applications or circumstances.  To close the deal, showcase
> > Java-Scala
> > API interoperability and address performance.  That's all you need.  If
> > people
> > take up the language in a way that they eventually transition to it fully,
> > fine,
> > if not, fine too.  But hearing "Scala is for smart people, Java is for
> > everyone
> > else" or "if you're good enough, you should move to Scala and abandon all
> > your
> > previous work" or whatever else is simply a turn-off.
>
> >  Alexey
>
> > ________________________________

> > From: Kevin Wright <kev.lee.wri...@gmail.com>

> ...
>
> read more »

[Mark Volkmann]

What is a SAM?

On Fri, Aug 27, 2010 at 6:23 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:
> I think virtually everybody disagrees with you; SAMs aren't nasty.
> Whatever makes you think they are?
>
> On Aug 27, 9:03 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>> What really gets my goat though... It's the pro-java/anti-scala crowd
>> who are pushing the claim that "Scala is only for smart people".
>>
>> Myself, and the rest of the Scala evangelists on this list are going
>> to great pains to point out that: no, actually, Scala is for everyone.
>>
>> I don't think that anyone here disagrees about how nasty SAM's are :)

--
R. Mark Volkmann
Object Computing, Inc.

[Josh Berry]

I believe it is Single Abstract Method.  Used as a description for many interfaces.

Typical examples are Runnable, Callable, Predicate, and Function.  We have plenty of others at work, but they are all some form of Function.  Typically the only real difference is number of parameters.  And... likely where they are used.  

It is this walled garden of where they can be used that gets annoying quick.  You wind up with many small utilities to convert one into another such that other logic can be shared.  I believe it is telling that there are utility methods in Functions to convert a Predicate into a Function.  (Or, in Predicates, utilities to make Predicates work with Functions.)  (I should add, Function and Predicate are from the Google Collections.)  An example from Spring would be something like Converter (which is essentially Function, but instead of apply, the method is convert.)

Of course... there could be another SAM.  Acronym finder didn't verify this for me. :(

[Miroslav Pokorny]

Personally i believe people focus too much on the low level bits, like the terseness of a language. I believe there are many more simple things that can make our life as developers easier. We need libraries that have good documentation, fewer dependencies, thorough testing, nice messages when things go wrong, nice interoperability eg closures(whenever Java gets them).

[Eric Jablow]

On Aug 27, 9:47 pm, Josh Berry <tae...@gmail.com> wrote:

> Of course... there could be another SAM.  Acronym finder didn't verify this
> for me. :(
>

A SAM is a surface to air missile, which is very nasty indeed.

Respectfully,
Eric Jablow

[Kevin Wright]

SAM = Single Abstract Method

It's how Java allows you to do stuff (like event handlers) that very clearly need first-class functions, even though the language doesn't have them.

As an example, imagine you want to take all the values in a list of integers, and multiply them by 2

With google collections, this can be done with the Function interface: http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Function.html

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final Function<Integer, Integer> f = new Function<Integer, Integer> {

    public Integer apply(Integer from) {

      return from * 2;

    }

  }

  final List<Integer> result = Lists.transform(myList, f);

That's an awful lot of boilerplate to capture the essential complexity "multiply by 2"

Now imagine that you could use methods as fist-class functions, as Scala does:

  public int multByTwo(int from) { return from * 2; }

  . . .

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final List<Integer> result = Lists.transform(myList, multByTwo);

better already!  and by getting rid of the type parameters, we've also been able use int instead of Integer, so double the benefit.

(of course, auto-boxing will still be happening behind the scenes)

Now take it to the next level, allow for anonymous functions, to be defined inline

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final List<Integer> result = Lists.transform(myList, {int i => i * 2});

Or given that the compiler already knows the type of the list, we could use _ as a placeholder:

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final List<Integer> result = Lists.transform(myList, {_ * 2});

This is already so much tidier than the original, but there's more...

If we're programming in this style, and using a sequence of transformations on immutable lists, then we're going to see that `List<Integer>` type repeated, a lot.  So lets just infer it!  May as well make final the default while we're here:

  val myList = ImmutableList.of(1,2,3);

  val result = Lists.transform(myList, {_ * 2});

Almost there, this immutablity stuff is looking good, so it's probably better to make immutable list the default too:

  val myList = List(1,2,3);

  val result = Lists.transform(myList, {_ * 2});

next, we can get rid of that static method `Lists.transform`, static methods are a hangover from C/C++ anyway, and aren't very good object-orientation.  Instead, we'll add a new method `map` on the List type, this is arguably a better name as it's also the term used in mathematics for the same concept.

  val myList = List(1,2,3);

  val result = myList.map(_ * 2);

finally, to take it all the way to idiomatic Scala, we can use `map` in infix notation, and we'll also get rid of those niggling semicolons

  val myList = List(1,2,3)

  val result = myList map {_ * 2}

and for comparison, here's the original again, using Java with a SAM type:

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final Function<Integer, Integer> f = new Function<Integer, Integer> {

    public Integer apply(Integer from) {

      return from * 2;

    }

  }

  final List<Integer> result = Lists.transform(myList, f);

So yes, SAM types are nasty when compared to the alternative...

> ...
>
> 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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

No, No, No, and more No. This really isn't the thread to explain,
though. You can pop me a private email if you'd like more details.

On Aug 26, 10:54 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> I think this sums it up nicely:http://lukewelling.com/2006/08/03/java-programmers-are-the-erotic-fur...
> Scala clearly belongs at the top of that list, alongside Lisp...
>
> To demonstrate, lets take the list of features suggested for a "next-gen"
> language

>
> will involve a similarly crappy syntax
>
>
>

> Yes, Scala inherits lots from Java, including String coercion, not to
> mention some truly awful handling of Numbers.
>
> > offers language-level module systems
>
> Such as Singleton Objects, implicits and type classes?
>
> > language evolvability
>
> Well... Scala *has* often been criticised for evolving too quickly
>
> AST-based editing
>
>
>
> Ahh, got me on that one!  What you really need is homoiconicity if you're
> truly passionate about such a goal.http://en.wikipedia.org/wiki/Homoiconicity
> So you'll probably want to be looking at Clojure...
>
> > compiler plugin based DSL enabling
>
> Not required, most DSLs can be implemented entirely in the language, without
> a plugin
>
> > extensive static analysis
>
> Though the tools haven't yet been written, Scala's stronger type system
> (compared to Java) makes it far more suitable for Static analysis.  In fact,
> you can encode many concepts in the type system such that the very act of
> compiling becomes analysis.

>
> > and other such features that aren't intricately involved with Martin
> > Odersky managing to remove another character from the
> > partition method.
>

> Such as removing another unjustified and ill-informed insult from an email.

>
> You'll find it very, very hard to critically compare the authors of the Java
> and Scala compilers here with a clean conscience.
> Not least, because they're one and the same.  I'll say it again: "Odersky
> wrote the Java compiler"
>

> --
> Kevin Wright
>

[Cédric Beust ♔]

On Fri, Aug 27, 2010 at 12:03 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Myself, and the rest of the Scala evangelists on this list are going
to great pains to point out that: no, actually, Scala is for everyone.

Of course you realize that for the claim "Scala is for everyone" to be true, everybody needs to say so. And so far, only Scala evangelists do...

--
Cédric

[Kevin Wright]

Just as Java evangelists did when C/C++ was the status quo...

2010/8/27 Cédric Beust ♔ <ced...@beust.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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Josh Berry]

2010/8/27 Cédric Beust ♔ <ced...@beust.com>

How do you feel about this statement, in light of the learning tool Kojo and grade schoolers using it to learn programming?

[Kevin Wright]

*delete as appropriate

I once considered [weight lifting at the gym/learning functional programming]*

but, as I'm a [fairly skinny guy/pure OO programmer]*

I decided that I didn't have any [muscles to build up in the first place/need for pure functions]*

and so it wasn't suitable for me

In fact, I've come to the conclusion that [FP/the gym]* is of limited use, and really wouldn't benefit everyone

And it really is so very difficult, especially for some of my less-capable colleagues!

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Viktor Klang]

On Sat, Aug 28, 2010 at 4:35 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

*delete as appropriate

I once considered [weight lifting at the gym/learning functional programming]*

but, as I'm a [fairly skinny guy/pure OO programmer]*

I decided that I didn't have any [muscles to build up in the first place/need for pure functions]*

and so it wasn't suitable for me

In fact, I've come to the conclusion that [FP/the gym]* is of limited use, and really wouldn't benefit everyone

And it really is so very difficult, especially for some of my less-capable colleagues!

I recently started to go to the gym, was more fun than I had expected, was there 4 hours ago, was nice. Now I do some FP.
 

On 28 August 2010 14:55, Josh Berry <tae...@gmail.com> wrote:

2010/8/27 Cédric Beust ♔ <ced...@beust.com>

On Fri, Aug 27, 2010 at 12:03 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

Myself, and the rest of the Scala evangelists on this list are going
to great pains to point out that: no, actually, Scala is for everyone.

Of course you realize that for the claim "Scala is for everyone" to be true, everybody needs to say so. And so far, only Scala evangelists do...

How do you feel about this statement, in light of the learning tool Kojo and grade schoolers using it to learn programming?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--

[Cédric Beust ♔]

Well, let's ask them: how do these grade schoolers feel about Scala compared to Java?

--
Cédric

[Cédric Beust ♔]

On Sat, Aug 28, 2010 at 5:36 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

  final List<Integer> myList = ImmutableList.of(1,2,3);

  final Function<Integer, Integer> f = new Function<Integer, Integer> {

    public Integer apply(Integer from) {

      return from * 2;

    }

  }

  final List<Integer> result = Lists.transform(myList, f);

So yes, SAM types are nasty when compared to the alternative...

Actually, this is not a SAM example, it's just the way we do closures in Java today.

Here's what  we'll be able to do with the JDK 7:

list.map(#(int n) n * 2)

or

Lists.map(l, #(int n) n * 2)

Regardless of the final syntax, I think the addition of closures in the JDK is a great compromise: adding a feature that a lot of developers feel comfortable with without introducing all the extra baggage that Scala comes with.

--
Cédric

[Kevin Wright]

They tried to start up the interactive Java REPL, so that the languages might be compared, but found that Java didn't have a REPL!  Java was already decided to be too difficult for their junior colleagues at that time, but they pressed on regardless.

Then they tried to rewrite this:

repeat(4) {

  forward(10)

  right()

}

but got confused because repeat isn't a Java keyword, and because it offers no way to define repeat() so it can be used like that, so they had to write it like this after being given a hint about for-loops (and after someone had told them that every line needs a semicolon at the end):

  for(int i=1; i++; i <4);

  {;

    forward(10);

    right();

  };

after a bit of trial and error, they finally got it right, but were seriously becoming frustrated at this point:

  for(int i=0; i < 4; ++i) {

    forward(10);

    right();

  }

but found it difficult to understand why i must start at 0, and why it was even needed!

and didn't know if it worked anyway, because there was another error in the source file, and no REPL...

The experiment was rightly abandoned at this point, it being deemed that pushing the poor kids any further would probably class as emotional abuse. 

2010/8/28 Cédric Beust ♔ <ced...@beust.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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

surely you mean "without taking away all the extra baggage that Scala removes"?

2010/8/28 Cédric Beust ♔ <ced...@beust.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 java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sat, Aug 28, 2010 at 9:09 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

surely you mean "without taking away all the extra baggage that Scala removes"?

Scala certainly removes some extra baggage but it adds quite a bit of its own.

For what it's worth, I think Python is actually a better language to begin because of its lack of compilation and very low syntactic noise.

--
Cédric

[Reinier Zwitserloot]

Two words for you, Kevin:

Java 7.

On Aug 28, 2:36 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> SAM = Single Abstract Method
>
> It's how Java allows you to do stuff (like event handlers) that very clearly
> need first-class functions, even though the language doesn't have them.
>
> As an example, imagine you want to take all the values in a list of
> integers, and multiply them by 2
>

> With google collections, this can be done with the Function interface:http://google-collections.googlecode.com/svn/trunk/javadoc/com/google...
>
> <http://google-collections.googlecode.com/svn/trunk/javadoc/com/google...>

> ...
>
> read more »

[Russel Winder]

Having tried Pascal, C, C++, Scheme, Miranda, Java, Groovy and Python as
introductory programming languages over the years, I can say that of the
languages today for today's audiences Groovy and Python win hands down.

As a second language though C++, D, and Scala are strong contenders.

Python and C/C++/Cython are a very natural combination;
Groovy/Scala/Clojure/Java are a very natural combination.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Kevin Wright]

Python/Jython, Groovy and Clojure are all truly great languages, with Clojure being my favourite of the three.

The only problem for me as that they're dynamically typed, which is the programming equivalent of doing physics without any sort of dimensional analysis (http://en.wikipedia.org/wiki/Dimensional_analysis), or perhaps like having unprotected sex (so, yes, it can be fun too!)

With good inference, static typing really doesn't have to be painful.  Plus you get to keep all the well known benefits in refactoring, etc...

We can actually go one step better than this though, just consider what's even now being achieved with type classes:

The List type has a sum() method; which does the obvious thing

This method will work for any list of Numeric values

It's even possible to define your own type such that it's recognised as being Numeric (e.g. complex numbers)

if you attempt to use the sum method on anything except a list of some Numeric type, it will fail

and it will fail statically, the compiler will throw an error

and yes, all this still happens even in the presence of type erasure (which Scala needs for Java compatibility)

Try *that* with Java 7 :)

[Josh Suereth]

As a "Scala Evangelist?"  I totally understand the love of the Java language and the wish to see it get better.  I feel the same way about Scala.   I don't really think this thread will change anyone's mind at this point.   I'd rather just continue to make awesome software and if it attracts folks to Scala, GREAT! 

In any case, I think we should all focus on our common ground: we all share the Java standard library, let's focus on the important points:   Fix the D**** Date API!!!!   That's something that can happen with or without closure support in JDK 7.  (P.S. I haven't followed the state of the JSR, are they still asking for assistance?).

The unfortunate side-effect of Scala 2.8.0 is that I don't think many Scala users will care much about the Java collections libraries, besides for interoperability reasons.   The new Scala collections provide a lot of power, and will also take some time to get "tuned" and be up to speed, however the programming benefit is pretty astounding.    Closure also has a great set of immutable collections that you can use within closure.   Collections are my most common import in *ANY* project I work on (at google, I do a lot of C++/javascript).   Most of the JVM languages "wrap" the Java Collection library.   They do this to add their language-specific idioms on top of the java collection API and partly for great interoperability with Java APIs.  

Why do I mention all this?   Fragmentation could hurt the overall community to favor one or another.   My call for the future of Scala is that it's going to go down its own path in defining useful, fast, efficient, potentially immutable data structures.   The work done into automagical fork-join collection operations was done using the Scala collections API and would be hard or difficult to use in Java.    How many of these types of innovations are happening in Clojure or Groovy or JRuby or Fantom in such a way that Java (or other languages) cannot make use of them?

The Java community is large, but with the fragmentation happening, it would be good to see a strong leader keep that community together through innovation and modern ideas.   I know in particular I'm a big fan or Functional Reactive Programming.    I'm rather frustrated that .NET has support for this currently and the JVM is lagging (although some Scala folks are working on that). 

So anyway, let's stop bickering about which one is better, and treat it more like a C#/F# pairing (except we have Groovy, which makes us infinitely more cool).   Let's make our platform the best.

- Josh

[Josh Berry]

2010/8/28 Cédric Beust ♔ <ced...@beust.com>

This wasn't really the intent of my question.  I was simply curious if you still feel that Scala "isn't for everyone."  Where the implication seems to be that "not everyone can understand Scala."

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 6:16 AM, Josh Berry <tae...@gmail.com> wrote:

How do you feel about this statement, in light of the learning tool Kojo and grade schoolers using it to learn programming?

Well, let's ask them: how do these grade schoolers feel about Scala compared to Java?

This wasn't really the intent of my question.  I was simply curious if you still feel that Scala "isn't for everyone."  Where the implication seems to be that "not everyone can understand Scala."

Definitely.

I don't see how your observation is relevant to this question because Kojo (which looks awesome, by the way) is basically a reimplementation of Logo in Scala. At the end of a Kojo class, the students still have no idea how to program in Scala.

--

Cédric

[Josh Suereth]

"No idea" eh?  I think that's exaggerated.  They at least know enough Scala to use the Kojo library.   Granted this is probably a very small subset of Scala, but still Scala nonetheless.

One of the things that Scala users love, and may annoy other programmers, is the embedded languages used in code.  "Idiomatic" scala has a few rules associated around it, but often users are defining "DSL"s for their abstractions.  This can turn an API into something rather elegant.   I think it still remains to be seen if this works well for large organizations and how composing these embedded languages works out.

In any case, tools like Lift, Akka, Kojo, etc. all employ certain "micro-languages" within the Scala langauge.   That is one of Scala's greatest strengths.   I think we'll find out if this embedding of DSLs pans out over the next five years.

- Josh

P.S. for those of you who didn't click the link, it's Stanford's Pervasive Parallelism lab and how they choose Scala to host DSLs for parallel computing.  I believe the scala is actually compiled natively, and against their library of C++ parallelism magic.

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

<snip/>

I don't see how your observation is relevant to this question because Kojo (which looks awesome, by the way) is basically a reimplementation of Logo in Scala. At the end of a Kojo class, the students still have no idea how to program in Scala.

--

Cédric

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 8:43 AM, Josh Suereth <joshua....@gmail.com> wrote:

"No idea" eh?  I think that's exaggerated.  They at least know enough Scala to use the Kojo library.   Granted this is probably a very small subset of Scala, but still Scala nonetheless.

Kojo is a small Logo-like programming language + libraries written in Scala. It could have been written in any language and the students wouldn't know or care. You don't even need any of the DSL capabilities offered by Scala to implement it.

--
Cédric

[Kevin Wright]

Go on then... create the DSL in Java

it must be possible to write the following fragment, in a .java file, so that it compiles and is checked by the compiler and continues to look like native syntax:

repeat(4) {

  forward(100);

  right(90);

}

as a concession, I don't expect you to make it work without semicolons, as the Scala version does.

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 9:37 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

Go on then... create the DSL in Java

it must be possible to write the following fragment, in a .java file, so that it compiles and is checked by the compiler and continues to look like native syntax:

repeat(4) {

  forward(100);

  right(90);

}

as a concession, I don't expect you to make it work without semicolons, as the Scala version does.

You're missing the point.

The fact that it's implemented as a DSL in Scala is a neat technical trick that you can't pull off in Java, but Kojo users don't care how you implement it and they certainly don't get more enlightened in Scala because of this trick.

Saying that Kojo teaches you Scala is like saying that programming in Java teaches you C++ because the JVM is written in C++.

--
Cédric

[Josh Berry]

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

Excepting that they can actually use Scala.  Kojo is essentially a magnificently done Scala REPL with some imports, no?  (Maybe I'm entirely off on this.)

[Kevin Wright]

I believe that response is an example of what psychiatrists term "deflection"

The point is that the kids programming in Kojo *are* using Scala.  It maybe a subset, a DSL, call it what you will, but the type-checking, function composition, parsing, etc. rules are all pure Scala.

It's then totally possible (and a very natural progression) for the more advanced students to then break out and use a wider range of built-in scala constructs and libraries.

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 9:57 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I believe that response is an example of what psychiatrists term "deflection"

You are saying that Kojo teaches Scala, I'm disagreeing and I'm giving you what I believe is a sound technical reason for my response. How is that deflection?
 

The point is that the kids programming in Kojo *are* using Scala.  It maybe a subset, a DSL, call it what you will, but the type-checking, function composition, parsing, etc. rules are all pure Scala.

It's then totally possible (and a very natural progression) for the more advanced students to then break out and use a wider range of built-in scala constructs and libraries.

Of couse, but the point is that what is taught in this class is not Scala.

--
Cédric

[Kevin Wright]

Yes, it does teach Scala, for a given value of "teach"

Just as this teaches BASIC:

  10 PRINT "HELLO WORLD!"

  20 GOTO 10

and this teaches LISP (well... after a fashion, it's actually LOGO, but the transition is fairly trivial)

  REPEAT 4 [FD 100 LEFT 90]

Sure, neither of those examples teach the full language, nor do they even capture what many people would feel is the "essence" of their respective languages.  But they are starting points, and we all began somewhere!

The important point, dare I say even the essential and *critical* point here is that these are not examples in some limited walled-garden of a parser, they are true and representative examples from their respective languages, and they are launch pads from which a fledgling programmer might begin to explore the full ecosystem of the language in question.

So in this sense, programming Kojo really *is* programming Scala, and it's doing so in a manner that Java cannot duplicate.

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 10:25 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

Yes, it does teach Scala, for a given value of "teach"

It teaches you a Logo-like language implemented in Scala.
 

But they are starting points, and we all began somewhere!

Absolutely. I bet a lot of us on this mailing-list started with Basic, and we turned out pretty okay despite Basic's alleged deadly flaws, thereby proving that the starting language is not that important as long as it sparks the interest of the student.

So in this sense, programming Kojo really *is* programming Scala, and it's doing so in a manner that Java cannot duplicate.

Of course it can, write the interpreter in Java and give it to the students, they won't be able to tell the difference with the version implemented in Scala.

I understand you really like the fact that Kojo is implemented as a Scala DSL but you need to step back and realize that it doesn't give Kojo users any insight into Scala (Scala is actually only mentioned on one page of the forty-four page documentation and the references simply point the reader to http://scala-lang.org if they want to learn about Scala).

--
Cédric

[Josh Suereth]

On Sun, Aug 29, 2010 at 12:50 PM, Josh Berry <tae...@gmail.com> wrote:

<snip/>

Saying that Kojo teaches you Scala is like saying that programming in Java teaches you C++ because the JVM is written in C++.

Excepting that they can actually use Scala.  Kojo is essentially a magnificently done Scala REPL with some imports, no?  (Maybe I'm entirely off on this.)

Yes, it is a magnificently done REPL, implying that I could use full Scala syntax in KOJO (but possibly at the expense of some of the graphical integration features).  So you could start with the logo DSL and jump into Scala syntax once the kids were ready for it.   Therefore the proof-by-analogy of Java teaching you C++ fails.   You cannot write C++ directly inside Java.   However, Kojo is still Scala, therefore you can write Scala inside "Kojo" (it uses Scala's REPL, not its own implementation which I think is Beust's misconception).

The other side to this is that I could pull Kojo into any Scala project I wanted to, if I really felt like some good turtle graphics were needed.


Once again, I think little is gained arguing this point.   Beust is obviously against Scala.   Reading his blogs, he has some complaints (implicits particularly) that may or may not be justified.   We can argue complexity all we like here, but let's stop focusing on periphery items and focus on the meat of the complaints.


* Scala has implicits.   O NOES C++!  In C++ those lead to lots of needless memcopy and stack allocations and poor programmers doing all sorts of evil.   I'm not so certain these objection hold up in Scala as it has static types.   Haskell also has implicit style magic with type classes, and it seems to have done them well.   Time will tell in Scala.
* Scala has an advanced type system O NOES HASKELL! -> Scala's type system is more powerful than Java's, but at the same time, Java's type system is possible harder to work with if you want to write generic functions.  It appears to focus on making collections easy, but just wait until Java 7 has closures.   Then you'll see the downsides to how Java handles variance.
* Scala allows you to drop syntax, making two expressions equivalent.  O NOES PERL!   While there is a dannger of making things so terse it takes a long time to parse what a function is performing, it also allows most code to become less verbose while still 100% readable.  Part of readability is understanding how a language works, so of course coming from Java to Scala one would think it an unreadable mess of gunk.   You would think the same if you went to Haskell, F# or even Ruby (I know I did).   Unfortunately, this means the true judges of readability are those proficient in a language.   Therefore I think it's pretty futile to make arguments form either side here.
* Scala is for academics.  O NOES ML!   The implicit argument here is that either A) I (The average Java user) am too stupid to use Scala.  I don't think any of us are implying this so it could be B) I can code much easier in Java and keep my productivity high.   It takes me a lot longer to think through a solution in Scala or read through a solution in Scala.   Well the, continue to code in Java.   I think it was about month 3 for me when my abilities to write Scala had gotten to the point where I could more efficiently write/read Scala than Java.   However in a large project with a lot of junk tacked on it (like Spring, Aspects, J2EE or whatever other frameworks you use) this point may never be realised.
Also note that Scala is not really for academics, as some view the innovations in Scala as being purely pragmatic extensions of what they've already accomplished in ML.


In any case, all these complaints are justified.   While I believe that Scala will shine through, it still has some issues to work with regarding each of these points.   Implicits are ever evolving, with a change to how they resolve in 2.8.0 and I think we've yet to see them completely stabilize (although I don't see massive change to their structure in any future).   I also know Implicits have a few issues around them that I'm actively trying to help solve.   As for the rest, well, let's see how long this thread will really get.

[Kevin Wright]

no, No, NO

Kojo is absolutely NOT an interpreter

You can use full power of Scala's syntax and libraries within Kojo, it's an internal DSL

THAT is the *entire* point!

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Josh Suereth]

2010/8/29 Cédric Beust ♔ <ced...@beust.com>

<snip/>

Of course it can, write the interpreter in Java and give it to the students, they won't be able to tell the difference with the version implemented in Scala.

I understand you really like the fact that Kojo is implemented as a Scala DSL but you need to step back and realize that it doesn't give Kojo users any insight into Scala (Scala is actually only mentioned on one page of the forty-four page documentation and the references simply point the reader to http://scala-lang.org if they want to learn about Scala).

--
Cédric

Just to reiterate here;   Kojo is an "embedded' DSL.  It does not have its own interpreter, but uses the standard Scala interpreter.   Therefore you could use "regular" Scala mixed in with Kojo.   Actually, Kojo is pretty much regular Scala, just with all the turtle functions imported into scope.

I've tried to use the BeanShell as a java REPL and I must say that, especially with my comfort in Scala, I'd just open up the Scala REPL now.   Or even the Groovy shell, go Groovy.

[Cédric Beust ♔]

On Sun, Aug 29, 2010 at 11:03 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

no, No, NO

Kojo is absolutely NOT an interpreter

You can use full power of Scala's syntax and libraries within Kojo, it's an internal DSL

THAT is the *entire* point!

I understand that.

This doesn't change the fact that Kojo doesn't teach you Scala.

--
Cédric