The author is definitely claiming that it's not just about naming conventions: "These different perspectives ultimately amount, I argue, to mathematically inequivalent structural conceptions of the complex numbers". So you would need to argue against the substance of the article to have a basis for asserting that it is just about naming conventions.
Syntax comment: in your control structures you use a keyword ("do", "then") to start a block as well as wrapping the block in parentheses. This feels superfluous. I suggest sticking with either keywords or parens to delineate blocks, not both.
The value of Org outside Emacs would be the same value that Markdown has, if it had wider adoption. Voit's post makes a strong argument for Org syntax's ability to serve for all the things Markdown currently does, while being more consistent and concise than Markdown, and so he pushes for it to be more widely adopted. We know that in tech, the better format doesn't always win at first, or ever, but we can advocate!
I was also impressed and read the whole thing and got a lot of gaps filled in my history-of-the-web knowledge. And I also agree that the uncritical optimism is the weak point; the article seems put together like a just-so story about how things are bound to keep getting more and more wonderful.
But I don't agree that the system is bound to collapse. Rather, as I read the article, I got this mental image of the web of networked software+hardware as some kind of giant, evolving, self-modifying organism, and the creepy thing isn't the possibility of collapse, but that, as humans play with their individual lego bricks and exercise their limited abilities to coordinate, through this evolutionary process a very big "something" is taking shape that isn't a product of conscious human intention. It's not just about the potential for individual superhuman AIs, but about what emerges from the whole ball of mud as people work to make it more structured and interconnected.
The unity of the block of cheese is circumstantial, but nonetheless we define a piece of cheese defined on the presence of actual matter. The article goes to some trouble to devise a definition of holes that's also based on matter rather than its absence. But only a strict materialist would feel the need to do that, assuming they didn't want to outright deny existence to holes.
I think your definition still leaves the essence of the discussion in the same place: do topological properties "exist"? That's how I tend to blanket-interpret this debate; it's whether one is wiling to define existence to include things that aren't material.
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.
Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
Am I wrong to be skeptical that this was a thought author had at 8 years old? I don't doubt that 8-year-olds can learn programming and advanced math, but even the brightest 8-year-old would still be in the "sponge" stage. It's hard to believe they would have a sufficiently fixed idea about algebra to be troubled that X = X + 1 is "wrong".
Someone could know what memory safety is and still be persuaded (or reminded) by an argument that it's not okay to adopt a non-memory-safe language due to all the security issues. The author did cite evidence from the Chromium project, which to me elevates it above a mere rant.
Intelligence isn't the same thing as happiness, but it could be correlated, because if IQ does measure generalized problem-solving ability, as it seems to, then smart people could apply themselves to the problem of happiness and have more success than average in it. Then the question is "why don't they"? As you indicated, one reason may be that there's not much encouragement to, because as a society we're still in "rat race" mode.
The line numbers and position bar are some real quality-of-life enhancements!
I don't regularly use nano anymore, but I have often thought that more programs should imitate the way it shows the command shortcuts on-screen as a kind of instant tutorial. I remember my physics major friends in college thinking it was pure snobbery for vi not to do that by default. Back then we were dialing in to an HP-UX server and using pico, which nano is an open-source clone of. For those who aren't aware, pico was originally the editor component of the Pine email client.
Projects like this are some of my favorite uses for single-board computers. Another one is Bare Metal C64, which aims for low-latency vsynced Commodore emulation on the Pi: https://accentual.com/bmc64/
TextAdept and its possibilities have intrigued me for a while now; a fast Qt GUI and Lua-based configuration sounds like a sweet spot for me. But I've never fully taken the plunge to configure it for development. I'm open to reading more propaganda for it if you can point me to any :)
There are a lot of people who learn and teach the RSA algorithm superficially without a sufficient grasp of the number theory to really understand what is going on. I know because I've been one of them (on both sides). The Carmichael vs. Euler totient issue confused me for a long time.
Needless to say, those people should not be implementing RSA for a system that needs actual security. I'm looking for a better way to teach "real" RSA without needing the students to be math majors or to spend a whole semester on it. Does anybody have any suggestions?
I didn't say more people should become career scientists; the incentives of that are all messed up from trying to measure research output like it's a product. IMO the best way to prevent junk science is to teach more people to tell good science from bad. Better understanding is empowering regardless of career.
To me, the greatest contribution of mediocre scientists is that they teach their field to the next generation. To keep science going forward, you need enough people who understand the field to generate a sufficient probability of anyone putting together the pieces of the next major discovery. That's the sense in which the numbers game is more important than the genius factor.
Conversely, entire branches of knowledge can be lost if not enough people are working in the area to maintain a common ground of understanding.
Does this or any other scrollable-tiling WM remember your preferred size of windows per-application? For instance, if I open a new Firefox window, I always want it to be the same width and full height. If I open a terminal, I want it to be half-height and the width I've set for terminals.
Ideally, I'd want to set that in a configuration, so if I made adjustments to a window one time it wouldn't change the default sizes.
This is not in fact a compositing window manager for Windows, but rather a port of a Mac app for WYSIWYG LaTeX editing. It looks like a very useful application. Just wish they prioritized porting it to Linux instead.
The argument could be made that rewriting in general can make a codebase more robust, regardless of the language. But that's not what the article does; it makes it specifically about memory safety:
> That’s how I feel when I see these companies claim that rewriting their C++ codebases in Rust has made them more memory safe. It’s not because of Rust, it’s because they took the time to rethink and redesign...
If they got the program to work at all in Rust, it would be memory-safe. You can't claim that writing in a memory-safe language is a "minor" factor in why you get memory safety. That could never be proven or disproven.
Of course! It wasn't really a criticism, just a cheeky observation that the documentation for every Wirth-style language I've ever seen begins with the EBNF grammar. Though it's rare for a new language to do that today, I appreciate you continuing the tradition.
And don't forget the GUI editor for Irrlicht, CopperCube! I had an easier time getting started with this than with the more modern but heavier frameworks (never finished anything though).
https://www.ambiera.com/coppercube/index.html
I gave Meow a fair shake a year or so ago. I'd say it's currently the most robust mode for implementing Kakoune or Helix-like bindings in Emacs, but you can customize it to be like vim or anything else. It's more lightweight than evil-mode. At present, however, I'm not using modal editing in emacs; just lots of Meta-key shortcuts for movement and a hydra with a key-chord for common commands.