Speaking a language fluently is impressive, and speaking many languages is impressive, but ultimately, it’s not about the words. Talking is about communication. This applies as much to programming as to speaking. Switching to Spanish or Cantonese won’t help if you don’t know how to form and organize meaningful thoughts about a subject, and knowing all the syntax and semantics of C++ won’t help if you don’t know how to write organized, meaningful code. Learn the principles that apply in many languages, and the rest will follow. Don’t just learn a programming language. Learn to program.
Consider: computer science professors lecture about concepts and algorithms, then assign homework in languages they haven’t taught. Recruiters hire candidates who don’t know the languages they’ll use on the job. The very beginning of Atomic Object’s careers page says, “Atomic doesn’t ask that you know a certain language or use a certain process.” It’s not about language. It matters to professors that students grasp important ideas, not just how to write compilable code, and it matters to recruiters that new employees have the right values, technical skills, and experience, not the right list of languages.
Programming languages are still important. Picking the wrong language can make a program run too slowly, take too long to implement, or use too much memory. Some languages are easier to learn than others, some are easier to write in, some have better documentation, some are in higher demand, and some are simply more elegant.
But with all these considerations, why is it possible to get a computer science degree without mastering every nuance of at least one language? Why is it still possible to get a job without knowing more languages than the other candidates? It’s possible because picking up languages is the easy part. All the syntax, rules, and built-in functions are documented in books and online. The hard part is knowing what to do with that information.
Programming languages are built on a common conceptual foundation. Understanding this foundation makes it possible to write good code even in a new language. A programmer who remembers all the keywords and function names in every language but never learned how to organize them is not as valuable as one who can use abstraction and encapsulation, who understands time and memory tradeoffs and asymptotic complexity, and who knows ways to make code readable, robust, and maintainable.
Don’t become an expert in the intricacies of any particular language without also learning the ideas that apply universally. Some languages are widespread, some are trendy, and some even bring higher average salaries, but it’s not about picking up a popular language, or even a well-grounded, long-standing language. It’s about using the core concepts of programming to write good code no matter what the language.
There is always a tradeoff between different priorities, including performance, learning curve, and ease-of-use, so choosing and learning the languages that fit projects will always be crucial. Knowing just one language might work for a while, but there is no single best language, and even if there were, it wouldn’t last. The languages that look best now can become useless in ten years. If all goes well, computers and programming will keep advancing, and newer, better languages will supplant most of what we have now.
This tumult would be disastrous if holding a job depended on being a specialist in the right language. We’d have to guess the right one or start over again and again. Fortunately, programming skills are transferrable between languages. Computer science ideas carry over from one language to the next, and as you learn them, it gets easier to pick up new languages. Learning the broad theories of computing makes it possible to use many languages effectively.
Never feel bad for needing to look up how to iterate over an array or where to put commas and colons. Never let being new to a language make you feel like an incompetent programmer. Never feel limited to the languages you already know. Pursue projects and careers regardless of the languages they use, and always be willing and eager to try new languages. It’s not about the syntax; it’s about the concepts. Don’t just be a C++ programmer, a Lisp programmer, or a Ruby programmer. Be a good programmer.
Is that a real language in the photo?
Looks a bit like some kind of shorthand to my untutored eye.
:) I think the point was that the language doesn’t matter!
I think it could be handwritten thai script, but I am not sure at all.
Having started with Fortran and Cobol, and learning many, many languages since, I can relate to your term, “common conceptual foundation.” It’s all the same, but different. My core programming style has evolved with every language learned.
More importantly, “The hard part is knowing what to do with that information.” Well said. Miss this one and you miss everything. If the organization is not greatly enhanced by a series of information transformations, the project has failed.
I agree, to a point. Changing between most mainstream languages is simple, and they are similar enough that lessons learned pass easily between them.
However, some languages encourage entirely different approaches. If you learn a language like Haskell, it forces you to approach tasks differently. Similarly, to fully understand OOP, I strongly recommend learning one of the languages in the Smalltalk family. These kind of things make you look at software differently, even when using other languages.
” If you learn a language like Haskell”
People who write shallow, content-free articles like this rarely know of such things.
Nice post, it supports the thought I’ve been starting to have myself.
After the course i continued building a web GUI for an application we use at work and i’m starting to feel that even if i don’t just want to build web apps in JS, everything I’m learning while i do it will help me significantly in the future when i try out another language.
So, thank you for an interesting post :)
This is a strawman argument. The differences between programming languages is not primarily a matter of syntax.
Respect and appreciate the ideology. Good read :)
Nicely said. So true. I heard Steve McConnell make this point as “Code into the Language,” as I remember from 16 years ago. I took this to mean do your best to deliver software built around (evolving) principles and best practices, adapting these into whatever was in the contract. I was a FORTRAN forest ecologist by trade from 1975 until budget realignment in 1983, at which time I entered the manufacturing world. Retired now, I developed many real-time MES/plant floor applications for information management based on as much OO as I could shoehorn into SQL to/from Ladder Logic, the language of Automation Controllers (aka PLCs). (Ladder logic syntax is based on electrical motor and device control diagrams and has “rungs” and “inputs” and “outputs.”) Many principles and practices worked nicely there albeit with much resistance from real SQL and PLC programmers. Better understanding, great testing, much extensibility and a team Patent. Thanks, Steve! And thanks again, Clara, for the nicely said principle.
Yes and No. Rob’s comments were accurate. Last I counted I have used at least 23 languages (over 35 years); however, there is a major difference between 4tg gen. languages and OO, and to truly use OO you need to understand abstraction, patterns, replication, and what the ORB (Object Request Broker) is doing. These days I manage projects – Many projects. Would I hire a B.Science graduate who has never mastered a language over a technical school graduate who can sit at a desk and code from day one? No – That would be bad business. Welcome to reality.
Comments are closed.