Rich Hickey rants about HttpServletRequest in 1080p: Death By Specificity from Clojure Made Simple

Rich Hickey "thinks in lisp". For example, he talks about his "maps" data structure (aka association lists). See [this video] Since data and programs are the same thing in lisp you can fluidly shift from one to the other, like I did with "knowledge" vs "rules". They both have the same representation (defstructs) but they are also code and have execution semantics. Clojure allows you to do this with map objects. The fact that you can use the whole language on everything at any time and that everything at any time is also "the language" is how you "think in lisp". Nobody thinks of Python programs as "data" or data as Python programs. Watch anything Rich Hickey talks about. He really "gets it".

A classic rant by Rich Hickey: [this video] I say this even though I don’t usually code this way: I think the big benefit for business code is sort of a constrained flexibility. Objects tend to get really big (the alternative is you have a ton of classes). Think about all the data that makes up one Uber ride. So if I want to do anything with a Ride, I need everything. An even the many classes thing doesn’t really solve that because maybe what I want is cross-cutting. So either way, I just end up having to supply a bunch of stuff I don’t need. The maps-first approach is more incremental. Every function takes what it needs and gives what it can.

Not who you are responding to, but the common idea that static types are all win and no cost has become very popular these days, but isn't true, it's just that the benefits of static typing are immediately apparent and obvious, but their costs are more diffuse and less obvious. I thought this was a pretty good write up on the subject that gets at a few of the benefits [link] Just to name some of the costs of static types briefly: * they are very blunt -- they will forbid many perfectly valid programs just on the basis that you haven't fit your program into the type system's view of how to encode invariants. So in a static typing language you are always to greater or lesser extent modifying your code away from how you could have naturally expressed the functionality towards helping the compiler understand it. * Sometimes this is not such a big change from how you'd otherwise write, but other times the challenge of writing some code could be virtually completely in the problem of how to express your invariants within the type system, and it becomes an obsession/game. I've seen this run rampant in the Scala world where the complexity of code reaches the level of satire. * Everything you encode via static types is something that you would actually have to change your code to allow it to change. Maybe this seems obvious, but it has big implications against how coupled and fragile your code is. Consider in Scala you're parsing a document into a static type like. case class Record(

Author is on the verge of having a Clojure epiphany. > 1. You should often be using different objects in different contexts. This is because "data" are just "facts" that your application has observed. Different facts are relevant in different circumstances. The User class in my application may be very similar to the User class in your application, they may even have identical "login" implementations, but neither captures the "essence" of a "User", because the set of facts one could observe about Users is unbounded, and combinatorially explosive. This holds for subsets of facts as well. Maybe our login method only cares about a User's email address and password, but to support all the other stuff in our app, we have to either: 1. Pass along every piece of data and behavior the entire app specifies 2. Create another data object that captures only the facts that login cares about (e.g. a LoginPayload object, or a LoginUser object, Credential object, etc.) Option 1 is a nightmare because refactoring requires taking into consideration ALL usages of the object, regardless of whether or not the changes are relevant to the caller. Option 2 sucks because your Object hierarchy is combinatorial on the number of distinct _callers_. That's why it is so hard to refactor large systems programmed in this style. > 3. The classes get huge and painful. The author observed the combinatorial explosion of facts! If you have a rich information landscape that is relevant to your application, you are