IMO language should be designed to be more effective, simpler or powerful, not to avoid programers to miss use them. All the "rules" about not using goto for example are legitimate but people forget that sometimes using goto could be a good practice in some languages. A semantic is just a tool you can miss used it`s programer issue not a language/semantic issue. OOP is a way to program among other we can argue that i…
An adage I use is you should know all the rules so you know when and which to break.
Classes Considered Harmful [pdf]
61–70 of 129 posts
Re: Classes Considered Harmful [pdf]
#62The practical usefulness of classes in C++ comes not from an "object-orientedness" that they supposedly give the language. It comes from the fact that they are merely a mechanism that can be used to create abstract data types, thereby providing a better encapsulation, and do many other things, rather than a policy saying that every object must be an instance of a class. So, one has to be careful when talking about cl…
Classes tightly couple functions on types with the type declaration itself. It's often not even clear in which class certain methods belong. Better to separate data types from functions on data types the way it's done in functional languages, and if you still want object-oriented programming, you can support it like Ada does, or as syntactic sugar over the ordinary call syntax like some functional languages do.
Re: Classes Considered Harmful [pdf]
#63Earlier quoted context omitted.
Classes tightly couple functions on types with the type declaration itself. It's often not even clear in which class certain methods belong. Better to separate data types from functions on data types the way it's done in functional languages, and if you still want object-oriented programming, you can support it like Ada does, or as syntactic sugar over the ordinary call syntax like some functional languages do.
Better why?
Class hierarchies are inherently unfriendly to strong, sound type systems. Interface composition isn't.
Composing interfaces is clean and straightforward. Composing classes isn't, and you run into things like the diamond problem.
Re: Classes Considered Harmful [pdf]
#64Earlier quoted context omitted.
An adage I use is you should know all the rules so you know when and which to break.
The problem is that this requires rules to not actually be rules, but strong recommendations. Compilers are good at rules, less so with strong recommendations, which end up in static analysis tooling.
Re: Classes Considered Harmful [pdf]
#65Earlier quoted context omitted.
I think that inheritance can have a place. It makes a lot of sense when writing //small variations// on an otherwise rich inner class. Small variations might include layering on a different input or output mechanism, or possibly handling 'extra' data that the object stores but previously did not modify.
You can achieve the same with composition or parametrisation. Both of which are the only tools in a functional language.
Re: Classes Considered Harmful [pdf]
#66Computer science gets a lot of papers with arguments for a certain way of doing things. Very few with controlled experiments to find out if a way of doing things is better than another. Every time I mention this, people say that it is hard to do such experiments. Yes, it is hard to actually know things. while it is very easy to make plausible arguments, for almost anything.
This applies to you, too. What controlled experiments have you performed to test productivity differences of different methods of programming?
Re: Classes Considered Harmful [pdf]
#67* Interfaces
* Records
* Abstract data types
* All the above should use foo.bar() syntax
Classes provide those things, which is good, but also provide implementation inheritance, which is bad.
Re: Classes Considered Harmful [pdf]
#68I feel like I just read a lot of opinions by one frustrated dude without a real sense of why classes are bad (or even really why they frustrated him so much). Am I missing something?
Re: Classes Considered Harmful [pdf]
#69In the early history of smalltalk Alan Kay talks about how he was never entirely satisfied with inheritance, and having inheritance in the language (quoting in full, hard to link to):
A word about inheritance. Simula-I had neither classes as objects nor inheritance. Simula-67 added the latter as a generalization to the ALGOL-60 structure. This was a great idea. But it did have some drawbacks: minor ones like name clashes in multiple threaded lists (no one uses threaded lists anymore), and major ones like rigidity in the extended type structures, need to qualify types, only a single path of inheritance, and difficulty in adapting to an interactive development system with incremental compiling and other needs for instant changes. Then there were a host of problems that were really outside the scope of Simula's goals: having to do with various kinds of modeling and inferencing that were of interest in the world of artificial intelligence. For example, not all useful questions could be answered by following a static chain. Some of them required a kind of "inheritance" or "inferencing" through dynamically bound "parts" (i.e. instance variables). Multiple inheritance also looked important but the corresponding possible clashes between methods of the same name in different superclasses looked difficult to handle, and so forth.
On the other hand, since things can be done with a dynamic language that are difficult with a statically compiled one, I just decided to leave inheritance out as a feature in Smalltalk-72, knowing that we could simulate it back using Smalltalk's LISPlike flexibility. The biggest contributor to these AI ideas was Larry Tesler who used what is now called "slot inheritance" extensively in his various versions of early desktop publishing systems. Nowadays, this would be called a "delegation-style" inheritance scheme [Liberman 84]. Danny Bobrow and Terry Winograd during this period were designing a "frame-based" AI language called KRL which was "object-oriented" and I believe was influenced by early Smalltalk. It had a kind of multiple inheritance—called perspectives—which permitted an object to play multiple roles in a very clean way. Many of these ideas a few years later went into PIE, an interesting extension of Smalltalk to networks and higher level descriptions by Ira Goldstein and Bobrow [Goldstein & Bobrow 1980].
By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in its semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). For example, inheritance and instancing (which is a kind of inheritance) muddles both pragmatics (such as factoring code to save space) and semantics (used for way too many tasks such as: specialization, generalization, speciation, etc.) Alan Borning employed a multiple inheritance scheme in Thinglab [Borning 1977] which was implemented in Smalltalk-76. But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan's original Simula-like design.
Re: Classes Considered Harmful [pdf]
#70Earlier quoted context omitted.
Forgive my ignorance. What do Rust and Go call their data structures that are analogous to classes?
There really isn't a direct analog in Rust. The best approximation in Rust is actually a combination of constructs in the language: structs and traits. Structs are almost exactly like the C-objects of the same name: they define layout in memory for a data structure with discrete types as fields, and there are various packing options available. However in addition to this a struct-specific implementation can exist whi…