7 ms·

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one appro

by choult 13y ago

The thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms. At the end of the day, pick what language and coding paradigms best suit your problem domain and you as a coder. Pick right, and there's no mistake there.

danenania 13y ago
OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.
- arethuza 13y ago
  "everything is a process" To me that's as bad as saying "everything is an object". I'd rather try and understand where each approach is best rather than picking a single approach and dogmatically applying it in every scenario.
  - wcummings 13y ago
    I think his point is that the real world is concurrent states, not context switching. To loosely paraphrase Joe Armstrong, in the real world, data isnt shared, it's communicated. In this sense, the process as a fundamental abstraction more correctly models "the real world."
- theseoafs 13y ago
  I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same?
  - SamReidHughes 13y ago
    No need to apologize. With immutability you have to explicitly model temporal changes.
  - tomp 13y ago
    Yes. Due to Special Relativity, different observers perceive events (changes to object state) at different moments, the state of the whole universe is not consistent. Therefore, we model the universe using a sequence of immutable universe snapshots, with different computational agents independently moving through the (branching) timeline of snapshots, so that each and every one of them views the universe consistently.
    - pmahoney 13y ago
      Most events humans care about happen in plain old classical physics, and no computer is moving at some large fraction of light-speed relative to any other computer. If you maintain synchronized clocks, everyone can agree on the exact same order of events (which would not be true in a relativistic situation). Now it turns out to be difficult to maintain synchronized clocks, and Lamport timestamps and vector clocks are alternatives. The end result looks similar to a relativistic situation, but (and I'm not a physicist), it seems wrong to claim this situation is because of Special Relativity. Thoughts?
      - tomp 13y ago
        Yes. I was half joking, half explaining why immutability actually is better to model the universe. In practice, replace Special Relativity with Network Problems.
    - eloff 13y ago
      So what you're saying is the universe is mapped COW, and everytime there's a new observer, UniverseOS runs it with fork().
  - evanspa 13y ago
    Check out the first 20 minutes or so of this SICP lecture. In it, Abelson specifically mentions special relativity as a way for us humans to "model" the real world as immutable values over the continuum of time (in contrast to a mutable world that fits with OO). http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
- deleted 13y ago
  [deleted]
- w0utert 13y ago
  >> In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Been reading up on Heraclitus lately? While this is an interesting statement for a philosophical dialogue, it doesn't really make much sense in the context of programming, where many things are constant, many things are not processes, and there are plenty of use cases for both mutable and immutable state (which is exactly why I always get really defensive reading articles like this one, that pretend all problem domains would be best modelled by a single programming language/paradigm/model of computation).
  - Mikera 13y ago
    It makes a lot of sense in the context of programming when you look at the big picture. I think Rich Hickey articulates it best: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich...
- collyw 13y ago
  "OOP actually doesn't model the real world well at all." Surely that is in part due to the developer. Poor developers will choose the wrong abstractions, and have a poor OOP model as a result. Better developers will choose the correct abstractions, and have better models. Obviously the domain you are modeling will make it easier or harder to model things, and in some cases OPP may not be a good choice at all. In my day to day work I use Django. I start with a data model - based on an ER diagram. I code that in the Django model classes. Is that OOP modeling or ER modeling? I don't know. I don't really care too much. It works fairly well for most things I am doing.
- hcarvalhoalves 13y ago
  > OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. This is important, and something almost everybody ignores. Get an OO codebase, and try to implement a time-dependent feature, like snapshots, or even a simple undo. The abstractions fall apart.
- mrkhwrd3 13y ago
  A criminal tells the arresting police officer: - You're wrong, officer. It was yesterday-me who committed the crime but you are trying to arrest now-me. How wrong are you! I bet the authorities around the world don't like your time-inclusive-dimenstion view much.
  - matjazmuhic 13y ago
    You do realize that there's a difference between an object with identity (ddd names it entity) and the one without it (ddd names it value object). No matter what you do, identity does not change. You commiting a crime yesterday was an event that included you as an object with identity and today you have the same identtiy so you are clearly responsible for what you did yesterday. GUARDS! :P
- homami 13y ago
  We can think the state of the world is immutable. When the state changes, it's a different world. If space-time is discontinuous, then we can think any change of state, like motion, as a set of discrete changes. If we think the motion of a particle from one energy bin to another is immediate (meaning the particle cannot be found on the border between the bins, or one moment the particle is in Bin A, next it is in Bin B) then we can think the particle was destroyed in Bin A and another one was created at Bin B. And this is what we call motion from A -> B.
kitsune_ 13y ago
Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason about the control flow and state of the program without investing a lot of time and mental effort. Sometimes it's almost impossible. I don't know, I think it's a point where education fails. Your average enterprise developer should be forced to read books like "Clean Code" by Bob Martin before being allowed to touch a keyboard.
- w0utert 13y ago
  >> Mutable state can be a huge pain in the ass [..] 8I don't know, I think it's a point where education fails* I'd argue that the problem with software quality is not so much in the (ab)use of mutable state, but the fact that (especially in enterprises) software often reflects the organizational structure of the people who worked on it. Exhibit A: the software solution where every tiny part of the system is developed by some (semi) random group of people that often changes, doesn't directly communicate with any of the other groups, doesn't bother to much with the 'architecture' of the complete system (a big ball of mud), and has no interest improving either the overall architecture of the system, or any of the components outside their scope. Add pervasive mutable state into this mix, and you have a recipe for disaster. That's not to say the mantra 'eliminate (almost) all forms of mutable state' will improve this problem much.
- drharris 13y ago
  >> Immutable state can be a huge pain in the ass. A common mistake FP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled functions. See what I did there.
  - Paradigma11 13y ago
    The analogy would be that those functions are mutually recursive and while mutual recursive functions can be an elegant solution to several problems (state machine, some algorithms)overuse is not a mistake i have seen very often. FP does coerce, or at least very strongly suggests, a very simple program structure. This makes it hard to model some more complex relationships that are easy in OO. Anyway, my point is that FP is indeed different in this regard compared to OO.
JackMorgan 13y ago
I agree wholly that picking the right tool is critical. I also think you have to be skilled at a broad subset of all the tools to be able to even make any sort of comparison. Many times I've heard this argument from someone who only knows the one or two tools they learned in college or in their first job, and they try to dress up their ignorance as wisdom for "not wasting time on the wrong tools". I recommend http://norvig.com/21-days.html http://norvig.com/21-days.html as a great place to start (I have only learned, at best, 3/6 of his suggested language categories, and I am on the 4th).
DanWaterworth 13y ago
The idea that the world appears to mutable and therefore programming languages should encourage mutation in order to model it is one that doesn't make any sense. To me, it makes much more sense to try to create programming languages that are able to express human thought. People think in terms of things that are, to a first approximation immutable, memories are a good example.
nailer 13y ago
> The thing about "Class based Programming" - or Object Orientated Programming You can have OOP without classes - prototypal inheritance for example. In JS, you just clone an exemplar with Object.create() for example. That said, the article author does the same thing.
- collyw 13y ago
  Having used Angular for a month or so in summer, I find prototypal inheritance horrible and unpredictable. I am never 100% sure if the data is coming from or updating the parent object or the current object. Class based inheritance seems a lot more predicable to me.
  - nailer 13y ago
    If Angular is your only experience of JS, I'm surprised you don't think JavaScript is the most complicated language in existence.
zeteo 13y ago
>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol manipulation. Trying to make it correspond to "real" objects is about as hopeless as basing literature on coloring books.
- delinka 13y ago
  "... RectangleCollectionColorPickerFactory ..." Sounds like you're blaming the OO world for Java's problems. But I digress... Trying to make code correspond to real world objects is annoying because after you've modeled your Car with Wheels that support Tires, and an Engine with EngineParts attached ... you then have to write a adaptation layer to make all that fit into your storage engine, your user interface, your query engine, etc ad nauseam. Strings are not "real world" objects, but we use them in our code nonetheless. They're a great UI item that lets us interface with our users. "I need input from the user. Here, type some text in this field and I shall call it String." Now you can manipulate the String with operations (methods on the object) that make sense for Strings. Point: OO is not about "modeling the real world," it's about code organization. Some people organize with OO. Some with other means.
  - emn13 13y ago
    It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critical concepts like factories, and that you will have a hard time elsewhere, for example in testing (this is what you often see in C#, for instance) or with global state (a common issue in ruby code). There is of course an alternative: use a function rather than a factory; but that's kind of the point of this discussion :-). (Before we start a flame war: This isn't a criticsm of ruby or C# specifically, it's just something I've seen a lot in those code bases. Both languages allow writing factories or using lambdas.)
jonahx 13y ago
Yes. The article correctly points out potential pitfalls of OOP but glosses over its benefits: > See, mutable state makes shorter English sentences, and the agent concept helps make analogies with our fellow humans. In the end, this first impression trumps the fact that avoiding mutable state where possible ultimately yield simpler programs. - But shorter English sentences are awesome. - Good analogies are awesome. - Effectively communicating with our fellow humans is awesome. Indeed, all these things contribute to simplicity. I find that often critiques of OOP are actually critiques of poorly implemented OOP. When it's done well, it can retain many benefits of immutability while still mapping more naturally to domain concepts. This talk by Gary Bernhardt is a great discussion of using functional concepts in OOP, and doing OOP well: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries The talk "Functional Core, Imperative Shell" is also a must see.
- jeremyjh 13y ago
  > - But shorter English sentences are awesome. You missed the author's point here. He of course prefers shorter sentences as well. He is complaining that mainstream language syntax is biased in favor of mutability since you need to use an extra keyword to make a const expression. In F# for example it is just the opposite, you have to use the keyword "mutable" in your declaration.
thearn4 13y ago
> pick what language and coding paradigms best suit your problem domain and you as a coder An addendum: there is often no single obvious best way to do something. Though many approaches are obvious as being less wrong than others.
runarberg 13y ago
Note that Class based != Object Oriented. Also note that theories that have tried to categories real world objects into classes have a tendency to fail (although they also have a tendency to become enormously popular [see Platon and Aristoteles fx.]). So the claim that classes allows you to model a problem in real-world terms, is most likely false. See for example http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.4713&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.... for a review.
quim05 13y ago
"it allows you to model a problem domain in real-world terms" Which is exactly the kind of specious, guesswork solution one would expect from non-practising management types and committees. In most situations, the contortions and indirection involved in this kind of approach usually outweigh any real benefits.
d23 13y ago
> cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms. It absolutely reduces cognitive overload. Having "containers" of functionality that allow me to easily know at a glance what I'm working with is invaluable. I'm not knocking functional programming, since I haven't built a few projects in a purely functional language yet, but trying to do some things with the functional paradigm (or at least, my understanding of it) left me recognizing class-based programming as a powerful tool when used correctly.
- Peaker 13y ago
  In fp, those containers are known as modules.
evanspa 13y ago
I love Hal Abelson's opening of this SICP lecture[1], in which he acknowledges that OO (with mutable state) is born from the idea of modeling computer programs the way we perceive the world. But then he goes on to say that the reason why OO can be so complicated (because of having to deal with the can-of-worms that is mutable state) is because maybe we have the wrong view of reality. He then proceeds to launch his piece of chalk across the room! (good stuff). And proposes that instead of the chalk having changing state (position, velocity, etc), instead, its better to thing of the chalk as a collection of immutable values; each value existing at a moment in time. And this of course aligns more to functional programming; and you see the same notion (immutable values over time) with descriptions of Datomic. [1] http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
- davexunit 13y ago
  What a great lecture. Thank you for sharing. I own and have read a good portion of SICP and these lectures are a great supplement to that.
Nekorosu 13y ago
The problem is it's not real-world most of the time.

by choult 13y ago

danenania 13y ago

OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.

arethuza 13y ago
"everything is a process" To me that's as bad as saying "everything is an object". I'd rather try and understand where each approach is best rather than picking a single approach and dogmatically applying it in every scenario.
- wcummings 13y ago
  I think his point is that the real world is concurrent states, not context switching. To loosely paraphrase Joe Armstrong, in the real world, data isnt shared, it's communicated. In this sense, the process as a fundamental abstraction more correctly models "the real world."
theseoafs 13y ago
I'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same?
- SamReidHughes 13y ago
  No need to apologize. With immutability you have to explicitly model temporal changes.
- tomp 13y ago
  Yes. Due to Special Relativity, different observers perceive events (changes to object state) at different moments, the state of the whole universe is not consistent. Therefore, we model the universe using a sequence of immutable universe snapshots, with different computational agents independently moving through the (branching) timeline of snapshots, so that each and every one of them views the universe consistently.
  - pmahoney 13y ago
    Most events humans care about happen in plain old classical physics, and no computer is moving at some large fraction of light-speed relative to any other computer. If you maintain synchronized clocks, everyone can agree on the exact same order of events (which would not be true in a relativistic situation). Now it turns out to be difficult to maintain synchronized clocks, and Lamport timestamps and vector clocks are alternatives. The end result looks similar to a relativistic situation, but (and I'm not a physicist), it seems wrong to claim this situation is because of Special Relativity. Thoughts?
    - tomp 13y ago
      Yes. I was half joking, half explaining why immutability actually is better to model the universe. In practice, replace Special Relativity with Network Problems.
  - eloff 13y ago
    So what you're saying is the universe is mapped COW, and everytime there's a new observer, UniverseOS runs it with fork().
- evanspa 13y ago
  Check out the first 20 minutes or so of this SICP lecture. In it, Abelson specifically mentions special relativity as a way for us humans to "model" the real world as immutable values over the continuum of time (in contrast to a mutable world that fits with OO). http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
deleted 13y ago
[deleted]
w0utert 13y ago
>> In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Been reading up on Heraclitus lately? While this is an interesting statement for a philosophical dialogue, it doesn't really make much sense in the context of programming, where many things are constant, many things are not processes, and there are plenty of use cases for both mutable and immutable state (which is exactly why I always get really defensive reading articles like this one, that pretend all problem domains would be best modelled by a single programming language/paradigm/model of computation).
- Mikera 13y ago
  It makes a lot of sense in the context of programming when you look at the big picture. I think Rich Hickey articulates it best: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich...
collyw 13y ago
"OOP actually doesn't model the real world well at all." Surely that is in part due to the developer. Poor developers will choose the wrong abstractions, and have a poor OOP model as a result. Better developers will choose the correct abstractions, and have better models. Obviously the domain you are modeling will make it easier or harder to model things, and in some cases OPP may not be a good choice at all. In my day to day work I use Django. I start with a data model - based on an ER diagram. I code that in the Django model classes. Is that OOP modeling or ER modeling? I don't know. I don't really care too much. It works fairly well for most things I am doing.
hcarvalhoalves 13y ago
> OOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. This is important, and something almost everybody ignores. Get an OO codebase, and try to implement a time-dependent feature, like snapshots, or even a simple undo. The abstractions fall apart.
mrkhwrd3 13y ago
A criminal tells the arresting police officer: - You're wrong, officer. It was yesterday-me who committed the crime but you are trying to arrest now-me. How wrong are you! I bet the authorities around the world don't like your time-inclusive-dimenstion view much.
- matjazmuhic 13y ago
  You do realize that there's a difference between an object with identity (ddd names it entity) and the one without it (ddd names it value object). No matter what you do, identity does not change. You commiting a crime yesterday was an event that included you as an object with identity and today you have the same identtiy so you are clearly responsible for what you did yesterday. GUARDS! :P
homami 13y ago
We can think the state of the world is immutable. When the state changes, it's a different world. If space-time is discontinuous, then we can think any change of state, like motion, as a set of discrete changes. If we think the motion of a particle from one energy bin to another is immediate (meaning the particle cannot be found on the border between the bins, or one moment the particle is in Bin A, next it is in Bin B) then we can think the particle was destroyed in Bin A and another one was created at Bin B. And this is what we call motion from A -> B.

kitsune_ 13y ago

Mutable state can be a huge pain in the ass. A common mistake OOP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled objects that all directly or indirectly manipulate each other's internal states. If you've ever had to work with such a code base for a prolonged amount of time you are pretty quickly ripe for a year-long sabbatical. There is simply no way to reason about the control flow and state of the program without investing a lot of time and mental effort. Sometimes it's almost impossible. I don't know, I think it's a point where education fails. Your average enterprise developer should be forced to read books like "Clean Code" by Bob Martin before being allowed to touch a keyboard.

w0utert 13y ago
>> Mutable state can be a huge pain in the ass [..] 8I don't know, I think it's a point where education fails* I'd argue that the problem with software quality is not so much in the (ab)use of mutable state, but the fact that (especially in enterprises) software often reflects the organizational structure of the people who worked on it. Exhibit A: the software solution where every tiny part of the system is developed by some (semi) random group of people that often changes, doesn't directly communicate with any of the other groups, doesn't bother to much with the 'architecture' of the complete system (a big ball of mud), and has no interest improving either the overall architecture of the system, or any of the components outside their scope. Add pervasive mutable state into this mix, and you have a recipe for disaster. That's not to say the mantra 'eliminate (almost) all forms of mutable state' will improve this problem much.
drharris 13y ago
>> Immutable state can be a huge pain in the ass. A common mistake FP beginners, and even "experienced" developers, make is the creation of this complex jungle of entangled functions. See what I did there.
- Paradigma11 13y ago
  The analogy would be that those functions are mutually recursive and while mutual recursive functions can be an elegant solution to several problems (state machine, some algorithms)overuse is not a mistake i have seen very often. FP does coerce, or at least very strongly suggests, a very simple program structure. This makes it hard to model some more complex relationships that are easy in OO. Anyway, my point is that FP is indeed different in this regard compared to OO.

JackMorgan 13y ago

I agree wholly that picking the right tool is critical. I also think you have to be skilled at a broad subset of all the tools to be able to even make any sort of comparison. Many times I've heard this argument from someone who only knows the one or two tools they learned in college or in their first job, and they try to dress up their ignorance as wisdom for "not wasting time on the wrong tools". I recommend http://norvig.com/21-days.html http://norvig.com/21-days.html as a great place to start (I have only learned, at best, 3/6 of his suggested language categories, and I am on the 4th).

DanWaterworth 13y ago

The idea that the world appears to mutable and therefore programming languages should encourage mutation in order to model it is one that doesn't make any sense. To me, it makes much more sense to try to create programming languages that are able to express human thought. People think in terms of things that are, to a first approximation immutable, memories are a good example.

nailer 13y ago

> The thing about "Class based Programming" - or Object Orientated Programming You can have OOP without classes - prototypal inheritance for example. In JS, you just clone an exemplar with Object.create() for example. That said, the article author does the same thing.

collyw 13y ago
Having used Angular for a month or so in summer, I find prototypal inheritance horrible and unpredictable. I am never 100% sure if the data is coming from or updating the parent object or the current object. Class based inheritance seems a lot more predicable to me.
- nailer 13y ago
  If Angular is your only experience of JS, I'm surprised you don't think JavaScript is the most complicated language in existence.

zeteo 13y ago

>The thing about [OOP] is that it allows you to model a problem domain in real-world terms. That's only true on a superficial level. Sure, in CS 101 it's easy to explain how to make a Point object and add a Move() method to it. But dive into any real-world code base and you're more likely to meet RectangleCollectionColorPickerFactory instead. Let's face it, writing a large program is an exercise in abstract symbol manipulation. Trying to make it correspond to "real" objects is about as hopeless as basing literature on coloring books.

delinka 13y ago
"... RectangleCollectionColorPickerFactory ..." Sounds like you're blaming the OO world for Java's problems. But I digress... Trying to make code correspond to real world objects is annoying because after you've modeled your Car with Wheels that support Tires, and an Engine with EngineParts attached ... you then have to write a adaptation layer to make all that fit into your storage engine, your user interface, your query engine, etc ad nauseam. Strings are not "real world" objects, but we use them in our code nonetheless. They're a great UI item that lets us interface with our users. "I need input from the user. Here, type some text in this field and I shall call it String." Now you can manipulate the String with operations (methods on the object) that make sense for Strings. Point: OO is not about "modeling the real world," it's about code organization. Some people organize with OO. Some with other means.
- emn13 13y ago
  It's not just java - any good OO platform has those problems. If you don't have that problem, it's worse: that tends to mean you failed to abstract away critical concepts like factories, and that you will have a hard time elsewhere, for example in testing (this is what you often see in C#, for instance) or with global state (a common issue in ruby code). There is of course an alternative: use a function rather than a factory; but that's kind of the point of this discussion :-). (Before we start a flame war: This isn't a criticsm of ruby or C# specifically, it's just something I've seen a lot in those code bases. Both languages allow writing factories or using lambdas.)

jonahx 13y ago

Yes. The article correctly points out potential pitfalls of OOP but glosses over its benefits: > See, mutable state makes shorter English sentences, and the agent concept helps make analogies with our fellow humans. In the end, this first impression trumps the fact that avoiding mutable state where possible ultimately yield simpler programs. - But shorter English sentences are awesome. - Good analogies are awesome. - Effectively communicating with our fellow humans is awesome. Indeed, all these things contribute to simplicity. I find that often critiques of OOP are actually critiques of poorly implemented OOP. When it's done well, it can retain many benefits of immutability while still mapping more naturally to domain concepts. This talk by Gary Bernhardt is a great discussion of using functional concepts in OOP, and doing OOP well: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries The talk "Functional Core, Imperative Shell" is also a must see.

jeremyjh 13y ago
> - But shorter English sentences are awesome. You missed the author's point here. He of course prefers shorter sentences as well. He is complaining that mainstream language syntax is biased in favor of mutability since you need to use an extra keyword to make a const expression. In F# for example it is just the opposite, you have to use the keyword "mutable" in your declaration.

thearn4 13y ago

> pick what language and coding paradigms best suit your problem domain and you as a coder An addendum: there is often no single obvious best way to do something. Though many approaches are obvious as being less wrong than others.

runarberg 13y ago

Note that Class based != Object Oriented. Also note that theories that have tried to categories real world objects into classes have a tendency to fail (although they also have a tendency to become enormously popular [see Platon and Aristoteles fx.]). So the claim that classes allows you to model a problem in real-world terms, is most likely false. See for example http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.4713&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.... for a review.

quim05 13y ago

"it allows you to model a problem domain in real-world terms" Which is exactly the kind of specious, guesswork solution one would expect from non-practising management types and committees. In most situations, the contortions and indirection involved in this kind of approach usually outweigh any real benefits.

d23 13y ago

> cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms. It absolutely reduces cognitive overload. Having "containers" of functionality that allow me to easily know at a glance what I'm working with is invaluable. I'm not knocking functional programming, since I haven't built a few projects in a purely functional language yet, but trying to do some things with the functional paradigm (or at least, my understanding of it) left me recognizing class-based programming as a powerful tool when used correctly.

Peaker 13y ago
In fp, those containers are known as modules.

evanspa 13y ago

I love Hal Abelson's opening of this SICP lecture[1], in which he acknowledges that OO (with mutable state) is born from the idea of modeling computer programs the way we perceive the world. But then he goes on to say that the reason why OO can be so complicated (because of having to deal with the can-of-worms that is mutable state) is because maybe we have the wrong view of reality. He then proceeds to launch his piece of chalk across the room! (good stuff). And proposes that instead of the chalk having changing state (position, velocity, etc), instead, its better to thing of the chalk as a collection of immutable values; each value existing at a moment in time. And this of course aligns more to functional programming; and you see the same notion (immutable values over time) with descriptions of Datomic. [1] http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/6a-streams-part-1/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...

davexunit 13y ago
What a great lecture. Thank you for sharing. I own and have read a good portion of SICP and these lectures are a great supplement to that.

Nekorosu 13y ago

The problem is it's not real-world most of the time.