Live data from Hacker News

Lisp: Icing or Cake?

dthompson.us

41–50 of 58 posts

Re: Lisp: Icing or Cake?

#41
post #19

No janet despite https://ianthehenry.com/posts/janet-game/ (article copyrighted between 1899-1907, but doesn't look vintage that's a shame)

Hi! Considered Janet very seriously, but couldn't see an immediate path to get where I wanted to go with it (web app, using WebGL (ThreeJS)).

There were some useful references in this thread: https://janet.zulipchat.com/#narrow/stream/409517-help/topic... and maybe I can try them later.

As it was, even with a proven production path, I still barely got something playable on time... ("Playable" is perhaps generous.)

Re: Lisp: Icing or Cake?

#42
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…

Please try one of the big Lisp/Scheme yourself instead of spreading uninformed opinions.

Re: Lisp: Icing or Cake?

#43
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.

Ironically we are now getting C Machines with hardware memory tagging, as there is no other way to fix C, and too much code around that will never be rewriten.

Re: Lisp: Icing or Cake?

#45
post #13
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.

Except conventional CPUs aren't really glorified PDP-11s, except in the sense that they're Von Neumann machines with untagged memory; and the conventional CPUs started lapping the Lisp machines around the mid-80s, when 32-bit microprocessors started becoming common and Lisp compiler technology evolved to better support them. And even the "untagged memory" bit might not hold; with things like CHERI, a LispM style arch…

Or SPARC ADI and ARM MTE, already around, only Intel and AMD keep failing to deliver something that actually works, e.g. iAPX 432 and MPX.

Re: Lisp: Icing or Cake?

#46
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…

Apparently some people keep being stuck in 1960, when Lisp 1.5 manual was published.

Since the 1980's that modern Lisps support all common data structures.

Re: Lisp: Icing or Cake?

#47

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 environm…

Another vote for s7. We successfully embedded it and SQLite as the (non graphics) engine for otherwise native apps on iOS and Android. Super fast. Great FFI. Reliable. Small. Huge benefits from shared code across our mobile apps, insanely fast unit tests and a clean set of tooling.

Ultimately we switched to Fennel as a more pragmatic Lisp for mobile. AFAIK we were alone using s7 on mobile whereas Lua especially is a common mobile extension. Partly also this reflected the state of r7rs Scheme compatibility. We were running Guile on the desktop for development while shipping s7 and subtle incompatibilities would bite us regularly (a fun one was parameter evaluation order).

Thumbs up to both s7 and fennel for their great projects and community.

Re: Lisp: Icing or Cake?

#48
post #47

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 environm…

Another vote for s7. We successfully embedded it and SQLite as the (non graphics) engine for otherwise native apps on iOS and Android. Super fast. Great FFI. Reliable. Small. Huge benefits from shared code across our mobile apps, insanely fast unit tests and a clean set of tooling. Ultimately we switched to Fennel as a more pragmatic Lisp for mobile. AFAIK we were alone using s7 on mobile whereas Lua especially is a…

Wow, so nice to hear some people actually experimenting with not just mainstream stuff.

Where do you work (if it is not a secret)?

Re: Lisp: Icing or Cake?

#49
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.

Well.... I really liked the pdp-11; for years I had a pdp-11/45 in my living room, but eventually sold it to downsize to a couple of H-11 LSI-11/2 machines with dual 8" floppies.

Why? Well, the pdp-11, besides being the unix protoplasm, is conceptually well-designed. In the same way we tend to write routines that 'fit on a screen', the pdp-11's small directly addressable space encourages not-very-big modules: it encourages modularity.

Is it inadequate for today? Sure. Especially painful for Big Data. But, conceptually -- there's a reason the pdp-11 was so successful, and continues to exist vestigially.

Re: Lisp: Icing or Cake?

#50
post #47

Earlier quoted context omitted.

Another vote for s7. We successfully embedded it and SQLite as the (non graphics) engine for otherwise native apps on iOS and Android. Super fast. Great FFI. Reliable. Small. Huge benefits from shared code across our mobile apps, insanely fast unit tests and a clean set of tooling. Ultimately we switched to Fennel as a more pragmatic Lisp for mobile. AFAIK we were alone using s7 on mobile whereas Lua especially is a…

Wow, so nice to hear some people actually experimenting with not just mainstream stuff. Where do you work (if it is not a secret)?

No secret. A little puzzle app company I’ve been running for a while: www.eggheadgames.com. No ads or gamification. Just classic paper magazine puzzles. Pay for more or subscribe for unlimited play.

As we’re small, rewriting the code over and over for cross-platform is costly. But as they’re games with words, we want a fully native experience for the highest quality app with great accessibility and full integration - as well as easier crash log debugging without intrusive 3rd party packages.

The classic solutions are either not native enough (Flutter), are graphics-based (Unity), too expensive to maintain the stack (React *), don’t integrate well with the native mobile tooling (Go, various ports of Python, Ruby, Lisps apart from s7) or also end up being a separate core but are harder to debug via crash logs (various JS, Kotlin or Swift cross platform).

Plus once we tried Lisp it was hard to go back! Succinct, fast, great editing. And yeah, it’s just fun to do something different. We also get a kick from being part of and contributing back to the Fennel community. It’s nice to mix some open source with commercial apps.

Post reply on HN