Bruce Eckel's blog; first paedagogic Scala intro I've seen

[Casper Bang]

[http://www.artima.com/weblogs/viewpost.jsp?thread=328540]

I'm one of the ones frequently annoyed by the "just use Scala" posts,
but Bruce Eckel's recent blog entry has me thinking perhaps it's the
way to go. Not because I necessarily agree with all of Scala's
philosophies and proponents (frankly I prefer Fantom's pragmatic
viewpoints over Scala's "let's capture everything through an ultra-
capable typesystem"), but because the critical mass now virtually
guarantees it's a good investment for any working programmer who just
wish to move on from Sun legacy.

[Fabrizio Giudici]

Read it... bah. In tutorials everything is simple and clear, if the
writer is skilled. It seems that All The Problems Of The World lie in
parentheses and semicolons. The real world is another thing. The
validation of Scala, if it comes, won't be in tutorials. Critical mass
and good ROI are very relative and still volatile at this point. While
if I look at my situation I'd say that I won't find a single customer to
whom I could sell my hypothetical skills in Scala (but maybe it's
because since I don't know Scala I don't search for Scala customers;
OTOH I seldom have to search for Java jobs, they come spontaneously),
the point is another: I still find lots of things that I don't know that
would give a much greater ROI if I spent some time in learning them.

--
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

[Chris Koerner]

"Indeed, I grew tired of the whole mindset that language design is more important than programmer time; that a programmer should work for the language rather than the reverse. So much so that I thought I had grown out of programming altogether. But now I think I might just have been tired of the old generation of languages and waiting for the next generation -- and especially the forward-thinking around those languages."

I agree with this sentiment.

[Ricky Clarkson]

> While if I look at my situation
> I'd say that I won't find a single customer to whom I could sell my
> hypothetical skills in Scala

To be fair, as a consultant you're probably generally working with
people who are slightly behind the curve. I bet Java 5 and earlier
come up for you too.

[Cédric Beust ♔]

Read it... bah. In tutorials everything is simple and clear, if the writer is skilled. It seems that All The Problems Of The World lie in parentheses and semicolons. The real world is another thing. The validation of Scala, if it comes, won't be in tutorials. Critical mass and good ROI are very relative and still volatile at this point. While if I look at my situation I'd say that I won't find a single customer to whom I could sell my hypothetical skills in Scala (but maybe it's because since I don't know Scala I don't search for Scala customers; OTOH I seldom have to search for Java jobs, they come spontaneously), the point is another: I still find lots of things that I don't know that would give a much greater ROI if I spent some time in learning them.

Same reaction. Bruce seems to like becoming overly enthusiastic for a technology every few years, I'm glad that at least he's recovered from his dynamic typing infatuation :-)

In my experience with Scala, it's hard not to like the language in the first week and it's hard to still be in love with it after reading the 700+ pages of a book about it, and I don't think Bruce's introduction is particularly innovative.

More specifically, showing that you can write "println("Hello world")" in one line compared to Java is pretty underwhelming, especially since there are so many areas where Scala shines over Java.

I think a tutorial that would be much more likely to win over Java developers would be one involving some fairly non trivial OO hierarchy and showing how a judicious mix of traits, genericity and implicits can lead to a much cleaner design than is possible in Java.

-- 

Cédric

[Robert Casto]

Another thing that might help are some ideas about how to incorporate it into existing projects without having to gut the project or start over with a new one. If I have a big website, how do I add some new feature using Scala instead of Java. People still have to maintain old code but if adding Scala to an existing website is possible, then people may be willing to give it a try since the cost to do so is low. If they have to start over, then the cost to try is much larger and thus many will not be inclined to give it a try.

2011/6/12 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.

--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

[Jeb Beich]

After about 10 years of Java development, I found Python and fell in
love. I never really felt comfortable giving up static typing, but I
was really attracted to much of what Python had to offer -- the
language, its community, and its lessons. When I picked up Scala a
year ago, I felt a huge sense of relief in finding something that felt
Pythonic yet retained its static typing and ran on the Java platform.

I was glad to see someone like Bruce express a similar sentiment. I'm
sure it wasn't intended to be a tutorial to Scala. It was merely akin
to similar blog posts comparing languages like Python to languages
like Java.

2011/6/12 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.
>

--
Jeb Beich
http://www.jebbeich.com

[Fabrizio Giudici]

Declaring Java 5 EOL has been extraordinary effective :-) At least for
the customers I've dealt with in the past year (of course, your point
has a general validity) everybody I work with is aligned to Java 6. This
also has to do with the fact that - thanks God - I'm still able to pick
my customers at least partially. I can partition my customer in two
classes, according to a certain perspective: the short-term and
long-term ones. The former class is made of up to one-two weeks of
consultancy and then bye-bye (typically a course or a mentoring). The
latter class is made by customers with whom I've a continuous
relationship - including the "main customer", a single one that I change
after a few years. Currently I'm working with him since three years.
Here my involvement is deeper and related to the products/services under
development. Once every a few months we make some exercise to "inject"
into the development new technologies and practices that we think can be
useful. Most are proposed by me, some by the customer himself. Some are
ways to drop legacy and most aren't beyond "slightly behind the curve",
as Ricky said, others could even be more to the edge - our decisions.
Can't go into details, but there's at least one "leading edge"
technology involved in a prototype. In all of this world, changing
language is not an option, desired or feasible.

[Kevin Wright]

I'm wondering why Scala is seen as being so "scary" from a risk perspective.  After all, at the very core it's just another way of generating bytecode that comes with a support library.

We've been through all this before, Spring does it, Guice does it, XDoclet does it, IDEs can replace coding with menu options to generate code (and in the case of IntelliJ can then hide some of that generated boilerplate), most of the Jakarta projects replace large chunks of the standard library.  Then we also have other projects that replace a focussed subset of the Java library known to be broken (JodaTime, for example).  Or move from JUnit to TestNG and you're again writing some of your logic in XML.

Why, then, should Scala be perceived any differently?  Anyone who has used Hibernate or Spring is *already* using an alternate language to talk to the JVM.  In many cases it's XML, sometimes it's string arguments in annotations - sacrificing type safety, easy refactoring, and a great deal of tool support.

Scala at least has the advantage of generating that code at compile time and with debug symbols, so it already has a big advantage of Spring's runtime-wiring when it comes to coverage testing or static analysis (for example).  Being statically-typed, it also means that you're only ever going to see the refactoring support get better and better over time.

So what is it that people fear about Scala, when they're already so willing to move large chunks of logic into XML?

[Fabrizio Giudici]

On 06/13/2011 11:46 AM, Kevin Wright wrote:
>
> So what is it that people fear about Scala, when they're already so
> willing to move large chunks of logic into XML?

While others are "auxiliary" languages, which are focused on a specific
scope and in the end one could live without them, Scala would be the
primary one. As it has been already said, it's a powerful weapon.
Powerful weapons are good for skilled people, self-destructive for
others. This perfectly explains the dichotomy: Joe, Kevin, Mario and
other skilled people that I know will do excellent things with Scala,
giving it to masses would be a disaster. In a sense, it's not a pitfall
of Scala itself: if the average project was decently managed, a powerful
weapon could be properly managed and controlled. The reason for the huge
success of Java in the industrial world is that it perfectly fits the
average unmanaged project and, while perhaps sacrificing a bit of
productivity, it contains damages (I wrote "contains", not "prevents
from happening"). IMO, until this simple fact isn't well understood, we
won't see any Next Big Language.

[Casper Bang]

> So what is it that people fear about Scala, when they're already so willing
> to move large chunks of logic into XML?

Just for the record, I fear both! :) What I liked about Bruce's intro
(and I am aware of his 2 year cycle i.e. Java, then C#, then Python
and finally Flex before Scala) is that he doesn't go out of his way
trying tp convince the reader that this is the best thing since sliced
bread, and he also acknowledges there's a perceived complexity issue.

So I guess my point is, even if I do find Scala hyperbolish and biting
over a bit too much; the majority of identifiable alpha-geeks that I
track, are moving this way and as a practicing professional, I can not
afford to ignore this.

[Kevin Wright]

On 13 June 2011 11:08, Fabrizio Giudici <fabrizio...@tidalwave.it> wrote:

On 06/13/2011 11:46 AM, Kevin Wright wrote:

So what is it that people fear about Scala, when they're already so willing to move large chunks of logic into XML?

While others are "auxiliary" languages, which are focused on a specific scope and in the end one could live without them, Scala would be the primary one. As it has been already said, it's a powerful weapon. Powerful weapons are good for skilled people, self-destructive for others. This perfectly explains the dichotomy: Joe, Kevin, Mario and other skilled people that I know will do excellent things with Scala, giving it to masses would be a disaster. In a sense, it's not a pitfall of Scala itself: if the average project was decently managed, a powerful weapon could be properly managed and controlled. The reason for the huge success of Java in the industrial world is that it perfectly fits the average unmanaged project and, while perhaps sacrificing a bit of productivity, it contains damages (I wrote "contains", not "prevents from happening"). IMO, until this simple fact isn't well understood, we won't see any Next Big Language.

I find myself pleasantly relieved that we don't live in a world where cooks, carpenters, etc. are forced to use blunt knives for fear that they're not well enough managed and that anyone less than a world-class gourmet chef might cut themselves with a dangerous tool.

Sharp knives are safer and faster.  They're less likely to slip in use, and if you do have an accident with one then the wound will be cleaner and will heal much faster.  They have to be properly taken care of, but I don't think that a poor programmer is any less capable of respecting their tools than a poor cook.

Yes, maybe some of the most vocal proponents of sharp knives *need* such a tool to do something like this: http://j-walkblog.com/images/kumo5.jpg

It's not a valid argument for keeping such knives out of the hands of others though, as they're of benefit if you're after nothing more than: http://www.hudin.com/blog/wp-content/uploads/hudin/969.jpg

[Fabrizio Giudici]

On 06/13/2011 12:25 PM, Kevin Wright wrote:
>
>
> I find myself pleasantly relieved that we don't live in a world where
> cooks, carpenters, etc. are forced to use blunt knives for fear that
> they're not well enough managed and that anyone less than a
> world-class gourmet chef might cut themselves with a dangerous tool.
>
> Sharp knives are safer and faster. They're less likely to slip in
> use, and if you do have an accident with one then the wound will be
> cleaner and will heal much faster. They have to be properly taken
> care of, but I don't think that a poor programmer is any less capable
> of respecting their tools than a poor cook.
>

LOL - but we should realize that unfortunately our profession is
managed, on the average, much worse than cooks, carpenters, etc. People
working in those fields on the average are much better educated and
trained to their jobs that people developing software. Probably this has
to do with the fact that cooks and carpenters don't have to deal with
some large corporates making money on body rental. And a manager in a
restaurant or a carpentry (?) perfectly realizes that the core business
_needs_ properly trained cooks and carpenters or they'll shut down. In
many places IT is not yet seen as a value, thus there are no proper
budgets and people just live by the day.

[Ricky Clarkson]

You've clearly been to different restaurants than I have.

[Josh Berry]

On Mon, Jun 13, 2011 at 7:37 AM, Fabrizio Giudici
<fabrizio...@tidalwave.it> wrote:
> LOL - but we should realize that unfortunately our profession is managed, on
> the average, much worse than cooks, carpenters, etc. People working in those
> fields on the average are much better educated and trained to their jobs
> that people developing software. Probably this has to do with the fact that
> cooks and carpenters don't have to deal with some large corporates making
> money on body rental. And a manager in a restaurant or a carpentry (?)
> perfectly realizes that the core business _needs_ properly trained cooks and
> carpenters or they'll shut down. In many places IT is not yet seen as a
> value, thus there are no proper budgets and people just live by the day.

I find this a frightening view on the situation. Are we really more
poorly educated in programming than in other areas? More accurately
stated, are we really more poorly trained? (I suspect it is an
attempt to replace the later with the former that is the largest issue
here.)

[Kevin Wright]

If anything, we're over-managed.  I know of no other industry that has the same level of obsession with project management, agile, etc. that can be found in Software (Agile & Lean are tacit acceptance of this fact, seeking to reduce process).

The closest you'll find is minimum-wage labourers in manufacturing, endlessly painting the same face on the same doll, or screwing the caps on toothpaste tubes, or some such mindless task.

There are two directions we could take our industry.  One is to empower developers, give them the necessary tools to do the best possible job, tell them broadly what's needed, and just let them get the **** on with it.   The other approach is to go overboard on health and safety, lock up all the sharp tools, and basically relegate ourselves to an assembly line.

Software does not meet this second model, it's a craft and is fundamentally creative.  An assembly-line metaphor is just totally unsuited for the sort of problems we're expected to solve as developers, it's also a self-destructive call for us all to be replaced by robots.  I can't see that actually happening, but it's guaranteed to cause a lot of pain and suffering in the attempt.

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 2:46 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I'm wondering why Scala is seen as being so "scary" from a risk perspective.  After all, at the very core it's just another way of generating bytecode that comes with a support library.

You are missing the point. It's not about being scared of Scala, it's about unwillingness to fix something that's not broken.

Java is not broken. It has weaknesses, like most languages, but not only does it get an amazingly vast array of jobs done, most people who use it actually enjoy programming with it. 

You compare Java with a blunt knife but I think a more accurate metaphor would be trying to replace a perfectly working power drill with one that has more buttons and a different color.

You can't have a revolution if nobody feels the need to pick up a pitch fork.

-- 

Cédric

[Jeb Beich]

Java's a great language, sure. Arguing with that is like calling a
professional athlete a bum and claiming you could do better -- unless
you're a language designer maybe.

But there's no doubting that many, many Java developers are looking
for something different, with some of the qualities that Bruce points
out. For me, after using the functional programming stuff in Python,
it was hard to go back to a language that didn't have it baked in. It
was something I genuinely missed on a daily basis. There are libraries
out there (FunctionalJava, FunctionalJ, etc) that help, but it's just
not the same.

Again, I agree with you that Java's a good language and working with
it is generally a pretty nice experience. But as good as it is,
there's nothing wrong with raising your standards and aiming higher.

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

[Josh Berry]

On Mon, Jun 13, 2011 at 10:41 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> Software does not meet this second model, it's a craft and is fundamentally
> creative.

I agree with this, but I think you understate just how much repetitive
"training" can actually help with producing creative items that are
ridiculously well done. Consider those carvings you linked, I
guarantee you the person that did those (and, ironically, the tomato
cuts) has done more than they can count. The technique isn't learned
in isolation, but by practice. (I think there are countless books and
such on this. Likely mostly horrible, but the point is I'm not trying
to be revolutionary here.) The outcome is highly creative with a lot
of skill, but the technique is likely very rigorous and was
strengthened by training.

That is, you can call them katas or whatever you want, but a short
assembly line constructing things in software could be used to train
skills.

[Josh Berry]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

> You compare Java with a blunt knife but I think a more accurate metaphor
> would be trying to replace a perfectly working power drill with one that has
> more buttons and a different color.
> You can't have a revolution if nobody feels the need to pick up a pitch
> fork.

Meh, I and the majority of people I encounter do feel that Java has
some rather annoying blemishes. For your analogy, it would be
replacing a 6 volt cordless power drill with either a corded or an 18
volt one with a clutch. The difference is staggering. Sure, you can
get by with the weaker one, but you'll likely make less mistakes if
you used the more powerful one.

[Kevin Wright]

I like this analogy, but it's missing a rather important point.  Even if you don't change your tools, you can be quite certain that best practices and the building materials you have to work with *are* going to change over time.  When the standard shifts from wooden joists to reinforced concrete, you can bet your cotton socks that you'll want to trade up that faithful drill of yours for a model with hammer action.

We've entered the era of desktop multi-core, and computing power is now cheap enough that the world and its dog are now doing big data crunching. The paradigm has shifted and building materials have changed; it's time to give up the window putty and get with the double glazing.

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 9:28 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

We've entered the era of desktop multi-core, and computing power is now cheap enough that the world and its dog are now doing big data crunching. The paradigm has shifted and building materials have changed; it's time to give up the window putty and get with the double glazing.

That's another fallacy that I'm planning to address in a future blog post. Well, two fallacies actually:

• The "multi-core era" is a brand new phenomenon that we need to start addressing (it's not new and we've been addressing it for at least a decade in Java).
• Languages that encourage immutability (which Scala doesn't, as we already discussed) or fancy actor-based frameworks are the way out of this mess (remains to be proven, and in the meantime, we have a lot of existing tools that are doing a fine job at that).

-- 

Cédric

[Mario Fusco]

> I still find lots of things that I don't know that would
> give a much greater ROI if I spent some time in learning them.

In my opinion there is an enormous ROI in learning Scala. You're just
looking for it in the wrong place. Let me make an easy example: why do
you spend so much time (I know you do) in configuring your building
tool? Maven comes with some non trivial issues and limitations (the
subject of the last trending topic in the mailing list of the jug of
Milan, to which both of us are subscribed, is "Maven desperation"),
but you spend some effort to learn and put at work it. I don't think
your customers ask for that, so where is the ROI of this effort? The
same applies for your continous integration environment and your unit-
test suite: nobody are asking for them, but you employ those good
practices because you believe that, despite all, they allow you to
make your work safer, faster and with an higher quality.

Now consider Scala. You're right: none of your customer are asking for
it as much as none of them ask for a building tool or a test suite.
However, after I have been working with it for a few months, I can say
that in my experience the typical Scala program is more or less 3
times shorter than the equivalent Java one. In other words, by using
Scala you have to design, write, test, debug, refactor and maintain
only one third of the LOCs. Don't you really see any ROI in it?
Another analogy could clarify (if necessary) my thoughts: just suppose
I could go to a car manufacturer and say I have a technology through
which he could build a given car with only 1,000 components instead of
the usual 3,000 ones. Don't you think he could be very interested in
it? I guess so and of course not because his customers asks for cars
with less components as possible (at least I didn't do that when I was
looking for my car), but because that gives him a big technical
advantage, by allowing to reduce the costs and the possibility of
defects and possibly to hit the market before of his competitors.

This is actually the most valuable type of ROI I can imagine and I
find hard that a wise engineer (in any field) would like to give up to
it.

Cheers,
Mario Fusco
http://twitter.com/mariofusco

[Kevin Wright]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>

Just to re-emphasise: "We've ENTERED [past tense] the era of DESKTOP [as opposed to server] multi-core".  Of course multi-core has been around for ages, it just hasn't been anywhere near as pervasive as it now is.

I'd also like to clarify my definition of "encourages immutability":

- provides immutable implementations of all standard collection types by default, mutable collections require an explicit import

- makes class and method parameters immutable by default, unless explicitly made into a mutable field by way of a keyword

- makes creating an immutable value *at least* as simple as creating a mutable one, forces you to take a conscious decision as to what you want, and makes the distinction clear

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 9:44 AM, Mario Fusco <mario...@gmail.com> wrote:

> I still find lots of things that I don't know that would
> give a much greater ROI if I spent some time in learning them.

In my opinion there is an enormous ROI in learning Scala. You're just
looking for it in the wrong place. Let me make an easy example: why do
you spend so much time (I know you do) in configuring your building
tool?

That's a very interesting example, because in my experience, the build problem is pretty much solved in the Java space while it remains quite immature in Scala. The amount of sbt bitching that happens on a daily basis on irc is quite impressive, with people either trying to make it work the way they want to or simply going back to Maven (not the best choice for Scala, but at least it works as expected).

And there's the fact that Scala is also considerably slower to compile than Java. Yes, you have fewer lines of code in general, but while I haven't run any specific benchmark, my impression is that for build times, the two languages are pretty much on par (happy to be proven wrong or right by some data).

Now consider Scala. You're right: none of your customer are asking for
it as much as none of them ask for a building tool or a test suite.
However, after I have been working with it for a few months, I can say
that in my experience the typical Scala program is more or less 3
times shorter than the equivalent Java one. In other words, by using
Scala you have to design, write, test, debug, refactor and maintain
only one third of the LOCs.

You seem to imply that the size of your tests is directly proportional to the number of lines of code. That seems wrong to me: you test functionalities and you test public API's. The language you use to implement those should not have a dramatic effect on the amount of testing that you need to do.

Scala offers to implement the *same* functionalities in less code. Surely you want to test these functionalities just the same as you do in Java.

 

Don't you really see any ROI in it?
Another analogy could clarify (if necessary) my thoughts: just suppose
I could go to a car manufacturer and say I have a technology through
which he could build a given car with only 1,000 components instead of
the usual 3,000 ones. Don't you think he could be very interested in
it? I guess so and of course not because his customers asks for cars
with less components as possible (at least I didn't do that when I was
looking for my car), but because that gives him a big technical
advantage, by allowing to reduce the costs and the possibility of
defects and possibly to hit the market before of his competitors.

Assuming that these 1,000 smaller components cost less than the 3,000, which is rarely the case in manufacturing. And that they are easy to service, and reliable, and long-lasting, and easy to find, and that you can retrain your workers quickly to understand how they work and how to fix them You need to make a case for all these dimensions of the problem, it's not as simple as saying "1,000 vs 3,000".

-- 

Cédric

[Mario Fusco]

> That's another fallacy that I'm planning to address in a future blog post.
> Well, two fallacies actually:
>

>    - The "multi-core era" is a brand new phenomenon that we need to start

>    addressing (it's not new and we've been addressing it for at least a decade
>    in Java).

Java addresses it in a cumbersome, verbose, difficult to write well
and to maintain way.

>    - Languages that encourage immutability (which Scala doesn't, as we

>    already discussed) or fancy actor-based frameworks are the way out of this
>    mess (remains to be proven, and in the meantime, we have a lot of existing
>    tools that are doing a fine job at that).

All functional languages encourage immutability, and Scala isn't
different in that. Nevertheless Scala, being a multi-paradigm language
allows you even to take the "mutable way" if and when you need it.
That doesn't mean that Scala doesn't encourage immutability.

Moreover actors aren't the only way through which Scala addresses the
parallel programming. An example worth more than thousand words:

https://gist.github.com/1021723

This class (showed by Odersky during the last ScalaDays), given a
dictionary of words, allows to convert a sequence of cyphers in one
(or more) list of words (in the provided dictionary) corresponding to
its phone mnemonic code. It has about 20 real LOCs and I believe it
would be very hard to do the same in Java with less than 200 LOCs. But
this is not the most important point. By using the awesome parallel
collections shipped with Scala 2.9, the only things you need to make
it run in parallel are to change the type of the list of words in the
constructor declaration in the first line:

1. class MnemonicsCoder(words: ParVector[String]) { ...

and add a ".par" in the 25th line:

25. splitPoint <- (1 to number.length).par

That's all! What should you do to make the above mentioned 200 LOCs
Java class to make it work in parallel?
Coming back to the email of Fabrizio Giudici who was wondering about
where is the ROI in using Scala, isn't that an important part of it?

Cheers,
Mario Fusco

[Josh Berry]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

> The "multi-core era" is a brand new phenomenon that we need to start
> addressing (it's not new and we've been addressing it for at least a decade
> in Java).

I'm curious on what are the examples you can think of that do this in
Java in ways that are easily scaled/maintained. I'm not saying you
are wrong, but I'm curious for some examples. (Also, remember that
JVM folks had to go out of their way considerably to speed up such
things as synchronized blocks to be virtually free because of how much
of java is written somewhat blindly to actual concurrency problems.)

> Languages that encourage immutability (which Scala doesn't, as we already
> discussed) or fancy actor-based frameworks are the way out of this mess
> (remains to be proven, and in the meantime, we have a lot of existing tools
> that are doing a fine job at that).

I agree with this to an extent. I think the way out are simpler to
read and logic about implementations of algorithms. I just happen to
think that immutable collections are often easier to logic about than
the mutable counterparts. I confess that my imperative habits often
trip me up.

Also, forget a reliance on actors or immutability. Going back to
Dijkstra's view on gotos "[we should do] our utmost best to shorten
the conceptual gap between the static program and the dynamic process,
to make the correspondence between the program (spread out in text
space) and the process (spread out in time) as trivial as possible," I
can't help but think continuations are going to be the "killer
feature" in the coming concurrency fun. (If I'm not mistaken, C# just
got them.)

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 10:11 AM, Mario Fusco <mario...@gmail.com> wrote:

> That's another fallacy that I'm planning to address in a future blog post.
> Well, two fallacies actually:
>
>    - The "multi-core era" is a brand new phenomenon that we need to start
>    addressing (it's not new and we've been addressing it for at least a decade
>    in Java).

Java addresses it in a cumbersome, verbose, difficult to write well
and to maintain way.

That's subjective, and while I agree with you partially here, the same can be said for Scala code using actors or Akka.

 

>    - Languages that encourage immutability (which Scala doesn't, as we

>    already discussed) or fancy actor-based frameworks are the way out of this
>    mess (remains to be proven, and in the meantime, we have a lot of existing
>    tools that are doing a fine job at that).

All functional languages encourage immutability, and Scala isn't
different in that. Nevertheless Scala, being a multi-paradigm language
allows you even to take the "mutable way" if and when you need it.
That doesn't mean that Scala doesn't encourage immutability.

No, but the fact remains that Scala doesn't intrinsically encourage immutability. Here is what I wrote a few months ago:

Mmmh, I thought we went over this already:  Scala "the language" doesn't offer much more in terms of immutability than Java. Classes are mutable by default (you can even make case classes mutable if you want), variables are not "val" by default, methods can modify fields without any ceremony, etc...

Mutable support in Scala comes much more from the libraries and developer discipline than the language itself (nothing wrong with that, by the way, it's one of the pragmatic aspects of Scala that I appreciate).

 

By using the awesome parallel
collections shipped with Scala 2.9, the only things you need to make
it run in parallel are to change the type of the list of words in the
constructor declaration in the first line:

1.  class MnemonicsCoder(words: ParVector[String]) { ...

and add a ".par" in the 25th line:

25. splitPoint <- (1 to number.length).par

Personally, I think that this claim is going to haunt Scala for many years.

First of all, I've read the article that led to the parallelization effort and I think it's a brilliant piece that dives very deep in trying to isolate and identify how to make collections parallelizable. Very nice research work.

Now: yes, adding ".par" will magically make your collection go parallel but I think people will soon start realizing that it takes much more than that to actually leverage parallelism, and in particular, they will learn the hard way that unless your data forms a group under the operation you pass, parallelism will not only "not work", it will actually return a different value every time.

In other words, I have the feeling that there are very few cases where adding ".par" will provide a big performance boost, and I feel uneasy whenever I see this new feature being sold as such a silver bullet because there is no way it will live up to its expectations.

-- 

Cédric

[Ricky Clarkson]

[this is a reply to three people, sorry if it looks like I'm misquoting]

Scala is slower to compile because the compiler has more work to do,
because the programmer has less work to do.

That said, SBT does seem to make the difference in compile speed
disappear, though I haven't tried it in the large yet. I don't think
Scala has any pathological compile times (i.e., programs that take a
disproportionate amount of time or memory to compile), it's just a bit
slower than Java.

People are always bitching about maven too, but in general in #scala
we have more experience with maven than with SBT. If you went back 2
years you'd see a lot more moaning about maven, at least from me!

> All functional languages encourage immutability, and Scala isn't
> different in that.

Scala isn't functional. It's a hybrid. Saying it's functional
without mentioning the other half is like those adverts saying that an
oven costs <font size="infinitessimal">from</font> £200.

Most importantly, Scala gives you no way of visually or even
programmatically distinguishing functional from imperative code. But
then it probably couldn't while maintaining its excellent level of
Java interoperability.

> Also, forget a reliance on actors or immutability. Going back to
> Dijkstra's view on gotos "[we should do] our utmost best to shorten
> the conceptual gap between the static program and the dynamic process,
> to make the correspondence between the program (spread out in text
> space) and the process (spread out in time) as trivial as possible," I
> can't help but think continuations are going to be the "killer
> feature" in the coming concurrency fun. (If I'm not mistaken, C# just
> got them.)

Sweet Jesus, I think I need a syntax-highlighting email client to see
which parts of that were written by Dijkstra and which were written by
you! :)

[Josh Berry]

On Mon, Jun 13, 2011 at 1:36 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
>
> Sweet Jesus, I think I need a syntax-highlighting email client to see
> which parts of that were written by Dijkstra and which were written by
> you! :)

Yeah, apologies on that. i had meant to redo it as a block quote but
hit send before retouching that section. :( Only part that is
relevant, I want to use continuations, badly. :)

[Kevin Wright]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>

On Mon, Jun 13, 2011 at 10:11 AM, Mario Fusco <mario...@gmail.com> wrote:

> That's another fallacy that I'm planning to address in a future blog post.
> Well, two fallacies actually:
>
>    - The "multi-core era" is a brand new phenomenon that we need to start
>    addressing (it's not new and we've been addressing it for at least a decade
>    in Java).

Java addresses it in a cumbersome, verbose, difficult to write well
and to maintain way.

That's subjective, and while I agree with you partially here, the same can be said for Scala code using actors or Akka.

 

>    - Languages that encourage immutability (which Scala doesn't, as we

>    already discussed) or fancy actor-based frameworks are the way out of this
>    mess (remains to be proven, and in the meantime, we have a lot of existing
>    tools that are doing a fine job at that).

All functional languages encourage immutability, and Scala isn't
different in that. Nevertheless Scala, being a multi-paradigm language
allows you even to take the "mutable way" if and when you need it.
That doesn't mean that Scala doesn't encourage immutability.

No, but the fact remains that Scala doesn't intrinsically encourage immutability. Here is what I wrote a few months ago:

Mmmh, I thought we went over this already:  Scala "the language" doesn't offer much more in terms of immutability than Java. Classes are mutable by default (you can even make case classes mutable if you want), variables are not "val" by default, methods can modify fields without any ceremony, etc...

Mutable support in Scala comes much more from the libraries and developer discipline than the language itself (nothing wrong with that, by the way, it's one of the pragmatic aspects of Scala that I appreciate).

 

It's true, Scala doesn't enforce immutability, nor does it force you to work via an IO Monad, Haskell style (though the planned effect system should allow you to selectively enforce immutable object in libraries, etc.).  Then again, nobody has ever claimed that Scala enforces immutability, the term "encourages" was carefully chosen.

By the same token, Java doesn't enforce mutability, it simply encourages it by making immutability verbose and cumbersome.

For example, values are not `val` by default, they're either `val` or `var` - this is an explicit choice that a you *have* to make.  There's a world of difference between this and the ease with which you can simply forget to leave off the `final` keyword in Java.  I'd be very curious to know exactly how consistent you are with marking even your method arguments as final, it's just oh-so-easy to leave out because it clutters up the code...

If immutable defaults (in params and collections) and forcing you to _think_ about mutability aren't "encouragement", then I'm at a loss to find an alternative term which better describes Scala's approach of constantly nudging developers in the right direction.

 

By using the awesome parallel
collections shipped with Scala 2.9, the only things you need to make
it run in parallel are to change the type of the list of words in the
constructor declaration in the first line:

1.  class MnemonicsCoder(words: ParVector[String]) { ...

and add a ".par" in the 25th line:

25. splitPoint <- (1 to number.length).par

Personally, I think that this claim is going to haunt Scala for many years.

First of all, I've read the article that led to the parallelization effort and I think it's a brilliant piece that dives very deep in trying to isolate and identify how to make collections parallelizable. Very nice research work.

Now: yes, adding ".par" will magically make your collection go parallel but I think people will soon start realizing that it takes much more than that to actually leverage parallelism, and in particular, they will learn the hard way that unless your data forms a group under the operation you pass, parallelism will not only "not work", it will actually return a different value every time.

In other words, I have the feeling that there are very few cases where adding ".par" will provide a big performance boost, and I feel uneasy whenever I see this new feature being sold as such a silver bullet because there is no way it will live up to its expectations.

Possibly.  Though I don't get the impression that anyone thinks of .par as a silver bullet.  It's simply another very powerful and easy tool that's of great use to a developer once they've already understood the necessary paradigms for dealing with parallelism.

[Kevin Wright]

You do know that Scala's had delimited continuations since 2.8, right?

[Josh Berry]

On Mon, Jun 13, 2011 at 1:53 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
>> Yeah, apologies on that.  i had meant to redo it as a block quote but
>> hit send before retouching that section.  :(  Only part that is
>> relevant, I want to use continuations, badly. :)
>
> You do know that Scala's had delimited continuations since 2.8, right?

Right. I don't yet get to use Scala at work. :) I'm just making sure
they are considered when any of the concurrency stuff comes up. I
think they provide a ton more benefit than they are often given credit
for.

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 10:49 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

I'd be very curious to know exactly how consistent you are with marking even your method arguments as final, it's just oh-so-easy to leave out because it clutters up the code...

I hardly ever use final in my code, because the kind of immutability it enforces is not very useful in practice.

-- 

Cédric

[Mario Fusco]

> People are always bitching about maven too, but in general in #scala
> we have more experience with maven than with SBT.  If you went back 2
> years you'd see a lot more moaning about maven, at least from me!

For what I read in the forums and mailing-lists I am subscribed to,
people are *still* bitching about maven far more than about sbt.

> > All functional languages encourage immutability, and Scala isn't
> > different in that.
>
> Scala isn't functional.  It's a hybrid.  

It seems to me I wrote exactly the same in the sentence after the one
you quoted: "Nevertheless Scala, being a multi-paradigm language

[Cédric Beust ♔]

Note: you quoted two different people in your message below, please try to preserve who is saying what.

-- 

Cédric

[Ricky Clarkson]

Two people, but they were both me.

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

[Fabrizio Giudici]

For what concerns me, I declare final everything that I can. There must
be less than five non final method arguments in several hundred
thousands lines of code.

For what concerns Mario's points, I'm going to answer in a different
thread - in fact, I think we'd rather reason at a different level (thus
a different subject).

[Cédric Beust ♔]

2011/6/13 Fabrizio Giudici <fabrizio...@tidalwave.it>

On 06/13/2011 07:58 PM, Cédric Beust ♔ wrote:

On Mon, Jun 13, 2011 at 10:49 AM, Kevin Wright <kev.lee...@gmail.com <mailto:kev.lee...@gmail.com>> wrote:

   I'd be very curious to know exactly how consistent you are with
   marking even your method arguments as final, it's just oh-so-easy
   to leave out because it clutters up the code...


I hardly ever use final in my code, because the kind of immutability it enforces is not very useful in practice.

For what concerns me, I declare final everything that I can. There must be less than five non final method arguments in several hundred thousands lines of code.

To each their own, I guess.

My argument is that I can hardly remember last time I was bitten by a bug because I reassigned a variable wrongly (or even, I reassigned a variable, period). In contrast, the noise introduced by using `final` everywhere is as annoying to me as Python saying `self` every other word, so overall, the trade-off is not worth it.

-- 

Cédric

[Ricky Clarkson]

Final can also tell you when you neglected to assign to a variable
(specifically a field). I think that's a less subjective advantage.

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

[Josh Berry]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

> My argument is that I can hardly remember last time I was bitten by a bug
> because I reassigned a variable wrongly (or even, I reassigned a variable,
> period). In contrast, the noise introduced by using `final` everywhere is as
> annoying to me as Python saying `self` every other word, so overall, the
> trade-off is not worth it.

I've had this argument at work several times. We have a style guide
saying that you must make all parameters final. I'm not against it,
per se, but I do think it is silly to think that it prevents mistakes
in most places. (Now, fields, I'm all for making final and curse gwt
whenever I realize I have to stop doing so.)

[Marcelo Fukushima]

Where i work, we dont use final on arguments but have checkstyle rules against reassigning method arguments

[Fabrizio Giudici]

On 06/13/2011 10:44 PM, Cédric Beust ♔ wrote:
>
> To each their own, I guess.
>
> My argument is that I can hardly remember last time I was bitten by a
> bug because I reassigned a variable wrongly (or even, I reassigned a
> variable, period). In contrast, the noise introduced by using `final`
> everywhere is as annoying to me as Python saying `self` every other
> word, so overall, the trade-off is not worth it.

Indeed I was backing your point, not Kevin's :-) My style is more for
symmetry reasons (I hate to see a dangling "final" on single parameters
that require it, e.g. because of a inner class, and not others, so I put
it everywhere). I reckon that this could not be liked by many:
aesthetics is subjective. And I agree that I've hardly see a bug because
of a non final stuff: it's object immutability that matters. So, in the
end, I'd appreciate a language where 'final' is default, or less
verbose, but I don't see as changing my life: in the end, if you want to
use 'final' everywhere in Java you can and doesn't cost much.

[Fabrizio Giudici]

On 06/13/2011 10:56 PM, Ricky Clarkson wrote:
> Final can also tell you when you neglected to assign to a variable
> (specifically a field). I think that's a less subjective advantage.

But static analysis can tell you that.

[Ricky Clarkson]

Yes, and that static analysis is done by the compiler, only if you add 'final'.

Optional static analysis is pretty hard to apply to a project
retrospectively. It's better if you can make invalid code fail
compilation.

[phil swenson]

> Java is not broken. It has weaknesses, like most languages, but not only
> does it get an amazingly vast array of jobs done, most people who use it
> actually enjoy programming with it.

Java isn't broken in the same way C isn't broken. It's more of a PITA
than it should be. It's unnecessarily clunky. But it's ubiquitous,
so that trumps any broken-ness.

I for one find it irritating coding in Java after spending some time
doing Ruby or Groovy. But fact is Java pays a lot better and is much
more widely used, so it's my main language.

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:
> On Mon, Jun 13, 2011 at 2:46 AM, Kevin Wright <kev.lee...@gmail.com>
> wrote:
>>
>> I'm wondering why Scala is seen as being so "scary" from a risk
>> perspective.  After all, at the very core it's just another way of
>> generating bytecode that comes with a support library.
>
> You are missing the point. It's not about being scared of Scala, it's about
> unwillingness to fix something that's not broken.
> Java is not broken. It has weaknesses, like most languages, but not only
> does it get an amazingly vast array of jobs done, most people who use it
> actually enjoy programming with it.

> You compare Java with a blunt knife but I think a more accurate metaphor
> would be trying to replace a perfectly working power drill with one that has
> more buttons and a different color.
> You can't have a revolution if nobody feels the need to pick up a pitch
> fork.

> --
> Cédric

[Cédric Beust ♔]

On Mon, Jun 13, 2011 at 7:01 PM, phil swenson <phil.s...@gmail.com> wrote:

> Java is not broken. It has weaknesses, like most languages, but not only
> does it get an amazingly vast array of jobs done, most people who use it
> actually enjoy programming with it.

Java isn't broken in the same way C isn't broken.  It's more of a PITA
than it should be.  It's unnecessarily clunky.  But it's ubiquitous,
so that trumps any broken-ness.

I for one find it irritating coding in Java after spending some time
doing Ruby or Groovy.

This is precisely my point: Java annoys you because you have programmed in other higher level languages. Replace Ruby or Groovy with Scala, Fantom, Gosu or whatever your language of choice is.

You need to realize that very, very few Java programmers have done that. Most of them come from a C/C++ background and for a growing number of developers, Java is the very first language they learned. Most of these people don't know much else beyond it.

Also, don't make the mistake of thinking that all you need to do is expose them to another language and they will automatically start disliking Java. If the current trends I read today area any indication, there is at least as many people liking Scala as people who tried it and decided it wasn't for them. Groovy seems to be getting a bit more consistent positive reviews from Java developers, probably because it's more focused on addressing Java's weaknesses and sticking to that goal than Scala is.

You will receive a lot less hostility from Java programmers about Java than you would asking C++ programmers about C++ ten or fifteen years ago (to be fair to C++; I am assuming the animosity toward C++ is even greater today than it was back then).

-- 

Cédric

[Roland Tepp]

just as a side-note.

Having had a pleasure to use both Galil automatic rifle and M16 and having taken both of them apart as part of my compulsory military training I can only say that given a choice I'd prefer Galil (or in fact any AK74 remake) over much more complex M16.

AK74 has deliciously simple design with only a handful of quite large moving parts, which makes it highly reliable and extremely easy to maintain even in most unfavorable of circumstances.

M16 operation mechanism seemed overly too complex in comparison and had many moving parts, some of which were quite small. 

Undoubtedly M16 has proven itself to be quite a versatile weapon and good piece engineering, but just for maintainability, AK models (and in particular Galil) are just pure work of genius and as I mentioned above, given a choice I'd prefer Galil over M16 any day (well ... except for weekends maybe, when I generally do stuff for fun...)

[Roland Tepp]

By the way,

Although the Java crowd does not generally like to be reminded of The Other VM and their Evil Overlord's doings, I had a somewhat fortunate opportunity to dip my hand into the C# world and while I was aware of Scala 2.9 efforts on parallel collections, I also heard about ongoing work for C# on parallelism. They already have parallel collections, parallel for loops, parallel LINQ, and so on.

http://msdn.microsoft.com/en-us/library/dd460717.aspx

And from all that I have heard, the parallelism related work has really caught on in .NET, so you don't really have to look into the future to see what can parallel arrays do for your concurrency needs...

[Kevin Wright]

2011/6/14 Cédric Beust ♔ <ced...@beust.com>

The problem here is that different comparisons are being made, in most cases the languages considered have different strengths:

C vs C++ - Valid C will directly compile as C++, so developers don't *need* to change anything, C also has an advantage in terms of efficient memory use and potential for low-level optimisation, frequently making it the language of choice for microcontrollers and similar resource-limited environments.

C++ vs Java - C++ is richer and more suitable for optimising, it gives you far better control over memory usage and supports lambdas, it also doesn't need a VM.  C++ is therefore better for systems-level programming and scientific applications.  Java can get you to market far faster, it's easier to write, test and debug, it's also immune to many errors that are possible in C++ and has a massive open-source ecosystem - making it ideal for applications programming and web services.

Java vs Groovy - Java's static typing offers better performance and trapping certain errors at compile time, making it faster, safer, and easier to refactor.  Groovy offers some significant improvements over Java's syntax which massively simplifies a lot of programming tasks.

Java vs Scala - Scala is statically typed and can do everything Java can (with a few minor exceptions) , emitting very similar bytecode being emitted.  It's more object oriented and also adds functional constructs as well as adding a bias towards immutability.  Java is incumbent and has checked exceptions.

The key difference here is that there are clear technical reasons for favouring C over C++, C++ over Java or Java over Groovy.  The arguments for using Java over Scala seem to be primarily social or political in nature.

[Josh Berry]

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

> You need to realize that very, very few Java programmers have done that.
> Most of them come from a C/C++ background and for a growing number of
> developers, Java is the very first language they learned. Most of these
> people don't know much else beyond it.

I've actually found that the majority of Java developers have never
touched another language. Those that have, I agree have likely done
C/C++, but they have been the minority for a while now. Seems that
those that switched from anything to Java are willing to switch away,
as well.

[Kevin Wright]

That's just depressing... While it may be impossible to mandate what's self taught, there really should be a good cross-section of paradigms covered in comp.sci courses for anyone who studies the subject formally.

Scheme, Haskell, Prolog, Erlang, Smalltalk & C all have something important and unique to offer here. With those under your belt, you'd be well equipped to handle any other language currently in production use.

[Josh Berry]

On Tue, Jun 14, 2011 at 9:29 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> That's just depressing... While it may be impossible to mandate what's self
> taught, there really should be a good cross-section of paradigms covered in
> comp.sci courses for anyone who studies the subject formally.

Well, major caveat on this as it is just my observation. I'm
welcoming numbers showing I'm wrong. I just know that a lot of the
developers I work with shy away from even doing SQL.

> Scheme, Haskell, Prolog, Erlang, Smalltalk & C all have something important
> and unique to offer here. With those under your belt, you'd be well equipped
> to handle any other language currently in production use.

Also, I must confess that until recently I didn't have much experience
outside of Java. I've started trying to read up on a lot of topics in
the past few years and really take stock in some of the things I was
exposed to earlier, but never really used.

[phil swenson]

So what triggered the mass adoption of Java?

2011/6/13 Cédric Beust ♔ <ced...@beust.com>:

>
> This is precisely my point: Java annoys you because you have programmed in
> other higher level languages. Replace Ruby or Groovy with Scala, Fantom,
> Gosu or whatever your language of choice is.
> You need to realize that very, very few Java programmers have done that.
> Most of them come from a C/C++ background and for a growing number of
> developers, Java is the very first language they learned. Most of these
> people don't know much else beyond it.
> Also, don't make the mistake of thinking that all you need to do is expose
> them to another language and they will automatically start disliking Java.
> If the current trends I read today area any indication, there is at least as
> many people liking Scala as people who tried it and decided it wasn't for
> them. Groovy seems to be getting a bit more consistent positive reviews from
> Java developers, probably because it's more focused on addressing Java's
> weaknesses and sticking to that goal than Scala is.
> You will receive a lot less hostility from Java programmers about Java than
> you would asking C++ programmers about C++ ten or fifteen years ago (to be
> fair to C++; I am assuming the animosity toward C++ is even greater today
> than it was back then).
> --
> Cédric
>

[Cédric Beust ♔]

On Tue, Jun 14, 2011 at 1:00 PM, phil swenson <phil.s...@gmail.com> wrote:

So what triggered the mass adoption of Java?

My Twitter-size explanation of it is:  the combination of two things: 1) applets and 2) weariness from C++.

Obviously, it's much more complicated than that and a lot of time factors contributed (e.g. the emergence of the web).

-- 

Cédric

[Ricky Clarkson]

There was also some desire to switch code monkey training courses
(read: computer science degrees) away from Pascal.

2011/6/14 Cédric Beust ♔ <ced...@beust.com>:

[phil swenson]

so what do you think would trigger the next language to become
ubiquitous (a successful java.next)?

2011/6/14 Cédric Beust ♔ <ced...@beust.com>:

[Kevin Wright]

2011/6/14 Cédric Beust ♔ <ced...@beust.com>

With 2 involving - in no small part - Garbage Collection

[Fabrizio Giudici]

a) Java was much simpler than C++
b) Java benefited of the "web-effect" and related "news" aura
c) Sun paid big money for the marketing (JavaOne, Gosling, employees
exposed on their blogs, etc...)
d) the initial business model for JEE was good, as allowed big
competitors such as IBM to happily jump on the Java wagon and push
themselves for marketing
e) Sun's reputation was excellent in mid '90s and after the dot.com
bubble many people thought that they would have recovered. Later Sun's
name started to be counter-productive for the Java brand (often without
any rationale), but in the meantime Java had developed robust roots.

[Matthew Farwell]

You took the words right out of my mouth.

+1 Garbage collection.

Matthew.

2011/6/14 Kevin Wright <kev.lee...@gmail.com>:

[Casper Bang]

> +1 Garbage collection.

Plus the promise of write-once-run-anywhere. Back in those days, CS
tutors were among the only ones *not* using Windows!

[Paulo "JCranky" Siqueira]

> +1 Garbage collection.

This one is so very much freaking true! This is probably the main reason I decided to use Java back in the day!

--
Paulo "JCranky" Siqueira
Visit my blog: http://www.jcranky.com/

[Robert Casto]

+1  Removed a huge number of headaches and made me way more productive.

--
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.

--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

[Ricky Clarkson]

I don't for one moment doubt the advance that having garbage
collection gave Java over, say, C++, but something that came across my
mind the other day was:

Without garbage collection each object has an owner (or you have
memory leaks), so it's more obvious which 'direction' things are
supposed to flow in. For instance, in some code I've worked on, each
GUI object has a ControlSet, which is basically a copy of the model.
However, how ControlSets are delivered to those objects varies
immensely, and there are temporal dependencies, to the point where
actually supplying the thing at construction time instead of later
causes problems, and various parts of code actually rely on setting
the thing to null temporarily, etc. In short, it's a mess that I
managed to work with, but it resisted all refactoring I tried.

I still have some ideas, and access to the codebase, so I might have
another go just for fun..

I think without garbage collection, such a codebase would be so leaky
that it just wouldn't have been allowed to develop. I'm sure there
would have been other problems in place of that one though!

[Vince O'Sullivan]

Completely off topic but related to this thread...

On Google Groups, if I sort this thread "by reply" then I only see the
first 45 items. If I sort it "by date" (which is less useful) I see
65 items. This happens on IE, Firefox and Chrome. A few other
threads have had the same problem. Is anyone else having this
problem?

Vince.

[Vineet Sinha]

On Tue, Jun 14, 2011 at 3:47 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

The key difference here is that there are clear technical reasons for favouring C over C++, C++ over Java or Java over Groovy.  The arguments for using Java over Scala seem to be primarily social or political in nature.

I believe that when we can show that the ROI for Scala is positive, and less than say 2-3 months we will see increased adoption of it. By ROI, I mean the increased training overhead vs development efficiency.

While I do like Scala, the reality is that it is not yet clear/obvious how much of a development efficiency it brings about. And quite frankly measuring this efficiency is hard.

I believe that most people moved from C/C++ to Java because most C/C++ projects were at some level 'dying'. All the power that the languages gave were just resulting in bad coders destroying the architecture and reducing team productivity. Java projects definitely do not seem to be dying to that same level, and at the same time I have heard Scala's complexity being compared with C/C++.

I am not sure what is the answer to get Scala's adoption, but I do believe that we will slowly figure it out. But I definitely do not believe this to just be a social or political problem (ofcourse those might help with adoption).

Vineet

--

Founder, Architexa - www.architexa.com
Understand & Document Code In Seconds

[Cédric Beust ♔]

Interesting perspective, Vineet.

To anyone trying to evaluate Scala, I suggest listening to the podcast that Typesafe recently released. It's an interview of Paul Phillips, Typesafe cofounder and pretty much gatekeeper of what goes into Scala.

The interview is very interesting and gives a very candid (and somewhat scary) view of what happens behind the scenes in Scala.

-- 

Cédric

--

[Josh Berry]

2011/6/15 Cédric Beust ♔ <ced...@beust.com>:

> Interesting perspective, Vineet.
> To anyone trying to evaluate Scala, I suggest listening to the podcast that
> Typesafe recently released. It's an interview of Paul Phillips, Typesafe
> cofounder and pretty much gatekeeper of what goes into Scala.
> The interview is very interesting and gives a very candid (and somewhat
> scary) view of what happens behind the scenes in Scala.

Why scary?

[Cédric Beust ♔]

Listen to the podcast and make your own opinion :-)

-- 

Cédric

[Cédric Beust ♔]

For those of you who asked, the podcasts are hosted here.

-- 

Cédric

2011/6/15 Cédric Beust ♔ <ced...@beust.com>

[Reinier Zwitserloot]

Op dinsdag 14 juni 2011 22:17:42 UTC+2 schreef phil swenson het volgende:

so what do you think would trigger the next language to become
ubiquitous (a successful java.next)?

Well, that's the million dollar question, isn't it?

I'm fairly sure that java.next needs to have something compelling. A relatively small evolutionary step is not going to do the trick. If the C to java exodus is any indication, we should NOT actually be looking at language features / syntax, interestingly enough. What java had to offer at the language level was virtually nothing. It was explicitly designed to be like C, warts and all (that's the only explanation for postfix array brackets and the switch statement), but it did offer things C just couldn't offer at the time: Garbage Collection, a far more complete (and far more standard) standard library, write once run anywhere, and the promise of sandboxing (which I admit never quite panned out, but the promise was there). None of these things are language syntax related.

So then the question becomes: What features are compelling that java does not have? It also suggests that java.next may not actually run on the JVM, as many of the limitations in this 'features, not syntax' dimension are caused by the VM and not java-the-language, but what's left. I can't think of all that many things:

 - Modularization (in all dimensions), built right into the language. A mix of OSGi (runtime modularization) and ivy/maven (build-time modularization), coupled with *NO* standard library (everything is a module available on the web, including the core libraries), and a central (per machine) distributed module management system, the upshot of which is: Type "import com.google.guava.*;" into any source file and your IDE / compiler / whatever tool you're using will 'just work', because is offloads the duty of figuring out what that means and what must be downloaded to make it work to that central module management system. This could be pretty compelling. Comparing such a thing to kludging it together with maven and OSGi in vanilla java is like java's GC vs. ref-counting kludges in C.

 - A fully pluggable compiler. A regex library would simply ship at least a syntax checker + compile-time path builder, and perhaps even, if the idea of a n IDE is fully embraced, a regex editing widget, in addition to the code used at runtime to actually execute the regex. This is an alternate and IMO far more powerful take on the 'scalable language' concept of scala, which tries to accomplish this by effectively letting a library author make just about any stream of characters one can write technically legal scala.

 - Some sort of built-from-the-ground-up-for-massively-multicore model which looks almost nothing like java. However, this feature is highly unlikely to work well with a java/C-esque syntax (I guess you could have loops parallel-by-default, but that's not all that interesting), and I'm not sure this is actually all that compelling. Even on a 128-core machine, getting more than a real-life ~20x speedup by having your app 'magically' be multicore ready is highly unlikely (memory reads cross-core slow down any attempt at fine-grained parallelism, most apps run so fast that they feel instant anyway, 20x speedup or no, and the majority of speed-sensitive apps are trivially parallelised in the large, such as a web server. There may also be other bottlenecks such as a lock on a db table). I very much doubt a potential future java.next can bank on this one. Maybe by inflating this issue they could run a decent PR campaign but it would be a bad reason for the programming world to switch.

 - Yes, no doubt this new language will have some form of code blocks ('closures') and perhaps other nice-to-haves such as list comprehensions, as a second generation that goes 'lets introduce new features and keep the syntax near 100% equal to java/C' is a bit much, but I doubt this part is what will compel a massive switch. It'll mostly serve to shut down naysayers.

That's a relatively small list, much smaller than what java had to offer.

[Casper Bang]

Not surprised. In general, the Google group interface is riddled with
various errors... not Google's finest product.

[Cédric Beust ♔]

On Wed, Jun 15, 2011 at 1:06 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:

I'm fairly sure that java.next needs to have something compelling. A relatively small evolutionary step is not going to do the trick. If the C to java exodus is any indication, we should NOT actually be looking at language features / syntax, interestingly enough. What java had to offer at the language level was virtually nothing. It was explicitly designed to be like C, warts and all (that's the only explanation for postfix array brackets and the switch statement), but it did offer things C just couldn't offer at the time: Garbage Collection, a far more complete (and far more standard) standard library, write once run anywhere, and the promise of sandboxing (which I admit never quite panned out, but the promise was there). None of these things are language syntax related.

I wouldn't go that far. At least for me, the syntax was a huge breath of fresh air after years spent wrestling with the darkest features of C++.

I also remember finding the absence of headers unsettling at first, but I surprised myself at how quickly I got over it.

The fact that I never had to say "new" and "delete" was indeed a big factor, and while it's technically due to the GC, it actually felt like it was more of a syntactic and thinking relief. This is an aspect of garbage collection that's often overlooked, by the way: its presence has a positive impact on both the runtime (no more memory leaks or crashes caused by referencing bad memory) *and* the source (no new/delete and the assorted headaches of figuring out when to free the memory).

But there is an important lesson in Java's emergence: it succeeded not because it added more power but because it liberated programmers from tediousness.

 - Modularization (in all dimensions), built right into the language. A mix of OSGi (runtime modularization) and ivy/maven (build-time modularization), coupled with *NO* standard library (everything is a module available on the web, including the core libraries)

I think that would be a mistake. Standard libraries are critical for the initial success of a language. The initial libraries of Java were ridiculously bad, but the fact that they were shipped with the JDK empowered developers to prototype stuff right away and adopt a common vocabulary and patterns. In my opinion, a bad standard will always be better than no standard (see C++' continuous struggle with collections and threading...).

The rest of your feature list looks pretty good to me.

About your "pluggable compiler" item: I think that open types (à la Gosu) are very compelling, and also that the compiler should export the various phases of its compilation (especially a decorated AST) via a listener/bus mechanism. This will make tooling trivial (an omission that Scala is going to pay a very heavy price for, in my opinion). Compiler plug-ins should be allowed to modify these models but not alter the syntax of the language, or only do so with very clear syntactic flags (e.g. Java's annotations with their @ prefix). I think Groovy has made some pretty interesting progress in this direction.

-- 

Cédric

 

[Fabrizio Giudici]

On 06/15/2011 10:26 PM, Cédric Beust ♔ wrote:
>
> The fact that I never had to say "new" and "delete" was indeed a big
> factor, and while it's technically due to the GC, it actually felt
> like it was more of a syntactic and thinking relief. This is an aspect
> of garbage collection that's often overlooked, by the way: its
> presence has a positive impact on both the runtime (no more memory
> leaks or crashes caused by referencing bad memory) *and* the source
> (no new/delete and the assorted headaches of figuring out when to free
> the memory).
>
> But there is an important lesson in Java's emergence: it succeeded not
> because it added more power but because it liberated programmers from
> tediousness.

Agreed on all (also parts not quoted). BTW, I'd push the reasoning about
the impact of GC saying that it positively impact, beyond the source,
the *design* since you don't have to assign the object ownership
responsibilty. For what concerns the C++ thing, I was working a lot with
it and I remember the long waiting for the STL - until I printed the
specification. Huge, massive, elephantiac, unreadable. With Java I gave
up to generics for a while, but STL wasn't just about generics, was
about a standard library with collections and such, which the language
missed. The idea of having Vector and HashMap, and a standard version
that was sharable by all the code and third party libraries, and no more
the mess with multiple alternate implementations in C++ of such a
basilar thing, was excellent. So ...

>
>
>
> - Modularization (in all dimensions), built right into the
> language. A mix of OSGi (runtime modularization) and ivy/maven
> (build-time modularization), coupled with *NO* standard library
> (everything is a module available on the web, including the core
> libraries)
>
>
> I think that would be a mistake. Standard libraries are critical for
> the initial success of a language. The initial libraries of Java were
> ridiculously bad, but the fact that they were shipped with the JDK
> empowered developers to prototype stuff right away and adopt a common
> vocabulary and patterns. In my opinion, a bad standard will always be
> better than no standard (see C++' continuous struggle with collections
> and threading...).

... exactly what I mean. BTW, yes, they could be better at the time, but
the current stuff is worse in 2011. So in the end they weren't that bad.
In addition to the standardisation of patterns, add the fact that Java
brought a single non-primitive variable type, the reference, compared
with the three different flavours of C++: pointers, auto variables and
references (&). Too many ways to do the same thing, which is one of the
reasons I fear Scala.

[Ricky Clarkson]

> So then the question becomes: What features are compelling that java does
> not have?

Fun, really. It should be more fun to write code in than Java is.

That means the runtime should start without noticeable delay, there
should be an interpreter installed by default, and the syntax should
be pleasant to read. To keep the sense of fun, it should be difficult
to get into difficulties with mutable values and threads, because it's
not a lot of fun to solve those problems. It should be difficult to
use the supplied APIs incorrectly, because working out what you did
wrong based on runtime errors isn't fun (I'm looking at you, Swing and
GWT).

<> brackets are not fun. C++'s templates, Java's generics and XML's..
XML show this quite clearly, so we don't need those.

Lambdas are fun, single-method anonymous classes are not. Type
inference is fun, repeating types everywhere is not.

A language that helps you as much as you want to get your types right
is fun, a language that delegates that to the runtime is not. Though
it is good to be able to selectively delegate that to the runtime as
you desire - sometimes you know (ahem!) code will work no matter what
the compiler says.

It should target fun platforms. The browser, Android, iPhone and
native are fun platforms for various reasons, the JVM and the CLR are
not. They're useful, but not fun.

[phil swenson]

I think you are on to something here. Java is definitely not fun. I
think it all boils down to the fact that java makes you do too much
work for things that should be either be trivial or more terse. This
is due to both the syntax of the language and the crappy APIs.

So Java.next would have a syntax that is more expressive, more
powerful, but still approachable. And better, more pragmatic APIs. A
language where you wouldn't need Apache commons :)

Next, I think it should be a language that you can bend to your will
to a large extent (apparently Scala is a bit like this?). In addition
to DSLs, this would allow language features to be in effect added
without waiting for some JCP to approve it and build it out. The
language would evolve via idioms.

As mentioned before, it should start really fast.

It should support both compilation and interpretation. Interpretation
would come in handy for build tools and scripting tools. Isn't it
annoying having to write .bat files and .sh files to launch java apps?
And switch from your n

It should have a REPL. (how in 2011 can Java still not come with a REPL?)

[Steven Herod]

Wait a while. It'll eventually become consistent. It's WEBSCALE.

[Cédric Beust ♔]

On Wed, Jun 15, 2011 at 8:24 PM, phil swenson <phil.s...@gmail.com> wrote:

I think you are on to something here.  Java is definitely not fun.

Obviously, "fun" is very subjective, but to me, there is much more to it than the syntax of a language.

I often program in languages that are more "fun" than Java (not saying which one since it's not my point to criticize that language) but whatever fun I have flinging closures and spinning traits is quite often ruined by the extra ceremony it takes to get something to compile, to run or to be debuggable.

The syntax of Java is not as fun as some other languages, but "fun" is about the entire toolchain and the surrounding ecosystem, and something missing in that bigger picture is often enough to spoil the fun.

-- 

Cédric

[Cédric Beust ♔]

On Wed, Jun 15, 2011 at 8:24 PM, phil swenson <phil.s...@gmail.com> wrote:

It should have a REPL.  (how in 2011 can Java still not come with a REPL?)

FYI, every Java IDE offers a REPL. They are call Display views in Eclipse, or there's another kind called scratch pages (I think).

Having said that, I think the importance of a REPL is way overstated:  it's pretty easy to throw a few lines of Java code together and run them with full debugger support (which the REPL doesn't offer) in a matter of seconds. This is much, much more powerful than a REPL will ever able to offer you.

Another reason why I think REPL's are not that useful is that most of the problems that I need to investigate require a full runtime environment to make sense. In other words, I usually need a breakpoint at a specific place and to run my application in order to set up the environment in a way that inspecting the code will make any sense. Again, a REPL is very limited for this and only useful for very trivial situations.

-- 

Cédric

[phil swenson]

Yes the more "fun" languages can be a PITA because of tooling. I was
just talking about the language itself. Java tools sucked early on
too....

2011/6/15 Cédric Beust ♔ <ced...@beust.com>:

[phil swenson]

You should check out what JRuby has done in this area.... I think
you'd reconsider. I don't have time to dig up the links right now,
maybe tomorrow.

I find using the REPL in ruby and esp rails to be hugely useful. The
rails REPL launches with the same context as your application, so you
have instant access to database models, configuration, etc without the
hassle of any setup. Obviously, IDEs are better for certain things
such as debugging. But from Rails REPL I can achieve tasks much more
quickly than I could via an IDE setup. I want both - IDE and a REPL,
and an embedded REPL in my IDE.

Example:

pull in a User model from my database with ID 2:

ruby-1.9.2-p136 :002 > User.find(2)
=> [#<User id: 2, email: "du...@dummy.com", created_at: "2011-03-18
03:23:44", updated_at: "2011-06-15 01:52:51", device_token: nil,
badge_count: 0, notification_count: 2, perishable_token:
"Q59LiNwGDuhAbizdqibv">]

2011/6/15 Cédric Beust ♔ <ced...@beust.com>:

[Ricky Clarkson]

> Having said that, I think the importance of a REPL is way overstated:  it's
> pretty easy to throw a few lines of Java code together and run them with
> full debugger support (which the REPL doesn't offer) in a matter of seconds.

Assuming you have the IDE open and an appropriate project to hand.
Otherwise it is a matter of minutes.

> This is much, much more powerful than a REPL will ever able to offer you.

Common Lisp's REPL, and Erlang's, if I recall correctly, have full
debugging support available.

> Another reason why I think REPL's are not that useful is that most of the
> problems that I need to investigate require a full runtime environment to
> make sense. In other words, I usually need a breakpoint at a specific place
> and to run my application in order to set up the environment in a way that
> inspecting the code will make any sense. Again, a REPL is very limited for
> this and only useful for very trivial situations.

Sure, but those trivial situations crop up fairly often. You're in
Freenode's ##java, and can probably bear witness to the fact that
about 1 in 8 questions there are trivially answerable in fewer
characters than the question by using a REPL.

[Steve Lindsay]

On Jun 16, 12:58 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> Again, a REPL is very limited for
> this and only useful for very trivial situations.
>

I think if you're writing in a functional style the repl is more of a
win. The things you're writing/testing tend to be smaller, more self-
contained, not as much stateful setup. Change a function, evaluate in
the repl, test it with a few different inputs, make some more changes,
re-evaluate, re-test etc. It's not so much that you're presented with
a situation and you think "this calls for a repl!", it's that your
general workflow is different. Not trivial at all.

- Steve

[Vince O'Sullivan]

On Jun 15, 10:08 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> Fun, really.  It should be more fun to write code in than Java is.

I'd place the emphasis less on "fun" and more on "confidence". I
think that, regardless of the features, it would be difficult to have
fun with a language that you don't have confident in and the fun is
the natural outcome of having confidence in the language (and tools)
that you are using.

When it first came out, everybody had a really high level of
confidence in the language as The Way Forward. Consequently, they had
a lot of fun with it. Phrases like "I'm an order of magnitude more
productive in Java than <substitute almost any language>" and "Checked
Exceptions are brilliant."

Soon though, issues became apparent.
Some trivial:
Why don't threads work predictably?
Some important:
Opening curly brackets - same line or next?
And plenty of others:
How should the Cloneable (sic) interface be used, without a clone()
method?
Why is AWT so ugly?
Why is processing date and time data so complicated?
Should I be using Date or Calendar objects?
What idiot came up with Checked Exceptions?
Why is Swing so ugly?
Gridbaglayout. Seriously?
Desktop java apps. Will there ever be one?
Worst of all:
Why aren't any of these issues being fixed?
And then came generics...

Unfortunately, Java hasn't aged well. It could have done, just look
at C#. Over the years, the general level of confidence in the
language (and its custodians) has steadily dropped and people started
looking elsewhere to have fun with computing.

It seems Java's ship has sailed. It's too late for JavaFX to replace
Swing because the desktop is receding into history. It's no longer
the automatic language of choice for servers and the nearest it made
to to anything mobile is Google's forked version which will inevitably
diverge from it over time.

Of course, it will survive in enterprises for decades. Just like
COBOL is still doing.

[Josh Berry]

2011/6/15 Cédric Beust ♔ <ced...@beust.com>:

> About your "pluggable compiler" item: I think that open types (à la Gosu)
> are very compelling, and also that the compiler should export the various
> phases of its compilation (especially a decorated AST) via a listener/bus
> mechanism. This will make tooling trivial (an omission that Scala is going
> to pay a very heavy price for, in my opinion). Compiler plug-ins should be
> allowed to modify these models but not alter the syntax of the language, or
> only do so with very clear syntactic flags (e.g. Java's annotations with
> their @ prefix). I think Groovy has made some pretty interesting progress in
> this direction.

I'm a little confused. I make no claims that Scala invented this, but
aren't you just describing the presentation compiler and plugin nature
that it has? I think it was a little late to the game, but it does
exist now and is the reason the emacs environment is amazing. The
improvements with Eclipse have been from moving it to use this, if I'm
not mistaken.

[Josh Berry]

On Wed, Jun 15, 2011 at 5:08 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
>> So then the question becomes: What features are compelling that java does
>> not have?
>
> Fun, really.  It should be more fun to write code in than Java is.

It is also just plain fun when the algorithm you are implementing is
more visible in the code you are writing. Getting lost in the
language such that you can't see the algorithm you implemented is far
far from fun.

I still think askng what will be the next Java is the same as asking
what will be the next McDonalds. It isn't like the next one will
replace the old one. (I think by my own argument, one could already
say that there have been next Javas, unless you limit it to the JVM
maybe.)

[Jeb Beich]

> I think if you're writing in a functional style the repl is more of a
> win. The things you're writing/testing tend to be smaller, more self-
> contained, not as much stateful setup.

I agree. My post-python life has been filled with this sort of
experimentation. I find myself frequently writing small functions and
wanting to simply prod at them. Firing up Eclipse or Netbeans
sometimes feels to heavy. I find that if I'm able to experiment with
what I'm building in the REPL, it's usually sort of a gauge of other
properties I'm after -- testability, for example.

> --
> 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.
>
>

--
Jeb Beich
http://www.jebbeich.com

[Reinier Zwitserloot]

Op woensdag 15 juni 2011 22:26:56 UTC+2 schreef Cédric Beust ♔ het volgende:

But there is an important lesson in Java's emergence: it succeeded not because it added more power but because it liberated programmers from tediousness.

That's worth repeating. Put that way, java.next would have a decent language syntax chunk to go along with it (as that's where a lot of 'java is tedious' is directed).

 - Modularization (in all dimensions), built right into the language. A mix of OSGi (runtime modularization) and ivy/maven (build-time modularization), coupled with *NO* standard library (everything is a module available on the web, including the core libraries)

I think that would be a mistake. Standard libraries are critical for the initial success of a language. The initial libraries of Java were ridiculously bad, but the fact that they were shipped with the JDK empowered developers to prototype stuff right away and adopt a common vocabulary and patterns.

I guess I wasn't clear. There are standard libraries, of course. Except they are just 'libraries'. You can switch them out to something else, they aren't elevated to the high pedestal of 'this is the core library'. Of course there should be a java.lang-esque core which everyone agrees on, i.e. its useful if 2 separate modules can share a collection object without having to jump through hoops, but this can suffice with mostly interfaces. I *REALLY* want to break this cycle of language development where a bunch of programmers go through the hullabaloo of switching languages basically just because its a convenient excuse to fix warts in API design.

[Reinier Zwitserloot]

This or that is 'fun' is about as eye-of-the-beholder as you can get. I very much doubt that is going to lead to a useful dialogue about good ideas for language design and evolution.

[phil swenson]

Unfortunately, I couldn't find the link I wanted. This one is OK, but
not as compelling as what I was looking for:
http://www.youtube.com/headiusmaximus#p/u/3/YrbyPZgTi0g