Developing a Space Flight Simulator in Clojure

Clojure / Lisp Readability and Syntax

• Several commenters coming from C-like or Scheme backgrounds find Clojure visually foreign and “noisy,” especially due to vectors and destructuring.
• Others argue that once destructuring and Clojure’s maps/EDN are understood, the syntax becomes highly readable and pragmatic, with more compact data representation than JSON.
• There’s broad agreement that the real shift isn’t parentheses but immutable, high‑performance data structures and the resulting coding style.

Macros, “Code as Data,” and REPL Workflow

• Some emphasize Lisp’s advantage: code is data, enabling powerful macros (e.g., custom control constructs, threading operators) with tiny code changes compared to non‑Lisps.
• Others push back that in professional Clojure, macros are used sparingly, mostly in libraries and “with‑context” helpers; application code should prefer functions.
• A separate thread praises the “live” Lisp/REPL experience (Emacs, babashka, Fennel) and the feeling of “playing” the system by changing running code.

Clojure and Functional Languages in Game Development

• One camp sees projects like this and native Clojure variants (e.g., Jank) as potentially transformative for some developers: REPL‑driven iteration, good language design, C++‑like performance.
• Others argue that programming is a small slice of game development; most indie devs are focused on engines like Unity/Unreal/Godot or Lua/C#/C++/Rust, not functional styles.
• Skeptics call Clojure-as-orchestrator over C++ engines a “beautiful dead end” for mainstream gamedev, citing low FP adoption and art/design priorities, plus GC concerns.
• Counterpoint: using a high‑level language for the logic while delegating rendering/physics to C++ is exactly the value proposition; maintainability of game logic matters.

Engines, Performance, and Low-Level Concerns

• Some nostalgia for “rolling your own engine,” but others note that’s now rightly seen as wasteful unless engine building is the goal.
• The project in question uses OpenGL and a C++ physics engine (Jolt); the author previously prototyped physics in Guile but prefers leveraging specialized C++ for performance.
• There’s discussion of GC pauses (with mention of ZGC) and of alternative approaches: GC‑free FP (e.g., Carp), high‑level metalanguages generating low‑level code, and functional‑friendly VMs.

Project-Specific Reactions and Wishlist

• Visuals and technical ambition are widely praised, especially given the non‑traditional stack.
• Suggested future features include docking, the Moon and eclipses, richer atmospheric/lighting effects, shared planetary datasets, and even elaborate “space war” and ocean simulations.