On Mar 12, 12:26 am, Jon Harrop <j...@ffconsultancy.com> wrote: > On Thursday 12 March 2009 00:01:43 James Reeves wrote: > > This doesn't have to be the case. There is nothing inherently magical > > about a types that makes them more concise to define than a unit test. > > Type inference: you don't write anything and the compiler infers your implicit > constraints.
That's true enough. You could get away with a few less lines by not explicitly defining your types. Though you obviously lose some type safety. I've written code that was implicitly typed that caused subtle bugs because the types weren't quite what I thought they were. There are also instances where the compiler requires you to explicitly type something, especially when you're dealing with GADTs or existential types. > Same amount of code but the compiler will now prove that the container can > never be empty. It's still a very simple check. Types can only handle very simple predicates, but simple predicates are also very easy to unit test. > With unit testing, you must create tests for every function that > handles the container and try to find cases where it erroneously > produces an empty result. But if you're programming correctly, there'll only be a few functions that modify the container directly. Honestly, it sounds good in theory, but I've never really run into any problems where this would have been /that/ useful. Even in Haskell, I can't think of many times I've needed a type like this. > I believe brevity is a major benefit. I find macros and homoiconicity more useful to brevity than type definitions. I occassionally miss having type inferred monads, but surprisingly not that often. On the other hand, I miss having homoiconicity and macros every day I go to work. > IME, the trouble can be well worth it. I once wasted two weeks trying to track > down bugs in a thousand lines of code using unit tests and never managed it. > When I finally caved in and tried to leverage the static type system instead, > I fixed all of the known bugs in 24 hours. I've been programming for quite a while, but I can't say I've ever encountered a problem like that. There was an interesting Google tech talk I listened to a while ago, where presenter talks about the relationship between theorems and type systems (i.e. Curry-Howard Isomorphism) in Haskell. I recall the presenter briefly musing about whether Lisp macros also have a link to types, as whenever he programs in Lisp, he seems to find no need for types. I'm not sure I agree that macros have any relation to types, but it is true that I don't seem to miss static typing much. Out of interest, have you done much work in Lisp? Or in a strongly functional Lisp like Clojure? > That will depend very strongly on your application. If you are using the > applications I described before where static typing offers little advantage > (essentially because the problem is inherently dynamic) then you would not > expect to see a difference. Maybe it's just me, but most problems I've encountered seem to be solved better in dynamic languages :) - James --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
