Hacker News Reader

Comment by iLemming | Hacker News Reader

> 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.

View on HN

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).

https://news.ycombinator.com/item?id=45158181

> 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.

> all that still needs code

Nope.

It's 2025 outside.

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.

Reply on news.ycombinator.com