I agree that programming language can be a better (denser, more precise) encapsulator of intent than natural language. But the converse is more often true; natural language is a denser and more precise encapsulator of intent than programming language.
I think there's some irony in using Russell's quote being used this way. My intent will often be less clear to a reader once encoded in a language bound inextricably to a machine's execution context.
Good abstraction meaningfully whittles away at this mismatch, and DSLs in powerful languages (like ML-family and lisp-family languages) have often mirrored natural(ish) language. Observe that programming languages themselves have natural language specifications that are meaningfully more dense than their implementations, and often govern multiple implementations.
Code isn't just code. Some code encapsulates intent in a meaningfully information and meaning-dense way: that code is indeed poetry, and perhaps the best representation of intent available. Some code, like nearly every line of the code that backs your server vs client time example, is an implementation detail. The Electric Clojure version is a far better encapsulation of intent (https://electric.hyperfiddle.net/fiddle/electric-tutorial.tw...). A natural language version, executed in the context of a program with an existing client server architecture, is likely best: "show a live updated version of the servers' unix epoch timestamp and the client's, and below that show the skew between them."
Given that we started with Russell, we could end with Wittgenstein's "Is it even always an advantage to replace an indistinct picture by a sharp one? Isn't the indistinct one often exactly what we need?"
Very cool app. Is there a way to periodically import from a Google Sheets spreadsheet? I track a bunch of things there on a daily basis and would love to have those pulled into this application.
"(…) They can be used to make containers because they are thicker than conventional cellulose-based materials. The new material is expected to replace plastics for this purpose, as plastics are a source of ocean pollution."
If there were an MCP to connect to, say, a running Chrome tab with your frontend running on it, that would allow an agent to both visually inspect and interact with the webpage as well as look at the network and console tabs, etc. That would be hugely helpful. Is there something like that today?
1. Fracking tech allows us to drill horizontally, and enhanced geothermal systems rely on this to get that surface area exposure at 7+ km below the surface
2. The steam's extremely (225C+) hot, so there are losses but doesn't make it infeasible.
Below a certain depth, the earth gets 1º hotter per 40m of depth.
Fracking has nothing to do with horizontal drilling. Fracking is used to increase the connectivity of the reservoir to the wellbore, in the case of low permeability reservoir. For geothermal applications there is no reason to pick the low perm and increase the cost of well completion.
Horizontal directional drilling is a very established field, which is very technologically intensive and some of the things we can do in this area are nothing short of amazing. Basically any trajectory can be executed, including some smart things like underground loops. Couple this with electric submersible pumps (ESP), which help to increase the flow and potentially run water through several cycles to maximize the contact with hot payzone before getting it to surface and you can do many interesting things.
My take (as a paying subscriber to both, largely because I want to support this world and think both teams are insanely talented and great) is that they're solving similar problems, with some different features.
I wish I could use both with a sync between them until I figure out which one I'd want to stick with. Or stick with both.
It's absolutely declined, no question. Further, the advanced search tools have been all but eviscerated, so it's even more difficult to find what you want even if you know what you're looking for.
I think this is a great summary of some of the main challenges nurses are facing.
I'd add to #1 that travel (temp) nurses are making 4x+ more than staff nurses, I've heard as high as $13-17k per week in high-demand areas. This exacerbates the problem, as staff nurses hear this, and if they can, they leave. Travel nurses can be great, but they won't know the facility and workflows and people as well as staff nurses: staff nurses now pick up more slack, all while getting paid 1/10th what their new colleagues are. This is more than most doctors.
For #3, this problem is made worse by additional compliance burden. Nurses need to document more and more, click more and more, read more and more… with less and less time. And on systems that are unpleasant to use. Among other issues, this leads to problems like these[0], which drive more and more nurses away.
I'm working with a badass team on solving some parts of these problems, particularly relating to technology and workflows. If you're interested (across basically any role, but product designers, engineers, product managers are top of mind right now), let me know (email in bio)!
I think there's some irony in using Russell's quote being used this way. My intent will often be less clear to a reader once encoded in a language bound inextricably to a machine's execution context.
Good abstraction meaningfully whittles away at this mismatch, and DSLs in powerful languages (like ML-family and lisp-family languages) have often mirrored natural(ish) language. Observe that programming languages themselves have natural language specifications that are meaningfully more dense than their implementations, and often govern multiple implementations.
Code isn't just code. Some code encapsulates intent in a meaningfully information and meaning-dense way: that code is indeed poetry, and perhaps the best representation of intent available. Some code, like nearly every line of the code that backs your server vs client time example, is an implementation detail. The Electric Clojure version is a far better encapsulation of intent (https://electric.hyperfiddle.net/fiddle/electric-tutorial.tw...). A natural language version, executed in the context of a program with an existing client server architecture, is likely best: "show a live updated version of the servers' unix epoch timestamp and the client's, and below that show the skew between them."
Given that we started with Russell, we could end with Wittgenstein's "Is it even always an advantage to replace an indistinct picture by a sharp one? Isn't the indistinct one often exactly what we need?"