3 ms·
Learning Lisp gave me perspective on the other computer programming languages that I worked with. Having done a few major projects with Clojure gave me some pra
by lkrubner 5y ago
Learning Lisp gave me perspective on the other computer programming languages that I worked with. Having done a few major projects with Clojure gave me some practical sense of what the advantages might be, especially when combined with Java's broad ecosystem. Above all, it gave me distance from the cult of Object Oriented Programming. It's important to have some perspective about the dominant paradigms of programming. It was only when I had that perspective that I ended up writing what became my most popular essay, "Object Oriented Programming Is An Expensive Disaster Which Must End":
http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr...
- mumblemumble 5y agoThat's an interesting position to share in the context of a discussion about Racket, since Racket embraces object-oriented programming. It's not purely OO, of course, but quite a few core libraries rely on its OOP features.
- neilv 5y agoThat might be for historical reasons. (IIRC, mostly, OO was the GUI libraries, and what's layered directly on top of those.) OO is no longer as en vogue, in either Racket or the broader field. In Racket, you'll see a lot of code using `struct`, and without traditional gratuitous use of object classes for everything. https://docs.racket-lang.org/guide/define-struct.html https://docs.racket-lang.org/guide/define-struct.html > New datatypes are normally created with the struct form, which is the topic of this chapter. The class-based object system, which we defer to Classes and Objects, offers an alternate mechanism for creating new datatypes, but even classes and objects are implemented in terms of structure types.
- mumblemumble 5y ago> traditional gratuitous use of object classes for everything This sort of phrasing is sort of distressingly characteristic of contemporary discussions about object-oriented programming. I can understand where it comes from - if you look through my comment history, you'll probably find plenty of examples of me running my mouth about Java or the overuse of OOP in Python - but I assure you there is a baby in all of that bathwater, and it doesn't need to be thrown out. That baby is dynamic dispatch, and it does let you do some things that can be a hassle without it. Unfortunately, it tends to be poorly taught or poorly understood nowadays. This is not a "no true Scotsman" argument. I'm not saying no true hammer would be used to drive screws. I'm just observing that, if a carpenter was never taught about screwdrivers, it's no surprise they'll develop a lot of pent-up frustration about hammers, and perhaps even be a bit confused about what they're really for. It seemed to me that one of the core sections of the essay ikrubner linked above rested on a conflation of dynamic dispatch and dynamic typing. Which is a worrisome thing I've seen many people do. It's no wonder we don't use OOP well, living in an intellectual environment where its only truly distinguishing characteristic rarely even makes it into lists of its key features. So, perhaps it's even worse than just having only been given a hammer. We were only given a hammer, and were also never taught about nails. Anyway, enough complaining. Let's take Racket's image drawing library as a positive example. It's implemented around an object-oriented interface. What this does is lets you write code against that interface, so that it is able to output graphics to any format that has a suitable implementation of that interface, without needing any special glue code or explicit branching logic to make it happen. I would argue that this is quite useful. As a contrasting example, Haskell's typeclasses are superficially quite similar, but, since they use static dispatch, adding a new output format does tend to require some glue code - not much, but still more than zero - that's specific to each drawing routine you want to hook up to that new format. There's a nice essay, https://www.sicpers.info/2018/03/why-inheritance-never-made-any-sense/ https://www.sicpers.info/2018/03/why-inheritance-never-made-... , that serves as an excellent excoriation of the C++/Java/etc lineage of OOP. But one key thing needed to contextualize it is that OOP mechanisms like Racket's or CLOS aren't trying to do OOP in the same way that Java does, and therefore don't run afoul of the same shortcomings. In particular, they're not trying to turn it into a single golden hammer that solves all abstraction problems. Racket gets a lot more mileage out of its module mechanism, for example.
- samth 5y agoThat's my usual assessment, but today at RacketCon Ryan Culpeper gave a strong case for using OO more in Racket, with a demonstration of his point in his new http client library.
- simongray 5y agoLove that essay. I read it right around the time I learned Clojure myself.