Content deleted Content added
m Signing comment by 96.45.180.110 - "→List of "modular programming" languages: " |
|||
Line 85:
I would not consider #include to be a rudimentary form of modular programming, it may allow for it, but it really has nothing to do with it. C is completely capable of being fully modular, if not more so than others due to it's low-level memory access.
Neither would I. But it is an attempt to emulate modular principles with what is available. That is something else than being a modular language. (iow the concept vs the language support).
I'm not sure if C can be considered modular. The meaning of an header can be modified by the preprocessor history till then, and thus does not uniquely represents an interface to an implementation
I've no clue what the memory access remark is supposed to demonstrate?
[[Special:Contributions/88.159.64.210|88.159.64.210]] ([[User talk:88.159.64.210|talk]]) 10:40, 10 May 2011 (UTC)
I would describe modular programming as analogous with [[legos]]. You start at some point, and build up. Each block is a piece of the greater structure. You can move blocks (or groups of blocks) to other structures copying their functionality to the new structure without everything falling apart. They´re both interdependent, and independent at the same time. The whole part in the article about trying to minimize dependencies is absolutely wrong, it's more the direction that the dependencies are going, they should be upper to lower. As in no foundational component can be reliant on a component that is less foundational. That is to say, lego blocks sit on each other, therefore they rely on their foundation, not the other way around. There my 2 cent. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/96.45.180.110|96.45.180.110]] ([[User talk:96.45.180.110|talk]]) 00:11, 27 December 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
| |||