Yet another JVM lang: Extend
phil swenson
Cédric Beust ♔
--
http://www.eclipse.org/Xtext/xtend/It looks quite cool to me. But it's getting a bit crazy with the number of JVM languages being created.... I think some consolidation would be 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+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Jon Kiparsky
Simon Ochsenreither
yetAnotherHalfAssedScalaImitation += 1
:-)
Blazej Bucko
with closures comes up, scala community (I assume that Simon is scala
enthusiast :)) calls it "half assed scala imitation"? I don't see this
kind of attitude from Groovy community.
Is scala one and only language and we must shoot everything else?
Scala is great and all, but there are other great languages. Maybe
Xtend will be better. Or at least have better tools :)
Regards,
Blazej Bucko
> --
> 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/-/iJYIO_lxvV4J.
Josh Berry
in .NET feel? :)
Though, I have felt some fatigue at the number of languages coming out
of Google. Seems that they stay willfully ignorant of what others are
working on at times. (The dart folks had never heard of coffeescript,
for example.)
Kevin Wright
I don't understand one thing: Why, when new statically typed language
with closures comes up, scala community (I assume that Simon is scala
enthusiast :)) calls it "half assed scala imitation"? I don't see this
kind of attitude from Groovy community.
Is scala one and only language and we must shoot everything else?
Scala is great and all, but there are other great languages. Maybe
Xtend will be better. Or at least have better tools :)
Ricky Clarkson
I'm sure many would do the same but mentioning Java if a new language looked like Java but added goto and implicit conversions from object pointers to booleans.
Ricky Clarkson
Cédric Beust ♔
Because they usually repeat the mistakes Scala and its users try to avoid.
Ricky Clarkson
Cédric Beust ♔
I don't see this kind of attitude from Groovy community.
Ricky Clarkson
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
Blazej Bucko
examples? Argumentation? Valid points?
2. Some might say that Scala is half-arsed Smalltalk/Erlang/Clojure
imitation. As one old man said: "There's always a bigger fish."...
Regards,
Blazej Bucko
Fabrizio Giudici
wrote:
> 1. Can someone elaborate why Xtend is half-arsed Scala imitation? Some
> examples? Argumentation? Valid points?
> 2. Some might say that Scala is half-arsed Smalltalk/Erlang/Clojure
> imitation. As one old man said: "There's always a bigger fish."...
>
> Regards,
> Blazej Bucko
My point of view is that Scala is packed with a lot of things. Too many,
for me. But Scala fans like them. Anything that is not as full of things
as Scala is clearly tagged as "half-arsed". It seems we're rather
discussing whether a language should be lightweight or heavyweight.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Josh Berry
amusement purposes. What with the smiley and all.
Ricky Clarkson
clay
It's just an example of first class functions.
The mass conspiracy of confusing "closures" with first class functions
continues.
I'm shocked that this ignorance is so pervasive. Even language
designers don't know what a closure is?
Ricky Clarkson
p [ for (arg : args) $(arg) ]
Skype: ricky_clarkson
martin
Russel Winder
[ . . . ]
> Though, I have felt some fatigue at the number of languages coming out
> of Google. Seems that they stay willfully ignorant of what others are
> working on at times. (The dart folks had never heard of coffeescript,
> for example.)
On interpretation might be that Google is so big and has so little
management reporting that works, that until the languages are announced
no-one in Google other than the development team knows about the work.
Another interpretation might be that Google is so afraid of all the
software patents lined up against it, that it protects itself by
requiring all language designers to not study the current languages
being developed in case they violate a patent and end up in court.
--
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
Russel Winder
[ . . . ]
> Because Groovy had significantly different goals, James wrote it to be a
> lightweight glue & scripting language that would support core Java work,
> not something that could realistically be considered a replacement or used
> anywhere that performance was at all important.
It seems that Groovy is veering rapidly to the optional typing camp
rather than dynamic typing camp (which it was already in of course ot
overloading wouldn't work. There is Groovy++ and the new Grumpy Mode in
the mainline Groovy.
Basically whatever James might have wanted in 2003, Groovy has moved on
and become something much more than it was.
You don't have to use Groovy, or even like it, but to hang an 8 year old
millstone around it seems a bit disingenuous.
[ . . . ]
> "Tooling" means a great deal more than how friendly the Eclipse plugin is...
>
> If I have to fire up half of the eclipse IDE in my Continuous
> Integration/Deployment server just to build the thing, and if I can't build
> it at the command line, and if I can't use Maven/Rake/Gradle/SBT/whatever
> with it, then I'm afraid I'm going to have to take any claims of "better
> tooling" with a particularly large grain of salt.
Indeed.
I wonder why it is that the Intellij IDEA SBT plugin always forces the
SBT window to be open and shown, none of the other tools do that, they
always revert to the last known state. If the SBT folk want to be taken
seriously they need to fix this.
Russel Winder
> That's pretty much what I was trying to say. Groovy is a half-arsed Java imitation (to me), similarly Fantom->Scala, PHP->Perl, Ruby->(Smalltalk, Perl)
Ricky,
If you are thinking of Groovy as a half-arsed Java imitation, you really
need to actually look at the two languages and compare them.
Interestingly isn't it Scala copying Fantom to be a language for the
CLR?
Ricky Clarkson
Also, Scala's .NET compatibility predates Fantom so in order to copy it Martin must be even smarter than I thought.
From: Russel Winder <rus...@russel.org.uk>
Sender: java...@googlegroups.com
Date: Tue, 08 Nov 2011 08:33:35
To: <java...@googlegroups.com>
Reply-To: java...@googlegroups.com
Subject: Re: [The Java Posse] Re: Yet another JVM lang: Extend
Blazej Bucko
Regards,
Blazej Bucko
> --
> 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/-/nCfAhanBOOwJ.
Paul King
int x = "hello"
obviously needs to compile but fail at runtime when in dynamic mode
(to cater for what would be somewhat dubious style of metaprogramming
in this case) and does indeed fail compilation in grumpy/static mode.
Cheers, Paul.
Ricky Clarkson
Ricky Clarkson
-----Original Message-----
From: Paul King <pa...@asert.com.au>
Sender: java...@googlegroups.com
Date: Tue, 8 Nov 2011 19:40:05
Paul King
in their IDEs) at type time. You wouldn't wait until compile time to
get such feedback.
Cheers, Paul.
Ricky Clarkson
Every time you make an error into a warning someone will deal with it later.
Paul King
> One of the problems we face as developers is taking over projects written by people who ignored or disabled such warnings, or didn't even use the IDE that provides the warnings.
>
> Every time you make an error into a warning someone will deal with it later.
Indeed, that is why things like CodeNarc (checkstyle equivalent) and
now Grumpy mode have been created and have enjoyed some
interest/popularity within the Groovy community. Of course, relying on
compilation alone is setting the bar fairly low. You would ideally
like tests, invariants, static and dynamic analysis tools etc. to be
in play - but agree with you that not all environments are ideal. Of
course, I have also seen the bad side of relying just on compilation -
people not understanding what some code does and just keep "hacking"
it until it compiles - then ship it once if compiles!
Cheers, Paul.
Ricky Clarkson
However it's much easier to tell what the original intent was if the environment actually prevents certain classes of error.
Did the programmer mean to write int x = 123 or String x = "123"? For that case you should be able to tell frm the context but in more involved cases it might be difficult, or worse, some parts of code assume the value is one type and some another.
At this point this isn't specific to Groovy, for a dynamic language Groovy at least does something at runtime with type annotations, which is more than most do.
The real issue is that mediocre programmers can create a worse mess in a language that doesn't enforce types and maybe other restrictions than one that does.
I'm not elevating myself here, apart from some good practices regarding source control etc., I'm capable of making just as big a mess as anyone in a language I don't know properly.
A good example that doesn't relate to typing directly is thread-safety in GUI toolkits. Swing and WPF have the same requirement whereby you are required to use components on the event dispatch thread only. WPF goes some way to enforcing that by throwing an exception should you instantiate a component on the wrong thread.
Swing, on the other hand, just protests mildly in part of the documentation and occasionally displays corruption. This makes it much easier to build up a large codebase of mostly-working but fundamentally flawed GUI code.
Refactoring that isn't something I've seen the two MFs cover, and frankly it's really hard. That's why where you see 'freedom' I see 'to make a huge mess' in small print, and I personally would only use Groovy in dynamic mode as a teaching environment or for small programs that would not be expensive to rewrite without looking at the original code.
I hope the static mode catches on, and if it does I expect I'll look at Groovy again if Oracle repeats Sun's to-ing and fro-ing on lambdas.
Robert Casto
Jon Kiparsky
--
Robert Casto
Josh Berry
I must say that at face value, I like the sound of that approach.
Sounds close to a management style I've always wondered why wasn't
used more.
Still not sure how to feel about it coming out of google, though.
There was a good perspective posted regarding the google reader stuff
the other day.
http://nick.typepad.com/blog/2011/11/the-long-term-failure-of-web-apis.html?cid=6a00d83451863669e2015436a131e0970c#comment-6a00d83451863669e2015436a131e0970c
I fear the same criticism applies to the languages and frameworks
they push, as well.
Russel Winder
> That's what I did about 5 years ago. Perhaps something has changed since then but I believe int x = "hello" still compiles in Groovy.
Still compiles, but fails at run time. This is to be expected since
Groovy is a run time typed language not a compile time typed language.
It is a dynamic language after all. Given there is Java to supply the
statically typed language to run on the JVM, in which the above
statement is illegal and caught at compile time, Groovy should not and
does not try to be a Java wannabee. Instead it provides a dynamic
symbiote to Java. This is as it should be.
> Also, Scala's .NET compatibility predates Fantom so in order to copy it Martin must be even smarter than I thought.
I did phrase my point as a question as I hadn't checked facts. If Scala
execution on .NET predates Fantom's then clearly Fantom as Scala
wannabee is a potential.
[ . . . ]
Russel Winder
[ . . . ]
>
> Did the programmer mean to write int x = 123 or String x = "123"? For
> that case you should be able to tell frm the context but in more
> involved cases it might be difficult, or worse, some parts of code
> assume the value is one type and some another.
>
> At this point this isn't specific to Groovy, for a dynamic language
> Groovy at least does something at runtime with type annotations, which
> is more than most do.
>
> The real issue is that mediocre programmers can create a worse mess in
> a language that doesn't enforce types and maybe other restrictions
> than one that does.
The real question here has nothing to do with Java, Groovy, static or
dynamic, it is to do with why organization continue to employ
sub-standard software developers, fail to train them to be competent,
and then expect to get top-quality software.
I agree that programming language is a tool and we should create and use
the best tools available. Static languages and dynamic languages are
different tools. We have to use them appropriately in the right
context.
I think demanding that programming language should hamstring the capable
to protect against the incompetent is to solve the wrong problem in the
wrong way.
[ . . . stuff on GUIs and event loops elided due to unqualified
agreement . . . ]
> I hope the static mode catches on, and if it does I expect I'll look
> at Groovy again if Oracle repeats Sun's to-ing and fro-ing on lambdas.
I am looking forward to Grumpy Mode in Groovy as well, not as a
protection mechanism, but as a new tool to expand capability.
If Oracle do not get lambdas into Java at the next main release then
Java really is headed for the scrap pile. Even C++ now has lambdas and
a data structures and threading system that can use them. Though it is
woefully lacking in actor and dataflow frameworks; asynchronous function
call and futures are great tools, but actors and dataflow make for less
complex and generally more correct and less buggy code. Fortunately
Anthony Williams is working on this -- but as this is a Java list...
Ricky Clarkson
>> a language that doesn't enforce types and maybe other restrictions
>> than one that does.
>
> The real question here has nothing to do with Java, Groovy, static or
> dynamic, it is to do with why organization continue to employ
> sub-standard software developers, fail to train them to be competent,
> and then expect to get top-quality software.
Because they can and they don't know any better. I wish I'd written
my part a bit differently, because even a great programmer can make a
complete mess in an environment he's not familiar with.
> I think demanding that programming language should hamstring the capable
> to protect against the incompetent is to solve the wrong problem in the
> wrong way.
That's not what I said and I think you know that. Most if not all
protections you can give actually help good programmers to write
expressive code.
> If Oracle do not get lambdas into Java at the next main release then
> Java really is headed for the scrap pile.
I'd love to agree, but each 'industry programmer' who I meet who uses
C# for example doesn't really know what a lambda is apart from perhaps
that LINQ uses them. I think it'll take more than that to kill Java,
though perhaps it will lose some limbs (mobile, desktop, university
education).