7 ms·
They're both wrong. Closures and Objects are both structures with function pointers and delusions of grandeur.
by cperciva 10y ago
They're both wrong. Closures and Objects are both structures with function pointers and delusions of grandeur.
- Cieplak 10y agoColin, Curious if this opinion extends to something like an Erlang process or a BSD thread. Thanks btw for all your FreeBSD work :))
- cperciva 10y agoI don't know enough about the implementation of Erlang to answer that question.
- Cieplak 10y agoI'm sorry to dissect your quote, which is hall-of-fame-worthy, guess I'm just curious if it's always turtles all the way down, or if there is a "right" level of leak-proof abstraction. I imagine that every abstraction leaks in certain contexts, but maybe certain ones have stuck just because they're "good-enough" for common cases. I suppose I brought up processes and threads since they might provide for a level of parallelism that raw objects or closures lack, without an OS or runtime supporting them.
- taneq 10y agoWhich is funny because I could never get anyone, when I first started programming in C and everyone was raving about how great 'object oriented programming' was, to tell me what 'an object' actually was. When I started learning C++ I was somewhat disappointed to find out an object was just a struct with some functions attached. (It's kind of like when people told me about "user defined data types" and I couldn't wrap my head around how you could create a new data type with all its associated syntax. Then when I learned that they were just bundles of existing data types, though 'oh is that all?')
- abritinthebay 10y agoWell, to be fair, "objects" as originally envisioned were not like C++ implemented it. The guy that invented OOP is on record as saying that.
- ashark 10y agoHigh-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 10y agoI 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 10y agoTurbo 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 10y agoLooks like what I was remembering as being an appendix was actually the last chapter of that volume: "Inside Turbo Pascal"
- taneq 10y 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).
- viraptor 10y agoAnd in practice usually with an implementation of lots of useful functionality and good integration into the type system. I mean objects are structures with pointers in the same way that OS is just an RPC server and databases are lists of arrays. ;-)
- goatlover 10y agoAnd lists are just cons cells.
- BurningFrog 10y agoSimplifications are just ordered letters!
- mycall 10y agoCon cell is just a 2-tuple node in a singly linked list. When do the definitions all end?
- runeks 10y agoThat's an implementation detail.
- cperciva 10y agoExactly! But because this is how objects are implemented, everything you can do with objects, you can do using structures and function pointers -- there's nothing magical about objects. Which means that as long as you understand structures and function pointers you don't need objects.
- runeks 10y agoRight, but all programming language constructs are eventually reduced to assembly code. So, strictly speaking, as long you understand assembly, you don't need any language constructs at all. This fact doesn't offer us any insight into the nature of language constructs, though.
- pg314 10y agoExactly. To quote Alan Perlis: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
- millstone 10y agoOf course a design centered around structs equipped with function pointers is, in fact, an object system.
- cperciva 10y agoSure. But realizing that objects are just structs with function pointers takes you from a binary "this code uses objects" vs. "this code doesn't use objects" to a more flexible "this code is designed in a more objecty way than that code". A lot of people think about objects as a language feature, when they're really a design paradigm; and like all good design paradigms, you can use more or less of them depending on how well the paradigm fits a particular piece of code.
- camus2 10y agoYou don't use objects because they are function pointers. You use object because it makes establishing contracts between them convenient. Closures can't replace that.
- antonvs 10y agoBy the same token, structures with function pointers are just Turing Machine bitstrings with delusions of grandeur.
- ScottBurson 10y agoCan't agree with this at all. Bare function pointers are inadequate for many purposes; using them often requires explicitly passing around an additional environment pointer ('qsort_r' on Linux is an example), which is ugly and not type-safe. What you see as "delusions of grandeur" I see as the elegance of two concepts which, while duals with each other, are much more general than bare function pointers. (And yes, I understand very well how closures and objects are implemented using function pointers.)
- agumonkey 10y agoI disagree, structure is an encoding scheme that embodies some interface ! :) No layer is truer than another IMO, it's hard to say which matter the most.. the abstraction or the implementation.
- gpderetta 10y agoBah! Function pointers are glorified gotos.