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.
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.
Every language I've used since then feels like it makes this issue needlessly complicated and implicit.
Closure is different of course. But not more functional than Haskell for example.
1. Everything is exposed as an API with little no insight to inner workings (black box)
2. Everything should be broken down into modules at a level where one person works on that module
3. He shows a video of his video editor, saying it supports multiple inputs (like two keyboards or two mice), then says no platform supports it, but if they ever do, it will work
4. Don't implement 'good enough apis'
I hope that anybody who has ever worked on software understands that there are virtues to doing exactly the opposite of what is described in each of these points. Even if you can make an argument for any of these, you would have to qualify them with so many exceptions that you would effectively negate the entire argument.
I spent a lot of evenings early in my career watching similar videos, hoping to find some magic bullet in how people better than me do what I do. People make a living doing this on the conference circuit. Maybe it is a fools errand to try to distill something as complex and situationally dependent as software into a video, but I'm having a hard time finding any major insights in all of the videos I watched.
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?
https://leanprover-community.github.io/mathlib-overview.html
If there were a lisp with optional static typing like typescript, it would seem to me to be completely possible to write macros that write types. In many cases it woudl do away with the need for generic types (and allow multiple competing syntaxes for dynamic types). Most interestingly it would allow you to write new generic forms instead of waiting for whatever the language designer gives you. It would also allow you access to types at runtime (which the typescript language designers took away).
Maybe people were telling me that lisp style macros were incompatible with hindley millner typing, but I still don't see how. The macros would just emit a hindley milmner subset.
What am I missing?
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.
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.
Personally, I wrote 200K lines of my B2B SaaS before agentic coding came around. With Sonnet 4 in Agent mode, I'd say I now write maybe 20% of the ongoing code from day to day, perhaps less. Interactive Sonnet in VS Code and GitHub Copilot Agents (autonomous agents running on GitHub's servers) do the other 80%. The more I document in Markdown, the higher that percentage becomes. I then carefully review and test.
The less code I write to solve a problem the happier I am.