Timeline for Do we really need OO languages to manage software complexity?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2017 at 17:35 | comment | added | fishinear | One concrete example is naming: the 'setName' function in a procedural language should actually include the module name: 'personSetName'. Otherwise it will lead to conflicts during linking. In OO languages you don't need to think about that. Anything that you don't need to think about makes programming easier. | |
| Mar 21, 2017 at 15:46 | comment | added | Nick Keighley | C effectively has these things. It has modules (.c files) with interfaces (.h files) and it can have public (extern) and non-public (extern) methods (functions). You can even have poor man's polymorphism with arrays of function pointers, I'm not saying OO is easy in C (or perhaps, sane) but encapsulation is pretty easy, | |
| Mar 20, 2017 at 14:01 | comment | added | Luaan | @steakexchange In ML-family languages, modules work great, and in combination with lambdas, they give you all the power of any OO language (after all, a function is an interface with a single method - isn't that almost what's recommended by "good code" guys in OO? :P). For various reasons, they're still less used than the more procedural languages like C++ or Java, but they do have their appeal, and many people are trying to educate people about how they can simplify their life (with more or less success). | |
| Mar 20, 2017 at 13:59 | comment | added | Luaan | @steakexchange Do note that OOP was developed a time where many procedural languages didn't have modules like that. Some wouldn't even call such languages procedural. Indeed, there's nothing that says a procedural language must not be OO or vice versa. Be careful of labels - they can easily mislead you. If your procedural language supports modules that have public and private fields and procedures, good for you :) The main difference between "traditional procedural" and "OOP" is that the call dispatch is more flexible in OOP - indeed, in strict OOP, you never know what code you call. | |
| Mar 20, 2017 at 10:58 | comment | added | user62575 | I guess my answer is that if you want to do this sort of thing, you're going to have to write special tooling and language constructs to do so (for example, a special 'include' call to a include one file that may not be included elsewhere). Once you've started down that path, you've actually started implementing an object oriented language in your own way. For example, C++ was originally a preprocessor which produced plain C, and I suspect once you're implementing your system it looks a lot like C++ on top of C. | |
| Mar 20, 2017 at 10:47 | comment | added | steakexchange | I am not sure if you understood my question correctly. I am already aware of encapsulation and data hiding as a way to manage complexity. I just think that this can be easily done in procedural languages aswell by dividing the program into modules that perform well-defined simple tasks whose inner workings are specified in separate protected sources. So why OOP when we can do those things in procedural languages? That is my question. | |
| Mar 20, 2017 at 10:31 | history | answered | user62575 | CC BY-SA 3.0 |