Developing a Space Flight Simulator in Clojure

> It would be nice and welcome, but it wouldn’t revolutionize anything.

I dunno, it'll certainly revolutionize my world once it's ready. A editor connected REPL, changes to running games on the fly while keeping existing state, using a well-designed language like Clojure but getting the performance (or similar) of C++ and native binaries.

It's pretty much a win-win-win for me, especially if I can replicate the speed of development I get with normal Clojure but for game dev.

> Programming is a tiny part of game development.

This is a weird take. It's a tiny part of game development until you can't program. Then you realize it's actually a huge part. Particularly for "indie" game development.

Ultimately code is just a tool, but it's still a tool that can translate into rapid iteration or into friction.

> Programming is a tiny part of game development.

Yeah, jut like writing is a tiny part of book publishing. What the heck are you even talking about? Programming is absolutely fundamental to game development - it's literally what makes games exist and function.

I'm not talking about "revolutionizing" anything, but maybe you haven't noticed how Unity democratized gamedev and how GDScript made game logic accessible. There is absolutely a sizable chunk of the market for the Lisp-based gamedev - look at Lua/Fennel gaming community - LÖVE2D, Pico-8, Defold engine, etc.

Having performant Clojure option (which Fennel ain't - it's only "like" Clojure) would be absolutely wonderful news.

Then there are folks like Notch, that by not following such advices got gold, as they managed a great additive game, regardless of the technology stack being used.

There is also 80% of the mobile phone market available, in the context of JVM like ecosystem to target, and avoiding NDK tooling is gold if one really doesn't need it, as its experience still sucks after all these years.

> you're competing against Lua

There's not exactly tiny community (but it's not huge either) that programs against Lua-based engines using Fennel - a Clojure-like Lisp. Jank, aimed to have one-to-one Clojure-parity, I think would be great news.

> the people in this space aren't dreaming of programming in a functional style.

IMO because they are extremely pragmatic and there still, doesn't exist a good, practical way to program games in a functional style. Jank may open that possibility.

it's not code it's data. :) -macro

Fun fact: the big difference isn't the syntax. Lisps only go from foo(bar baz) to (foo bar baz) which is a change but not really much of one. The change is actually the immutable and high performance basic data structures. Clojure can do something that something like C can't do - cheaply create a copy of something with a small change. That leads to a completely different preferred code style in the Clojure community that is a big departure from C-like languages which make heavy use of variables. The code is doing something practically different from what a C-like language can ergonomically handle.

Lisps (like Clojure) treat code as data (lists), so you write: `(if x (y) (z))` instead of Python’s `y() if x else z()`. So the code is more concise, but does less to walk a novice through it.

This gains a huge advantage, which allows even more concision: all code is data, so its easy to transform the code.

In Clojure if you want to add support for unless, a thing like if, but evaluating the opposite way you could do this: `(defmacro unless [p a b] `(if (not ~p) ~a ~b))`. Obviously if you wanted to do the same thing in Python you would in practice do `z() if x else y()`. However, you would do it that way because Python isn't as powerful a language. To actually do the same thing in Python you would need to...

1. Add __future__ support.

2. Update the Python language grammar.

3. Add a new AST type.

4. Add a new pass stage to the compiler.

5. Add a python library to integrate with this so you could use it.

Then you could do something like:

    from __future__ import macros

    defmacro unless(pred, then: block, else_: block = []):
        return q[
            if not u(pred):
                u*(then)
            else:
                u*(else_)
        ]

So in the trivial case its just hundreds of lines harder plus requires massive coordination with other people to accomplish the same feat.

This sort of, wow, it takes hundreds or thousands of lines more to accomplish the same thing outside of Lisp as it does to accomplish it within Lisp shows up quite often; consider something like chaining. People write entire libraries to handle function chaining nicely. `a.b().c().d().map(f).map(g)`. Very pretty. Hundreds of lines to enable it, maybe thousands, because it does not come by default in the language.

But in Lisp? In Clojure? Just change the languages usual rules, threading operator and now chaining is omnipresent: `(->> a b c d e (map f) (map g))`. Same code, no need to write wrapper libraries to enable it.

That's just existing muscle memory. Nothing is wrong with you and nothing is wrong with Clojure. I had the same feeling when I started with Lisp. Give it some time, it's absolutely worth it. Interestingly, every single programmer I introduced to Clojure as their very first programming language had no issues picking it up. Later, they complained about difficulties getting used to Javascript and Python.

Many of Lisp ideas are possible in C++, but I guess that depends how much you know it.

No, that's rightfully viewed as a waste of time if you want to make a game (vs if you want to make a game engine)

The hardware graphics acceleration stack is heavily shader-based now, so there's less and less graphics code being written in systems languages like C. In a way, people are still writing their own graphics engines, it's just for such a different platform from the unusual Turing-computer CPUs that all the old techniques go out of the window.

Nothing stopping you from writing it the old fashioned way though - you can just keep generating a single screen texture in the CPU and let the GPU idle!

I don't know such way now.

From what I see, looking promising, to discontinue UNIX systems (based on C, and yes, Windows is also favor of UNIX, as NT was made directly on foundations of VMS from Digital), and switch to something more high-level, like OpenStep (with high usage of SmallTalk), or at least BeOS (based on C++).

Sure, would be better to use Prolog based OS, when one will appear, or may somebody will create OS based on OcaML (Haskell, Rust).

What I see problem for gamedev, in many cases they need very high performance, and when nearly all target (current) OSs are just C-machines, it is very much like discover epic huge wall, when need to switch from OcaML level to C to get additional few FPS.

So most people choose easy way, they learn just primitive subset of C++ and work with it.

https://en.wikipedia.org/wiki/Comparison_of_operating_system...

I worked with IBM PC clones and DOS for a long time. What I seen - just hexadecimal dumps, sometimes picture patterns and nearly nothing else.

Once one boy said me "this is Mac, on it things look different" and shown me just ordinary MS Office (for Mac) files in just standard utility. And I seen really other world - even on old MacOS (7..something), Office files was not just hexadecimal, but I easily see structure. Unfortunately, that's time I have not enough education in CS to understand how structures work, but some things was obvious. These was just some things partially implemented on ObjectiveC (too small objective part and too large C part), but any way it become significant shake of my world.

Unfortunately, in Linux I constantly see the same as in DOS - mostly just hexadecimal dumps, no structure, so developers don't have motivation to use structured data, as it will not help them on build and maintenance.

There is an (IMHO quite underexplored) alternative of using HLL as a metalanguage for generating low-level code. Like Chisel/Spinal does for Verilog RTL, but with C or LLVM IR instead of RTL. I. e. terra-lang did this with Lua (afair didn't took off because of unfixably bad design choices from the start).

Why this matters: compile-time metaprogramming is the way to provide zero-cost abstractions. HLLs tends to avoid metaprogramming because it's hard, instead relying on rich runtime (i. e. late binding and dynamic dispatch). Sometimes (i. e. in game engine code) that's not really an option. And metaprogramming is best done is something lisp-like, rather than C-like or C++-templates like.

As to why this is underexplored, I think there are multiple reasons:

- The most important one: those who care about the language tends to spend so much time on the language that they never get to the actual product,

- We already have C++ templates which can do anything (they are also an unholy ureadable mess because they were invented for a completely different purpose) and C macros (which are also unholy unreadable mess because K&R hated macroprocessors passionately and curbed cpp to a bare unusable minimum). And people exposed to those conclude that any compile-time metaprogramming must necessarily be an unholy unreadable mess not worth exploring.

- Most library bindings are in C, so any such system should include a C parser. At which point you wonder why bother at all?

From second view, looks like good way using ECMA-6 (for example) with Babel and some things added into browser debugger.

So, technically, high-level ECMA-6 language transpiled (more traditional word translated) to ordinary Javascript, and supplied file with structures, similar ideologically to C symbols tables, and within browser debugger (Chrome work) you could see not target JS but sources and debug on high level.

And when your code become mature, you just remove symbols tables and as usual, target optimized code become very much like obfuscated, and you could provide it as closed source.

So, as summary - must have all from list:

1. high-level language translator (may be into assembler, may be into some lover level language, as with ECMA-6 and JS)

2. some sort of debug support (as mentioned symbols tables)

3. good enough debugger, as much close to client platform as possible (Chrome is good example).

Why not use some simpler, like old good UNIX Make? Or for business logic existing for a long time Lua, which is much easier to learn/use than Clojure.

I love functional paradigm, but sometimes fp lovers, looks like evangelists of Blockchain or LLMs - not bad things, but all have their limits, and not very useful without powerful support of large library of fp structures and debugging programs. So, trying to use fp, you dive into abyss, writing with fp, but debugging with low level C debugger.

BTW, as I know, OcaML, flagship of fp, just don't have graphics debugger, so people used to write on Haskell using old classic REPL technology, than, thanks to syntax similarity, most code just compile on OcaML without additional moves.

> Computers are stateful and imperative

This is semi-Truth.

Modern off the shelf Microcomputers nearly all imperative, because marketing won, but when world was under Mainframes (nearly up to 1980), existed many examples FP-optimized architectures or high-level architectures, even some of them was commercially successful (Lisp computers and some high-level mainframes).

Also, most developers don't deal with naked hardware, but working with libraries of structures and libraries of high level algorithms, this named abstraction layer. Just some existing abstraction layers are less abstract and other are more abstract. As example, in Windows (and in most UNIXes) file abstraction is very simple and just imperative, but in MacOS it is OOP (derived from NEXTStep as I hear, based on ObjectiveC), and also exist some other OSes based on OOP languages, like BeOS, even when MacOS/BeOS are now running on same x86 hardware.

So possible just run inside higher level VM.

And mathematics is not prohibiting FP-machine, they could have very effective implementations with modern math.

What really problem, except of Prolog, I don't hear about high-level debuggers for fp languages, so writing on for example Ocaml, you once end up looking on fp structures with old C debugger, which sure don't see fp structures.

Just for test purposes.

        ─────────────    
       /             \   
      /               \  
     /                 \ 
    /                   \
    │                   │
    │   circle of power │
    │                   │
    │                   │
    │                   │
    \                   /
     \                 / 
      \               /  
       \             /   
        ─────────────