4 ms·

Indeed! And not every language that claims to be OO actually follows the basic ideas [1,2]. So, Smalltalk, as e.g Squeak [3] or Pharo [4] is a good place to st

Indeed! And not every language that claims to be OO actually follows the basic ideas [1,2]. So, Smalltalk, as e.g Squeak [3] or Pharo [4] is a good place to start looking and learning but also Erlang [5] and Clojure [6]. State is necessary not "evil" but needs to be managed well. And most OO-languages have, apart from the assignment operation, no abstractions for. [1] http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging [2] http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ [3] http://squeak.org/ http://squeak.org/ [4] https://pharo.org/ https://pharo.org/ [5] http://www.infoq.com/interviews/johnson-armstrong-oop http://www.infoq.com/interviews/johnson-armstrong-oop [6] http://thinkrelevance.com/blog/2013/11/07/when-should-you-use-clojures-object-oriented-features http://thinkrelevance.com/blog/2013/11/07/when-should-you-us...

willtim 9y ago
OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objects in your system could potentially contribute to the global state space, resulting in a combinatorial explosion of state. This makes programs difficult to reason about and is not a good general approach. In contrast, functional programming makes state explicit. This makes it easier to manage and control state.
- TimMurnaghan 9y ago
  It's cute how people thing that functional will fix everything. In what way does functional make state explicit? If I look at a structure (if you have one in your language) and ask who changes this part of it across a large code base - it's much worse when you've just got a bunch of functions (with bad names) which can be hiding anywhere. And the "reasoned about" shibboleth. What "reasoning" do you actually do. Don't get me wrong - I have a long history in Lisp and ML and they're good languages in which good people can write good software. But no magic bullets. In another part of the development world I've seen React programmers jumping on the functional bandwagon and deciding that all components have to be stateless. Taking the state outside the components means that we have lots of bugs with mistaken state sharing. So external state doesn't equal well-managed.
  - quickthrower2 9y ago
    In functional programming n Haskell functions are pure so there is no state just an input and an output. The exception is the IO entry point. There is a lot of opportunity to sandbox things so that if you know the type of the function you know what it can or can't do to the programs state.
- mpweiher 9y ago
  > not offer true state encapsulation, it just hides it. That's kind of the definition of encapsulation. > difficult to reason about This is repeated as a mantra without any backup. Most people find state trivial to "reason" about. What becomes more difficult are certain types of proofs that nobody actually does. > [FP] makes it easier to manage and control state No, not "easier". In fact, incredibly more difficult. Just try updating a nested member. What it does is make it easier to isolate state updates, because it makes it so arduous.
  - willtim 9y ago
    > That's kind of the definition of encapsulation. State encapsulation, at least in FP, means that the state is not visible externally. For example a pure function that uses mutable state in its implementation. Such state does not contribute to the sytem global state. > This is repeated as a mantra without any backup. The more global mutable state your application has, the harder it is to reason about. That should be fairly obvious I think.
mpweiher 9y ago
> State is necessary not "evil" but needs to be managed well. > And most OO-languages have, apart from the assignment operation, no abstractions for Yep. "Once you're inside an object, it's essentially Pascal" -- David Robson That's what Polymorphic Identifiers[1][2] in Objective-Smalltalk[3] address. Partial inspiration was the Web and its REST model, which shows that using state as the basis for composition is not just possible, but works really, really well at the largest possible scales. What it does is replace your bog-standard programming language identifiers with URIs. So you can write things like the following: comment := https://news.ycombinator.com/item?id=14997098 file:/tmp/comment := https://news.ycombinator.com/item?id=14997098 file:{$HOME}/comment := https://news.ycombinator.com/item?id=14997098 file:{$HOME)/comments/{id} := https://news.ycombinator.com/item?id={id} But that's not the cool thing. The cool thing is that scheme handlers are completely user-defined and composable, so you can abstract over state handling, with scheme combinators that take other scheme handlers as parameters, for example a cache, or filters. Oh, and references (ref:comment, ref:file:/tmp/comment, ...) generalize the concept of pointer. So creating a symbolic links becomes: file:link := ref:file:path/to/link/target etc. [1] http://dl.acm.org/citation.cfm?id=2508169 http://dl.acm.org/citation.cfm?id=2508169 [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... [3] http://objective.st/URIs/ http://objective.st/URIs/

willtim 9y ago

OOP does not offer true state encapsulation, it just hides it. Objects are always potentially stateful when reasoned about externally. This means that all objects in your system could potentially contribute to the global state space, resulting in a combinatorial explosion of state. This makes programs difficult to reason about and is not a good general approach. In contrast, functional programming makes state explicit. This makes it easier to manage and control state.

TimMurnaghan 9y ago
It's cute how people thing that functional will fix everything. In what way does functional make state explicit? If I look at a structure (if you have one in your language) and ask who changes this part of it across a large code base - it's much worse when you've just got a bunch of functions (with bad names) which can be hiding anywhere. And the "reasoned about" shibboleth. What "reasoning" do you actually do. Don't get me wrong - I have a long history in Lisp and ML and they're good languages in which good people can write good software. But no magic bullets. In another part of the development world I've seen React programmers jumping on the functional bandwagon and deciding that all components have to be stateless. Taking the state outside the components means that we have lots of bugs with mistaken state sharing. So external state doesn't equal well-managed.
- quickthrower2 9y ago
  In functional programming n Haskell functions are pure so there is no state just an input and an output. The exception is the IO entry point. There is a lot of opportunity to sandbox things so that if you know the type of the function you know what it can or can't do to the programs state.
mpweiher 9y ago
> not offer true state encapsulation, it just hides it. That's kind of the definition of encapsulation. > difficult to reason about This is repeated as a mantra without any backup. Most people find state trivial to "reason" about. What becomes more difficult are certain types of proofs that nobody actually does. > [FP] makes it easier to manage and control state No, not "easier". In fact, incredibly more difficult. Just try updating a nested member. What it does is make it easier to isolate state updates, because it makes it so arduous.
- willtim 9y ago
  > That's kind of the definition of encapsulation. State encapsulation, at least in FP, means that the state is not visible externally. For example a pure function that uses mutable state in its implementation. Such state does not contribute to the sytem global state. > This is repeated as a mantra without any backup. The more global mutable state your application has, the harder it is to reason about. That should be fairly obvious I think.

mpweiher 9y ago

> State is necessary not "evil" but needs to be managed well. > And most OO-languages have, apart from the assignment operation, no abstractions for Yep. "Once you're inside an object, it's essentially Pascal" -- David Robson That's what Polymorphic Identifiers[1][2] in Objective-Smalltalk[3] address. Partial inspiration was the Web and its REST model, which shows that using state as the basis for composition is not just possible, but works really, really well at the largest possible scales. What it does is replace your bog-standard programming language identifiers with URIs. So you can write things like the following: comment := https://news.ycombinator.com/item?id=14997098 file:/tmp/comment := https://news.ycombinator.com/item?id=14997098 file:{$HOME}/comment := https://news.ycombinator.com/item?id=14997098 file:{$HOME)/comments/{id} := https://news.ycombinator.com/item?id={id} But that's not the cool thing. The cool thing is that scheme handlers are completely user-defined and composable, so you can abstract over state handling, with scheme combinators that take other scheme handlers as parameters, for example a cache, or filters. Oh, and references (ref:comment, ref:file:/tmp/comment, ...) generalize the concept of pointer. So creating a symbolic links becomes: file:link := ref:file:path/to/link/target etc. [1] http://dl.acm.org/citation.cfm?id=2508169 http://dl.acm.org/citation.cfm?id=2508169 [2] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... [3] http://objective.st/URIs/ http://objective.st/URIs/