"Simple Made Easy" - Rich Hickey (2011)

If you haven't heard of Rich Hickey, then you're fortunate to have the opportunity to watch "Simple Made Easy" for the first time: ▶ this video

This doesn't sound like a simple solution from your fellow devs. It appears to have been an easy solution. If the distinction isn't familiar to you, there is a great talk of Rich Hickey [0], that explains that distinction and some more. The talk is definitely not only applicable to Clojure. YAGNI is a great slogan, but must not be a dogma. If you already know, that you are going to need custom rules. Then prepare for it. But, if --- for example --- the current rules are almost trivial, and you don't know yet, which rule engine will be the right fit later on. Then it might be a good idea to postpone the decision about the rule engine, until you know more. In the meantime a hard-coded solution could be enough. [0]: ▶ this video

Actually Rick Hickey's talk ( ▶ this video ) is amazing because he talks about your case by going back to the original meaining of words: ,,Complex comes from the Latin complecti, which means “to entwine around, to embrace'' Simplicity requires layering, so in your examples the main requirement for simplicity is about how intertwined your hobby project is with the transciever code or ethernet code. As long as the abstraction layer works well for you without getting too much into the details of the implementation, it's a simple solution. Of course it's not a clear answer whether you should do things yourself or use a third-party, but if the third-party works perfectly for use case without significant tradeoff in your system, of course it's better to use it.

I highly recommend Rich Hickey's "Simple Made Easy" talk as a way to think about software complexity. We all know that complex systems are hard to work with, but I've found his presentation very useful in understanding the nature of complexity. Understanding complexity helps being able to avoid or minimize it. For example, easy is not the same as simple, and simple changes to one part of a system can introduce great complexity at the macro level. ▶ this video

Simple Made Easy ( ▶ this video ) The Language of the System ( link ) The Value of Values ( link ) All by Rich Hickey (Clojure creator) - strongest programming speaker I've found to date.

Great point about testing. The knee jerk reaction to defend this enormous rewrite because it passes a test suite reminds me of a Rick Hickey classic: what’s true of every bug found in the field? It passed all the tests. ▶ this video

> Claude can make decisions about architecture but they are often not very good decisions, and sometimes absolutely terrible I have to kick it back onto the right track, but as you sort of point out, I got that experience from making my own terrible decisions and finding out the hard way the blind alley I was walking up. Second system, inner platform, too general, planning for scenarios that never happen, stuff that doesn't scale - I've made them all. I think I learned as much from reading as doing though, I could later put names on the mistakes I made. So, for what it's worth - study the meta. Read about architectural theory, system design Study the craft and listen to the masters - ▶ this video And when you talk to Claude say "follow rich hickeys advice about explicit rules" and it knows what you mean more than you do !

take it up with Rich Hickey I suppose :) If you've never watched Simple Made Easy I really recommend it: ▶ this video

Rich Hickey's talks "Simple Made Easy" [1] and "Effective Programs" [2] provide a better explanation of these ideas IMO. The specific definition of "simple" is pretty crucial. [1] ▶ this video [2] link

> I'm sadly not very well versed with this alternative to OOP. But something tells me that a more "basic" and less dynamic scheme like that is probably best for performance reasons, since you'd either need a Julia-like JIT or a granular "dynamism knob" like link to truly amortize the cost of CLOS-like dispatch and polymorphism; though magic can be done, as the "Fast generic dispatch for Common Lisp" paper shows. You know, for someone who isn't "well versed" with it, you certainly nailed exactly why I chose it. Also, simplicity. The "as easy as Python" is only possible if I remove complecting [1] things like inheritance. > Huh! If this includes types deduced by compiler inference and not just user declarations (since Yao seems gradually typed, to my eyes), that'd be pretty impressive. It does, actually. But Yao is not gradually typed, unfortunately. Too complecting. [1]: ▶ this video

I believe GP is using it in the literal etymologically correct way in the vein of Rich Hickey: ▶ this video Pedantically, Common Lisp being a Lisp-2 vs a Lisp-1 arguably makes it a duplex vs a simplex…

I second this, as personally I believe that async is an anti-pattern. It's an unfortunate result of the programming world choosing easy over simple so it could recruit vast armies of inexperienced programmers for profit: "Simple Made Easy" by Rich Hickey: ▶ this video I'm old school, I want the runtime to do as much work for me as possible so I don't have to. Basically that looks like the runtime providing things like process isolation and concurrency, even if the underlying hardware can't do that. Especially if we're using a high-level scripting language like Javascript anyway. Rust I could maybe see at least providing access to async functionality, but I'd vote specifically against that footgun and go with lightweight threads and message passing (how Go does it) or scatter-gather arrays (there may be a better term for this) with the compiler detecting side effects and auto-parallizing everything else like loops. The simplest way to facilitate that is to use immutable data as much as possible, passed via copy-on-write (the Unix way). The idea of async being scattered around operating systems and kernels and such is anathema to my psyche. Code smells setting off my spidey sense everywhere I look. To the point where if the world goes that route, I just don't think we'll have determinism anymore. That makes me want to get out of programming. Note that I feel the same dismay about stuff like the DSP approach used by video cards, where the developer has to manually manage vertex buffe