Thanks for the ad hominem, this list was short of that. The example is simply a reduction of what real cases often boil down to. If I decide to change Point to Dimension throughout my code I *want* my compiler, not my users, to tell me when I missed a case. I'm not seriously suggesting that the example I gave itself is the real problem, it's just the shortest way to demonstrate it that I know of.
I find it insane that a language lets me add type annotations as if I were writing in a typed language, and then does nothing with them until runtime. That was actually the subject of early Groovy hype, with lines like "It's statically typed at runtime!". I can't find quotes now, that stuff has validly disappeared from the Internet. " 3. As a professional programmer, I thoroughly unit test my code. A piece of code like that won't get far before its caught. " But is every piece of code you have to maintain thoroughly unit tested? I expect that others don't do the same as you in all cases. Do your unit tests always catch everything a type checker would? Perhaps so, but armed with a type checker you can write in different ways that help the type checker catch more errors and without the repetitive boilerplate that unit tests can be. On Sun, Jul 29, 2012 at 12:51 PM, Rakesh <rakesh.mailgro...@gmail.com>wrote: > 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 <ricky.clark...@gmail.com> wrote: > >> That can't happen with shared mutable objects. >> On Jul 23, 2012 3:46 PM, "Russel Winder" <rus...@winder.org.uk> 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:russel.win...@ekiga.net >>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk >>> 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 javaposse@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscr...@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 > "Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@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 "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
