And this is specifically about tools that allow you to tailor the language to your specific task, so that there are no problems with language that you are prohibited from solving. Somebody can always write a bluetooth library.
That makes sense, and I do wish that more languages supported more capabilities, but I think it's unrealistic to expect all languages to support all, or even most, or even some large fraction of real-world tasks that are out there. There are vastly more tasks than there are languages: graphics (raster, vector, and 3d, on various systems), sound, desktop user interfaces, bluetooth, TCP/IP networking, bio-sequence alignment, finance, distributed computation, HTML parsing and rendering, SQL access... and that's just the stuff I'd had to handle this month !
Learning optimization on that level is something you can do while having a good grasp of other concepts already.
I think the opposite is true: performing this kind of optimization (even on a "toy" program) is exactly the kind of task that can help you internalize those concepts.
Type inference allows you to write with strict typechecks and catch some kinds of errors without cluttering the code with type specifications for every variable.
I agree with you there, but I'll play Devil's Advocate, in my attempt to adopt the perspective of someone who only knows Scheme. So, can you give me an example of some Scheme code where the strict typechecks you mentioned are truly helpful ? To me (or, rather, my Schemer's Advocate persona) this sounds inelegant. In Scheme, most entities are pairs, or data structures built of pairs, anyway. Sure, there are a few primitives, but why should I worry about 5 being different from 5.0 or "5" ? That sounds like a job for the interpreter.
That makes sense, and I do wish that more languages supported more capabilities, but I think it's unrealistic to expect all languages to support all, or even most, or even some large fraction of real-world tasks that are out there
You didn't understand my point correctly. Language per se should not support directly, say, bluetooth - because bluetooth will change in an incompatible way. Language could live without a bluetooth library - why not, there is always FFI for dire cases. But the question is about allowing to define a nice API if a need arises. Mo...
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?