miniblog.

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: https://graydon2.dreamwidth.org/307291.html
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! https://xorvoid.com/sectorc.html
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: https://inversegravity.net/2019/web-of-trust-dead/
I'm still figuring out where Copilot fits in my workflow, and I find it works really well *when I know exactly what code I want*. When I have e.g. two lines in mind, I can see if it will write them (saving me the typing), and it's trivial to validate correctness.
When you start a greenfield project, there will be parts of your code that you write and will never need to modify again. It's weird, and I don't think this phenomenon really occurs in established projects.
GitHub tracks download counts for releases, so I can see that macOS releases of difftastic downloaded are downloaded much less frequently! I don't know if it's proportional to usage though. All these operating systems have several package managers. https://somsubhra.github.io/github-release-stats/?username=Wilfred&;repository=Difftastic&page=1&per_page=5
Optimising GHC, implementing assembly pretty-printers, and the tradeoffs of implementing against an interface: https://www.tweag.io/blog/2022-12-22-making-ghc-faster-at-emitting-code/
I've released difftastic 0.47! In this release: * Language detection is now completely overridable. You can do things like DFT_OVERRIDE='*.json:yaml' to treat all .json files as YAML. * Added support for the Solidity language. https://github.com/Wilfred/difftastic/releases/tag/0.47.0
An introduction to devcontainers, the advantages of a reproducible local dev environment and where it makes sense: https://www.infoq.com/articles/devcontainers/
It's so easy to overlook the importance of tooling around a language, unlike (say) syntax. Are there any languages that explicitly put tooling first? Maybe Kotlin or Pharo?
It's really impressive to see hibernation support on RISC-V land in Linux, when you can't even buy RISC-V laptops yet! https://www.phoronix.com/news/RISC-V-Hibernation-Support
"origin" is such a long default name for git origins. I've started naming all my GitHub origins to just "gh".
Showing 341-360 of 7,506 posts