Will Crichton, a Brown University researcher, writes about programming languages, Rust, systems programming and new ways to present research.
Commenters praise his essay on portable EPUBs and his Nota work for making language papers clearer, though one disputes his conflation of systems and low-level programming.
So many of the difficulties in reading many papers (well, disciplines) boil down to adding links to things the first time you mention them. Good academic writers do this, bad ones don’t. The gist of this paper is that assuming all knowledge prior to your development is very limiting, not only because far fewer people can read it, but because every time you don’t introduce knowledge you also skip over part of a story. Very well, but I think you are correct that CS’ problem is pretty much isolated to the first point, because nearly all papers get to talk about real world applications of the research and that’s the story covered.
A big problem for CS papers, particularly in PL (programming language research), seems to be heavy reliance on assumed knowledge of Greek letters and notation in the very field-specific way you like to use them. People would understand your paper if only they had read your previous three, which alluded to what you might have meant by these Greek letters, but only by figuring out the two citations they each have in common. If you are bad at pronouncing Greek letters and it’s a PDF so you can’t copy them, you can’t even google what you see. Even if you could, it wouldn’t help. Notation is ten times harder to search for.
(I have never, ever had this problem reading a law paper, not even slightly, not even once.)
There’s an interesting demo here from Will Crichton about how to prepare better documents for conveying understanding in PL. He has a thing to…
I've been using Python for 15 years, and I also haven't gotten into Jupyter. I worked with some research scientists who used it, but even they ported their programs to plain text files in order to get version control with textual diffs (which is IMO better for collaboration.)
One reason I don't use it is that I started doing data science before the Python ecosystem was viable -- before Pandas existed. I use R for data science (which I generally find superior due to Hadley Wickham's libraries).
I know Jupyter supports R now, but I already had a terminal/web-based workflow by the time that happened.
-----
More importantly, I think this recent blog post finally crystallized why I don't program in REPLs: Because they encourage global variables! I naturally structure my code into functions from the outset.
I don't like the persistence because it can lead to "wrong" programs. I prefer to test my programs with a "clean slate", i.e. by starting a new process.
http://willcrichton.net/notes/programming-in-the-debugger/
Jupyter’s structure of delimited code cells enables a programming style where each can be treated like an atomic unit, where if it completes, then its effects are persisted in memory for other code cells to process.
However, this style of programming with Jupyter has its limits. For example, Jupyter penalizes abstraction by removing this interactive debuggability.
In other words, if you put all your code in functions like I do, then Jupyter doesn't add…
https://table.dog (a CLI to download Stripe to SQLite).
I considered Node.js, C#.
I went with Rust for a few reasons:
- Easy to build small portable binaries (as a primary language feature).
- The type checker ensures type consistency when writing out to SQL tables (SQLite is loosely typed). Code that reads from the SQLite database implicitly benefits from Rusts strong type checks.
- Macros to convert structs to SQL insert/updates.
- Reduce the chance of errors at runtime.
- Leverage as much as SQLite's write throughput as possible.
- When converting Stripes Open API JSON spec into Rust code (using another Node.js program), the Rust type checker ensures I have a well formed HTTP client - the strict compiler makes it a good target for generated programs. Read more about this idea at (https://willcrichton.net/notes/rust-the-new-llvm/).
Though it barely mentions security https://willcrichton.net/notes/portable-epubs/ is one of my favorite essays to be posted to HN in awhile https://news.ycombinator.com/item?id=39138042
I wonder how one would measure the costs and benefits (with a focus on security) of speeding up and making more security-driven the gargantuan task of shifting to a better, well, portable document format. People are thinking big and want measurement, eg just posted https://news.ycombinator.com/item?id=39514844 WH release on memory safety https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ would it not make sense to be similarly ambitious and metrics-driven for this too?
That's true! It's not an "also", you use both linear/affine types plus the typestate pattern
For the curious, it works like this in Rust http://cliffle.com/blog/rust-typestate/ https://willcrichton.net/rust-api-type-patterns/typestate.html
Or rather, typestate itself needs either linear/affine types or a similar mechanism to make sure that when you are in the "closed" state you can't access methods from the "open" state, and vice-versa. (now, there are languages that implement typestate as a language feature rather than a design pattern, but I don't know how they work)
> Now these explanations are just in the paragraph next to the equation and are not limited to 3 words.
Not necessarily. Will Crichton, a PhD student at Stanford University, has been working on a tool called Nota [0] that he's hoping might serve as a platform for online paper publication. I'd suggest checking out the initial presentation of Nota [1] to see some ideas of how syntax highlighting-type effects can be made as toggle-able capabilities that are not intrusive nor dislocated as you suggest.
[0] https://nota-lang.org
[1] https://willcrichton.net/nota/