Here's a tricky diff situation I haven't seen before: a minimal text diff can be ugly.
It would be nicer to match line 6 on the left with line 3 on the right, so the removed region is contiguous.
(git-diff handles this case nicely already.)
miniblog.
Structs are great in Rust, but sometimes I find them a bit heavyweight. There's a little more syntax than e.g. OCaml, for type definitions and usages.
I end up using more structs (records) in OCaml as a result.
rust-analyzer has "convert tuple to named struct", which helps.
I've realised that my favourite side projects all have fiddly bits.
It's really nice to have small features that you can add or debug in a few minutes.
> If you work on PLs long enough, you will develop a finely honed skill at creating bizarre programs like this that are technically valid but likely to trip up an implementation written by someone with a less perverse imagination than you.
https://craftinginterpreters.com/closures.html#flattening-upvalues
I've written CLI programs, GUIs, websites, but never a smartphone app. I suspect it would be tricky: playing with your WIP app on a laptop doesn't feel the same as loading it on a handset.
Have you ever written a smartphone app to scratch an itch? How was it?
Trends in mastodon decentralisation: https://socialhub.activitypub.rocks/t/analysis-of-fediverse-diversity-in-terms-of-decentralization/3252
The fediverse is becoming more diverse.
I've just added closure support to my toy programming language: https://github.com/Wilfred/garden/commit/d1fb4566a2187dfe98fb1d2278a7a0d2acd8059e
Closures are more fiddly than I expected, but I now have a much better understanding of what downward/upward funargs are :)
(Downward: passing a closure, upward: returning a closure)
Microsoft is writing a PHP parser that handles error recovery well, and the internals docs are really accessible.
It includes a discussion of handling trivia and even some sample parsing code.
https://github.com/microsoft/tolerant-php-parser/blob/main/docs/HowItWorks.md
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
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.
A surprising number of websites will reject packets if they have the evil bit set!
https://blog.benjojo.co.uk/post/evil-bit-RFC3514-real-world-usage
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!)
Showing 81-100 of 235 posts