LLMs struggle with TDD. They want to generate a bunch of code and tests in large passes. You can instruct them to do red/green TDD, but the results aren't great.

SDD starts before implementation, and formalizes intent and high-level design. LLMs eat it up. The humans can easily reinvent the worst parts of waterfall if they're not careful.

They're not mutually exclusive.

On the low end where RISC-V currently lives, simplicity is a virtue.

On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.

The instructors would bring out a helium balloon and a candle on a meter stick. The balloon goes pop, huzzah.

Then the twist. "Hey, wanna do it again?" All the kids would be like "meh, I guess?" They would then bring out a balloon full of hydrogen (maybe some oxygen too?). It would look identical to the first one, floating there tethered to the lab bench.

When the candle hit the second one, it made a white flash and a really sharp BANG. It was an order of magnitude louder, and you could hear the transient bouncing off the walls and echoing in the halls. It made an impression.

https://github.com/resumex/doom-over-dns/tree/main/TXTRecord...

If you want to lock down versions on a system, Apt Pinning: https://wiki.debian.org/AptConfiguration#Using_pinning

If you have a herd of systems - prod environments, VMs for CI, lots of dev workstations, and especially if your product is an appliance VM: you might want to run your own apt mirror, creating known-good snapshots of your packages. I use https://www.aptly.info/

Containers can also be a great solution though.

It's also a function of the rate of discharge. Have a look at this:

https://marsen.com.au/wp-content/uploads/2021/08/Panasonic-N...

All that space between the black and green curves is energy being lost to internal resistance.

Thank you, I'll update my brain and future explanations. :)

[1] https://ad.easa.europa.eu/blob/NM-18-33.pdf

[2] https://www.mouser.com/datasheet/2/187/honeywell_hwscs06627_...

Why do you need to make so many molds?

There was no memory protection in Real Mode, so you could always poke the hardware yourself, but something written on a Tandy wasn't going to work on a Zenith unless you supported both, or ran everything through the BIOS.

Over time, the OS took over the HAL role, with the BIOS only being used until the OS could load native drivers. Now it's UEFI... same idea with a higher greater level of abstraction and modularity.

For a simple example, let's say you are simply driving in a circle. The car wants to lean toward the outside. The linear motors can provide a countering force, lifting the outside, lowering the inside, so the car stays level. Variable damping can only control the rate that it rolls. It will still roll in sub-second timescales, unless it completely locks down the suspension, which is terrible for both handling and comfort.

For another simple example: going over a speed bump. Linear motors can lift the front wheels over the bump, and then the rear wheels, so the body stays level the whole time. An active damper can go full-soft the moment the wheel hits the bump, but the compressed spring will still start lifting the front of the car. An active damper can do a better job managing the rebound on the far side so it doesn't oscillate, but it can't entirely prevent the bump from pitching the body up and down in the first place.

That's not to say it's worthless. Very fast active dampers can improve both handling and comfort. It's just nowhere near the level which is possible with linear motors.

For my Ruby example, each of those method calls will allocate an Array on the heap, where it will persist until all references are removed and the GC runs again. The extra overhead of the named reference is somewhere between Tiny and Zero, depending on your interpreter. No extra copies are made; it's just a reference.

In most compiled languages: the overhead is exactly zero. At runtime, nothing even knows it's called "data" unless you have debug symbols.

If these are going to be large arrays and you actually care about memory usage, you wouldn't write the code the way I did. You might use lazy enumerators, or just flatten it out into a simple procedure; either of those would process one line at a time, discarding all the intermediate results as it goes.

Also, "File.readlines(i).count" is an atrocity of wasted memory. If you care about efficiency at all, that's the first part to go. :)

Compare with a simple pipeline in bash:

  grep needle < haystack.txt | sed 's/foo/bar/g' | xargs wc -l

Compare Ruby:

  data = File.readlines("haystack.txt")
    .map(&:strip)
    .grep(/needle/)
    .map { |i| i.gsub('foo', 'bar') }
    .map { |i| File.readlines(i).count }

Despite being clean and readable, I don't tend to do it any more, because it's harder to debug. More often these days, I write things like this:

  data = File.readlines("haystack.txt")
  data = data.map(&:strip)
  data = data.grep(/needle/)
  data = data.map { |i| i.gsub('foo', 'bar') }
  data = data.map { |i| File.readlines(i).count }

It's not completely crazy. Software was developed by much smaller teams and got out the door quickly in that era.

That's basically the JVM, isn't it?

It's interesting to think how some of the reasons it sucked for desktop apps (performance, native UI) are also true of Electron. Maybe our expectations are just lower now.

-- https://www.forbes.com/sites/startswithabang/2015/12/19/ask-...