On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote: > At 10:40 PM +0200 2005/8/10, mt wrote: > >... Languages with > >static typing would be more suitable if programs were something you thought > >of in advance, and then merely translated into code. But that's not how > >programs get written. > > Well, that is actually how lots of programs do get written. > > For software that is experimental and exploratory, whose code > undergoes continual change and whose only users are the code's > authors, static typing is arguably a dispensable nuisance. A type > error that pops up during execution is probably no more inconvenient > than one that's caught by static type checking. That's why Lisp is > popular for AI work.
I find pretty much completly the opposite is true. for random hacking and evolving code, static typing is essential. There is only so much room in one's brain to keep track of how everything works. if you were meerly translating from a previous design, this isn't so much an issue. but when writing code that is evolving and changing and perhaps you don't quite know how it will turn out, your ability to recall and understand how everything works together is a major limiting factor on the scope of what you can acomplish. Static typing offloads a _ton_ of responsibility away from the programmer. you no longer need to worry or even think about what types are held in variables because you know any mistakes will be caught by the compiler. and with haskell's advanced type system, you can encode much more advanced constraints and invarients in the type system offloading even more work from your brain. Haskell's strong type system made me writing jhc alone possible, not because of the better reliability (that is great though!), but because it let me 'forget' about so many inconsequential details that they type system enforced so I only needed to use brain-space for high level constructs and my overall evolving, changing, plan. I tend to only use perl or other dynamically typed languages when writing something that I know exactly what it will do and how to do it beforehand, because I find it to be quite an inflexible language when it comes to changing code after the fact, not because of any syntatic difficulty, but because you basically have to constantly redervive everything the program does and all the unspoken invarients to understand it and how to change it. which is something that gets super-linearly harder as code size grows. John -- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell