Joshua Bloch joins the Dart team as core libraries architect

722 views
Skip to first unread message

Serge Boulay

unread,
Dec 6, 2011, 6:24:01 PM12/6/11
to java...@googlegroups.com
Joshua Bloch joins the dart team as core libraries architect. 

Fabrizio Giudici

unread,
Dec 6, 2011, 6:27:32 PM12/6/11
to java...@googlegroups.com, Serge Boulay
On Wed, 07 Dec 2011 00:24:01 +0100, Serge Boulay <serge....@gmail.com>
wrote:

> Joshua Bloch joins the dart team as core libraries architect.
>
> https://twitter.com/#!/search?q=%23dartlang

So Dart seems definitely a serious thing.


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

Vince O'Sullivan

unread,
Dec 7, 2011, 2:14:33 AM12/7/11
to The Java Posse
On Dec 6, 11:27 pm, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> On Wed, 07 Dec 2011 00:24:01 +0100, Serge Boulay <serge.bou...@gmail.com>

> wrote:
>
> > Joshua Bloch joins the dart team as core libraries architect.
>
> >https://twitter.com/#!/search?q=%23dartlang
>
> So Dart seems definitely a serious thing.

Anything that replaces JavaScript has got to be a Good Thing. I hope
it succeeds but, unfortunately, can't see it ever being anything more
than an interesting niche because JavaScript is just so deeply
embedded into browsers and the web.

Fabrizio Giudici

unread,
Dec 7, 2011, 3:27:59 AM12/7/11
to The Java Posse, Vince O'Sullivan
On Wed, 07 Dec 2011 08:14:33 +0100, Vince O'Sullivan
<vjosu...@gmail.com> wrote:

> On Dec 6, 11:27 pm, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
> wrote:
>> On Wed, 07 Dec 2011 00:24:01 +0100, Serge Boulay
>> <serge.bou...@gmail.com>
>> wrote:
>>
>> > Joshua Bloch joins the dart team as core libraries architect.
>>
>> >https://twitter.com/#!/search?q=%23dartlang
>>
>> So Dart seems definitely a serious thing.
>
> Anything that replaces JavaScript has got to be a Good Thing.

You don't have to convince me :-) my point was related about how seriously
Dart is taken in Google. These days I was about to ask here whether there
were news about Dart, since after the debate peak following the
presentation there were no further feedback. But now we can say it's still
moving on.

> I hope
> it succeeds but, unfortunately, can't see it ever being anything more
> than an interesting niche because JavaScript is just so deeply
> embedded into browsers and the web.

But in the meantime Chrome share passed Firefox share and it's the second
browser around. So at this point if Google is serious about Dart, I'd say
that chances are good.

Matthew Farwell

unread,
Dec 7, 2011, 3:29:56 AM12/7/11
to java...@googlegroups.com
They said that when James Gosling joined Google as well, and look how that turned out...

Matthew Farwell.



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


Vince O'Sullivan

unread,
Dec 7, 2011, 4:01:06 AM12/7/11
to The Java Posse
On Dec 7, 8:29 am, Matthew Farwell <matt...@farwell.co.uk> wrote:
> They said that when James Gosling joined Google as well, and look how that
> turned out...

While acknowledging that he was the father of Java (and has greater
coding skills than I can dream of), I've long suspected that Java's
half-hearted lurch through version 1.5 and subsequent stagnation at
version 1.6 were, at least in part, due to his being de facto DFL of
Java at Sun, and that Oracle taking it over and him leaving were the
best things that happened to the language in the last three or four
years.

Cédric Beust ♔

unread,
Dec 7, 2011, 2:21:51 PM12/7/11
to java...@googlegroups.com, Vince O'Sullivan

On Wed, Dec 7, 2011 at 12:27 AM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
But in the meantime Chrome share passed Firefox share and it's the second browser around. So at this point if Google is serious about Dart, I'd say that chances are good.

Agreed. Javascript is very powerful and has proven extremely useful time and time again, and it's going to be around for a while, but something will eventually replace it.

I think Dart has a very decent shot at it considering it's being pushed by a company that is creating a very successful browser, has a lot of clout *and* also the manpower to actually pull off a very good language. And with the plan to generate Javascript for browsers that won't be supporting Dart natively, I think all the elements are in place.

My only concern is that Dart is being engineered by what seems to be an "old school" of language designers. I don't mean this in a bad way, just that they are people who probably tend to write their code in emacs and who might see IDE's and surrounding tooling as a second thought. The Chrome Javascript debugger is superb, though, so I hope to see something good come out of all this.

I compare this to Ceylon, which just released an early version of their Eclipse plug-in before a standalone compiler is even available. Now *that* is a model I can get behind.

Wishing Google and Josh well.

-- 
Cédric



Jeb Beich

unread,
Dec 7, 2011, 4:05:40 PM12/7/11
to java...@googlegroups.com
Seems like Josh (at least) understands tooling's importance. From an
interview regarding Effective Java, 2nd Edition:

"Joshua Bloch: Easier! People just love modern IDEs and all they do to
accelerate the development process. Programmers do refactorings that
they just wouldn't have bothered with if they had to do them manually.
And static analysis, of the sort performed by FindBugs and by the code
inspection facilities in modern IDEs is a real blessing. We all make
mistakes, and it sure is nice to have an automated assistant looking
over your shoulder."

http://www.infoq.com/articles/bloch-effective-java-2e

2011/12/7 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.red-source.net/jeb

Casper Bang

unread,
Dec 8, 2011, 3:35:50 AM12/8/11
to java...@googlegroups.com
On Wednesday, December 7, 2011 10:05:40 PM UTC+1, Jeb wrote:
Seems like Josh (at least) understands tooling's importance. From an
interview regarding Effective Java, 2nd Edition:


Moreover, he understand the complex interrelations of language features which is presently one of the most debated issues with Scala (slowly being replaced by the fragile versioning debate). I shall indeed be interesting to follow what comes out of this endeavor.

Ricky Clarkson

unread,
Dec 8, 2011, 2:38:00 AM12/8/11
to java...@googlegroups.com
You could also read it as “Google's most senior Java guy switches to Dart“.
From: Casper Bang <caspe...@gmail.com>
Date: Thu, 8 Dec 2011 00:35:50 -0800 (PST)
Subject: Re: [The Java Posse] Re: Joshua Bloch joins the Dart team as core libraries architect
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/E0DA53W2e8YJ.

Vince O'Sullivan

unread,
Dec 8, 2011, 3:40:44 AM12/8/11
to The Java Posse
On Dec 7, 7:21 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> On Wed, Dec 7, 2011 at 12:27 AM, Fabrizio Giudici <
> My only concern is that Dart is being engineered by what seems to be an
> "old school" of language designers. I don't mean this in a bad way, just
> that they are people who probably tend to write their code in emacs and who
> might see IDE's and surrounding tooling as a second thought.

I think that there's more to this than meets the eye. I wrote my
first code thirty years ago (in Fortran and Pascal). Modern languages
are a bit more structured than they used to be, but not a lot. At the
end of the day (when all's said and done), programmers are still doing
they're job by arranging variables and loops and branches in pretty
much exactly the same same as they were doing when I started out. In
all that time, I've yet to see a "new" language that actually does
anything "new" or changes the way I do my job.

(This sounds strangely like a conversation that I had with my teenage
kids recently. The music they listen to is identical to the music I
listened to at their age and the reason for that is (like programming)
that the technology behind it hasn't really changed in years, just
been tweaked a bit.)

There is some progress but a lot less than people think. Things like
"full screen mode" and "exit from full screen mode" (two of the two
hundred and fifty new features recently added to OSX) aren't progress.
Dart (to paraphrase Douglas Adams a bit) is another attempt to paint
the wheels a different colour to see if it will make the wagon go
faster.

Ricky Clarkson

unread,
Dec 8, 2011, 2:48:48 AM12/8/11
to java...@googlegroups.com
Sounds like time to invest in a new paradigm.

Try Haskell, if only for the way it affects the way you think about programming.
-----Original Message-----
From: "Vince O'Sullivan" <vjosu...@gmail.com>
Sender: java...@googlegroups.com
Date: Thu, 8 Dec 2011 00:40:44
To: The Java Posse<java...@googlegroups.com>
Reply-To: java...@googlegroups.com
Subject: [The Java Posse] Re: Joshua Bloch joins the Dart team as core
libraries architect

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

Kevin Wright

unread,
Dec 8, 2011, 5:22:50 AM12/8/11
to java...@googlegroups.com
I think that there's more to this than meets the eye.  I wrote my
first code thirty years ago (in Fortran and Pascal).  Modern languages
are a bit more structured than they used to be, but not a lot.  At the
end of the day (when all's said and done), programmers are still doing
they're job by arranging variables and loops and branches in pretty
much exactly the same same as they were doing when I started out.

No we're not.  In any declarative or purely functional language you'll discover that nothing is "variable", immutability is the order of the day.

I'd also seriously question whether a comprehension or mapping can be considered a loop.  In Haskell, Clojure, or Scala I can easily take the infinite collection of integers, double them all, subtract 7, and return the first 20 resulting values.  Try doing that with a loop and you'd be waiting for a *very* long time.

And then there's Prolog, which breaks every paradigm you know, plus a few more.


 
In
all that time, I've yet to see a "new" language that actually does
anything "new" or changes the way I do my job.


How about an old language then?  Lisp was one of the first post-assembler languages ever created, a full 12 years before Pascal and 4 years after Fortran.  Unlike those dinosaurs though, it's still very much current; the most accessible version available nowadays is Clojure.

Fortran is also influential in the creation of the Fortress language, though unlike Lisp/Clojure is varied so much that I can't really say Fortress is a variant of Fortran (it's closer to Scala, ML and Haskell in many ways).  See http://en.wikipedia.org/wiki/Fortress_(programming_language)


Or if that's a bit to "niche" for you, try something a little more recent...  SQL is one of the most widely used languages in active use today, it's declarative, and offers neither variables nor loops without vendor-specific extensions.


 
(This sounds strangely like a conversation that I had with my teenage
kids recently.  The music they listen to is identical to the music I
listened to at their age and the reason for that is (like programming)
that the technology behind it hasn't really changed in years, just
been tweaked a bit.)


How about the music they *dance* to?

Vince O'Sullivan

unread,
Dec 8, 2011, 8:25:33 AM12/8/11
to The Java Posse
On Dec 8, 10:22 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> In Haskell, Clojure, or Scala I can easily take the
> infinite collection of integers, double them all, subtract 7, and return
> the first 20 resulting values.

That's exactly my point. Regardless of the syntactic sugar new
languages bring to the table, the code being written now is
essentially identical to what was being turned out thirty or forty
years ago. We're still manipulating integers, fiddling with them and
returning the results. When I started out as a programmer, back then,
I was told it was a dead-end career because "by the end of the
century" computers would be able to do do all that stuff themselves
and programmers would be history.

Fabrizio Giudici

unread,
Dec 8, 2011, 8:45:16 AM12/8/11
to The Java Posse, Vince O'Sullivan

If you put it in that perspective, ok, nothing will ever change.

Kevin Wright

unread,
Dec 8, 2011, 8:57:16 AM12/8/11
to java...@googlegroups.com, Vince O'Sullivan
It's like roads really.  We still lay down surfaces for them, and sit in something with wheels and a source of locomotion.

Carriages will always be carriages, it's really only a minor trivial detail if they happen to be horseless nowadays, the essence of the thing is completely unchanged!

Vince O'Sullivan

unread,
Dec 8, 2011, 9:56:42 AM12/8/11
to The Java Posse
On Dec 8, 1:57 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> It's like roads really.  We still lay down surfaces for them, and sit in
> something with wheels and a source of locomotion.

Yes indeed, a pickup truck is basically a better horse and cart in the
same way that Scala is a better Fortran.

Programming by having a programmer "manually" defining what needs to
be done to each piece of data is a bit like requireing all transport
to go by road.

(At the risk of hammering the analogy into the ground) there are
alternatives to roads that can take you to places that roads cannot
(e.g. ships, planes and rockets) but little indication that the same
can be done in computing (i.e. the possibility of creating software at
a level of abstraction where the developer isn't writing stuff like
"let x = 1" or "var x = 1" or whatever the latest language's variation
is.).

jon.ki...@gmail.com

unread,
Dec 8, 2011, 10:38:57 AM12/8/11
to The Java Posse
This analogy isn't making it for me, unless you want to claim that today's ships are really just updated schooners,  and freight trains are just modern refinements to the iron horse. If you're going to go that far, you might as well say that a plane is just a truck with wings - that's closer to the mark than either of the other two claims!
And in that case, nothing has changed in shipping, any more than it has in programming, so what is your analogy buying you?

To me, the analogy works the other way around. Take shipping as practiced in, say,1900. Bring in  containers and multi-modal shipping and letting the user do the data entry and stuff like that, and our current shipping infrastructure looks a lot like the old one, just with a few refinements - a few refinements which, taken together, change the game entirely. Just as the little refinements in programming have changed the game entirely, even though at bottom we're still moving bits from here to there and back.

----- Reply message -----
From: "Vince O'Sullivan" <vjosu...@gmail.com>
Date: Thu, Dec 8, 2011 9:56 am
Subject: [The Java Posse] Re: Joshua Bloch joins the Dart team as core libraries architect
To: "The Java Posse" <java...@googlegroups.com>

Kevin Wright

unread,
Dec 8, 2011, 10:39:17 AM12/8/11
to java...@googlegroups.com
On 8 December 2011 14:56, Vince O'Sullivan <vjosu...@gmail.com> wrote:
On Dec 8, 1:57 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> It's like roads really.  We still lay down surfaces for them, and sit in
> something with wheels and a source of locomotion.

Yes indeed, a pickup truck is basically a better horse and cart in the
same way that Scala is a better Fortran.

Programming by having a programmer "manually" defining what needs to
be done to each piece of data is a bit like requireing all transport
to go by road.
 
My understanding is very different.  Of course programmers must manually define what to do, that's the very definition of programming, the only variant is the level of abstraction at which this takes place.

This is defining what needs to be done to every little bit of data:

    List<ObligatoryOutputType> output =
        new ConventionalSubclassOfList<ObligatoryOutputType>()
    for(ObligatoryInputType datum : input) {
        output.add(someFunc(datum))
    }

This, by contrast, is defining something that must happen to the collection as a whole:

    val output = input map someFunc

Just consider what would happen if this was a transform pipeline and you decided to start using arrays instead of lists.  In the first example you'd have to go back and change the collection types specified in every such transformation.  There's a crucial difference in the level of abstraction being used here.

(At the risk of hammering the analogy into the ground) there are
alternatives to roads that can take you to places that roads cannot
(e.g. ships, planes and rockets) but little indication that the same
can be done in computing (i.e. the possibility of creating software at
a level of abstraction where the developer isn't writing stuff like
"let x = 1" or "var x = 1" or whatever the latest language's variation
is.).

No language will *ever* exist where you don't have to name or otherwise specify the entities that are core to the functioning of the system.  Without the ability to name stuff, all that can really be said is "do something", and that isn't particularly useful as descriptions of a program go.

Fabrizio Giudici

unread,
Dec 8, 2011, 10:53:07 AM12/8/11
to java...@googlegroups.com, Kevin Wright
On Thu, 08 Dec 2011 16:39:17 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> No language will *ever* exist where you don't have to name or otherwise
> specify the entities that are core to the functioning of the system.
> Without the ability to name stuff, all that can really be said is "do
> something", and that isn't particularly useful as descriptions of a
> program
> go.

Exactly. The alternative is a computer with Artificial Intelligence
comparable to humans. I mean, it must be able to do what a human does
today. At this point some would think it's possible sooner or later, some
think it won't be ever possible, in any case is sci-fi for the foreseeable
future and not an interesting topic to discuss (BTW, it has been discussed
here in the past).


While I don't agree with the whole example, I think Kevin is right with
the point that it's a matter of level of abstraction.

Robert Casto

unread,
Dec 8, 2011, 11:14:38 AM12/8/11
to java...@googlegroups.com
Or the Space Shuttle was just a truck with wings that just went vertical. So was it really a leap to have a vehicle that could go around the earth a bunch of times or land on the moon? Software at its most basic level has to do with manipulating 1's and 0's. There is really no significance between them, just whether the circuit has a certain state. Yet we can do a great many things all based on bit-fiddling. And we can do it exceptionally fast with great precision. Are our brains nothing but a bunch of circuits connecting binary memory? I'm not sure but if so, then I think it is conceivable that some day we will be able to create something that matches or rivals the human brain. We first have to understand what we are building though and that is going to take a long time. We just emulate a lot of things right now at the most basic level.
--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

Josh Berry

unread,
Dec 8, 2011, 11:20:11 AM12/8/11
to java...@googlegroups.com
On Thu, Dec 8, 2011 at 10:53 AM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> While I don't agree with the whole example, I think Kevin is right with the
> point that it's a matter of level of abstraction.

I have to question whether constantly moving up that ladder is the
correct way to go. Specifically, where is the diminishing return
level of abstraction? My suspicion is that it is a very personal
answer.

I do keep coming back to the literate programming world, though. It
is just too appealing in how similar it is to how it seems everything
is taught. I can't help but thinking the "javadoc" style of thinking
you can jump in at any given method to fully understand what is
happening somewhere is a fallacy that causes more harm than is
admitted.

(See http://www.johndcook.com/normal_cdf_inverse.html for a good
example. Really, any of his posts on the topic.
http://www.johndcook.com/blog/tag/literate-programming/)

Cédric Beust ♔

unread,
Dec 8, 2011, 12:47:18 PM12/8/11
to java...@googlegroups.com

On Thu, Dec 8, 2011 at 8:20 AM, Josh Berry <tae...@gmail.com> wrote:
I can't help but thinking the "javadoc" style of thinking
you can jump in at any given method to fully understand what is
happening somewhere is a fallacy that causes more harm than is
admitted.

How is that a fallacy? I think it has worked very, very well overall. I consult Javadocs several times a day (most of the time from my IDE, which is another great progress in documentation browsing) and it does help my productivity significantly. Obviously, a Javadoc is only as good as the quality of the comment, but by now, Java has some very spectacularly well written doc across the board (both the JDK and external libraries such as Guice or Guava).

Just this morning, somebody posted on scala-debate a very interesting report of his experience getting up to speed on Scala, and here is one of his points:

There is definitely a huge price to pay developing Scala code because the IDE support is so poor. Writing Java code in Eclipse goes so much easier because of all the help the IDE editors give you. The fact that Eclipse lets you hover the cursor over things and brings up these great semi-persistent tool-tips with hyperlinked javadoc makes productivity incredibly high.

-- 
Cédric

Kevin Wright

unread,
Dec 8, 2011, 1:18:26 PM12/8/11
to java...@googlegroups.com
2011/12/8 Cédric Beust ♔ <ced...@beust.com>
In fairness, it's also worth pointing out that the user in question was trying to edit standalone script files in a directory that was explicitly *not* marked as a source directory in the IDE.  If it had been, he wouldn't have lost much of that goodness.  The full quote:

"In my current utilities environment the previous problem is compounded because I have my Scala source code under src/main/resources instead of src/main/scala or src/main/java so the IDE does not know how to compile things. I am still considering ways to resolve this. I do it this way because as resources, the Scala source files are easy for my application to deploy. The editor still does the basic lexical stuff, but not nearly enough in terms of syntax and semantics. Essentially my development cycle is (1) edit the Scala source in Eclipse, (2) copy/paste the source files from Eclipse into my bin/src folder, and (3) run the utilities from the command line and watch the Scala compiler complain about all my mistakes. However, this is similar to the experience someone in the field would find having to hack the utilities code at a customer site with no IDE or other development tools."

You'll also find seriously reduced functionality editing Java in Eclipse when it's not considered part of your project's source tree and doesn't get properly linked into the code DOM.  So taking the original quote out of context and implying it's a typical experience of Scala development is somewhat disingenuous.

I suggest readers check out the full thing for themselves here though, instead of relying on extracts:



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



--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Fabrizio Giudici

unread,
Dec 8, 2011, 2:07:48 PM12/8/11
to java...@googlegroups.com, Josh Berry
On Thu, 08 Dec 2011 17:20:11 +0100, Josh Berry <tae...@gmail.com> wrote:

> On Thu, Dec 8, 2011 at 10:53 AM, Fabrizio Giudici
> <Fabrizio...@tidalwave.it> wrote:
>> While I don't agree with the whole example, I think Kevin is right with
>> the
>> point that it's a matter of level of abstraction.
>
> I have to question whether constantly moving up that ladder is the
> correct way to go. Specifically, where is the diminishing return
> level of abstraction?

More complexity (in the entropic sense). Undoubtedly there's more entropy
in a Java algorithm making use of VM, hot spot, GC etc... than coding in
native machine language. Increased complexity is what you pay for more
productivity, manageability, readability, performance, etc...

Josh Berry

unread,
Dec 8, 2011, 2:30:56 PM12/8/11
to java...@googlegroups.com
On Thu, Dec 8, 2011 at 2:07 PM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> On Thu, 08 Dec 2011 17:20:11 +0100, Josh Berry <tae...@gmail.com> wrote:
>
>> On Thu, Dec 8, 2011 at 10:53 AM, Fabrizio Giudici
>> <Fabrizio...@tidalwave.it> wrote:
>>>
>>> While I don't agree with the whole example, I think Kevin is right with
>>> the
>>> point that it's a matter of level of abstraction.
>>
>>
>> I have to question whether constantly moving up that ladder is the
>> correct way to go.  Specifically, where is the diminishing return
>> level of abstraction?
>
>
> More complexity (in the entropic sense). Undoubtedly there's more entropy in
> a Java algorithm making use of VM, hot spot, GC etc... than coding in native
> machine language. Increased complexity is what you pay for more
> productivity, manageability, readability, performance, etc...

So.... how do you identify this added complexity? For example, are
higher kinded types out of the question? It seems they work rather
well for those that understand them. And I'm inclined to agree with
them that anyone can learn them if they put forth the effort. My
question is simply is it worth the effort?

Josh Berry

unread,
Dec 8, 2011, 2:27:24 PM12/8/11
to java...@googlegroups.com
On Thu, Dec 8, 2011 at 12:47 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> On Thu, Dec 8, 2011 at 8:20 AM, Josh Berry <tae...@gmail.com> wrote:
>>
>> I can't help but thinking the "javadoc" style of thinking
>> you can jump in at any given method to fully understand what is
>> happening somewhere is a fallacy that causes more harm than is
>> admitted.
>
>
> How is that a fallacy? I think it has worked very, very well overall. I
> consult Javadocs several times a day (most of the time from my IDE, which is
> another great progress in documentation browsing) and it does help my
> productivity significantly. Obviously, a Javadoc is only as good as the
> quality of the comment, but by now, Java has some very spectacularly well
> written doc across the board (both the JDK and external libraries such as
> Guice or Guava).

For API items, it works wonderfully. So did/do man pages for utility
files. Most of us are not writing an API. So, my contention is that
they do little to help understand a full program? They help document
parts of something, but they do not do anything to show how the parts
fit together. And many folks obsession with them does more harm than
is generally admitted.


>
> Just this morning, somebody posted on scala-debate a very interesting report
> of his experience getting up to speed on Scala, and here is one of his
> points:
>
> There is definitely a huge price to pay developing Scala code because the
> IDE support is so poor. Writing Java code in Eclipse goes so much easier
> because of all the help the IDE editors give you. The fact that Eclipse lets
> you hover the cursor over things and brings up these great semi-persistent
> tool-tips with hyperlinked javadoc makes productivity incredibly high.

I realize there is often a lot of amusing derailments into the realm
of promoting scala. It seems there is an equal number of derailments
into the realm of bashing scala, as well.

Fabrizio Giudici

unread,
Dec 8, 2011, 2:41:13 PM12/8/11
to java...@googlegroups.com, Josh Berry
On Thu, 08 Dec 2011 20:30:56 +0100, Josh Berry <tae...@gmail.com> wrote:


> So.... how do you identify this added complexity? For example, are
> higher kinded types out of the question? It seems they work rather
> well for those that understand them. And I'm inclined to agree with
> them that anyone can learn them if they put forth the effort. My
> question is simply is it worth the effort?

For your previous question I'd like to keep this argument out of my
answer. Discussing about the complexity of types will inevitably lead to
Scala :-) and I don't want to bring Scala (or any other language) into the
discussion now, because it's subjective (as you said, "they work rather
well for THOSE THAT understand them". I only mentioned facilities that
today are considered state of the art and rather orthogonal to most
languages, where I think everybody agrees that there are both things that
I was talking about: higher abstraction and higher complexity.

Fabrizio Giudici

unread,
Dec 8, 2011, 2:43:35 PM12/8/11
to java...@googlegroups.com, Josh Berry
On Thu, 08 Dec 2011 20:27:24 +0100, Josh Berry <tae...@gmail.com> wrote:


> For API items, it works wonderfully. So did/do man pages for utility
> files. Most of us are not writing an API.

This could be not true, or subjective. A coarse-level decomposition of a
system into subsystems basically exposes APIs (if it's well done). I'm
thinking of both horizontal (tiers) and vertical (layers) decomposition.
If you're doing SOA, you're exposing APIs. In that domain, javadocs are
pretty good. Of course I agree that they aren't enough.

Josh Berry

unread,
Dec 8, 2011, 2:47:26 PM12/8/11
to java...@googlegroups.com
On Thu, Dec 8, 2011 at 2:43 PM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> On Thu, 08 Dec 2011 20:27:24 +0100, Josh Berry <tae...@gmail.com> wrote:
>
>
>> For API items, it works wonderfully.  So did/do man pages for utility
>> files.  Most of us are not writing an API.
>
>
> This could be not true, or subjective. A coarse-level decomposition of a
> system into subsystems basically exposes APIs (if it's well done). I'm
> thinking of both horizontal (tiers) and vertical (layers) decomposition. If
> you're doing SOA, you're exposing APIs. In that domain, javadocs are pretty
> good. Of course I agree that they aren't enough.


Agreed, and your last statement really highlights an assumption I had
but did not voice. What I meant was that a sole reliance on javadoc
as a documentation method causes more harm than is usually admitted.
I had not meant to be pushing that javadocs should be abolished.
Apologies for any confusion that angle may have caused.

Also.... apologies if this went directly to you and not the group. I
think I got "undo" hit before I was too late. When did these emails
default reply to be direct to the person?

Ricky Clarkson

unread,
Dec 8, 2011, 2:55:38 PM12/8/11
to java...@googlegroups.com
It depends greatly on the API. E.g., JButton has around 380 public methods and a lot of Swing is like that. Most of those are irrelevant and some are actually harmful, but they'll all appear when you type 'button.' and wait.

For Swing, the tutorials are far more useful than the Javadocs.
From: Cédric Beust ced...@beust.com
Date: Thu, 8 Dec 2011 09:47:18 -0800
Subject: Re: [The Java Posse] Re: Joshua Bloch joins the Dart team as core libraries architect

Kevin Wright

unread,
Dec 8, 2011, 4:07:09 PM12/8/11
to java...@googlegroups.com, Josh Berry
You must admit though, higher-kinded types are a good example of the kind of abstraction under discussion here.

Simply put, a higher-kinded type is a type that itself takes another type argument.

For example, in Scala...* List[String] is a type, whereas List is a higher-kinded type

You can then pass "List" to some method, and it would be parameterised and used to build a concrete List.  You could alternatively pass the same method a "Set", or "Vector" to get the corresponding concrete collection in return.

The basic concept is not at all difficult, though specifics of the implementation or the paradigm shift to a higher-level of abstraction when you work in this way across an entire codebase may cause some initial head scratching.  Research in ways to improve the situation is, as ever, ongoing.

My personal experience is that this kind of stuff actually simplifies my programs, by allowing me to strip out a lot of code duplication and/or tricky uses of reflection.  YMMV, but unless you're explicitly using them to push the start-of-the-art in type system trickery then higher-kinded types don't add complexity.  If you *are* pushing at the boundaries, then you only have yourself to blame :)


* It's really not my intent to invoke Scala here, so don't make this a discussion about Scala, but Java can't express the concept (the closest it gets is raw types, which aren't the same thing at all).  I just used the closest thing to Java that can manage this, and I'm obliged to stay at least within the Java *platform* where possible :)
--
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

unread,
Dec 8, 2011, 4:16:00 PM12/8/11
to Kevin Wright, java...@googlegroups.com
On Thu, Dec 8, 2011 at 4:07 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> You must admit though, higher-kinded types are a good example of the kind of
> abstraction under discussion here.

I thought they were, though I have to cede that it will almost
undeniably land us in the realm of discussing Scala. So I can
understand wanting to avoid it.


So, generics could be a good topic instead. I know there are a few
languages that are working to seriously limit them. Are they too high
a price to pay?

Are there other topics that are amicable to this discussion?

Fabrizio Giudici

unread,
Dec 8, 2011, 5:03:33 PM12/8/11
to Kevin Wright, Josh Berry, java...@googlegroups.com
On Thu, 08 Dec 2011 22:16:00 +0100, Josh Berry <tae...@gmail.com> wrote:

> On Thu, Dec 8, 2011 at 4:07 PM, Kevin Wright <kev.lee...@gmail.com>
> wrote:
>> You must admit though, higher-kinded types are a good example of the
>> kind of
>> abstraction under discussion here.
>
> I thought they were, though I have to cede that it will almost
> undeniably land us in the realm of discussing Scala. So I can
> understand wanting to avoid it.

Just to be clear: I don't want to "avoid discussing" about Scala :-) Is
that we know we have different opinions on Scala, or other languages,
while leaving the language alone I think we can get on a broader consensus
on the current topic.

Russel Winder

unread,
Dec 9, 2011, 2:41:59 AM12/9/11
to java...@googlegroups.com
On Thu, 2011-12-08 at 06:56 -0800, Vince O'Sullivan wrote:
[...]

> Yes indeed, a pickup truck is basically a better horse and cart in the
> same way that Scala is a better Fortran.
[...]

Have you actually looked at Fortran 2009? Fortran remains the most
suitable language for writing computational intensive algorithms. Java,
Scala, C, etc. don't get a look in. C++ and D can get close.

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

signature.asc

Kevin Wright

unread,
Dec 9, 2011, 4:33:54 AM12/9/11
to java...@googlegroups.com
Fortran continues to be amazing, especially in HPC scenarios.
Fortress has the potential to surpass it, but not until Oracle implements a way to avoid the heavy cost of boxing/unboxing primitives.

Several solutions have been proposed, including fixnums, tuple types and stack allocation.  I eagerly await seeing what will be decided in the end.

Of course, once this is sorted then everything will benefit; including Scala, Clojure, Fortress, X10, JRuby, Java, etc. etc.

Bruno Leroux

unread,
Dec 11, 2011, 8:38:11 AM12/11/11
to java...@googlegroups.com
Cédric,
your personal knowledge of the Dart team members is far better than mine.
My impression was that first class tooling is very important for them.
I tend to believe them for the following reasons :
- Tooling is one of the announced key features : http://www.dartlang.org/docs/technical-overview/index.html#key
- Several commiters have a huge Smalltalk background, not a brand new language ;-), but  maybe the first language to have built-in tooling.
- AFAIK, main Dart commiters on Tooling are Dan Rubel and Steve Messick, they worked on tooling for many years (VisualSmalltalk, Part for Java, WindowBuilder, ...)

I too think IDE support is very important and I have high expectations for the Dart Editor. For instance I hope that the following will materialized : 'Gilad Bracha is promising Smalltalk-style edit-debug-edit-debug-cycles (without restarting the program)' :-)

Bruno

Vince O'Sullivan

unread,
Dec 12, 2011, 3:42:44 AM12/12/11
to The Java Posse
On Dec 11, 1:38 pm, Bruno Leroux <bruno.ler...@gmail.com> wrote:
> 'Gilad Bracha is promising Smalltalk-style edit-debug-edit-debug-cycles
> (without restarting the program)' :-)

Nooo! I hope we're not about to move back to an era of experimental
coding. 'Guess-edit-crash-guess-edit-crash'.

Cédric Beust ♔

unread,
Dec 12, 2011, 9:59:09 AM12/12/11
to java...@googlegroups.com
:-)

Joking aside, Eclipse (and probably IDEA as well) already allows you to do this today. You can set breakpoints anywhere in your code and while in the middle of it, you can modify the code of the method. Depending on the impact of the modification you just made, either the process will just keep running happily or Eclipse will reset the frame (basically, restarting your current method from line one) and you can test your change immediately.

I think it's only fair to expect the same kind of functionality from Dart.

-- 
Cédric

Fabrizio Giudici

unread,
Dec 12, 2011, 10:33:20 AM12/12/11
to java...@googlegroups.com
On Mon, 12 Dec 2011 15:59:09 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> :-)
>
> Joking aside, Eclipse (and probably IDEA as well)

... and NetBeans too.

Kevin Wright

unread,
Dec 12, 2011, 10:57:05 AM12/12/11
to java...@googlegroups.com
Well... within reason!

Grails/Play/Scalate all bump it up another notch with regards to dynamic recompilation.

For full effect though, JRebel to the mix! That's when you're really cooking with gas...

Casper Bang

unread,
Dec 15, 2011, 3:56:44 PM12/15/11
to java...@googlegroups.com
Know what happens when you cook with gas? It explodes!

Cédric Beust ♔

unread,
Dec 15, 2011, 4:57:44 PM12/15/11
to java...@googlegroups.com
On Thu, Dec 15, 2011 at 12:56 PM, Casper Bang <caspe...@gmail.com> wrote:
Know what happens when you cook with gas?

Delicious tri-tips.

-- 
Cédric

Reply all
Reply to author
Forward
0 new messages