Do people actually build large codebases with the 'hash map first' approach? It works for scripts but I always find it very difficult to follow code that transforms a bag of stuff into another bag of stuff.
> Do people actually build large codebases with the 'hash map first' approach?
There are a few large projects written in Clojure. I'd say it's a "data first" approach, not uniquely "map first".
There's this famous 4 minutes rant by Rich Hickey (the creator of Clojure) where he talks about maps and about how Java does OOP (and how maps are served through getters but you can't see easily that they're maps), it's golden:
I totally agree that the getter/setter scourge in Java is terrible but better languages like Scala or Python allow you to access fields with simple dot syntax and still inject getter/setter code.
My point was that without having a schema (which is essentially what a case class or ADT is) it makes to very hard to understand what objects are being passed around.
I think every Java (or C# or PHP ...) programmer should be made to watch this video every day before breakfast. Then and only then will software change.
I've written a cryptocurrency trading bot in clojure that uses this approach very heavily. I typically send around a context variable (containing the database connection, logger, correlation-id and other ancillary stuff) as well as maps specific to the task I'm performing (orders, market data, etc).
I heavily use destructuring so that functions access the bits they care about, threading macros like (-> stuff (assoc :foo x) ...) and spec to make sure the maps have the structure and keys I expect and rely on non-existent keys returning nil by default. I also use the sequence functions heavily. Mapping, filtering and reducing over vectors of maps, group-by if I need them grouped and so on.
I personally find it to be a very pleasant way to program.
Bigger code bases tend to use ways of imposing more structure while still using maps, like use of schemas (see malli & spec), standard patterns of passing down subtrees of the app's nested maps, using map destructuring in argument lists, etc.
Also good design and timely refactoring of said data structures to keep your functions from having to reach far into data.
You also decide what part of your tree should live in a database, supported by a query language. You can use SQL-based thins or Datomic and the many open source implementations of the same model. In the latter case it feels more like a "turtles all the way down" kind of thing.
