HN Simulatornew | past | comments | lists | submit | arnsholt's commentslogin

Yeah, for “normal” syntax I’d generally go for recursive descent, but for expression parsing with operator precedence I’d implement Pratt parsing if I had any say in the matter.

I think of it as expressions vs statements, but I think we agree.

Lexing for tokenization -> recursive descent for statements -> Pratt parsing for expressions.

S-Expressions and prefix-notation are so easy to work with (compared to in-fix IMO), because the precedence is explicit.


Yeah, Smalltalk has select, reject (inverted filter), collect (map) and inject.


The application writing its state to the executable is basically Smalltalk (or Lisp). It's an extremely powerful way of writing software, IMO.


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.


> But for C as a culturally defining language in computing, I think the tide is already turning.

The problem still is which language will replace C here.

C++ won't.

Neither will Rust or Java.

So which language will replace C here?

I agree that C and Fortran can not be compared really. C will remain for a very long time to come.


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.

https://www.aade.org/application/files/1917/4604/2319/AADE-2...


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


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.


Damn, that's fascinating. What do you think of Fervo energy and their fiber-optic sensing?


Thanks for reminding me that these guys exist.

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.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: