Hi guys,

just back from holidays sorry if I didn't response sooner.


Ricky:

"Let me know when int i = "hello"; is rejected by the compiler and I'll
look again."

Thats such a staggeringly huge, dumb thing to say, I have to assume you are
trying to be provocative. But if I was to give it some thought, here's what
I would say:

1. That does not say much about you if thats the level of due diligence you
are prepared to do before dismissing a technology that many people (some
better than you) are saying is worth a look.

2. If you're hoping the compiler will catch errors like that, then I think
you have a bigger problem in who you are hiring to write code.

3. As a professional programmer, I thoroughly unit test my code. A piece of
code like that won't get far before its caught.

Fabrizio:

"In the end I found that that kind of stuff is the empty set: I found
always preferable to do with Java"

Can you elaborate? At the moment I can't think of anything I would ONLY do
in Java if I also had Groovy available and could do a mix.

Kevin:

"What ultimately turned me off was the performance hit and the dynamic
typing (that, and the existence of Scala).  What has your experience been
with these in Groovy?"

That statement has the smell of 'Java is slow' that used to get bandied
about years ago. I guess the answer is I don't know yet. I've yet to come
across a development team where performance of the code was measured during
development time. It usually comes afterwards, which can be too late of
course.

I attended a presentation this year on Groovy performance at the
CloudFoundry Day and the message was with constant improvements in the JVM
and the new static checking, you are almost the same as Java.

My gut feel though is that unless you are already measuring your app in
terms of tsp then its likely to be fast enough. Even if it isn't, once you
isolated the critical parts, rewrite that part in Java. I just think the
people bitten by this is small.


Cedric:

"java.concurrent.util is not just very powerful, it's very well designed
and it's running tens of thousands of high volume web sites today"

I'm sure it is. However, as Russell and Ricky point out, is does feel as
though its too low level.

Over the past week I've been reading up on GPars which is an abstraction
layer on top of the concurrency libraries and its definitely way easier to
work with and feels at the right abstraction level, especially in Groovy
(in Java, it still seems verbose because of the lack of closures and the
extra syntax).

I think, to get philosophical for a moment, that software development is a
journey. Its also very unique to the individual as well. The journey I am
on may well lead me to the promised land known as Scala but I do not feel I
am ready quite yet and still have to pay my dues, learn more lessons out in
the wild with Groovy. Its like the levels you have to pass through on the
way to enlightenment. There's no point saying to people 'just use Scala' as
they have to worked their way there. Over the years I've heard Dick talk
about Java then he started playing with Python and then he moved to Scala.

Like I said, Groovy feels like a door opening onto a wider world. It has
enough bits of other languages that I could well get distracted by:

Functional programming and end up in Haskell land or more likely, Clojure
land.

Or maybe the dynamism gets into my blood and I end up moving to Ruby.

We all know people in these camps and it would be foolish to say there is
something wrong with their choices.

Also, one last think I want to mention. Groovy says it tries to bring the
'fun' back into programming. I know see what they mean. I actually do get
that buzz from writing something elegant that required me to have mastered
some previously unknown area.

Rakesh

On 23 July 2012 19:57, Ricky Clarkson <[email protected]> wrote:

> That can't happen with shared mutable objects.
> On Jul 23, 2012 3:46 PM, "Russel Winder" <[email protected]> wrote:
>
>> On Mon, 2012-07-23 at 08:25 -0700, Cédric Beust ♔ wrote:
>> […]
>> > To be fair, there is nothing running on the JVM today showing that this
>> is
>> > wrong. All the alternate solutions fail on one of these criteria while
>> > java.concurrent.util meets them all:
>>
>> A quick general response, I'll try and do a more detailed one tomorrow.
>>
>> Do Java programmers manage the stack. No.
>>
>> Do Java programmers manage the heap. No.
>>
>> So why do Java programmers try to manage threads?
>>
>> Threads are infrastructure and should be managed by the runtime system
>> just as heap and stack are.
>>
>> --
>> Russel.
>>
>> =============================================================================
>> Dr Russel Winder      t: +44 20 7585 2200   voip:
>> sip:[email protected]
>> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: [email protected]
>> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 "Java 
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to