Vim does not have multiple cursors which can be placed ANYWHERE even multiple on the same line and at any offset. You are clearly not aware of what Vim actually offers.
> People don't use vim because they enjoy puzzle solving.
I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!
> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.
A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
I am not sure how much clearer I can be in the article or in my replies to comments.
> You just edit as normal while recording, and replay those edits later.
And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
Which is kind of what I was arguing. Understand that having "fun" is not necessarily equivalent to being "productive". And even by an individuals own standards, the two can be completely different.
If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.
> The things about multiple cursors is that you think about the processing while doing it
That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
> Sublime is invisible to him because he's been at it for fifteen years.
It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.
> But the escape hatch is the whole problem with his thesis
I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).
> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.
I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.
I am not sure how to summarize the entire article other than what I already wrote in the conclusion.
That's not what I was saying. I used vim macros specifically as an example, not Vim as a whole.
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.
and
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.
> I am afraid the author confuses familiarity with proof that his tools are better.
Literally NOT what I was implying or even said anywhere. Quote me where I said anything like that.
To quote myself:
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
This has nothing to do with why I or another person one tool over another, but rather treating the flaws as if they are things to have a puzzle game to work around.
Another common question I’ve gotten a few times is why the `context` is passed as an implicit pointer argument to a procedure, and not something like a thread local variable stack? The rationale being that there would not need to be a calling convention difference for `context`. Unfortunately through a lot of experimentation and thought, there are a few reasons why it is implemented the way it is:
* Easier to manage across LIB/DLL boundaries than trying to use a single thread-local stack
* Easier management of recovery from crashes where the context might be hard to figure out.
* Using the existing stack makes stack management easier already, you don’t need to have a separate allocator for that stack
* Some platforms do not thread-local variables (e.g. freestanding targets)
* Works better with async/fiber based things, which would then require a fiber-local stack instead of a thread-local one
* Prevent back-propagation, which would be trivial with a global/thread-local stack
Odin’s context also has copy-on-write semantics. This is done for two reasons: to keep things local, and prevent back-propagation of “bad” data from an third-party library (be it malicious or just buggy). So not having an easily accessible stack of context values makes it harder for this back-propagation to happen.
If you're referring to me, I don't use Reddit much at all any more. I used to comment sometimes on that specific subreddit, but I didn't find the community that great nor the conversations that useful for me. There seemed to be more of a focus on Lambda-Calculus-related type theories, and less in other type theories, and less on practical design and implementation of programming languages and compilers. It varied from beginner level topics to very niche technical topics. I usually talk to other language/compiler developers (outside of Reddit) for discussions on programming languages, meaning most of it is not done in the public.
The categorizes are useful for understand how people perceive a language. It's a human psychology category, and just because you think it is "irrelevant" misunderstands why I made the categorical distinctions in the first place.
People actually talk this way about languages, and they already have this conception.
And I've just realized what your psychological hang-up is now too, the word "focused". I originally didn't use this term when I wrote the article in 2018, but a friend suggested the term instead because it was probably a little more "neutral". I honestly cannot remember what I used before now since I have just absorbed this arbitrary term "focused", even if the distinctions are useful.
You might not think this way about languages. I know I don't when I program. But I know this is how others things, and that's the entire aspect of design. Design is just so much about understanding humans. How they function, mentally and physically. Perception, psychology, sociology, physiology, ergonomics, needs, desires, etc. It's all about being able to put yourself in other people's shoes, more than making _the thing_.
And that's what I've been trying to understand and that categorization has been helpful for understand other people. I don't care if you think the categorizes are "irrelevant" but you are not "everyone".
This might might sound weird but I think that's a distinction without a difference.
Those "newline tokens" are effectively the equivalent to a semicolon in the parser. They are statement terminators. The way that Odin or Python handles them is effectively the same except when I tokenize the newlines, they are treated as semicolons but with the "text" being "\n". Thus the distinction here is a matter of what you call it, not how it is treated.
That is the same as a form of "automatic statement-terminator insertion" where that statement-terminator is whatever you want it to be. And to me, that is as form of "semicolon" (which is being used as a generalization for statement-terminator) insertion.
In the follow up article, I wrote something like this in the conclusion:
> Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly.
I was trying to be EXTREMELY clear I am talking specifically about DECLARATION syntax only and how for the most part, the concrete syntax for the DECLARTAION syntax is not that important in many languages.
However concrete syntax matters a heck of a lot and cannot be trivially interchangeable.
I tried my best to be very clear within this article that I am talking about two specific things: DECLARATION SYNTAX and SEMICOLONS. This does not extend to anything else. In fact I got so frustrated with people like yourself who are wrongly interpreting the article that way and extrapolating too much that I had to write a new article: https://www.gingerbill.org/article/2026/02/21/does-syntax-ma...
"Does Syntax Matter?" And the first one is "Yes."
And all languages can have their declaration syntaxes categorized into one of the three I mention. This is not limited to ALGOLs. And I have come across "really interesting language syntax". I am not talking about that in this article.
----
Ergonomics does matter and it's not just about optimizing for typing either. It's actually all about coherency and consistency, something I go into depth into the following article on syntax.
----
I am not "conflating" a semicolon with statement terminators, I am using that as shorthand as most languages that most people encounter (not all languages, obviously) will use semicolons. Python's approach to parsing is a form of automatic semicolon insertion, even if most people don't think of it that way.
----
And I do not like Python's approach requiring significant whitespace of "blocks" through indentation. I much prefer using something like braces, or an `end` keyword, etc, literally because it prevents the problems that significant whitespace introduces. I am not getting into that argument here; please don't start it.
Hello again. That's not my position in the slightest. The point of the article is to express how people will shallowly and naïvely judge something. It might be naïve conception of "aesthetics" but it's not even a good one.
It has nothing to do with people disagreeing with me, I have seen people dismiss numerous languages (not just my own) based on that declaration syntax. Things like "why does Rust not use `type name = value`? why did they have to change things so much from C++?".
Do you think these people are actually serious programmers or just having shallow and dumb opinions on things they know little to nothing about?
> I never got why compilers don't have pluggable syntaxes.
Because then you've created dialects and produced the Curse of Common Lisp all over again.
Syntax matters a heck of a lot, and you want consistency and coherency across codebases of the same language, otherwise you don't have a language at all. So wanting it "pluggable" is in fact the worse possible choice you want.
It's also a naïve view to think that concrete syntax can be trivially swapped out with the abstract syntax remaining. For certain things it can usually work (like declaration syntax in the article) but for most things it cannot.
The answer is "yes" depending on what you mean by STM32 :D
But if it's one we don't currently support officially, it should be pretty easy to support too, with probably a little extra assembly.