As mentioned elsewhere here, Ocaml and the ML family are often cited as easy to implement other languages, due to pattern matching, enum variants, sum types, etc. Since newer languages like Rust and Swift copied those features, you might be more interested in them since they're more popular than older ones like Ocaml and Haskell. Personally I like the syntax sugar in Swift.
> In the absence of Western tools like ChatGPT and Claude, many Chinese universities have begun deploying local versions of DeepSeek on campus servers to support students. Many top universities have deployed their own locally hosted versions of Deepseek. *These campus-specific AI systems–often referred to as the “full-blood version” of Deepseek—offer longer context windows, unlimited dialogue rounds and broader functionality than public-facing free versions.*
This makes so much sense. Are there any U.S. universities doing this?
A caipirinha with vodka is called a caipiroska. I name my computers after caipirinha varieties. Once at the office my laptop screensaver was showing "caipiroska" and a Russian guy exclaimed, "what's that?!?" Apparently "piroska" has a certain connotation in Russian that's nsfw.
More context at:
"Moonshot's Kimi K2 uses a 1T-parameter MoE architecture with 32B active parameters and outperforms models like GPT-4.1 and DeepSeek-V3 on key benchmarks"
<https://www.techmeme.com/250712/p11#a250712p11>
I've been in too many conversations where this topic comes up, and it's very disheartening to me. Gamers insist there are plenty of great narrative games, and every example they give is basically a branching story with bunch of flags that gate which branches can be taken. If I give the Holodeck as a counter-example, well that's just too pie-in-the-sky.
These conversations remind me a lot of Paul Graham's Blub Paradox: "Blub is good enough for him, because he thinks in Blub." Current SotA narrative games are good enough for most gamers, because all they've played are branching story games.
The complex emergent narratives people love in Dwarf Fortress or Caves of Qud aren’t branching stories though?
If the argument is “let’s build games that tell character stories as complex as Last of Us with the world building techniques of Dwarf Fortress”, it might be worth considering why 1) it wouldn’t be feasible and/or 2) it wouldn’t lead to a game that’s as fun/compelling as a more narratively linear counterpart.
The narrative in Last of Us is compelling because it’s tight and focused and authored by the authors to be told in a very specific way.
The “emergent narrative out of raw world simulation” argument sounds like filming thousands of hours of security camera footage and expecting Citizen Kane to come out of it.
I mean again, I would be pretty receptive to a “this game had the right idea, we should push it further” argument, but the “I’m a visionary game designer who hasn’t shipped a game that embodies my vision AND the thousands of other game designers are clueless, but everyone will see how clever I was in 3 centuries” argument rings pretty hollow.
For what it’s worth, Chris Crawford’s tool (http://storytron.com/) is a branching story editor, and one that seems much less powerful than what is used in the industry (eg articy).
You haven’t played dwarf fortress or caves of qud and it shows. Great example of armchair designers insisting they know better than all the gamers and game creators immersed in the art.
Chris Crawford's tools for interactive storytelling may have failed, but he was a huge inspiration for me in my game dev career, and I still harbor aspirations in "interactive storytelling" due to his influence.
I first attended CGDC in 1994. It was two years after his Dragon Speech (which I knew nothing about), but the highlight of the conference was his talk about the challenges of story-based games. The part I remember is how he modeled stories as branching trees with fan-out, foldback, tree-of-death, etc (he covers this in the "Architecture" chapter of this book "The Art of Interactive Design"). I didn't really follow Crawford's work on Erasmatron or later, but by the late 90's it sounded like his story model had changed from a tree to a graph network structure, like a finite state machine. While it was an improvement, I was a bit skeptical that this model was enough. Nevertheless, I spent a lot of time thinking about the problem. You see, he'd already infected me with his dream of interactive storytelling.
By the time I moved to California and took a job at EA/Maxis on The Sims 2.0 team, I had decided that true interactive storytelling (as I saw it) was not possible until game AI was sophisticated enough to enable autonomous NPC chatbots. So I put that dream aside while I pursued a career in software development.
Here we are, over a quarter of a century later, and that AI technology is here now. For those of us who have been waiting for this moment, it is almost miraculous. It might be the end of an era for Chris Crawford, but it is just the beginning of the AI-based interactive storytelling era.
In many ways Chris is ending things just as his dream is about to come to fruition. His vision was just 40 years ahead of the technology. If only he could stay engaged another 10 years. The best times are ahead of us
A few months ago someone here reported on making text adventures with language models. If I remember correctly, a problem is that it is not trivial to control the AI in a way that players can't cheat on puzzles.
This sounds like that Yogi Berra-ism, "No one comes here anymore, it's too crowded."
I suppose well over half of the people who read HN are too young to remember the dotcom craze. Everyone had every scrap of money tied up in tech stocks. IMO, the hype over AI is relatively small compared to other hype cycles. The goofiest part was the endless predictions about the singularity, and "you don't know what exponential growth looks like, man!". I mean, it can still happen, but for a while that's what AI was all about.
I agree that a debugger is a great tool; in particular, knowing how to set conditional breakpoints and how to read a stack trace allows you to do things that are nearly impossible in other ways. I can give a example story below, but first:
There's a larger point here that *debugging methodology* in general is a key skill that many programmers seem to overlook or take for granted, and even think they are good at it while making wasteful mistakes -- real Dunning-Kruger material here.
* I can't tell you the number of times I've seen developers get a hunch and waste too much time going down a rabbit hole, instead of devising a test to attempt to disprove the hypothesis before plowing into a huge code review and seeing ghosts in every shadow of the codebase.
* Print statements for debugging aren't necessarily always the wrong tool, but the mindset should be that they are code and can have bugs too. Good debug logging should be part of the code telemetry infrastructure, so you can toggle it on/off. If it's going to be written and deleted, then use a debugger instead.
Actually this post is getting long so I'll stop now, but I could go on for several paragraphs.
Oh wait, I promised a debugger story. One time I started a new job, they assigned me a bug that other developers had spent a lot of time on but never resolved. It was a random crash, in a game, that rarely happened in less than 12 hours of continuous runtime, typically after 18 hours. The crash occurred even when the game was idle with no player input. The crash stack trace was very different in many instances, so the failure was happening some time/distance after its cause. My first pass was to devise tests to eliminate subsystems: try to repro the crash after disabling all graphics/animation, another test that disabled all audio/input, etc. That led to narrowing it down to a problem with the music. Telemetry showed no memory leaks, it was not running out of heap. The music playback was in a thread, double-buffered. I added a bunch of conditional breakpoints that were based on assert-like conditionals. One of those caught the interrupt happening in between two statements that should have been in a critical section. Instead of using a mutex around the whole thing, I just switched the double buffer logic to a queue, which resolved the problem.
I too have been on Mac for over 20 yrs, but day-jobs are sometimes on Windows. Currently I work in Ubuntu under Windows on a Lenovo X1 Carbon. I feel the same about moving away from Mac. Apple's hardware planned obsolescence/deprecation schedule would have been reasonable during the Moore's Law era, but it feels too fast now, so I'm looking at migrating to Linux on Framework laptops. I don't play games much anymore so don't really need Windows.
Linux is fine, it's similar enough to macOS (and Windows, for that matter). For my tastes, all the OSes require some tweaking and compromise. I don't understand the fascination with tiling window mgmt, and disable it everywhere (was surprised it got added to macOS Sequoia). I love having different wallpapers on virtual desktops. Etc etc, there are all sorts of different setup options are available on one platform but not another.
It turns out that my stumbling block is the trackpad and keyboard -- I know this issue is highly specific to each individual, so you may not care about this. I haven't tried them on a Framework laptop but they're both horrible IMO on the Thinkpad. (Other people tell me that I'm crazy and they love the keyboard, so YMMV.) The trackpad feels like plastic crap and responsiveness is subpar. Causing a right-click by pressing slightly right of center is annoying. The page up/down keys in the inverted-T pad get in the way. Even on Mac, I didn't like the era of full size left-right arrows, and bought a couple spare old Mac keyboards that don't have those keys. Thankfully Apple fixed that in more recent designs.
Since I code all day, I'm constantly using the key sequences for copy/paste and search/replace. Maybe with time you can switch your muscle memory for these things, but I think it's simple to do these things on a Mac keyboard and not quite as easy (e.g. ctrl/shift-insert) on Linux/Windows.
However, the issues that you'd run into are most likely going to be different than the ones I did. You're probably just going to have to try it and find out if you like it or not.
Oh it's nice to see productivity ones. I mostly use bookmarklets on my phone to fix annoyances bc on a desktop browser you can just open the js console or inspector.
Also I found it useful to compare other people's implementations to get a feel for different approaches. See this suggestion: https://news.ycombinator.com/item?id=28479120