*sigh* so hoped this thread would not end up where others have gone. Its one of the reasons I tried to keep it personal as I am a pretty typical Java programmer used to static compilation.
I can try and address/challenge points as they get raised. Its NOT because I am an evangelist for Groovy. Its not *my* language. int i = "hello" I can't be blamed for silly examples. I realise (now) that its meant to represent a bigger issue about losing compile time checking rather than someone writing silly code. I am saying, that in practice, this check at not happening at compile time, based on my personal experience, has not been a show stopper. At all. Unit testing definitely made this a non-issue for me. That may not be the only solution. I seem to have stumbled into a 'religious' issue here and there's not much I can say to convince you that static compilation hasn't prevented me from being way more productive than before. Rakesh On 30 July 2012 01:17, Reinier Zwitserloot <[email protected]> wrote: > 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 javaposse+unsubscribe@* >>>>>> *googlegroups.com <javaposse%[email protected]>. >>>>>> For more options, visit this group at http://groups.google.com/** >>>>>> group/javaposse?hl=en<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 javaposse+unsubscribe@** >>>>> googlegroups.com <javaposse%[email protected]>. >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/javaposse?hl=en <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 javaposse+unsubscribe@** >>>> googlegroups.com <javaposse%[email protected]>. >>>> For more options, visit this group at http://groups.google.com/** >>>> group/javaposse?hl=en <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 javaposse+unsubscribe@** >>> googlegroups.com <javaposse%[email protected]>. >>> For more options, visit this group at http://groups.google.com/** >>> group/javaposse?hl=en <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. > -- 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.
