Clearly computer have introduced a lot more symbols to the keyboard, but for whatever reason, the em-dash wasn't one of them. Not, at least, as part of the original sets of unmodified and shifted keys. There are more symbols hidden under option and ctrl, but those aren't shown on the keyboard and therefore hard to find and unknown to most people.
> Clearly computer have introduced a lot more symbols to the keyboard, but for whatever reason, the em-dash wasn't one of them
Forms distinguished by width weren’t added to computer keyboards as separate keys because computer keyboards, like typewriters, solidified when computer displays were monospaced. (And, like other forms like proper opening and closing quotes, limited space on the keyboard was a concern.)
Yeah, except this one is much more arbitrary in its choice of groupings and arrangement. Why is the boolean and Unicode scalar type in the same column as floating-point types? Why is the ! type not next to enums if () is next to tuples? (Both are neutral elements of their respective type-formation operations.) How is Sized to Drop as Copy is to Clone? You can go on and on. If you take the "periodic table" framing seriously, you can see some actual correspondences on display (like between plain operators and compound assignment operators), but they drown in a sea of spurious ones.
It's like infographics. Pretty visuals, but little to no insight.
If I am allowed not to look at the screen when an advert is playing, then I should be allowed not to play it in the first place. There is no moral obligation on the part of the viewer here.
An advert is an investment: someone pays money to broadcast something and hopes that will generate awareness. Any investment is allowed to fail.
Web3, not 3.0 (I didn't realize they both use the same name). As late as last year I got a recruiter asking if I wanted to work for a Real Estate startup that was gonna use Web3 and Blockchain Technology to "revolutionize the housing market".
> A C argument declaration is made up of modifiers (register, const), a data type (char *), and a name (from).
Now explain a declaration like "char *argv[]"...
> We’ve also re-set the data type such that there is no space between char and * - the data type of both of these variables is “pointer to char”, so it makes more sense to put the space before the argument name, not in the middle the data type’s name (update: it should be pointed out that this only makes sense for a single declaration. A construct like char* a, b will create a pointer to char, a, and a regular char, b).
Ah, yes, the delusional C++ formatting style. At least it's nice that the update provides the explanation why it should be avoided.
My $0.02: Don't throw away a perfectly good mental model because of a compiler ideosyncasy. Just treat it as a special case and use a linter against stuff like char* a, b.
You also don't think about dollars differently than other units, just because the sign goes before the number.
If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.
> The things all being described are way beyond non trivial to solve, and they'd need to be solved for every language.
Except it already is a solved problem.
If languages compile to a common byte code then you just need one tool. You already see examples of this with things like the IR assembly produced by LLVM, various Microsoft languages that compile to CLR, and the different languages that target JVM.
There are also already common ways to create reusable parsing rules like LSP for IDEs and treesitter.
In fact there are already grep-like utilities that are based on treesitter.
So it’s not only very possible to create language agnostic, reusable, tools; but these tools already exist and being used by a great many developers.
The problem raised in the article is that we just don’t push these concepts hard enough these days. Instead relying on outdated concepts of what source code should look like.
> Grep works great
For LF-separated lists it does. But if it worked great for structured content then we wouldn’t be having this conversation to begin with.
