"The point i was trying to make in my original post is that complexity doesnt come from language, it comes from design."
If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree. The absence of essential organizational constructs in C is a breeding ground for complexity. Look at Xlib for example, you have to match up discriminated unions properly by hand, which involves keeping track of struct names, typedefs and union field names, all spelled differently and sometimes inconsistently. The resulting code is unnecessarily hard to write, harder to read (at least if "understanding" is a required part of reading) and full of accidents waiting to happen. I do not see how that can fail to translate into design complexity. You just can't cover up those flaws with a design, the underlying mechanism insists on showing through.
Posted Jan 13, 2011 22:31 UTC (Thu) by bug1 (subscriber, #7097)
[Link]
"If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree."
Design _should_ be separate from its implementation, they are separate stages.
But if you are designing as you go then its likely to all turn to shit a few times anyway, the efficiency loss of the language probably isnt significant compared to lost time due to re-writing whole sections of code.
Sobotka: Why GIMP is inadequate
Posted Jan 18, 2011 17:54 UTC (Tue) by daniel (subscriber, #3181)
[Link]
"Design _should_ be separate from its implementation, they are separate stages."
That is the waterfall method. I do not find it as effective or efficient as the iteration method.