Also thanks for the SteamDeck support!

The basics:

- SBCL: generates fast[0] code. runs well on windows

- Quicklisp: The package manager which lets you install the packages mentioned below

I've got a video here that should help with getting set up on windows https://www.youtube.com/watch?v=VnWVu8VVDbI&t=1s

Then you could try the SDL2 approach:

- cl-sdl2: Bindings over sdl2 https://github.com/lispgames/cl-sdl2

- cl-sdl2-mixer: audio playback https://github.com/lispgames/cl-sdl2-mixer

- Some basic math library like: 3d-matrices, rtg-math, sb-cga

Or maybe an existing engine:

- https://github.com/borodust/trivial-gamekit

Come down to #lispgames on freenode if you need a hand as there is usually someone there who has touched this stuff[1]

I'll also pimp my own stuff while I'm here just in case someone is looking for a lispy layer over gl

- https://github.com/cbaggers/cepl

Main downside of Common Lisp is that Emacs or Vim are pretty much a requirement to get a nice development environment, without which you are pretty much in 'writing Java in notepad' territory.

[0] for some definition of fast that I don't want to belabor this comment with.

As aidenn0 mentioned portacle will hopefully be a good option for some when finished as it gives you a complete environment in one shot.

For installing CL I may update my video to use Roswell at some point, I've been having good success with it when using TravisCI.

Fun! CL is a language to play in, after a day of wrangling Java & ObjC issues I love settling down to just play in an environment that lets blast some code out and play with ideas. Of course this applies to other languages too and this is dependent on your interests, so the case I want to put out there is:

Even if a language isn't suitable for your current business needs, see if it gives you joy. Languages have trades offs to meet their goals, evaluate languages for pleasure too.

Also come visit #lispgames on freenode sometime..most of us are procrastinating making engines but it's always nice to have new folks around.

Eventually though this will be a huge boon.

If you are interested in this stuff also look at kovasb's gamma library for clojure or any number of cool project for haskell.

Obviously these very different beasts with different goals, but the sheer scale of the old zeppelins never fails to make me happy.

- Elm dropped frp [0]

- Even in it's older frp incarnation, elm didnt allow changing of the flow graph (sorry I cant remember the correct elm term for this) while the program ran [1], making it hard to say this would be an ideal way to go for true 'interactive coding' for games.

To clarify my opinion I would like to add that I am assuming an ideal of 'interactive game coding' where one would start a GL context & repl session at the start of the day and make the game whilst never closing the session or killing the context.

The OP limited himself to retrogames which is a wise move for exploring this topic, _one_ of the things that makes writing modern games hard is the extent to which you are pushing what the hardware can do. It is normal to be required to really be strict about what happens when in each frame and it's not possible to do this if, part-way through rendering you have to process events coming from some input thread that has no idea about the context your program is in.

Lastly I would add that your program itself is state. Interactive programming requires you to create and remove functions from your running program and bugs particular to doing this can occur (some object has a reference to a version of a function you have removed etc etc). Unless we move to a point where our code (compiled & text) live in a some persistant data-structure that allows rollback in some meaningful way I find it hard to imagine _real_ functional interactive programming.

This is a cool topic and ripe for discussion and progress, but just dropping in interactive programming does not in itself make game coding easier. However it is a pile of fun.

[0] http://elm-lang.org/blog/farewell-to-frp [1] https://www.youtube.com/watch?v=Agu6jipKfYw

> Not really; it will clash

Nope, named-readtables fixed the clashing reader-macro issue a good while back.

> You mean ... programming the programming language?

Yes, I do. I said it the way I did out of choice, as the 'programmable programming language' phrase has been bandied around so often that, for some, it has lost impact. Maybe that phrase doesn't inspire the same ahah moment in some as it does for other. Saying the same thing in a different way can be enough for someone to pick up something new. (It feels weird writing this down as it's kind of self evident)

> Do you plan to type "lambda" with args enough times to eventually that hour of your life back

I that hour was spent learning about reader macros, learning something new is of value to me, so there is no 'lost hour' to reclaim. Don't you just code for fun some days, without worrying if it is somehow ultimately useful?

> Note how if we take λ(* _ _) and then just move the parenthesis over the Greek symbol, we get (λ * _ _). This saves almost the same amount of typing

Ah ok, maybe this is where we parted mental ways. I'm not interesting in saving typing, that wasn't the goal. The point was to remove a little visual obstruction from what I was doing. For example (and yes it is a trivial example) (lambda (x) (* x x)) is 20 characters long, of which 8 are of interest (* x x) I liked that the shorthand reduced a little visual noise.

Yes there are many ways to skin this particular cat, but I liked the shorthand. I also like not having the lambda in the first position as it maintained a property of lisp code I generally enjoy, that I can run my eyes over the lefthand side of the forms and quickly get a rough feel of what is going on. Again, this is just a personal feeling, but some days I write code just for me, for fun, so why not make things pleasant for myself.

It's rather odd to get into a discussion about this, when the whole point is that we don't have to pick one golden way and enshrine it in the language. It's just a library, use it or don't, it doesn't matter.

Peace

The best bit though, is that this isn't some nasty hack. This is supported by the spec, so I can package this up and let other people us it just like any other functionality we care to ship around.

That's my favorite thing really, being able to treat approaches to writing code in the same way we treat the functionality we make using code.

Regarding the authors issues, the APIs are very ugly, especially in GL where you have two apis smashed together (pre v3.1 and post). I'm not qualified to comment of DirectX but I feel in the GL case there is a fairly nice API buried in the madness, and that with a suitably flexible language you can making working with it rather pleasant without resorting to tools that totally separate you from the lower levels.

Vulkan is no panacea (nor dx12) because with control comes the associated complexity. Vulkan is going to be awesome for folks making engines, languages or those who just want absolute control. But Khronos are very open that these Vulkan & SPIRV are not replacements for GL/GLSL. The increased variety of APIs that will be possible for people to make WILL be exciting though and that is worthy of celebration, as will be mixing and matching the above.

Re the "impoverished GPU-specific programming languages" comment. Limiting the scope of a language can give you valuable places to optimize and one of the primary concerns for this hardware is speed. As an exercise/strawman add pointers to an imaginary gpu language and work out how to keep the performance you currently have. This is going to become more evident as languages come out that compile to SPIRV and we get to see behind the curtain at just how hard it is to make code run fast against the various hardware approaches to render that exist in GPUs (for a case in point see 'tiled rendering').

Im unsure around the 'interface too flexible' issue as GPU resources are still valuable enough that being able to unload code is still useful, and at that point you have to rely that the pipeline you load follows the interface you expect it to, as you would with any shared library. Even when you take away all the api ugliness you are still left with the fact you are talking to a separate computer with separate concerns, I'd rather embrace this in a way that feels natural to your host language than hide this separation which makes certain issues (e.g synchronization) harder to deal with.

Regardless, this is still a valuable post and an issue worth getting fired up about, it's always exciting to see people making different ways of leveraging these awesome pieces of hardware