211–220 of 253 posts
Earlier quoted context omitted.
Wait, learning curve? Relative to C++ or Java?
Java is perhaps cumbersome to use at times (and especially in older versions), but it's not a complicated language, in fact it is a lot simpler than most.
Earlier 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.
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…
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 others require their users to learn abstractions they were not used to.
The idea that all of this falls in the last category, with no capturing of the way "people think independent of the use of that language" is totally false to me. Sorry.
Earlier quoted context omitted.
Actually reading the whole article takes time, while reading the title and posting a knee-jerk reaction takes only a moment. One of the curses of a hotness-oriented system like HN is that earlier comments receive the bulk of the upvotes and responses, so it becomes less interesting to comment as time goes on. There are lots of little rules in place to minimize the damage of this (like no memes, jokes, pics, etc.; HN…
Actually, the article makes some far-fetched assertions which may not even correspond to reality and may not even be worth discussing at all. OO (in this case the author means C++) is less related to a programmer's understanding of reality compared to C because... programmers of the 90s make more errors that are harder to fix in C++. Yeah. Right.
But, it is reasonably hard data, and data has value, even if the interpretation is up for debate. I think if everyone had read the article, that'd be the more common theme of the discussion here: Are the conclusions valid based on the data seen, and either way, is it useful to know...is there something actionable in this data?
Earlier 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…
You also made your point very well, and all the facts you highlight support you and are good reason for me to doubt my conclusion regarding object oriented programming. I thought it's a terrible match for how people think about the world yet you give very strong reasons why I was wrong. (In other words you've convinced me.) Thank you.
In reaction to some of the comments popping up re. OOP and functional programming: I've come across quite a bit anti-OO sentiment in my career now, and not nearly as much anti-functional sentiment. I suspect that the prevalence of OOP has something to do with it - you're more likely to have been exposed to bad OO code than any other type simply because there's more of it. People often seem to draw an artificial disti…
I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…
>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog. This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same. This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is…
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; }
?
I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…
One of the main points of design patterns is composition over inheritance. Composition is also a major part of functional programming.
One of the opening pages of the Design Patterns book (the GoF book) has "Prefer composition over inheritance" (or words to that effect) as the only sentence on that page, right in the middle of it. My guess is that the GoF authors did that to emphasize the importance of that advice, maybe due to having seen too many brittle inheritance-laden hierarchies.
I mentioned this to a client I was consulting to, a couple of years ago, after I saw that he seemed to be using inheritance too liberally, and maybe without thinking if it was needed and the right thing to use for his specific needs. He did get the point, and changed his code from then on.
Earlier quoted context omitted.
>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog. This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same. This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is…
Is it true that all structural type systems are unsound? I was under the impression this is a typescript specific problem.
I think the big problem with OOP is that it's designed to simulate the real world but has the real world backwards. Real world objects are a composition of parts. The taxonomy of those objects, and its constituent parts, is am artificial construct independent of how those objects are composed. A frog is a frog because it fits some definition that experts agree on. The taxonomy comes afterwards - the composition just…
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…
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.
No doubt the OO language will give you some useful tidbits, so that you can have slightly non-trivial getter setters and whatnot. But the design ends up fundamentally procedural -- which I say is good thing.
Earlier quoted context omitted.
>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog. This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same. This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is…
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; } ?
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 compile and run like this the type system has failed its purpose of preventing developers from using the wrong types.