I wonder if "the right solution" is a programming language that is fast, concise, trivially easy to run, and outputs some efficient binary format like protobuf.

Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)

> Programming languages have . . . control flow

I do not want control flow of any kind in my configuration file. Nor do I want expressions or any kind of evaluation.

Greppability is a must-have feature for me. As is simplicity - I don’t want to have to deal with internalizing interpreter mechanics, rules for precedence, variable scope, etc just to figure out what config values my program is going to be provided with.

Any time I’ve been forced to work with a system which used a general or restricted programming language to express configuration, it’s been a nightmare.

If your config language doesn't have its own control flow then it's going to get a meta layer added on with control flow. Like, what do you do if this service has a different hostname in staging versus prod? Or connects to a different DB, or whatever. Either have one template file and give it a values file when you go to deploy it, or have two fully-written out files... which becomes annoying when you have to make sure you keep them in sync across two or more environments, often leading to a hacked on and poorly implemented templating system anyway (eg, Helm)

If your program requires executing another program to prepare its options, then something has gone wrong in design or architecture.

Configuration is a type of API - and should be designed with the same care and goals including human legibility, orthogonality, “simple things should be simple to do”, surprise avoidance, stability, minimalism, etc.

Instead often what we get is little more than a sort of serialized form of the internal state of the system.

If configuration is an API, what's the harm in scripting against it?

"Easier" is probably the right one-word generalization, but worth noting that there are quite different challenges. Stopping distance is substantially greater, so "dead halt" isn't as much of a panacea as it is in dense city environments. And you need to have good perception of things further away, especially in front of you, which affects the sensors you use.

Also on surface roads you can basically stop in the middle of the street and be annoying but not particularly dangerous. You can’t just stop safely dead in the middle of a freeway.

For compute-heavy code "100x slower than C++" is a good rule of thumb in my experience in python 3.10.

Maybe when you are reinventing the wheel instead of using e.g. numpy, Jax, PyTorch. Python is an ecosystem some of which is tooling built in C/C++. There’s no reason to ignore those libraries just because C devs like to roll their own everything.

There's an Amdahl-like effect, where "100x slower" means that anything nontrivial in pure python ends up being fat in your flamegraphs, even if your "heavy lifting" core algorithmic stuff uses some nice fast libraries.

For cloud jobs that can be true, but for single threaded dev-in-the-loop work you can't just buy a 100x faster processor than the one on their dev machine, and the latency is expensive workflow friction.

This might have been your experience, but mine has been very different. In my experience a typical python workload is 50% importing python libraries, 45% slow python wrapper logic and 5% fast native code. I spend a lot of time rewriting the python logic in C++, which makes it 100x faster, so the resulting performance approaches "10% fast native logic, 90% useless python imports".

There is more than one PEP related to making imports faster such as PEP 690 or PEP 810. It's definitely a well-known problem. The solution is probably right around the corner.

Imports being slow is annoying, but only matters to short running code.

Many simple scripts at my work that more or less just argparse and fire off an HTTP request spend half a minute importing random stuff because of false deps and uncommon codepaths. For some unit tests it's 45 seconds, substantially longer than the time taken to run the test logic.

In dev cycles most code is short-running.

> Many simple scripts at my work [...] For some unit tests it's 45 seconds

> I spend a lot of time rewriting the python logic in C++, which makes it 100x faster

Nice! Your workplace didn't care to pick a better tool for the job in the past, and it seems to not care what you're doing at present, if you have to spend time rewriting the stuff in C++, instead of picking Nim and calling it a day, in a day.

Even better, in Nim these little CLI tools could use https://github.com/c-blake/cligen and have had terminal colorized, auto-generated help for many years now with much less dev-effort than raw argparse. Start-up time of statically linked Nim programs is like O(100..500 microseconds, just like C programs).

Have you thought about packing that stuff into an executable or precomputing or preloading it? There's techniques for each of those things that help in some scenarios.

If imports are slow, you need to not be writing python in the first place, because you are either on limited hardware or you are writing a very performant app.

Yeah, I think the "paradox" is usually a problem for pundits and academics and not practitioners. Lots of people have experience finding and correcting market inefficiencies, usually getting paid for it.

Yeah, I feel like people have this idea that the EMH is 'economists think markets are perfectly efficient' when really it's 'under these idealised conditions a market should approach perfect efficiency' and any real market is obviously not going to be perfectly efficient, but ones that get closer to those conditions should be more efficient.

(And looking at how traders work, it's all about finding a strategy that no-one else has found and executing on it. Once two competitors with similar resources know the strategy, it ceases to be particularly profitable, which to me seems to be pretty in line with the EMH)

A system of n experts is no different to a single expert wrt the NFLT. The theorem is entirely indifferent to (ie "equally skeptical of") the idea.

Releasing an open source product that improves on alternatives doesn't sound like ”stealing” or ”adding no value" to me.

They're giving away something valuable, same as the people whose work they're building on top of.

The linked article literally starts by calling themselves an anti innovation company and declaring they do not intend to improve on it (at least not in innovative ways)

I wonder about the global statistics of sorted data... Is the most common number of elements to sort zero? Certainly less than ten?

What about the median? Two elements to sort? One? Zero again?

The question is also for which list lengths the performance matters most. When sorting a few strings (<20), whether the algorithm uses 5 or 7 comparisons would usually not matter too much. So to find the optimal algorithm for a given situation, we would have to compute a weighted average by list length importance on the performances of the algorithm per list length.

I have great credit and my bank charges me $3 every month to pay my rent. (They will send a cheque in the mail for free, but it wasn't reliable for me so I stopped doing that.) Third world stuff.

Doesn't sound normal unless the fee is being charged by the landlord and not the bank. (Landlords seem to love payment fees.)

It's the bank. One of the biggest US retail banks. Maybe other big ones don't, maybe I should change banks.

Wat