Hacker News Reader

Comment by cc_ashby | Hacker News Reader

[redacted] are my favorite people on complexity. [redacted] was notably my professor for operating systems @ [redacted]. He taught not just ways to design software, but also ways to live.

[redacted]’s work is also directly influenced by [redacted], as referenced at the end of his article.

For [redacted], I suggest looking at the class website: [redacted]

For [redacted], I suggest his book, [redacted]

View on HN

I'm a fan of Ousterhout's writing; "A philosophy of software design" clarified a lot of my thinking around complexity.

I find the "Grug Brain" stuff pretentious and dishonest. "Me not smart. Me like simple things. Me not believe in hype. Hence why me invent complex new frontend framework, and then me hype it up beyond reason."

(To be clear what I'm saying, my point is not that HTMX is overhyped -- it might be, but then so is everything. It's specifically the hypocrisy of the "we're against hypes" hype that makes me cringe.)

I feel the exact same about grug. I don't think people actually agree on what's simple, so it's pretentious to pretend your "simple" is the obvious one that a caveman would agree with.

Grug has some good points about complexity, but proceeds to take it all the way to full-blown, self-defeating anti-intellectual and anti-professional attitude. It makes sense for imaginary cavemen, but not for practitioners of a profession - people both capable and expected to learn the tools of their craft and continue learning past their first job interview.

ironically, i teach at a university

agree that anti-intellectualism is a danger if you take grugbrainism too far

Do you think this would be beneficial for a somewhat perplexed CTO of a newly seed-funded startup? Or would it be wiser for me to concentrate on my current responsibilities and return to this book when my mind is clearer? I'm feeling a bit overwhelmed and under pressure, and I'm concerned that reading this book might add to the chaos. I would appreciate your input.

APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less.

It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.

Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers.

Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.)

I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps.

I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.

> He taught not just ways to design software, but also ways to live.

Mind sharing his insights on ways to live?

Not parent commenter, but I recall seeing this talk of his posted online before: https://gist.github.com/gtallen1187/27a585fcf36d6e657db2

Rich Hickey is the odd one out. What do you see in someone who shuns static typing? Static typing is the clearest way to reduce complexity.

static typing is a way to manage complexity, Rich Hickey is about avoiding complexity

But there's no way to completely avoid complexity.

So tools to manage complexity are welcome in my toolbox.

Tools have their defined use cases. If you use the same tool in all cases, you’re probably misusing it.

Reply on news.ycombinator.com