Lost me at dynamic languages. Don't build anything of any significance in dynamic languages! ;)
Some good points. Laughed at TDD is a cult. I mean a lot of software orgs/cultures are cultish (Agile, Scrum, whatnot). At work I often feel I'm part of a cult.
> Don't build anything of any significance in dynamic languages!
Posted on a significant website built in a dynamic language.
I tend to disagree. Static typing can catch some bugs, but most serious errors are not type errors, and the common situation where the type system disallows just enough invalid states for developers to get complacent is the worst of both worlds.
On the contrary, I find "The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me." is exactly my sentiment too, with a caveat. I really like gradual typing, like python has. And not like ruby has (where it's either RBS files and it's tucked away, or it's sorbet and it's weird).
The worst code base I had to work in by far was a Python code base. Extremely difficult to refactor. Many bugs that were completely avoidable with static typing. I think maybe more modern Python is a little bit better but wouldn't be my choice for large projects. It's not just about correctness. It's also about performance. That code was so slow and that impacted our business.
Refactoring is a young mans game. I either nuke it and start over or treat it as a black box.
You can just as easily take a static language dynamic - in userland.
I've interop'd with JS from Haskell and you can just go full dynamic property access. And gradually add phantom typed APIs around it.
Debugging Haskell and JS in the same stack? You kids are brave. And/or I'm a coward and a simpleton.
I debug in ghci mostly
console.log also still works fine
One rebuttal to that is that with the benefit of hindsight, to a first approximation zero percent of the code I've written in my career turned out to be "of any significance" really.
Same. That line about "your legacy is your family and friends" hit hard.
I've been coding professionally for >30 years. I don't think any of my code has survived 5 years in production.
I don't think code quality affected that at all - I know the really, really, shitty code I wrote when learning OOP in the 90's survived for a looong time, while the amazing code I wrote for a startup 2018-2021 died with it.
One of the projects I'm most proud of is still running ten years later, and has processed over a billion AUD through it in that time, with very minimal maintenance. I recently consulted on it, and sure enough it's still ticking along nicely! The code is honestly quite good too, even if it is PHP (though in a very nice microframework we wrote on top of Silex: removed all magic that a lot of these systems relied on. No annotations!)
I haven't doing this forever (only 10+ years) but surprisingly I think a majority of what I've written is still running. Probably a fair bit will continue to run for a while yet too I think (again, surprising for CRUD web apps).
Most code I wrote over my career got pretty decent use and produced value for customers. Some was used by millions of people. What I work on today is used by thousands. It's important that it is of reasonable quality with less bugs, decent performance, functionality users are looking for etc.
A lot of code makes a difference but I guess there's a lot that doesn't?
Please elaborate
I'd guess, on average, code I've written has a half-life of maybe 3 or 4 years. There's pretty much none of my code (with a few surprising exceptions) that's still been running or in production anywhere for more than 8 or 10 years.
At the time, a lot of it felt "important" and "significant". And some of it probably was at the time, to the businesses I wrote it for. But whether I sweated blood and tears to craft the most elegant and efficient software I was capable of, or I phoned it in and just copy/pasted Stack Overflow answers together until I met some interpretations of a requirement to be able to leave the office on time - really made no difference.
I've been pondering lately, thinking about GenAI and vibe coding, with the very real risk of creating completely unmaintainable codebases - whether that matters, if the code is likely to be retired or rewritten in 3-4 years anyway? My current gig is on to the 4th rewrite of it's web/mobile app backend platform in 15 years, which started out as a Groovy on Grails app, which got rewritten in Java, then rewritten again in Java, and now it's being rewritten in Python. Each rewrite had fairly good reasons at the time, but a huge amount of code here gets thrown away every 4 years or so - which looking back makes me seriously question whether any of it was "of any significance". To be honest, the 2026 Python code really isn't doing anything notably different or more complex than the Perl and JavaScript code I was writing in 1996 - web work is CRUD apps all the way down.
As a person who started in a dynamic language (PHP; don't laugh, it's actually really good for web dev) and worked in an infrastructure team which had to do a lot of refactoring... I can't agree with the sentiment either. Dynamic languages _look_ good, but lightly typed languages like Go strike a much better balance in my opinion
TDD is a cult. But knowing your pre-conditions an post-conditions for your isolated parts of your code is important. I think all your AI codegen will work better with this.
The entire AI ball of wax is built on python (dynamically typed) - or at least a large part of it. It probably needs to move to rust to save on power and compute cost.
The heavy lifting of AI is done by GPUs that are not running Python. But yes, a lot of orchestration and glue work is done by Python. Python can be a decent glue language and it has its place. But if the core/high performance logic of inference and training was written in Python then we wouldn't have today's AI. I imagine there are other languages in the mix.
Python is also the choice of non-programmers for simple work. Nothing wrong with that. But I wouldn't want e.g. my car's ABS system to be programmed in Python (or my browser or my OS or many other examples).
Your car's ABS is probably programmed in something more error-prone than Python, like C or the assembly language of whatever microcontroller runs it.
This gets more terrifying if you've ever experienced spurious ABS activation. It's the third scariest thing that's happened to me in a vehicle.
> But knowing your pre-conditions an post-conditions for your isolated parts of your code is important.
Design-by-Contract[0] is a formalization of this concept and well worth considering when working in code using mutable types. In addition to pre/post conditions, DbC also reifies class invariants (which transcend method definitions).
0 - https://en.wikipedia.org/wiki/Design_by_contract
A lot of startups are cults. Tesla maybe the final form of a culted startup where the stock owners don't care about anything anymore.
That said, the people who change companies aren't the ones that believe that management ever had the best ideas, or are able to push back on the cult thinking with clarity. Unfortunately, though, it's not necessarily evidence that wins arguments, it's charisma, which is how the cult is started in the first place.