3 ms·

I think performance is still an issue today. We have orders of magnitude faster hardware as you say but the software is still slow as molasses. The C99 specifi

I think performance is still an issue today. We have orders of magnitude faster hardware as you say but the software is still slow as molasses. The C99 specification is much more interesting than the K&R C of yore. And it still gives the programmer a close mapping between language and target hardware platform. Pharo is super-awesome to work with and play in. However I won't be writing large simulations or ray tracing rendering systems in it any time soon. I'll have to wait another couple of decades before that becomes feasible. Fortunately the FFI API in Pharo let you hook into C code fairly easily.

zeveb 11y ago
> We have orders of magnitude faster hardware as you say but the software is still slow as molasses. Modern Lisps, at least, are fast enough, albeit not often as fast as or faster than C.
- agentultra 11y ago
  Some can be which is interesting enough to stick with them. Lisps that compile code to the target platform and give the programmer control over stack vs. heap allocation and memory layout... interesting. The meta-language features remove the need for a separate code-generation tool to handle boiler-plate like generating jump and decision tables. However with CL and most of the popular "modern lisps" you're still stuck with allocating everything on the heap and having to compile in a GC into your image along with the rest of the ball of mud. You can get pretty fast code at run-time if you're mindful and precise... but it's still pretty hard to debug... and of course, incurs an overhead. "Well we have the processor cycles now to make it feasible!" Well... just barely. We tend to think people don't mind waiting thirty seconds for our browsers to load or seeing the beachball-of-doom when working on a large document... but I think that's pretty wrong.
  - pjmlp 11y ago
    Common Lisp allows for stack allocation and offers many more data structures besides Lists. What I am missing here in regards to the likes of Allegro Common Lisp, for example? Never used them, hence the question.
    - agentultra 11y ago
      wrt stack allocation are you referring to DYNAMIC-EXTENT? It's implementation dependent so you have to know your compiler well. Allocation in C is explicitly a part of the language on the other hand. A conforming compiler has to initialize the memory you ask for in the place you tell it to (at least with optimizations off you can think of it this way): uint32_t flags[100]; vs (defun form () (let ((xs (make-array 100 :element-type :unsigned-int))) (declare (dynamic-extent xs) ...))) The CL example could optimize xs depending on the implementation and its configuration to allocate it on the stack. The C example has to initialize enough memory on the stack for 100 32-bit integers no questions. I hope I didn't give the impression that lists were the only data-structure in CL; I use structs, arrays, and macros to manage structs-of-arrays, etc. Plenty more of course. I do prefer to use CL but I end up spending more time in C/Python for reasons. What I find interesting in lisp land are lisps that don't try to take over the whole system and whose principle design is to be small and fast. C has a large run-time library but you can compile programs without it if you're willing to write your own stuff. You don't have such control in the open source implementations I've used. The open source CL implementations, afaik, still lack tree shakers to try and remove unused code from the image prologue before running the top-level. SBCL still produces a 25MB binary to print "Hello, world!" to the console... because you still have to compile in a GC, the entire CL library, the implementation's run-time, etc -- even if your code never uses it.
      - lispm 11y ago
        > It's implementation dependent so you have to know your compiler well. In any larger application you have to know your compiler and the special libraries well. GCC, CLANG, whatever... SBCL is kind of large. Other open source Common Lisps create smaller applications: CLisp, CCL, ECL, ... Some thought there was a use for delivery Common Lisp with or without GC. But it has not caught on widely. See for example Thinlisp, CLICC, mocl (derived from CLICC) and others. Those have compilers written in Common Lisp, which translated the code to static C. In case of Thinlisp without GC - its origin is in soft-realtime expert systems for process control. Thinlisp is probably not much used, but a related compiler (not publicly available) is still used for product development. There were and still are inhouse delivery compilers. Also specialized languages: You develop in a Common Lisp environment, but write in a special language. SubL, Stella, ... For example Cyc is written on top of SubL, which is derived from Common Lisp (and can be used inside Common Lisp) and the Cyc application then can run on top of C or Java.
  - zeveb 11y ago
    > However with CL and most of the popular "modern lisps" When I write, 'modern Lisp' I mean 'modern implementation of Common Lisp,' since there is no Lisp but Common Lisp, and Kent Pitman is its editor:-) SBCL, at least, provides some support for stack allocation, and I'd be surprised if Allegro and LispWorks don't. Like I wrote, modern Lisps tend to be fast enough, albeit not as fast as would be perfect.

zeveb 11y ago

> We have orders of magnitude faster hardware as you say but the software is still slow as molasses. Modern Lisps, at least, are fast enough, albeit not often as fast as or faster than C.

agentultra 11y ago
Some can be which is interesting enough to stick with them. Lisps that compile code to the target platform and give the programmer control over stack vs. heap allocation and memory layout... interesting. The meta-language features remove the need for a separate code-generation tool to handle boiler-plate like generating jump and decision tables. However with CL and most of the popular "modern lisps" you're still stuck with allocating everything on the heap and having to compile in a GC into your image along with the rest of the ball of mud. You can get pretty fast code at run-time if you're mindful and precise... but it's still pretty hard to debug... and of course, incurs an overhead. "Well we have the processor cycles now to make it feasible!" Well... just barely. We tend to think people don't mind waiting thirty seconds for our browsers to load or seeing the beachball-of-doom when working on a large document... but I think that's pretty wrong.
- pjmlp 11y ago
  Common Lisp allows for stack allocation and offers many more data structures besides Lists. What I am missing here in regards to the likes of Allegro Common Lisp, for example? Never used them, hence the question.
  - agentultra 11y ago
    wrt stack allocation are you referring to DYNAMIC-EXTENT? It's implementation dependent so you have to know your compiler well. Allocation in C is explicitly a part of the language on the other hand. A conforming compiler has to initialize the memory you ask for in the place you tell it to (at least with optimizations off you can think of it this way): uint32_t flags[100]; vs (defun form () (let ((xs (make-array 100 :element-type :unsigned-int))) (declare (dynamic-extent xs) ...))) The CL example could optimize xs depending on the implementation and its configuration to allocate it on the stack. The C example has to initialize enough memory on the stack for 100 32-bit integers no questions. I hope I didn't give the impression that lists were the only data-structure in CL; I use structs, arrays, and macros to manage structs-of-arrays, etc. Plenty more of course. I do prefer to use CL but I end up spending more time in C/Python for reasons. What I find interesting in lisp land are lisps that don't try to take over the whole system and whose principle design is to be small and fast. C has a large run-time library but you can compile programs without it if you're willing to write your own stuff. You don't have such control in the open source implementations I've used. The open source CL implementations, afaik, still lack tree shakers to try and remove unused code from the image prologue before running the top-level. SBCL still produces a 25MB binary to print "Hello, world!" to the console... because you still have to compile in a GC, the entire CL library, the implementation's run-time, etc -- even if your code never uses it.
    - lispm 11y ago
      > It's implementation dependent so you have to know your compiler well. In any larger application you have to know your compiler and the special libraries well. GCC, CLANG, whatever... SBCL is kind of large. Other open source Common Lisps create smaller applications: CLisp, CCL, ECL, ... Some thought there was a use for delivery Common Lisp with or without GC. But it has not caught on widely. See for example Thinlisp, CLICC, mocl (derived from CLICC) and others. Those have compilers written in Common Lisp, which translated the code to static C. In case of Thinlisp without GC - its origin is in soft-realtime expert systems for process control. Thinlisp is probably not much used, but a related compiler (not publicly available) is still used for product development. There were and still are inhouse delivery compilers. Also specialized languages: You develop in a Common Lisp environment, but write in a special language. SubL, Stella, ... For example Cyc is written on top of SubL, which is derived from Common Lisp (and can be used inside Common Lisp) and the Cyc application then can run on top of C or Java.
- zeveb 11y ago
  > However with CL and most of the popular "modern lisps" When I write, 'modern Lisp' I mean 'modern implementation of Common Lisp,' since there is no Lisp but Common Lisp, and Kent Pitman is its editor:-) SBCL, at least, provides some support for stack allocation, and I'd be surprised if Allegro and LispWorks don't. Like I wrote, modern Lisps tend to be fast enough, albeit not as fast as would be perfect.