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⑈