Clojure's Solutions to the Expression Problem
infoq.com156 points by adityaathalye 6 days ago
156 points by adityaathalye 6 days ago
I miss the days when productivity booster posts were all about REPL, functional programming, composability, immutability.
I just wish more people appreciated those things at all. What's the name of the rule where everyone with a sufficiently large codebase has a partially implemented, buggy time oriented data log somewhere and it's too bad people didn't realize that sooner. Datomic et all are so cool and solve so many interesting and pervasive problems but people would rather just mangle those bits themselves. The glory of refactoring a large, purely immutable piece of software is so glorious and easy. The wrapper/adapter hell that comes out of the Expression Problem is just one more thing that people just assume is unavoidable and the amount of gross code that falls out of that is so painful.
"Henderson's Tenth Law" :D
*But beware. Once you see, you cannot un-see the fact that…*
Any sufficiently complicated data system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a bitemporal database.
— Henderson's Tenth Law. (= henderson https://github.com/jarohen)
(edit: add links)
I enjoyed reading most of that.
One thing to watch out for with immutability is that if you're dealing with personal information about people, immutability is probably illegal. You must be able to forget information, and not just simulate you've forgotten it.
I don't how universal this is at the moment, but I think it's likely to be more universal in the future.
Thank you for the kind words, and feedback!
Yes, controlled excision is a (necessary) capability of all event-sourced systems and/or immutable object stores, i.e. it's quite universal already. All such systems have to build in some sort of special-case mechanism to excise facts, not merely redact (~tombstone) them.
But data-destruction superpower must be used sparingly, with care. See: git's documentation for --force-push, for example (and bemoan what popular git forges force us to do on a normal basis).
Back to DB-land...
Datomic does it this way: https://docs.datomic.com/operation/excision.html
Excision is the complete removal of a set of datoms matching a predicate. Excision should be a very infrequent operation and is designed to support the following two scenarios:
Removing data for privacy reasons
Removing data older than some domain-defined retention period
XTDB calls it ERASE: https://docs.xtdb.com/reference/main/sql/txs.html#_erase
Irrevocably erases documents from a table, for all valid-time, for all system-time.
While XTDB is immutable, in some cases it is legally necessary to irretrievably delete data (e.g. for a GDPR request). This operation removes data such that even queries as of a previous system-time no longer return the erased data.
Greenspun's tenth rule:
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. > -- Philip Greenspun,
> The wrapper/adapter hell that comes out of the Expression Problem
Yeah, I got lucky in my work (see sibling comment https://news.ycombinator.com/item?id=45207880).
For me, it was PageObjects all the way down, which "just composed".
Something like this:
(defprotocol IPageObject
"Each PageObject MUST implement the IPageObject protocol."
(page-object [this])
(exists? [this])
(visible? [this]))
(defrecord Checkbox [target-css]
IPageObject
(page-object [this]
this)
(exists? [this]
;; webdriver check if target-css exists
)
(visible? [this]
;; webdriver check if target-css is visible
)
Selectable
(select [this]
;; webdriver select the target
)
(deselect [this]
;; webdriver undo selection
)
(selected? [this]
;; webdriver return true if target selected
)
Value
(get-value [this]
;; webdriver return current selection state
(selected? this)))
Solid gold!
(edit: x-link to sibling comment)
This example just scratches the surface. I don't think it's showing any Clojure-magic per se, b/c in effect what you're showing is just "implementing an interface". You can do that in most languages.
The magic of protocol/records is that they work across library boundaries. A library may provide a record - and then you can extend the record with new protocols. Key is that it's all without needing to explicitly creating new agglomeration types.
You can take some Dog record from some pet-simulation library and then `extend-type` it with the IPageObject protocol and make the Dog record now something that can be displayed on a webpage
The magic of Clojure is that if a problem can be solved with an interface Clojure lets you solve it with an interface. It doesn't have any magic to show off, it is just a relentless implementation of a lot of basic good ideas.
???
I don't understand. Did you not read my comment?
I just explained how your seemlessly extend records across library boundaries. It's not just solving with interfaces
I don't agree with your characterisation of what the magic of protocols is. A protocol is the lightest possible thing that captures how two things can interface. That is magic in a way, but it is also the end of it, Clojure does a masterful job of keeping concepts tidy. In terms of what you can do with protocols, you can indeed do that in many languages. Clojure is pretty smooth but there is nothing stopping anyone implementing any interface on any object in most languages; build some sort of adapting whatever. It is rare enough in practice that the extra dev work isn't a major problem.
And as a bonus observation, any time your example of how to use a programming feature involves animals it is a fake use case. It is a bad sign because it suggests that the benefit doesn't have a real world use.
Mmm, I don't think what you're saying is true?
I'll be honest I haven't touched Java in a long time, and I'm haven't had to extend my Clojure code this much before (but it's nice to know that I can - and use protocols with confidence)
Say LibraryA has some record..
LibraryB and LibraryC `extend-type` the record and implement additional functionality by implementing protocols..
Now you want to us both libraries in your application and use this record with both extensions. In Java this is forbidden due to diamond dependencies restrictions.
You can use multiple protocols in Java, but you can't have the protocols implemented (there are default methods but they don't have access to the Record's state)
Is there some way around this..? As far as I understand there isn't.
Furthermore, all the extensions need wrappers and need names. Nobody is doing this b/c you'd go nuts. But in Clojure it'd be a natural way to extend a library.
For instance
(defprotocol MyProtocol
(foo [x]))
(extend-type clojure.lang.PersistentVector
MyProtocol
(foo [x] (str "Vector of size " (count x))))
(extend-type clojure.lang.PersistentList
MyProtocol
(foo [x] (str "List of size " (count x))))
I can't claim to know much of anything about Java. But this sounds like it might be linked to Java's type system and Clojure is an untyped language. From what I know of typed languages I don't see how a Clojure style interface could be implemented in a typed language or why someone would want to do that if they have chosen a typed language. So I don't understand the point and I don't know Java.
I'm fairly confident that Java is technically capable of doing anything Clojure can since in the extreme case someone could implement a Clojure library callable from Java. In a similar way to how the Python community claims to do machine learning despite all critical code actually being in C++.