Marco Arment’s post about being “addicted to PHP” talked about fear involved in switching languages:
Whichever language I choose to replace PHP will have its own problems that will take me years to master, but by the time I know whether I chose the “right” language, I’ll have invested far too much time in it to practically switch any meaningfully sized project to another language: exactly the situation I’m in now with PHP.
The fear of making the “wrong” choice actually makes the familiar, mastered PHP more attractive. That’s the problem Jeff’s identifying, and it’s very real. If you can get PHP programmers to agree that they need to stop using it, the first question that comes up is what to use instead, and they’re met with a barrage of difficult choices and wildly different opinions and recommendations.
I’d like to respond to that by saying “it’s not that hard.” More specifically, I think that these kinds of fears are blown out of proportion out of some misguided drive for perfection.
Web apps are not driven by perfection; this isn’t kernel code that has to be as optimized as possible. It’s not an electronic voting machine where governmental inspectors are going to be poring over each line of code to check it for legitimacy. No, web apps are driven by making things that work. To make things that work in a given language, you don’t have to be a “master” of that language. You don’t have to know the intricacies of how MRO works in Python to write a web app. If you want to write SQLAlchemy? Sure, then knowing how MRO works might be useful to write the best code for something that’s going to be used by tons of people – but most things you write aren’t going to be SQLAlchemy.
Essentially, people like Marco are letting the perfect become the enemy of the good. They’re so focused on “mastering such-and-such language” that they don’t realize that mastery isn’t required to reap the benefits of choosing a different language. You don’t have to be as respected as Guido in the Python community to create good things with Python. Heck, you don’t even have to follow PEP8 or any of the other “pythonic” idioms to create good things with Python. Sure, another Python coder looking at your code will think you’re a bit weird, but weird code is not the same as broken code. Weird code can be refactored as desired as you learn more about the language and what’s considered standard in the Python ecosystem.
So the next time you go to start a personal project, Marco, I’d suggest this: try stepping outside of the comfort zone, trying something new, and not worrying about it being perfect. If you “pick wrong” it’s not actually that bad; you can make a different choice with the next project. The only reason it seems like a huge investment is because your goalpost is set unreasonably high.