[lycopodiopsida]

> One thing I note is that all of the languages you name are very far from the machine

Common lisp is one step away from assembly - you disassemble any function and it is, in fact, a valid strategy of one wants to check the compiler optimizations.

[cjfd]

I googled a bit on how common lisp is compiled. Apparently it is possible to add some sort of type hints and ensure that parameters/variables have a certain type. If one uses that for most code, it would potentially be enough to qualify as being close to the machine.

[vkazanov]

Yes, in a way common lisp code can be locally lowered to a well-typed language.

What people do is just write code they way they usually write dynamic lisp and then add types to functions where necessary for performance.

SBCL generates good assembly, btw.

[Zambyte]

What does "close to the machine" mean to you?

[cjfd]

To me it means that one attempts to use the machine well. I.e., avoid introducing overheads that have nothing to do with the problem one is trying to solve. As an example of something that is very far from the machine imagine wanting to add some integers together. One can do this in untyped lambda calculus by employing Church Numberals. If one looks at the memory representation now your numerals are a linked list of a size equal, or proportional, to the number. However, the machine actually has machine language instructions to add numbers in a much more efficient way. For this discussion maybe the most relevant example is that using dynamic typing for algorithms that don't need it is distant from the machine because every value now has a runtime type label that is actually not needed because if your program could actually be statically typed, one would know in advance what the type labels are so they are redundant.