It looks like magic because it works like magic. Surprisingly it is also possible to believe in the magic of "government intervention" though it looks less like magic and more like unintended consequences.
Doing nothing and letting the market do whatever is also full of unintended consequences. Your argument is like letting your yard go to weed and accumulate a bunch of knotweed and himalayan blackberry. Yeah you can argue that you didn’t do anything to create that situation but at the end of the day you’re still responsible for it.
The thing is that not doing anything is still a policy decision. Unless you want to go full bore libertarian there will always be regulation. By saying that the market is magic and the government is intervention, then you ignore all of the intervention exists already and just saying you are fine with it.
> The farm equipment industry spent 20 years adding complexity and cost. Ursa Ag is wagering that a significant number of farmers never wanted any of it.
Nice tag line but not a complete picture. The "significant number of farmers" in terms of actual market spend driving the equipment industry is not mom-and-pop outfits but rather agri-industrial complexes with machines to match. What they want is (1) availability and (2) ROI. For (1), that is first and foremost subject to legal stipulations like EPA etc, then secondly subject to production availability. For (2), electronics are the name of the game if you are looking to turn a profit with farming because counting every seed, measuring every drop of chem, and tracking every inch of plotted ground leads to better ROI.
Farming is a way of life for a lot of people, not just a business. That’s what is missing from your picture. And by population, small time farmers significantly outnumber industrial outfits, regardless of how much they spend. Sure you can make more money selling the most advanced tech to the biggest spenders. That doesn’t mean there isn’t a market for affordable, reliable equipment that gets the job done. Add on the risky nature of farming and its untenable to trap yourself in high 6 figures of debt and pray that you can optimize your way to enough profit to pay the interest.
Not so. In fact, farming is a way of life for almost nobody in developed countries.[1]
Ursa shows us that there is indeed a market for "simple and reliable" equipment -- but it's not cheap or affordable. There is zero market for "affordable" equipment, because almost nobody does small scale farming anymore
Small farms became economically and socially irrelevant almost a century ago in developed countries. Petroleum based fertilizer and industrial machinery drove the marginal cost of food to zero, and it is now only profitable to farm at very large industrial scale.
The main social outcome there was that starvation and malnutrition became vanishingly rare in these countries.
(In fact, _obesity_ is now, for the first time in human history, a widespread problem for the poorest in these societies.)
Society chose "nobody starving" as a better outcome than preserving romantic small farms for the sake of tradition.
Ah yes, millions of people = “almost nobody”. Do you also believe trans people are irrelevant because they make up less than 1% of the population? Let’s also ignore that plenty of people live on homesteads and do small scale agriculture for their own needs (eg feed for animals) while working other jobs. If all you have is statistics and you’ve never lived in the country, maybe you shouldn’t pretend to be an authority. But please go on and continue telling other people their lived experiences aren’t real. It’s sure to make you plenty of friends. This is exactly why a lot of normies hate tech people, extreme arrogance and a complete inability to see outside your bubble.
Fancy gains in ROI come from smart seeder/sprayer attachments and combine harvesters (a completely different piece of machinery), not from the tractor that's pulling those equipment. At best there's the ROI from less seed overlap, but plenty of GPS systems integrate well into any tractor and the gains are really marginal. I don't think tractor electronics are as important as they're hyped up to be.
So the first thing that's important to understand is that Excel is the product of another era. One where resources like memory were very constrained and compilers and optimizers weren't as good as they are today (so much so that the Excel team at one point wrote their own because MSVC sucked, but I digress)...
And so, a lot of the core code is used to that. Cell formatting data for example is super tightly packed in deeply nested unions to ensure that as little memory is used to store that info. If something only needs 3 bits, it'll only use 3 bits. The calc engine compiles all of your formulas to its own (IIRC variable-instruction-width) bytecode to make sure that huge spreadsheets can still fit in memory and calc fast.
And a lot of it still carries the same coding and naming practices that it started with in the 80s: Hungarian notation, terse variable and file names, etc. Now, IMO, Hungarian notation by itself is pretty harmless (and even maybe useful in absence of an IDE), but it seemed to encourage programmers to eschew any form of useful information from variable names, requiring you to have more context to understand "why" something is happening. Like, cool, I have a pszxoper now (pointer to zero terminated string of XOper), but why?
So the code is tight, has a lot of optimization baked in and assumes you know a lot about what's happening already.
But more importantly, a lot of "why" information also just lives in people's head. Yes, some teams would have documentation in an ungodly web of OneNote notebooks, or spread across SharePoint pages, which had the least useful search functionality I've ever witnessed, but finding anything you wanted was hard. But that didn't use to matter, since the core team had been there for a long time, so you could ask them question.
That being said, I joined MSFT in 2012 and started working on Excel closer to 2014. At that point, heavyweight like DuaneC (who wrote like 10% of Excel and I don't think I'm exaggerating) had already retired and while others people were very knowledgeable in some areas, nobody seemed to have a good cross view of the whole thing.
You have to understand that I was in the Office Extensibility team. We were building APIs for the whole thing. I had to touch the calc system, the cells and range, the formatting, tables, charts and images (the whole shared oart system was interesting), etc. Answering "How do I do X" was always a quest because you would usually:
- Find 3 different ways of achieving it
- One of them was definitely the wrong way and could make the app crash in some situations (or leak memory)
- All the people on the "blame" had left
- One of them was via the VBA layer which did some weird stuff (good ol' pbobj)
- Be grateful that this wasn't Word because their codebase was much worse
And so, a lot of the API implementation was trial and error and hunting down someone who understood the data structures. The fact that full sync and rebuild took about 6 hours (you ran a command called `ohome` and then you went home) meant that experimenting was sometimes slow (at least incremental builds were OK fast). The only lifeline back then was this tool called ReSearch2 that allowed you to search the codebase efficiently.
But the thing is, once you got thing to work, they worked really well. The core was solid and performant. Just slightly inscrutable at time and not the kind of code you're use to reading outside of Excel.
> Interest per Second - General - The U.S. pays $31,688/second in debt interest — $1,901,285 every minute. Your share of that: $3893.33 [plugged in "normal" amount], gone before it bought anything.
...I thought I was already sufficiently terrified by the debt numbers...
By the way, the 1040 instructions have a pie chart like this (ref https://www.irs.gov/pub/irs-pdf/i1040gi.pdf, page 122). Not that most people do taxes themselves, or have a reason to read to page 122 of instructions for a single form. But still it's there and perhaps a nice gesture by the IRS.
Breaking it out into pie charts etc like this can be really helpful. In my view the real kicker with taxes is the opaqueness. Kinda like a meal card versus paying for every meal, or like using a credit card versus paying with cash, it's hard for humans to really grasp what's going on unless they're involved.
Of course it would be impractical to pay taxes separately to every waiting hand in government bureaucracy. But on the other hand maybe the number one goal shouldn't be ease of use, either. Maybe a little friction when paying for public services could be a good thing for citizens who are interested in a healthy country - my opinion.
Because U.S. corporations were taxed on a total of gross receipts of roughly $40T, while personal income was taxed on a much tighter pool of roughly $23.9T.
Yeah Block level dedupe has been an industry standard for decades. Tracking file hashes? Why?
And I see above that this is a self-hosted platform and I still don’t get it. I was running terabytes of ZFS with dedupe=on on cheap supermicro gear in 2012
File hashes are great to get two systems to work together to dedupe themselves. I have a Windows backup that sends hashes to a backup server, so we don't back up crud we already have.
> You could always write code to help doing those things direct from disk, but you know what you have just written if you do so? A database!
Yes, but that's my point. Why is this not a part of the standard library / typical package with very little friction with the rest of the code, instead of a separate program that the standard library / typical packages provide in an attempt to reduce the friction?
Or are you making the general point that databases already existed prior to the standard libraries etc, and this is just a case of interfacing with an existing technology instead of rebuilding from scratch?
Because a reasonably well optimized database with support for indexes, data integrity enforcement, transactions, and all the other important things we expect from a good (relational) database is complex enough that it takes a rather large codebase to do it reasonably well. It’s not something you slap together out of a handful of function calls.
ETA: look at SQLite for an example — it’s a relatively recent and simple entrant in the field and the closest you’ll find in the mainstream to a purely filesystem based RDBMS. How would you provide a stdlib that would let you implement something like that reasonably simply? What would be the use case for it?
It looks like magic because it works like magic. Surprisingly it is also possible to believe in the magic of "government intervention" though it looks less like magic and more like unintended consequences.
reply