I am familiar with the syntax, so I am biased ("*/3" and "12,14,20" makes sense if you are familiar with Unix tools), but it is still more intuitive to me than the systemd unit file syntax and usage. I know that I just have to edit /etc/cron or throw any executable file into /etc/cron.d/monthly and it will work on my system, but I cannot write a systemd timer file from scratch without looking it, and to do that I first have to find the directory where the other examples are located. /etc/systemd doesn't appear to be it.
This is generally my only real complaint about systemd. I don't care if it is too monolitic, written in C or whatever, I just want a straightforward syntax for straightforward operations. I'd like it if systemd could recognize if a .target file is a shell script and just do "the right thing". Perhaps it would make sense for a timer file to recognize cron syntax as well. Or at least allow for a kind of extensibility so that I can have it supported.
If systemd had a little more respect for existing conventions, I am pretty sure it wouldn't be so controversial. After all, system administrators like it because they use it all the time, but a regular, full-timer user like me, who only deals with it when something is broken or have to use it as a means-to-an-end to set something up, then all friction is annoying and bad UX. (And no, using Nix is not the solution)
The article doesn't sell it that way. "You should play modern board games if ..." would be a different claim. The premise
> They provide interesting puzzles to solve, and you work in a technical role - some part of your brain must find that appealing
is something I do not relate to at all. Almost every time I am in a situation where I play board games, my intuition is to think about how you solve the game so that one side always wins or break the rules so that everyone loses, but almost never am I actually interested in investing the energy to get invested in the game itself, let alone the rules.
In practice this should also work. Do keep in mind if you just add this to your init.el then this will not persist if you re-create the scratch buffer.
If we are already experimenting with different ideas, this should also work (and gives a hint of how you want to fix the issue upstream):
Do note that I only configure this for `lisp-interaction-mode', which in practice really only gets used for the *scratch* buffer. But there are a few other instances in core that also use it, and if that concerns you, you can extend the above snippet with a check like
No, I just guess that most people who dislike it (like me) dislike it on an "eyeroll" level, where you wouldn't use it yourself but don't have the energy to make a fuss about it.
But in 1976 Emacs was implemented in TECO. In 1984 it was implemented in Lisp, because Multics Emacs _or_ EINE/ZWEI (Lisp Machine editors) were using Lisp as an extension language, which apparently has shown itself to be useful.
A point of clarification: GNU ELPA (https://elpa.gnu.org/) is part of Emacs, and you have to sign the copyright assignment to submit packages an to contribute to packages. NonGNU ELPA (https://elpa.nongnu.org/) doesn't have this restriction.
From the historical sources I could find online, it appears that Rust's borrow system was independently invented, or at least they don't mention linear logic or anything substructural. This is kind of interesting to me, especially given the reactions in this thread, and ties into the general difficulty of PL research to find acceptance among practitioners, especially when presented by researchers (which I think is regretful, I like the ideas in the article!). Perhaps we really should stick to terminology like "function colors" to make effect systems more popular (or not, because the color framing makes it sound bad to have different colors in a program, IIRC).
I don't think it is not maintained, there is plenty of activity going on in the repo: https://repo.or.cz/tinycc.git, they just don't seem to be cutting releases?
According to https://algol68-lang.org/, and as expressed in the recording, the contributors (specifically Marchesi) believe that ALGOL 68 continues to have advantages over other languages to this day ("more modern, powerful and safe" and "without successors"). One mentioned in the video is that the more complex, two-level grammars allow properties that would usually be described in the semantics of a language to be formally expressed in the syntax (the example he gives is the behaviour of numeral coercion). I guess this is not a surprise, as van Wijngaarden grammars are known to be Turing complete, but nevertheless it seems like something interesting thing to investiagate! There is a lot of lost wisdom in the past, that we dismiss because it doesn't fit into the language we use nowadays.
Also, most languages trace back to ALGOL 60 (the C family tree goes ALGOL 60 -> BCPL -> CPL -> B -> new B -> C -> ANSI C -> ..., though there was some influence such as the idea of "casting", but apparently C only has a castrated version of what ALGOL 68 had) and Pascal is if anything negativly influenced by ALGOL 68 due to Wirth's disagreements with van Wijngaarden: https://dcreager.net/people/wirth/1968-closing-word/.
I recently realized that "pure functional" has two meanings, one is no side-effects (functional programmers, especially of languages like Haskell use it this way) and the other is that it doesn't have imperative fragments (the jump ISWIM to SASL dropped the non-functional parts inherited from ALGOL 60). A question seems to be whether you want to view sequencing as syntax sugar for lambda expressions or not?
Some sites like Anna's Archive have .onion site for the Tor network, and others do not. Is there a considerable downside (DDOS?) to providing access to their site by those means?