Or Forth. But all of these are extreme spaghetti-bait too. Being able to see all the code that goes into an executable, and generate a clean one using only that code, is important for good development hygiene, which of course they didn't know yet in the 1970s. Imagine trying to use version control on a REPL - it doesn't work - you have to version control the commands that go into the REPL and running them on a fresh REPL every time.
Yeah, it's not that the hurdles pointed out in this article are wrong, but IMO the jump from "it's very hard" to "it's impossible" isn't convincingly argued. In discussions of the future of C, something along the lines of "C is never going away" is frequently said, which I think is both right and wrong, depending on what precisely you mean by "going away". If you ask me, C is not going away in the same way that Fortran never went away: it's still hugely important for numerical kernels used extremely widely every day, and software like sqlite will continue to be important. But for C as a culturally defining language in computing, I think the tide is already turning.
Very chatty build scripts for one. I remember reading the build instructions for clisp many years ago, and it very explicitly told you to run the build in xterm and not something like gnome-terminal, because xterm was way way faster at getting all the output through.
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.
Downhole tools used in MWD/LWD do not use ultrasonic frequencies. Drilling is a very noisy environment. The first tool that I used employed a downhole pulser with a surface transducer and operated at about 0.5-1 Hz. That's not ultrasonic. It was a pretty low frequency signal. Data transmission rates limit the volume of information that can be transmitted from the downhole tool to the surface where they are decoded.
Your tool has to set up a pressure wave in the mud column that is detectable miles away from the tool while the well is being drilled.
This is a good recent paper authored by an experienced drilling engineer about MWD/LWD drilling history and pulser designs and data rates that can be expected.
Boy how I wish it had used ultrasonic frequencies. Sadly enough though, I spent large parts of every day in front of a laptop connected to a transducer waiting for signals to appear in the noisy stream of data coming from the standpipe transducer. Every few seconds if your tool still functioned you would get the first bit of a signal that contained toolface orientation information and gamma ray data if you had a gamma ray sub. It was a binary stream of ones and zeroes where a 1 was a pressure increase and a zero was a decrease to background. You needed to be quick on the decode because the directional driller on the rig floor was using the real-time toolface orientation to help steer the drill bit to the target formation and on to TD (total depth).
As the days went by and the hole was progessively deeper it was inevitable that some part of the downhole BHA (bottom-hole assembly) would fail due to erosion from the drilling mud, erosion at the bit/formation interface, friction along the borehole wall, etc. The hope was always that your tool would function well enough until something else failed and necessitated a round trip to replace a critical component. The costs of the round trip were placed on the service company that had the failed equipment so even if your company supplied the MWD/LWD services and the directional drilling services (DD), if your tool failed the cost of the trip fell on your service and impacted your service quality assessment which affected your rig bonus calculation.
It was common for a DD with a failing mud motor to hang around the MWD shack or keep the MWD engineers on the phone, harassing the engineers to get them to admit that their tool is nearing the point where the toolface data was so low level that it was undecodable. If he could hang the trip on the MWD he would every time so the MWD engineers were incentivized to struggle through poor signal for as long as possible when they knew from the pressure data that the mud motor was about to crater or that the drill bit needed to be replaced.
Battery failures and erosion of the pulser valve components that resulted in signal amplitudes diminishing to the point where they were undetectable were the things you knew would happen and you just hoped that downhole conditions killed someone else's tool before yours inevitably failed.
I had to read a little since I had not checked on their progress in a while.
First, I like the backgrounds and experience levels of the key personnel in the company. Many are oil and gas industry veterans with a good mix of skills - drilling, deviated well design, fracking, downhole monitoring sensors, etc.
DAS deployed downhole as their paper describes should give excellent information about conditions near the boreholes as they pressurize and depressurize the formations through the enhanced fracture networks. Induced seismicity is a common side effect of fluid injection and anyone who has watched USGS earthquake data for California has likely identified the geothermal fields by their frequent seismicity. Reducing the levels of induced seismicity related to geothermal energy production will decrease the likelihood of formation damage due to accumulated stresses in the production field. It sounds like they are able to tie specific stress/relaxation events to pressurization events so that is a very useful tool.
A lot of the earthquakes in the Permian Basin area are related to fluid injection. A DAS network could possibly mitigate some of that so a technology transfer back to the O&G industry may benefit all of us.
I agree with their goal of expanding geothermal energy production as an integral part of the power generation grid since, like they say, it is completely renewable. It does take advantage of downhole conditions in order to produce the energy and there is an opportunity to utilize existing boreholes as geothermal generation sites after the oil and gas becomes uneconomical so it could give new life to old fields and preserve jobs in the area since there will already be a trained workforce locally.
Pretty interesting. I lost track of these guys and now I see that they IPO'd a couple months ago. I expect that their business and their competition will both be increasing over the next few years at least.
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…
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.
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.
Sounds cool! Do you keep all data forever in the same table? I assume you need long retention, so do you keep everything in the same table for years or do you keep a master table for, let's say, the current year and then "rotate" (like logrotate) previous stuff to other tables?
Even with indices, a table with, let's say, a billion rows can be annoying to traverse.
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.
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.
It also can encode chess960 positions. With the article's encoding, uncastled rooks can only be decoded if their starting position is known, which it isn't in chess960.
It’s mathematically dissatisfying, but often the most optimal storage (or algorithm) solutions involve clever heuristics that are dynamically applied.
Some systems just have to be observed in order for solutions to be optimally designed around how they actually behave, rather than how they theoretically behave.
reply