Others have pointed it out, but it’s the juxtaposition of the fact that she’s definitely not an expert in this subject with a lesson in the subject.
There’s some subtle bits to the humor depending on how charitable you’re feeling. It might just be absurdist, as in “Blackbeard’s guide to astrobiology”, or it may be more mean spirited and playing on a belief that she is not intelligent.
TL;DR - the joke formula is just:
subject=…
person_not_familiar_with_subject=…
joke=“${person_not_familiar_with_subject}’s guide to {subject}“
And the amount of implied cruelty in the comparison is variable.
Those of us subscribing to AI newsletters are constantly slapped in the face with “___ is all you need” style jokes, such that I didn’t even register someone might not make that connection.
I wonder if any sense this is criticism (or actual criticism) is based on implementers of SaaS who have it so deeply ingrained that “haha what if the users of this software did this really extreme thing” is more like “oh shit what if the users of this software did this really extreme thing”.
When I worked on Google cloud storage, I once shipped a feature that briefly broke single-shot uploads of more than 2gb. I didn’t consider this use case because it was so absurd - anything larger than 2mb is recommended to go through a resumable/retryable flow, not a one-shot that either sends it all correctly the first time or fails. Client libraries enforced this, but not the APIs! It was an easy fix with that knowledge, but the lesson remained to me that whatever extreme behaviors you allow in your API will be found, so you have to be very paranoid about what you allow if you don’t want to support it indefinitely (which we tried to do, it was hard).
Anyway in this case that level of paranoia would make no sense. The programmers of this age made amazing, highly coreographed programs that ran exactly as intended on the right hardware and timing.
The idea of giving every character this sort of agency and seeing what opinion builds up about the world is incredibly fascinating.
Depending on how well we assume an LLM would do at this task, it’s an interesting way to see what “real people” would think about a very hypothetical situation.
An important point that’s missed in this is that these small farms are a vital part of the US’ food security. So regardless of what an analogous business in another sector may choose to do, we really want small farms to be sustainable all over the country.
> these small farms are a vital part of the US’ food security
Hmm, that's only true if the kinds of crops those small farms are regularly growing are the kinds we'd want to have already in the ground as an unexpected "food security" crisis occurs. In other words, durable staples with long shelf-lives, as opposed to cash-crops for export, quick-spoiling luxuries, etc.
Are there any stats that might confirm/disprove that? Because if most those small farms are geared to pistachios or asparagus or hemp, then they aren't really serving as a national safety net.
What is the basis for the idea that small farms are vital for food security? Farms, sure. Small farms? We need low-productivity small farms for food security?
I'm no expert in the field, but if asked, I would prefer thousands of small farms protecting our food security rather than a handful of companies too big to fail.
When you have more diversity, I imagine you would get more resilience, more competition, and market forces work properly.
I don't get the small businesses fetishism. Large companies are efficient, resilient, more likely to follow the letter of the law, and more scalably prosecutable if they don't.
The US is currently experiencing a fairly extreme security threat across multiple industries due dependency on a single provider. Boeing and Intel jump to mind, for example.
Small farms are inefficient though. Farming needs a diverse range of skilled labor but infrequently: the industry as a whole trends towards larger land holders being serviced by specialist labor forces which work seasonally or regionally.
And then within that bucket, it's fairly obvious that larger holders are going to be much more resilient to regional problems if they have diversified land holdings where one area can support a downturn in another.
Inefficient from an economic perspective may not be what we need as a society.
Perhaps we need more farmers living the the county, spending money in small county towns, with more work for people with those special labor skills. Get people out of the city and more people into primary industries.
No straight up inefficient. They produce less. More land is occupied for non productive buildings. Heavy equipment cannot be used at scale. Farms which go bankrupt and fall into disrepair don't produce, and the fields degrade.
The only way what you wrote could make sense would be if it's referring to crops grown for animal feed, and comparing that to if the crops were directly consumed by people.
So, the claim is thinly veiled propaganda for vegetarianism.
If that's your answer then you're vastly underestimating how much farmland there is. We have 1.6 million small farms, averaging a couple hundred acres. Large farms usually have a couple thousand acres.
If every farm in the US was around 3000 acres, we would still have a quarter million farms. Even 100k acre mega farms would leave us with 8000+ farms.
"“Seed, chemicals or fertilizer, it’s all in the hands of a few companies that are the only game in town."... "“They all tell me they’re aware of a monopoly problem, and they don’t deny it exists. But they do nothing."
sorry, when I said "thousands of small farms" I meant thousands of small companies producing Seed, Chemicals and Fertilizer.. as well as actually growing plants and animals.
So if that's the actual problem, what's the motivation for preserving small farms? Those small farms are still being supplied by those large suppliers.
Not the OP, but I assume they mean that it's encoded in the type system.
For example Rust gives you a `Result<Thing, ErrorType>`, which might be a `Thing` or might be one of the possible error types given by `ErrorType`. So when you get a function's return value, you have to deal with the fact that it might have failed with this specific error.
I suppose my negative experiences with async fall under #3, that it is hard to maintain two APIs.
One of the most memorable "real software engineering" bugs of my career involved async Python. I was maintaining a FastAPI server which was consistently leaking file descriptors when making any outgoing HTTP requests due to failing to close the socket. This manifested in a few ways: once the server ran out of available file descriptors, it degraded to a bizarre world where it would accept new HTTP requests but then refuse to transmit any information, which was also exciting due to increasing the difficulty of remotely debugging this. Occasionally the server would run out of memory before running out of file descriptors on the OS, which was a fun red herring that resulted in at least one premature "I fixed the problem!" RAM bump.
The exact culprit was never found - I spent a full week debugging it, and concluded that the problem had to do with someone on the library/framework/system stack of FastAPI/aiohttp/asyncio having expectations about someone else in the stack closing the socket after picking up the async context, but that never actually occurring. It was impenetrable to me due to the constant context switching between the libraries and frameworks, such that I could not keep the thread of who (above my application layer) should have been closing it.
My solution was to monkey patch the native python socket class and add a FastAPI middleware layer so that anytime an outgoing socket opened, I'd add it to a map of sockets by incoming request ID. Then when the incoming request concluded I'd lookup sockets in the map and close them manually.
It worked, the servers were stable, and the only follow-up request was to please delete the annoying "Socket with file descriptor <x> manually closed" message from the logs, because they were cluttering things up. And thus, another brick in the wall of my opinion that I do not prefer Python for reliable, high-performance HTTP servers.
This point doesn't get enough coverage. When I saw async coming into Python and C# (the two ecosystems I was watching most closely at the time) I found it depressing just how much work was going into it that could have been productively expended elsewhere if they'd have gone with blocking calls to green threads instead.
To add insult to injury, when implementing async it seems inevitable that what's created is a bizarro-world API that mostly-mirrors-but-often-not-quite the synchronous API. The differences usually don't matter, until they do.
So not only does the project pay the cost of maintaining two APIs, the users keep paying the cost of dealing with subtle differences between them that'll probably never go away.
> I do not prefer Python for reliable, high-performance HTTP servers
I don't use it much anymore, but Twisted Matrix was (is?) great at this. Felt like a superpower to, in the oughties, easily saturate a network interface with useful work in Python.
> I don't use it much anymore, but Twisted Matrix was (is?) great at this.
You must be an experienced developer to write maintenable code with Twisted, otherwise, when the codebase increase a little, it will quickly become a bunch of spaghetti code.
Glad I'm not only one in the boat. We have Python HTTP Server doing similar. No one can figure it out, Containerd occasionally OOM kills it, everyone just shrugs and move on.
I fine-tuned an LLM to do Verification IP wiring at a LLM hardware startup. We built the dataset in house. It was quite effective actually, with enough investment in expanding the dataset this is a totally viable application.
I'm curious: did you have to tailor your dataset around instruction-following/reasoning capabilities as well? No conflict of interest myself – I'm interested in hobby programming for vintage computers – but my understanding comes from Unsloth's fine-tuning instructions. [1]
No problem - although I'm out of that particular role, it's appropriate to discuss since the company shared these details already in an openAI press release a few months back.
I fine-tuned reasoning models (o1-mini and o3-mini) which were already well into instruction-following and reasoning behavior. The dataset I prepared was taking this into account, but it was just simple prompt/response pairs. Defining the task tightly, ensuring the dataset was of high quality, picking the right hyper parameters, and preparing the proper reward function (and modeling that against the API provided) were the keys to success.
I’d have liked to see the use of dependency injection via the effects system expanded upon. The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.
Also, I had no idea that the module system had its own type system, that’s wild.
> The idea that the example program could use pattern matching to bind to either test values or production ones is interesting, but I can’t conceptualize what that would look like with the verbal description alone.
The article appears to have described the free monad + interpreter pattern, that is, each business-logic statement doesn't execute the action (as a verb), but instead constructs it as a noun and slots it into some kind of AST. Once you have an AST you can execute it with either a ProdAstVisitor or a TestAstVisitor which will carry out the commands for real.
More specific to your question, it sounds like the pattern matching you mentioned is choosing between Test.ReadFile and Test.WriteFile at each node of the AST (not between Test.ReadFile and Prod.ReadFile.)
I think the Haskell community turned away a little from free monad + interpreter when it was pointed out that the 'tagless final' approach does the same thing with less ceremory, by just using typeclasses.
> I’d have liked to see the use of dependency injection via the effects system expanded upon.
I'm currently doing DI via effects, and I found a technique I'm super happy with:
At the lowest level, I have a bunch of classes & functions which I call capabilities, e.g
These are tightly-focused on doing one thing, and must not know anything about the business. No code here would need to change if I changed jobs.
At the next level up I have classes & functions which can know about the business (and the lower level capabilities)
StoredCommands (fetchStoredCommands) - this uses the 'Restful' capability above to construct and send a payload to our business servers.
At the top of my stack I have a type called CliApp, which represents all the business logic things I can do, e.g.
I associate CliApp to all its actual implementations (low-level and mid-level) using type classes:
instance FileOps CliApp where
readTextFile = readTextFileImpl
writeTextFile = writeTextFileImpl
...
instance Logger CliApp where
info = infoImpl
warn = warnImpl
err = errImpl
...
instance StoredCommands CliApp where
fetchStoredCommands = fetchStoredCommandsImpl
...
In this way, CliApp doesn't have any of 'its own' implementations, it's just a set of bindings to the actual implementations.
I can create a CliTestApp which has a different set of bindings, e.g.
instance Logger CliTestApp where
info msg = -- maybe store message using in-memory list so I can assert on it?
Now here's where it gets interesting. Each function (all the way from top to bottom) has its effects explicitly in the type system. If you're unfamiliar with Haskell, a function either having IO or not (in its type sig) is a big deal. Non-IO essentially rules out non-determinism.
The low-level prod code (capabilites) are allowed to do IO, as signaled by the MonadIO in the type sig:
readTextFileImpl :: MonadIO m => FilePath -> m (Either String Text)
but the equivalent test double is not allowed to do IO, per:
readTextFileTest :: Monad m => FilePath -> m (Either String Text)
And where it gets crazy for me is: the high-level business logic (e.g. fetchStoredCommands) will be allowed to do IO if run via CliApp, but will not be allowed to do IO if run via CliTestApp, which for me is 'having my cake and eating it too'.
Another way of looking at it is, if I invent a new capability (e.g. Caching) and start calling it from my business logic, the CliTestApp pointing at that same business logic will compile-time error that it doesn't have its own Caching implementation. If I try to 'cheat' by wiring the CliTestApp to the prod Caching (which would make my test cases non-deterministic) I'll get another compile-time error.
Would it work in OCaml? Not sure, the article says:
> Currently, it should be noted that effect propagation is not tracked by the type system
I am not a Haskell expert, nor an expert in effect systems, but, AFAIU, what
mrkeen has provided is an analogous pattern in Haskell -- where effects are represented via the free monad with an interpreter -- and not an account of what is described in the article.
In OCaml we can (and do) also manage effects via monadic style. However, we don't have ad hoc polymorphism (e.g., no typeclasses), so that aspect of the dependency injection must go thru the more verbose (but more explicit, and IMO, easier to reason about) route of parametric modules.
The point in the article is that effect handlers allow direct-style code with custom effects, which enable a kind of "dependency injection" which actually looks and feels much more like just specifying different contexts within which to run the same program. If you are very used to doing everything in Haskell's monadic style, you may not really notice the difference, until you try to compose the handlers.
No idea how common it is. It's never been my main work language but I've been using it at work for prototyping/scripting/automation/analysis etc for at least ten years now.
There’s some subtle bits to the humor depending on how charitable you’re feeling. It might just be absurdist, as in “Blackbeard’s guide to astrobiology”, or it may be more mean spirited and playing on a belief that she is not intelligent.
TL;DR - the joke formula is just:
subject=…
person_not_familiar_with_subject=…
joke=“${person_not_familiar_with_subject}’s guide to {subject}“
And the amount of implied cruelty in the comparison is variable.
reply