But it just moves the question to whether the theorems covered in the proof are sufficient. Underlying it all is a simple question:

Does the system meet its intended purpose?

To which the next question is:

What is the intended purpose?

Describing that is the holy grail of requirements specification. Natural language, behaviour-driven development, test-driven development and a host of other approaches attempt to bridge the gap between implicit purpose and explicit specification. Proof assistants are another tool in that box.

It's also one of the key motivators for iterative development: putting software in front of users (or their proxies) is still the primary means of validation for a large class of systems.

None of which is implied criticism of any of those approaches. Equally, none completely solves the problem. There is a risk that formal proofs, combined with proof assistants, are trumpeted as "the way" to mitigate the risk that LLM-developed apps don't perform as intended.

They might help. They can show that code is correct with respect to some specification, and that the specification is self-consistent. They cannot prove that the specification is complete with regards its intended purpose.

Comments URL: https://news.ycombinator.com/item?id=47216037

Points: 494

# Comments: 222

> It’s clear, people want to be addicted to social media

I'd say people are susceptible to addiction rather than wanting it. Suppliers of any addictive product - whether its tobacco, class A drugs, alcohol, gambling or social media - know that. Going too hard the other way into full prohibition is impractical because it starts to impinge on civil liberties: as a capable adult, why shouldn't I be able to smoke/drink/doomscroll instagram if I want?

That's why it's dificult; neither extreme liberty nor extreme prohibition is the answer. It's a grey area as GP notes. The trouble is it creates opportunities for people like Zuckerberg to exploit the middle ground and amass huge personal wealth paid for, in part, by the health detriment of those unable to self-regulate the addiction.

"Design Thinking" as a brand has codified that in several ways - not all successful. But the underlying principle is sound: there are plenty of examples of products/services that failed to address one or more of the 3 dimensions.

I found this quote from the linked article [0] more helpful:

> Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

[0]: https://www.designorate.com/design-thinking-guide-what-why-h...

1. Coding assistants have emerged as as one of the primary commercial opportunities for AI models. As GP pointed out, LWN is the primary discussion for kernel development. If you were gathering training data for a model, and coding assistance is one of your goals, and you know of a primary sources of open source development expertise, would you:

  (a) ignore it because it’s in a quaint old format, or

  (b) slurp up as much as you can?

  (a) carefully and respectfully leave it be, because you still get benefit from the previous content even though there’s now more and it’s up to date, or

  (b) hoover up every last drop because anything you can do to get an edge over your competitors means you get your brief moment of glory in the benchmarks when you release?

> it's really just a spec that gets turned into the thing we actually run. It's just that the building process is fully automated. What we do when we create software is creating a specification in source code form.

Agree. My favourite description of software development is specification and translation - done iteratively.

Today, there are two primary phases:

1. Specification by a non-developer and the translation of that into code. The former is led by BAs/PMs etc and the output is feature specs/user stories/acceptance tests etc. The latter id done by developers: they translate the specs into code.

2. The resulting code is also, as you say, a spec. It gets translated into something the machine can run. This is automated by a compiler/interpreter (perhaps in multiple steps, e.g. when a VM is involved).

There have been several attempts over the years to automate the first step. COBOL was probably the first; since then we've had 4GLs, CASE tools, UML among others. They were all trying to close the gap: to take phase 1 specification closer to what non-developers can write - with the result automatically translated to working code.

Spec-driven development is another attempt at this. The translator (LLM) is quite different to previous efforts because it's non-deterministic. That brings some challenges but also offers opportunities to use input language that isn't constrained to be interpretable by conventional means (parsers implementing formal grammars).

We're in the early days of spec-driven. It may fail like its predecessors or it may not. But first order, there's nothing sacrosanct about the use of 3rd generation languages as the means to represent the specification. The pivotal challenge is whether translation from the starting specification can be reliably translated to working software.

If it can (big if) then economics will win out.

He's also just released a book on hosting scale production Python apps [3]. Haven't read yet though would assume it'll get covered there in more detail too.

--

[0] https://talkpython.fm/

[1] https://talkpython.fm/blog/posts/we-have-moved-to-hetzner/

[2] https://talkpython.fm/blog/posts/update-on-hetzner-changes-p...

[3] https://talkpython.fm/books/python-in-production

Ladybird currently has 8 full-time devs [1] and is making impressive progress on delivering a browser from scratch. Wise investment in small, focused, capable teams can go a long way if they're not chasing VC-driven Unicorn status (or in stasis as a Google anti-trust diversion).

That's not challenging your point though: in the face of competing budgets at US tech giants, EUR17Mn still barely registers above noise level. Nevertheless, it's a start. We can only hope it grows and doesn't get shut down by some political lobbying by the aforementioned US behemoths. A modest budget might actually help there - not yet big enough to cause concern to incumbents.

[1]: https://ladybird.org/

Kind of. The intent is good and the wording disallows some of the dark patterns. The challenge is that it stands square in the path of the adtech surveillance behemoths. That we ended up with the cesspit of cookie banners is a result of (almost) immovable object meeting (almost) irresistable force. There was simply no way that Google, Facebook et al were ever going to comply with the intent of the law: it's their business not to.

The only way we might have got a better outcome was for the EU to quickly respond and say "nope, cookie banners aren't compliant with the law". That would have been incredibly difficult to do in practice. You can bet your Bay Area mortgage that Big Tech will have had legions of smart lawyers pouring over how to comply with the letter whilst completely ignoring the intent.

> The standard, developed in 1994, relies on voluntary compliance [0]

It was conceived in a world with an expectation of collectively respectful behaviour: specifically that search crawlers could swamp "average Joe's" site but shouldn't.

We're in a different world now but companies still have a choice. Some do still respect it... and then there's Meta, OpenAI and such. Communities only work when people are willing to respect community rules, not have compliance imposed on them.

It then becomes an arms race: a reasonable response from average Joe is "well, OK, I'll allows anyone but [Meta|OpenAI|...] to access my site. Fine in theory, dificult in practice:

1. Block IP addresses for the offending bots --> bots run from obfuscated addresses

2. Block the bot user agent --> bots lie about UA.

...and so on.

[0]: https://en.wikipedia.org/wiki/Robots.txt

Thanks for all your work, great to see how well the language and tooling are maturing.

> that has enough privacy to be sustainable

These are the key phrases. Mozilla has hitched its wagon to advertising. Behind all the bluster over last week, the underlying direction is clear. They bought Anonym [0] and Ajit Varma, the new VP of Product for Firefox and source of the updates, is ex-Meta. It's reasonable to assume that he's there, in part, because of advertising expertise.

Some will see Anonym's "privacy-powered advertising" as "enough privacy" and the only viable way to sustain Firefox without Google's annual cash injection.

Others won't buy that, believing that a browser can be built without relying on advertising. Ladybird is taking this approach - so we'll find out.

> If Firefox’s market share dips any lower website makers won’t support it

This is the risk the exec team must know they've taken. Specifically: what proportion of the current Firefox user base exists because of the historic pro-privacy stance, and what percentage of that will leave because of the advertising-based future?

[0] https://www.anonymco.com/

--

EDIT: addedd missing reference

1. Mozilla is now an advertising business - see e.g. links in this El Reg post [0].

2. How you feel about the alternatives.

Behind the PR bluffing of the last few days, #1 is clear. Mozilla has hitched the wagon to advertising.

There's unlikely to be a single good answer for #2. All the alternatives have compromises: Vivaldi is chrome-based and has some closed source code; Brave has crypto and Eich's political views (and also chrome-based; the various firefox forks (LibreWolf, PaleMoon, Waterfox, ...) all have questions over their sustainability.

Perhaps the most promising is Ladybird, but it's a good way off yet.

Let's hope we're near the botton of the enshitification curve and there are positives on the horizon somewhere.

[0]: https://www.theregister.com/2025/03/02/mozilla_introduces_te...

Comments URL: https://news.ycombinator.com/item?id=43203576

Points: 2

# Comments: 3

Those statistics may not be wholly attributable to differences in gun laws but it seems a stretch to suggest they're unrelated.

[0] https://www.linkedin.com/pulse/us-midst-public-health-crisis...

[1] https://www.bbc.co.uk/news/world-us-canada-41488081

I cut my teeth on OS/2 in the early 90s, where using threads and processes to handle concurrent tasks was the recommended programming model. It was well-supported by the OS, with a comprehensive API for process/thread creation, deletion and inter-task communication. It was a very clear mental model: put each sequential sequence of operations in its own process/thread, and let the operating system deal with scheduling - including pausing tasks that were blocked on I/O.

My next encounter was Windows 3, with its event loop and cooperative multi-tasking. Whilst the new model was interesting, I was perplexed by needing to interleave my domain code with manual decisions on scheduling. It felt haphazard and unsatisfactory that the OS didn't handle scheduling for me. It made me appreciate more the benefits of OS-provided pre-emptive multi-tasking.

The contrast in models was stark. It seemed obvious that pre-emptive multi-tasking was so obviously better. And so it proved: NT bestowed it on Windows, and NeXT did the same for Mac.

Which brings us to today. I feel like I'm going through groundhog day with the renaissance of cooperative multi-tasking: promises, async/await and such. There's another topic today [0] that illustrates the challenges of attempting to performs actions concurrently in javascript. It brought back all the perplexion and haphazard scheduling decisions from my Windows 3 days.

As you note:

> Of course, context switching between different tasks is not free, and event loops have frequently been able to provide higher efficiency.

This is indeed true: having an OS or language runtime manage scheduling does incur an overhead. And, indeed, there are benchmarks [1] that can be interpreted as illustrating the performance benefits of cooperative over pre-emptive multitasking.

That may be true in isolation, but it inevitably places scheduling burden back on the application developer. Concurrent sequences of application domain operations - with the OS/runtime scheduling them - seems like a better division of responsibility.

[0]: https://news.ycombinator.com/item?id=42592224

[1]: https://hez2010.github.io/async-runtimes-benchmarks-2024/tak...