"Thinking in types" or "The mind of a programmer"

[totherme]

In a previous post, pozorvlak and I wondered about the differences between the thought processes that goes into writing good static code, and those that go into good dynamic code. We figured that there wasn't a lot out there to help dynamic programmers get the hang of static style thinking, so what follows is a simple little toy example, solved in what I

Comments

Re: unfolding

[totherme]

(a good example of the loose reasoning used in coding here: When I realised that an assumption of mine was wrong, I immediately went on to fix things so that the assumption would be right without actually thinking of whether it has anything to do with how the code is breaking. In this case it was the right thing, not a surprise in a program this short, but in my experience it's usually *not* the right thing to do when working with code that's even slightly more complex)

That interests me...

The theorist in me wants to say "If there's a false assumption in your code, then it's wrong. The bug may not have manifested yet, but Murphey says it will if you ignore it, so you'd best fix it now whether that's the bug you thought you were working on or not."

Having said that, the engineer in me is more like "Oh man, that's gonna open up a huge can of worms: If I fix it so that the assumption holds, then something else will turn out to rely on the thing I changed, and if I try to remove the assumption from the code, then I'll probably have to follow through every dependency from this point out... And I'll have to look see if this assumption is made elsewhere... Maybe it'd be best to just fix the bug I was working on, and see if the code works ok for the cases I'm interested in?"

I'm not sure yet what I think about the relationship between these two guys in my head (though now I look at what I just wrote, I think it's interesting that the theorist in me talked about someone else's code, while the engineer in me talked about his own code ^_^ ).

I think the latter solution would be a lot easier to do if there was an array of tests on hand, defining the cases I'm interested in. Having said that, I think you might well be able to do a similar trick with theory - if you can see what effects the failed assertion will have on the output - you just change the specification to match what you can actually do ;) I guess I kinda did that when I noted that in my implementation split _ [] = [[]] and I didn't care...

Does haskell help reduce the pain of the engineer, and encourage coding in the style of the theorist? I wonder what working haskellers out there do in real-life situations.