Joel on Software: Anecdotes - <AUTHOR> http://www.joelonsoftware.com/items/2008/11/18.html

<comment><USER2> The book review is impressively hypocritical. She ruthlessly disdains Malcolm Gladwell's use of selectively chosen biographical examples and anecdotal evidence, and then proceeds to selectively cherry-pick examples, to optimally infuriate politically correct sensibilities. She then lampoons him for incompleteness.

She mentions only one of the many larger studies that he cites, the Terman study. Was the Terman study wide ranging? Yes. Does it fit Gladwell's hypothesis that the opportunities one is offered matter? Yes. Does she show it to be incorrect? No. Does she attack any part of it? No. Does she mention any of the other studies that Gladwell mentions? That major hockey players are nearly all born in the first three months of the year? Ericsson's studies on expertise? Flynn's analysis on historic chinatowns? No!

If I present a theory, and back it up with a bunch of other data points, one should not be able to pick out a single data point, claim that I am basing my loose hypothesis on anecdotal evidence, and say I am irresponsible. This is what is being done.

<comment><USER3> _"The book review is impressively hypocritical. She ruthlessly disdains Malcolm Gladwell's use of selectively chosen biographical examples and anecdotal evidence, and then proceeds to selectively cherry-pick examples, to optimally infuriate politically correct sensibilities. She then lampoons him for incompleteness."_

You've pretty much described 95% of the fun of reading the New York Times' book review. It's a public forum for less-famous writers to snipe at more- famous ones -- it's practically the first blog.

<comment><USER4> Indeed. And Michiko Kakutani happens to be somewhat famous for her negative pieces on famous writers.

</comment></comment></comment><comment><USER5> A lot of essays are extrapolated anecdotes. It's not an intrinsically evil form. You just have to do it right.

<comment><USER6> If you have real data, and used the anecdote to illustrate it, you're doing it right.

If you give us the anecdote, but don't extrapolate to wild grand theories, you're doing it right... simultaneously telling an interesting story and giving people more data points to build up their own understanding of how the world works.

If you give us an anecdote, then tag on some theory so that the anecdote isn't mere storytelling, trying to make the anecdote more than it really is, it's deception (at best), or, at the very least, talking about something you know nothing about.

And all these anecdotes and know-nothing books, blog posts, and articles are crowding out real, genuine stories and useful knowledge.

<comment><USER2> There are many theories that Gladwell's book ties together, and there's some pretty serious data on each of them. I know three, and all of this book I've read are excerpts. Each of his books includes a reading list and citations, and I don't think this will be any different. In particular, page 10 of Flynn's book is worth reading. It is not merely Gladwell's hypothesis.

Terman et. al's studies of gifted children ([http://books.google.com/books?id=MXwVAAAAIAAJ&printsec=f...](http://books.google.com/books?id=MXwVAAAAIAAJ&printsec=frontcover&dq=terman&lr=&ei=-6IjSaSSD4L8lQSjubSUCA))

Sherar et. al's study of physical maturity in hockey player development ([http://www.informaworld.com/smpp/content~content=a778078133~...](http://www.informaworld.com/smpp/content~content=a778078133~db=all))

Flynn's book "On Intelligence" and review of the growing IQ of the worldwide population and ethnographic studies of Chinese. ([http://books.google.com/books?hl=en&lr=&id=qvBipuypY...](http://books.google.com/books?hl=en&lr=&id=qvBipuypYUkC&oi=fnd&pg=PR8&dq=flynn+chinese+intelligence&ots=dI5FSqQ_c4&sig=SzsQ7umFTljNiYyaAkxhx7z04UI))

I don't think one should claim an insufficient justification of his hypotheses without actually _examining_ the justification thoroughly.

Oftentimes, for Gladwell in particular, people claim that he's being unrigorous, imprecise, or incomplete. He's not being incomplete. He's being concise. If he weren't concise, almost nobody would pay any attention. Almost nobody would learn anything from him. And almost nobody would, wanting to learn more, have the opportunity to follow the reference list that he carefully puts out. Which I guess few people do, anyway.

<comment><USER7> I believe in one of his interviews (the New Yorker?) Gladwell kind of sheepishly admitted that people think he's a genius while really he's just packaging up other people's work with a more engaging presentation.

<comment><USER8> _he's just packaging up other people's work with a more engaging presentation_

Since it's pretty so rare to find someone who both (1) spends the time to find and understands that work, and (2) has the literary ability to engagingly present it, by some definitions, that can be considered genius.

</comment></comment></comment></comment></comment><comment><USER9> This hit the nail on the head as to why I don't care for Gladwell's writings. I'm tired of telling smart friends that I think his books are largely useless (and incredibly boring) and getting the same look I would if I said that Jesus and L Ron Hubbard came to me in a dream and gave me a great recipe for chicken chili.

Though unlike Chris Anderson, at least the anecdotes Gladwell bases his stories on are true, rather than mistaken third-party analysis.

<comment><USER10> What writing then would you say was similar enough to Gladwells to be in the same genre, but better in your opinion?

<comment><USER9> Michael Pollan.

<comment><USER11> Thanks for the lead. For me, this is what makes HN great (and make Slashdot great, o'right not as great as back in the day), smart, brigth, curious people sharing knowledge. Thanks again.

<comment><USER9> Any time. Both In Defense of Food and The Omnivore's Dilemma are great. My wife also swears by The Botany of Desire but I haven't read it yet.

</comment></comment></comment></comment></comment><comment><USER10> A lot of the advances we have in science came not because people rigorously studied data and then came to conclusions, but because people had flashes of insight, and then looked for data to validate or invalidate their opinions.

We need this variety of uninformed opinion because it is from one of those nuggets that new things will be invented.

Science is just philosophy combined with statistical data.

</comment><comment><USER12> Isn't most of what most of Gladwell writes a genralised case of "Alien's cause global warming." [http://www.michaelcrichton.net/speech- alienscauseglobalwarmi...](http://www.michaelcrichton.net/speech- alienscauseglobalwarming.html)

<comment><USER13> I was surprised to discover that who we have to blame for all pseudoscience, according to Crichton, is Frank Drake, whose office I happen to be borrowing! ;-)

</comment></comment><comment><USER14> _On Sunday Dave Winer defined "great blogging" as "people talking about things they know about, not just expressing opinions about things they are not experts in." Can we get some more of that, please? Thanks._

Irony, defined. :-) I kid.

I think Joel's problem here is that he missed the point where any of these guys claimed to be doing anything more than making a bunch of observations. Galdwell certainly isn't science, but I don't think he proclaims to be either.

I haven't read his newest book, but certainly his thesis is at odds with the idea (the one we truly want to love) that the only thing separating the haves from have nots is desire and work ethic. We're all over saying this is common sense, but then we find it outrageous that this could have an affect on any one particular outcome.

Gladwell's ultimate theory I suppose is that his observations should make us question how our society functions overall (again, haven't read the book yet). I guess that forces us to look at things in a way we often don't enjoy.

<comment><USER15> "Galdwell certainly isn't science, but I don't think he proclaims to be either."

The problem is that the majority of people will think it is science. It is written in a book, so it has to be true.

<comment><USER16> _isn't science_ must be the new intellectual attack cliché.

Would someone care to define this proper science?

<comment><USER17> Here's a working definition for you: the construction of interlinked models that are proven/disproven by repeatable independent experiments. Science is tentative and falsifiable. The normal day-to-day scientist usually deals with somewhat boring measurements and experiments inside of a _paradigm_. Every now and then the paradigm is shown to be broken and a new paradigm takes its place.

Usually to call something "not science" is to say it is not based on 1) testable, falsifiable hypothesis, 2) accurate data, or 3) an inability to replicate/verify

</comment></comment></comment></comment><comment><USER18> An Anecdote can have a place and a purpose - heck, that's most of my blog.

But the plural of 'Anecdote' is not 'Data'.

<comment><USER19> What is data more than a plurality of anecdotes?

<http://news.ycombinator.com/item?id=239392>

<comment><USER20> A plurality of anecdotes sampled without bias?

That's the problem: interesting data points become anecdotes while uninteresting data points don't, which is why you can't reconstruct the data from the anecdotes.

<comment><USER19> Right, but people always make the statement without qualification. So just saying "the plurality of anecdote is not data" is simply not true. You can say "may not be scientific" or "may be incomplete" but to say it is not data is incorrect.

</comment></comment></comment></comment><comment><USER21> This is about as dumb as picking holes in Mythbusters episodes. These sorts of books are not designed to be "hard" science, packed with raw data, and reliable, but dull, outcomes.

Books like those you see in the airport, the type that Gladwell, Godin, and the like write, are designed to be _science-entertainment._ It's just science (or marketing, in Seth Godin's case) as entertainment.

If these sorts of books actually get people interested in and reading about science in the first place, it's awesome! There's no way the general public will read dry academic papers, no matter how scientifically valid they are. If people build up an interest from somewhat exaggerated but entertaining books that introduce certain scientific principles, we are improved as a society.

</comment><comment><USER22> Ummmm..Gladwell is not Friedman and we know Joel likes to rant. Blink opened a lively conversation, so did Tipping point.

</comment><comment><USER7> "Such assessments turn individuals into pawns of their cultural heritage, just as Mr. Gladwell's emphasis on class and accidents of historical timing plays down the role of individual grit and talent to the point where he seems to be sketching a kind of theory of social predestination, determining who gets ahead and who does not — and all based not on persuasive, broadband research, but on a flimsy selection of colorful anecdotes and stories."

1\. We have just spent an entire presidential campaign during which we were reminded at every turn (and rightfully so) that the gap between rich and poor is growing, and this seems to dovetail nicely with a "theory of social predestination." Having anecdotes and data to try to explain the mechanism for how this works seems a worthwhile undertaking.

2\. Why does she want Gladwell to research high speed Internet connections?

</comment><comment><USER23> The shoe is on the other foot now, isn't it?

Joel written many an essay with sole basis in anecdote.

</comment><comment><USER24> From his quote of Kakutani: "Much of what Mr. Gladwell has to say about superstars is little more than common sense"

This is what has always bothered me Gladwell's writings, and when I see someone list 'Blink' as one of their favorite books it pretty much tells me they are someone of little substance. Gladwell is simply a formula writer (and his speeches follow a similar format) and I find it amazing he has extended his popularity this far.

<comment><USER25> I haven't read any of Gladwell's books, so can't comment on how formulaic he is; but I wouldn't be in the least surprised if being a "formula writer" were an _advantage_ in becoming popular.

</comment></comment><comment><USER26> The 4 Hour Work Week is when this whole genre jumped the shark. And I have not read that either. I've met Tim Ferris in bars. That was enough.

</comment><comment><USER27> now, that's just funny :-) LMAO

</comment><comment><USER28> It kills me how the Gladwell book brought this out of Joel. Nobody wants to be told their success is a good part luck and timing. They all want to believe it is because they are smarter and worked harder.

So suddenly the software world's number one anecdotal blowhard decides to slam another blowhard. Okay. Whatever.

<comment><USER6> Um, lemme see if I understand here, what you're saying... Are you claiming that (a) I'm successful, and (b) I think that I'm successful because I'm smarter and worked harder and (c) Malcolm Gladwell thinks I'm successful because of good luck and timing and that (d) therefore I'm mad at Gladwell's new book and that (e) therefore I decided to slam it? Is that your theory?

<comment><USER28> 1\. I'm saying your timing is suspicious. 2\. My own anecdotal experience tells me successful people want to believe they earned their success through brains and hard work 3\. Gladwell states that a good portion of success is due to hard work but that you have to be lucky enough to be able to put in the 10,000 hours at the right time and of course, have the luxury of putting in that kind of dedication

So bottom line, he really flatters successful people on the surface, while making the successful folk equal to the rest of us.

I don't think you are "mad" at Gladwell. I just think the motivation is strong and possibly an unconscious aversion to accepting that your success may be in huge part due to luck.

But then. Take with a huge grain of salt some asshole spouting off on a forum.

Believe it or not, you are one of my heroes, and I never seriously expected YOU of all people to be reading this.

Cheers to you and don't stop doing what you do. We are a better field because of it.

<comment><USER25> Consider the following two propositions.

1\. When someone "successful" criticizes Gladwell's thesis, it's suspicious because maybe they just don't want to hear that they weren't really smarter than everyone else.

2\. When someone "unsuccessful" criticizes Gladwell's thesis, it's suspicious because maybe they just don't want to hear that their lack of success simply shows that they didn't work hard enough.

#1 is your argument; presumably you find it plausible. It seems to me that #2 is about equal in plausibility to #1; and #1+#2 would say that _anyone_ should be viewed with suspicion, as probably motivated by something other than honest intellectual inquiry, if they criticize Gladwell's book. Which seems ... unhelpful.

It also seems curious that you describe someone as (a) "the number one anecdotal blowhard" and (b) "one of my heroes". Why should the rest of us take any notice of someone who knowingly takes an anecdotal blowhard as a hero?

</comment></comment></comment></comment><comment><USER29> Holy fucking crap, are you kidding me? Joel, you _really_ want me to choose between your writing and Gladwell's?</comment>


Show HN: Bean Counter, a (non crypto) virtual currency platform - <AUTHOR> https://currency.moyaproject.com/

<comment><AUTHOR> Hi HN,

This is something I had an idea for years ago, and even wrote some code at the time, but never really got it off the ground. I started from scratch again, and its more or less working.

Essentially it's online banking for a virtual currency, but its not Bitcoin or similar. It's intended to be used as a 'Community Currency' or for a group / community that trust the provider.

Please test, and if you can, send some currency to an email address or user. Let me know if you find any bugs.

Will</comment>


Show HN: Gmelius for Inbox by Gmail - <AUTHOR> https://chrome.google.com/webstore/detail/gmelius-for-inbox-by-gmai/dlbjhjnahgmigifoggidegpakbcjomgg?#showhn

<comment><AUTHOR> Feedback and suggestions very welcome.</comment>


$60953 self-sufficient loft-style tiny home on wheels can be towed anywhere - <AUTHOR> https://www.businessinsider.com/tiny-house-guys-urban-tiny-self-sufficient-home-wheels-2020-6 <comment><USER2> Tiny House movement misses the point. The reason housing has become expensive is due to the cost of land, not improvements. Construction costs remain stable. You still need to park this house somewhere, and you always see them parked on huge plots of land with nobody else nearby -- park them close together and you have a "trailer park." So, you end up on the far outskirts or in someone's backyard, where land is cheap already -- so what's the point? Might as well build a normal house, which isn't that expensive to do, once you have land.

<comment><USER3> Exactly. Tiny homes misses the point. Where tiny homes are parked, land cost is generally not a problem and you don't actually need to have a kitchen- bedroom-toilet combo. IMO it is for the Instagram crowd.

</comment></comment><comment><USER4> This actually seems like a really bad financial deal when you consider the square footage you are getting. You could buy a house with 10x space in a nice city for 5-6x the price.

<comment><USER5> The marginal value of space in your house does not remain constant as you get more space.

On the other hand, this 60k doesn't include any land at all....

</comment></comment><comment><USER6> There's some really great tiny house tours on YouTube. My favourite is Living Big in a Tiny House, presented somewhat ironically by a really tall kiwi. His enthusiasm and the incredible labours of love that most of the houses he visits are makes it great watching.

[https://m.youtube.com/user/livingbigtinyhouse](https://m.youtube.com/user/livingbigtinyhouse)

Most of those houses are self-built, and the standards of fittings is an order of magnitude higher than any RV.

However, the show conveniently glosses over the fact that buying in a house in most Western cities isn't really about the house at all, but the land it sits on. Most of the tiny house builders are on a corner of a friend's land, or in their parents garden. They don't have the insecurity of having to move house that you'd have with renting, but they've often traded it for insecurity of location.

</comment><comment><USER7> As someone living in Japan, that looks awesome.

To put this into perspective, you can get apartments that size here. Obviously designed for bachelor's.

(A company called leo palace rents them out, but there are independent ones as well).

<comment><USER8> Agree. I live in an apartment similar size and layout to this and it's all i need. In fact it's more space than i need, since i only use my "living room" to dry clothes.

It would be cool to have an option like this if i ever moved to a less dense area. My concern would be finding land to put it on. Presumably any land you could legally park this would be far enough out in the country that you'd need to own a car to go anywhere anyway, at which point i feel might be better off with an RV.

<comment><USER9> You probably don't want to be commuting anywhere in your rv. Especially if the commute is _far_.

</comment></comment></comment><comment><USER10> Try quacking:

"park model mobile home"

Same notion, sans pricey self-sufficient solar.

<comment><USER11> Hehehe, is that what we call searching on DDG now?

<comment><USER12> I hope so! That would solve the biggest issue with its adoption IMO.

</comment></comment></comment><comment><USER13> I wonder how towable it is. I have friends who have RVs that are much more expensive than this portable house, and the RVs are not as nice inside.

<comment><USER9> I recently bought a travel trailer my family is living in while we build a house. It is not as spacious inside as this thing is, but I can stand up inside it without hitting my head anywhere and I'm not a small guy. It also cost only half what this tiny house is going for. My bathroom(s) are not as nice, but that said, I have been in someone's 120k Airstream conversion that had a 3 person jacuzzi in the master bath. My trailer is prewired for solar and setting it up off-grid was easy.

We talked about getting or building a tiny house on wheels instead but we settled on the travel trailer because it should be easier to resell once we've built our house.

If you want to live in a tiny house and it's not just temporary it seems easier and cheaper to just build it on the dirt. I could see these houses on wheels coming in handy if you don't own your land or have other building restrictions but still plan to be there for awhile. I wouldn't imagine these would be good for frequent moves since none of the interior is designed to "batten down" and the transport could stress the (often) wood frame classical construction.

<comment><USER14> There is often a minimum square footage requirement for new homes in most U.S localities. Putting the house on wheels generally skirts these restrictions.

</comment></comment></comment><comment><USER15> Self sufficient as long as the temperature outside is the temperature you want inside.

</comment><comment><USER16> I like the exterior and general blueprint of the house, but the interior materials and appliance choices don't seem very modern.

</comment><comment><USER17> Business model: buy cheap land with hookups for these things like millennial trailer parks.

</comment><comment><USER18> 60K? Are they retarded or something? One can get the same thing for 10K from china. Add 2k for shipping. 12k you're done. Check on Alibaba plenty of suppliers and custom builders.</comment>


It's the end of the office as we know it - <AUTHOR> https://www.vox.com/recode/2020/4/14/21211789/coronavirus-office-space-work-from-home-design-architecture-real-estate <comment><USER2> What on earth are all those empty office spaces going to be used for if they are vastly underutilized?

</comment><comment><USER3> Finally, a strategy against the Great Hall open office plan.</comment>


Apple files for patents on MagSafe 2 and iOS Notification Center - <AUTHOR> http://www.patentlyapple.com/patently-apple/2013/01/apple-patent-filings-uncover-magsafe-2-notification-system.html

<comment><USER2> I hope that the Android "notification center" does not infringe on this very original patent, which was clearly inspired by the Quake console, also invented by Apple.</comment>


High-Pressure Processing of Food - <AUTHOR> https://www.slideshare.net/zgoutham/high-pressure-processing-of-food <comment><USER2> Pasteurization is one of the great lifesavers of the modern age, akin to the initial use of fire to cook food. We in the west can afford to be obsessed with "fresh" because, thanks to modern scientific agriculture, we don't have to deal with so many pathogens. But the bugs are still out there. Cook your food properly. I would be extremely cautious about any new sterilization tech. I want it tested not just on clean food from clean farms, but on the horrible stuff not normally seen in our food chains.

I like my steak overcooked, cooked to the point of wrecking it, because where I grew up eating under-cooked meat was a serious health hazard. We used to wash our vegetables in water with a bit of bleach. Whenever I see someone eating a bloody steak, or vegetables rinsed only in tapwater, I shudder a little.

Does it kill pork tapeworms?

[https://www.cbc.ca/radio/asithappens/as-it-happens-friday- ed...](https://www.cbc.ca/radio/asithappens/as-it-happens-friday- edition-1.5166570/brain-surgeons-went-looking-for-a-tumour-but-found-a- tapeworm-instead-1.5166571)

"Some people get it by ingesting microscopic tapeworm eggs found in raw or undercooked pork, or unwashed fruits and vegetables from overseas. But Palma has never travelled outside the U.S."

<comment><USER3> > where I grew up eating under-cooked meat was a serious health hazard.

This is a not-so-obvious fact I only learned about in my 20s : that everyday food can be dangerous. I grew up in a very rural area and never thought our food couldn't be safe (except the milk, we had to boil it once back back from the farmer next door). I liked to eat bits of raw meat while my mother cooked and always thought we rinsed the vegetables only because they taste and look better without the dirt and small bugs.

Maybe I was lucky to live in a "safe food zone" (Europe, France). Is there any data on the prevalence of food pathogens? Also, is there any correlation between gut problems and being raised in rural vs. urban areas?

<comment><USER4> I've never heard of home paseurizing farm milk, is that common?

<comment><USER5> Yes. And easy. Though I would imagine not as common a practice as it was in the past.

</comment></comment></comment></comment><comment><USER6> HPP is awesome: extends shelf life with minimal flavor/texture changes. Favorite HPP product: "fresh" coconut water esp Harmless Harvest.

(I founded 3 successful food distribution startups)

<comment><USER7> I was wondering why harmless harvest tastes so much better than other coconut water. It's way too expensive for me to regularly buy but the flavor is so much better.

<comment><USER8> Alas their green bottle lids are near impossible to twist open.

</comment></comment></comment><comment><USER9> Fascinating.

So why exactly is this not widespread now?

Is it too new, too costly, or does it diminish the taste/texture more than the slides indicate?

Or is it just not necessary, e.g. most people either eat their food before it goes bad, or forget about it for so long that this wouldn't make much a difference anyways?

I have a hard time believing that subjecting, say, a crisp green pepper to pressure high enough to disrupt all bacteria wouldn't noticeably alter the texture (perhaps similar to how freezing does)... or just as bad, make it implode and rupture. (Although I guess you could poke a small hole in produce with hollow interiors.)

<comment><USER10> It's not that rare now. I have seen some mainstream dairies using it for particular products distributed in EU. And many veggie smoothie brands use it in the UK. E.g. Savse.

I would like to see studies comparing it to pasteurization as I said in another comment. I believe pasteurization creates some denatured proteins and weird peptides due to heat shock that might not be very healthy. It'd be interesting to see whether HPP is better in this regard.

<comment><USER9> I'm no expert, but it seems like it would have to be better, no?

Pressure at these levels could damage cell walls but not break apart molecules the way heat does, right?

<comment><USER10> That's the claim, and I tend to believe it's true. But I'd like to see some convincing data.

</comment></comment></comment></comment><comment><USER11> The effects of (very) high pressure on life are relevant to SETI, since it probably rules out the existence of life deep in large water worlds, and in "ice giants" like Uranus and Neptune.

At very high pressure, it becomes energetically favorable for proteins to be broken down into individual amino acids. This is because amino acids are zwitterions, with a positive and negative charged ends. These charged parts pull in water molecules, which makes the Gibbs free energy of the reaction more favorable for solvolysis as pressure goes up.

</comment><comment><USER12> Noticed the same thing with pressure cookers. Food that has been nuked with one will stay good at room temp for a surprising amount of time assuming no additional exposure to contamination

<comment><USER13> The point of a pressure cooker is to allow higher temperatures than 100°C, which cooks things faster. But anything higher than 60°C should kill almost all bacteria (possible exception: rice bacterial spores) if you cook it long enough. Have you done a side-by-side comparison of food cooked in a pressure cooker vs cooked at normal pressure?

<comment><USER14> Killing spores is a lot harder. They can sit around in harsh conditions for a few hundred years until the conditions are right to germinate. And cooked foods devoid of other life (competition!) is a perfect situation.

There's a lot floating through the air, not just what comes on rice.

For immediate consumption, it's not usually necessary to kill them, but for storage it can be.

<comment><USER15> It won't stay a spore when wet though. The difficulty is when dry, but in cooked food it's not going to stay in spore form.

That's why steam is used in medical sterilization, rather than just dry heat.

</comment></comment></comment></comment><comment><USER16> I'm a fan of irradiating food, but has never quite taken off.

Read through it all the way to see what it would do to beef, it looks like the meat will lose its color.

<comment><USER17> At HPBB last year (coincidentally in Japan where high pressure food sterilization was first commercialized) there was a whole series on high pressure sterilization of food.

The last presentation was a company with a scalable automated canning and sterilizing machine that was simply beautiful from an engineering standpoint.

Since we don't fully understand nutrients and how stuff like high pressure sterilization, heating, and other methods affect bioavailability, impact protein structure, and create other changes, it's all down to trying and learning as we go.

What's great about pressure is that it can deactivate and destroy some of the harmful organisms in food, but my curious concern is what does that do to the cellular material we want intact for our body, how does that affect the protein structure (for those not familiar, protein structure and folding is absolutely crucial for functionality).

Irradiation concerns me more than pressure because if you're not careful, you could be breaking bonds that you don't want to be breaking.

All in all it's a fascinating topic and important to everyone who eats.

<comment><USER18> You digestive system doesn't absorb intact protein but disintegrates it.

<comment><USER19> Look up variant Creutzfeldt-Jakob disease (aka Mad Cow Disease).

<comment><USER16> Largely caused by animals being fed their own kind, but once the protein is created, it's nearly impossible to destroy. It's denaturing temperature is 600+ degrees and it laughs in the face of irradiation. Id be curious if the prion is susceptible to high pressure treatment

</comment></comment></comment></comment></comment><comment><USER20> Pressures so high they aren't found in nature create all kinds of denatured proteins our digestive systems have never seen before. Most I'm sure won't do much, but some might turn out to harm us in unseen ways.

Is nobody just a little worried about consuming all those without some more serious safety tests first?

<comment><USER21> No. proteins are denatured by cooking and the digestive process, before being broken into constituent amino acids. It is both extremely unlikely that applying pressure would create either novelly denatured proteins or that said proteins, if formed, would be harmful.

The scenario isn't strictly impossible, but something reminiscent of an fda phase 1 study to ascertain safety of every food item to undergo the procedure is an insane standard[1]. Also a standard massively above and beyond anything our current food supply has ever had in place.

[1] Read: costs of study far outweigh benefits weighted by likelihood and severity of issue.

</comment></comment><comment><USER10> It'd be nice to compare the effects of HPP vs Pasteurization in milk, and whether it less disruptive.

Pasteurized milk doesn't ferment as well as raw milk, suggesting lots of peptides are altered. And that is why some cheese DOPs mandate raw milk (only on hard cheeses, as on soft ones it'd not be safe).

<comment><USER22> Fermentation is largely a product of naturally occurring bacteria is it not? Makes sense pasteurizing it and killing them all would prevent fermentation, which in this case would just be referred to as spoiling.

<comment><USER23> No, I think the point here is that even if you inoculate pasteurized milk with microbes, which you typically do in cheese- or yogurt-making to ensure that you grow the species you want, they still don't grow as well nor produce the same end product.

<comment><USER24> When I make yogurt, I usually hold the milk at a high temperature (> 180F) for a while first — it improves the final texture. Raw is not necessarily better.

</comment></comment></comment></comment><comment><USER25> > Fresh or marinated meat: Iron in the myoglobin changes from ferrous to > ferric and globin is denatured-the red color is lost.

For better or worse, it doesn't seem likely that the bioavailability is identical between ferrous and ferric iron. How significant are such changes? It'd be nice to see the results of some RCTs on rodents comparing this process to fresh and heat treated. I imagine high pressure would be nutritionally better or worse depending on the food.

Does anyone know if a 600 MPa pressure chamber, DIY or not, is within reach of a garden variety prepper?

<comment><USER26> Considering that the yield strength of a lot of steels is at or below 600 MPa I wonder what these machines are made out of. If you wanted to make one yourself a 50 ton hydraulic press would generate the pressure needed but the seals that you would need for this are crazy to be food safe.

Home canning would do almost the same effect for much cheaper.

<comment><USER25> > A typical HPP process uses food products packaged in a high-barrier, > flexible pouch or a plastic container.

If the pressure medium doesn't enter the pouch maybe it doesn't need to be food safe.

</comment></comment></comment><comment><USER27> Diamond synthesis machines are at ~100 MPa. I wonder if these food ones are capable of making gems without high temperatures.

<comment><USER28> Unfortunately the pressure in HPP machines is dispersed over a large vessel (foot scale diameter cylinders), while diamond anvil cells and the like focus that pressure at the mm/sub-mm scale.

Would be nice though!

<comment><USER27> Why would that matter? High pressure is high pressure. Large vessel would mean you can grow many diamonds at the same time, no?

<comment><USER28> You might be right... pressure needed for diamond synthesis is almost certainly much higher than for killing bacteria via pressure drop.

Turns out, it is, and they add temperature to the mix:

>They were able to heat carbon to about 3,000 °C (5,430 °F) under a pressure of 3.5 gigapascals (510,000 psi) for a few seconds.

</comment></comment></comment></comment><comment><USER29> Wouldn't the HPP process break the cell walls of the food being treated. This would lead to poor tasting and faster deteriorating of the food?

Freeze drying is a process for preserving food which shares the high pressure aspects of HPP. But apparently the pressure is not as high, and food can be stored for 20 years.

<comment><USER30> Freeze drying is largely about removing water. No water means no bacterial action. Instant mummification, in effect.

</comment></comment><comment><USER31> By the way, there's also Pulsed Electric Field Pasteurisation.

[https://www.newfoodmagazine.com/article/2116/pulsed- electric...](https://www.newfoodmagazine.com/article/2116/pulsed-electric- field-pasteurisation-of-foods/)

</comment><comment><USER32> The other day I was thinking about the survivability of microbes inside ice moons at various pressures and came across the the above topic.

It may well be that exomicrobes can be adapted to live at high pressures but not be able to surive at low pressures.

</comment><comment><USER33> I am assuming this is the same thing as Cold Pressure processing seen by this hummus brand? [http://www.bluemoose.com/about/](http://www.bluemoose.com/about/)

</comment><comment><USER34> This site is unreadable on mobile. Does anyone have a link to a PDF version?

<comment><USER17> Really? I had no problem on an iPhone X, swiped through the slides just fine. What platform are you on?

<comment><USER35> It worked fine on a 6" device on Firefox for Android for me, however the text was small, and when zooming it only shows the zoomed slides in the original viewpoint which doesn't change.

I tested on an iPhone 5S which has a much smaller screen, so I need to zoom, but when zooming the page ends up messed up.

</comment></comment></comment><comment><USER36> Does anyone have a sense for how much the machines cost?

<comment><USER37> Yes. I've looked into them for a project. They are very expensive. Like in the low 7 figures. They're high maintenance and the packaging for at least some foods required is relatively expensive too.

They're pretty much as this point only for large production facilities/copackers. They're useful basically for products where heat-based pasteurization has noticeable downsides.

</comment></comment><comment><USER38> We've been eating heat cooked food for millennia. We know it's more or less safe, and we have evolved suitable enzymes.

We've never eaten stuff which went through such a high pressure process. This is not your average pressure-cooker, look at the numbers.

We have no idea what eating this stuff does long term, just like micro- plastics for example.

Yet people here seem to be cheering and jumping head-first just because it's cool technology.

<comment><USER39> We can measure what it does. We can examine the inputs as well as the outputs.

Why are anti-science arguments from emotion/fear so common around new types of food technology? What is it about food specifically that triggers what appears to be a deep-seated fear of change in people?

<comment><USER40> Health has become a sort of religion for many. Health, food and religion frequently go together in old mythology and now new.

"Good for you" and "bad for you" spread like old myth, factions fight, people have incredibly strong beliefs sometimes which have at least a little basis in reality sometimes they are worse than harmless.

These days it just isn't because some mystical being said so.</comment></comment></comment>


Yogurl CLI (v.1) - <AUTHOR> https://github.com/720kb/yogurl <comment><AUTHOR> When you need to src files but don't want to waste time with Dropbox and Google Drive and "privacy-unsafe" services.

We made this so everyone is able to make remote URLs to source files as quick as possible.

It's just 1 line command.

The CLI quick example: [http://i.imgur.com/ujrIpEv.gif](http://i.imgur.com/ujrIpEv.gif) Yogurl is meant for developers, please use it with moderation.

Any contribution, feedback, bug report, issue, doubt is really appreciated.</comment>


Co-routines as an alternative to state machines (2009) - <AUTHOR> http://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative-to-state-machines/ <comment><USER2> A few observations:

* I've found that state machines are _much_ easier to understand when they consist of actual gotos, with labels for each state; the current state being where execution is.

* Coroutines are one of those things that I think are easier to understand and write in Asm - a yield looks much like a call but you pop the return address off the stack and save it somewhere, so the next call basically becomes a jump to the resumption point.

* Yielding between coroutines is very similar to switching between threads.

* It helps a lot when understanding coroutines if you forget any existing notions of what functions are and have to do, and just focus on how the execution flows.

<comment><USER3> I agree with all of these points.

As much as Dijkstra liked to cry foul on goto, there are some instances where they really can make imperative code _more_ readable [1]. State machines are a fine example of this. In languages that lack goto but _do_ have tail call optimization (such as many functional languages), you can safely substitute mutual recursion. Then functions become your states, and transitions are tail calls. Lambda is, after all, the ultimate goto [2].

Edit: forgot the links -_-

[1]: [http://web.archive.org/web/20090320002214/http://www.ecn.pur...](http://web.archive.org/web/20090320002214/http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf)

[2]: [http://dspace.mit.edu/bitstream/handle/1721.1/5753/AIM-443.p...](http://dspace.mit.edu/bitstream/handle/1721.1/5753/AIM-443.pdf)

<comment><USER4> Since this is the internet, I would like to nitpick and point out that Dijkstra never said that gotos are always evil. From his considered harmful letter:

> In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness > of the go to statement. The exercise to translate an arbitrary flow diagram > more or less mechanically into a jump-less one, however, is not to be > recommended. Then the resulting flow diagram cannot be expected to be more > transparent than the original one.

The important thing is to make sure that the state of the program can be modeled by something as static as possible and as close to the source code as possible. Ideally you should be able to tell what is going on just by looking at what line of code you are at and you want to avoid those times where the only way to understand a program is to go back to "main" and keep track of the whole code path that was taken to reach the point you are currently at.

So a state machine with gotos is fine since the state machine states are strongly correlated to the source lines of code. On the other hand, an unstructured program translated to a goto-less one via the introduction of lots of "flag" variables is just as hard to understand as the version using gotos.

\---

By the way, the "GOTO considered harmful" letter is smaller than your average blogpost amd is very easy to understand. I highly recommend that everyone should go ahead and read it if you haven't done so already :)

[http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...](http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html)

<comment><USER3> > Since this is the internet, I would like to nitpick and point out that > Dijkstra never said that gotos are always evil.

To further nitpick your nitpick: I never claimed Dijkstra _did_ say that gotos are always evil. I only said that he cried foul on goto, which he did:

> More recently I discovered why the use of the go to statement has such > disastrous effects, and I became convinced that the go to statement should > be abolished from all "higher level" programming languages (i.e. everything > except, perhaps, plain machine code).

As an aside, the Jacopini paper [1] doesn't really seem to have anything to do with eliminating jumps. In fact, all of their example normalizations given in figures 20-22 clearly contain jumps.

[1]: [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119.9119&rep=rep1&type=pdf)

Edit: After further reading the Jacopini paper, I think I see what Dijkstra was hinting at: abstracting the jumps into 2 basic operations which are less powerful than a generic jump -- a conditional jump and an iterative jump. Jumps remain in the normalizations but are more restricted, and in some sense "abstracted away". However, the paper does explicitly say that not all flow diagrams can be decomposed this way.

<comment><USER5> I suspect that the programming landscape has changed so much that the goto debate of the 70s is no longer relevant. People used to use gotos because they were necessary; naturally, bad code got written; a theory emerged that goto caused bad code. Fast forward to the present. Gotos are so feared that most programmers have never even seen one. Naturally, bad code still gets written. What we now know for absolute certain is that it's possible to write any kind of code without gotos (including awful code). If you wanted to revive goto today, you'd have to force people to use it, because no one would know what to do with it. There's a goto-free solution for everything. Bad code would still get written, but I doubt it would look like the bad code of the 70s.

</comment></comment></comment></comment></comment><comment><USER6> Rob Pike used coroutines for the Go Template implementation, instead of a standard lexer/parser:

Video: [https://www.youtube.com/watch?v=HxaD_trXwRE](https://www.youtube.com/watch?v=HxaD_trXwRE)

Slides: [http://cuddle.googlecode.com/hg/talk/lex.html](http://cuddle.googlecode.com/hg/talk/lex.html)

<comment><USER7> OMG that code looks horrible.

Kind of disappointing how he not uses proper parser generators and grammars.

I avoid imerative almost always if I can go declarative.

<comment><USER8> Very few production compilers uses "proper parser generators and grammars" for good reasons. He's even listed some of the reasons on one of the earliest slides.

Basically, the tools are generally not good enough.

</comment></comment></comment><comment><USER9> Neat, I was just wondering about this. I'm using the same idea with core.async channels in ClojureScript to parse the BitTorrent peer protocol[0], but I wasn't sure how to describe it.

[0] [https://github.com/happy4crazy/ittybit/blob/master/src/ittyb...](https://github.com/happy4crazy/ittybit/blob/master/src/ittybit/protocol.cljs#L93)

<comment><USER10> You can read more about the State Machines of core.async here: [http://hueypetersen.com/posts/2013/08/02/the-state- machines-...](http://hueypetersen.com/posts/2013/08/02/the-state-machines-of- core-async/)

</comment></comment><comment><USER11> Statemachines are an excellent way to get deterministic behavior of complex systems. Doing this using co-routines would be a lot harder, if it can be done at all once you reach a certain level of complexity.

I've tried to do something very similar to this in a library I wrote two years ago, in the end we reverted back to state machines because they were so much easier to tame. They're boring, but sometimes boring is good.

</comment><comment><USER12> Coroutines and state machines are indeed equivalent. Here is an example of how to (and good reasons why) translate mechanically one into the other:

[http://gabriel.kerneis.info/research/files/kerneis- boutier-2...](http://gabriel.kerneis.info/research/files/kerneis- boutier-2013.pdf)

More context in my work about Continuation-Passing C: [http://gabriel.kerneis.info/research/](http://gabriel.kerneis.info/research/)

<comment><USER13> Reading your papers now. Great stuff.

</comment></comment><comment><USER14> The blame is being placed on the wrong thing. It's not the state graph model that is the issue, but modeling it with object oriented constructs. The article actually also agrees that the the concept is succinctly modeled with the state graph diagram, and yet the object oriented version is hard to understand [1].

It's like saying Hashmaps are hard to use, when using List operations to manipulate a map stored as a list of tuples.

What the author needs is a library that can model state graphs in a much more readable way. I developed a state graph library for JavaScript when creating a turn-based game [2], which helped clean up my code immensely. There also appears to be a fairly popular Python library, with a nice looking API [3].

[1] "it's generally difficult to understand what's going on in the code without having some sort of a state diagram in front of your eyes." [2] [https://github.com/munro/stategraph](https://github.com/munro/stategraph) [3] [https://github.com/jtushman/state_machine](https://github.com/jtushman/state_machine)

<comment><USER2> There is nothing "object oriented" about the example, except for the fact that the code is in a class.

The "proper object oriented way" would be the State design pattern, using separate classes for each state and replacing the if/else with a virtual call, which I agree would be even more obfuscation of the control flow:

[http://en.wikipedia.org/wiki/State_pattern](http://en.wikipedia.org/wiki/State_pattern)

No, I don't think the answer is to make yet another library, if it isn't one that encodes the state graph as a table.

<comment><USER14> Yep! I completely agree, there is nothing object oriented about the example. So why use constructs meant for describing objected oriented code? Though, the fact that someone defined a pattern for designing state machines on top of object oriented constructs is interesting, thanks for bringing that up.

The other option is build a model for talking about state machines on top of Python's features (like decorators, meta classes, even coroutines!) than strict OOP to feel more like idiomatic Python, than say Java. And when someone has written the code already, I say why reinvent the wheel! :)

<comment><USER15> Classes are a way to encapsulate state, you don't have to use them together with oo. How else would you describe the example in python _without_ using object oriented constructs? Global variables or passing around a dictionary with all the things set up in init?

<comment><USER14> A distraction from the main point, being: state graphs rock! And deserve a high level way of talking about them in any language of choice, which most languages don't include in the stdlib. So one may have to roll their own/find a library. And that the article confused code that's "difficult to understand" with state graphs being bad.

> Classes are a way to encapsulate state, you don't have to use them together > with oo.

Lexical closures are another way to encapsulate state, modules are another, then there are monads! People have thought of lots of cool ways to encapsulate state.

> How else would you describe the example in python without using object > oriented constructs? Global variables or passing around a dictionary with > all the things set up in init?

I would build the example on state graph terminology, instead of on top of Python's class directly. Though, as userbinator pointed out, someone has described an OOP pattern for talking about state graphs [1].

Unfortunately there is no built in way for talking about state graphs in Python. To build that, Python has lots of fun features I can leverage! I wouldn't artificially limit myself. But first I would definitely research if someone has written a good library.

[1] [http://en.wikipedia.org/wiki/State_pattern](http://en.wikipedia.org/wiki/State_pattern)

</comment></comment></comment></comment></comment><comment><USER16> This is very much the same reasoning behind protothreads[1]. As a bonus, the implementation of protothreads uses a neat trick reminiscent of Duff's device [2].

[1] [http://dunkels.com/adam/pt/](http://dunkels.com/adam/pt/)

[2] [http://en.wikipedia.org/wiki/Duff's_device](http://en.wikipedia.org/wiki/Duff's_device)

</comment><comment><USER17> The great thing about state machines is that they are easy to debug. Once you have co-routines firing off co-routines, you're in co-routine spaghetti. In fact, I'll coin the term now:

      co-routines = "asynchronous gotos".

<comment><USER18> Can you clarify why state machines are easier to debug?

<comment><USER17> I've worked on large state machines in the past, which were rock solid and easy to work with. As the code was built using state transition tables, state machines were automatic. I would hate to think of how to juggle these systems using co-routines.

<comment><USER18> I'm not sure you're answering my question, though. You made a claim that state machines are easy to debug and coroutines are not. What makes you think they are not? I'm really just curious.

FWIW I've done significanly more work with state machines in the past, and I find them reasonable to debug, though not as easy as straight line code because in the latter the full state history (execution stack) is always known, while in state machines you usually need to do extra work to trace how the machine _got to_ some state.

<comment><USER17> Sorry I forgot my why. Probably because by using state transition tables the system's whereabouts is afforded salience. Compare this to a co-routines being sprinkled throughout a large code base, essentially creating asynchronous goto-hell.

</comment></comment></comment></comment></comment><comment><USER19> Good laughs chasing links:

\- Simon Chatham: "PuTTY is a Win32 Telnet and SSH client. The SSH protocol code contains real-life use of this coroutine trick. As far as I know, this is the worst piece of C hackery ever seen in serious production code." [http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html](http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)

\- Tom Duff: "Yeah. I knew this. In my piece about The Device, I mention something about a similar trick for interrupt-driven state machines that is too horrible to go into. This is what I was referring to." [http://brainwagon.org/2005/03/05/coroutines- in-c/#comment-18...](http://brainwagon.org/2005/03/05/coroutines- in-c/#comment-1878)

</comment><comment><USER20> This is cool for this example, but it seems like for a non-trivial state machine (I'm thinking TCP open/close or similar) the co-routine code could get very messy. It's really a small subset of state machines for which this is a good idea, or maybe even possible.

</comment><comment><USER21> Co-routines are great! Have been using them as part of Common Node ([https://github.com/olegp/common-node](https://github.com/olegp/common-node)) via node-fibers for a number of projects. Both stability and performance have been admirable.

For example at StartHQ ([https://starthq.com](https://starthq.com)) we have a framework that automatically fetches data about web apps from a number of sources, some as frequently as once every few minutes (blog RSS feeds) for all the 2K+ apps. At the same time we've had as many as a few hundred concurrent visitors on site at peak, all on an EC2 micro instance, with no noticeable impact on responsiveness.

</comment><comment><USER5> Theoretically speaking, any machine that keeps a fixed (finite) amount of state is a finite state machine. Once you recognize that, you will realize that you have written lots of them without even trying. If a problem inherently requires a fixed amount of state, writing a finite state machine is virtually inevitable. So it's not really a choice of whether to write a finite state machine; it's a choice of how you want it to look; it's a question of style. The state machine style assigns a name to each state, and makes the transitions very obvious. Co-routines can be finite state machines, quite clearly. You could argue that they do not follow the state machine style, though.

</comment><comment><USER22> At one point I was attempting to simulate multiple processors running in parallel. It turns out this behavior can get really finely grained.

So a processor executes instructions, and an instruction/opcode is made up of several cycles. Say for an "INCrement" instruction, there would be a cycle to fetch the opcode prefix, another to fetch the location to increment, another to read the value at that address, another to increment the value, another to write the value back to that address.

There can arise a case where one CPU is writing to memory right as another is reading that same address. And depending on whether you synchronize the two CPUs between opcodes or between cycles, the one reading can end up seeing a different value. This can, in certain cases, break emulated software if not done correctly.

It gets even hairier when you factor in that each cycle consists of several clock ticks. There is time required to hold a value on a bus before a read or write is acknowledged.

So as I continued to try and increase the precision, I found myself nesting state machines within state machines. Each CPU core had one for the instruction table to select the active instruction. And then each instruction had one for the active cycle. And then each cycle had one for the active clock. And then there was also an interrupt-driven DMA unit that could trigger within cycles that had to be accounted for. It was just too complex to collapse into one giant, 100,000 case state machine inside of a single function. Imagine trying to implement an x86 CPU inside one switch table inside one function.

So you would have to traverse through 3-4 state machines to do something as trivial as "increment an integer", and then return all the way back up the stack frame and switch to the other CPU. The code ended up being around 90% state machine maintenance to 10% actual simulation code. And it was painfully slow.

This led me to the idea of having a separate cooperative thread (coroutine+stack frame) for each CPU. Whenever one would read from or write to something the other CPU could see, it would make sure it was 'behind in time' to the other CPU. Otherwise, it would switch the stack frame and resume where the other thread left off. When that CPU stopped, it would resume right at our first CPU's pause. Very highly reciprocal.

The end result was a code reduction from around 350KB for a CPU core to around 35KB for the exact same code. And thanks to what I'll call "just in time switching", it was possible to run one CPU through hundreds of instructions when it wasn't communicating with the other, greatly reducing host CPU cache thrashing. I ended up with a huge speed bonus to boot.

The one problematic area ended up being serialization. Basically, this model moves the state machine into the host CPU's stack frames. But you can't write that out portably, so it becomes a real problem to capture an exact point in your program, write it out to disk, and then resume at that exact point in a future run. That took a long time to solve, and required some serious trickery involving "checkpoints" for serialization. So it's something to keep in mind if you want to use coroutines/cooperative threads and also want to serialize/unserialize things.

What was refreshing was that the core logic for switching between two threads is surprisingly simple. For x86, it is simply:

        thread_switch(to = ecx; from = edx):
        mov [edx],esp; mov esp,[ecx]; pop eax
        mov [edx+ 4],ebp; mov [edx+ 8],esi; mov [edx+12],edi; mov [edx+16],ebx
        mov ebp,[ecx+ 4]; mov esi,[ecx+ 8]; mov edi,[ecx+12]; mov ebx,[ecx+16]
        jmp eax

Basically: save the old stack pointer and volatile registers, swap to the new stack pointer, restore the volatile registers and return. The function design is the program-equivalent of a palindrome.

(push/pop tends to be slower on Athlon chips than indirect memory accesses; and getting the return address into eax instead of relying on ret allows x86 CPUs to start caching the new instructions quicker.)

So, like everyone else who has discovered this concept, I of course wrote my own library for it in C89, which can be downloaded here: [http://byuu.org/programming/libco/](http://byuu.org/programming/libco/)

Instead of trying like other libraries to build in complicated schedulers and hundreds of functions, mine is just four functions taking zero to two arguments each. No data structures, no #defines. The idea was for the user to write their own scheduling system that works best for their intended use case, instead of trying to be one size fits all.

<comment><USER2> Very interesting. If you're going for size instead of speed, then you can do that thread switch in 5 instructions:

        pusha
        mov [edx], esp
        mov esp, [ecx]
        popa
        ret

(This might be actually be faster too on recent CPUs.)

<comment><USER22> That will definitely work, and be more portable to esoteric ABIs and calling conventions. But it was more than 3x as slow on the Pentium 4, Athlon 64 and Core 2 Duo E6600. I haven't benchmarked since then. But you're pushing and restoring a whole bunch of volatile registers in vain.

Another fun detail, I tried using xchg r32,m32 to swap the stack pointer out in one instruction. Turns out that on the Pentium 4 (and probably others), the instruction is implemented in microcode now. Plus it's a guaranteed atomic operation. The benchmark I wrote ran at least 30x slower than with two mov instructions. I was absolutely blown away by that. People used that all the time in the 8086/80286 days to save a bit on code size (a much bigger deal back then.) Yet that same code, run today, can end up being substantially slower. Not knowing what opcodes will become slower in the future becomes a fairly compelling argument against writing inline assembly for speed.

ARM has nice register lists that you can use to mask out the volatile regs. So an optimal implementation is something like:

        push {r4-r11}
        stmia r1, {sp,lr}
        ldmia r0, {sp,lr}
        pop {r4-r11}
        bx lr

Moving on to amd64 ... Microsoft ignored the SystemV ABI (rbp,rbx,r12-r15 are non-volatile) and instead made xmm6-xmm15 non-volatile as well. This makes it more than twice as slow to perform a safe thread switch there. Even their own fibers implementation ignores xmm6-xmm15, unless a special flag is used.

Probably the strangest was the SPARC CPU. It has register windows for fast register saves/restores on leaf functions. Pretend your 16 regs were a block of memory. It gave you 16 blocks of that memory, and you could change one value to move to a new block of memory. When attempting threading, you couldn't know if you would recurse enough to exhaust this window. So you had no choice but to save and restore every single register window. Context switching became _immensely_ demanding. So much so that GCC offered a compilation flag to not use register windows in binaries it produced.

The choice of volatile vs non-volatile is really fascinating. The less non- volatile you have, the faster both cooperative and preemptive task switching is. But it also means you have less registers that remain safe to use after function calls.

There's also caller vs callee non-volatility: either the caller has to back up the regs it thinks the callee will trample (or all of them); or the callee has to back up the regs it knows it will trample (but may end up backing up regs the caller doesn't actually care about.)

</comment></comment></comment><comment><USER23> Yup, the connection between state machines and co-routines is pretty nice. Instead of state and a bunch of goto's you get a linear flow interrupted with 'yield' statements or whatever the equivalent is in your co-routine library.

</comment><comment><USER24> Coroutines as an encoding of state machines...?

<comment><USER25> Pretty much, which basically gives state to stateless system..</comment></comment>


Open source all-iron battery for renewable energy storage - <AUTHOR> https://www.sciencedirect.com/science/article/pii/S2468067219300318?via%3Dihub <comment><USER2> A fundraising appeal for this project was posted to HN in 2017:

[https://news.ycombinator.com/item?id=15618494](https://news.ycombinator.com/item?id=15618494)

I contributed. It's great to see the results published.

</comment><comment><USER3> Actual paper.[1] This looks like someone's science fair project. This chemistry has lower energy density than nickel-iron (Edison, 1901). Iron batteries are commercially available.[2] Not much of interest here.

[1] [https://reader.elsevier.com/reader/sd/pii/S2468067219300318](https://reader.elsevier.com/reader/sd/pii/S2468067219300318) [2] [https://www.essinc.com/energy-storage- products/](https://www.essinc.com/energy-storage-products/)

</comment><comment><USER4> Lithium ion battery prices are currently below $0.17 per watt-hour and expected to drop below $0.10 by 2024. Does the all iron battery have any advantages aside from being more environmentally friendly and not requiring lithium? I must admit, the "safe for DIY" description makes me want to give it a try.

<comment><USER5> Iron is extremely abundant. It's too heavy for most mobile applications, but might serve stationary needs.

<comment><USER6> Lithium batteries from EOL cars are also going to become extremely abundant.

<comment><USER7> Maybe in 20 years. As usage of electric cars is still ramping up, demand for new batteries is going to outstrip supply of old batteries by far. And that's before we ask how difficult it is to extract raw materials from old batteries.

<comment><USER6> FWIW, my city (Lünen, Germany) has 2 Multi-MWh storages built from them (1 from batteries from Smart cars, 1 possibly from i-MiEV batteries). Without any material-level recycling, just simple reuse, as energy density is a lot less important than for cars.

Maybe having 2 of those (admittedly pilot) projects in my backyard biases my estimations of their availability.

</comment></comment></comment></comment></comment><comment><USER8> Certainly iron is the metal to look at if you're going for the lowest cost, but the results so far are not inspiring.

There are about nine orders of magnitude in between these results and utility- scale energy storage, but it doesn't seem like that's what they're aiming for—the existing flow batteries they mention in the paper would be a better fit. They seem to be aiming at home applications, but they are seven orders of magnitude away from even the "tens of kilowatts" they cite in their abstract as typical for such applications.

However, both the negative results they mention in passing and the positive ones are major contributions to the progress of such low-cost battery designs.

Iron costs around US$0.03 per kg, while lithium is more like US$300 and nickel is US$30. In the intervening 3 orders of magnitude, cheaper than nickel but not as cheap as iron, are aluminum, antimony, arsenic, cadmium, carbon, cerium, chromium, copper, lead, manganese, samarium, silicon, tin, titanium, vanadium, and zinc.

Some of these are unpromising precisely because they are too electronegative; zinc, as they said, cannot be reduced electrolytically in water; the same problem applies to titanium, aluminum, and carbon—but maybe a different electrolyte could solve that problem. Others, like lead, are already in common use for batteries.

Chromium, titanium dioxide, vanadium, tin and tin oxide, copper, manganese and its oxides, cerium, samarium, and of course lead seem like plausible candidates. Indeed at least zinc-cerium batteries exist.

<comment><USER9> I'm not sure their materials even sound all that cheap. From the article

"The total cost of materials is $0.1 per watt-hour"

Or presumably $100/kWh

On the other hand with Zinc Air "our fundamental raw material cost of zinc is just $2-$3/KWh." from [https://www.altenergymag.com/article/2019/03/zinc-air- batter...](https://www.altenergymag.com/article/2019/03/zinc-air-battery- technology/30652) talking about NantEnergy's rechargables.

<comment><USER10> Yeah, the interesting comparison is the energy storage per dollar, not the cost of the raw materials.

<comment><USER9> Indeed. Nant have been talking $100/kWh all in which is cheap but I think that's projected rather than that you can actually buy them for anything like that. Though the material cost is interesting as a potential end point if you got super automated production. A problem with Vanadium flow for example is that the materials are like 60% of the cost of the battery so it's hard to drop much. With LiCo the materials are quite a big % of the battery cost though these things vary with time and may drop. I think Telsa are reducing the amount of Cobalt used dramatically for example [https://qnovo.com/82-the- cost-components-of-a-battery/](https://qnovo.com/82-the-cost-components-of-a- battery/)

<comment><USER10> Sodium ion batteries that don't use much in the way of exotic materials seem feasible. It's the sort of thing where someone has to be successfully selling them to prove that they are reasonably competitive though.

</comment></comment></comment></comment></comment><comment><USER11> +1 for discovering that a polymer used in diapers for absorbing moisture is a cheap and effective ion-permeable separator membrane.

<comment><USER12> Unfortunately only mentioned once. Are we talking about the granules inside the nappy here?

Also doesn't seem to have instructions for processing it beyond the short description.

</comment></comment><comment><USER13> This looks amazing - and great to see such detailed instructions.

One thing to note is that this probably isn't yet ready for home storage of solar power.

"Our iron battery has sufficient capabilities for practical use in low power devices and projects. The cell's internal resistance is high, and so the discharge rate is limited."

At the moment it could be useful as a backup for high efficiency lighting. The bill of materials doesn't cover any electronics to monitor and maintain the cells as the charge/discharge.

But all pretty nifty!

<comment><USER8> No, it doesn't provide enough power for high efficiency lighting, or any lighting. Yet.

<comment><USER14> In the article, it describes keeping an LED lit for 350 continuous hours. Lots of room for improvement too

<comment><USER8> An LED with 0.5 mA going through it is definitely visually distinguishable from one that's off, but it's not "lighting" either, except maybe for Borrowers in a romantic mood, or ants.

<comment><USER14> A single LED emits plenty of light. Just not compared to daylight. And this was for many days..

<comment><USER8> A single LED can emit enormously varying amounts of light. With some quantities of current, it can emit plenty of light. (Unless it's a low-power LED and burns up first.) With other quantities of current, it emits very little light, all the way down to no light when the current is zero. The brightness at a given current varies by the type of LED, but not all that much (unless you're dealing with infrared or ultraviolet LEDs). And at 0.5 mA, all LEDs are very dim, more like "barely visible".

I suggest you try the experiment. Grab a 7805 and a 10kΩ resistor; you can find these in any discarded electronic device (from 1980 to 2005, anyway) or you can buy them at any electronics store. Connect the resistor between the "output" and "ground" pins of the 7805. _Do not connect the "ground" pin to ground._ Connect an LED between the "ground" pin ( _not_ the "output" pin) and _actual_ ground. (The negative pin of the LED goes to ground.) Connect a positive DC voltage relative to ground to the "input" pin of the 7805; any voltage between 10 volts and 35 volts will work. Now you have a regulated 0.5 mA going through the LED; if you want to confirm this, replace the LED with a 1kΩ resistor and measure the voltage across it with your multimeter. Try different LEDs.

Do they emit "plenty of light"? No, they do not. None of them.

If you want variable current regulation, you can use a variable resistor, but you should probably put it in series with a fixed resistor. You aren't going to burn up the 7805 without great effort, but you might burn up whatever you're driving with it.

</comment></comment></comment></comment></comment></comment><comment> dcahill-ieee It made 1mA of current, 0.5mW of power. Pretty long bow to draw linking this to renewable energy storage. A kettle uses a kW or 2 just to boil water. You would need a million of them to make a packet of noodles.

<comment><USER15> "just to boil water" has got to be the biggest understatement that I've heard in a while. There is a reason we use water in radiators: It's because water has a very high heat capacity.

I think this battery is meant to be used in small electronics projects. Like powering an arduino or even just an ATTINY.

<comment><USER16> > "just to boil water" has got to be the biggest understatement that I've > heard in a while.

It's also a good illustration of how much we depend on extreme energy densities for everyday use cases. Coming up with a good storage solution for renewable fuels is going to be a defining challenge for our generation.

<comment><USER17> This is my favorite method so far:

[https://qz.com/1355672/stacking-concrete-blocks-is-a- surpris...](https://qz.com/1355672/stacking-concrete-blocks-is-a-surprisingly- efficient-way-to-store-energy/)

Works well, portable, space efficient (could house it in the center of a skyscraper), and easy to disguise as something aesthetically pleasing

<comment><USER10> A much larger battery (129 megawatt-hours) can fit into a similar footprint:

[https://hornsdalepowerreserve.com.au/](https://hornsdalepowerreserve.com.au/)

(it takes ~1 hectare, which maybe the tower of blocks won't have quite that footprint, it'll be at least that imposing)

<comment><USER17> But aren't the drawbacks of a Lithium ion battery going to outweigh the benefits of saving the space?

<comment><USER10> In a literal sense, apparently not. There's a real actual 100 megawatt-hour lithium-ion grid battery and (concrete?) pie in the sky ideas for using dry mass for gravity storage.

<comment><USER17> I wouldn't say it's "pie in the sky" when the technology already exists and has been demonstrated. It's a really simple system.

In a sense, you're right that any technology currently in use is better than a technology that isn't, but if every discussion ended there, we'd have no new technology.

My question was assuming someone is choosing between lithium ion and gravity storage. My understanding is that lithium mining is pretty awful for humans and the environment, the batteries can explode easily, and their lifespan is limited.

Besides being a weird shape, what are the drawbacks of storing energy in concrete blocks?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Curiously, the article has a link[1] to the sources, located at OSF (Open Science Foundation), but it asks for the login first, not allowing to view without registration. Doesn't look like open science to me.

[1] [https://osf.io/4jvr9/](https://osf.io/4jvr9/)

<comment><USER19> Clicking the "download" link with the pdf icon at the top gave me access to the entire pdf

[https://www.sciencedirect.com/science/article/pii/S246806721...](https://www.sciencedirect.com/science/article/pii/S2468067219300318/pdfft?md5=9b80bd4a023bb227ff43f2dc066b936b&pid=1-s2.0-S2468067219300318-main.pdf)

</comment></comment><comment><USER20> Great detailed publication ! Makes me want to build one.

Curious to know how much efficient this battery can become without using too hard to source material ! And for which kind of cycles.

Even if components are environmentally friendly, electricity production is never footprint free, so if you need to 2x it to compensate...

</comment><comment><USER21> It makes me think of the Acquion project from Pittsburgh ([http://aquionenergy.com/](http://aquionenergy.com/)). That was an interesting attempt to commercialize environmentally safe batteries intended for uses where low power density isn't a problem-- eg underground energy storage for windfarms or solar arrays. They went bankrupt a couple years ago, but the concept was really exciting.

The immediate technical challenge with these kind of batteries at scale is the electronics to monitor and maintain the battery banks as well as deploying these things. It would take a truckload to set-up something usable for a house, I think.

</comment><comment><USER22> To put the costs intro perspective, an 83 Amp Hour car battery (typically a small car might have a 40-60 AH battery and a large car >100 AH) holds 1 kWh (kilo watt hour).

An 80AH battery can be had for about $100 on eBay.

The article states that the cost of materials might be $100/kWh.

So you could get the storage for about the same price using a car battery.

</comment><comment><USER23> I skimmed through looking for some key numbers but didn't find them. I bet someone who knows how to read the many numbers they did share would be able to hazard a guess:

what would the $/kWh look like?

how many cycles until you hit 90%, 80%, 50% capacity?

<comment><USER24> 100 $/kWh

</comment></comment><comment><USER25> This reminds me of the cheap water purification thing that got rolled out across poorer bits of Africa. Any cost reduction possibilities for this design?

</comment><comment><USER26> What are the odds the steel wool could catch fire on these?

<comment><USER27> Only if the electrolyte dries out, and even then it will be probably covered by salt crust.</comment></comment>


Objects All the Way Down - <AUTHOR> http://www.holger-peters.de/objects-all-the-way-down.html <comment><USER2> Smalltalk is the future the GUI promised us. But something went wrong in the '80s and we got stuck with file systems, terminal emulators and command line arguments.

Isn't it absolutely crazy that we have laptops with 6-megapixel screens, and we use those capabilities to simulate a 40-year old video terminal that in turn simulates the behavior of an even older line-based Teletype machine? [1]

Programming today is fundamentally the same it was on a PDP-10 many decades ago, except that the unintuitive CLI interfaces have been propped up by fast web search: "Just google it, no big deal."

[1] [http://www.linusakesson.net/programming/tty/](http://www.linusakesson.net/programming/tty/)

<comment><USER3> I'm sympathetic to the GUI dream, but do note that language is far richer than pictures: we graduate from picture-books to literature, and from pointing and grunting to speaking.

I do think that a Smalltalk future might have actually managed to be the best of both worlds, combining images and text into one coherent whole. But it never really came to fruition.

As things are, since I may not have both, I'll choose the power of text over the ease of pictures.

<comment><USER2> To me, the GUI dream isn't really about pictures -- it's about structure. Humans are much better at understanding visual and symbolic representations of structure than prose. Purely textual interfaces don't take advantage of that.

The structure that we currently have is file hierarchies and URLs (just another form of Unix-style path strings), and files containing sequences of text with no more structure than line breaks and indentations -- and after 40 years, we haven't even agreed on how to represent those in ASCII. The whole thing is barely removed from sectors on disk.

Smalltalk's class browser let you drill into a live hierarchy of objects and edit them in place. That's already much more advanced than our static blobs of text in a lifeless path hierarchy. And that was in 1975.

<comment><USER4> I've got to disagree, because representing everything as an object involves a serious amount of cognitive overhead. You're limiting yourself to things that can be represented as objects and still make sense, plus you've got to write the code to make your ideas fit into the object box (methods, interfaces, this, public private etc).

I've been working on some networking protocols, and I started by modeling each node as an object. Seemed to make sense. But there's a lot of overhead. Send, receive methods etc etc, and then you've got to instantiate them and then collect the data from the objects afterwards to see how the network did. I switched my code over to being a bunch of stateless functions that operate on a network graph and stuff got a lot less verbose.

This is not necessarily always the case, but I would hate working in an environment where I was forced to always use a very specific metaphor for my work.

</comment></comment></comment></comment><comment><USER5> Well there are version control tools in Smalltalk land. The primary one that ships with Pharo is called, Monticello [0].

Images are also a huge advantage which the author has obviously not had time to exploit.

Knowing next to nothing about Smalltalk before the summer I checked out Pharo and wrote a small application to scrape the HN front page and display the links in a Painter window. I watched a few videos, read some tutorials, and eventually had a working Smalltalk program in a couple of days. It was actually a pleasant experience.

A typical workflow starts by writing a snippet of code in the playground that instantiates the program you want to run. You execute it and get dropped in the debugger. You slowly add the missing methods and tests, stepping through the debugger as you go, and eventually your program runs. If you ever need to take a break you can save your image -- debugging session and all -- and pick it up later. There's no need to load up your source code and try to rebuild your application state to get to the point you were at when you last left your work.

That's really powerful for interesting systems like the Moose platform [1].

Overall I think the author is too biased to his existing tools to appreciate what Smalltalk is really about.

[0] [http://pharo.gemtalksystems.com/book/PharoTools/Monticello/](http://pharo.gemtalksystems.com/book/PharoTools/Monticello/) [1] [http://moosetechnology.org/](http://moosetechnology.org/)

<comment><USER6> Original author of the blog post here. I find it interesting that your takeaway from my blog post is that I am writing unfavorable over smalltalk. I quite liked it. I think I mentioned that I was checking out Smalltalk, didn't claim to summarize longer experience with it.

Moose looks interesting indeed.

<comment><USER5> It did come off that way. If you are interested you should definitely keep exploring. It's an interesting system.

</comment></comment></comment><comment><USER7> Little known fact: you can't have objects all the way down. At some level you need to add machine integers together. For that you need the internal representations of two different objects at once, not just their responses to a bunch of methods. If your language is objects all the way down, that's fundamentally impossible.

In fact, Smalltalk's VM has special code that detects when you try to add two small integers. That's similar to "abstract data types" in ML or "class-based encapsulation" in Java, as opposed to "object-based encapsulation" which is the cornerstone of Smalltalk.

<comment><USER8> > At some level you need to add actual integers together. For that you need to > access the internal representation of both integers at once

Not necessarily.

[https://en.wikipedia.org/wiki/Church_encoding](https://en.wikipedia.org/wiki/Church_encoding)

<comment><USER7> Yeah, fair enough. Updated my comment to say "machine integers" :-)

<comment><USER9> In a language without machine integers exposed to the programmer, there may be no way within that language to see any machine integers. There is a further "way down", but not from within the language.

A proposition about an implementation aspect of the language you're working in is testable in that language if a program in that language can produce output which is different based on whether or not that proposition is true. If the proposition isn't testable in that language, then it doesn't lie on the "all the way down" path which begins inside the language.

</comment></comment></comment></comment><comment><USER10> What if my name is "anonymous user"?

Anyway, primitive types in java is one of the reasons, why java has success. Try to do image processing or fast networking, while each byte is represented as an object.

<comment><USER11> An object is an interface, nothing precludes optimising representations either specifically (tagged pointers, unboxed values) or generally (collection strategies and JIT unboxing). The former being what C# does, its primitive types can still be interacted with as objects, you can even add new methods on `int`.

<comment> david-given I have an experimental and somewhat half-baked programming language where all types are anonymous; type names always refer to interfaces. It then does global type inference to decide whether the thing you're referring to is a primitive type or an object for the actual implementation.

What this means is that at the semantic level, the language doesn't distinguish between objects and scalars, so avoiding the horrible schizophrenia that languages like C++ and Java do --- you can subclass an integer just as easily as you can anything else. Performance is really good, too, mostly.

The downside is somewhat unpredictable behaviour due to invisible boxing and unboxing. e.g.:

        function complexExpression(x: int) {
          // do something expensive with x
        }

        complexExpression(4);
        complexExpression(numberlikeObject);

The type inference will see that complexExpression() is being called by both a scalar and an object, which means that x needs to be implemented as an object pointer, and the literal 4 needs to be boxed. This means the calculations inside complexExpression() will end up being a lot more expensive due to boxing and unboxing overhead.

I should readdress this at some point; it was a really nice thing to write code for.

[http://cowlark.com/cowbel/example.html](http://cowlark.com/cowbel/example.html)

<comment><USER12> You could specialize for primitives, e.g. under the hood generate complexExpression_int() and complexExpression_ref(). It wouldn't be too bad in terms of code size, because you only have to specialize primitives, and all reference types can share the same implementation.

<comment> david-given Yes, that'd be the obvious thing to do, but I think right now it doesn't (I could be wrong; I haven't looked at the code for ages).

I did at one point try to specialise everything. The results were hilarious...

        var a = cons(cons(cons(cons(empty, 1), 2), 3), 4);

As the left-hand-side of each cons was a slightly different type, it ended up generating four different versions of the cons function!

</comment></comment></comment></comment></comment><comment><USER13> "Overall I think the author is too biased to his existing tools to appreciate what Smalltalk is really about."

Agreed. The author is clueless.

<comment><USER14> (We detached this comment from [https://news.ycombinator.com/item?id=10637544](https://news.ycombinator.com/item?id=10637544) and marked it off-topic.)

> _The author is clueless_

Maybe so, but since your comment is only name-calling [1], you shouldn't have posted it here.

Since you know enough about this fascinating topic to identify cluelessness, it would be much better to post a comment with real information that could teach readers something about it. If you don't have time to do that, posting nothing is always an option.

1\. [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


Startup sets full mobile browser free - <AUTHOR> http://www.infoworld.com/article/08/01/28/Startup-sets-full-mobile-browser-free_1.html <comment><USER2> Mobile phone browsers with flash support would be great! I have Opera Mini (<http://www.operamini.com/>), a 'full' mobile browser on a BB but the experience isn't that great because of the small screen. I prefer BB's built in browser that automatically formats the webpage for the small screen.</comment>


Alphabet rises as Cloud, other revenues soften Q2 ad decline - <AUTHOR> https://seekingalpha.com/news/3598012-alphabet-rises-cloud-revenues-soften-q2-ad-decline <comment><USER2> Google's ad revenue had declined 8% in the second quarter. This is the first time revenue had declined year-over-year [https://news.alphastreet.com/alphabet-goog- googl-q2-2020-ear...](https://news.alphastreet.com/alphabet-goog- googl-q2-2020-earnings-the-most-important-numbers/)</comment>