If you can define your problem well then you can write tests up front. An ML person would call tests a "verifier". Verifiers let you pump compute into finding solutions.

I'm not sure we write good tests for this because we assume some kind of logic involved here. If you set a human to task to write a procedure to send a 'forgot password' email, I can be reasonably sure there's a limited number of things a human would do with the provided email address, because it takes time and effort to do more than you should.

However with an LLM I'm not so sure. So how will you write a test to validate this is done but also guarantee it doesn't add the email to a blacklist? A whitelist? A list of admin emails? Or the tens of other things you can do with an email within your system?

Will people be willing to make their full time job writing tests?

We’ll just have an LLM write the tests.

Now we can work on our passion projects and everything will just be LLMs talking to LLMs.

I hope sarcasm.

They probably won't. But it doesn't matter. Ultimately, we'll all end up doing manual labor, because that is the only thing we can do that the machines aren't already doing better than us, or about to be doing better than us. Such is the natural order of things.

By manual labor I specifically mean the kind where you have to mix precision with power, on the fly, in arbitrary terrain, where each task is effectively one-off. So not even making things - everything made at scale will be done in automated factories/workshops. Think constructing and maintaining those factories, in the "crawling down tight pipes with scewdriver in your teeth" sense.

And that's only mid-term; robotics may be lagging behind AI now, but it will eventually catch up.

As well, just because it pasts a test doesn't mean it doesn't do wonky, non-performant stuff. Or worse, side effects no one verified. Plenty often the LLM output will add new fields I didn't ask it to change as one example.

> by the time I write an exact detailed step-by-step prompt for them, I could have written the code by hand

The improved prompt or project documentation guides every future line of code written, whether by a human or an AI. It pays dividends for any long term project.

> Like there is a reason we are not using fuzzy human language in math/coding

Math proofs are mostly in English.

Vibe code an eval harness with a web dashboard

Because your code is actual running serially so no matter what there is an iteration order, and the order matters for performance even if your code does not care.

For example if you literally don’t care about the order then your code can map over a default iterator that is efficient (DFS).

Not true due to parallelism. Also, SQL demonstrates that you can describe the desired result declaratively without being concerned about iteration order. I see SQL's CTEs as a good example of the kind of primitive the article is talking about.

Sure, and perhaps that's the reason why we don't have a built-in for_tree: for some people, order matters; for others, it doesn't.

Then, for some cases, depth-first traversal is needed; for others, breadth-first.

Then, there's parallelism, and even the plain old for loops aren't parallel by default.

By the time you specify exactly what you need from a tree traversal, you've written code to do it.

And if you're fine with some default choice — you already can use the default iterator with the for_each loop.

I don't see what need there is for adding an extra for_tree syntax to do that.

Also a lot of trees have fixed arity, like binary trees. But to model a general tree, you'd need a dynamically allocated list of children for each node, adding a layer of indirection that can noticeably worsen performance.

Trees are often considered too diverse to include even in the standard library, let alone as a primitive. Even Python doesn't have trees in the standard library. I'm sure it's been proposed and rejected at some point

> But to model a general tree, you'd need a dynamically allocated list of children for each node, adding a layer of indirection that can noticeably worsen performance.

I hate to be a broken record, but this again goes back to the assumption of a specific sequential computation model. Modelling relations as in SQL automatically supports for N-ary child relations. There are other computation models! eg. logic, relational, etc.

I'm talking about cache optimization. Fundamentally, you simply cannot guarantee data locality while also allowing resizing. Growing the child list may necessitate moving it in memory. This is true no matter what your computation model is.

Those other models lack native mechanical sympathy with the hardware.

Let's be practical about it: the reason you might want to say map_tree is so it could potentially be optimized to run more quickly, e.g. via automatic parallelization.

But to even parallelize a tree read operation we'd have to pull in other threads, split work, we'd want metadata on each node (child counts), and at the end of the day within each worker you'd still have a serial execution order.

For map_tree to have practical benefit your language would need to make a ton of opinionated choices about trees and parallel programming. Feasible? Yes. Worth making it a basic primitive? Well, even LISPs don't offer map_tree, despite building the whole language on top of car/cdr.

All the AI tools end up converging on a similar workflow: type what you want and interrupt if you're not getting what you want.

Advances in AI are bringing down the cost of processing audio by perhaps 5x a year, and has been doing so for several years now.

The risk is that it becomes worthwhile for someone to record everything now and process it later at their own leisure.

The primary cost in this case is raw storage and bandwidth. What is AI doing to reduce that cost? Also what source confirms that “processing audio” is 5x cheaper because of AI? Seems like a dubious claim.

People go to Tokyo and Osaka because that's where it's easier to find good-paying jobs.

> I don't think anyone today would seriously argue that Hanja is preferable

It's necessary to use Hanja today in educated contexts because Hangul has too many homophones, and most educated (technical, literary, scientific) vocabulary has a Sinitic origin and therefore are more homophonic than typical Korean words.

Sure, and lawyers in English-speaking countries similarly use Latin and Old French jargon to reduce ambiguity. But this is a fairly narrow use case that is really more of a specialized notation - it's not used day-to-day even by people who regularly use Hanja professionally.

This is not a reason for Japanese people to keep Kanji, but Chinese tourists can read Japanese at about 50% comprehension level just due to Kanji without knowing at all how the words are pronounced in Japanese.

> A professor isn't a school teacher that needs to look after each student individually

There's a line of research that shows that high quality one-on-one instruction gets you up to 2stdev gains in learning performance.

If you can afford to increase the professor to student ratio and make them available for office hours, you probably do see increases in performance. Is it due to better motivation? Seeing an academic up close? Actually better explanations you get from an expert in the subject? Hard to say.