Use dynamic languages

August 12th, 2009 § 4 comments

Ladies and gentlemen of the class of 2009:

Use dynamic languages.

If I could offer you only one tip for your future programming careers, dynamic languages would be it. The long term benefits on dynamic languages have been proved by thousands upon thousands of programmers, whereas the rest of my advice has no basis more reliable than my own admittedly limited experience.

I will dispense this advice now.

Enjoy the power and expressiveness of homoiconic languages. Or forget they exist. You will never really understand the power and expressiveness of homoiconic languages until you have spent forty hours straight debugging some heisenbug. But trust me, twenty years from now, you’ll look back at all the code you have written and wish you had used a homoiconic language. You non-homoiconic code is elegant, but not that elegant.

Don’t worry about the LOC of your programs. Or worry, but know that measuring lines of code is as effective as trying to count parenthesis in Lisp. The real troubles in your programming career will come from metrics that never crossed your mind, like the number of type declarations in your classes, the kind that will make your curse the compiler for its pretense safe type system at 4am in some caffeine-driven code marathon.

Write one line of code everyday that scares other programmers.

Comment your code.

Be careful with other people’s code. Don’t put with people who are not careful to keep your shared code as easily maintainable as when you wrote it.

Don’t use TODO, HACK or FIXME comments in your code.

Don’t waste time on programming languages wars. Sometimes your favorite language is ahead on the TIOBE index, sometimes it’s not. The race for delivering the code is long, in the end, only your lines count.

Remember the forks and patches your code receives. Forget the innuendo about its quality. If you succeed in doing this, tell me how.

Throw away obsolete documentation. Keep old beautiful code.


Don’t feel guilt if you still haven’t learned Assembly. The best programmers I know only bothered to learn it when they really needed it. Some of the most incredible programmers I know make a point of not learning it.

Drink coffee moderately. Be kind to your hands. You’ll miss them when RSI comes knocking.

Maybe you’ll write a compiler, maybe you won’t. Maybe will write a Linux kernel driver, maybe you won’t. Maybe you’ll write artificial intelligence systems in ML, maybe you won’t. Whatever you do, remember any of those accomplishments is as relevant as discussing whether Emacs is better than Vi.

Enjoy your test suites. Use them in whatever way you need. Don’t be afraid of what people say about TDD or of what people think of BDD. Sanity when developing is the greatest tool you’ll ever have.

Celebrate every successful build even if you are alone in the datacenter and nobody can share your happiness.

Write a Makefile at least once, even if you have never to bother with writing one again.

Don’t read Microsoft’s technological magazines, they will only make you despair of seeing beautiful code.

Get to know the big names in computing. You will miss knowing what Alan Turing and Donald Knuth did some day. Be kind to your fellow programmers. In the future, they will be the ones who will help you find the proper libraries when you need.

Understand that languages come and go, but that there are a few you should always keep yourself proficient in. Work hard to understand the features of each language you come across because, the older you get in your career, the more you will need to understand the purpose of certain features and techniques.

Write a couple programs in C, but dump the languages before it makes you believe manual control of memory is good. Write a couple programs in Haskell, but dump the languages before you come to believe that cryptic error messages are tolerable. And remember to learn a new language now and then.

Accept certain inalienable truths: market languages like Java and C# suck, dynamic typing is better than static typing, and your programming career will end someday. When when it does, you will fantasize that when you were a hot shot programmer, market languages were not that bad, that static typing was safer, and that your career would never end.

Respect those whose careers have ended because they contributed for you to be in the place you are now.

Don’t expect anyone to teach you to be a better programmer. Maybe you will have a mentor. Maybe you have access to better manuals. But you never know when either one might run out.

Collect a reusable code library but don’t add too much to it or you will find, just when you need it, that most of the code there is too terrible to use.

Be careful whose algorithms you use, but be patient with those who created them. Algorithms are like pets. Everybody thinks theirs are trustable, clean and fast but the truth is always different from that and they rarely are worthy the bytecode they generate.

But trust me on the dynamic languages.

Best enjoyed while listening to “Wear Sunscreen”, of which, I hope you notice, this text is an obvious parody.

§ 4 Responses to Use dynamic languages"

  • Sean says:

    Just stumbled on this sniffing out Java tips.. This is being bookmarked and sent to every coder I know that was foolish enough to give me their email address. ^_^

  • Avol says:

    The main ones for me are QB, freebasic, & C. I’ve been manliy programming C on linux lately. I know bits & pieces of many other ones as well. Essentially, the programming language is fairly irrelavent, in my opinion. Programming concepts & problem solving skills carry over to just about all languages and make it easy to pick up new ones.I’m not an aspiring programmer so I don’t really go deep into languages & computer science, just write basic programs that work for me. How’s computer engineering working out for you? I am studying electric engineering myself.

  • AFAICT you’ve covered all the bases with this answer!

  • Thanks for the info! I didn’t even think about sanders when considering brushless motors in corded tools. With these types of tools, torque is not exactly a concern, but the advantages in size and lower maintenance is definitely noted. It also makes sense that continuous-run corded tools might benefit most from brushless motors.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Use dynamic languages at Reflective Surface.