Earlier quoted context omitted.
Mathematical books were published for millennia. Writing is thinking...etc.
Can you be a bit more precise? I feel like we're talking past each other but perhaps have misunderstood each other.
[deleted]
Does OO really match the way we think (1997) [pdf]
231–240 of 253 posts
Re: Does OO really match the way we think (1997) [pdf]
#232How to model a door. class Door { void open() {...} void close() {...} } door.open(). But can a door open itself? Maybe Man petya = ... petya.open(door); But can a door be opened if it's not installed? So walls should also come into play when we think about door and its methods. It's difficult to model the world with OOP (at least in its current state).
A `Door` is not an agent, so no, it can't open itself (unless it's a game and your doors have agency). When you say a door can be opened, you are making the assumption that the door is installed in some sort of building. But then, the door is a component of that building, not just a stand-alone door. It can only be opened in that context. So I would suggest something like this: class Door(Material, Size) class Room(L…
You still follow the naive OOP thinking and it remains ridiculous.
For example, why Room?
Re: Does OO really match the way we think (1997) [pdf]
#233Earlier quoted context omitted.
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…
I see, sounds interesting. Are the names namespaced? And how would a method know its compatible? Do you type the properties a method needs instead of the object name?
You pretty much act as you do with regular type systems, rarely creating types that are compatible by accident. There is one place however where you use structural typing constantly.
TypeScript is a superset of JavaScript and using "options" objects as method parameters is a common pattern. These options objects are synonymous with anonymous classes and don't have a name, only a shape. Structural typing is one of the strategies TypeScript uses to maintain compatibility with patterns in JavaScript that use these nameless objects.
There are no namespaces. Methods are compatible if they take the same or a subset of the parameters. Objects need to have matching property names and values.
Re: Does OO really match the way we think (1997) [pdf]
#234Earlier quoted context omitted.
I see, sounds interesting. Are the names namespaced? And how would a method know its compatible? Do you type the properties a method needs instead of the object name?
You pretty much act as you do with regular type systems, rarely creating types that are compatible by accident. There is one place however where you use structural typing constantly. TypeScript is a superset of JavaScript and using "options" objects as method parameters is a common pattern. These options objects are synonymous with anonymous classes and don't have a name, only a shape. Structural typing is one of the…
Hum, thanks for the info. I feel curious to try it out. I think names should be namespaced though, that could solve the issue of having a length or value named property. The namespace could distinguish between two values that aren't compatible for example. Though I guess if the types are precise enough, they could embed some of that.
Re: Does OO really match the way we think (1997) [pdf]
#235OO solves some problems and creates others. One must remember that the competing paradigm isn't functional programming but imperative procedural programming. Very large code bases in C, Fortran, Cobol aren't all that nice either. It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Many of OO's flaws are being addressed and are even missing from new languages. Rust "feels" OO…
> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix. Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...
>Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps.
?!
Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran.
This means at least 10-20x faster than CPython, Ruby's MRI and others.
I routinely read third-party Lisp libraries and they are very readable, no problems with that.
Re: Does OO really match the way we think (1997) [pdf]
#236I've noticed most HN comments transformed from being discussions about the _content_ of the article to comments discussing the _topic_ of the article being posted, not sure if this is healthy, but the risk is HN becoming an echo chamber where people discuss opinions, and the posts becoming just topic triggers. We'll see how it evolves.
That's true but the HN algorithm for deciding what articles make it to the front page has itself become very political. For example, the amount of articles about programming languages like Rust or Elixir is disproportionate compared to their actual relevance in the industry. HN has a very strong bias for functional programming. You almost never hear about Go or Node.js anymore except when there is a major release but…
> For example, the amount of articles about programming languages like Rust or Elixir is disproportionate compared to their actual relevance in the industry.
But not to their possible relevance.
Re: Does OO really match the way we think (1997) [pdf]
#237Earlier quoted context omitted.
But I came here to read commentators' statements on the subject. I only clicked the paper due to your comment. The paper makes the claim, early, "[OOP's] central premise appears to be that it matches the way we think about the world." This is the same as the title, and enough for us to discuss. I want to hear what people here have to say about the subject. That's a lot more interesting than what this 1997 paper has t…
If writing is thinking (and googling "writing is thinking" quote produces plenty of hits), then object oriented code reflects the way we think because we write it...I mean thinking in terms of object orientation is pretty a given in order to right object orientated code. That's a different proposition than object oriented programming reflects the primary way humans think or the only way humans think. Without diving d…
> then object oriented code reflects the way we think because we write it
There are non-linguistic modes of thought that more naturally capture our intuition of evolving systems. You don't linguistically think through a baseball play in the moment. The most intuitive programming paradigms are actually event-driven [1].
To summarize, you can compute by thinking and you might be able to think by computing, but thinking is not like computing. Any particular programming paradigm is a mode of computing, not thinking. A programming paradigm that more closely aligns with thinking is more intuitive and natural, and will lead to fewer errors.
Re: Does OO really match the way we think (1997) [pdf]
#238Earlier quoted context omitted.
By that standard it is impossible for any type system not to match the way we think: for example a programming language could be abstracted in terms of food, recipes, and breakfast, lunch, and dinner, and express literally everything that way. Although by your standard our code would then match the way we think, clearly this is not a useful takeaway.
You're not refuting the point he was making, because no one is writing code in such a language. > If writing is thinking, then object oriented code reflects the way we think because we write it The point is the huge majority of systems (by any metric; number of engineers, lines of code, budget, ...) are written in an OO style (regardless of whether the language actually supports OO; practically all bigger C projects…
I actually don't think any of the points you've raised are valid or empirically supported at all.
Most novices do not in fact find OO easy to learn, and most novices do not in fact find FP harder than OO to learn. What you are probably alluding to is the difficulty in learning a specific language, like Haskell. Haskell is not FP.
Also, while most software projects use some kind of OO language these days, I don't know why in the world you'd think this somehow entails it fits our thinking. By all accounts, software defect rates aren't any better under OO than under procedural language paradigms. How does that make it intuitive?
To make any kind of "reasonable" conclusion, you'd need a comparison against software written under other paradigms. Such studies have been done, and OO does not fare as well as other paradigms on many metrics.
Re: Does OO really match the way we think (1997) [pdf]
#239Earlier 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…
Given an object with a length property with the type a method expects, is there ever a scenario where the method is incorrect?
I'm trying to wrap my head around it: if a method needs only the length property, which is an unsigned int, is there any good reason why it shouldn't accept any object that has that property?
It appears at first that this is a good quality: the code is general whilst obviously avoiding any type errors, including null/undefined errors.
Re: Does OO really match the way we think (1997) [pdf]
#240Earlier quoted context omitted.
> You are simply using objects to encode this and not making any use of their identify and mutable state. Most software with undo-redo will show you some metadata related to the action (for instance "Undo 'Drag stuff'", "Redo 'Set text in bold'"...) so you have to have a way to associate metadata with the "undo / redo" functions; the class is a good tool for this. Also, a common optimization is to alter the head of t…
You can do that optimization in FP languages if you have unique types, ie, types that can only have one reference to them. You use the list as if it's immutable, by creating a new list with the new command and the rest of the previous list. But since the compiler can prove that the old list is no longer referenced, it can reuse it and simply make the update in-place.
could you show an actual example where commands are polymorphic types (e.g. they come from a separate DLL) and this optimization actually happens ? (the actual "updating" of the command doesn't need to cross DLL boundaries, eg a DLL both provides a command, instantiates it, and updates it. The command queue is instantiated by another DLL though).