Have you ever tried learning a foreign language
English, French (I usually forget the latter and recover it when I have any proximate use for it). My native language is Russian. It is a big relief when learning French that most words have the same translations in many contexts. This multi-translation problem is way more annoying than simply looking up words.
Sometimes, I would even settle for an inferior language, if doing so grants me access to more powerful libraries that free me from extra work
This actually confirms my point. You will have to choose inferior language from time to time, and its lack of tools of adapting language to your task is either local incompetence of language authors or lack of resources for development of language or lnaguage community arrogance.
But C syntax is plainy malicious even in assignments... How so ? Perhaps you were thinking of C++, which is indeed malicious ?
"i+= i++ + ++i;" can be reliably compiled but not predicted. There are many actual everyday examples like "if(a=b);".
Of course, it is not even close to C++, which takes malicious semantics a few levels up.
basic concept you internalize when learning assembly is that (roughly speaking) the computer isn't a magical genie with arbitrary rules
leads naturally to understanding pointers, on which the vast majority of other languages
Any command-line programming environment will make you internalize that computer has some rules and that it does what you order - literally.
x86 assembly is quite arbitrary anyway. Maybe LLVM assembly (which is closer to "pointer machine" than to "random access machine) would be nicer. After all, high-level languages use specially wrapped pointers even in implementation.
I doubt that you can properly understand things like type inference without first understanding bits and pointers.
You cannot properly understand some performance implications, maybe. But the actual input-output correspondence can be grokked anyway. Of course, only higher-order functions have a strict proof that they can be understood without proper understanding of imperative semantics.
This multi-translation problem is way more annoying than simply looking up words.
It's possible that you are much better at automatically memorizing words than I am.
You will have to choose inferior language from time to time, and its lack of tools of adapting language to your task is either local incompetence or lack of resources or arrogance.
Wait... what ? Are you saying that, when I have some practical task to finish, the best solution is to pick the most elegant language, disregarding all other options -- and that not doing so makes me arrogant ? ...
Learning to program in a given language requires a non-trivial amount of time. This seems to be agreed upon as a good use of LessWrongers' time.
Each language may be more useful than others for particular purposes. However, like e.g. the choice of donation to a particular charity, we shouldn't expect the trade-offs of focusing on one versus another not to exist.
Suppose I know nothing about programming... And I want to make a choice about what language to pick up beyond merely what sounds cool at the time. In short I would want to spend my five minutes on the problem before jumping to a solution.
As an example of the dilemma, if I spend my time learning Scheme or Lisp, I will gain a particular kind of skill. It won't be a very directly marketable one, but it could (in theory) make me a better programmer. "Code as lists" is a powerful perspective -- and Eric S. Raymond recommends learning Lisp for this reason.
Forth (or any similar concatenative language) presents a different yet similarly powerful perspective, one which encourages extreme factorization and use of small well-considered definitions of words for frequently reused concepts.
Python encourages object oriented thinking and explicit declaration. Ruby is object oriented and complexity-hiding to the point of being almost magical.
C teaches functions and varying abstraction levels. Javascript is more about the high level abstractions.
If a newbie programmer focuses on any of these they will come out of it a different kind of programmer. If a competent programmer avoids one of these things they will avoid different kinds of costs as well as different kinds of benefits.
Is it better to focus on one path, avoiding contamination from others?
Is it better to explore several simultaneously, to make sure you don't miss the best parts?
Which one results in converting time to dollars the most quickly?
Which one most reliably converts you to a higher value programmer over a longer period of time?
What other caveats are there?