Programmers spend enormous mental energy making their code DRY — Don’t Repeat Yourself. …

Instead of forcing programmers to DRY up their code preemptively — collapsing it into parameterized abstractions before they even understand the variation — what if we used LLMs after the fact, as consistency checkers?

DRY is Overrated https://open.substack.com/pub/programmingsimplicity/p/dry-is-overrated?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Interesting tidbit about Lisp at the end. I never had a chance to learn Lisp. Definitely want to do it at some point.

Relevant thread from 2018: https://akkartik.name/archives/foc/thinking-together/1539030605.000100.html I posted a bibliography of links there, but I've continued collecting more since. Here's the current list: • http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction • http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to • http://bravenewgeek.com/abstraction-considered-harmful • http://akkartik.name/post/modularity • http://dimitri-on-software-development.blogspot.de/2009/12/disadvantages-of-code-reuse.html • http://thereignn.ghost.io/on-dry-and-the-cost-of-wrongful-abstractions • https://www.tedinski.com/2018/08/07/what-makes-good-design.html • https://www.theregister.com/2019/08/16/dropbox_gives_up_on_sharing_c_code_between_ios_and_android • https://orbifold.xyz/dry-trade-off.html • https://merveilles.town/@akkartik/106950150053702439

Having followed the entire Evolution of a Haskell Programmer https://people.willamette.edu/~fruehr/haskell/evolution.html, I'm going to say that "Write code that is easy to delete, not easy to extend" resonates most.

Also, I hate to rain on someone singing about Lisp macros, but they require just as much taste to use well as functions. Nobody's reading the macroexpanded output of macros.

Agreed, the Gutenberg-inspired manifestation of Lisp macros is functional programming. Yet,,, there is something else hidden away in there. An “attitude” that I’m currently calling “write code that writes code”. Thinking about how to buff “code” is what I call “Production Engineering”, which is only 1/2 of the story. The other half is something like “designing the design”, which, unlike buffing code, is an iterative process instead of a waterfall process. Our current tools and workflow do not support heavy, fluid iteration (other than Continuous Delivery which implies that it’s OK to ship buggy designs and wait months/quarters/years to allow paying customers to give feedback on how to de-bug the design(s)). “Designing the design” used to be called “RAD”, but the concept got crushed under the boot-heels of premature-typing zealots. I think that writing designs that are easy to delete is more important than writing code that is easy to delete.

@guitarvydas For you is “writing code that writes code” an attitude that supports “designing the design” or is it more related to “buffing”?

@Benji Rappoport It can be used for both. I tend to (over?) favour the weakest link, so right now, I think in terms of just designing the design and making it possible to backtrack, erase what I’ve done and start over again without feeling a lot of friction. I used to use Lisp for such friction-less retreading, but t2t makes it even easier in my mind. I approach it with a ‘sed’ or

.replace(…)

attitude and I use multiple stages, so that I can focus on doing only one thing at a time. I once converted a big Pascal program to K&R C using VI and regex replacements only. I just kept nipping away at the file - eyeballing the partially transmogrified code and getting inspiration on what to replace next. I think of OhmJS as a super-regex (I mean to say ‘t2t’, which is OhmJS plus a tiny rewriter DSL that bolts onto OhmJS). As I see it, buffing code is already (overly?) well handled, so all I need to do is convert what I want to say into some already-existing language, then let it do all of the buffing and optimization. My recent foray into the guts of Forth Haiku shows that it does both - it produces mediocre code very, very easily, then rewrites it with an optimizer - it was all done in Javascript, so it can’t be all that hard 🙂. 2 lines of forth-like code produces 400 lines (iirc) of Javascript which then gets rewritten as GLSL and produces pretty pictures on my monitor. (I can point to my YouTubes that attempt to explain the first part (thus far)). aside: literally at this moment, I’m looking at a pipeline (10 ultra simple passes) that converts a really, really ugly lump of XML into 13 lines of less-ugly code. (The XML is a drawing saved out as graphML, the 13 lines is an intermediate form which I intend to convert to JSON and interpret/compile into running code).

@guitarvydas Thank you for the clear elaboration. I see how your approach gives you a lot of leverage. I am really enjoying your programming simplicity YouTube and Substack. Many thanks for all the content you share.

Another related link that I like quite a bit: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase