Mark Wooding <m...@distorted.org.uk> writes: > Some people (let's call them `type A programmers') have decided that > they want to be assisted with writing correct programs... > Other people (`type B programmers') don't like having their (apparently? > possibly?) correct programs rejected.... > I think trying to persuade a type A programmer that he wants to work > like a type B programmer, or /vice versa/, is difficult, bordering on > futile. Type A stereotypes type B as a bunch of ill-disciplined > reckless hackers; type B stereotypes type A as killjoy disciplinarians. > Meeting in the middle is difficult. (`We just want to add a little > safety.' `You want to take away our freedom!' Etc., /ad nauseam/.)
That's an interesting analysis. You know, I think I'm really a type B programmer, interested in type A techniques and tools for the same reason someone who naturally sleeps late is interested in extra-loud alarm clocks. Also, the application area matters. There is a difference between programming for one's own enjoyment or to do a personal task, and writing programs whose reliability or lack of it can affect other people's lives. I've never done any safety-critical programming but I do a fair amount of security-oriented Internet programming. As such, I have to always assume that my programs will be attacked by people who are smarter than I am and know more than I do. I can't possibly out-think them. If I don't see problems in a program, it's still plausible that someone smarter than me will spot something I missed. Therefore, my failure to detect the presence of problems is not reassuring. What I want is means of verifying the absence of problems. Finally, your type-A / type-B comparison works best regarding programs written by one programmer or by a few programmers who communicate closely. I'm working on a Python program in conjunction with a bunch of people in widely dispersed time zones, so communication isn't so fluid, and when something changes it's not always easy to notice the change or understand the reason and deal with it. There have been quite a few times when some hassle would have been avoided by the static interfaces mandated in less dynamic languages. Whether the hassle saved would have been outweighed by the extra verbosity is not known. Yeah, I know, more docs and tests can always help, but why not let the computer do more of the work? > Haskell is interesting: it can provide a surprising degree of > freedom, but it makes you work /very/ hard wrangling its type system > in order to get there; and again, I found I had most fun when I was > doing extremely evil unsafePerformIO hacking... I've found Haskell's type system to work pretty well for the not-so-fancy things I've tried so far. It takes some study to understand, but it's very uniform and beautiful. I'm having more trouble controlling resource consumption of programs that are otherwise semantically correct, a well known drawback of lazy evaluation. The purpose of unsafePerformIO is interfacing with C programs and importing them into Haskell as pure functions when appropriate. Anyway, at least for me, Haskell is fascinating as an object of study, and a lot of fun to hack with, but doesn't yet have the creature comforts or practicality of Python, plus its steep learning curve makes it unsuitable for projects not being developed by hardcore nerds. The ML family avoids some of Haskell's problems, but is generally less advanced and moribund. Pretty soon I think we will start seeing practical successor languages that put the best ideas together. -- http://mail.python.org/mailman/listinfo/python-list
