On Tue, Mar 10, 2009 at 9:31 PM, Jon Harrop <j...@ffconsultancy.com> wrote:
[...] > > > 2. The whole thing does not need to be complete or even functional for > > you to start unit testing. > > Apples and oranges: unit tests are not the same between dynamic and static > code bases because dynamic code bases rely upon a huge number of additional > unit tests to serve as a poor man's substitute for static type checking. > I'd love to see some evidence to support this claim of "huge number of additional unit tests". Unit tests are there to check that a small part of a program behaves correctly under expected conditions. Static type checking only guards against a small set of errors in program correctness, primarily the accidental use of a wrong type. In a dynamically typed language there are two ways to deal with this: a) add explicit type checks at runtime to guard against an invalid type b) add unit tests to verify that the explicit type checks work as expected. The increase in unit testing therefore is directly related to number of areas where I am concerned about receiving an improper type that must be explicitly guarded against. For example in Python strings are iterable, but in a lot of functions that expect an iterable object receiving a string is often a sign of a mistake, so I have a few of those functions explicitly check that they are not dealing with strings. Situations like these are rare however so I've never seen a significant increase in unit testing to compensate for lack of static type checking. [...] > > > 4. Not having the static type system means that if it's ever needed, > > it will be possible for you to do what you know is right instead of > > what the compiler wants. > > You are assuming that what you know is right and what the compiler wants > are > different. IME, that is virtually unheard of in real code. > Actually it happens a lot in real code and in many non-trivial programs in static typed languages you end up with a proliferation of types that are simply there to make the compiler happy. To me it happens very often where I know what I want: to pass an object of type B into a function f that expects type A, because I know that B is sufficiently A-like to allow function f to work. > > Most of the reasons given in this thread were red herrings and many of > static > typing's real issues were not even touched upon: > > . Implementing modern static type systems correctly is really hard. > Consequently, the vast majority of new languages are dynamically typed > because that is much easier to implement. > I agree that implementing static type systems correctly is hard, and that dynamic type checking is easier, but I'm not willing to just agree that many languages use dynamic typing simply because it is easier. For example I prefer writing code in dynamically typed languages most of the time, so if I was to write a new language I would make it dynamically typed because that is my preference, not because it is easier. I can imagine that there is some subset of language designers that really would prefer to use a statically typed language but end up not implementing it because of the difficulty, but I'm not willing to just accept that they are the vast majority. -- Cosmin Stejerean http://offbytwo.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
