More on first programming language

William Cusing post in the ResearchGate discussion on which programming language to use in a first programming course. Very interessting:

Racket is a variant of Scheme that focuses on teaching.
http://htdp.org/
http://docs.racket-lang.org/drracket/htdp-langs.html

The Structure and Interpretation of Computer Programs (SICP) is also a classic textbook in computer science (which also teaches Scheme). 

Teaching someone a language is a serious amount of responsibility. It amounts to teaching how to think. Teaching a low-level machine language will 'straightjacket' that individual into low-level thinking. That could be called inflicting brain damage (eminent computer scientists do say so -- such as Dijkstra), instead of teaching.

It is rare, and only will get rarer as compilers/interpreters/virtual-machines improve, that programmers are needed to produce fast programs nowadays. Optimizing before profiling is the root of project failure. Learning how to think at a higher level, profile, and optimize by hand only when truly necessary is the way to approach the present, and moreso the future.

For example, let's consider a typical domain where C is held to be the "best" language: numerical algorithms. Say Fast Fourier Transform. Please Read:http://en.wikipedia.org/wiki/FFTW 
http://www.fftw.org/faq/section2.html#languages

In particular note that the Fastest Fourier Transform is implemented in a combination of ML and OCaml. They wrote their own mini-compiler in those languages, that spits out C code better than anyone else's hand-written C code. They pulled that off because ML and OCaml allow them to easily write their own compiler customized to compiling Fast Fourier Transforms. 

In 'principle' they could have written C code to manipulate C code; but in reality such a project would have failed. Likewise, in 'principle' we could implement an OS in assembly: but the result would be horribly poor in features, if it worked at all. From such considerations it should become clear: the path to the future is higher level languages. C is the new assembly (and has been for some time). Learn it only for the purpose of compiling to it (or because you have a burning desire to implement device drivers for the rest of your life), and learn it only after learning one of the many superior higher level languages out there. 

It is important to learn a higher level language first (ML, OCaml, Python, Ruby, Scala, Clojure, Scheme, Racket, Common LISP, ...) so that you do (less) harm to your ability to think clearly and concisely. Of these languages, Scheme has probably the best support for teaching, and one of the purest approaches; it may not be the language you use on a daily basis for the rest of your life, but it is an ideal language to have learned first.

 
An my answer, below:
I think there is a prejudice against low-level languages. If you think about it, Assembly or machine-level language is not "low level". It is very detailed, indeed. But a few syntactic sugar + expression parsing can take care of the register-to-memory and memory-to-register operations. There are languages, like old PL360, which do that. You can write complete expressions and the languages translates them to machine-language.

So, the point is not being low level. Also not of being a machine language. We had high level machine language like Algol for the Burroughs machine, or LISP for the Symbolic Machines.

The point is that learning machine language we do learn a Universal Machine model. The Von Neumann model. This experience is enlightning. The student understands that data and program have the same representation, are stored in the same memory. The student catches what a compiler has to do to translate his "high level program".

Lisp, Scheme or Racket, as mentioned in William Cushing post, and used in SICP, teach yet another different Universal Machine model, the lambda calculus.

With the Universal Machine concepts understood, the student can then go to "standard" programming languages like C, Java, etc...