I worked in scheduling and timekeeping industry for a little bit, when pen and paper is mentioned you think "oh it's just notes written, and some other things" but in reality it's literally whole departments storing everything in daily/weekly sheets/binders and it's like 20 people's job to keep it all in order and keep the ship running for next week.
When someone asks what the plan is for next week, the answer is normally, it needs to be written out, or I'll have to find this for you etc.
Yeah, my first job at a startup was at an oil and gas saas that ingested unstructured data into a standardized db for smaller operators.*
"How much money did we make yesterday?" was a nontrivial question that required a several people a couple of days to compile manually before our software.
---
* Would probably make a killing today; this was over a decade ago and the extraction was 98% regex and custom if statements
That's a pretty interesting idea! I guess 160+ is sort of doing some of that for us - it compiles to SQL WHERE clauses, right - but generally, we found good results giving it a SQL dialect directly.
I think some of the reason is that there's so much coverage of writing SQL in its training set.
Yes! This works really well from Sonnet 4.5 onwards, in our experience. Sonnet 4.0 was a little rocky - we had to give it tons of documentation - but by now it works without much effort.
One thing that works very well is just giving it one or two example valid programs/statements in the custom language. It usually picks up what you're getting at very quickly.
When it slips up, you get good signal you can capture for improving the language. If you're doing things in a standard agent-y loop, a good error message also helps it course-correct.
That’s really interesting. The “one or two examples + good error messages” part feels especially important. It suggests the limiting factor may be less finetuning and more whether the model is given a tight representation and a feedback loop it can recover from.
The AEPs were originally based off Google AIPs, but we did a hard fork and have altered a lot since then. For one thing, the AIPs were entirely protobuf focused, while we're focusing equally on protobuf + OpenAPI.
The CRUD methods are great examples where we deviate from the AIPs.
"Cheap" how? I have a friend who works on Seattle's bus planning. Removing a stop is a _lot_ of political work. When an elderly person depends on that bus stop being within a block so they can get to their doctor, and you're proposing to move it six blocks further away, that's essentially a _political_ cost.
It might better in the system throughput, and those benefits may even outweigh the misery put on that one person. But in the US, we largely sort that out by using cool-down times, hearings, and "community input."
Net result, according to my friend at least, is that bus stops feel _very_ sticky and hard to change.
I feel like I see an independent low-noise phone project like, every 3 months. Clearly there is some latent demand here. I wonder why the big players (Google, Apple, Samsung, HTC) haven't made a big-corp product for this market.
I am always reluctant to jump on with these independent ambitious projects. The first version is understandably rough, and the company seems to fold before they get to a second or third version.
But maybe advances in manufacturing in China are making high-quality, small-batch products like this more tractable?
Same reason Acura stopped making small cars like the Integra/RSX: costs scale more slowly than revenue as car size increases, so selling to the small car market segment results in unearned potential profits — even if the small car segment is a majority, it’s better to make a higher profit per unit on fewer unit sales if your most primary goal is to min/max labor/profit.
(Small phones, unlike small cars, also have costs in UI development to maintain their form factor’s OS support, which can create an additional pressure to withhold devices for a viable and profitable market.)
Big corps were the ones to move away from Blackbery en masse towards a BYOD system. Before that, Samsung and Nokia both had a series of keyboard phones running Windows Mobile 6 or SymbianOS. I had the Samsung Blackjack II in 2008.
No, there demand is negligible. It's just typical hacker news people who want to suddenly become productive Silicon Valley trope hustle style, or people who want to change their damaging habits in a day, so instead of uninstalling TikTok which takes 15 seconds to do, they will spend money a separate device.
reply