I agree. What OpenAI did was simple and beautiful.
Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, the only other alternative is to add more context into the prompt which is not easy unless you have a tone of experience. Most of our customers fail at prompting.
The reason I like the ai-plugin.json approach is that you don't have to change the API to make the description of a function a little bit different. One day MCP might support this but it will another layer of complexities that could have been avoided with a remotely hosted JSON / YAML file.
I love Nix as a package manager, and flakes are awesome for setting up environments. I wish it had more affordances for being a proper build system. If only there were a Buck2 and Nix hybrid.
There's a whole process. In the US, "Bulk Handling Systems" seems to be the leading company in the sorting of recyclables. There are shredders, shakers,
air separators to pull out the light stuff, DC magnets for ferrous metals, AC magnets for aluminum, multispectral vision sorters for different plastics, and even AI vision guided robot pickers. Most of the sorting is done with big, simple machines. The robotics just picks out unwanted stuff missed by the earlier steps to give clean product that can be sold. That was
a big insight in this business - you need some machine intelligence, but it's a small part of the overall system.
It's simpler and cheaper to machine sort the stuff at one location than have lots of little bins into which people mis-sort stuff. Most of the cost is out collecting the stuff, not sorting it, and single-stream recycling simplifies the collecting.
Seconding TVR Exploring! His videos are a breath of fresh air in today's clickbaity youtube landscape. He's easily the best abandoned mine exploration channel - I can hardly even watch any of the others any more.
> But it's also ridiculous to brush off all non-ionizing radiation as harmless.
I disagree. There's more than enough empirical data that shows non-ionizing radiation is safe. Consider, for example, how many people work at or live near MW emitters (like radio stations).
You don't find that populations around those emitters have higher incidents of health problems.
But further, we aren't finding an increase in tumors/cancers in places where people very commonly store their non-ionizing radiation devices (pants pockets).
Taken one step further, when you step out into the sunlight, you are being exposed to several watts worth at several frequencies of ionizing (UV) and non-ionizing radiation. Orders of magnitudes more than you'd see from any device. Yet, what we see is that people that work out in the sun most commonly experience skin cancer/damage and nothing else.
The fear over non-ionizing radiation comes from ignorance and nothing more.
To your bug example, yes, if you concentrate non-ionizing radiation up to 100W+ at a single point, it'll burn that point. But that's a strawman of the situation. No wireless tech is doing that in the slightest.
Broadcom likes to buy big companies with big moats that trade at a reasonable multiple because they have a mature growth profile. There are no more chip companies left with that profile except Qualcomm, which they tried to buy, and maybe Intel although their moat is fading. So they pivoted to software.
They even found that parents waiting to pick up kids at schools with their ICE engines running increased PM2.5 inside the entire building by orders of magnitude.
This data helped the kids teach their parents to stop their engines when waiting outside the school in order to help their asthmatic classmates.
The transition to EV is going to have a positive impact on people’s health and make city life better.
"We model data according to rigorous frameworks like Kimball or Inmon because we must regularly construct OLAP cubes for our analyses."
Actually, no. We model our data this way so it can be used for business decisions. It doesn't take long for any entity of any scale to discover that the logging and eventing done for heartbeat status, debugging, and scaling is just different than what you need to make a variety of business decisions.
You can solve with more events at different scales (button clicks nested in screen views) or pick events or event rolkups that appear to be clean business stages ("completed checkout") but still, your finance team, marketing group, all have different needs.
So, you decide to have some core shared metrics, derived and defined, and make them usable by everyone. Folks agree on the defns, and due to ease and trust, you see more data supporting more decisions.
You discover that some folks are doing 10 table joins to get an answer; it's fast but difficult to extend for new questions. You decide to build a view that solves some of these pains, and refactoring to allow a better time dimension. Your version links with the metrics you created, and the resulting queries shed tons of CTEs while becoming readable to the average user.
And now, you have some ELT pipelines, some event transforms that result in counts and filters that map nicely to your business needs but still allow you to get atomic raws, and you and your teams start to trust in consistent results. Your metrics are mostly clearly summable, and ones that aren't are in table views that precalc the "daily uniques" or other metrics that may need a bit special handling.
You've started modeling your data.
No, we don't need olap cubes. But we do need some type of rigor around analytic data. Otherwise, why go to all the trouble to collect it, count it, and predict from it if it may be wrong with no measure of that uncertainty?
And yeah, Kimball et al are from a world where olap was the answr, but it turns out they solved a broader set of sql problems. So, worth learning the good, toss the dated, and see what good data modeling can do for your analysis and predictions.
An excellent piece. I’m especially interested to hear stories from the fellow HNers about the last point Jocelyn mentions: how to build 2 shipping cultures inside one company, when your business requires it (for example: two-sided marketplaces with different apps for consumer and businesses).
In our case, we have this situation with SW vs HW shipping culture. On the SW side, we focus on continuously developing features and have deliberately emphasized productivity over schedule-predictability, while on the HW side they naturally are focused more on schedule-predictability due to complex dependencies.
Now, this dichotomy has created an interesting discussions inside the company on the right way to ship products and projects, and to me, arguments mainly come from the fact that people come from the different shipping culture and have hard time to see the benefits and requirements of the other culture.
For reference, Wikipedia lists her net worth at ~$115 million (as of 2018, likely higher now). It looks like ~$20 million of that is real estate but if she just put the rest in the S&P 500 that would give her over $5 million worth of AAPL.
Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, the only other alternative is to add more context into the prompt which is not easy unless you have a tone of experience. Most of our customers fail at prompting.
The reason I like the ai-plugin.json approach is that you don't have to change the API to make the description of a function a little bit different. One day MCP might support this but it will another layer of complexities that could have been avoided with a remotely hosted JSON / YAML file.