We often get threads asking if one language is "easier" then another, if a language makes programmers lazy, or if a language has too much abstraction. By and large the answers to these questions are no. However, the benefits they provide may be lost on an individual if the underlying concepts are not understood.

Why?

Abstraction is there for us, the programmers. Gone are the days where we would need to punch holes into a card and then insert it into a machine. And unless your job calls for it, spending the majority of your day neck deep in assembly code isn't a common occurrence either. Each successive generation of programming languages adds a layer of abstraction. Consider the following sequence [over a large period of time]:

Punch Cards[Machine Code]->Assembly Code->C

The level of tedium is significantly decreased from the move of one language/generation to another. You will also notice a transition from pure sequential directions to a structural layout. Fast forward to today and we have a variety of paradigms to work with all of which are based off of or were spun off previously existing ones.



Several of today's "popular" languages are part of the third generation. Even within this one group there are radical differences, in terms of level of abstraction, available to the programmer.

For example, if you've done most of your work with say Java or C# you haven't had to do any explicit memory management. Is that bad? Some might say yes [language fanboys, but that is out of the scope of this post]. I am under the notion that if you understand the benefits that a particular feature/abstraction is offering, then by all means use it. People get into trouble when they move from, say, Java->C++ and try to code the same way they have been. Which brings up the whole other topic of treating each language as a tool for specific needs, etc... but I won't get into that today.

What does 'do it the hard way, at least once' mean?

If you have the opportunity, I encourage you to program in something "lower" then what you use the most. The best choice would be a language that doesn't have a certain feature or abstraction that you are accustomed to. A quick example within the third generation of languages: Java/C# -> C++/C. Especially play around with memory management. If it seems I'm hammering this point hard, it's because I've seen people have gross misunderstandings about memory, it's allocation/de-allocation, and ultimately its affect on the program. Considering that quite a few mission critical systems are written in C/C++, this is truly a life or death situation.


Ultimately, the issue is that there is no foundation on which individuals build their programming experience. This is often the reason CS programs include at least on hardware concepts course. How can you write software without a basic(at least) grasp on how the computer itself is running your programs? The answer is you can't.

If at any point you have a "fuzzy" moment on how something works, immediately find a venue [i.e. a language] in which you can experiment with until you "get it".