jasperry

Another 8-bit "better than BASIC" language was COMAL. Similar to the language in the article, it also had structured programming constructs, and the C64 version had built-in turtle graphics, sprite, and sound commands. I remember picking a version up at a mall kiosk that sold PD disks and it expanded my horizons!

oh, thanks for the fact check. I guess it's obvious which computing ecosystem I never touch :)

I remember being mildly intrigued as a kid when I started seeing PCs with the Enter key where my C64 had Return.

It's ironic that, though we haven't seen a Return key for a long time, the down-left arrow symbol still used on many keyboards represents the motion of a carriage return. I guess there's no other symbol that would convey the meaning of Enter as well.

I've never heard of blocks in block-scoped languages being called procedures. I feel like the word "block" is well understood and serves the purpose fine. In lots of other languages, things called procedures do take input, like Ruby, which has first-class Procs like you mentioned.

Seconded. Languages could even use "function" only for pure functions and "procedure" for everything else. Pascal uses "procedure" for things that don't return a value, but I think the pure vs. side effect distinction is more useful.

To push back a little: Designing the syntax of a programming language always involves tradeoffs; nothing is "just wrong". For better or worse, equal sign as assignment has become widely used and understood. I think the author's use of colon is neat, but it is confusing if you're used to seeing that as the type indicator; again, a tradeoff. I like the look of := as the assignment operator but it adds another shifted key to type, which can push you that much closer to RSI for such a common operation.

That's very interesting about vitamin C, I never heard that it can reduce stomach lining damage. It's surprising because things with vitamin C tend to give me heartburn, I assumed because they were acidic. Do you have any references?

jMonkeyEngine is on my list of things I want to do a project in. I hope it continues to get support. It might be better for 3D than Godot (based on hearsay anyway)

I'm not the parent poster, but to me it's not about C# in particular, but that there is basically no other well-supported gamedev framework in a language that's 1) statically typed, 2) garbage-collected for safety and productivity, 3) has decent performance, and 4) has good tooling/IDEs. JavaScript, C++, and Python/GDScript are all missing at least one of those. Java could possibly fill the gap, but it's still clunkier to program in than C#, and no Java game framework has much traction.

I'd be ecstatic if there were something checking those boxes that wasn't owned by Microsoft.

Yes, I believe they're drawn or stenciled in. Some amount of care has been taken here to produce a more professional-looking result, but you can find plenty of old typed papers where math is obviously handwritten in. Like John Nash's thesis: https://library.princeton.edu/sites/g/files/toruqf6021/files...

"There is a sense in which we are all alchemists." --Schopenhauer

You didn't list all functions, just input-output pairs. Each function is a map from every possible input to an output:

f1 False = Nothing, f1 True = Nothing

f2 False = Nothing, f2 True = Just True

...

This gives the correct 3^2 = 9 functions.

Your comment makes me think the kind of people who favor OCaml over Rust wouldn't necessarily value a huge ecosystem or the most advanced tooling. They're the kind who value the elegance aspect above almost all else, and prefer to build things from the ground up, using no more than a handful of libraries and a very basic build procedure.

Question about terminology: Is it common to call higher-order function types "exponential types" as the article does? I know what higher-order functions are, but am having trouble grasping why the types would be called "exponential".

This is alluded to in the article, but not fleshed out: To me the ideal is to not have any limit on the length of _logical_ lines, but have the editor do syntax-aware _visual_ line wrapping. Then, people can view the code at any column width they want and it just looks right; line numbers don't change just because of reformatting; and most importantly, the programmer doesn't have to waste time thinking about how to break up an expression.

Thanks, but it looks like the web version doesn't let you do anything unless you sign in with Google or Facebook.

I quit Wordle when NYT bought it and started asking me to make an account. But I started again using the app because one of my kids does it and, as the article says, it does give something to talk to people about. So far, you don't have to make an account to use the app. I'll never make an account to be tracked just to play a word game.

Yes, this. I'm a long time XFCE user but when I got a beefier machine I switched to KDE, and unlike XFCE it manages the hardware thoroughly enough (sleep/brightness/network/audio) that I don't have to manually hack anything. I tolerate the bloat for that reason. I disabled all the kwallet and pim stuff though, that was a mess.

I also hoped it was actual emulation. I could tell it wasn't when I saw the bootup progress bar moving more smoothly than it ever did in real Windows :)

Could be, I'm not that far along yet. I've only just peeked into the incremental API. I'm still using the error token to try to improve my messages. It's just for syntax errors anyway, right?

I did learn about LR parser generators first in my Compilers class in college, but I assumed they were generally known about in language development communities.

But remember that the articles arguing for recursive descent parsers are arguing against the long-dominant paradigm of using LR parsers. Plenty of us still like LR parser generators (see my other comment.)

In between "easiest to get started with" and "what production-grade systems use", there is "easy to actually finish a medium-sized project with." I think LR parsers still defend that middle ground pretty well.

> If I was routinely working in a language that had a well respected de facto standard parser generator and lexer, and regularly building parsers for little languages for my programs, it would probably be worth mastering these tools.

In OCaml, a language highly suited for developing languages in, that de facto standard is the Menhir LR parser generator. It's a modern Yacc with many convenient features, including combinator-like library functions. I honestly enjoy the work of mastering Menhir, poring over the manual, which is all one page: https://gallium.inria.fr/~fpottier/menhir/manual.html

One of the primary uses of public-key encryption is key exchange at the beginning of a session that is subsequently encrypted using symmetric encryption. That's how every TLS session works, because public-key encryption is too slow for large amounts of data. Since QKD is a solution for key exchange, it can replace public-key algorithms in this respect.

The other main application of public-key encryption is digital signatures, which is vital for certificate checking and identity verification in general. At first glance, it seems QKD won't solve that, as you said, but I haven't looked into quantum research relating to signatures.

Quantum computing and cryptography research is important, but are some researchers taking advantage of hype to stay funded by letting people think practical applications are closer than they really are? Possibly. Nonetheless, the research is important.

That's also what I heard about traditional one-way hash functions and quantum. It's a theoretical result for now...

This is about the foundations of symmetric encryption. The authors are looking for constructions that give similar security guarantees to one-way functions if you live in the quantum world, and one-way functions are the theoretical foundation of symmetric cryptography.

Public-key encryption is based on trapdoor functions, which is a strictly stronger definition. So they wouldn't have got that far yet.

A pretty middling article from quanta--I expect better science writing from them. This one seems to be trying too hard to avoid being concrete, leaning into vague, unhelpful analogies. Still, I appreciate their work to publicize important theory results.

The research area is "Quantum One-Wayness" and here's the paper with the main result being discussed: https://arxiv.org/abs/2310.11526

I agree. This is a very enlightening discussion of individual glyph features that affect readability. But the thing that hit me immediately is the difference in how expanded or condensed these fonts feel. Even though in the examples, the text width of JetBrains and Fira is identical, JetBrains "looks" condensed to the point of being harder to read. But I feel like Atkinson goes too far the other direction and is too expanded. When I read it, I feel like I'm tripping over the empty space between the characters, or I have to move my eyes too much to read one word.

Rust semantics owes a lot to ML, but the borrow checker makes programming in Rust very different from other ML-derived languages, which are almost all garbage-collected.

Okay, I'll bite. ML did not mostly die, it morphed into two main dialects, SML and OCaml. OCaml is still going strong, and it's debatable whether SML is mostly dead.

My main beef, however, is that the last sentence in the section seems to suggest that the birth of Haskell killed SML on the vine because suddenly everybody only wanted pure, lazy FP. That's just wrong. The reality is that these two branches of Functional Programming (strict/impure and lazy/pure) have continued to evolve together to the present day.