Found some comment about the GOTO presentation, even though I presume many
more detailed ones will come later:
http://news.cnet.com/8301-30685_3-20117924-264/google-debuts-dart-a-javascript-alternative/
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
It is 2011 and the language designers repeated every single mistake made before?
They mixed the worst parts of Java with the worst parts of JavaScript and the result is not just bad, it is almost PHP-scale bad (but with Generics! (which are broken)).
Still shaking my head...
--
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.
--
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/-/3tp50ilyuSoJ.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
Well I like it: https://plus.google.com/115308028547191805295/posts/dr5bHLZt52F
--
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/-/Wfjnf6lMoi8J.
> Very nice summary, Osvaldo, and I agree with your assessment overall:
> this
> looks promising.
Before making my own opinion I need to read more examples and eventually
find the time to write something in it. I have a small photo gallery
software (yeah, yet another) made in JavaScript and if it's confirmed, as
I seem to understand, that one can write in Dart and translate to JS for
deploying everywhere already today, I could try to translate it.
For what I've seen so far, I second Osvaldo and 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+unsubscribe@googlegroups.com.
Scala GWT ?
--
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
Clojure, Groovy, JRuby, Jython, Mirah, . . .
Python, Ruby, . . .
C++, D, Go, . . .
Fortran, Cobol, . . .
Lisp, . . .
Prolog, . . .
Expertise is about knowing many languages and computational models to
usable level even if you only ever work with one language.
> - All generics are contravariant by design. Want to use a
> Collection<Double> as a Collection<Object> then try and add a String?
> With
> dart you can! A great tribute to ArrayStoreException, because now you can
> get the equivalent failure everywhere, in all your types...
True. But if you make them covariant, there's the wildcard thing. Can
somebody please explain me whether is it possible to have covariant
generics *without* all the corner cases that are often bashed in Java?
Also, if I understand your point, we have anyway a runtime check
(ArrayStoreException) that in Java is currently unfeasible because
generics arent' reified. Right?
On Oct 11, 3:24 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:++
> The three biggest problems I see are:
>
> - It has nulls, in 2011.
Ideally, you have a Haskell-like approach where you have a Maybe/
Option system and there is no universal null value.
Scala unfortunately has a global null value and it would be hard to
remove that without hampering JVM compatability.
> Ouch..
>
> http://blogs.perl.org/users/rafael_garcia-suarez/2011/10/why-dart-is-not-the-language-of-the-future.html
>
With "ouch" do you mean the poor quality of the blog post, right?
"The spec has even a chapter on factories (static constructors). (Oh my,
factories? it's like 1997 and design patterns all over again!) I should
note that the integration of popular design patterns at the syntax level
is disappointing: design patterns tend to emerge to work around a language
design's weaknesses. Embracing them is a bit like admitting a design
failure up front."
Please explain me this. For what I've understood, Dart factories are just
syntactic sugar to define a default implementation of an interface. I
don't understand the elaboration about design patterns and "design
patterns to work around a language weakness".
"Another example: Ovid pointed me at the NoMoreElementsException, and
added: "didn't Java programmers learn years ago that you throw exceptions
for exceptional things and not for expected things?"
To me this is bullshit, because exceptions are just part of the outcome of
the method execution. You can choose to use them only for exceptional
purposes, as well as going the opposite direction. A withdraw() method
throwing NotEnoughMoneyException is not exceptional (especially for me in
this period) but can make perfectly sense.
At this point I gave up reading. After all, it's so clear that the
language of the future is Perl.
BTW, up to that point I've read several assertions about the fact that
Dart would loose runtime information about types, which it's not how I
understood it, but I might be wrong (but: if Dart has got reified
generics, how can it loose type info at runtime?).
Generally speaking, I find that the picky review of such details of a
language is a really boring approach to comment about it. Given that Dart
is aimed at becoming a better JavaScript, I'd like to see people
discussing on whether the two claims by Dart guys (about JavaScript being
too flawed to scale) are reasonable or not. For instance, I've not read so
far which points for which JavaScript wouldn't scale for JIT performance
have been fixed by Dart.
Don't know why, but I found how you managed to turn an admission of an
ad hom into an insult rather amusing. :)
As for the post, I found the slant on the "feable type system" a good
spin on it. It does sound like they are encouraging more of a "lint
based" approach to typing.
I found the criticism of where you could have done "if (foo)
foo.bar()" before but now you can't because only false is false, is a
valid annoyance. I'll miss that idiom from javascript. If he is
correct about 2 + "2" being an exception whereas "2" + 2 being
concatenation, that is annoying. (I recall the pain this caused when
+ was added to List in Scala.)
I agree that the complaint about an exception is hollow, if you don't
know where it is used.
On Tue, Oct 11, 2011 at 1:31 PM, Cédric Beust ♔ <ced...@beust.com> wrote:Don't know why, but I found how you managed to turn an admission of an
> A Perl enthusiast who's written three blog posts in two years says he
> doesn't like a new language and we should pay attention because...?
> Anyway, even if I focus on the message and not the messenger, I can't say I
> see a lot of value in this post, why did you find it noticeable?
ad hom into an insult rather amusing. :)
I guess it is that I did not see the transition from an ad hom tone in
the first part where you were belittling perl and the blogger, to no
tone where you asked why the person found this interesting. You even
called out how you were making a direct ad hom attack, which seems to
signal that you were acknowledging the negative tone of the beginning.
Moving past that, though, and getting back on topic. Having only
false as false does seem odd. Especially with no way to coerce other
items into false. This is especially true in a system that will not
flag a compile error when you put something in that isn't going to
work, ever. Amusing that they went unsound to allow some stuff with
generics, but then open up comparable holes elsewhere in the system.
Same goes for the string conversion for concatenation, but no other
conversions, evidently. Seems a comparable mistake to the one made in
java. I would imagine it will be just as annoying there, as well.
I guess it is that I did not see the transition from an ad hom tone in
>> On Tue, Oct 11, 2011 at 1:31 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
>> > A Perl enthusiast who's written three blog posts in two years says he
>> > doesn't like a new language and we should pay attention because...?
>> > Anyway, even if I focus on the message and not the messenger, I can't
>> > say I
>> > see a lot of value in this post, why did you find it noticeable?
>>
>> Don't know why, but I found how you managed to turn an admission of an
>> ad hom into an insult rather amusing. :)
>
> Er... wha?
> Rereading what I wrote, I see fact, fact, a question and a personal opinion.
> Where do you see any attack?!?
the first part where you were belittling perl and the blogger
, to no
tone where you asked why the person found this interesting. You even
called out how you were making a direct ad hom attack
No worries, though I really didn't mean this to be a major complaint.
I really was amused by my reading. You called out that you were
making an ad hominem when you said "even if I focus on the message and
not the messenger." That is the definition of these arguments.
In fact, pointing this out, I am starting to feel like I'm just being trolled.
The more interesting question will be whether Apple, MS, Mozilla will embed the Dart VM in their browsers.
It seems interesting that dart leaves out all access to files, databases and screens in their library as well as any kind of native access. Seems it's more targeting the client side and not so much the server side of things. I don't really see how one would write a large server side application in Dart.
Ruben
--
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.
The more interesting question will be whether Apple, MS, Mozilla will embed the Dart VM in their browsers.
Or, like Go, Google pumps it so much that it is forced into being taken
up no matter that it is not the right solution to the right problem?
James doesn't like Java so creates Groovy.
Martin doesn't like Java so creates Scala. James now wishes he'd
invented Scala instead of Groovy
RedHat doesn't like Java so invents Ceylon, not to be confused with Sri
Lanka.
JetBrains doesn't like Java so invents Kotlin.
Google doesn't like Java so invents Dart.
I think I see a pattern. Actually one of two:
Everyone is scared of Oracle's ownership of Java (well the trademark and
patents anyway) and wants to own their own language so as to enhance
diversity and divergence.
Everyone wants to be a hero and invent the next monopoly language.
Presumably with the aimed for lock in to create dependants and hence a
sure income stream. This is, of course, the standard model in
technology and especially computing.
Let us hope that the Tower of Babel effect does not take place as it did
(analogously) with UNIX in the 1980s.
I think that mucks with the timeline of most of these languages.
Weren't a good many of them started under Sun's reign. (And you left
out clojure.)
Not to mention you are ignoring the vast progress MS has made in
language design in the .NET world. It isn't shocking that many in the
JVM world finally started realizing that, yes, Java has stagnated
heavily for a long time now. It isn't beyond hope, per se. Just very
stagnate.
Groovy was 2003, Scala 2004, after that things get hazy :-)
I am not sure the Sun/Oracle thing matters much, except that Sun itself
had stagnated such that it was choked with pond weed, whereas that is
unlikely ever to happen to Oracle -- at least in the same way.
Clojure is a realization of what many claim to be the only programming
language that you ever need, and that the history of programming
languages is one of people failing to realize that car, cdr and cons are
the only operations you ever need -- or at least that s-expressions are
the only expression one needs to express any expression.
> Not to mention you are ignoring the vast progress MS has made in
> language design in the .NET world. It isn't shocking that many in the
> JVM world finally started realizing that, yes, Java has stagnated
> heavily for a long time now. It isn't beyond hope, per se. Just very
> stagnate.
Hasn't M$ decided that C++ is actually a good thing and that CLR was
probably an aberration caused by lack of Intel.
coffeescript's approach just seems more pragmatic. compiles to javascript - works on everything. plus it's simply a cleaner, nicer syntax.it doesn't pass the "cool" test. it looks like a rehashed java. my gut says dart fails to get any uptake.
Everyone is scared of Oracle's ownership of Java (well the trademark and
patents anyway) and wants to own their own language so as to enhance
diversity and divergence.
Similarly, the bar is not to create a good language, but to get people
using it. :) I feel comfortable claiming that dart could be a
complete step backwards in every way, and there is still a chance it
would succeed quite well if google puts enough muscle behind it.
:) Fair enough. I admit that s-expressions are highly attractive to
me, years later now that I finally understand them. (Well, years
later now that I think I understand them.)
I admit to being lured by the abstractions put forth by many of the
Haskel folks, too. Applicatives and the like are very interesting.
Hopefully I can get to understand them faster than I did lisp.
Hasn't M$ decided that C++ is actually a good thing and that CLR was
probably an aberration caused by lack of Intel.
I'm still puzzled by Dart's allowance of dynamic typing, though. What's the rational here? Saving a few keystrokes just so you can prototype faster? This doesn't make much sense.
I think people just like it when things work as well as they can.
When building a bike, you are likely to try riding it a few times
before it is really "ride-able." With what is commonly called dynamic
typing, you can typically do this. With static typing, if it won't
stand, it won't run. Period.
In this regard, I admit I would like an optionally static/dynamic
split. Imagine testing a few additions to a visitor/node tree where
you purposefully didn't completely all implementations of the methods
because you just aren't there yet and don't care. (If you have
several visitors, might want to just try one or two at a time, for
example.) This is certainly doable with a lot of upfront planning
regarding modular codebases, but it would be a lot easier if you could
just say "don't enforce this now."
Obviously, this is all starting with "I think." So, your mileage will
vary. I'm interested in how far off the mark I am, though.
The only time is when I'm in the middle of a massive refactor and I'm
worried that I've changed behaviour accidentally.
The bigger problem is that I'm in the middle of a massive refactor. I
generally step back at this point and find a way to decompose it into
smaller refactors.
I think dynamic typing is generally helpful when you are beginning in
programming, when your mistakes can simply be deleted instead of
supported for years to come.
After that point, types are useful, even in Java where they're
verbose, or C where they're limited (no generics).
Unfortunately some of the OO techniques don't gel very well with
types, because types tend to make implicit complexity explicit.
For instance in JavaScript you could have a list of employees and
remove all but the developers then pass that to a method that expects
a list of developers.
Doing the same with types is a pain, but because what we're doing is
complex rather than types being complex.
E.g., if the list gets modified on another thread we could end up
sending a list of accountants to do a development team's job.
JavaScript would just blow up, but a typed language would force the
programmer to write the code in a safe way. And that can mean changing
the design for the better. Instead of modifying the list, create a
new one or a view to a version of the original if memory is tight.
Stepping to C# gratuitously:
WeNeedDevs(from e in employees where e is Developer select e as Developer);
The type system is happy and the program is better, but it requires a
change in thinking, and perhaps it's that that the Rubyists, etc.,
don't want to entertain. They prefer the freedom of a car without
brakes.
> --
> 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.
>
>
--
Sent from my mobile device
--
Skype: ricky_clarkson
You've just specified a very good reason to have type inference, full dynamic typing isn't a requirement to kill the boilerplate - The belief that static typing must be heavyweight is mostly perpetrated by Java.
The open question is "why do some folks like dynamic typing?" My
proposed answer was it can get out of your way better than static
typing. You shot that down. I'm still curious for the answer. So
far, the only answer either of you have put forward is "people that
like dynamic typing just don't know the good languages for static
typing." Is that really the best answer we have?
That said, even with that, there tends to be more boilerplate in statically typed languages than in
dynamic.
I don't know, I just find that a less than compelling answer.
Especially when considering lisp offshoots. I don't think it is a
lack of caring on their part.
Type annotations certainly count. Hell, anything that is "just a
standard part of a program and has to be present" counts. As an
example, setting up the tables and such in squeryl is something I feel
safe calling boilerplate. ActiveRecord showed many in the world that
you could have done that through reflection on a table.
Are there advantages to having that boilerplate? Of course there are.
Doesn't mean it isn't boilerplate. (That is, you can't eliminate
all boilerplate, by nature of the definition of boilerplate. It isn't
that java has any boilerplate that annoys so many, it is that it has
so much boilerplate.)
I'm using boilerplate in the "any text that is or can be reused in new
contexts or applications without being changed much from the original"
concept from wikipedia. Libraries actually do more to reduce
boilerplate than type inference, I would think. Consider the benefits
of map/filter/fold over your standard imperative loops.
How is this effortlessly thread safe unless each data structure has a
lock and so you have whole data structure locking.
To answer the challenge:
Python:
developers = [ e for e in employees if isinstance(e, Developer) ]
Groovy:
final developers = employees.filter { it instanceof Developer }
which of course gives rise to the problem of what collect, filter, map,
reduce, inject, etc. mean in each language, as each language that has
them uses them with different semantics :-((
Not the message Herb Sutter is putting about . . .
On Thu, 2011-10-13 at 14:04 +0100, Kevin Wright wrote:
[ . . . ]
>How is this effortlessly thread safe unless each data structure has a
> I'd defy anyone to come up with a dynamically-typed equivalent to this
> Scala snippet that's as simple, comprehensible, and as effortlessly
> thread-safe:
>
>
> val developers = employees collect { case d: Developer => d }
lock and so you have whole data structure locking.
To answer the challenge:
Python:
developers = [ e for e in employees if isinstance(e, Developer) ]
Groovy:
final developers = employees.filter { it instanceof Developer }
which of course gives rise to the problem of what collect, filter, map,
reduce, inject, etc. mean in each language, as each language that has
them uses them with different semantics :-((
--
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
I am *another* language, a bit closer to home. I'm perfectly at home on the Java platform and also use declaration site variance (a simple trick for me, thanks to the much-derided type erasure on the JVM).
I was written by the same guy as wrote the current generation of javac and who created Java's generics (though not the wildcards, as he'd be keen to point out)
I lack many of Java's difficult corner cases, especially in the type system; yet oddly I take a lot of undue criticism for being (allegedly) complicated.
What am I?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it