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.
It honestly sounds like how a diaper-wearing baby would mispronounce kilobyte.
"I will not sacrifice my dignity. We've made too many compromises already; too many retreats. They invade our space and we fall back. They assimilate entire worlds with awkward pronunciations. Not again. The line must be drawn here! This far, no further! And I will make them pay for what they've done to the kilobyte!"
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!
org-mode is just much more complicated to implement though and just contains so much. it's also a todo app. It also lets you run code like a python notebook. it can show you your tasks in a calendar.
I've used "org-mode" todo apps on android, but people complain they can't really use it because it doesn't implement everything.
The advantage of the core markdown syntax is that you know it works everywhere and it works everywhere because it's small and easy to implement.
I think the implementation challenge is the reasoning behind https://karl-voit.at/2021/11/27/orgdown/
So you can say "my org-mode parser implements orgdown level 1" meaning it has the basics. I think it sounds like a pretty good idea, though it's kind of a third party effort – it'd be better if there were some officially sanctioned compatibility level standard from the orgmode authors.
> org-mode is just much more complicated to implement though and just contains so much.
So just implement the features it has in common with Markdown and add the rest as and when people ask for them.
For me, org-mode syntax is just that much more intuitive than Markdown. I sometimes feel that when devs invent something (Markdown, YAML, etc), they really should do 5 minutes of research before inventing their thing.
Markdown should have used all the org-mode syntax for the the features they wanted.
Markdown was based on the "syntax" already being used informally in emails and on IRC. So the author did do some searching to define the syntax.
I don’t like many parts of markdown either (like the syntax for bold), but those were also IIRC already being parsed by some IRC clients before Markdown was specified.
> Markdown was based on the "syntax" already being used informally in emails and on IRC.
News to me :-/
> So the author did do some searching to define the syntax.
I recall using tin/rtin in 1995, and people used the org mode syntax for italics, underline and bold (not that it made any difference). Same with plain-text email (I used elm, then pine, then mutt). Same with IRC clients - convention was the org mode syntax, not the markdown we have today.
The very first time I saw '**' for bold was in setext, circa 2004. People weren't actually using setext though; they were using *some text*, _some text_ and /some text/.
In short, no, I don't believe that the authors did any research. I think what happened is that they saw something like setext, though "great idea, lets run with that!", and did so.
Fair enough. We can argue about the betterness of org but even if so, its enough better enough to push our something as popular as Markdown. The real item of value is org mode.
In the meantime, I'll advocate for evolving Markdown, specifically GFM.
I do use a custom keyboard layout, but that doesn't have to interoperate with anything/anyone.
Edit: I have a similar unpopular opinion: we should use functional languages and immutable datastructures. At least we some data of movement in that direction with the patterns being adopted by other languages and codebases.
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.
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.
Yeah but then neither does the cheese right? There’s no actual unity to objects, even solid objects, just parts interacting circumstantially, and any part can be subdivided into more parts interacting circumstantially.
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.
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?
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity.
More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe.
My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
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".
Kids can be flexible but also rigid about the most random things. My two year old gets really annoyed if I use the wrong spoon to stir my tea, saying certain spoons are only for food or cereals. I don't know where she got that – it's definitely not a practice we ever enforced!
reply