9 ms·

OOP vs Procedural Code

53 points by dave1010uk 14y ago

debacle 14y ago
I disagree with this somewhat. The biggest gain for large pieces of software from OOP is encapsulation, and in that regard writing loosely-coupled procedural code within classes will provide you will proper encapsulation. You can't get away from writing procedural code completely, because chances are you're writing a procedure, so even if you're thinking about state transforms rather than a list of actions to take, you're still writing procedurally.
- danieldk 14y ago
  The biggest gain for large pieces of software from OOP is encapsulation, But before OO languages became popular, people encapsulated data by using opaque pointers. It can be argued that OO-programming promotes encapsulation, but in practice it is not hard to accidentally leak the internal state of data (especially in languages that only provide boxed data types). Also, in (some) functional languages, encapsulation is comparably obtained by not exporting the constructors of a data type. So, I am not convinced that encapsulation is in any way an exclusive or even defining property of OOP.
  - debacle 14y ago
    That's all well and good, but that's not what wikipedia says.
    - simonbarker87 14y ago
      Are you implying that wikipedia is the authority on all topics? Given it can be edited by anyone at anytime I would suggest that comments on HN or elsewhere are no more or less valid than what wikipedia says
      - debacle 14y ago
        > comments on HN or elsewhere are no more or less valid than what wikipedia says I'm not going to be dragged into a discussion based on such a ridiculous premise.
  - seanmcdirmid 14y ago
    OOP is defined primarily by its ability to abstract and encapsulate data (and state) in objects. See William Cook's paper on "On Understanding Data Abstraction, Revisited." Of course, there are other ways to encapsulate state; e.g., as monads; OOP doesn't promote encapsulation so much as it promotes encapsulation using objects. The second defining aspect of OOP is messaging (goes along with encapsulation); Alan Kay has more to say about that (just check out Message Passign on wiki). The third is probably dynamic dispatch and polymorphism; not all OOP languages have that. I've dealt with plenty of weird non-procedural OO languages (including my own) with no recognizable procedure construct, but this is a much more controversial position as there are no mainstream non-procedural OOP languages out there (Erlang?). However, procedural programming is mostly orthogonal to OOP, which is what I think the blog post is trying to get across?
    - danieldk 14y ago
      OOP is defined primarily by its ability to abstract and encapsulate data (and state) in objects. I cannot help but thinking this is a tautology: 'Programming with objects is defined by putting data in an objects.' What is an object? How does it defer from other data structures where its members are hidden to the outside world? I am not arguing that OOP does not exist, just that one aspect that has always been touted as one of its greatest advantages, also exists in most non-OO languages. The second defining aspect of OOP is messaging (goes along with encapsulation); Alan Kay has more to say about that (just check out Message Passign on wiki). The third is probably dynamic dispatch and polymorphism; not all OOP languages have that. Is message passing without dynamic dispatch and polymorphism really message passing? (In contrast to a function call that has a structure as an implicit argument?) there are other ways to encapsulate state; e.g., as monads A data type is a monad if a function is provided that defines how computations of that data type can be combined[1], and that function obeys the monad laws. A monad can be used to combine effectful computations (IO, ST) or threading state through function calls (State). But e.g. the list, Maybe, or Either monads have little to do with state. [1] Excluding 'return' for brevity ;).
      - seanmcdirmid 14y ago
        Monads can be used to encapsulate state, they are used for other things. You can use objects to encapsulate state, or you can use another style of data abstraction, whatever floats your boat. OOP has no unique capabilities, you just get to design your programs around objects, which is good enough for me. Its all about design.
shasta 14y ago
No, please. OOP does not have a monopoly on abstraction, encapsulation, modularity, etc. If you are focused on "state transformations and encapsulated abstractions", you're not necessarily writing OOP.
- debacle 14y ago
  I agree, but I would state that it's easier to do encapsulation and modularity in OOP than procedural style. I prefer the functional method, though. In my opinion it's much easier to understand and much more flexible, but many programmers dislike that flexibility.
  - ufo 14y ago
    "Procedural style" is a strawman though, corroborated by years of people thinking C and FORTRAN are the only procedural languages out there. Most OOP languages are still procedural and many "traditional" procedural languages provide support for data abstraction.
    - debacle 14y ago
      The syntactical sugar provided by languages that support objects is the only real improvement over something like ADTs, but I think it's a noteworthy improvement.
- rauljara 14y ago
  From the article: "You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure." So the author agrees with you. So please, no "No, please."
  - olalonde 14y ago
    Yes but he wrote that to support his view that abstraction+polymorphism+encapsulation=OOP even when you are not using object structures: "The first sentence says that you must use object data structures to write OOP. That's blatantly wrong. You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure." I don't much enjoy arguments about semantics but I personally feel his definition of OOP is way too broad to be useful. I am tempted to believe it was called tempted to believe it was called Object Oriented Programming for a reason.
Knighty 14y ago
>> The first sentence says that you must use object data structures to write OOP. Actually I don't think it does. It says that: "objects are data structures consisting of data fields and methods together with their interactions". There is no obligation. True it would be easier implemented in a language provided data-structure. But if you were crazy enough you could place the data-structure all in global variables and try to tie them up using reflection.
Zenst 14y ago
Procedural has a static state of flow working from the program controling the data and OOP has a lose state of flow working with the data controlling the program. Would that be a easier true definition? Another way to look at this is if you have say a physical button that the user can toggle on or off and it is lit up by code. Doing this is processed by procedural code then the code will know what state the button is and if any processing limitations will be slow in processing if the button is on or off as could be indicated by slow transition to respond to the light going on or off. Now using OOP code the code that controls the light being on or off is would in general isolated from the processing of the state of the button and can lead to the the button showing on with the light on yet the processing code still thinking it is off. IE the code has no fixed static processing path and as such can lose state of if the button is on or off. This can lead to the button being off and the underliying code thinking it is on as they desync. Sorry if not the best explanation but is based upon a example I've seen in real life. The example was a phone busy/not busy button and the lovely C++ object oriented code got into a kefufle thinking the butotn was on when it was not after the operator had played track and feild on the button tapping away at it real fast out of bordem. The next result was the call processing system thought the phone was not busy when it was and tried to route a call which it was unable to do and the upshot was the entire phone system crashed. OOP has it's uses, but it also has it's downsides, like all approaches it is the right tool for the job. Just that error handerling in OOP can get more complex than boring old procedural code which is alot easier to deal with, when it comes to exceptions as the processing state is static. Another way to look at it is physical gears - procedural code is a fixed gear and OOP is a gear cog that can change in size and whilst you will see the end result you have no idea what size the dynamic OOP cog is. Realy can be a hard one to explain without examples and it does lack a classic Hello World example.
- Xurinos 14y ago
  Procedural has a static state of flow working from the program controling the data and OOP has a lose state of flow working with the data controlling the program. Would that be a easier true definition? No. (What is "static" vs "loose"? :)) Procedural programming is a control flow pattern. OOP is a data arrangement pattern. You may be thinking of GUI systems with single-threaded control loops and callbacks, which is another kind of control flow pattern, but it is orthogonal to OOP. People who use OOP can, within the methods or in calls to their objects, use a procedural approach, a functional approach, and/or a callback approach. For different control flows, there are sometimes more appropriate/maintainable data arrangements.
pixie_ 14y ago
Even without OOP you're carrying state information one way or another. This is a confusing article because his OOP examples are procedural, and his procedural examples carry state in a global object.
raganwald 14y ago
He [my father] taught me: "See that bird? It’s a Spencer's warbler." (I knew he didn't know the real name.) "Well, in Italian it's Chutto Lapittitda. In Portuguese, it is Bom Da Peida. ... You can know the name of the bird in all the languages of the world, but when you're finished, you'll know nothing whatsoever about the world. You'll know about the humans in different places, and what they call the bird. So let's look at the bird and see what it is doing -- that's what counts." I learned very early from my father the difference between knowing the name of something and knowing something.” —Richard Feynman
- kanak 14y ago
  In video form: http://www.youtube.com/watch?v=05WS0WN7zMQ http://www.youtube.com/watch?v=05WS0WN7zMQ
bunderbunder 14y ago
The bit about these kinds of articles that always nags at me is the assumption that different programming paradigms are somehow mutually exclusive. Essays talk as if object-oriented code cannot also be functional, or code isn't procedural if it involves classes, or whatever. In some cases that might be true - declarative programming and procedural programming, for example, are diametric opposites in many respects. But others can be quite comfortable bedfellows. In particular, object-oriented programming and its older cousin modular programming tend to play quite nicely with other paradigms. Consider CLOS or Objective-C. And even when they're opposed to each other that really just means you're limited in how you can mix them on a per-line basis. You can still write a multi-paradigm language that lets you support features from different styles. Consider C#, which supports object-oriented, procedural, functional, and declarative programming (with the last admittedly being somewhat constrained), and where it's standard practice to use elements of each style all within a single short procedure. Sometimes elements of different styles end up depending intimately on each other. For example, to provide optimal support for (declarative) query expressions, one will probably need to implement the (object-oriented) IQueryable interface, and many of the methods in that interface are expected to take (functional) anonymous procedures as arguments and/or are used to build up (functional) monads representing the query that's being declared, which are in turn represented as (object-oriented) instances of classes that implement specific interfaces.
- einhverfr 14y ago
  This. Even declarative and procedural program can have some interactions. It is very hard to do anything with just declarations ;-), and there is some logic to making the procedures of the code clear and explicit. A lot of stuff comes back to 'be simple, be clear.' And if mixing paradigms lets you do it, go for it!
- ExpiredLink 14y ago
  > The bit about these kinds of articles that always nags at me is the assumption that different programming paradigms are somehow mutually exclusive. Paradigms are by definition mutually exclusive[1]. I'd argue that neither OOP nor FP nor procedural programming ... are paradigms but merely styles or idioms. Combining idioms is quite usual in our culture. [1] http://plato.stanford.edu/entries/thomas-kuhn/#3 http://plato.stanford.edu/entries/thomas-kuhn/#3
eeeeaaii 14y ago
Maybe oversimplified, but, these being the 5 programming paradigms listed in Wikipedia: Aspect-oriented (? not an expert on this) Imperative/procedural (most work is done by statements) Functional (most work is done by functions) Logic (most work is done by declarations) Object Oriented (most work is done by objects)
- anamax 14y ago
  > Object Oriented (most work is done by objects) Objects don't do work - methods do. Objects organize state. Methods are functions with implicit state that may be shared with other methods. These functions may be functional (as in Actors) or imperative. Objects help organize state. You can "OOP" in any language; it doesn't actually require any language-level constructs. (Yup, you can do OOP in assembly language, Fortran 66, etc.)
beagle3 14y ago
Obligatory http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html - OOP is not well defined. State your definition (use the above link as a legend) before arguing about what OOP is and isn't, and there will be much less miscommunication.
- bunderbunder 14y ago
  It's an interesting observation, but I can't help but notice that none of the nine members of that list includes the single essential feature that's shared by all languages that claim to be object-oriented: The presence of a language-level construct (an "object") which bundles data together with operations on that data. The nine in the list are instead just a bunch of optional features that an object-oriented language may or may not have in addition to that one essential feature. Some of them aren't even particularly emblematic of OOP in the first place. The most well-known poster child for #6, Erlang, is a (non-OO) functional language that implements it among processes instead of objects. In other words, while the essay is correct in observing that OOP can be a frustratingly fragmented paradigm, the claim that it is "not a well-defined concept" is a glaring case of failing to see the forest for the trees.
  - beagle3 14y ago
    > The presence of a language-level construct (an "object") which bundles data together with operations on that data. And yet, many people argue that objects don't even need to have data to be objects ( e.g. http://stackoverflow.com/questions/6500127/whats-the-overhead-of-a-data-less-type http://stackoverflow.com/questions/6500127/whats-the-overhea... ) ... you can google "stateless objects" or "dataless objects" and see that they were common enough at some point to be "considered harmful".... > The most well-known poster child for #6, Erlang, is a (non-OO) functional language that implements it among processes instead of objects. Are processes not objects? I think they very much are. > In other words, while the essay is correct in observing that OOP can be a frustratingly fragmented paradigm, the claim that it is "not a well-defined concept" is a glaring case of failing to see the forest for the trees. If you have at least 4 incompatible definitions (as given by Rees) then it is, by definition, NOT a well defined concept.

53 points by dave1010uk 14y ago

I disagree with this somewhat. The biggest gain for large pieces of software from OOP is encapsulation, and in that regard writing loosely-coupled procedural code within classes will provide you will proper encapsulation. You can't get away from writing procedural code completely, because chances are you're writing a procedure, so even if you're thinking about state transforms rather than a list of actions to take, you're still writing procedurally.

danieldk 14y ago
The biggest gain for large pieces of software from OOP is encapsulation, But before OO languages became popular, people encapsulated data by using opaque pointers. It can be argued that OO-programming promotes encapsulation, but in practice it is not hard to accidentally leak the internal state of data (especially in languages that only provide boxed data types). Also, in (some) functional languages, encapsulation is comparably obtained by not exporting the constructors of a data type. So, I am not convinced that encapsulation is in any way an exclusive or even defining property of OOP.
- debacle 14y ago
  That's all well and good, but that's not what wikipedia says.
  - simonbarker87 14y ago
    Are you implying that wikipedia is the authority on all topics? Given it can be edited by anyone at anytime I would suggest that comments on HN or elsewhere are no more or less valid than what wikipedia says
    - debacle 14y ago
      > comments on HN or elsewhere are no more or less valid than what wikipedia says I'm not going to be dragged into a discussion based on such a ridiculous premise.
- seanmcdirmid 14y ago
  OOP is defined primarily by its ability to abstract and encapsulate data (and state) in objects. See William Cook's paper on "On Understanding Data Abstraction, Revisited." Of course, there are other ways to encapsulate state; e.g., as monads; OOP doesn't promote encapsulation so much as it promotes encapsulation using objects. The second defining aspect of OOP is messaging (goes along with encapsulation); Alan Kay has more to say about that (just check out Message Passign on wiki). The third is probably dynamic dispatch and polymorphism; not all OOP languages have that. I've dealt with plenty of weird non-procedural OO languages (including my own) with no recognizable procedure construct, but this is a much more controversial position as there are no mainstream non-procedural OOP languages out there (Erlang?). However, procedural programming is mostly orthogonal to OOP, which is what I think the blog post is trying to get across?
  - danieldk 14y ago
    OOP is defined primarily by its ability to abstract and encapsulate data (and state) in objects. I cannot help but thinking this is a tautology: 'Programming with objects is defined by putting data in an objects.' What is an object? How does it defer from other data structures where its members are hidden to the outside world? I am not arguing that OOP does not exist, just that one aspect that has always been touted as one of its greatest advantages, also exists in most non-OO languages. The second defining aspect of OOP is messaging (goes along with encapsulation); Alan Kay has more to say about that (just check out Message Passign on wiki). The third is probably dynamic dispatch and polymorphism; not all OOP languages have that. Is message passing without dynamic dispatch and polymorphism really message passing? (In contrast to a function call that has a structure as an implicit argument?) there are other ways to encapsulate state; e.g., as monads A data type is a monad if a function is provided that defines how computations of that data type can be combined[1], and that function obeys the monad laws. A monad can be used to combine effectful computations (IO, ST) or threading state through function calls (State). But e.g. the list, Maybe, or Either monads have little to do with state. [1] Excluding 'return' for brevity ;).
    - seanmcdirmid 14y ago
      Monads can be used to encapsulate state, they are used for other things. You can use objects to encapsulate state, or you can use another style of data abstraction, whatever floats your boat. OOP has no unique capabilities, you just get to design your programs around objects, which is good enough for me. Its all about design.

shasta 14y ago

No, please. OOP does not have a monopoly on abstraction, encapsulation, modularity, etc. If you are focused on "state transformations and encapsulated abstractions", you're not necessarily writing OOP.

debacle 14y ago
I agree, but I would state that it's easier to do encapsulation and modularity in OOP than procedural style. I prefer the functional method, though. In my opinion it's much easier to understand and much more flexible, but many programmers dislike that flexibility.
- ufo 14y ago
  "Procedural style" is a strawman though, corroborated by years of people thinking C and FORTRAN are the only procedural languages out there. Most OOP languages are still procedural and many "traditional" procedural languages provide support for data abstraction.
  - debacle 14y ago
    The syntactical sugar provided by languages that support objects is the only real improvement over something like ADTs, but I think it's a noteworthy improvement.
rauljara 14y ago
From the article: "You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure." So the author agrees with you. So please, no "No, please."
- olalonde 14y ago
  Yes but he wrote that to support his view that abstraction+polymorphism+encapsulation=OOP even when you are not using object structures: "The first sentence says that you must use object data structures to write OOP. That's blatantly wrong. You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure." I don't much enjoy arguments about semantics but I personally feel his definition of OOP is way too broad to be useful. I am tempted to believe it was called tempted to believe it was called Object Oriented Programming for a reason.

Knighty 14y ago

>> The first sentence says that you must use object data structures to write OOP. Actually I don't think it does. It says that: "objects are data structures consisting of data fields and methods together with their interactions". There is no obligation. True it would be easier implemented in a language provided data-structure. But if you were crazy enough you could place the data-structure all in global variables and try to tie them up using reflection.

Zenst 14y ago

Procedural has a static state of flow working from the program controling the data and OOP has a lose state of flow working with the data controlling the program. Would that be a easier true definition? Another way to look at this is if you have say a physical button that the user can toggle on or off and it is lit up by code. Doing this is processed by procedural code then the code will know what state the button is and if any processing limitations will be slow in processing if the button is on or off as could be indicated by slow transition to respond to the light going on or off. Now using OOP code the code that controls the light being on or off is would in general isolated from the processing of the state of the button and can lead to the the button showing on with the light on yet the processing code still thinking it is off. IE the code has no fixed static processing path and as such can lose state of if the button is on or off. This can lead to the button being off and the underliying code thinking it is on as they desync. Sorry if not the best explanation but is based upon a example I've seen in real life. The example was a phone busy/not busy button and the lovely C++ object oriented code got into a kefufle thinking the butotn was on when it was not after the operator had played track and feild on the button tapping away at it real fast out of bordem. The next result was the call processing system thought the phone was not busy when it was and tried to route a call which it was unable to do and the upshot was the entire phone system crashed. OOP has it's uses, but it also has it's downsides, like all approaches it is the right tool for the job. Just that error handerling in OOP can get more complex than boring old procedural code which is alot easier to deal with, when it comes to exceptions as the processing state is static. Another way to look at it is physical gears - procedural code is a fixed gear and OOP is a gear cog that can change in size and whilst you will see the end result you have no idea what size the dynamic OOP cog is. Realy can be a hard one to explain without examples and it does lack a classic Hello World example.

Xurinos 14y ago
Procedural has a static state of flow working from the program controling the data and OOP has a lose state of flow working with the data controlling the program. Would that be a easier true definition? No. (What is "static" vs "loose"? :)) Procedural programming is a control flow pattern. OOP is a data arrangement pattern. You may be thinking of GUI systems with single-threaded control loops and callbacks, which is another kind of control flow pattern, but it is orthogonal to OOP. People who use OOP can, within the methods or in calls to their objects, use a procedural approach, a functional approach, and/or a callback approach. For different control flows, there are sometimes more appropriate/maintainable data arrangements.

pixie_ 14y ago

Even without OOP you're carrying state information one way or another. This is a confusing article because his OOP examples are procedural, and his procedural examples carry state in a global object.

raganwald 14y ago

He [my father] taught me: "See that bird? It’s a Spencer's warbler." (I knew he didn't know the real name.) "Well, in Italian it's Chutto Lapittitda. In Portuguese, it is Bom Da Peida. ... You can know the name of the bird in all the languages of the world, but when you're finished, you'll know nothing whatsoever about the world. You'll know about the humans in different places, and what they call the bird. So let's look at the bird and see what it is doing -- that's what counts." I learned very early from my father the difference between knowing the name of something and knowing something.” —Richard Feynman

kanak 14y ago
In video form: http://www.youtube.com/watch?v=05WS0WN7zMQ http://www.youtube.com/watch?v=05WS0WN7zMQ

bunderbunder 14y ago

The bit about these kinds of articles that always nags at me is the assumption that different programming paradigms are somehow mutually exclusive. Essays talk as if object-oriented code cannot also be functional, or code isn't procedural if it involves classes, or whatever. In some cases that might be true - declarative programming and procedural programming, for example, are diametric opposites in many respects. But others can be quite comfortable bedfellows. In particular, object-oriented programming and its older cousin modular programming tend to play quite nicely with other paradigms. Consider CLOS or Objective-C. And even when they're opposed to each other that really just means you're limited in how you can mix them on a per-line basis. You can still write a multi-paradigm language that lets you support features from different styles. Consider C#, which supports object-oriented, procedural, functional, and declarative programming (with the last admittedly being somewhat constrained), and where it's standard practice to use elements of each style all within a single short procedure. Sometimes elements of different styles end up depending intimately on each other. For example, to provide optimal support for (declarative) query expressions, one will probably need to implement the (object-oriented) IQueryable interface, and many of the methods in that interface are expected to take (functional) anonymous procedures as arguments and/or are used to build up (functional) monads representing the query that's being declared, which are in turn represented as (object-oriented) instances of classes that implement specific interfaces.

einhverfr 14y ago
This. Even declarative and procedural program can have some interactions. It is very hard to do anything with just declarations ;-), and there is some logic to making the procedures of the code clear and explicit. A lot of stuff comes back to 'be simple, be clear.' And if mixing paradigms lets you do it, go for it!
ExpiredLink 14y ago
> The bit about these kinds of articles that always nags at me is the assumption that different programming paradigms are somehow mutually exclusive. Paradigms are by definition mutually exclusive[1]. I'd argue that neither OOP nor FP nor procedural programming ... are paradigms but merely styles or idioms. Combining idioms is quite usual in our culture. [1] http://plato.stanford.edu/entries/thomas-kuhn/#3 http://plato.stanford.edu/entries/thomas-kuhn/#3

eeeeaaii 14y ago

Maybe oversimplified, but, these being the 5 programming paradigms listed in Wikipedia: Aspect-oriented (? not an expert on this) Imperative/procedural (most work is done by statements) Functional (most work is done by functions) Logic (most work is done by declarations) Object Oriented (most work is done by objects)

anamax 14y ago
> Object Oriented (most work is done by objects) Objects don't do work - methods do. Objects organize state. Methods are functions with implicit state that may be shared with other methods. These functions may be functional (as in Actors) or imperative. Objects help organize state. You can "OOP" in any language; it doesn't actually require any language-level constructs. (Yup, you can do OOP in assembly language, Fortran 66, etc.)

beagle3 14y ago

Obligatory http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html - OOP is not well defined. State your definition (use the above link as a legend) before arguing about what OOP is and isn't, and there will be much less miscommunication.

bunderbunder 14y ago
It's an interesting observation, but I can't help but notice that none of the nine members of that list includes the single essential feature that's shared by all languages that claim to be object-oriented: The presence of a language-level construct (an "object") which bundles data together with operations on that data. The nine in the list are instead just a bunch of optional features that an object-oriented language may or may not have in addition to that one essential feature. Some of them aren't even particularly emblematic of OOP in the first place. The most well-known poster child for #6, Erlang, is a (non-OO) functional language that implements it among processes instead of objects. In other words, while the essay is correct in observing that OOP can be a frustratingly fragmented paradigm, the claim that it is "not a well-defined concept" is a glaring case of failing to see the forest for the trees.
- beagle3 14y ago
  > The presence of a language-level construct (an "object") which bundles data together with operations on that data. And yet, many people argue that objects don't even need to have data to be objects ( e.g. http://stackoverflow.com/questions/6500127/whats-the-overhead-of-a-data-less-type http://stackoverflow.com/questions/6500127/whats-the-overhea... ) ... you can google "stateless objects" or "dataless objects" and see that they were common enough at some point to be "considered harmful".... > The most well-known poster child for #6, Erlang, is a (non-OO) functional language that implements it among processes instead of objects. Are processes not objects? I think they very much are. > In other words, while the essay is correct in observing that OOP can be a frustratingly fragmented paradigm, the claim that it is "not a well-defined concept" is a glaring case of failing to see the forest for the trees. If you have at least 4 incompatible definitions (as given by Rees) then it is, by definition, NOT a well defined concept.