4 ms·

High-school-me bounced off several Java and C++ books with their stupid "sally wants to buy flowers and john's flower shop" explanations of objects were before

by ashark 9y ago

High-school-me bounced off several Java and C++ books with their stupid "sally wants to buy flowers and john's flower shop" explanations of objects were before finally realizing, while using an OO PHP library, what was actually going on. Felt like people'd been deliberately obtuse to keep me from learning. "It's just structs with functions attached and a couple reall-easy-to-explain sugary features on top" would have been much better.

cperciva 9y ago
I will be forever grateful that an appendix to one of the Turbo Pascal manuals described exactly how objects were laid out in memory (including function pointers).
- lobster_johnson 9y ago
  Turbo Pascal's manuals came with a separate volume dedicated solely to OOP. It's one of the best technical manuals I've ever read. Beautifully typeset, too [1]. Borland's technical documentation was really, really good at that time. [1] ftp://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_5.5_Object-Oriented_Programming_Guide_1989.pdf
  - cperciva 9y ago
    Looks like what I was remembering as being an appendix was actually the last chapter of that volume: "Inside Turbo Pascal"
taneq 9y ago
> Felt like people'd been deliberately obtuse to keep me from learning. When I get that feeling, what's really happening 99% of the time is that the person trying to explain actually has no idea what they're talking about, but doesn't want to admit it. If you understand a concept well enough, you can explain it simply and succinctly (barring things like really esoteric maths/physics, but nothing in computing is that difficult in my experience).
problems 9y ago
Yeah, honestly, I think I didn't "get it" until I read about vtables and the use of ecx as the "this" pointer while learning reverse engineering. I think I struggle to learn a lot of functional programming concepts now because it's even more distant and abstract explanations.
- lacampbell 9y ago
  I think I struggle to learn a lot of functional programming concepts now because it's even more distant and abstract explanations. I've come across this a lot. Some people (like you perhaps) view computing in terms of machines, and others in terms of mathematics and formalism. (I'm lazy and lack principle, so I will go with whatever interpretation is easiest.) FWIW, I've met at least one incredibly smart person from both camps. If you're into compilers at all, you might appreciate this[1] - how the "machine tribe" and "lambda tribe" view the same thing. [1] https://wingolog.org/archives/2011/07/12/static-single-assignment-for-functional-programmers https://wingolog.org/archives/2011/07/12/static-single-assig...
humanrebar 9y ago
> Felt like people'd been deliberately obtuse to keep me from learning. Well, that's one way to put it. What's really going on is they are trying to describe an abstraction from a user's perspective. So you could say the point of abstraction is to be "deliberately obtuse" in a productive and healthy way. It's also common for people to try and fail to abstract things. Bad abstraction can be a net negative. It's likely that was what happened here. And, to agree with you, OOP as a taxonomy of physical objects is both a pervasive and a bad idea. The point of classes and objects is to group data and functionality together. The things you do with a "Rose" may or may not look like the things you do with a "Cactus". Forcing them into the same hierarchy of behaviors because they are both "Plants" is injecting extra requirements into the system.

by ashark 9y ago

cperciva 9y ago

I will be forever grateful that an appendix to one of the Turbo Pascal manuals described exactly how objects were laid out in memory (including function pointers).

lobster_johnson 9y ago
Turbo Pascal's manuals came with a separate volume dedicated solely to OOP. It's one of the best technical manuals I've ever read. Beautifully typeset, too [1]. Borland's technical documentation was really, really good at that time. [1] ftp://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_5.5_Object-Oriented_Programming_Guide_1989.pdf
- cperciva 9y ago
  Looks like what I was remembering as being an appendix was actually the last chapter of that volume: "Inside Turbo Pascal"

taneq 9y ago

> Felt like people'd been deliberately obtuse to keep me from learning. When I get that feeling, what's really happening 99% of the time is that the person trying to explain actually has no idea what they're talking about, but doesn't want to admit it. If you understand a concept well enough, you can explain it simply and succinctly (barring things like really esoteric maths/physics, but nothing in computing is that difficult in my experience).

problems 9y ago

Yeah, honestly, I think I didn't "get it" until I read about vtables and the use of ecx as the "this" pointer while learning reverse engineering. I think I struggle to learn a lot of functional programming concepts now because it's even more distant and abstract explanations.

lacampbell 9y ago
I think I struggle to learn a lot of functional programming concepts now because it's even more distant and abstract explanations. I've come across this a lot. Some people (like you perhaps) view computing in terms of machines, and others in terms of mathematics and formalism. (I'm lazy and lack principle, so I will go with whatever interpretation is easiest.) FWIW, I've met at least one incredibly smart person from both camps. If you're into compilers at all, you might appreciate this[1] - how the "machine tribe" and "lambda tribe" view the same thing. [1] https://wingolog.org/archives/2011/07/12/static-single-assignment-for-functional-programmers https://wingolog.org/archives/2011/07/12/static-single-assig...

humanrebar 9y ago

> Felt like people'd been deliberately obtuse to keep me from learning. Well, that's one way to put it. What's really going on is they are trying to describe an abstraction from a user's perspective. So you could say the point of abstraction is to be "deliberately obtuse" in a productive and healthy way. It's also common for people to try and fail to abstract things. Bad abstraction can be a net negative. It's likely that was what happened here. And, to agree with you, OOP as a taxonomy of physical objects is both a pervasive and a bad idea. The point of classes and objects is to group data and functionality together. The things you do with a "Rose" may or may not look like the things you do with a "Cactus". Forcing them into the same hierarchy of behaviors because they are both "Plants" is injecting extra requirements into the system.