Sunday, March 18, 2007
5 ways to not pick a programming language
Performance is usually a big issue when people are looking at a language. They always want to see numbers in benchmarks compared to others. It's great fun but on the end it really doesn't matter that much. Let's see how much an extra server costs compared to an extra employee. That should be a one time investment of like $3000. The average salary of a developer is like ~$75,000 worldwide. Still want to use assembly now for your next project? Don't think so, pick a language which delivers great productivity to your team.2. It doesn't have feature X
Of course it has no such feature, there is no single language which has all features you need else you wouldn't have to program. When it comes down to features there are always languages who have a little bit more to offer over the other. Ask yourself how much time it would take to implement them in others and see what libraries the community already made for them.
3. My boss/client wants language X
Your boss wants big texts in blink tags too, but obviously you don't make that for him (unless you have absolutely no principles). Always try and tell them why your solution is more cost effective or has a higher ROI (they love those terms). People who have no clue about programming are always trying to outsmart you. Be prepared and convince them, thats what they hire you for.4. But MySpace uses it too!
There are always companies who have successfully deployed applications in a certain language. Doesn't mean you can't do better. Who would have thought ruby could be usefull for web applications? Before DHH not many people. If you seriously think your application can be written in Haskell, go for it and prove the community it can be done.
The fact that some site using technology X is slow doesn't mean it can't scale. Even the fact that digg.com seems to have scalability problems doesn't mean it can't scale. A properly designed application with share nothing architecture will be able to scale to extreme levels. If you don't know how to design such architecture it is not a big deal. Solve scalability problems when they arise, don't try and solve them before they happen. Premature optimization is the root of all evil.
Subscribe to Posts [Atom]