_verandaguy

I imagine it's not the first time, It must've at least been proofread at the time of writing :)

But really impressive stuff! Between this and (a particularly optimistic outlook on) the Linear-A news from the other week this is an exciting time for linguistics.

I'm still trying to figure that out. Something diplomacy-adjacent would be interesting to me; maybe conflict studies, or international relations.

Based on word from my friends who work in the field, a lot of it is people who have a lot of respect for the field, and a lot of professional respect for eachother. It's also a field I feel is unlikely to suffer from the same kind of scams that are taking over software while still offering an engaging environment.

It's also work with real-world impact, which is nice, though obviously comes with its challenges.

    > I am contemplating whether I want to stay inside this rat race.

I'm in the same boat. I'm hoping to go back to school in 2027 and be out of work that revolves around programming in 5 years.

I'm not enthusiastic about the field anymore, which sucks, because I used to love working in programming.

My issue with this is that it's a form of "soft" reproducibility, where it'll work for many (maybe even most!) people, but that depends on the way the original prompt was formulated (read on) and the state of the random noise in the system.

On the prompt formulation; prompts with very similar formulations (in terms of both semantics, hamming distance, or both) can lead to _wildly divergent_ outputs in my experience. It's not rigourous, and when that divergence happens, it's extremely difficult (arguably impossible, by nature of the architecture of transformers) to identify why the divergence happened and where.

All things aside, I think this misses the forest for the trees on the halting problem.

It's not about being able to throw claude or codex at a loop and having it evaluate it for halting, it's about being able to do this for arbitrary code. Computer science rigourously defines the halting problem as not computable and undecidable. within the framework of using something akin to static analysis using any deterministic Turing machine.

There's not really a question of "solving" the halting problem like there's some as-yet unknown way of generally figuring out if arbitraty code halts. Turing proposed a proof in 1937 in favour of undecidability of what we now know as the halting problem, building on ideas first articulated by Church a few years prior.

Frankly, if anything, it's reasonable to say that the halting problem's been solved, just in the direction of undecidability rather than decidability.

Anyway, back to LLMs; as code gets more complex, the robot will need a bigger context window, more hardware resources, and more time, all of which will be variable due to the noise inherent in the system. It'll be difficult to put a useful upper and lower bound on how much computing power and time it'll take to figure out if a program ever halts. Which is all a bit moot, frankly, in the context of halting, but useful to keep in mind in the more general context of using these things as analysis tools.

This isn't really a reasonable approach, is it?

The original prompts aren't provided, nor is the original context; even then, you can't really treat a stochastic system like an LLM as a major component in reproducibility.

Thank you for this meaningful contribution to the discussion.

This is a bit of a traffic circle way of explaining the joke.

Isn't it usually "souverainiste?"

Driving everyone's QoL to be as bad as possible will lead to increasing enshittiffication in the entire market.

Consumers will be spoiled for choice between deeply mediocre options.

Besides, what's the point of adopting new technologies if it's not to increase the quality of life? If everyone just exists in service of the product development lifecycle, who and what are the products actually for?

Believe it or not, the library predates the understanding of monads as a mathematical concept! Though it can be argued it is an example of a functor (the library is mapped over two countries).

It would be good to understand how exactly a frontier lab is approaching "removing the model's ability" to do a thing.

There's an ocean of difference between e.g. preventing the model from routing to something at the firewall level and just updating the prompt (especially given models' historically poor understanding of negative prompts, relatively speaking).

    That's true. But if America is so bad, why are you still in it?

I am not. I have never lived in the US. I live in Canada, and I've had my country's sovereignty threatened by the US in the past 18 months.

Leica started doing this a few years ago in response to the first wave of AI images[0]. Other, bigger manufacturers (Nikon, Canon, Sony as well I believe) have also joined, though with less fanfare. Adobe is in the loop.

As someone with a passing interest in infosec and cryptography, I'm sceptical of the long-term viability of this kind of product; it only takes one person successfully extracting a signing key to undermine the entire project.

    [0] https://leica-camera.com/en-int/news/partnership-greater-trust-digital-photography-leica-and-content-authenticity-initiative

Historically, it isn't Canada that's been threatening to leave NATO.

I'm saying that the truth lies somewhere in between, and that Anthropic's current revenue is being, in part, propped up artificially.

We're also in a place where a lot of the usage guidance around these tools is still nascent. People are cowboying a lot of stuff, even as larger companies start to organize AI policy/safety/responsible use working groups to try and policy around the shortfalls of the technology.

IMO: if this technology persists, and if we figure out a way to use it in a broadly safe way, the value proposition will probably trend down rather than up, at least on the code generation front.

As a research tool, it shows some promise, though I still find the ethics of the technology disgusting.

With respect to Simon, whose writing I've usually agreed with in the past and whose insights I've liked: this is a bad take that overlooks the extent to which corporations are imposing the use of AI on employees, and in particular ICs, who make up a majority of the AI-using workforce by headcount.

Many of us are either openly having our performance reviews tied to AI use, especially at larger enterprises. Whether that's measured by sheer token count or just "how many of your tasks are you using AI for these days" (combined with the implication that question carries at many orgs which are heavily invested in AI).

You don't have to root for or against anyone in this fight. It's perfectly valid to oppose both actors and both outcomes, and the stakes of the fight.

This is the main reason I stay away from Vivaldi; using Firefox is, for all of Mozilla's borderline comical mismanagement, a protest vote against Blink (and previously, Chromium).

Why would the language being typographically ugly matter? Python's pretty, but it hides a lot of functional nuance behind that. Rust is terse, but it's also expressive in its terseness.

If you want to give it a fair shot, it does take some time to get used to, coming from something like Python or Ruby. I won't deny that. I've found that using LSP-assissted semantic syntax highlighting helps, for me, on the typographic front.

I don't think typographic design is a key consideration in most languages' designs, though, and I don't think it should be. The main thing I look for is consistent, relatively predictable rules around the syntax, as far as that layer of language choice goes.

    > So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)

No, the performance impact will depend on `impl Clone` for the underlying type, the hotness of the code path, and how sensitive to those two variables your code's domain is. It may be extremely expensive.

    > Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).

There are cases where assuming `clone` is possible allows for significant architectural and API simplifications at the expense of performance. In those cases, de-cloning will be involved and may produce significant changes.

The other side of this is that they're replaced with people who aren't qualified to evaluate the work output of the LLMs.

I'll push back against most of the points in your comment.

    > The demand for AI is currently overwhelming. As in, can't build data centers and GPUs melting overwhelming, companies growing 3x in a month while already at multi-billion revenues.

This isn't a sign of a successful, sustainable business; it's what a bubble looks like. Between the aggressive marketing (including astroturfing!) that LLM companies are engaged in, the perceived stock market advantage companies can gain by shoving LLMs into their offering, and the missile-gap-style approach that many businesses are taking around this, this centre cannot possibly hold.

    > The models get better and better, Chinese open source is falling further and further behind American companies

American companies are, to be fair, flaunting safety and ignoring the wider social impacts of this technology, and both the US federal and state governments seem to be more than willing to go with the flow on that, probably at least partly because of a recognition that the LLM industry is propping up a significant part of the US economy.

    > The productivity gains are, at this point, obvious

They are, emphatically, not. For me and my peers (most of us, individual contributors in software -- and emphatically, those of us working at companies who haven't fully leaned into vibe coding), our jobs have become babysitting claude agents and spending most of our time cleaning up its messes and doing code review. Short-term, sure, this might lead to some productivity gains, but long-term, this is going to lead to mass burnout.

    > The best talent works (or wants to work) in America and get compensated obscene amounts, the most capital flows through America, this is still by far the best place to start a technology business in the world

Unfortunately, the US is in the midst of cracking down on immigration, and the international perception of the country is increasingly that it is an unsafe one.

    > I think American technology was on the decline for the past few years before LLMs, but for the foreseeable future as long as American companies control the talent flywheel I think the new world of tech is going to be much more American than before.

What I see in the US's LLM-backed economy is what I see in many businesses in this same economy, increasingly: the blanket of AI is being used to paper over serious, systemic issues in the organization, but this clearly won't hold. In a world where we have an ounce of responsibility for what we produce, and where customers care about the quality (notably, quality as in correctness) of what's being delivered, this will eventually collapse.

IMHO: when an emerging technology threatens the livelihoods of millions, it's responsible and ethical to step away from seeing this stuff through a purely competitive lens.

Out of the three big geographic players, the US and China are jockeying for "most performant" models (whatever that means) with two separate approaches; the EU is trying to develop models that work best within their privacy, human rights and labour rights frameworks and laws.

All of these have have merits, though arguably the US's (de-facto) strategy of market dominance at any cost with as few restraints as possible will be the worst for society at large. The prudent thing to do would be to first determine if this is something that will actually live up to the hype (which IMO is still very much in the air), and then if it does, turns this into an international collaboration rather than a competitive enterprise.

It's not lost on me that this is a terminally naive point of view.

AI-unrelated tangent, but I think it's pertinent to your comment.

I come from a heavily Python background, professionally. I spent the entire first decade-and-change of my career using almost exclusively Python; I know it about as well as a person reasonably can (outside of scientific and ML Python, which I just never got interested in, but that's beside the point).

A year and a half ago I got a job doing Rust. At a surface level, it's about as far as you can get from Python in terms of ease of readability, but after 18 months I'm really reconsidering some of my points of view on the matter.

"Explicit is better than implicit," for example, is something I still strongly agree with, but my definition of "explicit" has shifted a lot in the past year. Seeing which guarantees are provided through mandatory, explicit, strong typing saves a lot of time over tracking down guarantees in MRs while reviewing Python code. If I see a signature as an `Arc<dyn AudioInterface>`, for example, I immediately know that:

- It's thread-safe and memory-managed using reference counting (because `Arc` provides those guarantees);

- It's a type-erased object but is guaranteed to provide all the functionality from the `AudioInterface` trait (which, let's say, could be a supertrait of `AudioInput` and `AudioOutput` -- so it provides both of those);

- It uses runtime dispatching (since it's a `dyn` rather than a generic/`impl T` where `T: AudioInterface`)

I can choose to operate on it by reference with all the caveats that entails, or decide to either `Copy` or `Clone` it, depending on whether that's available for that type and if I can stomach the runtime cost.

All that to say -- Rust doesn't suck to review, relative to Python, in the long run. At first, yes, holy crap, it's such a huge cliff, and I can appreciate your point of view... but there's something to be said about having all this information surfaced as part of the language's syntax and semantics.

Python still has a special place in my heart, and I'd still use it over anything else if Rust isn't an option, but to echo a popular sentiment from other people who've made this migration, I don't know if I can go back to handwaving away whether or not something'll cause an allocation :)

A counterpoint, since I never made that logical jump in your latter part of your comment: programming languages are, functionally, all domain-specific languages and do a good job of either describing directly, or consistently, deterministically, providing a reasonable and unambiguous abstraction over low-level concepts expressed by assembly languages.

Human languages are mostly very bad at this, and in particular bad at mapping low-level abstraction to the human written word unambiguously in a way that is as expressive as programming languages.

Inference closes that specific gap significantly (which is why anyone at all sees LLMs as a useful option to explore), but it will never be as good as a purpose-built language designed to map to a reasonable corresponding assembly language implementation.

Satire is dead

It is a fact that some useful things in the software world are a pain in the ass to learn, and that they could be better on that front.

LSP is one of those things, or at least it has been, for a while.

LSP is also something that's not necessary to writing quality code; it's absolutely a major quality-of-life boost, but before rewriting my configs after switching to Rust, my LSP usage was limited to being a slightly faster autocomplete engine more than anything. I didn't have keybinds set up for going to definitions, implementations, or references of symbols. I still put out what I think was decent code. I'm also better off now that I've adopted a more useful config.

IMO it's an important part of this industry (among others) to let developers have whatever workflow they want, within reason. If someone decides they want to invest the time into setting up LSP with their editor, that's their prerogative. If not, that's fine too. I don't know who among my present or past coworkers use LSP outside of occasionally chatting about editor configs with one or two of them, because they've usually figured out a workflow that lets them produce respectable code, and I've never had to question their tooling before questioning their methodology.

While this comment is overly general (some major editors ship without LSP support built in; many more do not have a sane configuration out-of-the-box), it is useful to learn about them and how your editor of choice integrates with them.

The landscape isn't generally intuitive, unfortunately, and while it's getting better, understanding the differences and interop places between LSP, Treesitter, DAP, your editor, and the underlying language-specific tooling can be a big, confusing time hog.

That said, and to be clear: LSP's been a huge boon for me. I used a minimal, kinda-broken configuration for a while with Python, then rebuilt the whole thing when I switched to Rust for work, and holy hell, this thing's awesome.

An outstanding move for a company claiming to sell trust as a service.