miniblog.

I like the idea of a personal LLM trained on my emails. "Summarise my upcoming flight and travel to New York" would be useful. Email is a blob of fairly unstructured text that contains useful information.
Super impressed with the Ariadne library for compiler error formatting. It handles all the messy line highlighting, underlining etc that a good error should have. Left: old, handrolled error formatting Right: Ariadne formatting
PhotoPhoto
Porting my 2016 Rust project from getopts to clap, and it's amazing how far the ecosystem has come. clap gives me a nicer help, automatic value validation, and can even generate completions for shells! First screenshot is getopts, second is clap.
PhotoPhoto
A surprising number of websites will reject packets if they have the evil bit set!
Listening to the latest episode of Maintainable interviewing Daniela Baron, and she introduces a clever concept: ticket rotation. When you divide programming jobs into tickets, deliberately give team members tickets from different areas. This prevents knowledge silos.
A new class of typosquatting attacks for malicious packages: register package names that are hallucinated by ChatGPT: https://vulcan.io/blog/ai-hallucinations-package-risk (h/t @rauschma)
C# has an interesting concept of second-class macros called Source Generators: https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ You can generate additional code at build time, but you can't transform existing expressions (unlike normal macros), so it's more amenable to tooling.
A fascinating discussion of how Graydon saw the original Rust design goals, and how today's Rust differs (in some ways better) than the original:
Rust has an elegant solution to testing private functions: you put the test in the file that defines the function. It generally works well. I've even seen people argue that it makes mocking much less necessary! I've not felt the need to mock in Rust so far.
@RenewedRebecca That's correct, but I was thinking that offering threading to a user might make them more tolerant of a slow interpreter. For example, if I have an AST walker but provide Clojure semantics, users can hopefully get a big speedup by using all the cores in their application.
Suppose you want to make a small, hackable interpreter, so you write an AST walker. Could you recover performance by supporting lightweight threads that use all the CPUs? The Python GIL preferred single threaded performance over multithreading, this is the opposite.
Writing a parser that is resilient to syntax errors, and why a parser should always return something: https://duriansoftware.com/joe/constructing-human-grade-parsers (The latter property is important in e.g. IDEs and it's rarely discussed!)
Fitting a respectable C compiler into a 512 *byte* binary!
I'm writing an experimental PL and I want to exercise it on real programs asap. These need to be useful (so I actually try them), but simple (my PL is unfinished). My current ideas: * A git fuzzy branch switcher (shell commands) * dotfiles sync (filesystem access) Suggestions?
TIL that PGP keyservers no longer support 'web of trust' chains of signatures, as they were being spammed by people uploading massive signature chains:
Showing 91-105 of 245 posts