This is not directly related to Haskell, but it's a thought that occurred
to me after exposure to the Haskell community.
I've spent most of the past 15 years doing scientific programming. The lead
software architect and software managers are using good software
engineering practice, though (this is *scientific* programming, not
*programming by scientists*, ha ha). But, there is a particular culture in
my company that has become more obvious to me by contrast to the Haskell
community.
I call it "design by negation." When asked to justify his design, the lead
software architect explains everything that *wouldn't* work. "We couldn't
have a unique key for every entry because blah blah blah. We couldn't use a
garbage collector because blah blah. We couldn't write a sugar layer
because then you have to document it separately blah blah." So the chosen
design seems to be the only thing left after eliminating everything you
can't do.
I want to aspire to "positive design." I want to list the goals, and think
of design as making clever choices that meet all the goals.
I don't mean to suggest that design is never constrained. It often is. But
it's a mindset I'm talking about. I don't like this mindset of design by
negation.
-Mike
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
