for the same reason that learning a human language to the point where you can converse in it will never be easy. There are always a bunch of library APIs (or dictionary words), edge cases, and best practices (or colloquialisms) to memorize. But understanding the basics of the language does not have to be hard
All this is simple to look up - programming is not fluent speech, it is writing. The problem is that similar words have radically different combinations of meanings. And also, sometimes there are totally new concepts in the language. You see it better after you try learning a language where concepts do match your expectations.
Technically, this is a language deficiency in and of itself. I rarely find myself wishing I had more macros in Python, or even C#.
Well, I have written significant amount of code in Python and I did have to use workarounds that would be cleaner as macros... If you consider your language a good fit to your task at any time, you are likely just not asking for the best. It can be mitigated if your requirements are understandable.
I dislike Pascal because I find its pointer syntax to be needlessly obscure
It is still the same. But C syntax is plainy malicious even in assignments, so why care about pointers. Somehow, Google managed to create a clean C-derived syntax in Go by streamlining a lot of rules.
You can't learn everything at once, so you might as well start with the big ideas, and go from there
But it is also clear that you should always know that you are not learning some magical set of all basic concepts, just the concepts that are simpliest to learn in the beginning.
All this is simple to look up - programming is not fluent speech, it is writing.
Have you ever tried learning a foreign language ? Maybe it was easy for you -- I know people who seem to have a natural aptitude for it -- but for me, it was basically a long painful slog through dictionary-land. Yes, from a strictly algorithmic standpoint, you could look up every word you intend to read or write; but this works very poorly for most humans.
If you consider your language a good fit to your task at any time, you are likely just not asking for the best.
I th...
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?