Athas

One of the charming parts of IRC is just how simple it is to do things with it. Much is lost in more featureful protocols.

Yes, I really wonder how they expected people would react to that.

Comic Chat is a piece of Internet history, but I remember that it was somewhat reviled when I first started being active on IRC. This was around 2002, so it was probably due to some cultural memory rather than anyone having actually used it in years.

The issue, as I remember it, is that Comic Chat extended the IRC protocol with support for explicitly indicating the appearance and emoting of your comic character, rather than relying entirely on contextual cues. This was essentially done by adding some nonsense string to every message, which presumably could be decoded by other Comic Chat users, but read like spammy noise to everyone else. I know it did that, because I remember downloading Comic Chat to check it out, but I forget whether it was the default or not.

I have never used Qualcomm's OpenCL driver, but it is not unknown to get the NVIDIA driver into a state where some kernel is stuck in a running state, or some memory is allocated long after the originating process has terminated. This is usually down to application bugs, sure - but no application bug should be able to wedge the driver. While developing GPU kernels, the code will certainly be buggy, and hence the driver should be robust. For that matter, maybe I am running untrusted GPU code, and anytime the driver gets in a weird or stuck state, I am uneasy that it might not be many steps away from an exploitable situation. We don't accept this in CPU operating systems, so why should it be acceptable for GPUs? We are talking unprivileged code - nothing runs as root. Ever since I first got into GPGPU programming (about 2012), I noticed that they were far less robust in the face of buggy code than I was accustomed to.

It is also common in my experience for buggy GPU code to crash displays if the GPU is simultaneously used to drive a monitor. This usually happens for kernels that go into infinite loops, or out-of-memory conditions.

It is my understanding that modern GPU drivers even have watchdog systems that notice when they get stuck and forcibly reboot them, which to me is mere symptom treatment.

Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!

I wrote a bit about this some years ago: https://futhark-lang.org/blog/2020-05-03-higher-order-parall... - but note that Jax isn't subject to these constraints; it's more like Accelerate and Futhark.

I'm not a Jax expert. Accelerate's 'map' allows for almost arbitrary sequential code - there is some fine print, because it's an embedded language, and the biggest fine print is that nested parallelism is not allowed. You can define your own Haskell-level higher order functions, and Accelerate will handle them just fine, because essentially all the Haskell-level computation is "compiled away" (by being run) before the Accelerate code is JIT-compiled at run-time. You can consider Haskell to be a meta-language in which you ultimately construct Accelerate program terms, and then those are compiled and run - not too dissimilar from how Jax does it, actually.

Recursion works, but for an uninteresting reason: the recursion is on the Haskell side, and will essentially be unrolled before Accelerate gets its hand on it. This allows you to do some fun things (like partially evaluating a ray tracer on its scene description), but it's often not what you want, and Accelerate provides some combinators (that look like higher-order Haskell functions) for expressing sequential looping.

One big difference compared to NumPy (which you may or may not care about depending on how picky you are), is that Accelerate is a higher-order programming model. Basically, you can have 'map' (with a user-provided function), and it will go fast, in contrast to NumPy's model where only first-order operations go fast.

Making Haskell programs go faster. I will say that Accelerate is in most cases not faster than similar libraries for other languages (e.g. Jax), but the integration with normal Haskell is very pleasant. As Haskell is a very nice and practical language for general-purpose programming, it's convenient to be able to use Accelerate for those parts where numerical performance is critical (but not so critical that you rewrite the entire program in CUDA or C).

Isn't the data they capture so valuable that they (Microsoft) are happy to eat the cost?

Even if that is true, unless the value of the data corresponds to near-term revenue, then eventually the cost may simply not be possible to meet. Or for that matter, the capital to manage the increasing load may simply not exist - it does not matter how much valuable data you have, if the supply of hardware cannot keep up with your demand.

Also, I suspect that most of the "data" obtained by the incessant hammering on GitHub is not very valuable. Most business code is routine, and getting Copilot to help out with generating enormous amounts of it may not contribute much in return.

This page reads like an exasperated response to constant discussions and requests for how to extract strontium nitrate from road flares, and emphasizes that it is hard and pointless in the first place. I never noticed such discussions, but maybe it's outside of my bubble! Quite an amusing read nonetheless.

As others have mentioned, such tools exist. However, I believe they do more harm than help. Good --help output does not make for good --man output. In particular, while man pages are terse, good ones are more than just lists of command line options, and the part of them that are a list of command line options will usually have more detail than --help. The writing of documentation is a place where I often see programmers employ automation inappropriately.

That depends on the language. I have used (and implemented) languages where arrays are modeled as a function from an index space to some expression. During compilation, this is used to drive various optimisations. For those arrays that need a run-time representation, they may be stored in the classic way (a dense region of memory accessed with offsets computed from indexes), but also in more complicated ways, such as some kind of tree structure. These are still, semantically, arrays at the language level.

The post explains that 'a[i]' can easily enough be written as 'a i'. Your suggestions do not resemble the current function application syntax in the language discussed in the post. The question is not whether a terse slice syntax can exist (clearly it can), but whether a syntactic similarity between indexing and application can also be extended to a syntactic similarity between slicing and application.

Depending on how you look at things, functions can also be mutated at run-time. Most impure languages allow you to define a function that has some internal state and changes it whenever it is applied. In C you would use 'static' variables, but languages with closures allow for a more robust approach. Scheme textbooks are full of examples that use this trick to define counters or other objects via closures. You can well argue that these functions do not "mutate", they merely access some data that is mutated, but there is no observable difference from the perspective of the caller.

In some sense, Go does not allow you to change the major version. Packages with the same name but different major versions are treated as different packages.

It is basically dependent types, but there is a specific and intentional omission (no true dependent products) that interacts with another feature (the ability to hide sizes) that ultimately causes the mess. I elaborated on it here: https://futhark-lang.org/blog/2025-09-26-the-biggest-semanti...

This blog post showcases V in a positive light. I suppose it is good that people can have productive experiences with it now, although I don't see from this post why it is a significant improvement on Go.

The problems discussed (performance, compiler fragility) are somewhat worrying though. My impression is still that V is not particularly robust and focuses on flashy things instead of getting the basics right. I must admit that it is however still hard to look at V objectively, given the near-fradulent presentation it had when it was first announced.

The greatest value brought by compiler optimisations is removing the overhead of convenience. Sometimes that is about avoiding the boxing that is a necessity in many high level languages, but in other cases it serves to allow a more modular programming style without overhead. Stream fusion is a good example: it lets you structure your program as small and composable units, without the cost of manifesting intermediate results. That is not merely about avoiding the inherent inefficiency of e.g. Haskell, but about permitting different styles of programming, and the argument is that a low level language simply cannot allow such a style (without overhead), because the required optimisations are not practical to implement.

How does this avoid rounding error? Division and multiplication and still result in nonrepresentable numbers, right?

The problem with fixed point is in its, well, fixed point. You assign a fixed number of bits to the fractional part of the number. This gives you the same absolute precision everywhere, but the relative precision (distance to the next highest or lowest number) is worse for small numbers - which is a problem, because those tend to be pretty important. It's just overall a less efficient use of the bit encoding space (not just performance-wise, but also in the accuracy of the results you get back). Remember that fixed point does not mean absence of rounding errors, and if you use binary fixed point, you still cannot represent many decimal fractions such as 0.1.

Yes, but you're not going to have efficient transcendental functions implemented in hardware.

Who do you work for? And is packaging ROCm for Debian really a full-time job, or is it just a part of your job?

As messy as ROCm's packaging is, I can't imagine spending all day every day trying to fix it.

Most recent I remember was in 2011: https://github.com/ocaml/ocaml/issues/5419

The comments were quite often in French, however! Until relatively recently, the OCaml compiler would also sometimes emit error messages in French in some obscure cases.

What are they supposedly trying to do with Warhammer (40k)? I am aware that Amazon has the rights and are working on developing something, but apart from the Secret Level episode (which was good), has there been any details?

While some of what Amazon has made is terrible, much is good. They produce so much that the average quality is pretty close to the global average, so I find predictions challenging.

This is not the case in Haskell, because let-bindings can be self-referential, while lambdas cannot (without using a fixed point combinator). Also, in most functional languages, a let-binding causes type generalisation, which is not the case for a lambda.

This looks like an invocation of a C++ CUDA kernel through an FFI. It is not running k or q directly on the GPU.

Why not essentially treat it as a cross compilation scenario? NixOS is also source based, but I don't think such a migration would be particularly difficult. You'd use the 32-bit off_t gcc to compile a glibc with 64-bit off_t, then compile a 64-bit off_t gcc linked against that new glibc, and so on. The host compiler shouldn't matter.

I always understood the challenge as binary compatibility, when you can't just switch the entire world at once.

Not at all! Lynx is a quite serviceable Gopher client, and it is available in most package repositories. For Emacs users, elpher is available, and it is very comfortable to use. Far more than modern browsers, really.

Yes, and undoing this means it's no longer UNIX as it will no longer run on that PDP-11! (Unless you can afford a bigger disk I guess.)