Mad Max Economics - <AUTHOR> http://bit-player.org/2015/mad-max-economics <comment><USER2> If there is a problem with our economy it is much more likely that it is a case of suboptimal capital investment.

It's not like we lack goals and needs.

There is some hint to this in the ridiculous cash reserves held by some of the big dogs:

[http://americasmarkets.usatoday.com/2015/04/27/194b-apple- ca...](http://americasmarkets.usatoday.com/2015/04/27/194b-apple-cash-pile- hits-record/)

They are probably trying very hard to make good use of that money but it is very likely that them being in charge of all that capital is not the most optimal way to generate growth. Each of them is only specialized in a select few markets so for this capital allocation to be optimal it would mean that there would need to be exponential growth in each single market in which the capital is currently held. That is much harder than having exponential growth overall.

<comment><USER3> It doesn't really matter how specialized they are, if they hold it _in cash_.

And if it is "just" a cash position on their bank accounts, it doesn't mean that said money isn't invested or isn't working. It means that the banks have 194 billion dollars of almost free funding from Apple for their investments.

<comment><USER4> That's not cash. From their 10K: Cash and cash equivalents: $14B Short-term marketable securities: $11B Long-term marketable securities: $130B

<comment><USER3> Even better. Most of the so called "cash pile" is hard at work.

<comment><USER4> Exactly, all that cash is hard at work being invested.

The structure of the portfolio allocation is also interesting (in rough numbers): 10% cash, 10% short term, 80% long term.

</comment></comment></comment></comment></comment><comment><USER5> Author confuses units from step 1 to step 2 of his arguments.

Step 1 starts with an "S" shaped graph of GDP/Capita. Step 2 shows derivative of the curve, but is labeled as dGDP/dt, ignoring dCapita/dt. Author does not consider historical changes in demographics when GDP growth slows.

See demographic changes in Japan, Europe, US for examples of how population growth rates change due to economic and war-related shocks. Also see motivation for China ending the 1 child policy - they want to bring the cost of labor back down and they need a higher pop growth rate to generate enough economic activity to pay pensions, retirement, healthcare for expensive retirement-age cohort where people are living longer and thus costing the country much more.

Author should have challenged Porter's initial claim: "Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist."

While it makes for a good soundbyte, it ignores the symbiotic and (usually) directly proportional but lagged/leading relationship of economic growth and population growth.

<comment><USER6> It also ignores the question of what economic growth is. Infinite economic growth does not mean infinite potatoes. Infinite economic growth means infinite increase in perceived worth of stuff we make. That's eminently doable. I mean, growth has shifted to services long ago.

We can't make infinite potatoes, but that's not required for infinite growth.

<comment><USER7> If potatoes have value, the total economy is expressible in in some number of potatoes. Unbound growth requires the relative value of potatoes to always decrease. However, the same must be said for every other physical good including gold and land etc.

Thus, economic growth is only infinite when _all_ physical goods have zero value. That might happen, but it seems really unlikely.

<comment><USER6> As inflation-adjusted GDP approaches infinity the value of potatoes must approach zero, yes. Of course, were demand for potatoes to suddenly increase, the value of potatoes would too, so it does not imply any ability to buy an earth-sized ball of potatoes for a dollar in the near future. But the price of potatoes, at typical demand, must approach zero, yes.

The value of potatoes have been going towards zero for a long time, anyway. It's not hard to envisage a future with self-maintaining automated farming and fusion energy where potatoes are basically free.

<comment><USER7> Self maintained automated farms are not going to be handing out beach front houses any time soon. Further, an economy where everyone get's their own complete copy of earth and can teleport anywhere is still finite.

</comment></comment></comment></comment></comment><comment><USER8> Humanity's ability to produce sufficient food is likely capable of outstripping population growth for a long, long time. For example, over the last 80 years, corn yields in bushels per acre have increased 6 fold in the US [0], where the population has less than tripled. Kansas wheat yields have tripled from 12 to 36 bushels over the same period [1]. Granted, we eat much more varied diet than corn and wheat, but we've also managed to bring the cost of feeding ourselves down as the population has increased. Per-capita spending (as a % of income) on food in the US has dropped 43% since 1960 [2], which may indicate that the productivity of the food industry is increasing relative to population growth. (have to factor in per-capita income, which I don't have time for...).

What's more relevant to me is that nations with the most mature economies also have the lowest population growth rates. 35 of 241 nations have negative population growth, including Japan, Germany, Poland and Russia. The US has less than 1% growth [3].

So it seems that all things being equal, the Earth's population will trend asymptotically to some maximum due to human nature, and not out of control into crisis, unless it is somehow self-imposed by politics. And it seems likely to me that we'll be able to feed all those people by means of increasing productivity in agriculture and distribution.

[0] [https://www.washingtonpost.com/news/wonk/wp/2012/08/16/a-bri...](https://www.washingtonpost.com/news/wonk/wp/2012/08/16/a-brief- history-of-u-s-corn-in-one-chart/)

[1] [http://www.nass.usda.gov/Statistics_by_State/Kansas/Publicat...](http://www.nass.usda.gov/Statistics_by_State/Kansas/Publications/Crops/whthist.pdf)

[2] [http://www.ers.usda.gov/data-products/chart- gallery/detail.a...](http://www.ers.usda.gov/data-products/chart- gallery/detail.aspx?chartId=52216)

[3] [https://en.wikipedia.org/wiki/List_of_countries_by_populatio...](https://en.wikipedia.org/wiki/List_of_countries_by_population_growth_rate)

<comment><USER9> How much of that increased agricultural production is fueled by synthetic nitrogen fertilizers created with natural gas?

</comment></comment><comment><USER10> >Without growth, he says, economic life becomes a zero-sum game. "As Martin Wolf, the Financial Times commentator has noted, the option for everybody to become better off—where one person's gain needn't require another's loss—was critical for the development and spread of the consensual politics that underpin democratic rule." In other words, the function of economic growth is to blunt the force of envy in a world with highly skewed distributions of income and wealth.

The answer lies right here but the author fails to consider it. We could evolve our economic systems to redistribute obscene wealth and build a more egalitarian society. The ones who give in this scenario only lose on paper but they wouldn't notice any difference in their day to day. This is especially true once automation becomes the norm. The article is too simplistic and fails to consider a host of important variables which are only now coming into play.

<comment><USER11> > We could evolve our economic systems to redistribute obscene wealth and > build a more egalitarian society.

There is not enough of what everyone wants. There's no way to get it. Let's take a trivial example. There are a number of companies out there making smartphones. What if everyone wanted iPhones? There may be enough iPhones out there to give one to everyone in, say, New York City. There is not enough, and there will never be enough iPhones to give to everyone in the entire world.

If you're just talking about money, then that's even worse. If you redistributed all the wealth in the entire world among 7 billion people, every person in the whole world would get a check for the princely sum of $8.57. (Obtained by dividing the entire world's money supply, found on Google, by 7 billion, roughly how many people there are in the world right now) Meanwhile every single organization, every single company doing anything useful for the world has been completely decapitalized.

There simply isn't enough wealth in the world. And making everyone equal is the best way I can think of to ensure that no one will ever have the ability to make more wealth. Like it or not, we're stuck with inequality for the foreseeable future. Either people are going to be unequal in purchasing power terms, or in the fact that production capacities for all possible luxuries people might want are not and will never be world-scale. You can't give everyone on the planet a NYC penthouse. And until you do, people will complain about inequality. We need another way of thinking about the problems of the world than that some people have lots and lots of things that other people don't.

<comment><USER10> I never said make everyone equal. I said redistribute obscene wealth. There is a whole greyscale between black and white.

<comment><USER11> Where does that get us? Some small number of people get more wealth. Redistribution is not a solution for anything, all it does is destroy stuff.

I'm all for the expansion of classes that aren't ultra-rich and ultra-poor. But that process is already happening as fast as it really can happen, it's what globalization is if you can look at it with a rational eye. Through capitalism and markets. Big political solutions are sledgehammers that tend to only wreck things.

<comment><USER10> Globalization is a big political solution that favours only the ultra-wealthy. Ensuring people have purchasing power is the only way to ensure the economy doesn't become a zero-sum game. The way things are going, companies with only a handful of employees can be worth billions. Where does that leave the rest of us?

<comment><USER11> > Ensuring people have purchasing power is the only way to ensure the economy > doesn't become a zero-sum game.

How are you going to do this? You can't just print money and give it to them. If you do that, then you're either just creating another, tiny, class of people, or if you do it for everyone, then you're just devaluing your currency through mass inflation. If you take it from people that do have it, then you either have a huge management problem, how are you going to decide which wealth is worth redistributing and which is worth leaving alone, or you'll have mass chaos.

> The way things are going, companies with only a handful of employees can be > worth billions.

That's just, like, your opinion man. Mine is that the living standards of the poor have markedly improved in the last 50 years and continue to improve. Purchasing power is only one thing. There's access to food, political stability, access to a social ladder. All of these things are more important than how many dollars are in their pocket. Even the most autocratic nations have in the past few years had to open up.

</comment></comment></comment></comment></comment></comment><comment><USER4> Funny how this article would fit right in at the apex of the Roman Empire. Their "Mad Max" era was just the middle ages.

And how it would fit right in the middle of the "middle ages" if you're looking at it from the perspective of the caliphates.

And for the Mongols, their "Genghis Khan" era was equivalent to our modern era.

</comment><comment><USER12> I don't understand these problems.

The size of our population grows and, because of scientific advance, the amount one person produces increases too.

As long as non of those two factors becomes negative, everything should work fine.

The only problem I see in the future is, that we converted too much of earths bio mass to humans before we are able to get to other planets.

<comment><USER13> No. the amount each person produces does not increase, certainly not because scientific advance.

You see per capita productivity increase, where "productivity" not necesarily means "producing more". If you can cut your production in one third and get away with doubling your prices (inelastic market), that couonts as productivity increase: you are producing more Profits with the same Capital investment. If on top of that you go and lay off 40% of your work force, you get the per capita part as well: You are running the same Productive Assets with less Labour.

That last is always a goal of Management, because of (19th century) reasons.

</comment></comment><comment><USER14> Economic growth does not strictly require _specific_ raw materials and natural resources. With ingenuity and time, it is almost always possible to utilize alternative resources or recycle/reuse existing ones (e.g. seawater desalination).

The constraints seem to be our intelligence and perhaps energy. Energy could probably be solved with sufficient intelligence as well--e.g. nuclear fusion.

Negative externalities, such as anthropogenic climate change, are a real concern. We do not yet have good ways to neutralize all of those but it does not mean we never will. It is in some sense a race between consumption and invention.

John McCarthy, a father of AI, wrote a mini-site on this with some strong arguments: Progress and its Sustainability: [http://www- formal.stanford.edu/jmc/progress/index.html](http://www- formal.stanford.edu/jmc/progress/index.html)

</comment><comment><USER15> Isn't the first graph erroneous (and subsequantly the others)?

How can the GDP/Capita in the Mad Max age stay the same than the GDP/Capita in ~2050?

Shouldn't it go back to the same level as the GDP/Capita during the stone age?

I'm probably missing something there.

<comment><USER16> The idea he's criticizing is that constant GDP, zero-growth, would result in a mad-max future even if that constant was the 2050 level.

<comment><USER15> Thanks, that totally flied over me.

</comment></comment></comment><comment><USER9> Let's get material. How long would an economist expect there to be exponential growth in electricity consumption? Steel production? Indium usage?

<comment><USER17> _> How long would an economist expect there to be exponential growth in electricity consumption? Steel production? Indium usage?_

Irrelevant, because exponential growth of wealth does not depend on exponential growth in any of these things, or in anything material. Wealth is what you can do, not how much stuff you have; as technology advances, we figure out ways to do the same things as we did before, using fewer material resources (not to mention doing new things that no one could do before--like posting here).

<comment><USER9> I think it's a highly relevant distinction and leads to a very different view of the future.

</comment></comment></comment><comment><USER18> with inflation, flat growth is negative growth, so at least there's that.

</comment><comment><USER19> Just remember next time you talk about the 'War on the middle class' who's trying to give it ALL away in Paris this week.

</comment><comment><USER20> Exponential growth is needed only for keynesian economists because it keeps their pyramid scheme called welfare state running. If you have a decent one- digit economy growth on non-inflatable money (bitcoin), then everything Just Works. Money does not suddenly lose all its value because no one is printing it to extend never-ending credit that leads to inevitable collapse of inflated expectations and reality of finite supply of resources.

<comment><USER21> This isn't a story about money and/or inflation. It's a story about goods and services and our ability (or lack thereof) to make more and more of them.

<comment><USER20> Yup. And my comment is about when it does and when it does not matter that you make more and more of them. If your society is in fiat credit bubble, then you are doomed into Mad Max Scenario when you slow down the exponential growth (bubble collapses). But if you do not have any bubble in the first place, then slow down is just a slow down. People make less people, consume less, wait for better days, "time slows down" so to speak if we are talking about technological progress. No Mad Max scenario at all.

<comment><USER21> No. That is wrong.

People are much happier and get along much better with everyone else when they expect tomorrow to be better than yesterday.</comment></comment></comment></comment>


Altered Image MasterChef - <AUTHOR> http://tv.yahoo.com/blog/sharpeyed-viewers-catch-master-chef-faking-a-huge-crowd--3229

<comment><USER2> Between this and the CG Japanese popstar it looks like we won't be able to trust video any more than we trust digital photos now.</comment>


A type of semi-transparent polymer that can be mended at room temperature - <AUTHOR> https://phys.org/news/2017-12-semi-transparent-polymer-room-temperature-small.html <comment><USER2> I'm thinking that if you can stick things that people commonly carry around together just by pressing them against each other that this opens up a whole new area of drunken antics

</comment><comment><USER3> This is a better link IMO: [https://phys.org/news/2017-12-semi-transparent- polymer-room-...](https://phys.org/news/2017-12-semi-transparent-polymer-room- temperature-small.html)

And here's the actual paper all the articles are about: [http://science.sciencemag.org/content/early/2017/12/13/scien...](http://science.sciencemag.org/content/early/2017/12/13/science.aam7588.full)

<comment><USER4> Ok, we've changed to that first link from [http://www.enca.com/technology/japanese-inventor-shatters- ex...](http://www.enca.com/technology/japanese-inventor-shatters-expectations- with-self-healing-glass). Thanks!

</comment></comment><comment><USER5> Somebody had fun with that headline.

</comment><comment><USER6> > _The organic glass, made of a substance called polyether thioureas, is > closer to acrylic than mineral glass_

Plastic is organic glass?

<comment><USER7> If it's non crystalline then yes, glass is defined as a non crystalline amorphous solid and there are more than a handful of plastics that fall into that category.

<comment><USER8> What is the distinction between amorphous and non-crystalline? Also, for instance, aren't all solid metals amorphous non crystalline solids?

<comment><USER7> Someone has already answered, most metals are crystalline, the metallic alloys that aren't are actually called metallic glass, there aren't many of them and they were first produced in the 50's or 60's.

But for all intents and purposes nearly all commonly used metals and alloys are crystalline, metallography is pretty much the study of the different types of crystalline structures that any given metal or alloy can have.

Each metal can also have multiple crystalline structures this is how you give different properties to the same metal or alloy, this most usually achieved through heat treating, quenching and tempering, or alternatively metals that cannot be heat treated are often work hardened or "cold formed".</comment></comment></comment></comment>


[NSFW] Maximizing Your Slut Impact: An Overly Analytical Guide to Camgirling - <AUTHOR> https://knowingless.com/2018/11/19/maximizing-your-slut-impact-an-overly-analytical-guide-to-camgirling/ <comment><USER2>
      Camgirls tend to drink a lot. Drinking
      is another common thing to tip for,
      and it makes camming easier. My friend
      once told me that she used to get on
      cam, black out, and wake up every
      morning with a thousand dollars.

Gee. Let's all stop and think about that one for a moment.

I mean really. Just pause for a second.

</comment><comment><USER3> Interesting data point on "worth" of beauty. In estimating your earning potential...

 _If, on the traditional 1-10 beauty scale, you're:

1-2, multiply X by 0.3

3-4, multiply X by 0.8

5-6, multiply X by 2.5

7-8, multiply X by 4.5

9-10, multiply X by 8_

And...

 _None of this applies if you appear male. If you appear male, god help you._

In who are these men?

 _There's different types, obviously, but the most common tipper is single /divorced/unhappily married man in his 40s-50s, who is too depressed/anxious/unattractive to be able to get any affection from women in real life._

</comment><comment><USER4> Good to see actionable and realistic advice for women posted on HN.

<comment><USER5> What is wrong with you?

<comment><USER6> Let's be charitable and assume that it was sarcasm.

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


Gadget: A smallish web framework for Go - <AUTHOR> http://redneckbeard.github.io/gadget/

<comment><USER3> As a fan of Flask/Bottle/Sinatra/Express style web frameworks I miss a Go framework that works in a similar fashion. Don't know of any better way to prototype APIs so quickly and with such a small mental effort.

Edit: Just discovered [Martini]([https://github.com/codegangsta/martini](https://github.com/codegangsta/martini)), that's exactly what I wanted.

<comment><USER4> Have you seen Martini?

[https://github.com/codegangsta/martini](https://github.com/codegangsta/martini)

<comment><USER5> I'm kind of amazed at the SLOC, ~600 lines for the whole thing. Flask is much bigger and depends on Werkzeug (~20K?), heck even Bottle doesn't come in under 1,000 lines. That is incredibly attractive.

<comment><USER4> Yup I plan to keep it that way too. I believe there is enough flexibility in Martini to cultivate some great functionality around the martini-contrib repo. There is already some pretty awesome things landing there [https://github.com/codegangsta/martini- contrib](https://github.com/codegangsta/martini-contrib)

</comment></comment></comment></comment><comment><USER6> Unlike Revel, you don't seem to have watch setup for .go files, which make sense since you want to keep it smallish. Curious on how other gopher trigger app restart from their editor of choice. Anyone have insight for setting up VIM+Tmux for Golang development that enable app restart from single key press? Sample .vimrc will be great.

<comment><AUTHOR> Recompiling and restarting the server has yet to become a bottleneck in development for me, or at least it hasn't caused enough friction or irritation to compel me to add something using fsnotify or other solutions. If you told me that you were very interested in using the framework but the lack of this feature was a barrier to adoption, I'd definitely think harder about it.

<comment><USER7> I write plain handlefuncs, but so far I have a pretty easy to remember command to restart the server for local development (works as well in Acme, where I'm writing most of my go code as in emacs, where I write templates and vim, where I usually just make really quick edits.) It's Cmd-Tab C-c [up] enter.

Just trying to express the same redneckbeard said: until it is a very thin bottleneck, this should be no problem.

</comment></comment></comment><comment><USER8> I would love to hear why I would want something like this, or revel, or goweb, over: angular.js + Go web-service (net/http + Gorilla).

<comment><AUTHOR> I just don't understand the argument that we should all just use HandlerFuncs for everything. Python and Ruby have stdlib HTTP facilities that are pretty good. They aren't nearly as nice as net/http, but you could totally build websites with them. People still have written lots of web frameworks, because it makes their lives easier. It lets them express programs in a simpler, higher-level way. I feel like this is even more valid now in 2013 since nearly anyone who's building websites has done so with one of those high-level frameworks, and they expect a similar experience.

Lots of people have abandoned Rails for Sinatra, or Django for Flask. That's totally cool, and there are good reasons to do so. There are also very good and obvious reasons to use something that further abstractions common patterns if the software you are building conforms reasonably well to those patterns.

<comment><USER8> _> feel like this is even more valid now in 2013 since nearly anyone who's building websites has done so with one of those high-level frameworks, and they expect a similar experience._

But in 2013 do I really want to use server side HTML tempalating? Why not just connect a webservice to a HTML/JS presentation layer like I am suggesting? If all you are doing is building a webservice then the abstractions beyond net/http + Gorilla are not buying you much IMHO, but they do come at quite a performance cost: [http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=json&l=cn4)

My first couple Go web applications did things the html/template way and were structured on the way I used to go JSF applications- but since I switched to the above approach my projects have been better performing, faster to develop , better scaling and easier to maintain. As we all know, we seldom get all those things in one technology choice without trade-offs.

<comment> grey-area _But in 2013 do I really want to use server side HTML tempalating?_

Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser).

I don't agree doing rendering server-side necessarily means a significant performance cost, or is harder to maintain or slower to develop, why do you think that is the case? Caching and a server-side framework can make things far faster and easier, depending on what you are doing, and raw speed of rendering is not often an issue nowadays anyway.

I'm not sure what the test you pointed to there was showing, because using Go to output json could be done with a framework too by just bypassing the framework, in _exactly_ the same way. It hardly seems a relevant test, and there were other issues in those tests when I looked at them previously - <USER2> comparing wildcard routes in one test to hard coded ones in another. Comparing bare JSON production with go to JSON production with webgo (do people use webgo?) is hardly very useful or a fair comparison. It would be trivial to make those equal in speed and I suspect the diff will just be down to different routing and/or template rendering. In addition, I don't want clients to see JSON, so the rendering speed of that is pretty irrelevant, what matters to most people is when html finishes rendering.

It would be interesting to hear the reasons behind the string of assertions in your penultimate sentence, are you sure all types of app would benefit equally from your approach? Can you describe the advantages as you see them to this approach?

<comment><USER8> _> It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar_

This is how bad implementations look to users, consider something like Gmail as a counter example however...

 _> would be interesting to hear the reasons behind the string of assertions in your penultimate sentence_

Sure:)

 _> are you sure all types of app would benefit equally from your approach?_

Of course I am not, I didn't make a that claim. I _think_ most typical applications benefit, it has worked well for me. I was asking questions to understand the point of view I don't hold-

 _> Can you describe the advantages as you see them to this approach?_

      In this approach:
      Performance:
        1. Most assets are (server side) static
        2. They are pre-gzipped and stored in memory using a little reusable code I wrote.
        3. They are extremely cache friendly
      Better scaling:
        1. Only a fraction of the previous work happens server side... You using your users compute power.
        2. You are transfering less data.
      Faster to develop/easier to maintain:
        1. This way you have two differnt apps that happen to talk to eachother. This makes it easy to replace one or the other.
        2. Responsibilities are clearly defined. This makes brining new people up to speed easier and makes thingse asier to test, debug, etc.

<comment> grey-area Thanks for the comments, it'd be easier to read if they weren't styled using pre!

 _Of course I am not, I didn 't make a that claim._

Sorry, I should have phrased that differently as something like - _perhaps not all types of app would benefit equally?_ I wasn't trying to put words in your mouth. I do think it's a little early to start asking why anyone would use server-side logic any more, there is room for both approaches :)

Perhaps if you are serving data which is text-only, static and fits well into json as you describe, and don't mind coding in Javascript, client-side is a better fit. If you have a lot of server-side data and editing/auth requirements (more of a CMS), and depend on heavily nested templates etc, server-side may be a better fit, though I'm sure it's possible to handle every type of website in theory using either system. There is also the question of which language you prefer to work in - personally I'd rather keep JS use to a minimum, as it's pretty gnarly.

Re the separation of concerns, yes this is a valid point and is something you gain from serving an API if you have a complex system, though it is possible to have a back-end behind a traditional web framework too, with one side being the API serving json or whatever and a separate user-facing service serving HTML.

I don't think speed or caching are a big problem with server-side frameworks nowadays though, and I'd rather use a language like Go than JS to produce web apps. Out of curiosity, which client-side frameworks are you using?

<comment><USER8> I think we agree more than we disagree. Maybe we just differ on which approach is our default one. I dislike JS as well and will be switching to Dart on the front end when I feel it is ready.

 _> though it is possible to have a back-end behind a traditional web framework too._

Sure I think you get a lot of the maintainability pro's this way, but loose on some of the performance ones.

I mostly write systems software (in Go), but when I write webapps I use angular.js (frontend) + Go (backend) + One of many datastores (ex MySQL, Postgre, LevelDB etc)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> As a "non programmer" this excites me greatly. I learned Python by way of Django and can't wait to stand on some Go giant shoulders.

</comment><comment> re-l Damn, routers and controllers are not an issue in Go, models — is. I belive, that rich middleware between rich backend and rich client does matter. It isn't manipulating with html views, it's working with data. It's a proxy layer. And unfortunately, I don't see it in the modern Go web frameworks. Anyway, it's a great job.

<comment><USER10> You could easily use something like gorp ([https://github.com/coopernurse/gorp](https://github.com/coopernurse/gorp)) alongside Gadget (or any other Go web framework). Like Flask, the use of SQLAlchemy isn't innately tied to the framework.

</comment></comment><comment><USER11> Looks smart! Curiously, any reason you chose not to use Revel?

<comment><USER12> Or martini? I liked the look of martini but have not delved deep enough to make an informed decision. Might pick Go for my next side project...

<comment> saiko-chriskun Just came back from a go meetup where I met the developer of martini actually, I think it's a really well thought-out framework :)

</comment></comment></comment><comment><USER13> This is an irrelevant comment but I love the name. I'm assuming it's a play on the Go-Go-Gadget line?</comment>


Instant.io - Massive Google Translate (built in 8 hours) - <AUTHOR> http://instant.io/

<comment><USER2> As seen in Firebug : jQuery15106557239134263726_1305644071940({ "error": { "errors": [ { "domain": "usageLimits", "reason": "dailyLimitExceeded", "message": "Daily Limit Exceeded" } ], "code": 403, "message": "Daily Limit Exceeded" } } );

</comment><comment><USER3> What does it do? It just sticks my text on a US flag. With mentions of scrolling in the comments, I am certainly missing something. Will leave open for 8 hours and see if situation improves.

</comment><comment><USER4> What's with the constant reminder that it was "built in 8 hours"? Is that to warn me that it's really buggy or are you trying to impress me?

</comment><comment><USER5> It would be good if the user could control the scrolling. I can't read the page because it keeps scrolling to the bottom to show me new translations.

Also copy and paste is broken.

</comment><comment><USER6> flag

</comment><comment><USER7> >I launched 3 sites recently (Instant.fm, Instant.IO, and >EmuSpin) (feross.org) > 2 points by feross 1 hour ago | flag | discuss

we got it the first time, stop treating hn as your blog</comment>


Drinking age of 21 doesn't work - <AUTHOR> http://www.cnn.com/2009/POLITICS/09/16/mccardell.lower.drinking.age/index.html

<comment><USER2> Not hacker news certainly?</comment>


Misconceptions About iOS Multitasking - <AUTHOR> http://speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html <comment><USER5> > You may think that, if an app is resident in memory, you have to somehow > remove it to conserve memory. You don't because iOS does it for you. If > there are Suspended apps lying around and you launch a memory-intensive app > such as a big game, iOS will start to purge Suspended apps and move them to > the Not Running state. That is, they will be completely removed from memory > and will launch afresh the next time you tap their icon.

This, however, is not "impact-less": when running truly memory-intensive games, they _will_ experience performance degradation while the OS performs cleanup and shutdown of the various applications "hibernating". This is sensible on games like Infinity Blade.

iOS also suffers from not allowing the user to make a distinction between "not running or hibernating" (no resource consumption) and "keeps your GPS or data connection active" (very high battery drain), and not providing a way for the user to know which application requested what (in the way the "Notification" settings let you control notifications rights for all applications, or iOS5's new "General > Usage" gives you a size estimate for the system's applications).

I also believe this:

> 5\. Five classes of apps - audio, GPS, VOIP, Newsstand and accessory apps - > and some built-in apps such as Mail may run indefinitely in the background > until they complete their task.

is partially incorrect in following 4.: these applications can all be killed as memory pressure on the system increases, however they have a "higher priority" (and thus will be killed last) compared to suspended applications.

<comment><USER6> True. However I should point out that cleanup and shutdown is pretty minimal: it's killed without warning. (I don't know if you even get a signal handler called.) A hibernating app is not allowed to execute any code.

<comment><USER7> This only happens when memory has become critical and not enough applications can free memory fast enough; initially, applications get a low-memory warning and they have an opportunity to deallocate things they are not using in the hope that the system will not have to kill processes. This includes things the developer may not even have explicitly coded, such as dumping video surfaces and sqlite caches.

I'm willing to believe (as I have never specifically tested this) that suspended third-party from-the-App-Store ("User") applications are immediately killed without this first stage (although then it would seem weird that they participate in the cross-application memory warning system at all), but the default Apple-provided ("System") applications (such as Safari, Mail, etc.) definitely get this opportunity.

<comment><USER5> > I'm willing to believe (as I have never specifically tested this) that > suspended third-party from-the-App-Store ("User") applications are > immediately killed without this first stage (although then it would seem > weird that they participate in the cross-application memory warning system > at all)

According to the iOS Application Programming Guide[0],

> Suspended apps are not notified of termination but f your app is currently > running in the background state (and not suspended), the system calls the > applicationWillTerminate: method of your app delegate.

(this is the iOS5 doc, but the iOS 4 version essentially said the same thing)

So a suspended app is killed immediately, a running (backgrounded) app gets the standard applicationWillTerminate: message.

[0] [http://developer.apple.com/library/ios/#documentation/iPhone...](http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW49)

<comment><USER8> I guess the logic behind that decision is that unsuspending an app and allowing it to run arbitrary code while the system is in a low memory condition will take memory.

Because of that, the likely effect of informing swapped-out processes that they will be killed is an avalanche of suspend/unsuspend events, resulting in an unresponsive sytem, similar to the effect of VM trashing.

<comment><USER5> > I guess the logic behind that decision is that unsuspending an app and > allowing it to run arbitrary code while the system is in a low memory > condition will take memory.

Even more so as a suspended application already got a message indicating that it was suspended, so it already had the opportunity to perform operations it needs to perform (mostly persisting state).

> Because of that, the likely effect of informing swapped-out processes

iOS does not swap, the VM only ever uses real memory, suspended processes live fully in real memory.

</comment></comment></comment></comment></comment></comment><comment><USER9> Steve Jobs email addressed this in an email: [http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multita...](http://macdailynews.com/2010/06/29/steve_jobs_on_ios_multitasking_just_use_it_as_designed_and_youll_be_happy/)

"People shouldn't have to understand multitasking. Just use is [sic] as designed, and you'll be happy. No need to ever quit apps." – Steve Jobs' email, June 29, 2010

another email too: <http://forums.macrumors.com/showthread.php?t=955236>

regarding quitting apps to save battery life: "You don't need to do that to save battery life. Trust the iPhone."

<comment><USER10> Which makes it all the more infuriating that Geniuses are telling people to clear that stuff out. A directive needs to come from on high to stop that.

<comment><USER11> Indeed. I took my iPad in because it kept losing its wifi connection. The "genius" looked at all that apps along the bottom and declared that they were using so much memory that the OS was forgetting the wifi password.

<comment><USER12> That's just weird. There's no supported way to tell what apps are actually in memory. The list in the bottom when you double-click the home button just shows all recently used apps, even if they've been purged.

</comment></comment></comment></comment><comment><USER13> Isn't the exact same principle true of Android, with the slight distinction being that any app can multitask, not just the 5 classes of apps? Android may also kill any app whenever it wants (and prior to 2.1 or 2.2 actually did that very often, requiring always on apps to have ongoing notifications). It's just not as strict as the iOS scheduler.

<comment><USER14> Android has applications and services, services are application dedicated to running in the background. Android also provides a list of these services (Settings -> Applications -> Running Services). Normal applications, in regards to background computation, are handled in a similar way to iOS.

<comment><USER15> Also, Android opens all of this information up for developers via apis, so you can only imagine the plethora of great task managers available...

</comment></comment></comment><comment><USER16> This is a really well written article and does a great job explaining backgrounding on iOS.

Unfortunately, I've seen a couple of apps that have somehow been able to abuse the background APIs and have killed my battery. The only way to prevent this from happening is to force quit the app from the multitasking bar. The app I've noticed this with is GroupMe. If I don't kill it after closing it, my phone gets really hot and my battery dies. I have location turned off for GroupMe.

</comment><comment><USER17> I really wish the article explicitly explained exactly what happens when you manually manage the multitasking bar. My anecdotal experience is that removing an app from "recently used" does have the effect of terminating it if it was in one of the semi-background states.

While the advice to manually manage this is ham-fisted troubleshooting, it is unfortunately effective (cf. restarting Windows). I suspect (and would love to see more analysis on this) that some apps in the categories allowed infinite background time are behaving badly. It may only be one VOIP app running persistently in the background that drains the battery, but this advice would consequently solve that problem.

<comment><USER16> yes if you kill it from the multitasking bar it completely kills the process and the next time the app launches, it is from scratch. That is why force killing an app and restarting it will often fix little glitches in it.

</comment></comment><comment><USER18> Is there a tool that lets you trigger some of these state changes (Suspended -> Killed, for example) for debugging/testing purposes? Trying to get the OS to forcibly kill an app due to memory pressure is something I've had trouble doing on Android and seems like it could be a problem on iOS also.

<comment><USER19> The simulator can simulate a low-memory warning. To simulate an app being killed, just kill the app from Xcode.

<comment><USER20> The key word there is simulate. There are cases (see my response) that arise that purposely triggering these state changes could really help with.

<comment><USER21> You could try to write a very simple app to run in background and waste memory on purpose (e.g. creating some shit in a loop) if you really needda replicate such a scenario w/o emulation. In my experience, as usually you can get away with ~30mb of "wasted" memory per each instance before iOS kills the daemon. So just launch a couple of those and enjoy.

</comment></comment></comment></comment><comment><USER22> The skype app will run indefinitely in the background, killing your battery much sooner than normal. Killing it from the multi-tasking list does prevent this. It is the only app that I am aware of where this makes any difference.

<comment><USER23> That's because it's a VoiP app - which was listed in the article as being one of the classes of apps allowed to run in the background indefinitely.

Skype is not unique. All VoiP-declared (has to register itself as such and Apple has to approve that classification for publishing on the App Store) apps act like this.

</comment></comment><comment><USER24> I certainly wish iOS managed backgrounded apps _better_ than the article purports it to. If you have a handful of applications suspended, and you're using MobileSafari, why does the application dump tabs that you're actively switching between before the OS dumps suspended apps? You're creating memory pressure in a _foreground app_ and should therefore be given priority. That's sort of where this thing falls apart: "iOS does it perfectly. Don't argue it." except when it does not.

</comment><comment><USER25> My only exception to this rule is with the memory.

Safari uses avaliable memory for caching web pages in tabs, which is understandably at a low priority. I often find that iOS will give priority to 'suspended' apps rather than 'suspended' tabs.

In order to get safari to stop upnloading the tabs you need to free up memory manually.

This however is an edge case.

</comment><comment><USER26> Well, however, the 'killing the app manually' is useful while you're testing your app. We had a situation where the app is not the culprit but a middle- layer that authenticates through Facebook. As we've not yet taken care of the middle-layer failure, our iOS app was unable to figure out what to do but sent us in a Limbo.

Killing it manually help us 're-start' the app so we can use it without doing the 'un-install' and 'install' all over again.

Outlined in an article I wrote recently - <http://brajeshwar.com/2011/kill-a- background-app-in-ios/>

</comment><comment><USER27> This article is at least disingenuous and probably flat out wrong. As many have pointed out, "running" apps are not impact-less. The author says as much himself. The author also acknowledges that being "well-written" matters which we of course know is not always the case. The author oddly brushes off the impact of long running background apps. And simply wrong is the contention that the multitasking bar is merely recently used apps.

</comment><comment><USER28> I'm fairly certain that if I run "Words With Friends" once, if I don't kill it after I'm done, it will kill my battery roughly twice as quickly as normal. Has anyone else seen this, or am I simply wrong?

</comment><comment><USER29> Does continual, and/or static, RAM usage/storage not effect battery life? I know it would be minimal, but I imagine it would be potentially noticeable.

<comment><USER30> RAM doesn't use more or less power depending on whether or not it's been allocated to an application, so by itself continual/static RAM usage doesn't effect battery life at all. Now, if the OS needs to remove a suspended application from memory in order to free up RAM for a foreground application, that will involve the processor and so use some power, although I would imagine a small amount. If a suspended application is removed from memory and then needs to be restarted when it is next used, that will also use the processor (and the flash storage), which will require power. So leaving memory allocated for suspended apps can have an effect of battery life, although not directly because of the memory itself using power.

</comment></comment><comment><USER31> You can write a audio, GPS, VOIP, etc app that does more than just do audio, GPS, VOIP, etc in the background. For example, you may think the app is only playing audio or doing GPS updates, but it can be badly-written and updating UI and/or other intense stuff. Now granted, iOS will still kill those apps if they start taking up too much memory/resources while in the background.

But I think the article is accurate, you shouldn't ever have to manage apps. iOS is night and day compared to Android's task management (where iOS is much better for users).

</comment><comment><USER32> I miss Symbian :(

</comment><comment><USER33> Not exactly true - for example I can force-quit apps using the multitasking bar.

</comment><comment><USER34> If something is leaky, it's worth force killing it then, right?

</comment><comment> buff-a _There is one iOS "tip" that I keep hearing and it is wrong._

I've never heard this "tip" from anyone. Ever. Any links or references to these "supposedly authoritative sources"?

I'm finding it hard to take this article seriously when it says:

"When you press the home button, iOS will tell the app to quit. In almost all cases, it quits..."

Then, a few paragraphs later:

"When you press the home button, the app moves from Active to Background. Most apps usually then go from Background to Suspended in a matter of seconds."

Wait, I thought you said it gets told to quit?

According to this [1], an app has to specifically request to be killed when the home button is pressed. "When the value of this key is YES, the application is terminated and purged from memory instead of moved to the background. If this key is not present, or is set to NO, the application moves to the background as usual."

The information in the article about states is useful, but why open with factually incorrect information?

[1] [http://developer.apple.com/library/IOs/#documentation/Genera...](http://developer.apple.com/library/IOs/#documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html)

<comment><USER35> Really? Really?!

It's correct. In almost all cases when you press the home button the app quits (i.e. gets suspended). End of story.

<comment> buff-a Yes, this definition of "quits" as "gets suspended" is what I have a problem with. "Quits" used to mean "terminates". I guess in the new apple world, especially given what happens on Lion, "quits" doesn't mean what I think it does.

<comment><USER35> We are not interested in meanings here, we are interested in consequences. When it comes to battery life and slowing the OS down, quitting and suspending have exactly the same consequences: both don't do it.

You are making a distinction without a difference that's not relevant for what the article is talking about.

</comment></comment></comment></comment><comment><USER36> While the article may be accurate in "theory" - I can say that my iPhone 4 got significantly better battery life when I was careful to kill all but the currently running application. I think the issue is that some of the apps that I was running may have been abusing the "background" feature, and so switching to home didn't kill them - as evidenced by how hot my iPhone would get while on the home screen - which results in a pretty trivial stimuli/response strategy: If you have been on the home screen for 15+ minutes, and your iPhone is hot - either Reboot it or simply close down the "background/running" apps. Note - that lacking the built-in tools that the droid has to track things like CPU/Memory usage (and, in ICS - Battery Usage) - we have to resort to things like "Is my iPhone acting Slow? Is it Hot? "

If I've been using my iPhone for a few days, and there are a zillion apps in the "Recently Used" bar, I simply reboot the iPhone - may take a couple minutes, but requires no effort as compared to playing whack-a-mole with the Launch Bar.

<comment><USER37> I'm sorry, but this "accurate in theory" junk needs to stop, it's this sort of meaningless reliance on inaccurate anecdotal accounts that allows the misinformation that the article talks about to spread.

The article specifically points out that iOS doesn't allow apps to "abuse" background processing; you get 10 minutes and then the OS forces your app to standby. If an app uses the indefinite background processing for something other than what's permitted, then the app is rejected from the App Store, and they're very strict on this one.

The Android/ICS model you talk about is exactly the kind of process management that Apple specifically avoided in iOS, and for good reason. IMO, that's the exact sort of thing that I'd never want to do on my smartphone.

Your routine may keep you happy, but please don't respond to a well-researched and accurate article with the exact opposite of the truth; you're basically just plugging your ears and shouting "NUH-UH!" here.

<comment><USER36> I can't argue with the theory presented in the article - and I read it very, very carefully. All I can do is present the reality, and demonstrate it conflicts with the theory.

The reality is that certain apps on IOS can continue to run in the background - whether that's because they are polling the GPS radio, waiting for a VOIP connection, or something else - I don't know. All I know, (And I'm speaking here as an owner of the Original iPhone, 3G, 3GS, 4, 4S who uses his iPhone multiple times, every waking hour) is that sometimes the iPhone gets hot, and the battery starts moving to 0 from a full charge in a matter of hours - <USER2> it does this, if I either (A) Reboot the iPhone or (B) shut down all of the apps listed in the "Recently used" task bar, then my iPhone is (1) No longer hot, and (2) experiences normal battery drain.

I reference the Android/ICS model because at least in _that_ world (and remember - I'm a dedicated apple users) I could tell you which of the Apps was actually sucking my battery dry.

If this were science, then it would be useful to collect a large number of observations that conflicted with accepted theory, to determine if (A) there was measurement error on the part of the observer - for example, perhaps I didn't wait 10 minutes after hitting the home button before waiting for the iPhone to cool down, or (B) There is a problem with the theory.

My belief is that it's (C) The theory is accurate, it just doesn't recognize that Apps will sometimes run in the background using more CPU than the user is aware they are, or wants them to. I just wish I had a tool to tell me _which_ app it was - then I could just shut down that _single_ app, instead of my existing reboot/shut-them-all-down approach.

<comment><USER38> > I can't argue with the theory presented in the article - and I read it very, > very carefully. All I can do is present the reality, and demonstrate it > conflicts with the theory.

This article is not, repeat _NOT_ , presenting "theory". This article describes the way iOS is actually built to work -- it is a factual description of all and only those behaviors that iOS engages in. It is a complete, and accurate, description of iOS's behavior because it is a recapitulation of the behaviors that iOS's designers built it to exhibit.

The only contrast here is between the reality of the way iOS works (the article) and your misunderstandings of reality.

<comment><USER36> My understanding of reality is pretty straightforward - "Over the last 3-4 years, I normally get 36-48 hours of casual use out of my iPhone, or 24 hours of really aggressive use, but, for some reason, on some days, while my iPhone is at the home screen, it is really hot and the battery is draining to zero quickly. Shutting down all of the apps in the task bar, or, rebooting the iPhone, immediately fixes that."

Couldn't we allow for the possibility of a bug in IOS that results in a deviation from the behavior explained in the article? Or, more likely, an application that is using IOS as designed, but in a way that results in extended background processing and CPU drain?

The good news is that another contributor posted a link to "Instruments" - which should let me get a diagnostic trace off my iPhone and determine which of the apps is actually pulling down the battery. I then have the options of (A) figuring out if there is a pref in that App to cause it to stop using battery when backgrounded, (B) Contact the application writer and let them know they have a poorly behaving App, and (C) (most important for me) - <USER3> the number of applications I need to shut down to just the misbehaving ones.

Until then - count me in that category of users who believes (through experience) that the advice the Apple Geniuses are giving, that is, to terminate applications when you have an iPhone that is performing differently than when it is initially booted up, is good advice and is a real-world fix to this class of problem. (Though rebooting your iPhone accomplishes the same thing in my experience as well)

<comment><USER38> > Couldn't we allow for the possibility of a bug in IOS that results in a > deviation from the behavior explained in the article?

No, because there is absolutely no reason to believe this is the case and no one has ever observed a non-privleged app store approved app outliving its OS- mandated termination deadlines.

> Or, more likely, an application that is using IOS as designed, but in a way > that results in extended background processing and CPU drain?

ie) there's a bug in a background process that causes it to eat CPU? Yes, this is what you are actually experiencing, and this is 100% compatible with the facts presented in this article. Accepting this means you've entirely moved away from your previous "theory vs reality" nonsense.

> Until then - count me in that category of users who believes (through > experience) that the advice the Apple Geniuses are giving, that is, to > terminate applications when you have an iPhone that is performing > differently than when it is initially booted up, is good advice and is a > real-world fix to this class of problem. (Though rebooting your iPhone > accomplishes the same thing in my experience as well)

Indeed rebooting your phone will terminate all processes running on the phone. This should be pretty obvious. Clearing out a list of previously run applications willy nilly is, on the other hand, superstitious hokum. You need to specifically target only those apps with infinite background privileges, which are few and far between.

<comment><USER36> Okay - I yield msbarnett. You win.

What is your guidance when my iPhone is in battery-draining/Hot mode while at the home screen and I need to fix it? If I'm engaging in superstitious hokum by terminating all the apps in the MRU/Multi-Tasking bar, what is your advice to fixing my problem? Keep in mind, that if I've been only using the iPhone for a day or so since I last killed/removed all the apps - <USER4> everything in the MRU bar takes about 30 seconds versus a minute or so for a reboot.

Thanks for taking time to provide your insight on this topic - I'm looking forward (honestly) to your advice.

<comment><USER38> I'd identify the particular app that's causing your issues; instead of mass clearing out the recents list, or rebooting, slowly signal to the OS that you're done with each app, one at a time, and determine whether your phone continues to run hot and drain battery after each closure.

Eventually you'll narrow it down to the app with background privileges that's causing you grief.

Kick that app off your phone, or otherwise stop running it. If you can't live without it, then the next time your battery life goes to hell, go into the recents list and remove only the troublesome app in question, so that the OS knows you're done with it and kills its (presumably crashed or busy-looping) background thread.

Desist worrying about how many apps are in your recents list in general, because that's not a really related to the underlying problems you're experiencing.

<comment><USER36> Yes - I've tried that a number of times - the problem is you always _think_ you got the right app, but you are never 100% certain. And you are always worried that you just happened to have shut down an App, at the same time that the poorly behaving background app decided to Idle a bit.

Better solution will be for Apple to just tell us how much power each of the running apps have used in the last 1,5,10 minutes.

I agree 100% that the user _shouldn't_ have to worry about that, but when they do, it's annoying that it's so difficult to track down the problem.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Disclose All Facebook Private Primary E-mail Addresses - <AUTHOR> https://www.youtube.com/watch?v=RkRKTH7fXqQ <comment><USER2> As someone on the receiving side of bug bounty reports, PoC videos are usually the worst way to go. A clean writeup is 100x better and easier to figure out.

The actual bug here looks to be that the reporter is able to add themselves as an admin to any account via insecure direct object reference (IDOR), after which they can query the users' account information. Good find and worth the $5k reward they got for it.

However, publishing a video with them fetching PII data and displaying the data seems grossly irresponsible (and illegal depending on the jurisdiction).</comment>


The Sum of Our Google Fears - <AUTHOR> http://gizmodo.com/5488482/the-sum-of-our-google-fears

<comment><AUTHOR> "Google is a company on steroids" -- Andy Grove

Pretty awesome quotes in 2 minutes and 46 seconds, even though this is somewhat of an "alarmist" video

<comment><USER2> Paul Revere was probably a silly alarmist too.</comment></comment>


Lambda Calculus Interactive Tutorial - <AUTHOR> http://blog.klipse.tech/lambda/2016/07/24/lambda-calculus-2.html <comment><USER2> I really enjoyed _A Tutorial Introduction to Lambda Calculus_ by Raul Rojas. Apparently he released a new version last year: [https://arxiv.org/abs/1503.09060](https://arxiv.org/abs/1503.09060)

<comment><USER3> Oh wow, I printed an older version and have been reading it during my commutes for past few days. So happy that there's a newer version.

</comment></comment><comment><USER4> I'm probably showing my profound ignorance, but what has lambda calculus done for me lately? It seems to be an abstract formalism of some sort, but I've yet to see any real use of it, the examples are baby step type stuff with obfuscated syntax.

CS seems overburdened with jargon and trendy crap (IMO) so is this just the latest thing coming down the pike that everyone needs to give lip service to in order to seem smart to their peers?

<comment><USER5> Here is how you can use the lambda calculus to compute factorials in non- geological time:

[http://www.flownet.com/ron/lambda- calculus.html](http://www.flownet.com/ron/lambda-calculus.html)

<comment><USER4> OMG, that's insane (in a bad way). Stacks exploding, hours of optimization, all for a simple factorial (toy problem). Exciting I suppose for a few souls in academia who spend their lives writing papers about theoretical stuff (not that there's anything wrong with that).

<comment><USER5> Oh dear, I have failed. The whole point of that paper was _supposed_ to be that all this theory stuff actually has practical applications. The same techniques that worked on that toy problem can be used on real problems and produce similar results.

I did some follow-up work after that paper to implement binary arithmetic in the lambda calculus, and using that, of course, you can compute "real" factorials. Here it is computing the factorial of 100 in under a second:

      ? (time (pbn (bn_fact (bn 100))))
      (PBN (BN_FACT (BN 100)))
      took 942,269 microseconds (0.942269 seconds) to run.
            64,791 microseconds (0.064791 seconds, 6.88%) of which was spent in GC.
      During that period, and with 4 available CPU cores,
           878,343 microseconds (0.878343 seconds) were spent in user mode
           111,475 microseconds (0.111475 seconds) were spent in system mode
       759,285,088 bytes of memory allocated.
       504 minor page faults, 0 major page faults, 0 swaps.
      93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

This is he expanded code:

      ((λ f ((λ g (g g)) (λ (h x) ((f (h h)) x))))
       (λ f
        (λ n
           (λ nil
              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) n)
                (λ dummy ((λ (l r s) (s l r)) (λ (_t e) _t) (λ s (λ (_t e) _t))))
                (λ dummy
                   (((λ f ((λ g (g g)) (λ (h x) ((f (h h)) x))))
                     (λ f
                        (λ (n1 n2 r)
                           (λ nil
                              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) n1) (λ dummy r)
                                (λ dummy
                                   (f
                                    ((λ (l)
                                        (λ nil
                                           (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                             (λ dummy (λ s (λ (_t e) _t))) (λ dummy ((λ p (p (λ (l r) r))) l)))
                                            (λ x x))))
                                     n1)
                                    ((λ (l r s) (s l r)) (λ (_t e) e) n2)
                                    (((λ (l)
                                         (λ nil
                                            (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                              (λ dummy (λ (_t e) e)) (λ dummy ((λ p (p (λ (l r) l))) l)))
                                             (λ x x))))
                                      n1)
                                     (((λ f ((λ g (g g)) (λ (h x) ((f (h h)) x))))
                                       (λ f
                                          (λ (n1 n2 c)
                                             (λ nil
                                                (((λ (c _t e) (c _t e))
                                                  ((λ (p q) (p q (λ (_t e) e))) ((λ p (p (λ (l r) (λ (_t e) e)))) n1)
                                                   ((λ p (p (λ (l r) (λ (_t e) e)))) n2))
                                                  (λ dummy
                                                     (c ((λ (l r s) (s l r)) (λ (_t e) _t) (λ s (λ (_t e) _t)))
                                                      (λ s (λ (_t e) _t))))
                                                  (λ dummy
                                                     ((λ (l r s) (s l r))
                                                      ((λ (b1 b2 c)
                                                          (b1 (b2 c ((λ c (c (λ (_t e) e) (λ (_t e) _t))) c))
                                                           (b2 ((λ c (c (λ (_t e) e) (λ (_t e) _t))) c) c)))
                                                       ((λ (l)
                                                           (λ nil
                                                              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                (λ dummy (λ (_t e) e)) (λ dummy ((λ p (p (λ (l r) l))) l)))
                                                               (λ x x))))
                                                        n1)
                                                       ((λ (l)
                                                           (λ nil
                                                              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                (λ dummy (λ (_t e) e)) (λ dummy ((λ p (p (λ (l r) l))) l)))
                                                               (λ x x))))
                                                        n2)
                                                       c)
                                                      (f
                                                       ((λ (l)
                                                           (λ nil
                                                              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                (λ dummy (λ s (λ (_t e) _t)))
                                                                (λ dummy ((λ p (p (λ (l r) r))) l)))
                                                               (λ x x))))
                                                        n1)
                                                       ((λ (l)
                                                           (λ nil
                                                              (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                (λ dummy (λ s (λ (_t e) _t)))
                                                                (λ dummy ((λ p (p (λ (l r) r))) l)))
                                                               (λ x x))))
                                                        n2)
                                                       ((λ (b1 b2 c) (b1 (b2 (λ (_t e) _t) c) (b2 c (λ (_t e) e))))
                                                        ((λ (l)
                                                            (λ nil
                                                               (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                 (λ dummy (λ (_t e) e))
                                                                 (λ dummy ((λ p (p (λ (l r) l))) l)))
                                                                (λ x x))))
                                                         n1)
                                                        ((λ (l)
                                                            (λ nil
                                                               (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) l)
                                                                 (λ dummy (λ (_t e) e))
                                                                 (λ dummy ((λ p (p (λ (l r) l))) l)))
                                                                (λ x x))))
                                                         n2)
                                                        c)))))
                                                 (λ x x))))))
                                      n2 r (λ (_t e) e))
                                     r))))
                               (λ x x))))))
                    n
                    (f
                     (((λ f ((λ g (g g)) (λ (h x) ((f (h h)) x))))
                       (λ f
                          (λ n
                             (λ nil
                                (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) (λ (_t e) e)))) n) (λ dummy n)
                                  (λ dummy
                                     (λ nil
                                        (((λ (c _t e) (c _t e)) ((λ p (p (λ (l r) l))) n)
                                          (λ dummy
                                             (((λ p (p (λ (l r) (λ (_t e) e)))) ((λ p (p (λ (l r) r))) n))
                                              (λ s (λ (_t e) _t))
                                              ((λ (l r s) (s l r)) (λ (_t e) e) ((λ p (p (λ (l r) r))) n))))
                                          (λ dummy ((λ (l r s) (s l r)) (λ (_t e) _t) (f ((λ p (p (λ (l r) r))) n)))))
                                         (λ x x)))))
                                 (λ x x))))))
                      n))
                    (λ s (λ (_t e) _t)))))
               (λ x x))))))"

I didn't write that all by hand, of course. I built it up in pieces and my "compiler" assembled it for me. But start to finish that took be about an hour.

<comment><USER4> If we were playing the Hot and Cold game you would be getting colder.

Are you telling me that the most efficient means of generating factorials is via LC? That no other method can touch it in terms of real time?

<comment><USER5> No, of course not. Factorial are just an illustrative example.

My goal was to dispel the myth that the lamdba calculus is nothing more than an intellectual curiosity. It is much, much more than that, not because you can use it to compute factorials, but because the _techniques_ that you use to compute factorials in LC are generally applicable. If you really want to master the craft there are a few things you really need to know how to do: write your own compiler, your own editor, your own implementation of the Hindley-Milner type system. Writing an efficient factorial in LC is like that. It's not useful in and of itself, but for what you learn simply by going through the process.

<comment><USER4> Your initial words were "Here is how you can use the lambda calculus to compute factorials in non-geological time" which led me to believe you were claiming LC was a very (the most?) efficient route to factorial calculation. Which would make me sit up and take notice were that the case.

I'm sorry to say that your factorial example just seems painful and pointless to me, and doesn't encourage me to expand my mind via LC at all.

<comment><USER6> > LC was a very (the most?) efficient route to factorial calculation

It is, because it is a standard model for computation. To put it in layman terms, every programming language is lambda calculus in disguise. You have absolutely no idea of computability theory. That is the theory in which the P=NP conjecture is formulated, which has massive implications e.g. on cryptography.

You seem frustrated for not understanding at all what's going on here and you try to provoke answers. I know what I'm talking about, because I don't grok LC either and I get furious quickly when I'm hungry, tired or overworked. You are paranoid.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> This tutorial is about Boolean Algebra in Lambda Calculus.

Here is the first part of the tutorial (about arithmetics) [http://blog.klipse.tech/lambda/2016/07/24/lambda- calculus-1....](http://blog.klipse.tech/lambda/2016/07/24/lambda- calculus-1.html)

<comment><USER7> I didn't like this tutorial. I don't think that using Lisp clarifies what is going on.

They claim to show how numbers are created in lambda calculus, by defining some lisp functions that call take a function and call it on itself n times (starting from... what?). And then they just use the builtin lisp function "inc" and claim this somehow shows how numbers are represented.

That doesn't make any sense to me. They haven't shown how 45 is represented in lambda calculus. Is it just represented as "inc" called 45 times, starting from the number 0? If so, why is zero special? What is the connection between "inc" and representation of numbers in lambda calculus? I'm a mathematician and this is similar to one way to define integers, so I may be filling in blanks that aren't there.

Then they try to show equality between numbers (which doesn't exactly work "because Lisp") by showing that the two functions generated by this process are equal... of course they are! You started with two numbers which were already equal, this isn't a proof of anything!

Basically this gave me no insight into lambda calculus but I learned a couple of lisp functions.

</comment></comment><comment><USER8> > We are using clojure for the code snippets - as it belongs to the LISP > family, and LISP is founded on top of lambda calculus.

The lambda calculus doesn't have functions of more than one argument, which is itself a variable standing for a lambda term (satisfying additional restrictions, depending on your choice of reduction strategy). If you want functions of more arguments, you need to curry them. If you want arguments to have arbitrary structure, you need to Church-encode them.

The lambda calculus doesn't have macros or any other means to analyze its own syntax. The only thing you can do with a lambda abstraction is apply it. That's precisely why it's called lambda _abstraction_ : you don't get to peek into its internals. Which is why it's a theorem, and not a triviality, that the lambda calculus is as expressive as Turing machines. (As long as you only care about computability, that is.)

The lambda calculus doesn't have pretty-printing. If you want it, it has to be an external facility (say, of the REPL), not a first-class operation internal to the system. Warning: pretty-printing lambda terms can cause psychological trauma.

For obvious reasons, nobody uses the lambda calculus as a serious programming language. But there are several actual implementations floating around the Interwebs. And, if you don't want to use those, implementing the lambda calculus on your own isn't even hard. So, if your goal is to teach the lambda calculus, why not actually implement and actually use the lambda calculus?</comment>