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 ? I am pretty sure this isn't right. For example, my current project involves some Bluetooth communication and data visualization on Windows machines. There are libraries for Java and C# that fulfill all my Bluetooth and graphical needs; the Python library is close, but not as good. Are you saying that, instead of C#, I should just pick Scheme or Haskell or something, and implement my own Bluetooth stack and drawing APIs ? I am pretty sure that's not what you meant...
"i+= i++ + ++i;" can be reliably compiled but not predicted.
Ok that's a good point; I forgot about those pre-/post-increments, because I avoid them myself. They're pretty terrible.
On the other hand, the regular assignment operator does make sense; the rules that let you say "if(a=b)" also let you say "a=b=c". The result of an assignment operator is the RHS. I don't see this as a bad thing, though it might've been better to use "eq" or some other token instead of the comparison operator "==".
Any command-line programming environment will make you internalize that computer has some rules and that it does what you order - literally.
True, and that's a good lesson too, but programming in assembly lets you get close (though not too uncomfortably so) to the actual hardware. This allows you to internalize the idea that at least some of these rules are not arbitrary. Instead, they stem from the fact that, ultimately, your computer is an electron-pushing device which is operating under real-world constraints. This is important, because arbitrary rules are something you have to memorize, whereas physical constraints are something you can understand.
You are right about x86 assembly, though, which is why I mentioned "a small microcontroller" in my original post. Their assemblies tend to make more sense.
But the actual input-output correspondence can be grokked anyway.
You are right, though this depends on which problem you're solving. If you approach the programming language completely in abstract, then yes, you can understand things like input-output correspondence from the strictly algebraic point of view. What you won't understand, though (at least, not as readily), is why all these language features were created in the first place, and which problems they are designed to solve. But if you never intend to write practical programs that perform applied tasks, maybe that's ok.
It's possible that you are much better at automatically memorizing words than I am.
Or simply annoyed by different things.
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?
Sorry for unclear phrase. I mean that language's lack of tools is language's arrogance.
rules that let you say "if(a=b)" also let you say "a=b=c"
"a=b=c;" vs "a=c; b=c;" is not much; the former s...
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?