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.

Reply via email to