Ricky Clarkson's got this, but I just wanted to chime in with a simple observation:
If someone rightfully calls out a disadvantage of your language, retorting with "Real programmers test their code, and that would have caught this", is not going to convince anyone that groovy is a good idea. In fact, it'll turn them off of it. Part of the appeal of any language is its community, and having a blowhard in it is always a bad sign. Duh, yes, we test our code, you don't have to patronize. Duh, yes, if my editor will red-wavy-underline this thing right as I write it, that is vastly superior to having to run a test first to find this issue. int i = "Hello"; You really can't put it simpler than that: This is one area where java has got the drop on groovy. I understand precisely why it's this way, and it is definitely not at all a comment on the general value of groovy itself, but it is a succint and obvious 'proof' that calling groovy 'a strict upgrade to java' is horsepuckey. It's a different language, which is better for some use cases, worse for others. Bout the same for most. On Monday, July 30, 2012 1:54:21 AM UTC+2, Ricky Clarkson wrote: > > I used dynamic typing exclusively from 1986 to 1997, and I've generally > used static typing since but I've always had my hand in dynamic languages > too. I appreciate them and know that there are things that you can do > there that are tricky in a static environment. (define (f x) (f f x)) > doesn't translate to any static language I know of (requires infinite > types) but Scheme handles it without blinking. Python's readability is > amazing and worth taking inspiration from no matter what type system one > implements. Perl's syntactic flexibility is worth, erm, learning from. > Erlang's tuple-matching is a lot like using types pre Java 5. > JavaScript's prototype model shows us that OO isn't necessarily about > classes, Common Lisp's CLOS shows that there can validly be more than one > 'this' in a method call. > > However, none of those, not even JavaScript, take an existing static > language and clone its grammar but change the semantics, then claim to be > an advance over that static language and even source-compatible. > > Compiler help *is* that important because that's what I use to help me > program. Instead of adding lots of if statements I add a type. When I > refactor I tend to do it in such a way that if I or my IDE do it wrong, I > get a compile error. That means avoiding reflection, making sure I have > warnings enabled for nonsensical calls to methods that take Object as a > parameter (.equals, List.contains, etc.), avoiding null or at least using > the @NotNull/@Nullable annotations so that I get static warnings about > possible NPEs. It sounds like more effort than it really is, though I > confess it's getting harder to do that as I get dragged helplessly towards > Java web technologies, which seem to actually prefer reflection over > ordinary method calls. At least the IDEs still provide navigation, but my > brain doesn't at that point. > > A type system also helps in navigating, because the IDE gets a completely > correct picture of the code and can find references, let me navigate > between implementations and declarations of methods, provide accurate code > completion, etc. I imagine Groovy gets some or even all of that, but I > expect there are holes. > > On Sun, Jul 29, 2012 at 7:54 PM, Rakesh <[email protected]>wrote: > >> Ricky, >> >> firstly I did think I may have been a bit harsh in tone and sorry about >> that. >> >> Secondly, your points are from the perspective of static programmer >> *thinking* what it must be like to use a dynamic language. >> >> I suggest you give it a try and then you might find that compiler help >> isn't all that important in the end. >> >> Personally though, I don't care about being able to not define types. I >> actually put them in if its not obvious because I think its cleaner and >> more readable. >> >> Unit testing, actually test driving (TDD) every piece of code I write is >> something I aim for. Do I always manage it? Of course not, and its >> bitten every time with bugs!!! I'm getting better though. >> >> Rakesh >> >> >> On 29 July 2012 17:46, Ricky Clarkson <[email protected]> wrote: >> >>> 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 <[email protected]>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 <[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. >>>> >>> >>> -- >>> 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. >> > > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/P1tShNeGVtEJ. 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.
