5 ms·

> This is why I always think the programming world did a left turn by adopting UNIX tooling instead of what was going on at Xerox PARK. The real reason was tha

by progman 11y ago

> This is why I always think the programming world did a left turn by adopting UNIX tooling instead of what was going on at Xerox PARK. The real reason was that Unix (which is written in C) runs way more efficiently on legacy hardware, orders of magnitudes faster than Smalltalk and Lisp, even on special Lisp hardware. Performance was really an issue in those days. If Lisp and Smalltalk would have had modern PC power at their time then things likely would be very different today.

pjmlp 11y ago
That is true if speaking about servers running text based stuff, what real UNIX used to mean back in those days .e.g. UNIX System V. However, from those days I have in memory that the price difference between workstations wasn't that big. Maybe I don't recall that well. Also JIT compiler research goes back to ways to improve Smalltalk.
eggy 11y ago
I need to look it up, but I thought that it was because of Lisp machines licensing, and only running on custom hardware, that the PC with Unix (C) won. If Lisp had been implemented to run atop the cheap PC, it would have run faster with each hardware iteration, and may have won market share. Now I play with Shen and PicoLisp, which can run on anything almost.
agentultra 11y ago
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.

by progman 11y ago

pjmlp 11y ago

That is true if speaking about servers running text based stuff, what real UNIX used to mean back in those days .e.g. UNIX System V. However, from those days I have in memory that the price difference between workstations wasn't that big. Maybe I don't recall that well. Also JIT compiler research goes back to ways to improve Smalltalk.

eggy 11y ago

I need to look it up, but I thought that it was because of Lisp machines licensing, and only running on custom hardware, that the PC with Unix (C) won. If Lisp had been implemented to run atop the cheap PC, it would have run faster with each hardware iteration, and may have won market share. Now I play with Shen and PicoLisp, which can run on anything almost.

agentultra 11y ago

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.