4 ms·

I haven't programmed in Lisp yet, but I love the idea: it seems very directly inspired by lambda calculus. However, I tend to think of it as the opposite pole o

I haven't programmed in Lisp yet, but I love the idea: it seems very directly inspired by lambda calculus. However, I tend to think of it as the opposite pole of expressiveness from ASM. Lisp excels at abstraction, but is not good at bit-twiddling, or (from my limited perspective) interacting with anything that isn't Lisp. That said, I know that my perspective is incomplete at best, so I would listen very attentively to anyone who might disagree with it.

kazinator 8y ago
I made a Lisp dialect called TXR Lisp. I gave it a nice, ergonomic FFI. I took the MSDN "Your First Windows Program" which is a C sample, and translated it expression for expression: https://rosettacode.org/wiki/Window_creation#Win32.2FWin64 https://rosettacode.org/wiki/Window_creation#Win32.2FWin64 The C original is here: https://docs.microsoft.com/en-us/windows/desktop/learnwin32/your-first-windows-program https://docs.microsoft.com/en-us/windows/desktop/learnwin32/... The Lisp program recreates all of the needed C structure definitions, and binds to the needed functions from user32.dll and other libraries. Here is another TXR Lisp program which parses TCP/IP packets right out of the "pcap" style output from tcpdump: https://unix.stackexchange.com/a/379759/16369 https://unix.stackexchange.com/a/379759/16369 Lisp dialects tend to be close-to-the-metal languages whose workings can be explained using bits and bytes (even if such an explanation is not always accurate due to issues of optimization and whatnot). When I'm debugging Lisp, I think of word-sized arguments on a stack, and pointers and all those same kinds of things like when debugging a C program. Historic Lisp implementations were bootstrapped from assembly code. Lisp primitives were written as a library of machine language routines. With that, plus I/O and memory management, you just need an eval routine for interesting things to start happening. The car and cdr terms are inspired by machine instructions, and they help keep us grounded in reality.
- sethrin 8y ago
  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.
  - kazinator 8y ago
    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.
    - sethrin 8y ago
      Just to be entirely clear, are you disagreeing with the author about the suitability of Lisp for video game development?
      - kazinator 8y ago
        The author is noted for using Lisp for game development.
        sethrin 8y ago
        The author says: > 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.
mepian 8y ago
Common Lisp is fine for bit-twiddling, you can see it for yourself if you read this chapter in Practical Common Lisp: http://www.gigamonkeys.com/book/practical-parsing-binary-files.html http://www.gigamonkeys.com/book/practical-parsing-binary-fil... The FFI of Common Lisp is on par with more mainstream languages like Python.

kazinator 8y ago

I made a Lisp dialect called TXR Lisp. I gave it a nice, ergonomic FFI. I took the MSDN "Your First Windows Program" which is a C sample, and translated it expression for expression: https://rosettacode.org/wiki/Window_creation#Win32.2FWin64 https://rosettacode.org/wiki/Window_creation#Win32.2FWin64 The C original is here: https://docs.microsoft.com/en-us/windows/desktop/learnwin32/your-first-windows-program https://docs.microsoft.com/en-us/windows/desktop/learnwin32/... The Lisp program recreates all of the needed C structure definitions, and binds to the needed functions from user32.dll and other libraries. Here is another TXR Lisp program which parses TCP/IP packets right out of the "pcap" style output from tcpdump: https://unix.stackexchange.com/a/379759/16369 https://unix.stackexchange.com/a/379759/16369 Lisp dialects tend to be close-to-the-metal languages whose workings can be explained using bits and bytes (even if such an explanation is not always accurate due to issues of optimization and whatnot). When I'm debugging Lisp, I think of word-sized arguments on a stack, and pointers and all those same kinds of things like when debugging a C program. Historic Lisp implementations were bootstrapped from assembly code. Lisp primitives were written as a library of machine language routines. With that, plus I/O and memory management, you just need an eval routine for interesting things to start happening. The car and cdr terms are inspired by machine instructions, and they help keep us grounded in reality.

sethrin 8y ago
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.
- kazinator 8y ago
  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.
  - sethrin 8y ago
    Just to be entirely clear, are you disagreeing with the author about the suitability of Lisp for video game development?
    - kazinator 8y ago
      The author is noted for using Lisp for game development.
      - sethrin 8y ago
        The author says: > 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.

mepian 8y ago

Common Lisp is fine for bit-twiddling, you can see it for yourself if you read this chapter in Practical Common Lisp: http://www.gigamonkeys.com/book/practical-parsing-binary-files.html http://www.gigamonkeys.com/book/practical-parsing-binary-fil... The FFI of Common Lisp is on par with more mainstream languages like Python.