atom feed23 messages in org.codehaus.groovy.devRe: [groovy-dev] Suggestions for @Imm...
FromSent OnAttachments
Guillaume LaforgeMar 2, 2009 2:16 am 
Dierk KönigMar 2, 2009 2:38 am 
Guillaume LaforgeMar 2, 2009 3:01 am 
Dierk KönigMar 2, 2009 3:40 am 
Guillaume LaforgeMar 2, 2009 3:53 am 
melixMar 2, 2009 3:56 am 
Guillaume LaforgeMar 2, 2009 3:59 am 
Paul KingMar 2, 2009 4:11 am 
Guillaume LaforgeMar 2, 2009 4:23 am 
Tom NicholsMar 2, 2009 4:39 am 
Michael MellingerMar 2, 2009 5:11 am 
Martin C. MartinMar 2, 2009 5:31 am 
Tom NicholsMar 2, 2009 6:19 am 
Robert FischerMar 2, 2009 6:25 am 
Robert FischerMar 2, 2009 6:39 am 
Tom NicholsMar 2, 2009 6:51 am 
Graeme RocherMar 2, 2009 6:56 am 
Alex TkachmanMar 2, 2009 7:07 am 
Robert FischerMar 2, 2009 7:08 am 
Robert FischerMar 2, 2009 7:13 am 
Alex TkachmanMar 2, 2009 8:18 am 
Robert FischerMar 2, 2009 8:58 am 
Guillaume LaforgeMar 3, 2009 1:39 am 
Subject:Re: [groovy-dev] Suggestions for @Immutable
From:Robert Fischer (robe@smokejumperit.com)
Date:Mar 2, 2009 7:13:25 am
List:org.codehaus.groovy.dev

Why should that make you feel weird? You're offsetting the cost of development
by throwing machinery at it. That's a pretty standard and fairly cost-effective answer to
limited development resources.

Now, if it'd be fast enough to rewrite your slow parts in Java, and that can be
done for less cost than the hardware, then rewriting those parts in Java is a just fine solution.
But in any but the simplest cases, you're better off throwing hardware at the problem: the cost
over time is a lot less than maintaining code.

~~ Robert.

Alex Tkachman wrote:

AFAIK it is not as brilliant as Scala original.

In general all my experiences with both Groovy concurrency and cloudization so far was very strange. 1) From one prospective we know that Groovy is extremely expressive and ability of DSL creation are unlimited 2) From other prospective I feel myself like an idiot by putting grid of 5 machines to make calculation faster and at the same time using language, which is executed several times slower compare to Java.

Alex

On Mon, Mar 2, 2009 at 5:56 PM, Graeme Rocher <grae@springsource.com <mailto:grae@springsource.com>> wrote:

There is this: http://www.groovyactors.org/

Don't know if its any good

Cheers

On Mon, Mar 2, 2009 at 2:39 PM, Robert Fischer <robe@smokejumperit.com <mailto:robe@smokejumperit.com>> wrote: > See a tutorial here to take the magical veneer off of Actors: > http://www.scala-lang.org/node/242 > > There's no reason you need language changes -- including @Immutable -- to > implement actors. It's a pretty simple design pattern which could be just > as well implemented in Groovy. We could even get the same syntax modulo > "case ... =>" becoming "case ...: ... break". > > Were I to design the library for Groovy, though, I wouldn't try to mimic > Scala's API: I'd probably implement actors with a more conventional > approach: actOn(SomeType var) becomes the handler for SomeType instances, > with a "setUp", "teardown", "before", and "after" phase. Bonus points for a > conventional handle(Exception) methods (handle(IOException), > handle(RuntimeException), handle(Exception)). > > Between my 9 to 5'er, my graduate school, GroovyMag training, Autobase, and > Cornerstone, I really don't have time to write up that code. But as someone > who is big into concurrency, functional programming, and language/library > design, I'd be willing to provide thoughts/guidance/critiques. > > ~~ Robert Fischer. > Grails Training http://GroovyMag.com/training > Smokejumper Consulting http://SmokejumperIT.com > Enfranchised Mind Blog http://EnfranchisedMind.com/blog > > Check out my book, "Grails Persistence with GORM and GSQL"! > http://www.smokejumperit.com/redirect.html > > > Tom Nichols wrote: >> >> On Mon, Mar 2, 2009 at 8:31 AM, Martin C. Martin >> <mar@martincmartin.com <mailto:mar@martincmartin.com>> wrote: >>> >>> Groovy's approach to performance has generally been to never leave out or >>> modify a feature strictly for performance, and when you need performance, >>> you should rewrite the bottleneck in Java. When the world was single >>> core, >>> immutability was just a nice invariant, another check the compiler could >>> do >>> to catch certain kinds of errors. And it wasn't part of Java, let alone >>> Groovy. (Java has "final" for variables and fields, but no notion that >>> an >>> entire object is immutable.) >>> >>> So, unless I'm missing something, this seems like a feature that's >>> difficult >>> (or impossible?) to implement efficiently in the face of arbitrary >>> metaclass >>> changes at runtime. And it seems the main motivation is performance. >>> >>> Or have I got it wrong? >> >> The motivation, I believe is to actually not have to worry about >> multiple threads modifying shared memory. If objects are immutable >> you don't need to worry about somebody else changing that same >> instance. So it is not so much about performance, but readability and >> ease of designing concurrent systems. Java (an C variants) are >> notoriously difficult to write concurrent systems in. So "dropping >> down to Java" is not really helping in this case. >> >> Scala seems to have achieved this fairly well with Actors and >> immutable types (which is built on the JVM). My impression had been >> that Scala would generally be more suitable for concurrent programming >> because of its compile-time checking. But I still have trouble with >> some of Scala's syntax and idioms, so if this model can in fact be >> applied successfully to Groovy I am all for it. >> >> -Tom >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >

-- Graeme Rocher Head of Grails Development SpringSource - Weapons for the War on Java Complexity http://www.springsource.com

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

Check out my book, "Grails Persistence with GORM and GSQL"! http://www.smokejumperit.com/redirect.html