3 ms·

I think you're throwing out the baby with the bath water. The fact that unfamiliarity can be mistaken for complexity does not mean that complexity is impossible

I think you're throwing out the baby with the bath water. The fact that unfamiliarity can be mistaken for complexity does not mean that complexity is impossible to recognize or avoid. There are some cases where you can, for example, radically simplify a complex algorithm by using an unfamiliar toolkit (Feynman diagrams, Lisp, etc.) but there are also cases where a solution is obviously more complex than it needs to be even within its existing framework.

gruseom 15y ago
Oh, I don't claim that complexity is impossible to recognize. It's really important to do so. But how? Most judgments of complexity we currently make have a lot to do with familiarity. (Is the 40-line spreadsheet program at http://www.nsl.com/k/s/s.k http://www.nsl.com/k/s/s.k complicated or simple?) You assume something similar when you say "obviously more complex than it needs to be". When is complexity obvious? When it exceeds what we habitually consider ok. What we really need is an objective measurement. Do we have one? We sort of do, insofar as the research on this seems to point in one direction: shorter programs are simpler. That doesn't answer every question - you still need a way of measuring program length and defining what a program is - but it's the beginning of an objective answer.
- stcredzero 15y ago
  For evaluating a refactoring or using a library/framework, you can compare the number of statements that would be used to add a given feature before vs. after the refactoring. What's harder is to evaluate the effect of adopting a certain pattern or framework will have on the cost of future refactorings. I don't think people do even a back of the envelope estimation of even just the first number. The number of statements put in can probably be used to estimate the cost in man hours.
  - gruseom 15y ago
    My preference would be to put it in when it pays for itself (i.e. makes the code smaller) and not before. Otherwise it's too easy to fall victim to one's own spin.
- losvedir 15y ago
  It boggles my mind every time I see that spreadsheet program. It's probably one of the tersest bits of code I've ever seen. Here's an overview of the spreadsheet program that's implemented and a walk through a bit of the code: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm

gruseom 15y ago

Oh, I don't claim that complexity is impossible to recognize. It's really important to do so. But how? Most judgments of complexity we currently make have a lot to do with familiarity. (Is the 40-line spreadsheet program at http://www.nsl.com/k/s/s.k http://www.nsl.com/k/s/s.k complicated or simple?) You assume something similar when you say "obviously more complex than it needs to be". When is complexity obvious? When it exceeds what we habitually consider ok. What we really need is an objective measurement. Do we have one? We sort of do, insofar as the research on this seems to point in one direction: shorter programs are simpler. That doesn't answer every question - you still need a way of measuring program length and defining what a program is - but it's the beginning of an objective answer.

stcredzero 15y ago
For evaluating a refactoring or using a library/framework, you can compare the number of statements that would be used to add a given feature before vs. after the refactoring. What's harder is to evaluate the effect of adopting a certain pattern or framework will have on the cost of future refactorings. I don't think people do even a back of the envelope estimation of even just the first number. The number of statements put in can probably be used to estimate the cost in man hours.
- gruseom 15y ago
  My preference would be to put it in when it pays for itself (i.e. makes the code smaller) and not before. Otherwise it's too easy to fall victim to one's own spin.
losvedir 15y ago
It boggles my mind every time I see that spreadsheet program. It's probably one of the tersest bits of code I've ever seen. Here's an overview of the spreadsheet program that's implemented and a walk through a bit of the code: http://www.nsl.com/papers/spreadsheet.htm http://www.nsl.com/papers/spreadsheet.htm