Fork me on GitHub

I started to read A Philosophy of Software Design and watched a few talks of Ousterhout. So far I think there are some sound ideas in there that are worth thinking more deeply about and exploring. But there also seems some “bigger” idea hinted at, when we compare the contradicting notions of deep modules (classes) with what the likes of Martin and Fowler are suggesting in Refactoring and Clean Code, which is breaking code into pieces. From what I know this goes back to the idea of layering abstractions, which is for example explored in SICP. In pragmatic terms you likely always want both, a layer that solves the problem in terms of your user’s semantics (deep modules) and a layer that solves the problem of solving the problem in your semantics through composition of flexible submodules. And this actually works. In a recent project I first tried make the tool that can make the tool that solves the problem of my client, then as requirements got discovered, I was often (not always, I made mistakes too) much quicker and more confident in accommodating them. I guess sometimes there are more than two layers (i work alone and in small teams on small to medium custom stuff). But I feel like this is a decent heuristic so far.

👍 2

In Elements of Clojure we have the idea of principled components and adaptive systems. This relates to the deep modules idea. I don’t remember if it discusses the composition of components themselves, but that is an inherently layered exercise too, or rather recursive. In Simple Made Easy Hickey talks about disentanglement and breaking things apart. I also remember him saying something along those lines: “design is breaking things apart and putting them together again” (maybe in relation to spec2?). Again, a related concept that we very much appreciate. One example where this way of thinking becomes useful is in investigating the concept of data hiding. At first glance it seems to be fruitful: A model (class, module or what ever) hides data so the interface has simpler semantics. But if we apply the concept in this talk, then data hiding is complecting data with complexity itself. What we actually want to hide is not the data, but the complexity of an operation. Now I have all kinds of half baked understandings of what abstraction and modularisation is. I feel like I’m making progress in learning but I’m also kind of confused.

👍 2

Modules ought to hide a hard design decision from the rest of the modules... that's a great rule of thumb.

👍 2

It’s really hard though. In the book A Philosophy of Software Design it is mentioned that the first attempt usually doesn’t work well. I very much resonate with this. And it’s not even like I can cheat it. Because when I don’t actually tryhard the first attempt and deliberately write a prototype, then that often doesn’t „count“.


I try to go as far as I can without modules. Usually I go very far, some might say too far. But I enjoy having all the code in one file. I think modularizing code makes sense for reusable components, but that's basically the same as saying "this ought to be a library."

👍 3

Btw, that's Guy Steele doing the QA session with Rich in the HOPL IV video right?


And a question from Richard Gabriel... THE Richard Gabriel? wow :)

Alex Miller (Clojure team)21:07:45

would have been an epic in-person conference :)


who is richard gabriel? Google is telling me a supreme court of colorado justice?


My master's thesis starts with a quote by Richard P. Gabriel: > Art, engineering and science are - in that order - part of a continuum of finding truth in the world and about ourselves – Richard P. Gabriel

Alex Miller (Clojure team)21:07:48

he did a keynote at Clojure/west 2012 btw. eventually I'll get around to re-editing and releasing that one :)


thanks, I'm going add that one to the top of my queue


"Worse is better..." interesting