For all my obsession with powerful and flexible programming languages, and believe that programming languages are tools for thought, in the end, if you want to be productive in the real world, here and now, instead of spending all your time in a daydream of a better world where Lisp won, either bitter and resentful or mostly irrelevant and useless, or doing shockingly productive work in a field that ultimately won't produce anything that's actually useful to you or anyone else, you need to use what is practically most effective, not what "would be the most effective" if it had the same community size/documentation/industry support/number of libraries/etc.
Because ultimately, it doesn't matter how productive your language is compared to Blub on a one to one basis implementing the same programs, if a Blub user can quickly and easily access the crystallized work of hundreds of thousands of people over multiple decades to get everything they want to do done, whereas you have to rebuild everything from scratch, or with the help of a poorly documented library made by one dude that was actively improved for a year or two. No language, not even our lord and savior Common Lisp, is so overwhelmingly productive that it can overcome that difference in multiple orders of magnitude of developer time and effort, nor the difference in the amount of material resources (for things like build servers and infrastructure). And that's just looking at things from a quantitative perspective: a more active community, by having more people, doesn't just have more developer hours and more money to throw at things. It also has more perspectives, more water molecules to flood-fill the problem space. Yes, the language they're working in will limit the ideas they can think of and the areas of the problem space they can even touch, but even still, I think the difference is just gigantic; and that linguistic limit is not as big as you think: there are pure functional and reactive functional methods and libraries for things like Java and C# for chrissake!
You might argue that leveraging existing libraries and frameworks for everything, to get what you want done as fast as possible, is "not real engineering," since you're not taking the classic Structure and Interpretation of Computer Programs route of building your code from scratch, from the ground up, out of small modules that you fit together into larger and larger modules until you create a full program that you understand from top to bottom. But I'd argue that that's only good if you're explicitly setting out to learn, or to write handmade code for fun. If you just want a tool or app to work, or you have an idea and are more interested in executing that idea and iterating on it, that hair-shirt style of programming shouldn't be forced on you. And if you really want to go that route, than yeah you'd definitely be 100% better of using Lisp, because it will make you more productive in a fair fight with another language.
That's why, moving forward, now that Python's build and dependency management system has been fixed thanks to UV, and it has dataclasses and a type system that can be integrated into my editor, and is starting to get serious performance improvements and a JIT, I think I'm probably going to be writing most of my hobby work going forward in Python. It's a good enough language now, and you can't beat import antigravity.
