6 ms·

This is kinda funny. I wrote a "rebuttal" article back in 2009: http://goran.krampe.se/2009/06/26/joe-is-wrong/ http://goran.krampe.se/2009/06/26/joe-is-wrong/

by gokr 6y ago

This is kinda funny. I wrote a "rebuttal" article back in 2009: http://goran.krampe.se/2009/06/26/joe-is-wrong/ http://goran.krampe.se/2009/06/26/joe-is-wrong/ ...and then I met Joe not long after and we also discussed this in fact. He then told me that he felt my article was fair (!) and that he had *changed his opinion on OO since writing that article*. IIRC his exact words were something along the lines of "I did not understand OO when I wrote that article". Now... he also argued Erlang is in fact VERY OO, and in some ways he is correct, since its very focused around autonomous "parts" communicating solely via messages. Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that. I can find joy in simple imperative coding as much as I can long for the days I was working in pure OO in Smalltalk. :)

diggan 6y ago
> Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that What are we programmers supposed to do with all of our free-time unless argue about what is the holy grail versus which is not?! I feel so empty. Jokes aside, I think this is the most important point really. There is no single language/paradigm that works best for everything, it all really depends on the context, environment, and so much more. It's easy to forget on the internet, that someones environment might be vastly different than yours, and think your solution will work for others because you miss their context. OOP is hated all around the world, and still solves problems. Functional programming is loved all around the world, but is still not the right solution for everything.
- gokr 6y ago
  "hated all around the world" sounds a bit harsh :) Sure, lots of people like "throwing hate" at it, but AFAICT it's mostly "bad use" that gets people riled up like insane deep inheritance or overly complicated frameworks. Also, it seems especially young guns feel cool by claiming FP is superior ;) AFAIK OOP languages are still ruling the whole GUI space, which is reasonable since GUI was the main driving force behind it (see history of Smalltalk) and the domain is such an obvious candidate for composition of separate independent elements. What languages are primarily used for GUIs today? Java, C#, Swift, ObjC, C++, Dart, Kotlin ... and the list can probably be made much longer. On the web ... well.
  - cuddlecake 6y ago
    Not sure if OO really rules the GUI space. Afaik, at least Swift, Dart (Flutter) and Kotlin are trying to solve the mismatch between OO and Reactive Programming (where functional approaches very helpful) Most of GUI development is pure data handling (render state and react to interactions) where a strong functional toolset is much appreciated (lambda, pattern matching) and some parts are well done with closures (where OO comes in) Ultimately I would love to have a GUI development language that allows me to use one set of language features and constraints when I really just want to use functions on data immutable data, strong pattern matching and ADT for modelling) and another when I need strong closures, with message based dispatches and reactivity. Basically, whatever React does, minus the constraints of requiring JS compatibility.
    - gokr 6y ago
      It all depends if you consider basically all non web GUIs developed the last 40 years or if you limit yourself to reactive web UIs developed the last few years. Tongue in cheek :) Sure, reactive frameworks in js that mainly operate on the DOM/HTML/CSS stack may be very little OO, but Swift/Dart/Kotlin are OOP languages and Flutter for example, while using a reactive model, is still 100% OOP with Widget classes in a composition and so on.
      - geokon 6y ago
        Well non-web GUIs have been basically stagnant for a good chunk of that 40 years :) You're right that it's OO under the hood. The latest thing I've used is CLJFX which is a React-like wrapper around JavaFX. I don't feel the OO side has much effect on my experience using the library. It's still events, callbacks, state-updates. The class hierarchies are irrelevant to the library user the vast majority of the time. I wouldn't be surprised if for the library writers it provides benefits with code reuse and type gymnastics. But for mere mortals that need to refactor and reorganize our messy ideas OO hierarchies seem scary after React-like development.
        francisl 6y ago
- rsj_hn 6y ago
  Strangely a lot of the functional programming advocates are fine with closures, which are guilty of all the same issues -- private state, hidden state, combining data with functions. Closures are basically lightweight objects. Really the debate should be about whether you are dealing with pure objects or not, rather than whether you are binding code and data into a single variable that is passed around. I once saw a python function that returned two other functions, a, b, such that depending on what was passed to a, the return value of b would change. Sounds terrible, right? Well, A was set_test_parameters(params) and B was get_test_results(test_run). In OO parlance, they were two methods of the same test_ object but because they were returned as closures the underlying object was hidden as an internal variable in the function that returned a and b. In OO parlance that would be a factory. Wonder what Joe Armstrong would think about that -- it was both cringeworthy and also quite efficient, as the code that consumed A didn't need to know about B and vice versa. One could even think of A and B as two ends of a pipe, or as pointers to inputs and outputs of an unspecified function. Being able to cleanly design a complex program so accurately that only immutable types are used is difficult. Then throw in large numbers of junior engineers working in tight time windows, subject to constantly changing requirements, and the odds of that codebase being pure a few years out is basically zero. In the end, we have to ship.
  - _ZeD_ 6y ago
    "Obligatory c2.com reference": https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent """ The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. """
- prionassembly 6y ago
  > What are we programmers supposed to do with all of our free-time unless argue about what is the holy grail versus which is not?! I feel so empty. Learn about monads for advanced pedantry points? (I joke.)
- mosselman 6y ago
  In the end it is probably most important what you like to use rather than how it performs, which abstractions are best, etc. If you can wake up every day and think "Today is a great day for some non-OO programming" and you get to it, adding value to you and hopefully others, who is someone else to look down on that?
the__alchemist 6y ago
After reading the comments, I get the impression we (and by proxy, many people?) don't agree on what OO means. There's a spectrum, including "Using classes / structs", "Not pure functional programming", "inheritance / getters/setters / factories", "everything is a class".
- michaelscott 6y ago
  I think what OP means in the case of Joe Armstrong's comment is that Erlang follows the original conception of OO, as defined by Alan Kay, in which code is structured as black boxes passing messages and has nothing to do with semantics. It's true though, it's become such a muddy term.
canadianfella 6y ago
Grail
mbrodersen 6y ago
The funny thing is that Erlang is more OO than any other so-called OO language. Messaging in Erlang is messaging not just another word for a function call with a funny syntax.

by gokr 6y ago

diggan 6y ago

> Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that What are we programmers supposed to do with all of our free-time unless argue about what is the holy grail versus which is not?! I feel so empty. Jokes aside, I think this is the most important point really. There is no single language/paradigm that works best for everything, it all really depends on the context, environment, and so much more. It's easy to forget on the internet, that someones environment might be vastly different than yours, and think your solution will work for others because you miss their context. OOP is hated all around the world, and still solves problems. Functional programming is loved all around the world, but is still not the right solution for everything.

gokr 6y ago
"hated all around the world" sounds a bit harsh :) Sure, lots of people like "throwing hate" at it, but AFAICT it's mostly "bad use" that gets people riled up like insane deep inheritance or overly complicated frameworks. Also, it seems especially young guns feel cool by claiming FP is superior ;) AFAIK OOP languages are still ruling the whole GUI space, which is reasonable since GUI was the main driving force behind it (see history of Smalltalk) and the domain is such an obvious candidate for composition of separate independent elements. What languages are primarily used for GUIs today? Java, C#, Swift, ObjC, C++, Dart, Kotlin ... and the list can probably be made much longer. On the web ... well.
- cuddlecake 6y ago
  Not sure if OO really rules the GUI space. Afaik, at least Swift, Dart (Flutter) and Kotlin are trying to solve the mismatch between OO and Reactive Programming (where functional approaches very helpful) Most of GUI development is pure data handling (render state and react to interactions) where a strong functional toolset is much appreciated (lambda, pattern matching) and some parts are well done with closures (where OO comes in) Ultimately I would love to have a GUI development language that allows me to use one set of language features and constraints when I really just want to use functions on data immutable data, strong pattern matching and ADT for modelling) and another when I need strong closures, with message based dispatches and reactivity. Basically, whatever React does, minus the constraints of requiring JS compatibility.
  - gokr 6y ago
    It all depends if you consider basically all non web GUIs developed the last 40 years or if you limit yourself to reactive web UIs developed the last few years. Tongue in cheek :) Sure, reactive frameworks in js that mainly operate on the DOM/HTML/CSS stack may be very little OO, but Swift/Dart/Kotlin are OOP languages and Flutter for example, while using a reactive model, is still 100% OOP with Widget classes in a composition and so on.
    - geokon 6y ago
      Well non-web GUIs have been basically stagnant for a good chunk of that 40 years :) You're right that it's OO under the hood. The latest thing I've used is CLJFX which is a React-like wrapper around JavaFX. I don't feel the OO side has much effect on my experience using the library. It's still events, callbacks, state-updates. The class hierarchies are irrelevant to the library user the vast majority of the time. I wouldn't be surprised if for the library writers it provides benefits with code reuse and type gymnastics. But for mere mortals that need to refactor and reorganize our messy ideas OO hierarchies seem scary after React-like development.
      - francisl 6y ago
rsj_hn 6y ago
Strangely a lot of the functional programming advocates are fine with closures, which are guilty of all the same issues -- private state, hidden state, combining data with functions. Closures are basically lightweight objects. Really the debate should be about whether you are dealing with pure objects or not, rather than whether you are binding code and data into a single variable that is passed around. I once saw a python function that returned two other functions, a, b, such that depending on what was passed to a, the return value of b would change. Sounds terrible, right? Well, A was set_test_parameters(params) and B was get_test_results(test_run). In OO parlance, they were two methods of the same test_ object but because they were returned as closures the underlying object was hidden as an internal variable in the function that returned a and b. In OO parlance that would be a factory. Wonder what Joe Armstrong would think about that -- it was both cringeworthy and also quite efficient, as the code that consumed A didn't need to know about B and vice versa. One could even think of A and B as two ends of a pipe, or as pointers to inputs and outputs of an unspecified function. Being able to cleanly design a complex program so accurately that only immutable types are used is difficult. Then throw in large numbers of junior engineers working in tight time windows, subject to constantly changing requirements, and the odds of that codebase being pure a few years out is basically zero. In the end, we have to ship.
- _ZeD_ 6y ago
  "Obligatory c2.com reference": https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent """ The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. """
prionassembly 6y ago
> What are we programmers supposed to do with all of our free-time unless argue about what is the holy grail versus which is not?! I feel so empty. Learn about monads for advanced pedantry points? (I joke.)
mosselman 6y ago
In the end it is probably most important what you like to use rather than how it performs, which abstractions are best, etc. If you can wake up every day and think "Today is a great day for some non-OO programming" and you get to it, adding value to you and hopefully others, who is someone else to look down on that?

the__alchemist 6y ago

After reading the comments, I get the impression we (and by proxy, many people?) don't agree on what OO means. There's a spectrum, including "Using classes / structs", "Not pure functional programming", "inheritance / getters/setters / factories", "everything is a class".

michaelscott 6y ago
I think what OP means in the case of Joe Armstrong's comment is that Erlang follows the original conception of OO, as defined by Alan Kay, in which code is structured as black boxes passing messages and has nothing to do with semantics. It's true though, it's become such a muddy term.

canadianfella 6y ago

Grail

mbrodersen 6y ago

The funny thing is that Erlang is more OO than any other so-called OO language. Messaging in Erlang is messaging not just another word for a function call with a funny syntax.