Athas

> I'm not convinced it's "serious" --- thread-local-storage easily solves that.

What about other cases of exceptional control flow? What happens if a signal arrives while that static area is being used, and the signal handler also needs to use the static area?

Well, this sounds like it was before ANSI C, so there was no defined notion of undefined behaviour - I think that term of art came with the later standardisations. And if it was written to run on a specific OS or compiler (4BSD), one can argue that it was a really bad design, but it worked reliably on what was essentially the implementation-defined platform it was targeting.

How so? References are not polymorphic in SML (that's what the value restriction ensures).

This part (which is tangential to the real thesis of the paper) is interesting:

> Advocates of strong type checking in compiled languages have attempted for years to build compilers capable of proving the type correctness of programs. We believe that they have failed. All languages sophisticated enough for serious programming require at least some dynamic checks for type safety at execution time.

In 1986, languages such as Miranda and ML existed in reasonably serious forms, and clearly had sound type type checkers and quite powerful type systems, including parametric polymorphism. Does the paper take the stronger position of counting things like array indexing as part of "proving type safety", or was there still a conception in 1986 that "serious programming" could not be done in a type-safe manner?

It is definitely true that even in 2022, the vast majority of statically typed languages still perform run-time safety checks for some operations, such as integer division and array indexing. While languages that support fully provably safe programming exists, they are clearly in the tiny minority and not widely used, and still have ergonomic problems.

It's always surprised me that game mods tend to be developed behind closed doors. Why don't they follow common open source development processes? Is there a cultural or perhaps technical reason why open development doesn't work for mods?

(The one in TFA is an exception of course.)

> It at least doesn't lock anything up that has a file open when the network goes down.

I must admit I feel quite a bit of irrational fury when this happens (similarly, when DNS lookups hang). That some other computer is down should never prevent me from doing, closing, or killing anything on my computer. Make the system call return an error immediately! Remove the process from the process table! Do anything! I can power cycle the computer to get out of it, so clearly a hanging NFS server is not some kind of black hole in our universe from which no escape is possible.

Unless some abstraction layers have been added while I wasn't looking, Wayland doesn't have a notion of window manager - only of compositors. These compositors incidentally also manage windows (although that's not the Wayland term I think), but I think the correspondence of compositor and window manager is still 1:1. Thus it is safe to assume that anything called a "window manager" is for X11.

Some people appreciate simplicity as a virtue - simplicity of implementation as well. To such people, using a third party library to conceal an incredibly complicated implementation is still in principle ugly. I don't know if that is what motivated the author here, but I certainly know lots of people who would cite that as their motivation.

But then it might easily become unclear exactly which subset of SVG is supported. I am personally leery of implementing subsets of other formats. I find it better to define entirely new formats, at least for simple things like this. To render this "lines" format, you could of course easily write a translator that turns it into SVG. It's mostly the other direction that I would be hesitant about.

SVG is very complex. This format is very simple because it is not supposed to solve a very complex problem. That makes it easier to write other viewers and editors.

Joining the eglot choir. It behaves like I expect Emacs modes to behave and hooks into other Emacs functionality (xref, eldoc). Actually, it behaves better than that: it often works with zero configuration, which is much better than I expect.

Yes of course, just like on more or less any Linux system. But IIRC, shutdown is a suid binary that will do its own permission checks while running. The permissions on the /sbin/ directory should not matter.

> As a sysadmin, I would not want my /bin /sbin exposed to everyone.

Why not? It's not like most of them are suid (right?). Most Unix systems I've used allow any user to peruse /sbin at their leisure and run whatever they want.

> /sbin, /usr/sbin is for binaries that need root. You put them in separate directories so their permissions all match up, and so they don't show up when completing in bash.

I also got this explanation, but it never made much sense to me. First of all, the binaries there are executable by everyone anyway. Second, it really doesn't matter that they show up during completion. Third, many of them work fine and are quite useful without root! I don't recall the specific examples that bothered me (/sbin and /usr/sbin have been in my PATH forever now), but I think it was something like ifconfig or ping.

Yes, but the next iteration will take care of those interactions. You're not really "moving" anything; that was poor imagery on my part. The illustration on the Wikipedia article shows it well: https://en.wikipedia.org/wiki/Block_cellular_automaton

There are some diagonal interactions that are not directly expressible in this way, but they can propagate through the non-diagonal neighbours instead.

If you want more performance, falling sand simulators can further be made parallel by implementing them using Margolus Neighbourhoods, as in Falling Turnip: https://github.com/tranma/falling-turnip

The idea is that a single iteration divides the world into 2x2 squares and then applies effects sequentially within each square, but not between the squares. This means each square can be processed independently. In the next iteration, the division into squares shifts right and down by one cell each direction. This does mean you need more steps than in a sequential implementation, but I found it to be quite a principled approach to parallelizing cellular automata when I first read about it. One interesting side effect of this design is that falling particles end up being separated by blank space, as shown here: https://futhark-lang.org/static/falling-sand-2016.12.04.webm I wonder if that is fixable. (Although at larger scale it's not particularly visible: https://sigkill.dk/junk/diving-beet.webm)

Still, I would expect the overhead to be moderate, not a killer.

> Note that I benchmarked with --check-bounds=no, which is a startup option that you pass to Julia, when launching, that disables the performance killer “bounds checking”.

Why is bounds checking a performance killer?

> Haskell's primary solution to this is to burn it all to the ground. Mutation doesn't cause any type problems because there isn't any.

This is true, but I think it is also misleading. Haskell has the same problem if you use unsafePerformIO to create a polymorphic IORef at top level. You can then use this IORef to subvert the type system. I think this is something many Haskell programmers are not fully aware of: unsafePerformIO doesn't just break referential transparency; it can also fundamentally break memory safety. Now, you may say that unsafePerformIO is obviously unsafe (it's in the name!) and should never be used. But if you look at many foundational Haskell libraries, you will find that they use unsafePerformIO or similar functions internally, usually for performance reasons. What are the rules that govern safe usage of unsafePerformIO? As far as I can determine, these rules are basically just GHC implementation details, and people often get them wrong. And if you break these rules, you don't just get a function that doesn't do what you expected - you may have subverted memory safety entirely.

I think this is an interesting conundrum. Haskell makes much stronger promises than SML, but if you break the rules, all bets are completely off.

Sure, but e.g. the documentation problems with Nix don't prevent you from working with it. While the problems make it less smooth and productive than it otherwise might have been, it might already be better than legacy systems for you.

In particular, Nix can be used in a non-invasive add-on manner on ordinary distributions. We have it installed on RHEL servers at work, where it is used exclusively as a build system and for "userspace programs" (not in the kernel sense, but in the sense of programs that are not core to the functioning of the system).

> And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...)

I agree that the name is bad and has always been bad. I wonder what they were thinking. But the syntax of the Nix language is not based on Haskell. It would be better if it were, but the Nix syntax is actually based on trying to twist a functional language into looking like a Unix-style configuration file. It's horrible, and conceptually big details like "this is a function" are hidden by subtle syntax (a single colon). The liberal use of semicolons and the use of space-separated lists is another concession to looking like a config file. I feel Nix would have been better if it didn't try to cater to older conventions in this way. Sometimes the old ways are just bad. Incidentally, one of the big advantages of Guix (a Nix fork/derivative) is that it uses Scheme as its declaration/configuration language.

I switched to Nix some years ago on my desktop system. While I was initially quite frustrated at lots of the paper cuts - particularly the byzantine design of Nixpkgs itself which is built around manual programming with fixed-point combinators - I was carried through by two things:

1) I was intellectually convinced that the basic premise was sound.

2) Getting a basic desktop system running doesn't require you to understand all the complexity. NixOS works really well out of the box with its standard settings, and making basic configuration changes and adding/removing packages doesn't require you to know anything about the Nix language or the design of Nixpkgs.

Not much later I was able to do pretty radical things like changing the version of LLVM used by Mesa on my system, to work around a defect in AMDs GPU drivers[0]. I have no idea how I would do something like that on Debian. Even better, when this workaround later became unnecessary, I just removed the pertinent parts from my configuration file, and it was like it was never there. My system is fully declarative and not soiled by the remnants of previous hacks.

[0]: https://github.com/athas/dotfiles/blob/d495aeb85fe38569eb212...

I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)

This is the historic origin of the name, but I'm not sure it's still supposed to be an acronym. Modern ML may just be named with two arbitrary letters, as often happens when things named by acronyms grow beyond their original domain.

The "meta language" part refers to MLs original domain of writing tactics for proof assistants, where the "object language" was the language of the programs you were manipulating, and the "meta language" is the language in which you manipulate the programs. This also sort of makes sense when using ML to write a compiler (the "object language" is whatever you're compiling), but of course modern ML goes far beyond just language processing, even if it's still pretty good at it.

I feel the same way. But beyond these concerns, I must admit I also feel a sense of sadness due to the inevitable rise of application-specific hardware. When I hear about these super-fast specialised chips, all I can think about is whether I'd have enjoyed sitting in my bedroom as a teenager hacking on them. And the answer is probably no. They can do very specific things, but they don't have the kind of freedom of programming I enjoy.

Maybe I just need to look at them differently, or maybe my perception of their capabilities is just wrong. I do like GPUs, for example. While they are ornery and limited in many ways, they are still flexible enough that you can do enjoyable general-purpose programming on them.

It doesn't affect your right to do anything with the software. It doesn't even affect your right to remove this citation notice (and some distributions do so). Free software is not about software not being annoying; merely about your right to remove the annoyances.

I'm not certain GNU parallel's approach to obtaining funding is a good strategy, but I find it weird that people object to it on philosophical or legal grounds.

Local flags can be quite interesting. That Ohio flag is beautiful, but a somewhat different result can be observed in the flag of Brown County, Nebraska: https://www.crwflags.com/fotw/flags/us-ne-br.html

Well, to the compiler, the parallelism probably just looks like an opaque call to a higher-order function. The bulk of the program will still be serial code, which will be subject to all the normal optimisations. I talked a bit with one of the main authors of MPL, and he mentioned that the existing optimisation passes in MLton just kept working without any nontrivial modifications.

MPL is based on MLton, so they also do whole-program optimisation (the same one, in fact).

> - Is it your only source of income?

Yes, except for a small amount of passive investment income.

> - Do all assistant professors at your University earn the same amount of money or is it based on individually chosen fields of research / classroom hours they take?

It is the same or very close. The university publishes the average salary for an assistant professor and I am pretty close. It is possible to negotiate salary on a per case basis, but my impression is that it's quite rare except for at the very top.

My name is Troels Henriksen and I work as assistant professor at the University of Copenhagen. That is a unique combination, so it identifies me as a person. I'm not averse to my income being connected to my identity.