deterministic

Don’t listen to the BS garbage coming from the tech bros. They have zero clue about how Ai will ultimately shape the future.

Not my experience at all. I have added multi-threading to very large C++ applications safely. One of them has been used in production for 5+ years without a single bug. The trick is to do it very carefully and use automatic tools (Valgrind etc.) to verify the code.

> the spec must be human readable

Usually I would agree with you but when porting code the source code is the spec.

And they’re 100% right about the vast majority of people.

All it takes to understand this is a little knowledge of history and psychology.

Progress has always been driven by a tiny minority who refuse to be amoral sheep. Without them, we’d still be living in caves, bashing each other over the head with rocks.

It’s unbelievable that some of Europe’s biggest banks still put all their eggs in one basket when they know things can break without warning. And with the obvious decline in US political reliability, depending 100% on US infrastructure is a huge mistake. If I were the CEO of one of those banks, I’d fire the CTO for sheer incompetence.

So humans care more about belonging to a group than discovering the truth, and use reasoning to justify beliefs they've already adopted.

Nothing controversial about that to me. I see people operate like that every single day. And history is a looooong list of people doing exactly that.

Because, in my experience, most middle managers don't know how to manage people effectively. Instead of focusing on outcomes, they focus on activity.

It's like measuring how fast the wheels are spinning rather than how far the car is actually moving.

The problem is not the other languages. The problem is Haskell not fully embracing dependent types.

I've managed everything from large-scale software projects to small personal projects using a simple, prioritized to-do list. Sometimes in a .txt file, sometimes in Excel. The format really doesn't matter.

It works beautifully, and I've never felt the need for anything more complicated.

I would love to actually try this but the black font on a dark background makes it unreadable.

There is no such thing as objective taste or an objective quality bar.

What you like will not be what I like.

I absolutely love this, especially the detailed explanation of how it was created using Opus 5.5.

I wish there were more posts like this on HN showcasing the creative possibilities of AI.

I used to be a big Haskell fan and had a lot of fun writing and using monads. And I agree that once you get them, the basic idea is quite simple. I’ve even used monads to prove a small compiler correct in Lean.

But in practice, I think monads are a poor tool for large-scale software development. I spent a long time trying to build a large game in Haskell and eventually gave up out of frustration with the complexity they introduced.

Monads make sense as a way to manage effects in pure languages like Haskell/Lean/Idris/Agda. But outside that context, I don’t think the additional abstraction is worth the cost.

Understanding how monads work is one thing. Understanding why they’re needed in the first place, and when they’re not, is another.

No, monads are largely a solution to problems introduced by pure functional programming, problems that impure languages don’t have in the first place.

I like monads as a concept, but in practice I find them frustrating and unnecessarily complicated. I worked on a large game written in Haskell and eventually gave up because dealing with monads made development so cumbersome.

I love the idea, but for real-world projects I’d rather avoid the complexity.

My main problem with Haskell is that it never fully embraced dependent types. Instead, it kept adding one type system extension after another, making the language unnecessarily complicated.

I used to be a big Haskell fan, until I discovered languages like Lean, Agda, and Idris 2 and realized how much cleaner and more coherent the whole thing could be with dependent types built in from the start.

I highly recommend Haskell fans explore Lean/Agda/Idris. They make Haskell feel like a pile of spaghetti by comparison.

I've long suspected that writing your own game engine can give you much better performance than using something like Unity. And with AI, it's now a lot more doable.

Focus on verifying, testing, and quality-assuring the team's output. Nothing else.

That’s true today, was true a year ago, and has always been true.

Judge the quality of the results, not the tools used to produce them. Whether those tools involve AI or not is irrelevant.

I develop indie games for fun in my spare time, but I would never bet my livelihood on doing it full-time.

We hear about the tiny fraction who manage to make a decent living from their games, but rarely about the vast majority who don't. It's classic survivorship bias.

And it's hardly unique to indie games. The same is true across pretty much every creative industry: books, movies, music, art, and so on.

Not my experience at all (30+ years of professional development experience). I love that I can now take on much bigger projects than would have been possible just a year ago.

At work, I’ve just started a large, complex project that we wouldn’t even have considered practical before LLMs.

I absolutely love learning new things and pushing myself far beyond what I previously thought was possible. And I love that I’m no longer limited by how fast I can type.

My advice is to embrace the change and see it as an opportunity to expand your capabilities. You now have the chance to build far more cool stuff in your lifetime than you could ever have imagined before.

I think this just shows that language syntax doesn’t matter any more in the age of AI. What does matter is the language performance.

Claude is brilliant at writing C++ so I get the performance I want with zero hassle and see no reason to switch to a “better” language.

If you don't use a formal tool like Lean to define your spec, then your C++, Rust, or other implementation effectively becomes the spec.

So “you might get the spec wrong” applies either way. The big difference is that with Lean, you can prove that the implementation matches the spec. With mainstream programming languages, you can't.

Yes really. Do you have any examples yourself you would like to show?

Share the concrete problems you have with LLMs and we might be able to help you out.

My experience as well. Opus 5.5 is really good at matching the existing coding style. I often look at code and think I wrote it, only to realize it was written by Opus.

The trick is to give it enough guidance about the style you prefer.

The job of a software engineer has always been to turn a real-world idea or problem into a precise specification a computer can execute. That specification used to be assembler, then higher-level languages like C and Python. Now it might be detailed Markdown files that AI turns into code.

So our understanding moves from the C/Python level to the Markdown specification level. We still need to understand exactly what we're building and why.

The hard part was never translating the spec into machine code. The hard part is defining the right spec. That is still the job of the software engineer.

I am soooo tired of that quote. Especially because it’s BS. In 30+ years in the industry, I’ve never seen it happen. Not once. And I’ve never seen anyone demonstrate it convincingly on a real, large-scale commercial project either.

Jaw droppingly excellent work. Thanks!

I’m so tired of the “X written in Rust” posts on HN. Seriously, who cares what language you used? Especially nowadays, when LLMs are writing much of the code anyway.

What an excellent read. This is why I read HN!

This post doesn’t really add anything new. These points about AI and critical thinking have been made many times before.