> 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
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.
> 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.
--
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.
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.
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.
"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
Seems like Josh (at least) understands tooling's importance. From an
interview regarding Effective Java, 2nd Edition:
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.
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.)
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.
If you put it in that perspective, ok, nothing will ever change.
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.).
On Dec 8, 1:57 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:Yes indeed, a pickup truck is basically a better horse and cart in the
> It's like roads really. We still lay down surfaces for them, and sit in
> something with wheels and a source of locomotion.
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.).
> 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.
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/)
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.
--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.
"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."
--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.
> 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?
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.
> 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.
> 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?
--
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.
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?
> 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.
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
Nooo! I hope we're not about to move back to an era of experimental
coding. 'Guess-edit-crash-guess-edit-crash'.
> :-)
>
> Joking aside, Eclipse (and probably IDEA as well)
... and NetBeans too.
Know what happens when you cook with gas?