rkrzr

This is a good post. AI has changed the programming language trade-offs and, as someone running a company that uses both Haskell and Python, I hope that Haskell can adapt to this new era.

I would like to add one additional observation, since we have been using both Haskell and Python in production for a long time:

Haskell excels at platform work, while Python excels at product work.

Our infrastructure teams work in Haskell (and also Rust nowadays), while our product teams work in Python. This gives us the best of both worlds (in my opinion): fast and rock-solid infrastructure on the platform side, and fast development speed and quick iteration cycles on the product side.

This setup has worked well for years for us, but it remains to be seen how and if this is going to change as well in the new AI era.

Cells may generate their own electrical signals through microscopic membrane motions. Researchers show that active molecular processes can create voltage spikes similar to those used by neurons. These signals could help drive ion transport and explain key biological functions. The work may also guide the design of intelligent, bio-inspired materials.

Lots of interesting points here, e.g.

> We should distinguish between infrastructure code and application code. Often, the two areas need different languages, tools, and techniques. Sometimes, that’s the case even when we use the same language for both infrastructure and applications. The role of static typing should be increased.

The extra emissions come from several factors:

- cows need a lot of land. If you used that land for e.g. efficient crops instead (and if people ate that instead of all that beef) you would free up a lot of land which you could use for other things (say, plant trees for example)

- cows need to eat a lot of feed to produce 1 calorie of beef. It is much more efficient to produce 1 calorie of vegetables and let people eat those vegetables directly instead of having it go through a cow first

- cows emit a lot of methane

- deforestation to produce more feed (like e.g. soy) is indeed also a factor

No. The SQLite bytecode is much higher-level than the instruction set of a CPU.

You can learn the lambda calculus in a few hours.

If you read just the first page of the linked paper and work through a few examples, you will likely already know enough about it to read the book. It's really just like equational reasoning in mathematics.

I suspect that the actual cost to rebuild the bridge will be far higher than that. Initial estimates of large public works projects are virtually always too low, and actual costs can easily be 5-10 times higher.

There is a great book about this phenomenon (and how to avoid it) by Brent Flyvbjerg called "How Big Things Get Done".

I am really glad to see that deterministic simulation testing is getting more coverage on HN lately. It feels like the next step up from property-based testing and (coverage-based) fuzzing.

We have gotten a lot of good use out of property-based testing in Haskell (using QuickCheck) since it is easy to set up and can cover a lot of ground for which you would otherwise have to write a lot of testing code.

I think that techniques like this have the potential to dramatically change software for the better if more of our industry starts adopting them (and it feels as if this is happening more and more!).

Thank you for all the great products that you have created! Your vision on infrastructure has always been inspiring to me and you are one of the few engineers who has truly moved the field as a whole forward.