arnsholt

Oh derp. It’s been a while since I worked adjacent to this, so I clearly misremembered some important bits. Thanks for the correction!

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.

0: https://en.wikipedia.org/wiki/Tanis_(fossil_site)

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.

0: https://lichess.org/@/revoof/blog/adapting-nnue-pytorchs-bin...

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.

0: https://blog.regehr.org/archives/1180 1: https://blog.regehr.org/archives/1287

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.

Because the Rafah crossing is currently controlled by the Israeli army. Egypt can allow all the aid it wants, it’ll still get stopped by the Israelis.

To expand on "tin was hard to come by", I believe two major sources of tin have been identified for bronze used in the Fertile Crescent: one in Cornwall, and one in Afghanistan. They had to travel really far abroad to make this stuff.

Arabic script as written in Iran (and Pakistan I think) is in a different style than most of the rest of the world. The style is called Nastaliq (the more common one being Naskh).

My favourite one was when I learned about the existence of US survey feet.

To expand a bit on why this is cool: it lets you introduce new abstractions (for example wrapping some code in a database transaction or specialised exception handling) on an equal footing with the rest of the language, all without macros.

My stint with MongoDB was brief, but I too came away with a deeper appreciation of SQL bases. I feel it's a bit like a good type system: yes, there absolutely is an upfront cost, but over time it really does save you from stupid runtime problems. It's especially important when the bugs are in the data storage layer, because if a bug causes bad data to be written to your database, not only do you need to find and fix the bug, you also have to figure out how to deal with (possibly lots of) bad data.

Also, modern SQL is an incredibly powerful language. Good SQL can save you from lots of dumb data munging code if you know how to wield your database properly. Especially for analytical queries, but also more typical application code IMO.

Ownership serves another important purpose: it determines when a value is freed.

I worked on an application implemented in SmallTalk for about two and a half years, and having the IDE be in the application was honestly a huge force multiplier, at least for the kind of complicated desktop application we were making. Basically, it made development extremely smooth because you always had the application at your fingertips and while developing no matter what kind of error happened it would trap into the debugger so you could see what was going on. No more remembering to set breakpoints or running under a debugger or anything; just write code, test and get dropped straight in the debugger if something goes awry. In some cases we could even fix the bug, and retry the failing operation in-flight. To stretch the Factorio metaphor beyond the breaking point, I would even say that the image-based nature helped there to be less mess, because you no longer have to care about the organization of your code in the source files: you edit methods and classes, but the on-disk organization of the bits and pieces is no longer a concern.

Where the image-based system does cause trouble is when you need to interact with stuff outside of SmallTalk. It basically doesn't play very well with others (in particular stateful stuff like database connections which can't straightforwardly be persisted when the image is saved and closed). But overall, I found developing in SmallTalk to be extremely productive, even in the antiquated implementation we were working with.

In my jurisdiction, damages from car crashes are strict liability, so you would in fact be legally liable. Limited to ~10 million USD for damages to objects, no limit for damages to persons. Of course the manufacturing defect would give you a credible claim against the manufacturer, but that's a separate matter. Which is why automotive liability insurance is mandatory.

Pseudo coordination is a fun phenomenon in Scandinavian. Lots of detail in NALS: https://tekstlab.uio.no/nals#/chapter/65 but an important difference with English is that the Scandinavian construction occurs with many more verbs in the first conjunct, not just _try_.