deterministic

Assembly is not that hard. I taught myself to program Z80 assembly on the ZX Spectrum when I was 11 and wrote a small platform game with it.

You are doing it wrong.

I dump highly complex modified code straight into production and haven't had a single production bug for 6+ years.

The reason why is automatic tests.

And the result is that most new open source languages (and commercial companies) use LLVM instead of GCC as the backend => way more engineering resources are dedicated to LLVM.

90% of my code is auto generated using custom code generation tools. No AI needed.

I have never (in my 30+ years career) worked for a company that required formal code reviews. And yet have managed to deliver a ton of commercially successful software. I am pretty sure that adding a review step would have slowed me down tremendously. Without adding any commercial value.

However I can imagine that code reviews would work well for inexperienced developers being reviewed by more experienced developers?

It’s rare to read an article where I agree 100% with everything written.

Bravo!

I have noticed that most developers prefer to spend a month typing code without having to think hard, instead of thinking hard for a bit and then solving the problem in a day.

I don’t get it. It’s very strange.

Lines of code is not a useful metric for anything. Especially not productivity.

The less code I write to solve a problem the happier I am.

I am still way more productive using customer code generators than using AI.

However AI’s are great for quickly learning how to use external tools/libraries (like JasperReports) and for quickly writing parser functions.

It is like any other tool: good for some things bad for others.

C++ developer here (30+ years). C++ is really missing support for sum types. The Haskell JSON example shows how useful it would be to have native support for it. Yes you can build your own but it’s pages of boiler plate code.

All code is data. Many languages (Haskell for example) can directly manipulate code as data (macros). The unique thing about lisp is that the code is represented as a car/cons list. Other languages could do the same when writing macros. However most have chosen not to.

Lisp doesn’t have a monopoly on “data”. And most Lisps are not functional (setq/setf).

Closure is different of course. But not more functional than Haskell for example.

> Everything is exposed as an API with little no insight to inner workings

This is how I build large scale biz software (30+ years of experience). And I have never seen a case where it wasn't a good idea.

For example, the largest software system in the world (the internet) operate this way.

However I am always open to learn something new?

Maybe worth checking out if you want a formal (as in machine checkable) definition of reals:

https://leanprover-community.github.io/mathlib-overview.html

You are missing nothing. Haskell has two different macro systems: typed and untyped.

This nowadays sounds more like a product announcement than a joke.

Coding tests (if done correctly) is basically defining the behaviour of a black box API using running code. So it is easy to imagine an AI generating the black box from the tests/behaviour spec.

The largest successful software system we have is the internet.

So perhaps we should ask ourselves: What can we learn from the internet architecture?

And no that does not automatically mean micro-services. The core idea of the internet is to agree on API's (protocols like HTTP) and leave the rest as implementation details. You can do the same with modules, libraries, classes, files etc.

The key take away is to embed software developers everywhere in the development process.

Which makes perfect sense. Software is about automating things. And the more you automate, the faster you go.

A bit like how Jane Street operates I think.

You can think of any software (or hardware) as a state that transitions to a new state when an event happens.

State0 -event0-> State1 -event1-> State2 etc.

In other words, it's all a state machine.

Good. The "food" they were producing was anything but healthy.

I highly recommend writing your own Lisp interpreter in any language followed by writing a Lisp compiler using your own interpreted Lisp (compiling to C for example).

It is great fun!

Here is a good place to start:

https://adam.math.hhu.de/#/g/leanprover-community/nng4

Customer code generators have made me 10x more productive (generating 90% of a typical client/server biz application from a declarative spec).

AI's so far haven't been able to beat that.

However I have found AI's to be great when working with unfamiliar tools. Where the effort involve in reading the docs etc. far outweigh the benefits. In my case using AI's to generate JasperReports .jrxml files made me more productive.

In my experience PhD's are not 10x productive. Quite the opposite actually. Too much theory and not much practicality. The only two developers that my company has fired for (basically) incompetency were PhD's in Computer Science. They couldn't deliver practical real code.

Yep agree. Good point!

Companies that use AI interviewer are either dodgy or dysfunctional.

The smartest thing you can do is to avoid them.

That is not my experience at all (30+ years here working in different countries).

I have only experienced this kind of environment once. And the fix was to quit and join a functional company instead.

And only write tests against the API you are responsible for.

Never let tests depend on implementation details.

1. Write exhaustive automatic tests against the API you are responsible for.

2. Don't write tests for anything else.

If you are responsible for implementing a server/service, the API is the protocol for the server/service. If you are responsible for implementing a module/library, the API is the public interface to your module/library.

The tests are basically a specification for how any implementation of the API needs to behave. So you can give the tests to another developer, who has never seen your implementation, and they should be able to re-implement everything based on your tests.

Nope. Performance really matters. Even today. And even for web applications! Just remember how you feel using a slow sluggish website vs. a snappy fast one. It's night and day.