Thanks for writing this! I remember reading about dBase II as a kid, and now that I’m (much!) older and actually using some of the databases of today, I have sometimes wondered what those older personal-computer databases looked like.
The problem I always run into when I try something like this, is that I mostly (there are exceptions) use paper as a data processing medium (as opposed to a data recording medium). Most of what I do on paper is messy, half-baked, wrong, turns out to be a false start, whatever. Once all that is fixed, what is left gets tidied up into some sort of digital form, usually program code. I don’t want all that mess in the capital-N Notebook, but it is hard to know when to switch from backs of envelopes to the Notebook.
I suppose there might be a value in stopping right before the tidying-up stage (or perhaps right after it) and summarise the steps that led up to it (including abandoned approaches, and why) into some sort of document but that, for me, would be a digital file somewhere, not paper.
> I don’t want all that mess in the capital-N Notebook, but it is hard to know when to switch from backs of envelopes to the Notebook.
On the contrary, I want and enjoy recording my failures, false starts in these notebooks. These are important lessons. A culmination of "what not to do"s, or "Lessons Learnt" in NASA parlance.
My engineering notebooks are my messy garages with working things on the workbench and not working things in a pile at the corner, recording how I think, what I think, and what works / what not.
The code is the distilled version of what's working, the "second" prototype, and the polished product.
Creation is messy, and there's no running away from that. Keeping the mess in its own place allows incubation of nice things and diving back into the same mess to find parts which works beautifully elsewhere.
I feel I could write a long response to every comment in this thread as notekeeping is something I consider critical.
Knowing when to commit to “The capital-N Notebook” is something I’ve struggled with as well. What has been effective for me is to scribble daily on a marker/chalk/dry erase board and then transpose the final thought into “The Notebook” at the end of each day. This lets me format, err, mull, etc. and the final (sic clean) notebook still has enough granularity to retrace my thoughts in the med-to-long term.
As far as I can remember, most mail servers were fairly sane about that sort of thing, even back in the 90’s when this stuff was introduced. However, there were always these more or less motivated fears about some server somewhere running on some ancient IBM hardware using EBCDIC encoding and truncating everything to 72 characters because its model of the world was based on punched cards. So standards were written to handle all those bizarre systems. And I am sure that there is someone on HN who actually used one of those servers...
From what I have understood, a significant part of the reason why Sweden scrapped its nuke program last time around, was that we found out that nukes pose more questions than they answer. Obviously, you need the nukes themselves, and a reliable delivery mechanism. Neither are cheap. Preferably, you want second-strike capability, which is kind of tricky. And you want some way of balancing things so that the enemy does not take a chance on that second-strike capability and nuke you first anyway. Then you need something to use them for. At the time, the targets would probably have been ports in the Baltic states, then (involuntary) parts of the Soviet union and likely starting points for the hypothetical Soviet invasion fleet. Could we really stomach the idea of killing a few thousand Estonian civilians, probably not too happy about being used as stepping stones by the Soviets? For most military targets, there are better weapons.
Of course, it has later been argued that by entering into various more or less hidden agreements with the US, we made ourselves nuclear targets anyway, with no formal guarantees whatsoever to show for it...
Given that Sweden manufactures submarines since long ago, I'm surprised second-strike capability was even a question.
Agreed that finding a target that doesn't blow back in our own face would be an issue. Though you don't really have to answer that question to have a deterrent, almost by definition.
I haven’t studied the project that this is a comment on, but: The article notices that something that compiles, runs, and renders a trivial HTML page might be a good starting point, and I would certainly agree with that when it’s humans writing the code. But is it the only way? Instead of maintaining “builds and runs” as a constant and varying what it does, can it make sense to have “a decent-sized subset of browser functionality” as a constant and varying the “builds and runs” bit? (Admittedly, that bit does not seem to be converging here, but I’m curious in more general terms.)
In theory you could generate a bunch of code that seems mostly correct and then gradually tweak it until it's closer and closer to compiling/working, but that seems ill-suited to how current AI agents work (or even how people work). AI agents are prone to make very local fixes without an understanding of wider context, where those local fixes break a lot of assumptions in other pieces of code.
It can be very hard to determine if an isolated patch that goes from one broken state to a different broken state is on net an improvement. Even if you were to count compile errors and attempt to minimize them, some compile errors can demonstrate fatal flaws in the design while others are minor syntax issues. It's much easier to say that broken tests are very bad and should be avoided completely, as then it's easier to ensure that no patch makes things worse than it was before.
Obviously, it has to eventually build and run if there’s to be any point to it, but is it necessary that every, or even any, step along the way builds and runs? I imagine some sort of iterative set-up where one component generates code, more or less "intelligently", and others check it against the C, HTML, JavaScript, CSS and what-have-you specs, and the whole thing iterates until all the checking components are happy. The components can’t be completely separate, of course, they’d have to be more or less intermingled or convergence would be very slow (like when lcamtuf had his fuzzer generate a JPEG out of an empty file), but isn’t that basically what (large) neural networks are; tangled messes of interconnected functions that do things in ways too complicated for anyone to bother figuring out?
I don't want to defend the AI slop, but it's common for me to go on for a few weeks without being able to compile everything when doing something realy big. I can still compile individual modules and run their tests, but not the full application (which puts all modules together)... but it may take a lot of time until all modules can come together and actually run the app.
We _have_ standardized on Earth circumferences for length, only we divide by 40 million to make the numbers more sane, and got the measurement slightly wrong!
How hard would it be to fix this? Could we theoretically add or subtract enough material or make whole thing slightly more dense or less dense to compensate?
Per Wikipedia, the discrepancy is approximately 74 km, so digging a ditch with an average depth of approximately 74/2π ≅ 12 km around the circumference of the Earth would theoretically fix the problem.
Feasibility and geological implications are left as exercises for the reader.
Regardless, I suspect a more cost-effective fix would be to redefine the meter to be a couple "legacy" millimeters longer.
You take a language designed around the limitations of 1970’s computers and the absence of limitations of Donald Knuth’s brain, and then you build a document system on top of that. What could possibly go wrong? =)
Meanwhile, Cambridge has, or at least had a few years ago, at least one combined pedestrian/cattle tunnel (there was a fence down the middle!) under a major road.
Well no, the in operator is just defined to produce results equivalent equivalent to any(nan is x or nan==x for x in a); it is counterintuitive to the extent people assume that identity implies equality, but the operator doesn't assume that identity implies equality, it is defined as returning True if either is satisfied. [0]
Well, more precisely, this is how the operator behaves for most built in collections; other types can define how it behaves for them by implementing a __contains__() method with the desired semantics.
reply