Meanwhile every time I put a new kind of bread / bagel / muffin in my toaster, it comes out unsatisfyingly burnt or underdone as is the particular setting of the day. See, the objects I insert into the toaster almost _never_ resemble the model bread that the EE designed for.
If the toaster had a shade selector, a built in camera and was factory color calibrated, then no matter what I stuck in the toaster it would come out that color (or hit some global MAX_TOASTING_TIME) .
Good software engineers design robustly without increasing the problem domain (much).
In this case, it was unlearned for a very good reason. The hexavalent chromium plating on those toasters is a genotoxic carcinogen. The metal body gets dangerously hot during toasting. The internal metal wires are not safe and will electrocute children who poke metal inside. The mechanical temperature control and automatic toast ejection were complicated and extremely expensive, making it unaffordable for most.
* Twee nostalgia for technology of yester-year annoys me; I feel the same way about people who preach about the technical superiority of safety razors and vinyl records.
Personally, I'm happy to trade the mild cancer risk for aesthetics. I just don't make a habit of taking a grinder to my toaster and sprinkling the shavings on my toast.
As for the body, I can report that as of this morning it's within the thermal range of a full-load MBP.
I see the shock hazard as a learning opportunity. Maybe I'm old fashioned, but "Don't stick fingers / metal objects into the internals of electrical devices" seems like solid life wisdom.
Thankfully, I was shielded from the price, but quality costs money. In return, you get a lifetime (or more) of service. You may optimize differently.
And as a final note, there is no toast "ejection." To do so with such violence would be crass and disruptive to my morning calm.
My toast instead gently and incrementally rises to a comfortable removal height, while a chorus of angels sings in the background. Truly an elegant toast maker, from a more civilized age. /Twee
PS: I'm also happy to wax on the benefits of my daily driver 1940s Gillette Super Speed safety razor.
Even if none of these things matter to you, how about the fact that the mechanical control would not be easily adapted to handle variable width bread without much more expense?
Who wants a toaster that can't handle thick cut bread or bagels in the 21st century?
And it's not just California. You couldn't get UL approval for such a toaster today, so it would not be sold anywhere.
These old toasters cost the equivalent of $235 in today's dollars. (~$23 in 1949) Of course if you buy a $200 toaster today, it would be a marvel of technology. Nobody buys $200 toasters though, you can get a crappy one for $15 and that's what people buy, so any comparisons between today and yesterday are unfair. Compare like price with like price.
Google "toaster dualit". You will find chrome, dangerously hot toasters for hundreds of dollars. It's up to you to figure out how to electrocute yourself, but I don't see why a little ingenuity wouldn't suffice.
I don't think they have the features of the Sunbeam though. If there is a model that does, I'd like to know about it since it sounds brilliant.
> "If the toaster had a shade selector, a built in camera and was factory color calibrated, then no matter what I stuck in the toaster it would come out that color (or hit some global MAX_TOASTING_TIME) ."
...which would fail on dark breads like pumpernickel or be confused by marbled or cinnamon swirl breads.
I think this points out the challenges of "Just make me a simple X" that business and product folks always initiate with, hoping to get the cheapest solution.
Then they wonder why it fails in every way except the ones they explicitly said during design/coding and why there is a long tail of updates that often exceed the MVP...
How do you determine whether the object being toasted has reached equilibrium from radiated heat measurements which are from the surface of the object?
What is needed is a detector for the flavor agents given off by the Maillard reaction.
If I don't know the proper time in the microwave to heat a dish, I just let it run until it starts to smell right. The same strategy should work for toast.
Since we are comparing in this thread, why are computer science grads often afraid of math based solutions?
For example, I had a physics problem and a computer science buddy was opposed to solving it ourselves. He insisted we needed an expert. When at worst it needed differential equations that ended up cancelling out. It wasn't a hard problem, it just took some effort.
Is this a rare experience? Or have other people found a reluctance of math in comp sci?
So, I did computer science almost two decades ago and our school as part of an engineering degree. Our school taught differential equations as an optional course. However, for all other engineers it was a required course.
Today, computer science at my old school is part of liberal arts and differential equations isn’t listed anywhere on the curriculum.
Because many aren’t taught differential equations it’s hard to know what they can do, or how to use them so it’s easier to just get an expert.
When you want engineering done, hire an engineer. If you need science, hire a scientist.
I have not been able to discover which of those a Computer Science graduate is. By observation, a piler-on of frameworks, most usually. But some scientists and some engineers get CS certification, so you can't be sure, by the label.
I can't really blame him/her. CS focuses mostly on discrete mathematics. While there are some required calculus courses in a CS program, IIRC they don't go up to diffeqs and most CS courses never really make much, if any, use of the calculus that is taught.
I can say, as a CS graduate, that I liked discrete math and hated anything in-discrete. I avoided statistics (as opposed to discrete probability) entirely.
Once upon a time, there used to be companies who made money by selling toasters. When toasting bread went out of fashion, these companies found their businesses to be in peril. They wanted their businesses to respond to the change in the market and pivot. The ones whose toasters were software-driven were able to survive, while the ones who hardwired them to do just toasting breads, did not.
That's an interesting take, but what actually happened is three different things:
1. microwave ovens became affordable, popular, and then discovered to be terrible for browning things, but so good at generally warming food that they became a smash hit.
2. toaster ovens were introduced, with two hardware controls instead of one (heat and time), which did an acceptable job of toasting but also handled lots of other small warming and browning tasks.
3. toasters came back as a nostalgic luxury good.
In all of these markets, the companies with more robust hardware capabilities were able to charge a premium, attract customer loyalty to their brands, and use the brand reputation to diversify to related kitchen goods.
The ones who survived designed and built a new simple product that matched the market demand rather than attempting to retrofit their complicated product designed for a different purpose.
Au contraire, I think it's a parable about software departments being overstaffed and producing churn to fill the hours. See: Uber Engineering, Google rewriting everything all the time, Javascript frameworks of the month^H^H^H^H^H week, etc.
Exactly. Use an engineer for an engineering problem.
Mark Twain wrote, "An engineer is a [person] who can do for a dime what any damn fool can do for a dollar." Adjusting for inflation, the engineer can do for a million dollars what any damn fool can do for a billion.
The language and word-choice actually reminded me of Stanislaw Lem's The Cyberiad, in which Trurl doesn't challenge Klapaucius to building a better toaster, but should have.
If the toaster had a shade selector, a built in camera and was factory color calibrated, then no matter what I stuck in the toaster it would come out that color (or hit some global MAX_TOASTING_TIME) .
Good software engineers design robustly without increasing the problem domain (much).