Ask HN: What made you change your mind about a programming language/paradigm?

Types - I worked on an enterprise Java application for a few years and grew to hate them. What I actually hated was J2EE, but at the time I didn't know that. So I swung hard into "You don't need types", only to work for another two years on the world's worst Node.js app. I was young, I was naive, I didn't realize how bad things could get. We didn't have anybody that cared about testing, and I'd never been around testing, so I didn't either. It was a mess. More of a mess than J2EE ever was - we were constantly writing code on quicksand. So now I'm back to types for the most part. I think 2012-but-actually-2007 era Java was also part of my pain, and a few years ago I moved on to Go/C# and have been very happy.

Testing - as noted above, prior to my last two jobs I had never had any experience with people pragmatic/dogmatic about testing. At my first few, there just wasn't any testing, for better or worse. I worked on a team with a person that was fairly dogmatic about TDD, and I spent almost a year painstakingly focused on caring about testing. What I found was that focusing on 100% test coverage across each layer of your app is a fool's errand - you'll never get to where you think you're going. All the tests in the world are useless if you're bad at writing tests, which (at that job) we were. I've now moved onto "Just enough E2E/Integration tests" as a paradigm. If a PR contains _some_ testing, and that testing is focused on making sure units of logic work together, I feel much better. Prioritizing fast and easy response time to bugs, and making sure that all the test we contribute having meaning and add value, as opposed to just mindlessly boosting our stats has been a huge boon.

Cadillac languages with a bunch of stuff in the std lib take away a lot of fussy bike shedding problems. I like not having to worry about library selection in my first through fifth revisions.

I’m willing to put up with a lot more using a built in. It’s built in, a junior dev can be expected to cope with that. Adding dependencies has a cost. Usually the cost is bigger than realized at the time.

I don’t think that’s the problem. I wouldn’t use Python (especially 2.x), but I’d have no hesitation with using Common Lisp. It has lots of great features for programming in-the-large that Python simply lacks.

I started using python 3 with mypy, which provides (optional) static typing, and my gosh has it reduced the time I spend looking for stupid problems by orders of magnitude.

I got a somewhat direct comparison when I mypy-ified a small program where I used a lot of async and await (basically implementing own event loops and schedulers, it was interfacing very custom hardware that handled very different but interacting streams at once).

So basically I did it because I was tired of not noticing mixing up "foo()" and "await foo()", but then the static typing continued to catch a myriad of other, unrelated problems that would have ruined my day way late (and often obscurely) at runtime.

For small ("scripty") to moderate sized things, mypy absolutely recovered my faith in it.

I also completely switched to python 3 after being in python 2 unicode hell just once. There are very good reasons for python 3.

Way back in the 80s, I looked into Pascal and C, and was dead certain that Pascal would win out. Oops.

Many years later I was dragged into writing C because it's the de facto language for microcontrollers, and my assembly language programs were getting too big to manage. So I've finally gained an appreciation for C, even though I'm far from being a great C programmer yet.

I've often got two IDE's running on my desktop -- C for the microcontroller and Python for testing my embedded designs.