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.
OCaml supports imperative, functional, and OOP just fine, and you use whichever makes more sense, and it has a REPL, too, most popular one is called "utop", but "ocaml" works. As for graphics debuggers, I have no idea if OCaml has a graphical one (if that is what you meant), but there is ocamldebug[1][2].
That said, I agree, why not just use Lua? Seems like the perfect language when you only care about the game itself and not the underlying stuff. There are many other alternatives that are better than Clojure anyways. I might be pessimistic, but I doubt Clojure is going to catch on.
Well, I'll believe you about fp debugger, so only problem left with OcaML and Clojure, each of them have GC with non-linear complexity (Clojure as I understand using BEAM GC which claimed soft-realtime, meaning 90% of GC work will look like realtime, but OcaML using some typical GC), and what all these mean for games - they will suffer framedrops or even short freezing, when GC running.
Exist two approaches to overcome GC problem, but if somebody will again minus my comment I will not bother to find links in my records.
1. Here on HN mentioned GC-free fp platform.
2. Few years ago appeared GC algorithm with linear complexity (sure, with limitations, but good enough for example for 16-bit consoles level games).
Unfortunately, haters minusing comments, but don't add anything valuable, and author was not mentioned these problems.
> Unfortunately, haters minusing comments, but don't add anything valuable
Tell me about it. It happens so often that I am very reluctant to leave comments now, especially on topics that I know people have already made up their mind and are not willing to discuss it with an open mind. That said, I did just leave a comment about something I probably should not have, but oh well.
Is it really Clojure that uses BEAM? I thought it was a JVM-based language, I would have to look this up.
BTW OCaml finally has multicore support, which was a long time coming.
[1] Especially this part: "OxCaml gives programmers tools to control allocations, reducing GC pressure and making programs more cache efficient and deterministic.".
Unfortunately, I see very familiar things from Perl world - many people made really interest things alone, but for some reason, they don't organize to make one direction really on par with commercial platforms (even when with current technologies could make efficient distributed governance, and even could make significant sells for sustainable development). I mean, people disperse resources, making many good small things, but most Open Source software recessing or even in crisis without moving ahead.
I've seen JVM, BEAM, CLR at field with heavy load, they all have significant drawbacks, but from my opinion, CLR ecosystem developing faster than other mentioned.
Clojure is not a "JVM-based" language, it's a hosted language - means Clojure is designed as an abstract language that can be implemented on different runtime platforms. The language's core abstractions (persistent data structures, protocols, vars, etc.) are not tied to any particular host - it's just that JVM variant was first and remains the main focus. Clojurescript run on JS VMs, ClojureCLR on .NET, ClojureDart - targets DartVM, babashka is great for scripting, SCI - for small embedded Clojure DSLs. There is also Clojerl - that runs on BEAM, and Jank for native compilation. You can run Python in Clojure and Go, and it just keeps growing. Seriously, one could learn only Clojure and write code for [almost] any platform.
Because there isn't "true" REPL. Non-homoiconic languages don't have the same kind of REPLs, because every step in them - Read, Eval, Print and Loop have slightly different semantics.
I just wrote my Hyprland config in babashka - native Clojure scripting engine. Once I build a socket management function that connects me to hyprctl, I was able to do the rest from within my editor connected to the REPL. I would write (hypr-cmd :clients), eval it, get the list of windows in my WM, and then filter, group, sort, etc. It is so much nicer to build things "from within", most people who never experienced that, wouldn't get it.
I'm running my WM and fully controlling it by writing code and executing it in-place, from the editor running in that same WM - without saving the code, without compiling it, without restarting the WM or my editor. I'm programming my shit as if I'm playing a video game. If I was a game developer, for sure, I would stick to the same mentality - why the heck work on a game, if I can build it by playing?
Fennel already "works". There's a small community of devs around it and in my opinion and practice, it remains a better choice to use instead of Lua directly. I don't even hesitate - whenever I need to tap into Lua-based engines, I would try to bootstrap Fennel on top - I use it with Hammerspoon, with Neovim, with mpv, and if I at some point I finally decide to switch to Wez terminal, I will for sure use Fennel.
That being said, Fennel is nice but ain't ideal, it's rather weird. It tries to imitate Clojure syntactically, without actually posing as a Clojure dialect. Fennel is extremely thin layer over Lua - you're essentially writing Lua with s-expressions. In Fennel, you constantly feel Lua's presence (1-indexed arrays, table semantics, nil behavior), while Clojure abstracts over Java/JS/Dart/etc., much more heavily with its own semantics. I constantly feel like I'm missing good CLJ ergonomics - no built-in immutable data structures; no rich standard library; limited REPL experience;
The difference in philosophy is that Fennel prioritizes being "just a syntax" for Lua and Clojure prioritizes being a "better language" that happens to run on JVM/JS/.NET/Dart/etc. Makes Fennel feel more like a transpiler - remember the days of Coffeescript?
I guess, maybe all that actually makes Fennel more appealing to some - abstraction layer thickness sometimes does matter. I personally, wish for an actual Clojure dialect on top of Lua, rather than something "like Clojure".
> Lua, which is much easier to learn/use than Clojure.
As someone who used both, I can certainly argue for that point not being true at all, and in practice it isn't.
Lua's syntax is a mixed bag and even after years dealing with it, I just can't stand how ugly the darn lang is - I just never know how to format it for better readability. Metatables are powerful but conceptually complex; global by default and 1-indexed arrays - who the fuck even thought it was even worthy to call it "an idea" - those are just plain stupid. Nil handling can also get weird.
While Clojure for sure may feel like having a steeper learning curve, once you get past parentheses - it feels so much simpler.
As I understand, you mean, fp approach is comfortable to work with large codebase.
But in GD this is not the case, and even not was case at past.
Why so, because, at digital games dawn, hardware was too limited, just hardware limitations prohibited large projects;
when appeared big networking games, complexity shifted to server-side, so for them subject irrelevant;
now possible big games without networking, but high-definition multimedia costs prohibitive.
So, for subject only relevant small games, with small codebase, so they even avoid text programming at all and many people switched to so named Visual Scripting (google).
> As I understand, you mean, fp approach is comfortable to work with large codebase.
I didn't say anything about "large codebases" or "FP approach". I'm just saying that in comparison with Lua, Clojure holistically simplifies many aspects of the entire process - for small and large code, and not only because it's an FP language - after all, it's not "purely functional".
Clojure gets many small details right that other languages, including Lua, struggle to handle elegantly. But programmers often face a cognitive trap: once they master their language's quirks and edge cases, they mistake familiarity for design quality. What once seemed obscure becomes "the way things should be". This expertise paradox prevents them from seeing these quirks as the pragmatic obstacles they really are - they've internalized the workarounds so deeply that they defend them as features rather than flaws.
Clojure is not without flaws, but somehow, it just doesn't feel like one needs to learn a collection of language gotchas to be productive.
We can talk about philosophy, psychology, technical merits, and design of programming languages, but at the end of the day people will use whatever makes them happy. Clojure and its dialects genuinely bring joy to thousands of programmers, and I understand now why. After writing code in a dozen of languages, I see why.
Ok, I'll say more strict - I talking about GAMEDEV, not about abstract things.
And in GD, code have much less importance than in other fields.
As example, I once meet amateur of RC-planes, and looking on his setup I asked, why his electronics is so simple, as I understand, he could make much more sophisticated things.
Answer was: "here, I want to be airplane designer, not electronics designer, so I make plane highest priority, and sure, when you will make your plane, you could make electronics priority".
Again, this is not philosophy, this is real thing - in GD language is the least important thing for happiness, in best case it is small obstacle at the way to create game, so the best language could be no language at all.
If you could suggest some way, how it is possible to do platform where programming language hidden deep under the hood, so people just don't use language at all, but things are done, this will be very constructive talk.
> code have much less importance than in other fields.
Although I'm not a game developer anymore (I've done some in the past) I still have hard time believing this sentiment to be true, even today. Game development is interdisciplinary - code, art, design, and audio all matter. But code is definitely not less important than in other software fields; it's just that games also need those other disciplines to succeed.
Yes, modern game engines abstract away low-level code and many successful indie games have simple mechanics but great art/design, still, code remains one of the most important aspects of a good game. Physics, collision detection, rendering and graphics optimization, network for multiplayer, AI for NPCs and procedural generation, performance optimization, state management, input handling - all that still needs code.
Google "Visual Scripting", "Unreal Blueprints". It is now possible to make game literally without writing any STRING of code.
Second, with development of AI more and more appearing "no-code" solutions, in some cases even capable deliver app from blueprint painted with pencil on paper.
This is interest assumption, but let's think, who are building large applications?
I've taken part at some large apps built inside one company in extremely short time.
And no, in my list only more or less adequate platforms - Perl, MS VBA on web.
And I've countless times just rebuilt some large systems from sources - FFMPEG, Unreal 4 environment, what interest, whole FreeBSD 4.x with BSD environment including XWindow is smaller than U4.
And what was really big pain, I tried to work with NASA OpenMCT, and because it was based on Javasript technologies, I spent huge amount of time to figure out, where end server-side and where begin client-side. I think you understand this is important, because each part debugged with very different instruments and techniques.
And what I must say there, games are very different in scale.
- Sure, exist very large games (named AAAA, like cinema movies, and have so huge download size, as for example new Stalker, that my friends working in telecom complained, it was like huge DOS attack when game came out). And what also interest, AAAA games tend to make their own custom game engine, yes, each game with own game engine, because for them easier to figure out in their own code than to learn ready game engines.
Also exist industry of game studios, medium businesses, but they tend to be much like big businesses just without resources to make own engine.
And also exist huge industry of independent -games (i will use indi- name), which have very small amount of code, because of tiny budgets or just "no-budget" work, in many cases literally made by one person, who making pictures, code and sound himself. And in reality I know very few cases, where indi- makes his own engine, but most others are slightly modified already known game mechanics.
What important - big business will not use subject code, nearly guaranteed, because they have very specific demands about maintenance, to fulfill them need at least medium company;
there is more probability to reach medium business clients, they are trying to be "like a big boys", but in most cases possible to achieve some understanding;
and the most probability is to reach indi- developers.
So, what we talking about now, is mostly about indi- developers, one-person sized commands, and it is very god if they will just use C-like languages, but you cannot account for them to use fp paradigm.
I cannot at the moment give estimate of distribution of game sizes, but now tend to appear more indi- developers with small games (and sure, using some made by other people.
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.