4 ms·

(I'm not trying to sound condescending, so bear with me) How else would you write software with modular and re-usable components?

by yan 18y ago

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.
darkxanthos 18y ago
I've got 8 minutes til I need to catch the bus. The answer to your question hinges mainly on how you define components. In the Erlang language for example: It is completely functional but threads actually become somewhat stateful and ultimately end up recreating some similar scenarios for OOP programmers. On top of that, functions themselves showcase an even higher amount of reusability at times especially in functional languages because of the prevalence of lists of things and tuples. This prevents an over abundance of duplicate implementations of the same thing that, even though their signatures are identical (or nearly so) can't interoperate because they haven't been specified as exactly the same. So language wide consistency is a big plus for some functional languages. Having said that no one tool is a golden hammer. OOP and Functional programming are just tools and there are others out there. Some not even based on Von Neumann architectures that are even more flexible than the ones we, Von Neumann proggies, are (think data flow architectures for example).
- seiji 18y ago
  A common misconception about erlang is its degree of functional-ness. It isn't completely functional. As Peyton-Jones says, a completely functional language will just sit there and make the computer run hot[1]. Erlang is a well thought out compromise between tying your hands by restricting side effects (the monad approach) and allowing a wide audience of people to be quickly productive. [1]: Changing the temperature of the environment can be considered a side effect thereby rendering the 100% functional language 99.999% functional.
- nailer 18y ago
  > Having said that no one tool is a golden hammer. Clearly you're inexperienced with golden hammer methodology, which provides both a mightier paradigm and a pleasantly horned helmet.
andreyf 18y ago
How else would you write software with modular and re-usable components? Hah! However you want! The first few chapters of Paul Graham's `On Lisp' does a great job covering closures, which can provide elegant encapsulation. But even in Java or C++, objects aren't the only modular or reusable components - consider packages or name spaces, for example. Data types such as streams, arrays, and trees don't have to be classes, either - take a look at Haskell's data types.
Kaizyn 18y ago
Does not functional programming allow you to do just that?

(I'm not trying to sound condescending, so bear with me) How else would you write software with modular and re-usable components?

by yan 18y ago

(I'm not trying to sound condescending, so bear with me) How else would you write software with modular and re-usable components?

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.

darkxanthos 18y ago

I've got 8 minutes til I need to catch the bus. The answer to your question hinges mainly on how you define components. In the Erlang language for example: It is completely functional but threads actually become somewhat stateful and ultimately end up recreating some similar scenarios for OOP programmers. On top of that, functions themselves showcase an even higher amount of reusability at times especially in functional languages because of the prevalence of lists of things and tuples. This prevents an over abundance of duplicate implementations of the same thing that, even though their signatures are identical (or nearly so) can't interoperate because they haven't been specified as exactly the same. So language wide consistency is a big plus for some functional languages. Having said that no one tool is a golden hammer. OOP and Functional programming are just tools and there are others out there. Some not even based on Von Neumann architectures that are even more flexible than the ones we, Von Neumann proggies, are (think data flow architectures for example).

seiji 18y ago
A common misconception about erlang is its degree of functional-ness. It isn't completely functional. As Peyton-Jones says, a completely functional language will just sit there and make the computer run hot[1]. Erlang is a well thought out compromise between tying your hands by restricting side effects (the monad approach) and allowing a wide audience of people to be quickly productive. [1]: Changing the temperature of the environment can be considered a side effect thereby rendering the 100% functional language 99.999% functional.
nailer 18y ago
> Having said that no one tool is a golden hammer. Clearly you're inexperienced with golden hammer methodology, which provides both a mightier paradigm and a pleasantly horned helmet.

andreyf 18y ago

How else would you write software with modular and re-usable components? Hah! However you want! The first few chapters of Paul Graham's `On Lisp' does a great job covering closures, which can provide elegant encapsulation. But even in Java or C++, objects aren't the only modular or reusable components - consider packages or name spaces, for example. Data types such as streams, arrays, and trees don't have to be classes, either - take a look at Haskell's data types.

Kaizyn 18y ago

Does not functional programming allow you to do just that?