> resulting in the production of an abundance of PDFs. The contents of some of those PDFs may even have important applications.
I hope, from the depths of my soul, that the static typeset report format for transmitting knowledge and understanding will finally die and be laid to rest.
As a researcher in theoretical computer science, I love PDFs more than any other format when it comes to mathematics.
There simply is no contender to LaTeX and PDFs.
Lucky for you, almost all research in math, cs, and physics, are put on arxiv, where you can download the source code (.tex) as well as get an HTML render.
We don’t need new ideas, we need languages that take the best ideas developed over the past decade of PL research and operationalize them in a language with modern tooling and build support.
Most of my research conversations with Claude nowadays are basically about this—what it would take to make every latent bit of program semantics visible and expressible in the language itself. As you put it, first-class everything.
At this point I think we have good solutions for expressing pretty much all the most common program semantics, but there’s no language that brings them all together under a unified syntax, tooling, etc.
I think Pony’s reference capabilities are a better solution for linear types. It’s just part of the language so a violation is simply a type error, not something flagged later during static analysis.
This article concludes with the following statement:
> So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment.
It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the oldest and most well-studied in all of computer science. It would make sense to go consult a textbook on the matter before trying to reinvent the wheel.
Well yes. But most of those studies assume/assert control over the environment. In this case you are running in the browser and you have to deal with the primitives it gives you. Both in compute management (threads/workers), communication (RPC, messages, shared memory, sockets), as scheduling (like having yield or not.
I’m not sure whether inventing a setup like green threads in JavaScript/workers would even be possible.
That is not to say that we should just forget about those learnings though.
This! Since it became easier for people to post their thoughts on a problem vs. research and learn from past work, we're now in the era where its harder to find the seminal and really-well-explained material for having to wade through years and years of people's rediscovery blogs.
(Don't get me wrong; I too think the article is great; just wish all the folks who went to JS bootcamp and are amazed by this would have cracked any CS or OS text book written since the late 60's and browsed a few chapters.)
“non-trivial” is one of those words that seems like it should be a Claude-ism but is actually just the single best word for a concept that comes up extremely often in research and engineering discussions.
Assembly doesn’t have typed objects, it has typed instructions. It’s like checked exceptions in Java—you have to declare them in the type signature of the method, and the compiler enforces that they are either caught and handled, or also explicitly declared by the caller. The type declaration is all about possible side effects.
It’s an effect in the type system, not a data type or behavior.
If you give an untyped number to B's print function, it'll print the ASCII letter. That doesn't make B typed.
And this is being generous. Types in typed languages aren't just about the data, it's about what you can do with that data. If a function requires a pointer, it needs to know that that arbitrary collection of 1s and 0s is a pointer. Typing is the mechanism to enforce that. All (?) functions on all(?) languages assume, if they don't outright know, something about the type, so are all languages typed? And in that case why is the distinction at all meaningful?
You're talking about objects. I'm talking about integers, chars, pointers.
A 32bit register could be handed to sign extend, it could be used as pointer, used as an interrupt number, printed as a letter. The processor doesn't care. Assemblers typically don't care. Different things you do with that number imply that you are using it as a type, but nothing cares if you use a pointer as a system call number and then print is out as a utf32 character.
In other words, the type of an assembly instruction specifies its effects and coeffects. This is an active research area—describing effects and coeffects in the type system, and discharging handler/provider obligations at the compiler level.
I suspect the main reason someone might quibble over the “assembly is typed” assertion is that many programmers have a rather narrow view of type systems, heavily skewed by OOP patterns.
That's pretty much the quibble. Most people's narrow view of type system.
And we already track all of the basic side-effects and clobbering that each form of each mnemonic does. That's kind of the entire point of this being possible: it's all "typed".
The problem was never the volume of homework, it is the targeting and specificity. Learning happens through repetitive deliberate practice, full stop. You can’t learn through osmosis; effort is required.
Industrialized mass education has always suffered from a unit economics problem: the labor required to assign individually-tailored problem sets and manually grade them in the volume needed for most students to actually learn the material is prohibitively expensive.
I hope, from the depths of my soul, that the static typeset report format for transmitting knowledge and understanding will finally die and be laid to rest.