Yes, but there's also a limit. For the dishwashing, consider that you can already exchange money for a maximally efficient, maximally flexible solution: you can hire someone to do your dishes. How much would you pay for a live in, automata like servant who washes all your dishes for you? What about if they could do many other things? $1k? $5k? $100k? What about the maintenance? What're the ongoing costs like?
Sure, if a dishwasher is $1k and the robot has a high success (not many broken dishes) rate AND can do other things AND is priced like a nice used car (up to $35k) then yeah, maybe? But there's so much of "it depends" in there that it's hard to say for sure. In curious what price/generality/reliability you have in mind when you say "many people would prefer..."
On reflection, inefficient and high level vs efficient low level is far from the only dimension to evaluate these tools on :P
Clearly humans are of the first sort, just like this robot.
To the current example you gave - I would argue that humans require a huge amount of configuration/maintenance - far more than any machine. Of course they are definitely effective at tasks once they get going.
As to what price/generality/reliability level I think people would really prefer - I guess we'll have to wait and see when these come on the market, if they ever do. It's nearly midnight where I am and my morning confidence in humanoid robots has waned a little
Eh, autocrats get away with looking like they move fast due to their lack of transparency; slow things can be dismissed or not propagandized, fast things will be shouted from the rooftops.
Autocrats also had thousands of years and generations to give their citizens freedom of expression, the freedom to innovate, to eat, have access to clean drinking water, to solve child mortality, to extend life expectancy for those who lived through childhood to be past 60, to put a man on the moon. Yet the progress of civilization was far slower before democracy.
Similar to what you suggest, many say history is written by the victors. But instead history is written by those who can write and survive. There's not much written from the perspective of a commoner for most of history. But where those writings survive, the situations do not appear pleasant.
The UK during the first half of the industrial revolution was about as democratic as some of the ancient Greek city states, and even that was an improvement over the reaches of the British Empire.
What solved all those things you list was industrialisation and (arguably) capitalism*, but capitalism itself is tens of thousands of village-sized autocratcies** where each has the freedom to try things and fail (though even that varies with time, hence debtors' prison), and back then people were still working out what "workers rights" and "health and safety" meant, hence the radium girls, or children being crushed by the power looms they were paid to clean while they were still running.
To illustrate your list with e.g. food, what solved food was the Haber-Bosch process, which is responsible for about half the nitrogen in our bodies today; the British Empire thought famines were nature's way of finding balance.
* the argument against capitalism here is the Soviet Union; the counter-argument is that the Soviets could literally just look at and copy what already existed by that point; the counter-counter-argument is that they also invented some stuff of their own; the counter-counter-counter-argument is that vanishingly few of those examples were actually state-of-the-art, and the only ones I can even think of is the first half of the Space Race.
With age Ive found myself much more comfortable with folks "being mean, but in a friendly way" as they intend it. When I was younger though, I never understood why folks didn't instead just "say the nice part." Like, if your friends are always glad you join them even if you're always late, making fun of you for being late with a big smile can still feel pretty bad for you. Much better to say "hey please don't be late" and also "we really enjoy you spending time with us."
With age Ive come to see that for reasons I don't understand, lots of folks have a massive aversion to saying clearly the things they appreciate about the people around them directly. Eh, their loss.
I think there's a bit more to it than that. Being mean in a friendly way is sort of a sport, for some people finding a good quip is about the mental challenge of wordsmithing. It's easy, and not all that creative, to say "don't be late" and also with certain people can come across more negatively than just jokingly berating them, believe it or not. It sounds more serious. Something like, "glad you made it, Leland! We were just posting a GoFundMe to buy you a watch." Said in the right way with people you are very familiar with keeps a lighter tone, and less like I'm actually upset (even if I may be.) Not that I'd ever say something like that in a professional setting or to people I'm not actually strong friends with; those people just get a "glad you made it, Leland!"
It's also sort of the same reason shows like It's Always Sunny in Philadelphia are funny. When you're jokingly mean to a friend, you're being a bit of a caricature, an exaggeration. That's part of the fun of it, too. And why it can get a point across while keeping it light.
They're not claiming that it's like the dot com boom because no one is actually making money. They're claiming that this is more like the dot com boom than the housing bubble, which I think is true. The dot com crash didn't cause Jane-on-the-street to lose her house while she worked a factory job, though the housing crisis did have those kinds of consumer-affecting outcomes.
It's nothing like the dot com bubble because that was based on speculative future value and zero present value. There is more present value in AI than at any point in software in the last 30 years.
Note to the developer: you may want to consider simplifying the CSS you're using to display the "clever" dot in the background of your page. On my computer, opening viewing your site in Firefox, scrolling the page has a nearly 2000ms delay caused by whatever is going on. This is improved but not fixed by disabling the `.bg-dot::before` background CSS property.
What you have mentioned is hypothetically true, but not usually relevant. Folks bring up "there is a labor shortage" for vast swaths of lower skill jobs, famously so: e.g. waitstaff, dishwashers, drywallers. These are jobs that huuuuuge portions of your population can do, if you give them the minimal training the job requires. So it is with many of the entry-level factory jobs discussed in the parent article. Folks in hiring positions for entry level factory jobs, or waitstaff, or dishwashers, those folks say things like "there's a labor shortage" when what they typically should be saying is "wages for the positions I am hiring for need to increase to match market rates."
The key thing is "an index is a flattened tree", and for all us devs who haven't thought about trees in many years or younger folks who might not yet know, that means it's conceptually a bunch of nested maps/objects/dictionaries where the keys at each "level" are the columns in that same "level" of the index. To use a little bit of python, here's a list of the raw maps in your ascii art DB:
Notice that since this index is built from nested maps, if we want to use this index to find things, we HAVE to first do it by checking the keys in the "outermost" map, the 'date' column. It's a compound index but its order matters. This 'order matters' property is true in our map-based index and it's also true in our SQLite based index. It's also true that because this 'date < 17' is a range criteria, it has to check individual keys in the outermost map, which constitutes a SCAN of the index (smaller than a scan of the DB, but a scan nonetheless). To then find everything matching 'color = blue', it has to individually check all the color values in the result of the prior date SCAN in order to get down to only those with a 'color = blue'. As you can see, this index of date -> color isn't super helpful for the query 'WHERE color = blue AND date < 17' query. A query this index would be good for is a query like 'WHERE color = red AND date = 14'. That would not require any scans; if we were writing application code such a query with this index would be like calling `index[14][red]` which as we all know is super fast.
A better index for this, which is a different index, comes from swapping the order of the columns when forming the index. Instead of (date, color), this better index would be (color, date). That index looks like this:
Now with this new index to fulfill the exact same query of 'WHERE color = blue AND date < 17', we can do a `index[blue]` and then do a single SCAN of that intermediary to find only those `date < 17`. This still means our query does a SCAN, but it's scanning a smaller set of values (only 4 instead of at least 8 with the previous index) and we only do one scan instead of two scans.
Indexes in general are not flattened trees; they are just trees. Using a Python map as a mental model is fraught with peril since those are implemented as hash tables, which don't have ordering (which most database indexes need to support). So it's the wrong model.
For multidimensional indexes, you don't need to do anything fancy about nesting; you just need to have keys that have more than one component. To a first order, string concatenation is a good enough model. So in your case, here's what the index looks like:
Yes, this is true. I chose a nested-maps example because while it is inaccurate for actual DB applications, it's very helpful for explaining the limits of index ordering and the limits that range queries have when interacting with indexes. It's helpful to use maps as a first explanation because they're one of the most used datastructures that nearly all languages have built in (yes, I know, C, I'm talking about the other 9 of top 10 languages), and many work-a-day developers and dabblers will use nearly _only_ lists and maps (and objects/classes/structs) in their language of choice. I could've used Python's OrderedDict but I figured if I was going to stray away from "the most straightforward possible case using the datastructures everyone is already using daily", I'd have been better off jumping straight to a custom tree, like you've done.
While that's technically true for highly specialized applications such as an F1 car such as the one you listed, the parent article is discussing USB compatible consumer battery banks. Consumer battery banks are worth building with cutting edge-but-still-mass-produced cells, multiple layers of redundancies, and integrated BMS.
Those can be business decisions too though. It depends on whether or not the real / lucrative customers will notice, or maybe the noisy customers who will be all over twitter because a dev figured they'd make a big change like this on their own.
Throttling and tiering can definitely affect more people than you might suspect (like spiky services) and considering data and use are important.
Sure, if a dishwasher is $1k and the robot has a high success (not many broken dishes) rate AND can do other things AND is priced like a nice used car (up to $35k) then yeah, maybe? But there's so much of "it depends" in there that it's hard to say for sure. In curious what price/generality/reliability you have in mind when you say "many people would prefer..."
reply