kqr

Completely with you. I've played with limited syntax highlighting in the past (class names were blue, to answer the question in TFA), but for the past few years I've been running with plain black-on-white, with only a green highlight for comments, and a subtle yellow for strings.

https://i.xkqr.org/lighttheme.png

I think the relatively bold highlighting of comments is important – lots of times I'm the only person to react to incorrect comments because people's themes blur them into the background and they stop reading them.

(But then again, I'm crazy. I colour diffs blue and orange: https://i.xkqr.org/blueyellowdiffs.png inspired by similar advice in https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... I think it has worked to help me notice things other reviewers have not, but it's hard to know for sure.)

This all rests on the assumption that design errors are independent beween LLM-generated programs for the same specification. That's not true for humans (Knight and Leveson, 1986) and I highly doubt it's any more true for robots.

(On the other hand I just found out about Ron, Baudry, Monperrus, 2026, which seems to say "sure, problems are correlated, but it could still be useful.")

> A weird poorly specified format that is only fully editable from one editor.

While this has been true historically, the Org maintainers are moving away from that approach.

The example that comes to mind is that parsing and interpretation of formatting markup such as *bold* and /italics/ used to be controllable by Emacs Lisp variables that dictate things like which neighbouring characters cancel the interpretation of the markup as markup, or the maximum allowed distance between delimiters for them to count as a pair. Such things have been moved into standardised parsing routines now, with no variables for customising it.

The problem with the wheel is not inventing it so much as finding ways to use it. Aside from capstans and pulleys, the wheel is mostly only useful in combination with good infrastructure or complicated machinery.

> PageRank doesn't work today

That's silly to say when it can be fruitfully applied in so many situations. Any time you have noisy and sparse pairwise comparisons, you can think of them as one of the sides of the pair vouching for the other side. If you then solve PageRank for the entire graph, you get a somewhat principled global ranking of all items.

I used it recently to construct a top list of books I read a year based only on sloppy pairwise comparisons between them. I've also used it to judge the quality of other relevance algorithms while keeping the human input to a minimum.

I don't know of many alternatives that work better than PageRank under those conditions. Thurstone-type models require dense comparisons, and Elo doesn't fare very well when the comparisons are too noisy.

> One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.

https://www.linusakesson.net/programming/syntaxhighlighting/

But on the other hand table are represented with trees![1]

[1]: https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas...

Right! As I was reading I was thinking of ways to evolve this, and one idea kept coming back: What if we don't store compiled code in the SQLite database, but something primitive like s-expressions representing code? Then we could update definitions live as regular INSERTs. Then I realised I'd reinvented Lisp.

> One of my favourite ways to develop apps is to use Lua - for everything. Construct an efficient core application framework, then embed the Lua VM in it, and then do all program logic and control flow in Lua, then put the Lua bytecode in the binary with luastatic, and off we go.

Okay, you have to expand on this. Do you have a blog post or anything that goes into more detail?

Oh, and I forgot and now it's too late to edit my comment. 6400 has a bunch of nice divisors too. A half-turn is 3200 mils, a quarter is 1600, a quarter of a quarter is 400, etc. A sixth of a turn is nearly 1000 mils. A tenth is obviously 640 mils.

It's also useful for sighting distances when the width or height of something is known. A knuckle on your outstretched arm is roughly 30 mils, so you cover the thing with your hand, count knuckles, multiply by 30, then divide the size by that number to get the distance.

You can calibrate your knuckles by doing this is reverse. Put up a target 1 cm wide and back up until it's just covered by a knuckle. Measure how far you got and divide.

It was when I thought about why this works I started really understanding radians.

I think your last sentence is getting close to the truth. You're no longer the audience for those descriptions. Other robots are.

I'm not saying that's good or bad because I don't know, but I think that's the idea of dumping all that junk into PR descriptions.

However, annoyingly, we still need to review those descriptions very closely, because the robots are trained to put a lot of weight into things they read in the documentation. And they tend tospresent loose speculation as fact. They often end up documenting some assumption that isn't true, then end up writing code as if it were.

Code-generating robots are pretty bad at property-based testing, in my experience. They can do it but they still need a lot of hand-holding. They often regress to writing a mirror implementation as the oracle and trying to enumerate a fixed set of examples they find meaningful.

I also write a lot about things I learn and not always fully understand yet. My secret worry is that one of my readers will meet me in person and quiz me verbally on the subjects of one of my articles. I would end up sounding really dumb compared to the impression made by the article!

When it comes to pretending to know something about things you don't understand, I think there's a big difference between talking and writing. Talking is bad because you're not equipped to form intelligent off-the-cuff sentences about the thing. But writing can be okay, if done with care.

Some things I would be able to talk about because I have insense opinions enough to remember (e.g. insurance purchasing decision logic), or they are easy to remember (the alpha-max plus beta-min algorithm), or I wrote about them recently enough to remember (how to perform an FFT). But ask me about anything else (sloppy confidence intervals for Pearson correlations?) and I'd just stand there.

A lot of the software I really admired in the early 2000s was developed by single persons using Delphi. It seems to me like there is (was?) something promoted by a Delphi environment that is rare to find elsewhere, that lets people (a) quickly prototype cool stuff, and then (b) sustainably grow it into a mature product as it gains users. I wish I cared enough to learn it, but there's so much else I need to learn first!

You probably know it, but Boyd did not at all suggest speed beats quality. If anything, his realisation was the opposite: the US aircraft had a more open canopy and thus improved quality of observation, and that was what won despite the superior power and turning performance of the Soviet aircraft.

I find the recommendation in favour of discrete categories over numeric probability for confidence level intriguing, because it goes against the grain of all advice I've read for humans interested in forecasting.

The easiest argument in favour of numeric probability is that it's simple to evaluate. Someone claiming to be 90 % certain better be right about nine out of ten times -- no fewer, but also not too often! This is useful when you're learning to judge your own confidence, which most people are bad at. (Almost everyone can train themselves to be better at i but some people seem to be good at it with no training.)

The typical argument against categories is that people can mean very different things with the same word: https://i.ibb.co/kQT4Ymz/q.png

It seems like TFA gets around these problems by creating a translation table between a fixed set of categories and the probabilities implied by the model for those categories. That's an interesting approach!

This was RyanAir's CEO. https://www.theguardian.com/business/2012/feb/28/ryanair-sta...

> On one particular Friday afternoon, he stated a conjecture that he hoped was true, and invited us to try to help him prove or disprove it.

This kind of professor/researcher/teacher needs more praise. One of the first engineering courses I took when I started out in higher education was taught by such a person.

Maybe it's just me, but I never felt so welcomed and included during my time in higher education as when that lecturer told a bunch of first-year students "here are some things we haven't figured out which you can help with, let me know if you come up with something". It was inspiring and a great introduction to what's otherwise a rather dull first couple of years of academia.

I agree. I didn't mean to imply the article should have stated that. I just wanted to add to the article with additional context that's hopefully helpful to some HN readers.

The article doesn't really state why one would do this, so here's my reason: I'm the sort of person who likes to challenge myself to geometrical problems, but I'm not good enough at it to do any higher maths.

Flight simulation, or, more specifically, finding my way around the sky by radio navigation aids scratches that itch. The procedures involved are precisely solving simple 3D geometrical problems on the fly.

I was thinking of the British Empire. Their naval technology was superior enough to overpower the distance term.

I was under the impression the Dutch didn't really wage interstate war in the same sense, but rather that a bunch of paramilitary private organisations happened to fly Dutch flags. I have to admit I know very little about the Spanish case, but again I thought they mainly fought proxy wars with other European colonial powers, i.e. both were equally disadvantaged by distance.

It's not exactly rocket surgery, is it? Because they are fighting on the other side of the world. I feel like the article glosses over this way too quickly.

It's not surprising the US aren't winning. It's surprising they are at all able to do something that resembles waging war at that distance. Wars are incredibly hard to fight away from home. On the other side of the world? There is basically only one country in the history of ever that has been able to do that.

The article does go on to discuss the Kuwait case and that's a meaningful discussion to have, because actually winning a war so far away is surprising. It's interesting to dig into why that might have been, and the article briefly does. But why they aren't winning is less interesting.

For more meat on how important a factor distance is, Bueno de Mesquita's The War Trap presents one of the most accurate models for predicting wars[1] I know of. That model measures the fighting ability of a country by two factors:

1. It's at-home military power as a sum of population size, metal production, fuel consumption, military expenditure, etc.

2. It's power projection as the distance between its capital and the closest point of enemy land.

Note that the second number is weighted equally to the sum of all other factors, because wars are a logistical nightmare.

[1]: https://entropicthoughts.com/war-what-is-it-good-for

On a similar note, people are way too precious about their dead-tree books. Feel free to chuck them in bags, make notes in the margins, fold pages, underline, and strike through text in them. It's yours. Make it yours! Your scribblings don't detract from what's in there – they elevate it to something unique.

(This is particularly true if it's a book that's still in print, or was in large enough print runs it's easy to buy another second-hand copy when the one you have falls apart. It's still somewhat true even when that's not the case.)

Not a single 24-hour analogue face? That unexpectedly turned into one of the best reasons I keep carrying my smartwatch.

Because for it to be effective it must have reasonable cost compared to the benefit. The cost for such a sweeping lifestyle adjustment seems quite high, and the authors have not showed any benefit to interventions.

The article never says anything about causation. It says sleep regularity is a predictor of mortality. That means if you find someone who already has poor sleep regularity they're more likely to die sooner, not that if you force someone into a bad sleep schedule they will become more likely to die sooner.

Self-stopping is called autonomation (or jidoka) in lean/Toyota terms. It's born out of the realisation that automation is capable of producing mistakes at a very high rate, so anything automated needs a way to detect when it's operating outside of the narrow envelope for which it is designed, and shut itself down.

Vaguely related realisation I had a couple of years ago: if you don't need a complicated mobile app, but just something simple for your own use, you can write and run Perl scripts in Termux and there you go – an app, without learning any Android at all!

Not only must there be trust, but there must also be a resolve to make deeper fixes to problems surfaced through the andon system. It's a typical mistake to forget that part. If the response to a problem is patching over the immediate symptom, then the cord will keep being pulled for the same reasons so often no work will end up getting done.

Then the andon system is abandoned as "didn't work for our organisation".

Workers should pull the andon cord (and thus stop the entire production line!) when they need to go to the bathroom, for example. The solution is not to sternly tell the worker to hold it for longer, nor to have a replacement worker come over, but to review scheduling and include more appropriate bathroom breaks between shifts at the line. (Or, if the problem affects one worker disproportionately, figure out some alternative way for that worker to contribute.)