And in case people think ultrasonic signaling isn’t a real thing, it very much is. In the oil and gas industry, it’s how measurements taken while drilling a hole are sent back to the surface through the drilling mud.
John Regehr tried to start an initiative to make what he called Friendly C, removing some of the most blatant C footguns, and even that turned out to be extremely hard to get consensus on: https://blog.regehr.org/archives/1287
If I had to guess, they probably have some ideas. In Your inner fish (an excellent book, BTW) Neil Shubin has an afterword where he describes roughly how they went about deciding where to look for Tiktaalik. Basically, you start with whatever thing you want to find out more about; in the case of Tiktaalik, the transition of tetrapods from aquatic to terrestrial living. So you start by finding out where you have exposed sedimentary rocks of the correct age likely to be contain fossils. Next, you also need to the rocks to expose the right kind of environment: desert sands or deep ocean environments aren't going to help you find Tiktaalik, for that you need shallow waters and intertidal zones. Finally, it needs to be somewhere you can get to. So in this case, I wouldn't be surprised if they were purposefully looking for soft body preservation (especially since I think Cambrian fauna generally was quite soft and squishy).
From memory, to get fossilised soft tissues you want the remains to be buried extremely rapidly in an environment where the soft tissues don't decay (typically an anoxic environment, so for a shale basically covered in mud). So a mudslide is one option, and I think there are some lovely fossils North American from the end of the Cretaceous that are hypothesised to have been buried by the tidal wave caused by the Chicxulub impact.
Edit: After some googling, the Cretaceous fossils I was thinking of is Tanis,[0] which is in fact plausibly (but not universally) thought to be covered by the earthquake caused by the impact, before the tidal wave arrived.
I worked as a Smalltalk developer for a few years, and it spoiled to such an extent that I’ve tried to make an extension for IntelliJ to replicate the browser for Java development. Maybe I should revive that project, actually…
I wasn’t involved in the day to day operations of the system, but it had records going back to the 90s at least I think. I think data related to non accepted offers were deleted fairly quickly (since they didn’t end up being actual customers), but outside of that I think everything was kept more or less indefinitely.
Yeah, basically. The full system actually has more date stuff going on, to support some other more advanced stuff than just tracking objects themselves, but that's the overall idea. When you need to join stuff it can be annoying to get the SQL right in order to join the correct records from a different table onto your table of interest (thank Bob for JOIN LATERAL), but once you get the hang of it it's fairly straightforward. And it gives you the full history, which is great.
The core system at my previous employer (an insurance company) worked along the lines of the solution you outline at the end: each table is an append only log of point in time information about some object. So the current state is in the row with the highest timestamp, and all previous stars can be observed with appropriate filters. It’s a really powerful approach.
Lichess uses a scheme which is probably more efficient on average, described on revoof's blog[0]. Basically, it's a variable length scheme where the first 64 bits encode square occupancies, followed by piece codes (including castling, side to move, and ep with some trickery), followed by half-move clocks if necessary.
For about two and a half years I worked on a Smalltalk system, written in a quite old Smalltalk, which gave me two idiosyncrasies editor-wise: I no longer care very much about syntax highlighting (though I don't really bother to turn it off), and I now prefer to use proportional fonts for my programming. The only syntax highlighting I missed in the Smalltalk was a fading out of comments (which would in fact have prevented a stupid issue similar to the comment thing shown in the OP).
Good PBT code doesn't simply generate values at random, they skew the distributions so that known problematic values are more likely to appear. In JS "__proto__" is a good candidate for strings as shown here, for floating point numbers you'll probably want skew towards generating stuff like infinities, nans, denormals, negative zero and so on. It'll depend on your exact domain.
I'm pretty sure the publishers are alleging that a crime has been committed. In that case, private parties can't open a suit (at least if Swedish criminal law is at all similar to Norwegian law), so this asks the police to open a criminal investigation into the matter. What happens next in the Norwegian system at least is that the police will conduct their investigation, and at some point when the police consider their investigations complete the prosecutor's office will decide what to do next. Next steps can be concluding that no crime has occured, to ask the police to investigate further, that a crime has been committed but the evidence are insufficient for a trial, or that someone should be tried.
I found the Smalltalk way of working in the running environment to be very programmer efficient too, and that it was by far the smoothest development experience I’ve had, even in a pretty dated and clunky Smalltalk at that point. And debugging wasn’t really a problem in my experience, but we stored application state outside of the image in an SQL database (initially Sybase, then MSSQL), which probably removes some «haha, the image has some weird data saved in the dark and dusty corners» issues.
I worked on a Smalltalk system which ran on Visual Smalltalk Enterprise, and in that system the image opened its windows as native Windows GDI windows, which made the application quite seamless in the OS (except this was in 2016-2018 and VSE was last updated in ‘99, so the look and feel was a bit dated :D).
I've only used PBT a few times, but when it fits it's been extremely useful. A concrete example from my practice of what has been pointed out in this thread, that you want to properties of your function's output rather than the output itself: I was implementing a fairly involved algorithm (the Zhang-Shasha edit distance algorithm for ordered trees), and PBT was extremely useful in weeding out bugs. What I did was writing a function that generated random tree structures in the form I needed for my code, and tested the four properties that all distance functions should have:
1. d(x, x) = 0 for all x
2. d(x, y) >= 0 for all x, y
3. d(x, y) = d(y, x) for all x, y
4. d(x, z) <= d(x, y) + d(y, z) for all x, y, z (the triangle inequality)
Especially the triangle inequality check weeded out some tricky corner cases I probably wouldn't have figured out on my own. Some will object that you're not guaranteed to find bugs with this kind of random-generation strategy, but if you blast through a few thousand cases every time you run your test suite, and the odd overnight run testing a few million, you quickly get fairly confident that the properties you test actually hold. Of course any counterexamples the PBT finds should get lifted to regression tests in addition, to make sure they're always caught if they crop up again. And as with any testing approach, there are no guarantees, but it adds a nice layer of defense in depth IMO.
In discussions like this, I sometimes feel that the importance of related work like the increasing use of Rust in Android and MS land is under-appreciated. Those who think C is fine often (it seems to me) make arguments along the lines that C just needs to have a less UB-prone variant along the lines of John Regehr and colleagues' "Friendly C" proposal,[0] which unfortunately Regehr about a year and a half later concluded couldn't really be landed by a consensus approach.[1] But he does suggest a way forwards: "an influential group such as the Android team could create a friendly C dialect and use it to build the C code (or at least the security-sensitive C code) in their project", which is what I would argue is happening; it's just that rather than nailing down a better C, several important efforts are all deciding that Rust is the way forward.
The avalanche has already started. It is too late for the pebbles to vote.
After a couple of years working in Smalltalk, I’ve acquired the hot take that all the code should be in a proportional font. Admittedly it doesn’t work quite as well for brace syntax languages, but in Smalltalk and Python it’s great.
KT is obviously (from context here) Karahan Tepe, and GT thus Göbleki Tepe. ANE is a standard abbreviation for Ancient Near East. For PPNA Wikipeda supplies Pre-Pottery Neolithic A, which is a subdivision of the Early Neolithic period.
Underscore for italics probably has its origins in the use of a solid underline as markup in a manuscript/typescript instructing the typesetter to set that fragment in italics (underscore generally being frowned upon in professionally set material otherwise, I think).
Oh yeah, the good hand crafted grammars are really good. For my PhD I worked in a group that was deep in the DelphIN/ERG collaboration, and they did some amazing things with that.