klibertp

I suspect the GP might not like Rhombus because it uses indentation (like Python) for code blocks instead of braces (which isn't actually Algol-like; IIRC, Algol mostly used parentheses). In that case, even Pyret wouldn't work for them.

Personally, I'm still (25 years into programming) undecided: does syntax not matter at all, matter only a bit, or is one of a language's most important characteristics? It's incredibly hard to say, at least for me.

Take a look at Racket (or Rhombus if allergic to parens). Support for contracts there is stellar and provides everything you mentioned. You can use `define/contract` for inline contracts, or you can attach contracts when exporting names from a module using `contract-out` declaration. Contracts are first-class, can be defined separately and attached wherever you want (importantly, this includes values (structs, classes) as well as functions). There are higher-order contracts that generate new contracts from existing ones. There's support for both static and dynamic metadata for almost all kinds of entities in code (ie. both the syntax and the semantic entity it produces can be annotated with anything). I wouldn't recommend using Racket/Rhombus in production, but it's a great preview of what might become commonplace in a decade or two :)

See the papers "Soft Contract Verification" and "Soft Contract Verification for Higher-Order Stateful Programs" (Nguyễn et al.) In general, there's a lot of academic work on the topic coming from the Racket community.

In short: yes, some classes of contracts can be statically proven. Not all of them, and it depends on the language's semantics, so it's probably not easy to retrofit into C++. But there's work being done on unifying types and contracts, moving back and forth between static proof and dynamic enforcement, and it's all pretty interesting. Proving contracts statically eliminates runtime overhead; generating contracts from types makes it possible for a gradually typed language to be sound.

PvE vs. AI on maps larger than 10x10 slows down to a crawl after ~40minutes. It's not FPS (which remains perfectly smooth), though: it's the simulation speed, influenced by pathfinding, trajectories of every single projectile, managing construction, managing units' scripted movement, and all the AI decision-making. Plus the performance penalty of using Lua (and its GC) for parts of game logic. Apparently, all of that is crammed into a single thread, and by the time you have 1k units, simulating 1 second of in-game time can take 3-4 seconds (or more, obviously, depending on the CPU; but single-core performance stopped improving drastically at some point). It's been a few years since I last checked, but I'd be surprised if anything beyond 20x20 maps would be playable against the AI, even today. And since it's a matter of codebase architecture, fixing it would require a rewrite (someone in this thread is actually attempting it, which could be fun).

Queuing orders in TA and then in Supreme Commanders was best-in-class. Both single units and structures, and groups of them (selected with an assignable hotkey), could have infinitely long command queues. Patrol mode was useful for both engineers and normal units. SupCom added air- and sea-based transportation corridors. The queues were not broken if you ran out of resources temporarily; they just paused and then resumed when possible. I played TA before StarCraft and after Warcraft 2 - I felt SC to be a huge downgrade in terms of controls, and dropped it almost immediately. SupCom then came close to the absolute peak of RTS for me in terms of controls, physics, and economy management. The problem with all the fan-made successors is that I don't want PvP at all, and they seem to focus on that, while the original TA and SupCom were incredible single-player experiences, too.

> will oppose AI because it's too hot

This is actually a defensible position. It's not either-or - the "gross chuds" doing things you mention are worrying, too. But providing unrealistically attractive depictions of a human body is also a problem. It's been a problem for ages - all the girls and women who try to compete in beauty with celebrities and models (without a team of specialists supporting them), only to ruin their bodies through anorexia or bulimia, or their minds with depression, deep insecurity, and an inferiority complex, exist and deserve mention. AI(-generated images) is not the reason, but fits "well" into the preexisting social problem, and has a chance of intensifying it on a global scale.

You're lucky, since it probably means you never got hit with serious, high-level LinkedIn-speak. People speaking like this exist: I only had one or two interactions, but I honestly ran for my life and sanity as soon as I could. It's eerie, and both possible interpretations ("this guy speak like this for a reason (I'm not going to like that reason)" and "this guy honestly believes what he's saying (is he mad?)") are frightening. I feel really fortunate to only really encounter them IRL this rarely.

HN is an ad platform - it's just maintaining the old style of providing actual value to bribe users into accepting the occasional ad organically, instead of min-maxing for engagement and providing nothing else.

Mentioning LessWrong and 4chan in the same breath made me chuckle, but it's actually a good summary of the modern Internet: to be ad-free, you need to either care very much, or simply not care at all. The middle of the road has been bought, fenced, and you need to pay (with money or attention) to access it.

Agreed - the circumstances indeed changed, and the possibility of automatically generating code from a natural language prompt is something we didn't have ever before.

As an Emacs user, I can testify that it's a game-changer. Codex CLI paired with `emacs --batch` is perfectly capable of setting up, developing, and testing just about any kind of extension you'd want. And with packages integrating LLMs into Emacs, you don't even need an external harness - open a buffer, type a prompt, get a useful extension or customization. It really works quite well.

But I stand by my opinion: Emacs is just one piece of software, not completely unknown, but rather niche, all things considered. Almost no other app supports seamless extensibility at Emacs' level (not even web browsers come close, and not by accident - it was a conscious decision to drastically limit what plugins can do).

Most programmers don't feel the need to make their apps easily and deeply extensible. Most users don't feel the need to extend their apps - even simple customization is rare. Most product owners don't want users to have "too much" freedom to change things.

So, while LLMs do give us a realistic path towards making extensible/malleable software attractive to users, almost nobody is taking that path right now. Realizing LLMs' potential in this area requires large parts of both the user and developer populations to recognize the possibilities and then actively pursue them for a few years. For now, it doesn't look like anything like that is happening.

> Its quite reasonable to assume a future operating system

Possible, yes. Reasonable to assume? I don't think so.

The issue is that we had that for a decade or two already: people who lived through the era will tell you more, but Smalltalk environments and Lisp Machines already realized this "malleability" to the extreme and... died. We got DOS instead; the rest is (a pretty shameful) history.

Emacs is just about the only artifact (along with Squeak-derived Smalltalk-likes) of the era that still exists and is in popular use. The PC revolution killed interactive, vertically integrated, fully programmable environments. It happened because of hardware limitations of the time, but the consequences are cultural: the LispMachine-like environment simply faded from the collective imagination of programmers who learned programming by writing "resident programs" for DOS in assembly. It didn't happen immediately: DOS was sufficiently open for modification that (if you knew x86 assembly) you could mold it to your preferences, but the hardware wasn't powerful enough to do much with it. As hardware advanced, PC OSes ossified, adding abstraction level after level in both hardware and software. Early Windows was trivial to dissect - I remember WindowBlinds, a set of apps that transformed Win 95/98 into almost anything you wanted. I recently checked, and nothing like that is possible in the recent Windows versions. GNOME on Linux seems to have followed the same trajectory (fortunately, there are still a few other desktop environments there).

So I don't think the "malleable software" is going to return any time soon. We have not only rigid software everywhere - we have 30 years of shared culture of developing and using such rigid tools. With the size of the programmer population, changing that culture in any meaningful way seems very hard. There will be people who rediscover Lisp Machine ideas, there will be a segment of users swearing by Emacs and similar apps, but we'd need a revolution in corporate and educational policies to get anywhere beyond that, I think.

My internet provider in the early 90s maintained a Unix system with pine and lynx; it only allowed access to WWW a few months after we subscribed to their dial-up. I didn't know what to do with that remote system, but I knew `cd` and `ls`, so I looked around. Somewhere on the filesystem, I found a Hexen (IIRC) demo, and decided to download it via Kermit (the only tool/protocol I knew how to use). It took almost a day to finish, but in the end it ran - I was overjoyed. I somehow even found a cheat code for all weapons, and spent a few weeks playing the first 2 levels, while occasionally poking around in the remote system. Then the phone bill came - for 7x more than normal, on top of the ISP subscription - and I lost access to both the Internet and the computer for more than a month. Needless to say, I learned to watch that connection timer like a hawk, and it served me well for the next 10 years before broadband connection was available.

Interestingly, an almost identical proverb exists in Polish ("him" is replaced with "swine" canonically, but it's often replaced by a person's name). It's used to suggest that someone is either too dumb or too self-assured to accept criticism. Is the intended meaning similar in Greek?

What's funny is that with Sol, I added an instruction to AGENTS.md in one project to prefer sed/python ("deterministic tools" in general) for moving code instead of deleting it and rewriting it elsewhere from memory, because otherwise it butchered comments. After switching to Astra, I saw it suddenly do this for all edits in all projects, which isn't great: the second argument to `replace` is still written "from memory", but now you need to unravel the Python script before you can understand what was actually changed.

Yes, large. I haven't used Zig much myself, but from a few experiments I ran, Zig handles dead code elimination exceptionally well. It compiled a full Win32 GUI calc app that used Capy (a full, cross-platform GUI framework) into a 133kb executable. Removing Capy completely and using Win32 APIs directly produced an even smaller (93kb) binary (it also removed some DLL dependencies, leaving basically only ntdll.dll). For the same task, Rust + Slint produced a 4.7 MB binary that still depended on multiple (non-Windows-provided) shared libraries.

Given another commenter's mention of a similar project written in Nim that yielded a 1.6 MB binary, my first guess is that the 6 MB Zig binary simply isn't optimized for size - it might be a debug build. If not that, then I'm not sure what's happening, but yeah, in the context of Zig, 6mb for a CLI app is a bit strange.