> If you can deliver the same thing in fewer correct lines of code

it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.

Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?

Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).

Parent said "I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N."

You're arguing the inverse: that at least some parts of the code are independent of N. Sure. But the topic is the part that isn't.

This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.

Apparently roughly ~150k math PhDs live on earth right now, assuming they all know Lean that's between 0.001% and 0.002% of earth population so quite closer to no one than one

Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)

> How fast do you want your slideshow to be?

we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.

For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.

That's fine reasoning for video, but if someone is actually looking at a still picture for more than 1/240th of a second, the fine detail matters a bit more. These are different applications, with different sweet spots in the time/quality trade-off.

would be great to have the weights somewhere

or maybe erlang / elixir do not have 1/1000th of the libraries and features available to C++ thus it's more efficient to port what can be ported? would you rather have the whole of C++ ported to erlang?

next intel cpus will have AVX 10.2 & APX

export to large files that represent numbers in textual format for instance ? this can be the difference between "waiting 10 seconds when hitting ctrl-s" and "the software saving automatically on each change because it's unnoticeable"

> it's OK to not be the most efficient all the time

is it ? it's a non-negligible reason for the absolutely unsufferable technological world we are currently living in

It absolutely is wonderfully alright to not be the most efficient all the time. I'm going to use this opportunity to quote Kurt Vonnegut at length:

I work at home, and if I wanted to, I could have a computer right by my bed, and I’d never have to leave it. But I use a typewriter, and afterwards I mark up the pages with a pencil. Then I call up this woman named Carol out in Woodstock and say, “Are you still doing typing?” Sure she is, and her husband is trying to track bluebirds out there and not having much luck, and so we chitchat back and forth, and I say, “OK, I’ll send you the pages.”

Then I’m going down the steps, and my wife calls up, “Where are you going?” I say, “Well, I’m going to go buy an envelope.” And she says, “You’re not a poor man. Why don’t you buy a thousand envelopes? They’ll deliver them, and you can put them in a closet.” And I say, “Hush.” So I go down the steps here, and I go out to this newsstand across the street where they sell magazines and lottery tickets and stationery. I have to get in line because there are people buying candy and all that sort of thing, and I talk to them. The woman behind the counter has a jewel between her eyes, and when it’s my turn, I ask her if there have been any big winners lately. I get my envelope and seal it up and go to the postal convenience center down the block at the corner of 47th Street and 2nd Avenue, where I’m secretly in love with the woman behind the counter. I keep absolutely poker-faced; I never let her know how I feel about her. One time I had my pocket picked in there and got to meet a cop and tell him about it. Anyway, I address the envelope to Carol in Woodstock. I stamp the envelope and mail it in a mailbox in front of the post office, and I go home. And I’ve had a hell of a good time. And I tell you, we are here on Earth to fart around, and don’t let anybody tell you any different.

Now I want to read the wife’s thoughts on this piece.

I wonder if she knew about the woman at the post office!

Really? Do elaborate.

out of dozens of laptops and computers we have where I work, we have maybe 3 that have a PTP-compatible NIC.