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 <rakesh.mailgro...@gmail.com> 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 <ricky.clark...@gmail.com> 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 <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. >> > > -- > 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.
