I'd argue you can have much more precise definition than that. My definition of intelligence would be a system that has an internal of a particular domain, and it uses this simulation to guide its actions within that domain. Being able to explain your actions is derived directly from having a model of the environment.
For example, we all have an internal physics model in our heads that's build up through our continuous interaction with our environment. That acts as our shared context. That's why if I tell you to bring me a cup of tea, I have a reasonable expectation that you understand what I requested and can execute this action intelligently. You have a conception of a table, of a cup, of tea, and critically our conception is similar enough that we can both be reasonably sure we understand each other.
Incidentally, when humans end up talking about abstract topics, they often run into exact same problem as LLMs, where the context is missing and we can be talking past each other.
The key problem with LLMs is that they currently lack this reinforcement loop. The system merely strings tokens together in a statistically likely fashion, but it doesn't really have a model of the domain it's working in to anchor them to.
In my opinion, stuff like agentic coding or embodiment with robotics moves us towards genuine intelligence. Here we have AI systems that have to interact with the world, and they get feedback on when they do things wrong, so they can adjust their behavior based on that.
Are you absolutely positive? Danes and Germans already sent troops and France a nuclear sub and a Frigate. UK, Sweden, Finland and others are preparing to send troops as well. Perhaps "small operation" is not a foregone conclusion.
80% of the place is frozen ice - you would need specialist units to fight there - US has never done that really - the Russians had units equipped for arctic conditions and they were locals and had unique armor meant for that (tracked-lighter-more durable).
Even China has more experience due to their conflicts in the Himalayas and Tibet.
You not going to get a Stryker or Abrahams tank working there.
Good point. Ukraine example:
"Battlefield Challenges (Abrahams): Despite being formidable, these tanks struggled against Russia's extensive drone warfare, leading to high attrition rates, with nearly 90% of the original U.S. fleet lost or damaged..."
Whatever military capability there is in NATO, it's clearly on the side of the US. The EU can't even produce basic things like artillery shells and explosives at this point. The UK can't even make steel.
I don't think America ever said that Greenland would be a state, that it would be an overseas territory of the US instead, which still sucks, but I don't think Trump wants 2 senators and 1 house member from a territory that is bound to be much more liberal than the average American state. Inuits vote Democrat even in Alaska.
In my view, this is the exact right approach. LLMs aren’t going anywhere, these tools are here to stay. The only question is how they will be developed going forward, and who controls them. Boycotting AI is a really naive idea that’s just a way for people to signal group membership.
Saying I hate AI and I’m not going to use it is really trending and makes people feel like they’re doing something meaningful, but it’s just another version of trying to vote the problem away. It doesn’t work. The real solution is to roll up the sleeves and built an a version of this technology that’s open, transparent, and community driven.
Most pixelation libraries take the lazy route where they just downscale the image and then upscale it back with nearest neighbor interpolation. It's fast but the results are usually pretty messy because the grid just cuts right through important features like faces or distinct edges. You lose a lot of the actual character of the image that way.
I tried something different where I treat pixelation as an optimization problem rather than a simple scaling operation. Instead of forcing a rigid grid onto the image it adapts the grid to match the underlying structure of the picture. The end result is pixel art that actually preserves the semantic details of the original image while still nailing that low-res aesthetic.
The secret sauce here is an edge-aware algorithm. It starts by running Sobel operators to detect edges and gradient magnitude. Once it has that data it initializes a standard grid but then iteratively moves the grid corners around to snap them to those detected edges. It uses a search-based optimization to test local positions for each corner and finds the spot that aligns best with the image boundaries.
It’s definitely heavier than the naive approach but optimizations to keep it usable. The edge detection runs on WebGL so you get a massive speedup there and it uses spatial hashing for O(1) lookups during the rendering phase. On modern hardware you are looking at maybe 100 to 500ms per image which is fast enough for most purposes. It’s pretty cool seeing the grid warp to fit the content rather than just chopping it up blindly.
That's literally the whole point of using a high level functional language though. You use it to express the business logic of your app, the code that you care about. The fact that the underlying details of how rendering and physics are done is written in an imperative language doesn't really matter here. What I care about is maintaining the logic of my application, and that's what a language like Clojure makes easier to do.
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.
Personally, I’ve had a pretty positive experience with the coding assistants, but I had to spend some time to develop intuition for the types of tasks they’re likely to do well. I would not say that this was trivial to do.
Like if you need to crap out a UI based on a JSON payload, make a service call, add a server endpoint, LLMs will typically do this correctly in one shot. These are common operations that are easily extrapolated from their training data. Where they tend to fail are tasks like business logic which have specific requirements that aren’t easily generalized.
I’ve also found that writing the scaffolding for the code yourself really helps focus the agent. I’ll typically add stubs for the functions I want, and create overall code structure, then have the agent fill the blanks. I’ve found this is a really effective approach for preventing the agent from going off into the weeds.
I also find that if it doesn’t get things right on the first shot, the chances are it’s not going to fix the underlying problems. It tends to just add kludges on top to address the problems you tell it about. If it didn’t get it mostly right at the start, then it’s better to just do it yourself.
All that said, I find enjoyment is an important aspect as well and shouldn’t be dismissed. If you’re less productive, but you enjoy the process more, then I see that as a net positive. If all LLMs accomplish is to make development more fun, that’s a good thing.
I also find that there's use for both terminal based tools and IDEs. The terminal REPL is great for initially sketching things out, but IDE based tooling makes it much easier to apply selective changes exactly where you want.
As a side note, got curious and asked GLM-4.5 to make a token field widget with React, and it did it in one shot.
It's also strange not to mention DeepSeek and GLM as options given that they cost orders of magnitude less per token than Claude or Gemini.
reply