Celebrating 40 years of magic with Hal Abelson & Gerald Sussman

at the (fourteenth RacketCon) October 5-6, 2024, University of Washington Featuring Lisp legend Gregor Kiczales

https://con.racket-lang.org

Finally posting after lurking here for a long time. Friends don't care too much about this sort of thing.

This is written in Odin, with my own small Lisp interpreter from over 5 years ago. Lisp was the easy choice, primarily because paren's are easier to parse into pretty circles, but also it is much lighter than including Lua.

Using Raylib for the rendering.

There are tons of things I want to implement, but I finally got it into a state that I'm happy sharing something about it. Like one thing I want to change is that spells shouldn't define the cost, but functions like `move-toward` should consume MP as they are called.

There are other spell effects not demoed: shield, heal, buff, debuff, damage, status, teleport, etc.

As for the window decor, a Windows 7 skin for KDE Plasma.

If you would like a copy of myCommon Lisp book, you can get a free PDF/MOBI/EPUB copy at https://markwatson.com/books/ or if you want to support my writing then you can but it on leanpub

this is part of my efforts to revive the cl-wayland endeavor, with client-side codegen now complete (a HUGE milestone)

currently rewriting the codebase for documentation/readability but will then begin work on server-side

note that this is only for libwayland, and not wlroots, pixman, and other commonly-required libs for a functional compositor

repo: https://gitlab.com/bigbookofbug/wayvment

Lisp has macros like no other language. They allow the program to extend the syntax of the language in arbitrary ways. Lisp even has Reader macros (though Clojure doesn't have them) which let the programmer invent syntax that's not s-exp. Racket (a dialect of Lisp) makes heavy use of this and encourages Language-Oriented-Programming. Racket says it's better to develop DSLs that match the problem at hand instead of libraries.

Lisp also has continuations and restarts, meaning that programs never crash. Lisp allows the programmer to modify the running program, debug it, update the definitions of functions, etc., and solve any issues. This was crucial when NASA JPL was using Lisp to debug a spacecraft 10 million miles aways from the Earth.

Lisp also has a REPL that's not like any other REPL. Other REPLs are mostly used to enter a piece of code and evaluate it (Python's REPL for example). But Lisp's REPL is part of the development process (they call it REPL-Driven-Development), and offers advantages over test-driven-development.

Lisp can be fast! Several compilers of Common Lisp (e.g., SBCL) get very close to C code speed despite Lisp being an interpreted language and despite the much less funding thrown at Lisp development.

Lisp has lots of parentheses but it turns out they make the syntax uniform. One can think of them as do-end blocks of Elixir. Because of this homoiconicity, professional editing tools are developed only for Lisp. For example, parinfer and paredit. These tools allow the programmer to code at the speed of thought because they allow for structural editing, meaning that the programmer works on the code AST instead of editing/typing lines one at a time.

Lisp also has an Erlang flavor called LFE which runs on the Erlang VM and allows you to take advantage of the entire OTP library and the BEAM for real concurrency, fault tolerance, and parallelism.

The list goes on. But if someone told me there's a language that offers these features, I'd quickly wanna learn the language. But quite shockingly, Lisp is one of the least used languages in the industry compared to C++, JS, Python, Java, C#, etc.

Why is that?