Learn programming, not a language. But know your language(s).

There are discussions about focusing on programming, not on a particular programming language. Choose a language you enjoy and exercise general topics that can be implemented in any programming language. Later, when you’ll need a new language, you’ll already have the knowledge of programming. And switching to a new language is easy.

It’s true, you can switch to new languages, have some patience to get to know them, and you will soon be pretty used to the syntax. It can take some time to know what a language is capable of, but being able to write more than a few lines of code won’t take an eternity.

And you can stop here. We are done. Nothing new, nothing special. The most that the lines above could give is another confirmation from another person, a boost of self-confidence if I want to use big words.

If you got to this line, maybe you thought I have more to say, it couldn’t have been just that. I think what follows is more of talking to myself, thinking out loud, because again, it’s not something new; it’s just that I don’t read often about a specific flavor of learning programming languages.

It can be critical to know, besides general programming, the language that you are using. To really know it. You can solve nice problems with any language. Until the context is not nice. Until the context kicks you in the back without knowing what hit you. It’s all about context. If correctness, performance, scalability, or ease of maintenance and extension do not matter, there’s no point to focus on them. Implement your business requirements and you’re good. But when they do matter, knowing to approach them includes knowing your language.

And I want to consider two aspects.

What a language can give

Many day-to-day tasks that you implement can leverage what your language and its standard library offers. Concepts that are already implemented better than you could do. Functions that have better semantic than yours. Of course, it’s all about the context. Don’t use something because you can, do it because it makes a difference.

Using what a language gives you can help you reduce code, bad code, testing, risks, time, money. The language’s tools guarantee that, if used correctly, they will respect your intent.

Knowing what a language can give can come from years of experience and/or from constantly reading about it and trying to understand its details.

What a language can hide

C++ is difficult, cumbersome, ugly, dangerous, weird. It has undefined behavior, implementation-defined behavior, noexcept, const correctness, too many ways of creating a thread, move semantics that sometimes is bad to use because there is copy elision, universal references that can but must not be used with move on a const object, and… what does not have C++ that can be compiled, executed, is working correctly, but… it’s crashing at some point? Or “it might” crash, depending on how you’re using it. I’m exaggerating just to make a point: C++ is difficult. I would be happy if someone would write a comment with what they find difficult in C++.

It takes a lot of time and practice and mistakes and reviews to get to know (parts of) what C++ is hiding. But it’s all about context: If C++ is not good for your project, there are alternatives. C++ has its weird and unsafe way of offering power. But it’s offering all of it.

 

Combined with general programming, knowing your language gives you the next level of power. With context in mind, please learn your language. I used C++ as an example, not to promote or blame it.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.