If a man has a story to tell, he doesn’t ask himself, “What language should I tell this in?” He uses the language that he has, and works from there. Just as the man starts with an idea for a story, a programmer must start with an idea for a program.
Once the idea is there, every program — even a simple one — consists of pieces. A piece to talk over the network. A piece to draw to the screen. A piece to do whatever… The internet is presently littered with great programming languages and great open-source code libraries. The best code is code that has already been written, so scour the internet for languages and libraries that best provide the pieces you need.
Most programmers have very strong opinions about languagues:
“Oh, but X is so much more expressive than Y!”
“The safety that E provides is crucial for a project this size!”
For small programs that are limited to a specific domain, one language can have a definite edge over all the others, yet programs that reach a certain stage of maturity (i.e. solid cross-platform support, easy extensibility, localization, graceful error handling, scalability, etc.) look very similar to each other under-the-hood — regardless of language. In other words, you will eventually have to pay the piper. A language that helps you in the beginning can hinder you in the end, and vice-versa. I’m not saying write your next program in brainfuck. I am saying that any general-purpose language with an active community around it can be used to write a great program.
A few caveats about choosing languages and libraries:
Keep it open source. Troubleshooting interactions with black-boxed proprietary code is a miserable waste of time. It is like driving blind. Don’t do it.
Don’t compromise on great documentation. If I had to choose between a so-so language with great documentation or a great language with so-so documentation, I would choose the former. Good documentation lets you program with confidence. Poor documentation wastes your time.
Strive for cross-platform support. Every platform you support provides an opportunity for user feedback, and user feedback is pure gold! It is quality assurance on someone else’s dime. It can also be a perspective on your program from a completely different point of view — the kind of insight you would never have by yourself (even with all of the time and all of the mind-expanding drugs in the world).
Cross-platform support also has a way of bringing very subtle bugs to the surface. Look at these bugs as an opportunity, and fix them!
After the tools have been chosen, it’s time to haul ass to the finish line. Finishing is very important — even if the program is a little “rough.” If you never finish a program, it is a tell-tale sign that you would be happier doing something else with your life.
Stan Lee once said:
“Great ideas are a dime-a-dozen. It’s all in the execution!”
The truth is that even after you “finish,” you are never really finished. There is always room for improvement. Look at what GNU and Linux did to the old proprietary Unixes, what Facebook did to MySpace, or what Google did to Yahoo! In each case, organizations that were leading with years of work and loads of cash were outdone by small teams of programmers persistently pursuing quality.
“Where should I start?”
Write a program. Finish it. Keep improving it. Everything else can be Googled.