23-Feb-2013 22:40, Russel Winder пишет:
> On Sat, 2013-02-23 at 21:44 +0400, Dmitry Olshansky wrote:
> […]
>> I have to say that no amount of provided out of the box nice libraries
>> and top-notch GC help alleviate the dire need for plain value-types and
>> some kind of terseness (rows of static final int xyz = blah; to define a
>> bunch of constants). With Java version being 5 or 6 (as is usually the
>> case in production ATM) there is basically not a single construct to
>> avoid horrible duplication of information on each line.
>
> Maybe in Java 1.4, 8 years ago a plethora of public static final int
> constants, but these days seeing that implies a bad design, a complete
> lack of updating/refactoring of the software to modern Java features, or
> simple laziness. Java 5 introduced more than generics.

Admittedly I'm no expert on Java. Hence "have to work".
Would be nice to know if there is something that can represent this C snippet without the usual heaps of verbosity:
enum {
STATUS_OK = 0,
STATUS_FAIL_REASON_XYZ,
... ad infinitum (but presently dozens)
};

There are lots of other cases, but this one is prime.

You might argue for using classes and inheritance + visitor pattern instead of plain switch/state machines. The heaps of boilerplate to write/generate all of "state"/visitor etc. classes argues the other way around.
(and I suspect the execution speed too)

>
> The G1 GC is a significant improvements to Java.

I guess this depends on the platform you (have to) use?
BTW I agree that Java's GC is nice, more so the automatic de-heapification of modern VMs.

>
> Java supports value types, albeit as objects on the heap. Give me an
> example of the problem so we can approach this with more than waffly
> statements.

A trivial example is storage of pairs or tuples. That plus using Java's containers makes memory footprint explode. At 100K+ hash-map I notice quite high factor of waste. It's some double digits compared to plain C arrays. I probably shouldn't care that much since servers are having tons of RAM these days, and customers throw money on equipment without second thought. Thus for the moment I just can't help but notice. Thank god we are mostly I/O bound.

Another example. I had to sort some objects by rating for a bit of processing with ranking. Yet this rating is computed and really doesn't belong with them at all (and needs locking beforehand) and I can't reorder them in place. What I'd do is create an array of tuple link-rating and sort these.

In Java I have to create a full-blown object and allocate each array slot separately, cool. Not to mention the complete lack of concise tuples.

Writing functors is a royal pain in the ass too. Anonymous classes doesn't quite cut it on the scale of verbosity/benefit. If there any library that doesn't use reflection like crazy to achieve simple, concise functors, I'd be glad to use it but so far I found none.

Sorry can't elaborate on exact details here, the work is not open-source by any measure.

> Far too few programmers use the final keyword properly/effectively.

In Java programs it can be used very often. I'd say too often since I find it rare to have a need to e.g. rebind an object. As for "a few programmers", well you have to type it everywhere, guess why it's not popular?!

>> There are few shortcuts in Java 7, and even more stuff in Java 8 but all
>> of it is coming horribly too late and doesn't fix the "big picture".
>> Plus that has to propagate into the  mainstream.
>
> This is Java's serious problem. There are still people using Java 1.4.2
> because they can't be bothered to update to Java 5 let alone 7.

And even if e.g. I for one would go for Java 7 it really doesn't depend on my views at all.

> […]
>
> I have many problems with Java, it is very verbose, but it needs to be
> criticized in a fair manner not in a "slag off" way. Clearly everyone on
> this list is going to prefer D over Java, but that is not permission to
> use inappropriate argumentation.

Mmm. I report my experience not argument much of anything excpet that it's far from pleasant.

If anything I might convince the team to switch off to Scala, someday.
If not the somewhat alien syntax it would be far easier.

-- 
Dmitry Olshansky

On Sat, 23 Feb 2013 09:17:37 -0800
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Sat, Feb 23, 2013 at 05:57:23PM +0100, simendsjo wrote:
> > On Saturday, 23 February 2013 at 16:44:59 UTC, Nick Sabalausky
> > wrote:
> > (...)
> > >Anyone still using Java is just so last decade ;)
> > 
> > I've managed to dodge Java all these years, but I just started a college which teach Java. Even after using it only for a couple of thousand lines of code, I understand the hatred.. Feels like I'm in a straitjacket. Yes, it might be easy to learn, but damn it's verbose!
> 
> That was my reaction too, when I first starting learning Java. And that is still my reaction today.
> 

When I used it, it was back when v2 was new. To it's credit, it *did*
teach me to hate C++'s module system and classes. But, yea,
"staightjacket" and "verbose" are the right words. (And if an
advanced IDE is *required* to make a language usable, then the language
sucks).

I know there's been improvements from v5+, but by then I had already switched to the [at least at the time] far superior C# (which I've since gotten fed up with too, and abandoned completely in favor of D). Any modern Java improvements are just far too little, far too late. They could fix all it's problems tomorrow, but won't matter because the damage to its reputation has already been done.

Plus does any serious coder really trust Oracle?


> It's not a *bad* language per se. In fact, a lot of it is quite ideal. Or rather, idealistic, should I say. Unfortunately, that makes it a pain to map to messy real-world situations -- you end up with a truckload of wrappers and incrediblyLongAndVerboseIdentifiers just so the language can remain "pure". As for being a straitjacketed language, this IOCCC entry says it best:
> 
> 	http://www.ioccc.org/2005/chia/chia.c
> 
> ;-)
> 

Nice :) It's interesting how much in-line that is with the quote
from the old D homepage that was a big part of what made D win me over
from day one:

"It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe it's time for a new language born out of practical experience implementing compilers."

On Sat, 23 Feb 2013 23:22:54 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> 
> A trivial example is storage of pairs or tuples. That plus using Java's containers makes memory footprint explode. At 100K+ hash-map I notice quite high factor of waste. It's some double digits compared to plain C arrays. I probably shouldn't care that much since servers are having tons of 0RAM these days

That "tons of RAM" isn't always true. My server is a lower-end VPS, so I have a mere 512 MB RAM: one-eighth as much as my *budget-range laptop*. But it's been fine for me so far, especially since I don't run JVM on it. (I know I could use a dedicated physical server and easily get far more RAM, but I *love* VPS hosting - all the many benefits of an external web host (ex: not having to pay for my own T1 or better), but without the near-total lack of control or the impossibility of finding a company that knows what they're doing.)

Anyway, I'd love more RAM and I will certainly get it when I need to, but every double-ing of my server's RAM will double my hosting costs - and doing that just for the sake of downgrading from a great language like D to a mediocre one like Java (even if it's J8+) wouldn't make very good business sense ;) Higher costs *plus* lower productivity and morale...yea, not exactly a great deal ;)

My main point, of course, being: "Tons of RAM" isn't *always* the case for servers. Thank goodness for D :)

24-Feb-2013 00:18, Nick Sabalausky пишет:
> On Sat, 23 Feb 2013 23:22:54 +0400
> Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>>
>> A trivial example is storage of pairs or tuples. That plus using
>> Java's containers makes memory footprint explode. At 100K+ hash-map I
>> notice quite high factor of waste. It's some double digits compared
>> to plain C arrays. I probably shouldn't care that much since servers
>> are having tons of 0RAM these days
>
> That "tons of RAM" isn't always true. My server is a lower-end VPS, so
> I have a mere 512 MB RAM: one-eighth as much as my *budget-range
> laptop*.

Yup, I'm having even half of that but at least it's KVM so I can hack on kernel drivers or at least try IPsec ;)

But here I was talking of real metal beasts sitting in racks and doing *solely* one-two processing task (no matter how stupid does it look).

> But it's been fine for me so far, especially since I don't run
> JVM on it. (I know I could use a dedicated physical server and easily
> get far more RAM, but I *love* VPS hosting - all the many benefits of an
> external web host (ex: not having to pay for my own T1 or better), but
> without the near-total lack of control or the impossibility of finding
> a company that knows what they're doing.)
>

Agreed.

> Anyway, I'd love more RAM and I will certainly get it when I need to,
> but every double-ing of my server's RAM will double my hosting costs -
> and doing that just for the sake of downgrading from a great language
> like D to a mediocre one like Java (even if it's J8+) wouldn't make
> very good business sense ;) Higher costs *plus* lower productivity and
> morale...yea, not exactly a great deal ;)


> My main point, of course, being: "Tons of RAM" isn't *always* the case
> for servers. Thank goodness for D :)
>

+1 Hence my discomfort with Java ;)

-- 
Dmitry Olshansky

On Sat, 2013-02-23 at 23:22 +0400, Dmitry Olshansky wrote: […]
> Would be nice to know if there is something that can represent this C
> snippet without the usual heaps of verbosity:
> enum {
> STATUS_OK = 0,
> STATUS_FAIL_REASON_XYZ,
> ... ad infinitum (but presently dozens)
> };

        enum StatusCodes {
          STATUS_OK,
          STATUS_FAIL_REASON_XYZ,
        }

Is perfectly valid Java.

> There are lots of other cases, but this one is prime.

Job done then, Java is fine for your purposes!

> You might argue for using classes and inheritance + visitor pattern instead of plain switch/state machines. The heaps of boilerplate to write/generate all of "state"/visitor etc. classes argues the other way around.

That used to be the right way of doing it in Java, but as you say too much boilerplate, so the syntax was added to make it all work correctly. There is much more to the Safe Enum pattern implementation in Java. For example see the Planets enum example in the Java documentation.

> (and I suspect the execution speed too)

No point in philosophizing about performance, measurement is the only valid way of making any form of performance comparison.

> > The G1 GC is a significant improvements to Java.
> 
> I guess this depends on the platform you (have to) use?
> BTW I agree that Java's GC is nice, more so the automatic
> de-heapification of modern VMs.

No G1 is just nice.  I think it is standard in JavaSE and JavaEE from 7u6. Not sure about JavaSE Embedded.  Although JavaME is due a re-launch, I think it is dead in the water before being launched.

> A trivial example is storage of pairs or tuples. That plus using Java's containers makes memory footprint explode. At 100K+ hash-map I notice quite high factor of waste. It's some double digits compared to plain C arrays. I probably shouldn't care that much since servers are having tons of RAM these days, and customers throw money on equipment without second thought. Thus for the moment I just can't help but notice. Thank god we are mostly I/O bound.

Java is a big memory user, anyone trying to claim it isn't is living in cloud cuckoo land. But the memory does get used efficiently in modern JVMs especially with the G1 GC.

I can't see D ever really competing with Java or any other JVM-based language as JVM-based shops won't even consider D (or C or C++), except in very few circumstances.

> Another example. I had to sort some objects by rating for a bit of processing with ranking. Yet this rating is computed and really doesn't belong with them at all (and needs locking beforehand) and I can't reorder them in place. What I'd do is create an array of tuple link-rating and sort these.
> 
> In Java I have to create a full-blown object and allocate each array slot separately, cool. Not to mention the complete lack of concise tuples.

Without the code it is difficult to comment other than to say, are you using the right data structures for the job? Creating small short-lived objects is now highly efficient on the JVM, especially immutable ones. Support for tuples is interesting: Kotlin just removed them, Ceylon just added them. Java is nowhere!

> Writing functors is a royal pain in the ass too. Anonymous classes doesn't quite cut it on the scale of verbosity/benefit. If there any library that doesn't use reflection like crazy to achieve simple, concise functors, I'd be glad to use it but so far I found none.

Java 8. You'll love it. Lambda expressions aplenty. Interestingly, no need for anonymous classes since it is possible to do call site type inferencing and use method handles and invokedynamic to get it all in place without an object in sight.

> Sorry can't elaborate on exact details here, the work is not open-source by any measure.

In which case if you want help I'm available for consultancy!

> > Far too few programmers use the final keyword properly/effectively.
> 
> In Java programs it can be used very often. I'd say too often since I find it rare to have a need to e.g. rebind an object. As for "a few programmers", well you have to type it everywhere, guess why it's not popular?!

Indeed, we all agree on verbose. Java variables should be single assignment by default and variable only by annotation, but that isn't going to happen now. So final should be typed first and only remove if rebinding is needed.

> 
> Mmm. I report my experience not argument much of anything excpet that it's far from pleasant.

Different people like and hate different languages, this is only natural. I am surprised though how many people stay working in places using languages they do not and cannot begin to like.

> If anything I might convince the team to switch off to Scala, someday. If not the somewhat alien syntax it would be far easier.

Scala has many pluses over Java, but also some minuses, as do the other languages such as Kotlin and Ceylon. There is also Groovy which can be both a dynamic and a static language these days and is closely tied to Java (but without all the verbosity), unlike Scala, Kotlin and Ceylon which have significant impedance mismatch in places.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2013-02-23 at 14:58 +0100, deadalnix wrote:
[…]
> Comparing ant and maven is not appropriate here as maven is a build system + a package manager when ant only builds.

Comparing Ant and Maven is perfectly valid since the goal of both is to build software from source.

> The plugin system of maven is notoriously hellish. This shows 2
> things :
> 1/ That extending the build system is really required, and if not
> permitted from the build file themselves, by plugins to extends
> the descriptive capabilities of the descriptive language.
> 3/ That the benefice of having the build tool and the package
> manager working together is big as people plebiscite it even when
> the system is way worse on many other aspects.

Thank goodness Gradle is available and showing that whilst Maven Central is a wonderful resource, Maven itself is second rate. Ant is fourth rate.

We should note that Gradle and Maven have dependency management including of artefacts. In the Java-verse an artefact may contain many packages.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2013-02-23 at 10:08 -0700, David Gileadi wrote: […]
> I love Gradle!  Official site at http://www.gradle.org, with very good docs including getting started tutorials.

Excellent. So do I, but I am biased. But less so that I was three or four years ago.

> In practice I've found it to be concise and readable compared to Ant/Maven, and (almost ridiculously) easily extended when necessary. IMO if you're doing Java builds it's the hands-down winner.

Also, Gradle handles dependencies properly where Maven doesn't and Ant doesn't even try. Also Gradle handles multi-module projects very well where Maven doesn't and Ant doesn't even try.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

24-Feb-2013 14:34, Russel Winder пишет:
> On Sat, 2013-02-23 at 23:22 +0400, Dmitry Olshansky wrote:
> […]
>> Would be nice to know if there is something that can represent this C
>> snippet without the usual heaps of verbosity:
>> enum {
>> STATUS_OK = 0,
>> STATUS_FAIL_REASON_XYZ,
>> ... ad infinitum (but presently dozens)
>> };
>
>          enum StatusCodes {
>            STATUS_OK,
>            STATUS_FAIL_REASON_XYZ,
>          }
>
> Is perfectly valid Java.
>

You missed the point that these have to be the *real* integer constants
starting from 0. No frigging magic classes please.

Citing Oracle:
 All enums implicitly extend java.lang.Enum. Since Java does not support multiple inheritance, an enum cannot extend anything else.

My thoughts after reading this: "holy crap, they are class instances". Even then we seem to use enums where there is no need for integer constants specifically.

>> There are lots of other cases, but this one is prime.
>
> Job done then, Java is fine for your purposes!

Nice  irony but I've meant the cases for rows of "final static int blah" specifically.

If I had a power to fix a single thing in Java I'd say "remove redundancy".

> No point in philosophizing about performance, measurement is the only
> valid way of making any form of performance comparison.

Right.

It however doesn't prevent one from observing the potential bottlenecks
in e.g. parsing binary packets. Measuring is good but in server/distrubuted
context is highly non-trivial to do correctly.

Like I said earlier the current project (the one I go by) is largely I/O bound (and that's not network but rather the "device" I/O). I did synthetic benchmarks back then and in short visitor sucked.

>>> The G1 GC is a significant improvements to Java.
>>
>> I guess this depends on the platform you (have to) use?
>> BTW I agree that Java's GC is nice, more so the automatic
>> de-heapification of modern VMs.
>
> No G1 is just nice.  I think it is standard in JavaSE and JavaEE from
> 7u6. Not sure about JavaSE Embedded.  Although JavaME is due a
> re-launch, I think it is dead in the water before being launched.

Then it's in Java 7? Okay, now I have a solid argument to bring about the switch to Java 7 :)

Seriously, of course, we tend to switch to whatever is perceived as stable in the "local market". Currently it was Java 6. Newer projects would be 7 I guess.

>> Another example. I had to sort some objects by rating for a bit of
>> processing with ranking. Yet this rating is computed and really doesn't
>> belong with them at all (and needs locking beforehand) and I can't
>> reorder them in place. What I'd do is create an array of tuple
>> link-rating and sort these.
>>
>> In Java I have to create a full-blown object and allocate each array
>> slot separately, cool. Not to mention the complete lack of concise tuples.
>
> Without the code it is difficult to comment other than to say, are you
> using the right data structures for the job? Creating small short-lived
> objects is now highly efficient on the JVM, especially immutable ones.
> Support for tuples is interesting: Kotlin just removed them, Ceylon just
> added them. Java is nowhere!
>
>> Writing functors is a royal pain in the ass too. Anonymous classes
>> doesn't quite cut it on the scale of verbosity/benefit. If there any
>> library that doesn't use reflection like crazy to achieve simple,
>> concise functors, I'd be glad to use it but so far I found none.
>
> Java 8. You'll love it. Lambda expressions aplenty. Interestingly, no
> need for anonymous classes since it is possible to do call site type
> inferencing and use method handles and invokedynamic to get it all in
> place without an object in sight.

From what I read about Java 8 it is tolerable (as the language). Still a far cry from D but largely more usable then now.

>> Sorry can't elaborate on exact details here, the work is not open-source
>> by any measure.
>
> In which case if you want help I'm available for consultancy!
>

Thanks, I'd gladly do.

>> Mmm. I report my experience not argument much of anything excpet that
>> it's far from pleasant.
>
> Different people like and hate different languages, this is only
> natural. I am surprised though how many people stay working in places
> using languages they do not and cannot begin to like.
>

Don't get me wrong here. Java as language is awfully verbose (above all) and lacking some simple features. Of these shortcut-like are the primes ones, I've mentioned functors, also e.g. unsigned data types are very useful sometimes.

Then as JVM platform it's perfectly fine for us at the moment due to it being:
a) mature and largely accepted (the key factor in favor of using it)
b) quite nice selection of tools in the standard library not to speak of reams of 3-rd party code
c) a VM. Like it or not but corps love VMs and safe isolated environments. For us the fact that it's cross-platform also removes quite a bit of pain, plus no memory corruption bugs etc.
d) friendly for plugins and dynamic (re)loading of these

Also given some constraints it turns out to be either code the whole stuff in plain C or split in Java/C parts. The C all the way down is definitely less pleasant.

D would probably fit perfectly were it not for:
a) Not widely recognized but sometimes we may cheat and tell it's C++
b) No support for loading shared libraries (bye-bye sane plugin architecture)
c) Lack of stable 3-rd party libs for pretty much everything
(this is getting better but is not there by miles)

>> If anything I might convince the team to switch off to Scala, someday.
>> If not the somewhat alien syntax it would be far easier.
>
> Scala has many pluses over Java, but also some minuses, as do the other
> languages such as Kotlin and Ceylon.

> There is also Groovy which can be
> both a dynamic and a static language these days and is closely tied to
> Java (but without all the verbosity), unlike Scala, Kotlin and Ceylon
> which have significant impedance mismatch in places.

Yay, Groovy! I've pushed for using it recently for web application in favor of "evolving" some legacy JSP-based hell. BTW you are solely responsible for me ever knowing about it in the first place.

Hmm. An OT question - how hard it is to convert some moderately sized app to Grovvy from Java (just to see if it looses anything in terms of performance, in static mode obviously)?

-- 
Dmitry Olshansky

On Sun, 24 Feb 2013 15:49:52 +0400
Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> c) a VM. Like it or not but corps love VMs and safe isolated environments. For us the fact that it's cross-platform also removes quite a bit of pain, plus no memory corruption bugs etc.

Luckily, modern server hardware should support hardware virtualization,
and most languages/libs are pretty good at cross-platform, so this
one shouldn't be much of a "reason for JVM" anymore like it might have
been ten or so years ago.

On Sun, 2013-02-24 at 15:49 +0400, Dmitry Olshansky wrote: […]
> You missed the point that these have to be the *real* integer constants starting from 0. No frigging magic classes please.

I am not sure why they have to be hardware integers, this is a JVM-based system and hardware integers do not exist. I feel a contradiction between requirements and technology here!

> Citing Oracle:
>   All enums implicitly extend java.lang.Enum. Since Java does not
> support multiple inheritance, an enum cannot extend anything else.
> 
> My thoughts after reading this: "holy crap, they are class instances". Even then we seem to use enums where there is no need for integer constants specifically.

Safe Enum pattern/idiom is indeed all about the representation of the symbols being instances of a class. But small immutable objects are very cheap these days on the JVM.

It is possible Java 9 or Java 10 will remove the primitive types completely so that all variables are reference types leaving it to the JVM to handle all boxing and unboxing internally thus making things a lot more efficient and faster.  Experiments are scheduled and underway, decisions made only once the results are in.

[…]
> It however doesn't prevent one from observing the potential bottlenecks
> in e.g. parsing binary packets. Measuring is good but in server/distrubuted
> context is highly non-trivial to do correctly.
> 
> Like I said earlier the current project (the one I go by) is largely I/O bound (and that's not network but rather the "device" I/O). I did synthetic benchmarks back then and in short visitor sucked.

I'm not sure where "visitor" fits into this, I may have missed something…

[…]
> Then it's in Java 7? Okay, now I have a solid argument to bring about the switch to Java 7 :)

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html

G1 is the default in Java 8, but you have to switch to it in Java 7 if I remember correctly.

> Seriously, of course, we tend to switch to whatever is perceived as stable in the "local market". Currently it was Java 6. Newer projects would be 7 I guess.

Any Java user still planning to stay with Java 6 or earlier and not planning to switch asap to Java 7 will be on their own very quickly and seen and just another legacy problem.

[…]
>  From what I read about Java 8 it is tolerable (as the language). Still
> a far cry from D but largely more usable then now.

Java 8 and Groovy (also Scala, possibly Clojure, Kotlin and Ceylon) will make it hard for any organization with a JVM heritage to even contemplate switching to native.

No matter how good D is compared to C++ or Java, if there is no easy route for take up, D will remain is the traction position it currently is.

[…]
> D would probably fit perfectly were it not for:
> a) Not widely recognized but sometimes we may cheat and tell it's C++

With the current marketing strategy, this is how D is going to remain. D does not have an organization such as Google pushing it as Go has had. Yet there is a strong analogy: Go is C with warts removed and modern stuff added. D is C++ with warts removed and modern stuff added. Go has a small hardcore that is active and outward looking trying to create replacements for all the C and Python codes that people actually use. Go sells itself on the purity of the concurrency model and it object model, not mention GC. D on the other hand has a small hardcore.

> b) No support for loading shared libraries (bye-bye sane plugin architecture)

Go has eschewed all dynamic linking and is making this a feature. But it has a mechanism for being able to call C from libraries. Python has a mechanism for calling C from shared libraries. D is at a disadvantage.

> c) Lack of stable 3-rd party libs for pretty much everything
> (this is getting better but is not there by miles)

Go has managed to attract volunteer labour to write in Go new versions of everything previously written in C other than actual OSs. But even there people are beginning to write OSs in Go.

[…]
> Yay, Groovy! I've pushed for using it recently for web application in favor of "evolving" some legacy JSP-based hell. BTW you are solely responsible for me ever knowing about it in the first place.

Sponditious :-)

> Hmm. An OT question - how hard it is to convert some moderately sized app to Grovvy from Java (just to see if it looses anything in terms of performance, in static mode obviously)?

No tools for this as yet, so down to manual transform. First step though is to run the Java through the Groovy compiler and see what happens. Once you have something compiling you refactor the code replacing Java verbosity with Groovy terseness until there is nothing left to refactor, you have a "pure Groovy" codebase.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder