5 ms·

It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is g

by prewett 11mo ago

It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). Microservices, in fact, could be considered "network objects" and a microservice framework as network OOP. The problem there is that normal making a function call is straight-forward. The call produce a failure result, but the call actually happens. On the network, the call might not happen, and you might not be aware that the call cannot and will not happen for some seconds. This is not likely to simplify your code... OOP can be just about structuring code, like the Java OOP fundamentalism, where even a function must be a Runnable object (unless it's changed since Oracle took over). If there's anything that is not an object, it's a function! Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from. In transforming information and passing it around, no state is needed or wanted, and immutability is helpful. FP in a UI or a game is not so fun (witness all the hooks in React, which in anything complicated is difficult to follow), since both of those require considerable internal state. Algorithms are a sort of middle ground. Some algorithms require keeping track of a bunch of things, others more or less just transform the inputs. OOP (internal to the algorithm) can make the former much clearer, while it is unhelpful for that latter.

gwbas1c 11mo ago
> It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The author is complaining about bloat. The thing is, in this case, the bloat has highly tangible costs: Spreading an application across multiple computers unnecessarily adds both operation costs and development costs.
- bloppe 11mo ago
  Unnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary. The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.
senderista 11mo ago
The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.
- webstrand 11mo ago
  And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP. Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state. And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
  - Jensson 11mo ago
    > Personally I'm against the practice of enforced state-hiding Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message. Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.
  - bccdee 11mo ago
    > So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP. That's just polymorphism. Are Haskell typeclass manipulations OOP too? If I fmap a function f across a functor, am I "passing" an fmap "message" with payload f to a dynamic functor object? That feels like a real stretch. And message-passing isn't inherently polymorphic. If I call `Foo.bar(1, 2)`, I'm only dispatching by type if Foo is cast as a parent class or an interface object, which is typically not the case even in strongly OO code bases. That doesn't mean I'm not passing a message. Any type of procedure-calling can be framed as "message passing," but that doesn't make all programming OOP.
hackthemack 11mo ago
> It's unclear to me what the author thinks OOP is I rather liked the old post "Object Oriented Programming is an Expensive Disaster that Must End" written over 10 years ago. https://medium.com/@jacobfriedman/object-oriented-programming-is-an-expensive-disaster-which-must-end-2cbf3ea4f89d https://medium.com/@jacobfriedman/object-oriented-programmin... Many complained the post was too long, and then debated all kinds of things brought up in the article (such is the way of the internet). But the one thing I really liked is how it laid out that everyone has a different definition of what OOP is and so it is difficult to talk about.
- swader999 11mo ago
  I'd settle for just getting inheritance to fade away.
- 1718627440 11mo ago
  I initially agreed with that article, but it than further and further focused on criticizing cargo culting in specific OOP languages (mostly Java). The actual problem is that there is an abstraction boundary introduced at every tiny thing. The fact that these abstraction boundaries are structured with OOP, is only incidental. I see that this is relevant to OOP, but only in so far as this seems to be a disease of OOP-only/first languages and OOP cultures. What I say is that it is true, that what he criticizes is OOP, but OOP doesn't requires any of that and the actual problem is the existence of the abstraction boundaries, not their shape. You can't make the all generic implementation, than you will get a more complicated formulation of a turing machine. Software is useful in that it narrows down the expressiveness of computation to a single problem. A generic implementation is able to express anything and thus nothing, i.e. it doesn't contain the information of the problem anymore.
deepsun 11mo ago
> If there's anything that is not an object, it's a function! Why, functions have state -- their closure.
- knome 11mo ago
  closures and objects with a single invoke() method have been considered equivalent in many views for some time.
  - deepsun 11mo ago
    Exactly, that's why I disagree with parent's comment: > If there's anything that is not an object, it's a function!
    - Jtsummers 11mo ago
      Functions aren't closures. To be a closure it needs to be a function paired with an environment. Functions do not inherently carry their environment with them.
- endgame 11mo ago
  Ancient wisdom: closures are a poor man's objects; objects are a poor man's closures. https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
airstrike 11mo ago
> So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). OOP is not better suited for user-interfaces than the alternatives.
- exploraz 11mo ago
  Unrelated, but your comment is the 46 millionth item by the way. https://news.ycombinator.com/item?id=46000000 https://news.ycombinator.com/item?id=46000000
  - airstrike 11mo ago
    That's pretty cool! Makes you wonder who all the other millionaires are
elevation 11mo ago
> The main point of OOP to me is hiding internal state. So OOP is great for user-interface One principal I pursue aggressively in UI design is NOT hiding state! A client had written a script to calibrate an embedded system across several operating parameters. The program consisted of a TUI to capture setup parameters, then ran 5-layers of nested FOR loop for several hours. This original program lacked even a basic progress bar. You never knew what it was doing or when it would be done - it hid a lot of internal state! You might say, "the TUI program was hiding relevant state; your program should only hide the irrelevant state." But as I iterated on the program I realized that literally all of the program state was relevant! So I meticulously crafted a GUI to display every operational detail on screen at all times. This included the state of each FOR loop, a plot of the intermediate results, the state of each TCP connection, the state of the unit under test, and the user-selected test parameters, the full path of the calibration files the test relied upon. While the program had some "magic" (it would auto-recall the default parameters associated with the model under test, and would auto detect equipment types with a network scan) I future-proofed it by ensuring that ALL of the parameters were both visible (not hidden!) and human-overridable AND resettable (A reset-to-default option would appear when the user changed defaults, in case the selection was unintended.) The GUI is also wire silent (no network packets transmitted) until directed by the user to scan for/connect to equipment, and it gives a visual indicator while waiting for network responses. The GUI also tracked test progress as a first-class file-saveable object, so not only was there a progress bar, but tests could be resumed if equipment connectivity was lost mid-test. And a 95% confidence interval estimate, shown as "between 9 and 13 minutes remaining" to help production techs plan their day. Even when state is read-only, I still don't hide it. Once a test has commenced, the selectable test parameters cannot be changed, but displaying them on screen confirms to users that their 5-hour test was not started with the wrong parameters. My big takeaway from this effort is that ANY hidden/inaccessible state is a liability. A user should be able to observe at all times what their program is up to.
- 1718627440 11mo ago
  These sound like great principles of UI design.
- prewett 11mo ago
nurettin 11mo ago
What they mean is probably the original intended Alan Kay definition of message passing which interconnected systems do.
Mikhail_Edoshin 11mo ago
Objects are exactly same as functions.
- Jtsummers 11mo ago
  No, they are equivalent to closures. Functions don't have state on their own.
  - Mikhail_Edoshin 11mo ago
    They do: the stack frame.
    - hollerith 11mo ago
      An object typically has state that persists between method calls whereas a function typically does not.
    - Jtsummers 11mo ago
      That's not a closure. A closure can be persisted and retains some state, the state may or may not be mutable. What's the closure for this function in C: int f(int x) { return x * 2; } There isn't one, it's just a function. This returns a closure: (define (multiplier n) (lambda (x) (* x n))) multiplier is not a closure, it's a function, but it returns a closure which is a function closed over the environment where n is set to some value. (define f (multiplier 2)) ;; f is a closure
      - Mikhail_Edoshin 11mo ago
        Look: I have some data and want to compute a checksum. I write code that goes through the data, does the math, and returns the result. Here the code is a function and you say it has no state; the stack frame doesn't count. Fine. Now I want to do something else with the data AND also compute a checksum. I need to go through the data only once. So I rewrite my checksum code. I define a small record type and split my code into three pieces: initialise, add data, get the result. Now it appears I do have an object with a state, right? But it is the same code, just a different organisation.
koolala 11mo ago
smalltalk is all UI and exposed all state, wish we had a fast modern language that did the same thing
- pjmlp 11mo ago
  Pharo :)
mrkeen 11mo ago
> The main point of OOP to me is hiding internal state. > Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from 'Hiding' isn't good enough. OO sells the dream of 'black-box' objects, where you only need to be concerned with the inputs and outputs, and only the object cares about its internals. But what do programmers stick inside objects? The world! Files are outside the black-box, but inside a FileWriter object. Likewise with external webservers and databases. That's where the FP hype comes from - or at least Haskell. I can encapsulate functions perfectly (and actually stop caring about the internals!) If I try to stuff an Airplane inside flight-recorder, I get a compile error.
- tracker1 11mo ago
  I think you can get a lot from more functional approaches to even non-fp languages.

by prewett 11mo ago

gwbas1c 11mo ago

> It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The author is complaining about bloat. The thing is, in this case, the bloat has highly tangible costs: Spreading an application across multiple computers unnecessarily adds both operation costs and development costs.

bloppe 11mo ago
Unnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary. The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.

senderista 11mo ago

The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.

webstrand 11mo ago
And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP. Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state. And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
- Jensson 11mo ago
  > Personally I'm against the practice of enforced state-hiding Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message. Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.
- bccdee 11mo ago
  > So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP. That's just polymorphism. Are Haskell typeclass manipulations OOP too? If I fmap a function f across a functor, am I "passing" an fmap "message" with payload f to a dynamic functor object? That feels like a real stretch. And message-passing isn't inherently polymorphic. If I call `Foo.bar(1, 2)`, I'm only dispatching by type if Foo is cast as a parent class or an interface object, which is typically not the case even in strongly OO code bases. That doesn't mean I'm not passing a message. Any type of procedure-calling can be framed as "message passing," but that doesn't make all programming OOP.

hackthemack 11mo ago

> It's unclear to me what the author thinks OOP is I rather liked the old post "Object Oriented Programming is an Expensive Disaster that Must End" written over 10 years ago. https://medium.com/@jacobfriedman/object-oriented-programming-is-an-expensive-disaster-which-must-end-2cbf3ea4f89d https://medium.com/@jacobfriedman/object-oriented-programmin... Many complained the post was too long, and then debated all kinds of things brought up in the article (such is the way of the internet). But the one thing I really liked is how it laid out that everyone has a different definition of what OOP is and so it is difficult to talk about.

swader999 11mo ago
I'd settle for just getting inheritance to fade away.
1718627440 11mo ago
I initially agreed with that article, but it than further and further focused on criticizing cargo culting in specific OOP languages (mostly Java). The actual problem is that there is an abstraction boundary introduced at every tiny thing. The fact that these abstraction boundaries are structured with OOP, is only incidental. I see that this is relevant to OOP, but only in so far as this seems to be a disease of OOP-only/first languages and OOP cultures. What I say is that it is true, that what he criticizes is OOP, but OOP doesn't requires any of that and the actual problem is the existence of the abstraction boundaries, not their shape. You can't make the all generic implementation, than you will get a more complicated formulation of a turing machine. Software is useful in that it narrows down the expressiveness of computation to a single problem. A generic implementation is able to express anything and thus nothing, i.e. it doesn't contain the information of the problem anymore.

deepsun 11mo ago

> If there's anything that is not an object, it's a function! Why, functions have state -- their closure.

knome 11mo ago
closures and objects with a single invoke() method have been considered equivalent in many views for some time.
- deepsun 11mo ago
  Exactly, that's why I disagree with parent's comment: > If there's anything that is not an object, it's a function!
  - Jtsummers 11mo ago
    Functions aren't closures. To be a closure it needs to be a function paired with an environment. Functions do not inherently carry their environment with them.
endgame 11mo ago
Ancient wisdom: closures are a poor man's objects; objects are a poor man's closures. https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...

airstrike 11mo ago

> So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). OOP is not better suited for user-interfaces than the alternatives.

exploraz 11mo ago
Unrelated, but your comment is the 46 millionth item by the way. https://news.ycombinator.com/item?id=46000000 https://news.ycombinator.com/item?id=46000000
- airstrike 11mo ago
  That's pretty cool! Makes you wonder who all the other millionaires are

elevation 11mo ago

> The main point of OOP to me is hiding internal state. So OOP is great for user-interface One principal I pursue aggressively in UI design is NOT hiding state! A client had written a script to calibrate an embedded system across several operating parameters. The program consisted of a TUI to capture setup parameters, then ran 5-layers of nested FOR loop for several hours. This original program lacked even a basic progress bar. You never knew what it was doing or when it would be done - it hid a lot of internal state! You might say, "the TUI program was hiding relevant state; your program should only hide the irrelevant state." But as I iterated on the program I realized that literally all of the program state was relevant! So I meticulously crafted a GUI to display every operational detail on screen at all times. This included the state of each FOR loop, a plot of the intermediate results, the state of each TCP connection, the state of the unit under test, and the user-selected test parameters, the full path of the calibration files the test relied upon. While the program had some "magic" (it would auto-recall the default parameters associated with the model under test, and would auto detect equipment types with a network scan) I future-proofed it by ensuring that ALL of the parameters were both visible (not hidden!) and human-overridable AND resettable (A reset-to-default option would appear when the user changed defaults, in case the selection was unintended.) The GUI is also wire silent (no network packets transmitted) until directed by the user to scan for/connect to equipment, and it gives a visual indicator while waiting for network responses. The GUI also tracked test progress as a first-class file-saveable object, so not only was there a progress bar, but tests could be resumed if equipment connectivity was lost mid-test. And a 95% confidence interval estimate, shown as "between 9 and 13 minutes remaining" to help production techs plan their day. Even when state is read-only, I still don't hide it. Once a test has commenced, the selectable test parameters cannot be changed, but displaying them on screen confirms to users that their 5-hour test was not started with the wrong parameters. My big takeaway from this effort is that ANY hidden/inaccessible state is a liability. A user should be able to observe at all times what their program is up to.

1718627440 11mo ago
These sound like great principles of UI design.
prewett 11mo ago

nurettin 11mo ago

What they mean is probably the original intended Alan Kay definition of message passing which interconnected systems do.

Mikhail_Edoshin 11mo ago

Objects are exactly same as functions.

Jtsummers 11mo ago
No, they are equivalent to closures. Functions don't have state on their own.
- Mikhail_Edoshin 11mo ago
  They do: the stack frame.
  - hollerith 11mo ago
    An object typically has state that persists between method calls whereas a function typically does not.
  - Jtsummers 11mo ago
    That's not a closure. A closure can be persisted and retains some state, the state may or may not be mutable. What's the closure for this function in C: int f(int x) { return x * 2; } There isn't one, it's just a function. This returns a closure: (define (multiplier n) (lambda (x) (* x n))) multiplier is not a closure, it's a function, but it returns a closure which is a function closed over the environment where n is set to some value. (define f (multiplier 2)) ;; f is a closure
    - Mikhail_Edoshin 11mo ago
      Look: I have some data and want to compute a checksum. I write code that goes through the data, does the math, and returns the result. Here the code is a function and you say it has no state; the stack frame doesn't count. Fine. Now I want to do something else with the data AND also compute a checksum. I need to go through the data only once. So I rewrite my checksum code. I define a small record type and split my code into three pieces: initialise, add data, get the result. Now it appears I do have an object with a state, right? But it is the same code, just a different organisation.

koolala 11mo ago

smalltalk is all UI and exposed all state, wish we had a fast modern language that did the same thing

pjmlp 11mo ago
Pharo :)

mrkeen 11mo ago

> The main point of OOP to me is hiding internal state. > Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from 'Hiding' isn't good enough. OO sells the dream of 'black-box' objects, where you only need to be concerned with the inputs and outputs, and only the object cares about its internals. But what do programmers stick inside objects? The world! Files are outside the black-box, but inside a FileWriter object. Likewise with external webservers and databases. That's where the FP hype comes from - or at least Haskell. I can encapsulate functions perfectly (and actually stop caring about the internals!) If I try to stuff an Airplane inside flight-recorder, I get a compile error.

tracker1 11mo ago
I think you can get a lot from more functional approaches to even non-fp languages.