Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp: Icing or Cake?

dthompson.us

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Lisp: Icing or Cake?

#31

Post by shawn_w »

coliveira wrote: post #30
ngcc_hk wrote: post #12

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary. Btw any icing with sdl I wonder.

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fo…

Luckily, lisp has arrays too, and a bunch of other data structures besides lists.

Re: Lisp: Icing or Cake?

#32

Post by dwringer »

coliveira wrote: post #30
ngcc_hk wrote: post #12

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary. Btw any icing with sdl I wonder.

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fo…

Common Lisp allows one to use arrays or other structures, and can even be used to inline assembly. So despite lists being a major part of the ecosystem and code representation itself, they are not mandatory for implementing an algorithm, or necessarily a performance drawback to using lisp. By the same token, it's easy for people to accidentally use lists and pointers to implement algorithms just as inefficiently in other languages - Python comes to mind. A standard approach in Python is to lean on external libraries for high performance computation, and this can be done just the same way in Lisp - but Lisp can also be used directly to write efficient low level algorithms by making a conscious effort not to use the list- and pointer-based functions to do so.

Re: Lisp: Icing or Cake?

#33

Post by wtetzner »

coliveira wrote: post #30
ngcc_hk wrote: post #12

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary. Btw any icing with sdl I wonder.

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fo…

If the cons cells are allocated linearly it's fine. Plus the fact that lisps have more data structures than just lists.

Re: Lisp: Icing or Cake?

#34

Post by momentoftop »

anthk wrote: post #24
swatson741 wrote: post #7

I'm very curious what sort of games were made in elisp. It's not really the first thing that comes to mind when I think about games programming.

Malyon it's a ZMachine interpreter which works mostly fine.

Playing "This thing all things devours" is one of the most profound gaming experiences I have had, and I happened to use Malyon. Why wouldn't I use the best text editor to play an inform game?

Re: Lisp: Icing or Cake?

#37

Post by f1shy »

coliveira wrote: post #30
ngcc_hk wrote: post #12

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary. Btw any icing with sdl I wonder.

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fo…

Depending on the implementation for short list they can be optimized (just as strings in C++). You may be right with C and Fortran. But tbh in an era where the tiniest thing has an OS with MMU, I really prefer GC when the performance is not a problem. If it is just a performance concern, then ASM will always beat C… Like everything in engineering is about the right trade off.

Re: Lisp: Icing or Cake?

#38

Post by iainctduncan »

Great to see s7 getting some love. I used it as the Scheme for Scheme for Max, an open source extension to the Max/MSP computer music environment that puts a Scheme interpreter in Max, and I love it. It occupies a space somewhere between Guile, Clojure, and CL, while being very minimal, and is dead easy to embed. It is also much more liberally licensed (BSD) than Guile.

If you like CL macros with first class environments, you will probably like s7.

It's also dead easy to use in WASM, which I am doing for a music pedagogy project. It's using the icing approach, but I would say the cake is 3/4 icing. Notably, it was not difficult to make generic functions for calling JS functions from Scheme and vice versa, which has made things very smooth. A ganache perhaps. :-)

Re: Lisp: Icing or Cake?

#39

Post by lispm »

coliveira wrote: post #30
ngcc_hk wrote: post #12

“ We’re not living in a world of Lisp machines, but a world of glorified PDP-11s.” Quite a summary. Btw any icing with sdl I wonder.

Lisp is unsuitable for modern CPUs because of memory hierarchy. Lisp operates primarily with lists, which can have pointers all over memory. This was not a problem on earlier CPUs because all memory was the same with similar random access time. Modern CPUs cannot access pointers in memory with the same speed, they need to follow locality rules for performance. This means that an algorithm using something like C or Fo…

Modern CPUs can execute Lisp just fine, like they execute languages like Java and Javascript, which also use a lot of pointers. Just like those, Lisp offers vectors, strings, hash tables, structures/records and objects.

> This was not a problem on earlier CPUs because all memory was the same with similar access time.

That's not true. Many early systems had small RAM sizes (example: a DEC VAX 11/780 had a few Megabytes and often served dozens of users) and 10 (or more) times larger slow virtual memory.

Lisp systems then tried to deal with that with the first generational garbage collectors, often also compacting (related objects stayed near in memory). Ephemeral GCs watched for changed memory in RAM.

Re: Lisp: Icing or Cake?

#40

Post by hazn »

ertucetin wrote: post #17

I recently created 3D boss fight prototype using Clojure: https://prototype-game.pages.dev

i mean this with absolute adoration for what you've created: it reminds me of avatar - legends of the arena [0].

one of my absolute favorite games of my childhood :')

[0] https://www.youtube.com/watch?v=dcJFldES9dg

Post reply on HN