3 ms·

modular and re-usable components is not really OO specific tho.

by mlLK 18y ago

yan 18y ago
That didn't answer my question though. You can technically convert any programming paradigm to anything that is touring-complete. Just because something is designed with OO methods doesn't mean that it can not be designed any other way. Original C++ compilers simply converted C++ code to C. But seriously, if you had to write software that abstracts complexity (good), has modular components (good) and let's you attack specific problems one at a time, how would you do it? If you don't think these are worthwhile tenets of software engineering, what are, in your opinion?
- jganetsk 18y ago
  Research into statically typed functional languages approaches this question, and generates some pretty good insight. It turns out that OO is sort of a religion... just one approach to modularity and abstraction. Languages like ML and Haskell provide these features in a completely non-OO style, and are very expressive and powerful. If you are curious, look at abstract data types and polymorphism in SML/OCaml and Haskell. Also, look at Haskell's type classes, and look at SML/OCaml's module system. Here's a paper you can read: http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT...
- mlLK 18y ago
  This is sort of resonating with me. Maybe I've been doing to many exercises by the book, I dunno, but your description of the problem space seems straight out of a textbook which I'm all to familar with. Divide and conquer; define the data set, factor, isolate, call foo, iterate. . .expressions, storage space, and iterating each as a function is not hard, in short deducing a problem set in terms of an operation is not hard for me, since an operation, to me at least, is synomous with run-time, which is why I thought I was programming. . .a compositon of operations in terms of input and output. I understand that each approach is borrowing similar tenents of refactoring input, but I don't understand how the composition of operations are playing in terms of code-time vs run-time.

modular and re-usable components is not really OO specific tho.

by mlLK 18y ago

modular and re-usable components is not really OO specific tho.

yan 18y ago

That didn't answer my question though. You can technically convert any programming paradigm to anything that is touring-complete. Just because something is designed with OO methods doesn't mean that it can not be designed any other way. Original C++ compilers simply converted C++ code to C. But seriously, if you had to write software that abstracts complexity (good), has modular components (good) and let's you attack specific problems one at a time, how would you do it? If you don't think these are worthwhile tenets of software engineering, what are, in your opinion?

jganetsk 18y ago
Research into statically typed functional languages approaches this question, and generates some pretty good insight. It turns out that OO is sort of a religion... just one approach to modularity and abstraction. Languages like ML and Haskell provide these features in a completely non-OO style, and are very expressive and powerful. If you are curious, look at abstract data types and polymorphism in SML/OCaml and Haskell. Also, look at Haskell's type classes, and look at SML/OCaml's module system. Here's a paper you can read: http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT...
mlLK 18y ago
This is sort of resonating with me. Maybe I've been doing to many exercises by the book, I dunno, but your description of the problem space seems straight out of a textbook which I'm all to familar with. Divide and conquer; define the data set, factor, isolate, call foo, iterate. . .expressions, storage space, and iterating each as a function is not hard, in short deducing a problem set in terms of an operation is not hard for me, since an operation, to me at least, is synomous with run-time, which is why I thought I was programming. . .a compositon of operations in terms of input and output. I understand that each approach is borrowing similar tenents of refactoring input, but I don't understand how the composition of operations are playing in terms of code-time vs run-time.