Skip to content
0:00 / 0:00

#narcissisticdesign#clojure#softwaredesign

Stuart Halloway - Narcissistic Design

Reaktor

1.3K subscribers • 1 video on Hallway

YouTube
  • Recommended by 5 people: 4 on Hacker News and 1 curated list.
  • Presented by Stuart Halloway
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

28K views9 years ago5 recommendations

Software designTools and practiceDesign patternsSoftware architectureSimplicity and complexity

Stuart Halloway uses satire to catalog software design anti-patterns that introduce accidental complexity while appearing to follow industry best practices.

The software industry changes rapidly, but you can protect yourself from these changes by creating code that is complicated enough that only you can maintain it. Of course you should not engage in obvious bad practices. The good news is that you don't have to. You can follow idiomatic industry practice and stay buzzword compliant with the latest trends, while quietly spreading complexity throughout systems. Better yet, the symptoms will show up not in your own code, but in other code that uses your code, directly or indirectly. You will be a hero as you lead larger and larger teams burning the midnight oil to keep systems alive. Practice these principles, and your code will have an infectious complexity that guarantees you will always be needed to maintain it. Use OO, and don't forget those setter methods! Prefer APIs over data. Start with DSLs. Always connect (and never enqueue). Create abstractions for information. Use static typing across subsystem boundaries. Put language semantics on the wire. Write lots of unit tests. Leverage context. Update information in place. Stuart Halloway is a founder and President of Relevance. He is a Clojure committer, and a developer of the Datomic database. Stuart has spoken at a variety of industry events, including StrangeLoop, Clojure/conj, EuroClojure, ClojureWest, SpeakerConf, QCon, GOTO, OSCON, RailsConf, RubyConf, JavaOne, and NFJS. Stuart has written a number of books and technical articles. Of these, he is most proud of Programming Clojure. Seen at Reaktor Dev Day 2013 reaktordevday.fi blog.reaktordevday.fi

Why it's here

5 people recommend this

What people say. Highly recommended as a humorous yet insightful critique of over-engineering, DSLs, and common software design pitfalls.

Moments people linked to

ajsson Hacker News • Recommends

On “How to Write Unmaintainable Code (2017)”

Along a similar line, I love Stuart Halloway's talk on Narcissistic Design - link to this video Prefer APIs over data. Start with DSLs. Always connect (and never enqueue). Create abstractions for information. Use static typing across subsystem boundaries. Put language semantics on the wire. Write lots of unit tests. Leverage context. Update information in place.

smnplkon Hacker News • Recommends

On “The faster you unlearn OOP, the better for you and your software”

Reading some of the comments here reminded me of a great talk by Stuart Halloway called Narcissistic Design.1 1 link to this video

programming-talkscurated list on GitHubRecommends

Under “System Architecture”

Narcissistic Design 00:37:14 by **Stuart Halloway** (2013)

echlebekon Hacker News • Recommends

On “I don't want to learn your query language (2018)”

Nobody seems to have posted Stuart Halloway's Narcissistic Design yet, so I'll just leave this here. link to this video Has some great insights and quips. "Nothing says 'screw you' like a DSL"

blacktriangleon Hacker News • Recommends

On “SQLBolt – Interactive lessons and exercises to learn SQL”

link to this video This talk goes into many anti-patterns, but he gets to the real problem with SQL, that it is ONLY a DSL and lacks either an API or a fundamental information model to program against. Composability when working with a DSL is a nightmare. I also have been moving away from ORM to directly writing SQL, but lets be honest about the reasons that programmers are wary of working directly with SQL as they are legitimate issues.

u/vvvvalvalvalin r/Clojure • Mentions

On “top 10 words to help you learn Clojure – Stu Halloway”

I think the whole point of this quote is to drive people to research these concepts, so it's no surprise that their meaning is not immediately obvious. Let me offer a few leads: * **situated programs:** explained by Rich in his keynote Effective Programs. The typical web app is a situated program. Oppose that to programs that run standalone and / or on a one-off basis, e.g compilers or scripts. * **egal:** Clojure's equality semantics, allowing for sound equality of composite structures. See the paper Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same. In layman terms, 2 objects are egal if they are either egal immutable scalars, immutable collectio…
16View on Reddit

u/vvvvalvalvalin r/Clojure • Mentions

On “What are the best resources for learning how to design good libraries?”

I think this talk by Stuart Halloway gives you a good checklist: Narcissistic Design I find Zach Tellman's libraries to be very tasteful in their designs. However, be ready to accept that in the JS world, the "right" choice will often be the unpopular one! In the sense that a 'visually pleasing' API will often be more popular than a robust one (example: GraphQL being based on text instead of data).

u/dsrptrin r/Clojure • Mentions

On “What are the best resources for learning how to design good libraries?”

ha ha sorry :) , I replied to the wrong comment. I was referring to the one on \`Narcissistic Design\` in the comments below.

u/slifinin r/Clojure • Mentions

On “Error Handling Macro - Opinions/Alternatives Welcome”

> In other languages I would use an early return to stop all my processing and return an error then something fails The default error handling method in Clojure is exceptions if you threw an exception you get an early return and the ability to catch it and report the error to the user I would advise making the default error handler very general and relying on it most of the time, this is touched on here: link to this video I would not raise the complexity beyond that unless you need proactive recovery systems in which case look into condition systems