12 ms·
How Class-based Programming Sucks (2011)
- rowanseymour 13y agoBest (and most humorous) argument against Java's object oriented obession that I've ever read is: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- pjmlp 13y agoThe funny thing is that many like to bash Java's OO model, and in the process forget that Smalltalk, Eiffel, C# and many others offer a similar model.
- astrobe_ 13y agoWhat's really funny is to claim that the Java/C++ model is similar to the Smalltalk model.
- pjmlp 13y agoKind of, yes. You can map instance methods to normal methods in Smalltalk. And static methods to class methods in Smalltalk. Of course, you don't have the dynamism of sending messages, instead of invoking method calls. However given that Smalltalk is the originator of OO and everything is an object, OO critics would feel in prison most likely. :)
- Alphasite_ 13y agoI thought Simula was the originator of OO?
- enobrev 13y agoI truly miss Steve Yegge's rants.
- stopthemadness 13y agoIt's more that Java is hard because naming things is hard and Java forces developers to name lots of things.
- rayiner 13y agoThis is a very good article. The point about mutable state is key. Class based programming encourages you to treat objects as little bags of mutable state, instead of as values, and everything goes downhill from there. Its one thing to not go all the way to disallowing mutation. Its another to encourage it to be used pervasively.
- jimmaswell 13y agoProrgramming without mutating state is honestly just bizarre to me. Mutating state is all a program does, literally.
- choult 13y agoThe thing about "Class based Programming" - or Object Orientated Programming - is that it allows you to model a problem domain in real-world terms. No one approach is ever going to be perfect; OO being mutable makes it perhaps less founded (on the face of things) on formal principles, but for a lot of large codebases it can have a great beneficial effect on readability and maintainability - cognitive overhead is, perhaps, reduced when you can "ground" your understanding in real-life terms. At the end of the day, pick what language and coding paradigms best suit your problem domain and you as a coder. Pick right, and there's no mistake there.
- danenania 13y agoOOP actually doesn't model the real world well at all. It seems to on the surface, but it completely ignores time. In the real world, everything is a process. Nothing ever stays the same or stands still. No object is the same object from one millisecond to the next. Immutable state isn't just a formal exercise--it's a more authentic model of the world.
- arethuza 13y ago"everything is a process" To me that's as bad as saying "everything is an object". I'd rather try and understand where each approach is best rather than picking a single approach and dogmatically applying it in every scenario.
- wcummings 13y agoI think his point is that the real world is concurrent states, not context switching. To loosely paraphrase Joe Armstrong, in the real world, data isnt shared, it's communicated. In this sense, the process as a fundamental abstraction more correctly models "the real world."
- theseoafs 13y agoI'm sorry, are you arguing that immutability models the world more well than OO because no object in the real world ever stays the same?
- auggierose 13y agoIn case you don't know ML, you should. Also note that though OCaml is the most popular ML dialect right now, Standard ML is where it all started (PolyML is a good Standard ML implementation: http://www.polyml.org/ http://www.polyml.org/)
- JackMorgan 13y agoOr even F#, which is basically OCaml on the CLR. Very fast, fully supported IDE, great if you're stuck in SLAs for CLR code, complete interop with C# or VB.NET, it's the current hidden treasure of the .NET world.
- quim05 13y ago.NET sucks. Microsoft sucks. Take your transparent Microsoft advocacy elsewhere please.
- pjmlp 13y agoPity that Microsoft pushes it more for library code and not so much for full applications. But if it gets more use in the mainstream that way, then so be it.
- profquail 13y agoThe only difference between a "library" and a "full application" is that the "full application" has an entry point where execution begins, whereas a "library" does not. Many large applications are implemented as a thin user interface (GUI, web, services/APIs) which glues together a bunch of libraries (which is where all of the real functionality is implemented). This doesn't only apply to F#, but C#, Java, Python, etc. The reason F# gets used for implementing libraries is because that makes it easier to introduce into organizations with existing code in C# or VB.NET; a new component or plugin can be written in F# and easily utilized by the existing code, so the other developers in the organization don't need to anything differently than if they were consuming another C# or VB.NET component.
- 13y ago
- toolslive 13y agomutable state is not a problem per se. _Shared_ mutable state however, is a recipe for disaster. There are other problems with Object-Orientation. For example, it tends to scatter allocation which has performance impact. ( see this nice presentation: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... ) If performance is not an issue, I'd guess the price you pay for OO is that you eschew parallelism and concurrency.
- tomp 13y agoFunctional paradigms scatter allocation even more (though maybe more predictably, so the Generational Hypothesis is of more value in a functional programming language). Also, as soon as state escapes a function, it becomes shared, so should be immutable (except when explicitly made mutable).
- toolslive 13y agoany evidence for the 'even more' statement ?
- louthy 13y agoIt's a natural side-effect of using immutable structures. When you need to modify you allocate a new object with the mutation. This naturally has an impact on the GC because it needs to allocate and recover more garbage.
- DanWaterworth 13y agoThat's true, though it's also worth pointing out that immutability can make garbage collection easier.
- louthy 13y agoIndeed, and many of the objects will be very short lived, therefore getting collected in generation 0.
- arithma 13y agoI find a mix between Object-Orientation to model the problem, and a lot of functional thinking in the 'solving' department to be the most comfortable. The modernisation (as in taking features from the old languages into the newer ones) of C++, C#, Java, Obj-C etc. are all liberal with this direction.
- arethuza 13y agoI agree - in my experience object-orientation is at it's best at structuring a representation of the problem domain and functional thinking fits well with solutions. I've written a lot of code over the last few years that models large scale industrial systems and the general style is very much functional processes over immutable objects and this has worked pretty well.
- barrkel 13y agoClass-based programming works great for GUI toolkits. In most other contexts, the suitability is variable. OO is a horrible match for compilers, for example. The article is chasing down the wrong tree when he tries to build an Option type in C++, though. The normal OO way to handle the same class of functionality as ADT sum types is to use separate subclasses. What he's not acknowledging is that OO and functional+ADTs both only handle half the expression problem[1], in different ways. There's no absolute superiority for either model. It depends on the domain. Less mutability is good almost everywhere though. The lack of persistent data types is a blight on almost all non-functional container libraries. http://en.wikipedia.org/wiki/Expression_problem http://en.wikipedia.org/wiki/Expression_problem
- fhd2 13y ago> Class-based programming works great for GUI toolkits. That and games (and I'd wager simulations in general). The only two domains I'm familiar with which I cannot imagine without OO. From what I've seen, even UIs and games written in languages without support for OO still use something very close to OO. GTK for instance takes it quite far with GObject.
- ocharles 13y agoI spent some time writing Asteroids in netwire - a functional reactive programming library in Haskell - in my free time over a few evenings. I blogged about this at http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-netwire.html http://ocharles.org.uk/blog/posts/2013-08-18-asteroids-in-ne... - and I don't think it pretends to be OO. It was a radically different style, and I left feeling fairly convinced that FRP is a fantastic model for realtime interactions
- seanmcdirmid 13y agoFRP is great until you need to be interactive or switch over collections, then it becomes quite ugly. It can work for small games, like the ones in Courtney's dissertation. But over that? Not until a complete physics engine can be joined with a FRP library.
- quim05 13y agoI hate class-based programming too, but this article is poorly-reasoned, dogmatic bullsh1t.
- swah 13y agoRelevant recent tweet by the creator of the Io Language, Steve Dekorte: https://twitter.com/stevedekorte/status/411045428361056256 https://twitter.com/stevedekorte/status/411045428361056256 I suppose most folks here disagree?
- rurban 13y agoOf course I agree with Dekorte. Having written compilers written in perl, C and LISP - the ones in perl in pure OO, and the ones in C and LISP without, I conclude that I rather add classes and methods to my compilers than trying to improve it without. In the one written in C, classes are supported by the intermediate VM though (dynamically typed, very similar to Io), which is still better than having to write it in horrible C++.
- pbsd 13y ago> You may even have to inherit a base class or implement an interface. Subtype polymorphism is a very poor substitute for closures. This is why C++ algorithm library is unusable. Does anybody understand what the author means by this? STL's algorithm library does not use class hierarchies for anything. And they often take functions (be they free functions, lambdas, or functors) as arguments.
- nly 13y agoThe author probably had (this was written 3 years ago) a bitter and rather narrow view of OOP capable languages. In C++ a class is just a facility of the language with many different features. If you want immutable, value-semantic objects, then do it. If you want a closure... well objects can be closures too. C++ calls them functors, they can be immutable. In fact, C++11 lambdas are immutable by default. His criticism of the STL is probably that they expose their mutation, rather than hiding it in the architecture like pure functional languages. In C++ you just have to hide the infrastructure yourself.
- humanrebar 13y agoThe overhead that is assumed unimportant by most functional languages (copying is cheap, GC is fine, etc.) is intolerable in key situations and problem domains. In C++ all overhead must be optional. That being said, nearly all C++ applications can benefit from immutable classes, algorithms that take closures, and so on. But C++, like C before it, is really just an abstraction of the hardware and OS below it. That hardware mutates. That pool of memory changes size and locality. The closer your problem domain is to the metal (especially drivers and highly-optimized code), the more you appreciate mutable state, at least given the current state of computing.
- pkolaczk 13y agoDealing with complex immutable data structures without GC is either extremely hard or inefficient (and usually both). C++ standard library does not offer any helping hand here either. Additionally C++ logical memory model (flat, uniform memory) does not describe the hardware memory model well - it is already an abstraction. An memory access isn't uniform and mutations can cost you really very much. In some cases immutable structures + little copying is often the way to go, especially when we aim at parallelization.
- draegtun 13y agoAlso see: The problem with OOL is not the OO by Carl Sassenrath (from 2009) - http://www.rebol.com/article/0425.html http://www.rebol.com/article/0425.html PS. Just submitted to HN - https://news.ycombinator.com/item?id=6900426 https://news.ycombinator.com/item?id=6900426
- xcthulhu 13y agoOkay, for one: 1. Dynamically Typed Languages (LISP, Erlang, Smalltalk, Python, Ruby, and Javascript) are all easier than Haskell, JAVA, C++ or any other typed language for working with ADTs. Whether the language is OO or not isn't really relevant. On the other hand, you loose type-safety/efficient representations. But life is filled with choices, different tools are good for different things at different times. 2. You can have closures in a class based language. Here's some rather exotic Python code that uses both for measuring the performance of iterators: https://github.com/wearpants/measure_it/blob/master/measure_it/__init__.py https://github.com/wearpants/measure_it/blob/master/measure_... Smalltalk and Scala also have closures. It's not an either/or for classes vs. closures in programming language land. 3. There's more to concurrency than shared memory, so immutability is again a weapon that is good for some battles. If you have an app which you've factored into workers, unless they are on the same machine they'll need to communicate. Having your data be serializable is more important than having things be immutable in this context. What a worker does with data while it is handling it can involve lots of mutation. So everyone should take a big breath, and remember that there's no one way to think about software and there's no universal rules, other than probably P != NP and stuff like that.
- platz 13y agoAt this point, it's probably easier to name the languages that don't have closures as opposed to those that do
- EdwardDiego 13y agoJava's anonymous classes can also act as a (large and bulky) closure, although as you have to declare local variables used by the anonymous class as final, the capacity to close over mutable state is limited to instance fields or mutable objects.
- alkonaut 13y agoI agree, mostly, with the conclusions. "Classes" as a method of code re-use is dead. However, his conclusion that ML would dominate C# and Java as a language, I highly contest. The most important thing in my opinion is tools and platform support. Show me a fast, good looking IDE with good autocomplete/intellisense/integrated debugger and UI tools for ML. See? Is there an abundance of libraries and api wrappers available (that doesn't require you to do straight C-interop)? See? Also: the design of a language should be done with the tools in mind. While there is not much difference between norm(vec) and vec.norm() the latter is the form that supports autocomplete. So even for functional languages, being able to use member properties and member functions is an absolute reqirement to support the tooling that we expect. You could say that F# dominates C#. It has almost the same tool and library support, while having the features you expect from an ML type language.
- MichaelGG 13y agoIf your functions are inside a module you import, you can still navigate them by browsing autocomplete using the module name as an unnecesary qualifier. Then once you find/remember, delete the qualifier in cleanup. No need to force members just for discoverability. (Not to mention that tools could provide other ways of doing autocomplete.)
- likeclockwork 13y agoI'm noticing that whenever there is talk about any language that isn't Java or a CLR language several someones pop up to go on about the tooling "we" expect. The difference between norm vec and vec.norm() is that the function can be used in a higher order function while the method would require wrapping it in a lambda to achieve the same thing and would probably still break your tool's ability to autocomplete if you used it that way. You're basically insisting that an FP language needs to include an embedded OO language to be usable.
- al2o3cr 13y ago"The obvious conclusion is that ML simply dominates Java (and C#) as a language. Time to switch." The obvious conclusion is that any statement that contains the phrase "the obvious conclusion is" is 100% BS, including this one.
- deleted 13y ago[deleted]
- mtdewcmu 13y agoA language can't suck just because it isn't Haskell or ML.
- matjazmuhic 13y agoIt's funny how people blame the language when they are the ones who made a mess. :) On the other hand, there are languages that make it easier for you to screw it up and the ones that try to prevent that. But there's no bullet proof language.
- mtdewcmu 13y agoA bug-proof language is like an uncrashable car.