4 ms·

From the Haskell reddit discussion: > It's a simple truth, indeed a tautology, that if you want the compiler to check the consistency of interactions between m

• swannodette 15y ago
  The blog post isn't about correctness - it's about modularity. Lispers and Smalltalkers are used to programming with very small compilation units - individual methods and individual functions. Being able to fix running programs w/o going through the whole compile cycle is a demonstrable productivity gain. Types and modularity are at odds. The antagonism is readily apparent in languages that support dynamic and static typing - Qi. It's RCEPL (Read-Check-Eval-Print-Loop) has serious restrictions in comparison to its standard REPL.
  • jamii 15y ago
    I suppose turning type errors into type warnings would satisfy both camps. That way you can experiment with incremental changes and then fix up the rest of the program when you are ready. Erlang + dialyzer works quite nicely like this.
  • dons 15y ago
    > Being able to fix running programs w/o going through the whole compile cycle is a demonstrable productivity gain. Indeed! Removing many sources of runtime failures at compile time is also a demonstrable productivity gain. So good thing that static typing is no barrier to dynamic extension or modification -- however, you must defer type checking of splice points between components until later stages. (This was my PhD thesis).
    • swannodette 15y ago
      The act of verifying types defeats modularity. I think static typing is grand, but Gilad has a valid point.
      • deleted 15y ago
        [deleted]
      • jrockway 15y ago
        This is a serious "citation needed" assertion. What language doesn't verify types? Python does. Lisp does. ("TypeError: cannot concatenate 'str' and 'int' objects" or "wrong-type-argument: stringp 42") I think the problem that people run into with types is when storing values for future use. Imagine that you have a data structure that looks like: data Foo = Foo String And then later on in your application, you have a function like: frobnicate :: IsString a => a -> a Then, you write a program that looks like: program :: String -> String program = frobnicate . preprocess . Foo This is all well and good as long as you only want your program to operate on Strings. But if you want to change the type of your string data (perhaps to a more efficient "ByteString", or something like that), then you are kind of out of luck. You pigeonholed yourself into using String when you defined Foo as "Foo String", and now you have a lot of work to do to feed that ByteString to the function that actually cares about the type, "frobnicate", which can already handle ByteStrings. The problem here is not type checking, but rather that you built your program in terms of an abstraction that was not generic enough, namely the "Foo" type. If you were just using Python, then your program would have been: class Foo: def __init__(self, string): self.string = string; def frobnicate(whatever): return whatever In this case, there would be no trouble using whatever type you wanted as the "string", because you decide what type is OK at "frobnicate" time, instead of at compile time. The downside is that with your too-specific Haskell program, you know it's too specific before you run it (because the compiler whines at you), but with the Python program, you may only find out when your pager starts making a loud noise at 3 AM, because Python has no idea what you're trying to do. (Personally, having worked on a huge Python app that does no type checking anywhere, I have to say I hate that technique. I prefer what I do in Perl, which is to type check on object creation, but use type classes instead of concrete types. You can still "late bind", but you also get errors when you're making a mistake rather than deferring a decision. You can do the same thing in Haskell, too, but with even better guarantees that you won't be waking up in the middle of the night to unfuck your code.)
• cageface 15y ago
  Indeed. Types are useful because they span module boundaries. I've been working in Scala and C++ lately after working for ten+ years exclusively in dynamic languages and I can't tell you how happy I am to let the compiler catch my dumb mistakes. IMO, dynamic languages optimize for the rare need for freeform metaprogramming at the expense of the common need for easily maintained code. Dynamic language enthusiasts will tell you that testing is better than static typing but in my experience static typing eliminates about half my test code and gives me much more immediate and precise feedback on my most common errors.