That book is partly what made me think this way! I knew the high-level story, or thought I did, but I came to understand I only knew part of the story. Alas I can't remember who/where I saw it recommended to thank them!
Shopify / Royal Academy of Engineering Research Chair in Language Engineering. https://tratt.net/laurie/
1,543 followers 84 following 344 posts
view profile on Bluesky
That book is partly what made me think this way! I knew the high-level story, or thought I did, but I came to understand I only knew part of the story. Alas I can't remember who/where I saw it recommended to thank them!
New post: Why Firsts Matter tratt.net/laurie/blog/...
The idea that static types mean you don't need tests has done our field a great disservice IMHO. I test the life out of systems I write that use all sorts of type system features to make it hard/impossible to represent many unwanted states, because so many unwanted states are still possible.
There's a reason I only partly agree with the article! But that doesn't mean it's not useful for making me wonder if we've over-emphasised one solution to the problem (in the same way that the article might over-emphasise another solution). [As often in life, I suspect the middle is nearer optimal.]
I tried studying that book intensely early in my career, and I learnt a lot from it, thought not always in the ways I expected. Looking back, maybe the first 40% or so is quite profound and changed how I think about OO; the remainder was so far over my head that I could not form a judgment on it!
Personally, for expert programmers, I would like access to rigorous type systems *and* different architectures of software systems. There are some obvious contenders, but they've rarely been tried at scale IMHO.
I like articles which challenge our assumptions, even when I only partly agree with them. This article posits that type systems in programming languages are a poor substitute for different architectures of software systems. programmingsimplicity.substack.com/p/type-check...
It's muddy as there are many `vi`s (or, at least, many forks). On OpenBSD the base `vi` is basic and not extendable. OK for quickly editing a config file, but not much else IMHO. `vim` (or `neovim` as I now use) is a huge, customisable beast in comparison, that can be turned into an IDE if you wish.
Related to that is the challenge of scale: some language features only turn out to be a good or bad idea when you try them on big (big!) problems. And then we're in a combination of chicken-and-egg-land and lotteries whilst we wait for people brave enough to take the risk and report back.
When I upgraded my OpenSSH a couple of weeks back, I started getting some surprising (to me) warnings when using GitHub. I'm not sure I'd enjoy being the person who has to upgrade the fleet of servers that are now being fingered as culprits!
Perhaps due to narrowness of thinking on my part I think any plausible CPU will have to have a fixed, and fairly small, amount of "quick access slots" whether those are registers, a stack, or something else (e.g. the Mill's belt).
Register allocation is one of those things that seems like it should take 2 days to implement. Everyone I've ever spoken to about it has found all sorts of surprises that cause those 2 days to balloon. This great post will save future folk much time! bernsteinbear.com/blog/linear-...
Not quite: it's `void` in disguise as it consumes arbitrary number of arguments and doesn't return them!
I have been a Unix user for a... long time... yet only today did I accidentally discover that `:` is a built-in shell no-opt.
Finally, 3 years and 3 months after I bought a Framework laptop, there is an update for the (frankly, pretty poor) BIOS. But... it doesn't work. It says it does, but nothing is updated. Thankfully I eventually stumbled on this post community.frame.work/t/unable-to-... -- what a pallava!
Indeed, I'm increasingly noticing obvious mistakes in English subtitles for English language programmes. Which is... interesting.
I've noticed that even if I have only a passing familiarity with the on-screen language, there'll be clear oddities in the subtitles. Sometimes it's due to compressing lots of speech to a smaller amount of text, but sometimes it seems just plain ... wrong or, at least, suboptimal.
I'm interested to see if that is what happens. It seems to me like it should -- but, as yet, I'm not seeing much reflection on the matter. Perhaps it's just a matter of time!
New post: LLM Inflation tratt.net/laurie/blog/...
If I gave the impression that I didn't think that reviewers who go down this route should not be equally punished, I apologise. It seemed so obvious to me that they should that I (foolishly, in retrospect) didn't think to make it explicit.
I assign blame to actions: when it can be proven that an individual reviewer has used an LLM for their review, name and shame them, because they absolutely deserve their misconduct to have consequences!
By all means, help the community find out who the bad reviewers are (which requires telling someone that you're doing so!): but trying to exploit other's moral weaknesses for one's own gain is not a valid excuse.
If the authors had prenotified someone of what they were doing, then I would applaud them for trying to help us discover bad reviewers. As yet, there is no suggestion this is what any of them did AFAIK. [The analogy is imperfect, of course; analogies nearly always are!]
Indeed. My analogy is that the authors slipped a brown envelope with cash in with their paper and if the brown envelope came back unopened their defense is "I didn't bribe anyone, because they didn't take the money". But they still tried, immorally, to take advantage of other's immorality.
I think the causal relationship is the other way around, but Yes, they have lots of similarities. [The central keys on the Maltron, IMHO, are pointless: I only use 10% of them...]
Yes, although I'm not sure this would have helped very much TBH. But, since I didn't try it, I will reserve judgment. I'm sure there are more things I could try, but I realised I was in severe danger of the sunk cost fallacy!
New post: Comparing the Glove80 and Maltron keyboards tratt.net/laurie/blog/...
The LLM-for-software Yo-yo tratt.net/laurie/blog/...
I thought the image generators had become better than that by now! Admittedly, for someone of my hamfistedness, I'd probably make as good a tune with that as a more conventional guitar...
Reading that paper now makes me realise that I've changed a number of my opinions on PLs over time. I'll also be interested to see if the Verse language from Epic -- whose evaluation system is, as far as I can tell, very similar to Icon's -- can solve any of the issues I couldn't.
I was also surprised a while ago when I discovered that "performance desktop" now almost exclusively means "for games". My current motherboard makes disabling RGB relatively painless; my previous motherboard made doing so very difficult. And it stayed on during suspend!
New blog post by @cfbolz.bsky.social: "How fast can the RPython GC allocate?" pypy.org/posts/2025/0...
But before all that he wrote and produced many wonderful songs. Few are better than Warmth of the Sun. A beautiful Brian lead vocal, lush backing harmonies, and a supremely weird chord sequence that should be horrible, yet somehow is perfect www.youtube.com/watch?v=uoDm...
Brian Wilson's life, to the extent I ever been able to tell, was not a happy one overall. His obituaries inevitably lead with Pet Sounds, the drama with Smile, and its aftermath.
Looking forward to it! If you wanted another angle on this, I'd love to hear from Robert O'Callahan on `rr`, and given your tooling background, you'd surely be able to ask him deeper questions than just about anyone! [No, I've never met him (online or in person. I just admire the idea!]
It could be, though I think that relatively unlikely in this particular case (but maybe not in others). It might also be random flaws in predictors (etc. etc.) and so on. There's no real way of knowing. The black box strikes again!
This means that I'm now more sceptical of benchmark numbers on older CPUs. But, like many people, budgets are what they are and I often have to make do with old CPUs...
I have now repeatedly seen this sort of thing: new CPU does what I expect, old CPU randomly performs poorly. In other words, generation to generation, the performance mean might not change very much, but the performance distribution seems to be tightening quite considerably.
For example, a couple of days ago I optimised a loop, removing several instructions from it. Performance on new CPU == 40% better. Performance on old CPU == 5% worse. Why?!
Their per-core performance is usually similar -- indeed, the older CPUs (all of them the same generation!) are clocked slightly faster -- for a given program BUT the older CPUs have all sorts of weird performance quirks.
CPU performance is a fascinating topic. In one way, the differences between newer generations is quite small. In another, it can be quite big. I now regularly benchmark on a fairly new and several fairly old server CPUs, and the differences have surprised me.
This is really excellent stuff -- it validates IELR in my mind! Now all I have to hope is that some brave soul implements IELR in grmtools/lrpar!
Finally I'm happy to say that someone else has reimplemented IELR! Start at this blog post branchtaken.com/blog/2024/07... and explore the report and more.
When I first read the IELR paper, I assumed that was the Right Way To Do Things, but (a) I lacked the time to examine it myself because (b) these algorithms are always hard to implement.
Long story short: our current algorithms occasionally generate wrong LR tables in the face of disambiguation operators (`%prec` and so on).
Sometimes one can use "raw LR" grammars, but often it is convenient (and sometimes necessary) to add additional disambiguation. That then causes problems with LR table generation and minimisation.
LR parsing is the static typing of parsing: if your grammar is provably LR, you've ruled out a whole class of ways it can go wrong. Every time I've examined a non-LR parser, it has had unexpected bugs: parsers are hard to get right!
University of Jan & Natalie, where he occupies the position of Director of Strategy, Operations, and biscuits.
I consider this acceptable reasoning on both fronts ;) Those of us from Somerset are used to being the county championship bridesmaid... It would almost feel weird if we did ever win it!
You are not alone. Obviously you're not supporting the right team (i.e. Somerset), but I appreciate that there may be extenuating circumstances (i.e. where you were born).
I like to think I'm a terrible person, generally, with terrible organisation just one of my many skills. I must admit that a couple of the roads in Bertinoro, though not long, are hard enough work to walk up...
RPython is really only meant for writing interpreters in ("RPython" is best thought of as both a restricted subset of Python / a language, and a meta-tracing system).
I wouldn't call the GC aspect an incompatibility per se; rather it is programs and programmers assuming that a particular implementation is coterminous with the specification. This can feel like a pedantic distinction to many folk, I admit.
I wouldn't expect *exactly* the same outcome, but I would expect an outcome compatible with the language's semantics (and I believe PyPy delivers on this). Where life gets harder are things like C extensions, which are often (not intentionally) intertwined with CPython's implementation.
I think PyPy shows that the *language* can become fairly fast (not C speeds, of course!) but whether CPython the *implementation* can enable that is a more difficult question to answer (and one many have tried tackling).
Agreed. And I speak as someone who's done quite a bit of research in this area (with the general aims you're suggesting).
One is not entitled to anything from an open-source project. But, equally, an open-source project is not entitled to prevent analysis of its technical nature and management. So much of all of this rests on an assumption of good faith which, mostly, I'm happy to say is adhered to!
I have no idea and I don't think that should detract from the analysis. [AFAICT they have, at the very least, tried to be good citizens in terms of bug reports and the like. I don't pretend to know all the ins and outs, though, and perhaps there's more going on.]
That was a trigger, but it doesn't really explain (for me, at least!) why they've continued proliferating and changing. I had no idea that OpenSSL 3, for example, had such different performance properties vs OpenSSL 1...
I have wondered for a while why SSL libraries have proliferated: now I have an answer, even if it's much different and longer than I expected www.haproxy.com/blog/state-o...
Yes, that is a definite possibility, particularly if we expect marginal gains (say <=1.5x). My assumption (again, based on zero evidence or expertise!) is that there is a decent chance of significant improvement (say >5x). I have no idea if the plausible performance ceiling can be estimated or not.
So far I would say about 90% of the people I've asked have replied "er....". I think mostly we (1) equate "CPU" with "transistor" with "silicon" (2) assume the way these things came about was preordained. I think I was jolted into reconsidering this after reading the history of the transistor.
Perhaps we now have our first realistic hint that there might be something better. No, I don't expect this to lead to a new product next year, perhaps never, but it's still fun to make further guesses in an area I barely understand! www.zmescience.com/science/news...
A question I've intermittently asked people is: how likely it was that we picked the perfect material for transistors -- i.e. silicon -- so early on? Since my answer was "not likely", I assumed, with zero evidence or expertise, that something better probably exists.
One of the great joys of being an optimist is that I not only say, but nearly always mean, "better late than never". "Too little, too late" does not seem to me an enjoyable way of viewing life.
snare-0.4.12 out, which solves the "time dependency doesn't compile on recent versions of rustc" issue tratt.net/laurie/src/s...
Question: how many colours can we cope with and what other analyses would be improved by colouring functions? [I don't have an intuition as to the "right" or "a realistic" answer, so I'm asking naively!]
I think it's best at this point that we agree to differ on our interpretation of non-strictly monotonic :)
MONOTONIC isn't "most correct" if adjtime can be called. Pick your poison!
My understanding is: if adjtime puts time backwards by a month (say) and then there are no further adjustments, MONOTONIC can return the same time for the next "month in the real world".
IMHO the docs for neither clock specify clearly the guarantees I want to know. But, of the two, MONOTONIC_RAW seems to me less likely to give misleading answers.
Frequency adjustments can be arbitrarily long: IMHO one can't assume they aren't noticeable. I have seen machines whose clocks are out by weeks, and then someone has called adjtime! I'm unconvinced that MONOTONIC is a useful timer: MONOTONIC_RAW is nearly always what one wants AFAICS.
I'm not sure what "real" means (and I'm not just being pedantic!). MONOTONIC is non-strictly monotonic: 10 seconds can elapse in the real world but it can say 0 seconds have elapsed. MONOTONIC_RAW (IIUC) is strictly monotonic and will say 10 seconds have elapsed.
We might have different definitions of "frequency adjustment"? To me, the definition of MONOTONIC is "non-strictly monotonic". it can get stuck (indefinitely!) returning the same value, so isn't "seconds in the real world". MONOTONIC_RAW is "strictly monotonic" is is "seconds in the real world".
My assumption is different, though the docs I have aren't strong enough to validate your or my assumptions AFAICS :) I currently believe clock_gettime always returns units as seconds. My guess is that MONOTONIC and MONOTONIC_RAW probably derive from the same source and have the same units.
I agree, units in seconds is vital. I haven't yet found any documentation saying that the units aren't seconds, though, so am very interested in what documentation you've found!
I am very curious as to where (and why!) it's documented not to be in seconds!
Do you have a web link to such a man page? I can't see this on Debian stable or unstable (though perhaps I'm reading into those man pages what I want to see!).
Given that it returns a timespec, how can the result not be in seconds? Maybe I'm missing something obvious...
Indeed, but that doesn't clarify if it guarantees to always tick forwards: CLOCK_MONOTONIC on Linux doesn't go backwards, but it can become "stuck" at the same value arbitrarily long (which leads to... surprising... results if you're benchmarking).
On Linux, is CLOCK_BOOTTIME similar to CLOCK_MONOTONIC (non-strictly monotonic) or CLOCK_MONOTONIC_RAW (strictly monotonic)? The manpage I have says it's "identical to CLOCK_MONOTONIC", but that would seem the odder of the two choices to me, so I hope the description is wrong!
Probably that. But there's a possibility -- tiny, small, microscopic -- that the programme chairs are desperately chasing up a small handful of reviewers who continue honing the skills necessary to ensure they will turn up late to their own funeral.
I don't know why, but I assumed naked functions would never be stabilised! To punish me for my complacency and stupidity, our CI broke in two ways on two subsequent days as the support landed. I deserved it!
I couldn't agree more! Another variant of this -- I assume ultimately deriving from the same insights as the Fletcher–Munson curve -- is how different things become apparent at different volume levels. The human ear has all sorts of interesting quirks!
Maybe -- I'm an optimist! -- with ever-increasing levels of technology we might see people willing to let musicians sound human again. We can leave the perfect sounds to machines --- and they can listen to the results, not me.
It's sad to think of so many albums, with so many great songs, recorded to a click track and diminished because of that. This isn't the sort of thing that can be easily fixed in the future (e.g. as remastering/remixing sometimes does).
It's not something you can easily put your finger on. I remember on Nevermind wondering why Lithium felt... weird. A few years back I discovered the reason: it's the only song done to a click track.
When musicians -- excellent musicians with an excellent sense of timing -- play together, they naturally do things like speed up during the most energetic parts of a song. When you take that away, something that many of us enjoy is lost.
As I like to do occasionally, I've been pulling apart some songs recently. Every time I do this, I learn something new, even for songs I thought I knew inside out. This time what became obvious to me is how much more fun music recorded without a click track is.
As CPUs have become better at optimising code -- but necessarily more complex -- I've become increasingly surprised by the performance differences of "normal" looking code across CPU generations. Sometimes I can guess at causes, but mostly I end up bemused.
If there is research on this, I suspect one would at least want to update it for modern hardware and software and probably also think carefully about context. [e.g. I've anecdotally noticed huge differences in threading performance across OSs, but I haven't measured it carefully.]
Please feel free to write an email when you're ready!
My pleasure!
(I say "we" which is immodest of me: this is something we pick up for free from BDWGC, modulo the TLS scanning we added).
There are various optimisations one can do to reduce the amount of memory scanned (e.g. "this struct can't contain a pointer so don't scan its instances"). Some are probably fairly easy; some might be harder.
Yes, we scan everything: we deliberately don't want to pin Gc in that way (there are other Rust GCs which more-or-less do this, and we wanted to try something with different ergonomics).
Hamming has an answer IMHO: when you have a new line of attack, retry the problem. That does imply, though, that you don't endlessly train people in the old ways: you have to have a new insight. That might take a long time to come and, probably, it will come via some external insight.
Hamming has a profound observation on this in You and Your Research
There's a related problem where fields (1) hit a brick wall that is insurmountable unless an earthquake happens (2) no-one wants to admit that. Generations continue being trained to research at, or behind, the brick wall. Admitting the existence of the brick wall is poor form. Best ignore it.
New post: The Fifth Kind of Optimisation tratt.net/laurie/blog/...
