Thank you for the response. The article at hand suggests:
> Performance (beyond the efficiency gained from appropriate algorithms) is going to be dictated from your ability to control what is being processed and when. Maybe I can’t afford a GC in the middle of my frame, maybe to get the entity count I need I really have to maintain data locality.
> ANSI CL doesn’t have many provisions to allow for this kind of control. Certain implementations do have some and you can do a lot with CFFI, but at what point do the restrictions you impose on yourself making another language a better candidate?
This to me suggests that while certain operations may be "close to the metal" as you say, this is not necessarily descriptive of the whole, or perhaps that "close to the metal" may mean a number of different things. Other languages seem to offer more control, perhaps at the expense of abstract expressive power.
Also, while I believe your description of history is accurate as far as it goes, I had rather thought that the Lisp Machines were invented to run Lisp instructions in hardware. I'm not sure if that might argue against your point, nor if those were actually significant in the development of Lisp.
Thank you once again for helping to rectify my ignorance.
If I use a garbage collector in an assembly language program, then I get pauses; the assembly language is still "close to the metal".
There are ways to avoid garbage collection pauses in Lisp or minimize them ranging from program design and coding techniques, as well as compiler optimizations to avoid the consing that leads to garbage collection, to garbage collectors that perform incrementally so as to conceal the pauses by amortization over time.
Lisp was implemented on IBM mainframes initially and then various other mainstream hardware. Research on Lisp-oriented hardware began in 1973 or so, and wasn't commercialized until 1979 or so; the "boom" in Lisp machines could be regarded as a 1980's phenomenon.
Lisp machines allow for type checking to be significantly reduced in cost. The hardware instructions themselves can perform a check such as whether the two operands to an add instruction are integers. A Lisp machine can have idealized type representations as well, so that Lisp programs aren't disadvantaged on it. E.g. It's hard to stick a type tag into floating-point numbers on conventional hardware (doing so involves a loss of mantissa bits), but we could design Lisp hardware which has it has type bits as part of the floating representation.
Run-time type checking overhead can also be reduced in compiled Lisp programs on conventional machines thanks to type information which is either inferred to some extent, or comes from declarations, or a combination of both.
> I am not going to make any bigger claims on the community or industry as a whole so this is just where I’m at right now. I’ll also touch a little on why I’m not using lisp for my current games.
> CL is a great language that still has a lot to give. I’m gonna be using it for a long time including for games. It lives in the place of being fantastic and performant for scripting and also having the control to be truly viable for higher performance code. The implantation specific extensions to the language open up a ton of possibilities for squeezing more out of the machine and the abilities that macros afford us means there is a lot of meaningful stuff we can do trivially that require complex and unwieldy systems in other languages.
And:
> I’d heartily recommend making a non-trivial game in lisp.
> Performance (beyond the efficiency gained from appropriate algorithms) is going to be dictated from your ability to control what is being processed and when. Maybe I can’t afford a GC in the middle of my frame, maybe to get the entity count I need I really have to maintain data locality.
> ANSI CL doesn’t have many provisions to allow for this kind of control. Certain implementations do have some and you can do a lot with CFFI, but at what point do the restrictions you impose on yourself making another language a better candidate?
This to me suggests that while certain operations may be "close to the metal" as you say, this is not necessarily descriptive of the whole, or perhaps that "close to the metal" may mean a number of different things. Other languages seem to offer more control, perhaps at the expense of abstract expressive power.
Also, while I believe your description of history is accurate as far as it goes, I had rather thought that the Lisp Machines were invented to run Lisp instructions in hardware. I'm not sure if that might argue against your point, nor if those were actually significant in the development of Lisp.
Thank you once again for helping to rectify my ignorance.