[HN Gopher] Lisp: Icing or Cake?
___________________________________________________________________
Lisp: Icing or Cake?
Author : psj
Score : 223 points
Date : 2024-06-01 21:32 UTC (1 days ago)
(HTM) web link (dthompson.us)
(TXT) w3m dump (dthompson.us)
| ggm wrote:
| Porque no los dos?
| swatson741 wrote:
| 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.
| rjsw wrote:
| It has snake and tetris in the default installation.
| doublerabbit wrote:
| I'm surprised no one has joined the two and invented Snake
| Tetris.
| JadeNB wrote:
| They have; it's just usually called SnakeTris.
| davexunit wrote:
| https://bcardoso.itch.io/shoggy
|
| https://lcolonq.itch.io/slgj2024-game-boy-gizmo
|
| https://asquared31415.itch.io/disassembly
|
| https://grindingstone.itch.io/pendulum
| skissane wrote:
| Every copy of GNU Emacs comes bundled with the text adventure
| Dunnet [0].
|
| Dunnet was originally written by Ron Schnell in 1982, as a
| Maclisp program running under TOPS-20. [1] In 1992, he ported
| it to Emacs Lisp; however, the Emacs Lisp version is more than
| just a simple port of the original, it extends the game with
| new rooms/items/puzzles, but also removes MIT-centric
| content-e.g. the "endgame" computer at the end of the game was
| originally named MIT-SALLY, was located at MIT, and was
| accessed via Chaosnet-the GNU Emacs version removes all those
| (dated) MIT references-although the GNU Emacs version contains
| (obviously intentionally) equally dated (albeit more widely
| recognisable) content such as a VAX 11/780
|
| [0] https://en.wikipedia.org/wiki/Dunnet_(video_game)
|
| [1] Original is here:
| https://github.com/Quogic/DunnetPredecessor/blob/master/foo....
| stevekemp wrote:
| I've been an Emacs user for 20+ years and had never stumbled
| across that game, thanks for highlighting it!
|
| I found the CPU, the Key (guarded by the bear) and made it
| into the house. Was a fun diversion I guess I need to play it
| more seriously sometime.
| anthk wrote:
| Malyon it's a ZMachine interpreter which works mostly fine.
| momentoftop wrote:
| 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?
| anthk wrote:
| Ditto, I loved devours too, and it's a libre game:
|
| https://jxself.org/git/devours.git
|
| Spiritwrak it's Zorkian but libre licensed unlike Zork
| [1-3] / Dungeon.
|
| And, OFC, Emacs has Inform-mode, a helper for Inform6 and
| Inform6-lib.
| ngcc_hk wrote:
| " 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.
| bitwize wrote:
| 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 architecture is due for a major
| comeback.
| imachine1980_ wrote:
| Hi I think is in the hypothesis (I'm not sure) of that we
| have edition made by the pdp 11 keyboard developer and
| tooling that's old and design whiout introspection in mind
| showcase in this video, the video is really cool but little
| bit long
|
| https://youtu.be/8Ab3ArE8W3s?si=FdwCbmRnU1gJIXJx
| pjmlp wrote:
| 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.
| coliveira wrote:
| 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 Fortran arrays will
| always be faster than a Lisp list based version.
| shawn_w wrote:
| Luckily, lisp has arrays too, and a bunch of other data
| structures besides lists.
| dwringer wrote:
| 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.
| wtetzner wrote:
| If the cons cells are allocated linearly it's fine. Plus the
| fact that lisps have more data structures than just lists.
| f1shy wrote:
| 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.
| lispm wrote:
| 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.
| rscho wrote:
| Please try one of the big Lisp/Scheme yourself instead of
| spreading uninformed opinions.
| pjmlp wrote:
| 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.
| pjmlp wrote:
| 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.
| GeorgeTirebiter wrote:
| 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.
| ertucetin wrote:
| I recently created 3D boss fight prototype using Clojure:
| https://prototype-game.pages.dev
| all2 wrote:
| I cannot make the controls work on mobile. I'll try when I have
| a PC in front of me again.
| ertucetin wrote:
| Yes it is for PC web. You can check sample video with your
| phone here: https://x.com/ertuctn/status/1796627956120399898
| kolme wrote:
| That's rad! What libraries are you using?
| hazn wrote:
| 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
| happypumpkin wrote:
| This is great! I used to hate all forms of webdev but
| ClojureScript actually makes it enjoyable, I really hope it
| gets more traction.
| bmacho wrote:
| No janet despite https://ianthehenry.com/posts/janet-game/
| (article copyrighted between 1899-1907, but doesn't look vintage
| that's a shame)
| rcarmo wrote:
| Janet seems to have fallen through the cracks. I went back to
| fennel for scripting stuff, mostly because I can just go and
| get a lot more Lua libraries and run it everywhere (even on my
| iPad with a-Shell) with zero hassle.
| cardanome wrote:
| Do you think that Fennel adds enough value on top of Lua to
| justify the extra compilation step?
|
| I mean it is valid to use it for the fun of it, just
| wondering. Lua is already more or less a Scheme clothed in a
| more conventional syntax. On top of that the fact that Lua
| already has excellent metaprogramming capabilities kind of
| negates the typical advantage of using a lisp-style syntax.
| So what is Fennel bringing to the table?
| oofoe wrote:
| 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.)
| rcarmo wrote:
| This was... a hoot (pardon the pun) to read, since I've been
| eyeing Guile as a go-to for future stuff I build. Nice going on
| the WASM front.
| sourcepluck wrote:
| If you like puns, strap yourself into your chair before reading
| this essay from Andy Wingo if you haven't seen it yet:
|
| https://wingolog.org/archives/2024/05/16/on-hoot-on-boot
| hazn wrote:
| i encourage the readers of this comment thread to check out the
| spritely institute, especially it's blog [0].
|
| i don't wanna spoil what it's all about, but i ensure you it's a
| topic (and institute!) worth diving into. i poured 10h+ just
| reading the blog and all the related links and projects :)
|
| [0] https://spritely.institute/archive/
| sourcepluck wrote:
| +1. They seem to attract excellent people and do very cool
| stuff.
| runlaszlorun wrote:
| Nice piece. Maybe because I havent seen many articles these days
| with any sort of objective comparison of software approaches in
| general. Ok... I'll admit that any attempt I've made to find such
| pieces never makes it past all the SEO spam these days.
|
| A little surprised to not see any games using Janet- since it
| seems to be both made for gaming and has a surprising number of
| 'batteries included' like a web server and graphics. Then again,
| I've only stumbled upon it pretty recently myself. From my minor
| hacking with it, it's def worth a peek in the Lisp/games arena.
| doublerabbit wrote:
| PHP: Noodles or Soup?
| iainctduncan wrote:
| 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. :-)
| mikemee wrote:
| 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.
| supaflybanzai wrote:
| Wow, so nice to hear some people actually experimenting with
| not just mainstream stuff.
|
| Where do you work (if it is not a secret)?
| mikemee wrote:
| 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.
___________________________________________________________________
(page generated 2024-06-02 23:01 UTC)