Does OO really match the way we think (1997) [pdf]

Post by [deleted] » Sat, Aug 12, 2017, 8:23 PM UTC

willtim wrote: post #186

imtringued wrote: post #173

Earlier quoted context omitted.

How can you know that without comparing the same programs with a FP version? What if those codebases would become messy even with FP simply because the problem they are trying to solve is difficult? Also in what way does OOP prevent you from writing the code in a FP-style? It doesn't because the concepts FP and OOP are orthogonal.

It is much harder to do functional programming in an OOP language, as one is often fighting the syntax, semantics and various defaults. For example all variables are typically by default mutable, null in every type, libraries and frameworks with pervasive mutable state etc. Granted it has been getting easier as OOP languages have been slowly getting more and more functional features. But it really is easier to favour…

Post by brudgers » Sat, Aug 12, 2017, 8:58 PM UTC

logicallee wrote: post #212

brudgers wrote: post #193

Earlier quoted context omitted.

That's not the idea I was trying to convey. I think any claim that any language (computer or ordinary or otherwise) captures the way people think independent of the use of that language is at least suspect [and for me probably false, but I could be wrong]. To me, it seems more likely that the flexibility of human cognition allows a person to think in terms of a programming language than any particular programming lan…

I'm afraid we disagree entirely. Before the existence of any computer language, humans talked, and thought: at various levels of rigor. Mathematical books were published for millennia. People thought, interpreted their world, argued with each other, and so forth. With the advent of computer languages, some of these have captured more of this independent thinking and abstraction, others capture less of it, while still…

Post by dyarosla » Sat, Aug 12, 2017, 9:59 PM UTC

adrianratnapala wrote: post #219

dyarosla wrote: post #111

Earlier quoted context omitted.

I think you'd benefit from taking a look at Entity Component Systems. Generally used for games, this programming pattern assigns behaviour to entities based on the components that they have. Moreover, neither entities nor components on their own actually own any behaviour. Behaviour occurs by systems that operate on entities with the associated component "signature". For example, an entity with a position and a veloc…

ECS as you describe it sounds like a good idea, but notice how it is a step away from OO which was supposed to keep code and data in a single encapuslated thing called an "object". Now our componenents are nearly just plain-old-data and entities are slightly more sophisticated data-structures for tying them together. All the code is now kept is "systems", which are starting to look very much like plain-old modules. N…

Post by kazinator » Sat, Aug 12, 2017, 10:14 PM UTC

empthought wrote: post #152

mbrock wrote: post #149

Earlier quoted context omitted.

Wait, isn't that exactly how lexical scoping in Scheme works? That's how you implement "objects" using lambdas. You make closures that mutate their closed-over bindings.

The question is if you mutate the variable, create a closure, mutate the variable, create a closure, and so on -- do those closures -- when executed -- each use the value that the variable had at the time the individual closure was created, or do they all use the latest value that the variable had? Scheme (and other academic languages) do the first, Python (and other scripting languages) do the second. But the proble…

Post by didibus » Sun, Aug 13, 2017, 1:13 AM UTC

slackingoff2017 wrote: post #220

didibus wrote: post #216

Earlier quoted context omitted.

Is structure defined just by type? Like is all things which only have two integer properties considered the same? { Int age; Int weight; } Would be equal to: { Int x; Int y; } ?

Close, any objects with the same properties and types are compatible. The name of the properties and their types need to match. And this isn't always a good thing. If you have a function dealing with the property 'length' or 'value' for instance, you might as well have no type system because Typescript will allow you to pass in any object with those properties which is almost anything. While the code will still compi…