On Monday, July 30, 2012 12:24:13 PM UTC+2, rakesh mailgroups wrote: > > > As for unit testing, I actually use them to design my code: > > "now I need my code to do this, so I am going to pass these arguments in > and expect this back" > > rather than > > "if i pass this, then I expect that" > > Subtle but important point. Its not about exhaustive input testing. >
I'm not sure how far off-topic we've veered here, but if this is a motion to indicate certain programming languages are more productive than others, beware second go-around syndrome. It usually applies to the idea that you feel a newer project is so much better designed than a much older one. Yeah, that makes sense - you know more about the problem domain, etcetera. Same applies to trying to gauge a programming language's productivity when language A is the one you learned to code with and you've now delved into language B. Yeah, it's going to feel like lang B is 'better' somehow. It's not the language; it's you. Scientific research would require that you eliminate that variable and that's not exactly an easy task. There is nothing stopping you from writing java code tests-first. > Rakesh > > > On 30 July 2012 11:06, Fabrizio Giudici <[email protected]<javascript:> > > wrote: > >> On Mon, 30 Jul 2012 11:51:45 +0200, Rakesh >> <[email protected]<javascript:>> >> wrote: >> >> 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, this is not only religious but I think that people have many >> points here. Kevin just pointed out that unit testing can't be complete. It >> would be complete only if one submitted to any piece of code all the >> possible combinations of inputs. Of course, this is theory: in practice, it >> would suffice to submit all the practical combinations of inputs. This can >> be quite large. The fact that you didn't experience problems so far is not >> necessarily a strong point: see the inductivist turkey argument by Russel / >> Popper. In practice, you might feel strong for a lot of time, until you get >> burned. Of course, this is still theory, and in practice I'd say that >> personal experience, given that we have a sufficient bunch of data, is an >> indicator... for that person. >> >> Let's put this in another way. I think it's a very strong point to say >> that without static typing you loose lots of benefits. Now, we can afford >> to lose something in change of something more interesting. What's the >> benefit you get with Groovy. When I answered in the previous mail exchange, >> my point was that with my experience with Groovy I didn't get much in >> return: just writing a few less line of code is not enough, and if it was a >> very important point to me I'd rather consider alternatives such as Scala, >> which allows less lines of code and it's static. >> >> >> >> -- >> Fabrizio Giudici - Java Architect, Project Manager >> Tidalwave s.a.s. - "We make Java work. Everywhere." >> [email protected] <javascript:> >> http://tidalwave.it - http://fabriziogiudici.it >> > > -- 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/-/l6ODwooPrGkJ. 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.
