further debate between #Muratori and #Uncle-Bob about #Clean-Code, elaborating an OS I/O device example in a very illuminating way
on 02026-04-10discussion between #Muratori and #Uncle-Bob about #Clean-Code, significantly but not completely focused on #performance, discussing Muratori’s video criticizing it.
on 02026-04-10#Muratori harshly criticizing #Uncle-Bob’s version of #clean-code as a “debacle”, and "gingerBill", the guy who wrote #Odin, reviewed his criticism, adding criticism of his own. gingerBill’s video commentary is mostly just low-content snarky innuendo.
Many commenters agree with Muratori: “I would not recommend Clean Code even to beginners, it’s an awful book. Here is the thing: if you just skim it and read the headlines then any sane person would agree. But if you just want to skim it, then you are not the target audience of CC. The issue is when it comes to actually implementing the suggestions. Martin’s examples make the code even worse than it was before.”
on 02026-04-10#video of four hours of #Blow on #IMGUI. He’s programming in #Jai and struggling to understand why his UI isn’t doing the right thing. I think this video might be from 02021, halfway through his Sokoban game. In watching frame by frame, I notice that he has one (or sometimes two) frames of lag before initiating mouseover effects (tweened animated fades to brighter colors, etc.) on his IMGUI widgets. (Some of them “breathe” at about 1Hz when the cursor is over them.) Also a frame or two of lag is visible with the mouse pointer when he’s dragging windows. He sure spends a lot of time restarting his game; it takes 8 seconds from recompile initiation to seeing the cutscene, and then by default it plays for a few seconds, though it can be cut short to a single second. if ui.begin(panel, resizable=false) { ... defer { ui.place_rect(0, outer_margin); ui_end(); } ... ui.radio_button(*debug_mode, .Lightmap, *theme); ... ui.separator(); ui.label("Paint color", w=100); ui.same_line(); ui.color_edit(*paint_color, linear=false); ... if ui.button("Swap colors") { Swap(*paint_color, *clear_color); } ... ui.separator(); ui.checkbox("Airbursh", *airbrush); It seems like his .separator() is a small amount of vertical space. For tooltips, ui.hint("Radius of the brush - Wheel"); ui.input_float(*radius, w=64); ui.same_line(); ui.label("Radius");. There are ui.indent(); ... ui.unindent(); pairs for some visual hierarchy, but the indents are very subtle indeed. There’s a ui.enable(bool) for graying buttons out until a ui.enable(true);. The video shows how useful it can be to have video recordings of GUI interaction for debugging; at 43'33” a bug misinterprets a mouse movement dragging a window as also moving a slider, which mystifies Blow, and at 43'57” he erroneously speculates, “Must’ve accidentally dragged that, real fast?” At 45'16” he’s looking at another bug where a “clear” button isn’t being clipped properly and is overdrawing an accordion-control button in its parent. He gets into the implementation arount 54'44”. His definition of “em” is wrong by a factor of 2. He sure spends a lot of time manually doing small table layouts that a sort of elastic tabstops would solve for him. The implementation figures out when to pop up “hints” (tooltips) with rect := place_rect(w, h); over := is_over(rect); update_hint(over); and detects clicks with over && (ui.mouse_button_left_state & .START), and I think place_rect handles moving you to the next line and widening the current line. It’s interesting to hear him using Tk terminology like “entry” for “text field” in 02021. The RGBA color picker is interesting; I thought maybe you dragged up or down from R, G, B, and A buttons to adjust the respective color components, which changes the colors of the buttons to the corresponding primary shade, but in fact they’re just “checkbuttons” that change color when you click them. I like text_height, text_width := text_size(text);. Fading out a border around the window to α = 0 gives a nice cheap fuzzy-drop-shadow-like effect. I feel like for indentation some kind of current-drawing-origin stack might be a good complement to the clipping stack (“scissor stack”, maybe nomenclature borrowed from glScissor). He spends a lot of time debugging problems induced by how Jai’s static type system doesn’t have an Option type for optional parameter defaults. His defensiveness is grating: “The last thing I need is for someone who’s been programming for 5 years to tell me what I do and don’t know.” He’s hashing the addresses of callsites (plus an optional integer for loops) to get unique widget IDs for the IMGUI library. Casey #Muratori pops on at 2'56”, explaining that nowadays he streams his IMGUI drawing commands into a command buffer, sort of like ocornut’s dear-imgui, but higher level so he can run layout algorithms over it afterwards. “The reason I like the command buffer approach is because I like to be able to have more logic in the layout stuff.” Muratori’s definition: “IMGUI just means that you don’t call Create and Destroy on widgets. It means that there’s no need for you, the user, to like record what they are. (...) The core problem that you're trying to solve, and the one that determines whether I call it an IMGUI or not, is, can you just run some code on your side to output the current state of the UI, and you never have to think about whether some previous thing you said will make the UI, like, appear different, right? So you can just say, one pass, here’s what the UI should look like, and that is what the UI will look like.” Blow asks at 3h14m8s: “Was it Sean who used to do the IMGUIs where you would like call the function twice, once with display off and once on?” Muratori: “Yep.” Blow: “Did you ever do it that way?” Muratori: “I think I have played with doing it that way but I don't remember ever liking that.” At 3h19m55s Muratori explains how he did the React virtual-DOM diff and merge thing on his “command buffer” to draw an IMGUI with Qt, pointing out that you could do the same thing with HTML. Oh, at 3h45m50s there’s how scrollable sections work (though it has some bugs where scrollbars don’t show): ui_begin_scrollable_section(*results_scroll_value, w=..., h=...), with presumably a corresponding end call later. He has just a ui.selection_list inside it in that case, which turns out to be a loop calling ui.button for each item in the array which returns the index of the selected button. And I’m amused to see that ui.button is just a call to ui.checkbutton which passes a null pointer for the state, which ultimately calls draw_button with 8 positional parameters, which calls draw_label, which calls text_origin to figure out where to draw the text. Very educational video, even though I think some of the code is kind of naff, like ui_end(false, true). I managed to finish the whole video.
discussion of #Muratori’s keynote
on 02025-07-23#Muratori’s notes on his keynote talk
on 02025-07-23Casey #Muratori on "Semantic Compression" #toread
on 02025-07-23Chris #Wellons explores how to do interactive programming in #C, following Casey #Muratori’s “Handmade Hero”, by reloading a shared library. #toread
on 02025-07-23Casey #Muratori’s keynote about, largely, #disjoint-unions and how it is sad that #C++ doesn’t have them. “I’m not saying OOP was a mistake. I’m saying this [a compile-time hierarchy of encapsulation that matches the domain model] was a mistake.” Also traces the #history of records in #programming-languages through Simula and Hoare’s record-handling paper and the “plex” of Douglass Ross of the MIT Servomechanisms Laboratory in AED, Algol Extended for Design, and also #Sketchpad, which had in-memory records (“chickens”) linked together in circular linked lists, which apparently was an idea he got from Ross (“n-component elements”). Both Ross’s plexes and Sketchpad had function pointers in the records. (But the constraint solver was “the most unencapsulated thing that you could possibly imagine”.) Also documents how Looking Glass in 01998 introduced the #Entity-Component-System pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. At 82'40” he points out that he independently invented a worse version of ECS at definitionSIX for Negaman in 01997. “It’s just, I sucked at it, and Looking Glass was good.” Basically his “35-year mistake” thesis is that we almost had ECS in 01963 with Sketchpad, but it took until 01998. He likens 01990s OOP dogma to playing Magic: The Gathering, which I think is insightful. At 136'45” he tells his devotee Ryan Fleury that he has snatched the stone from his hand and may now leave. Nice quote: “You should focus on the hardest stuff. You should say, ‘what solves the hardest problems?’ because we can always then take that and scale it down, and remove things from it or dumb it down, for people to use in cases that aren't as hard. But it’s almost impossible to take something that only solves simple problems and scale it up to something that solves hard ones.”
on 02025-07-22a software conference organized around Casey #Muratori’s ideas
on 02025-07-20#video of Casey #Muratori explaining #ImGUI
on 02024-08-16