Playing with Docker 1.13 and Minio - <AUTHOR> https://media-glass.es/playing-with-docker-1-13-minio-9b38a36e88b#.pl01otijq <comment><USER2> Before anyone gets excited, know that Minio only _just_ started supporting clusters of multiple machines, and that it is severely limited: "As with Minio in stand-alone mode, distributed Minio has a per tenant limit of minimum 4 and maximum 16 drives"[0].

They built a toy object store while blogging aggressively.

Openstack Swift or Redhat Ceph are still the only real open-source object store players, AFAIK.

[0][http://docs.minio.io/docs/distributed-minio-quickstart- guide](http://docs.minio.io/docs/distributed-minio-quickstart-guide)

<comment><USER3> It's good for using in house storage for things that require S3.

<comment><USER2> I'd use an object store that can scale horizontally, and has. [https://github.com/openstack/swift3](https://github.com/openstack/swift3)

</comment></comment></comment><comment><USER4> __*Medium.com giving me fits and starts trying to post so doing here. CDN issues I am guessing through the GFW of China.

So glad to come across this piece; it is as if you are looking over my shoulder at my to-do list. Started messing with Minio on Docker on Raspberrypi a few days ago testing a setup to implement in my newish business in Shanghai (version 2.0). Still early days but I like what I see.

You continue to produce practical, insightful, germane pieces. Keep up the high quality work. Really appreciate it. Bought your Flocker book last month and plan to start it during Chinese New Year.

Kudos! Be well.

<comment><AUTHOR> I am glad you are finding the posts useful. It is always good to know that someone has a similar to-do list as it confirms that you are at least on the same page as other people :)

</comment></comment><comment><USER5> Does anyone have large (PB-scale) deployments of Minio on premises? We have a need to store hundreds of terabytes of data, and we don't need a filesystem per se, so I was wondering how robust it is.

<comment><USER2> Physically impossible to run a PB-scale Minio cluster: it's limited to 16 hard drives. See my comment above.

<comment><USER5> Good to know. Looks like more of a PR initiative then. Some of my servers have more drives than that. :-)

<comment><USER6> Minio shards data across 16 drives. If you have more drives, you would run multiple instances for each set of 16 drives. I would generally recommend against denser storage servers. When it goes down, all the drives go offline with it.</comment></comment></comment></comment>


How to Save a Dying Language - <AUTHOR> http://www.smithsonianmag.com/innovation/how-to-save-a-dying-language-4143017/?all <comment> guard-of-terra Same way as saving Guinea worm - by housing it inside your body (and mind).

The next question is why would you want to.

</comment><comment><USER2> It's a question on where to spend funds. There are so much more important things to do that will have more impact on our society.

<comment><USER3> Perhaps, but it is foolhardy to discard and forget such a culturally relevant artifact.</comment></comment>


SQLite + Redis hybrid database with threading support (2012) - <AUTHOR> http://thredis.org/?

<comment><USER2> Looks like an interesting abandonware project</comment>


OkCupid Doesn't Care How You Find Love, As Long As You Never Ever Use Firefox - <AUTHOR> http://www.slate.com/blogs/the_slatest/2014/03/31/okcupid_urges_members_to_boycott_firefox_because_of_ceo_s_opposition_to.html

<comment><USER2> Well now, if you really want to stick it to him, you should just disable JavaScript altogether! Brendan Eich created it after all.</comment>


Top Hacker News Submissions by Year: 2009–2015 - <AUTHOR> https://github.com/antontarasenko/smq/blob/master/reports/hackernews-top-submissions-by-year.md <comment><USER2> For those (like me) wondering what became of that P != NP proof. It seems to have generally been discredited (though not yet retracted). Note that I'm just reporting what I found here: [http://www.scottaaronson.com/blog/?p=458](http://www.scottaaronson.com/blog/?p=458)

But I don't keep up with this area, so maybe the status of that work is more contentious than Scott Aaronson makes it appear.

</comment><comment><AUTHOR> Updated: I've added submissions from 2006-2008. Now it includes the entire HN history.

Also, ranking by category: [https://github.com/antontarasenko/smq/blob/master/reports/ha...](https://github.com/antontarasenko/smq/blob/master/reports/hackernews- top-submissions-by-category.md)

<comment><USER3> This is great. It is very cool to see this link in the "way" back in 2007: [https://news.ycombinator.com/item?id=8863](https://news.ycombinator.com/item?id=8863).

</comment></comment><comment><USER4> [http://sivers.org/kimo](http://sivers.org/kimo)

Thank you for letting me re-read "There is no speed limit" by Derek Sivers.

</comment><comment><USER5> If you enjoyed this you might also like Wayback HN, a past project of mine! You can look at top posts by year, month, and day. [http://www.waybackhn.com](http://www.waybackhn.com)

<comment><USER6> This is really useful. I choose random year (month..) and pick the best of these parameters. Some materials are timeless.

</comment></comment><comment><USER7> One thing still bothers me as a techie is that the death of Steve Jobs ranked first, and Dennis Ritchie 8th, I know that Hacker News is about business as it's about tech, but I just think that the contributions of Dennis Ritchie to our modern world compared to Steve Jobs are much bigger, I hope they both rest in peace.

<comment><USER8> It's indisputable that Steve Jobs is more of a household name than Dennis Ritchie, even among techies, it's likely that Jobs and his accomplishments are more well-known. The other thing to consider is that Ritchie lived a fairly full life, reaching the age of 70. Steve Jobs died at 56. More importantly, he died while basically at his peak...Apple had surpassed Exxon to become the world's most valuable company in 2011, and by all accounts, Jobs still had plenty of ideas and initiatives. So there's a special amount of tragedy involved with Jobs.

There are a lot of unsung engineers and scientists who were happy to keep out of the public eye. One of the things that Jobs did well was publicize himself and make his ideas and opinions known -- and undoubtedly, his attitude and drive pushed Apple to success...coincidentally, such a characteristic gets more _notice_...so it shouldn't be a surprise that Jobs's death hits more people.

<comment><USER9> I'm a critic of Jobs, especially his legend, as much as someone respects him. Yet, your comment rings true to my ears. Good summary.

</comment></comment></comment><comment><USER10> "Tim Cook Speaks up" as #1 in 2014.

Slightly related I was talking to some people the other day who are still strongly against gay marriage and want the Supreme Court to go backwards.

I explained to them that the fantastic news is that in 15-20 years, it won't even be called gay marriage, it's just marriage :)

If they still don't like it, we just have to wait until they die and the world will move on without them.

<comment><USER11> Alabama actually has pending legislation right now that finally takes the proper approach to this whole thing.

The state will simply record marriages reported to them. A person can be married to one other person and outside of writing it down the state is no longer involved. They actually cited the state getting involved with marriage licensing a hundred years ago as due to legislative desire to prevent race mixing.

Getting out of the process entirely is the most logical way to say "Enough, there is no debate. Move on."

<comment><USER12> My simplistic understanding of history is that this is how marriage was in the Western world for hundreds of years. Two people just said they agree to marry and the local church would record it. No ring, no ceremony, just two people agreeing.

</comment></comment></comment><comment><USER13> The 2013 "NSA collecting everything you do" entry claims 611 comments and 1,689 points, but the thread linked to only has 1 point and is [dead]: [https://news.ycombinator.com/item?id=6133321](https://news.ycombinator.com/item?id=6133321)

<comment><USER14> Probably supposed to be this link: [https://news.ycombinator.com/item?id=6133349](https://news.ycombinator.com/item?id=6133349)

</comment></comment><comment><USER15> "why the lucky stiff" ...gone, but not forgot.

</comment><comment><USER16> Interesting that a lot of the top rated articles over the year have been political, not strictly (or sometimes even remotely) technical.

<comment><USER17> In casual observation, I've found that to be the case in every submission/comment site I've read (Slashdot, Reddit, HN, etc). The submissions that seem to gather the most comments are always the ones about politics, social drama, and "real-world" news.

<comment><USER18> Just taking a guess here: the really interesting technical submissions might just appeal to the users who are fond of that subset of tech, but the political ones have a broader interest? Or maybe it's that the technical submissions don't really cause the same emotional response (well, barring stuff like Heartbleed, or other serious issues in tech).

<comment><USER17> Definitely both of those.

</comment></comment></comment></comment><comment><USER19> Outlawed by Amazon DRM ( [https://news.ycombinator.com/item?id=4682392](https://news.ycombinator.com/item?id=4682392) ) tells the story of someone having their Kindle remotely wiped by Amazon with no explanation. Someone in the comments claimed to work on the Kindle and said some aspects of the story should not be technically possible.

Was there ever any followup to this mystery?

Either Amazon's explanation, or clarification of what happened on the device?

Some of the stories in the top make perfect sense. Other stories look a little odd in hindsight...

</comment><comment><USER20> Something interesting is that the top score seems to have peaked in 2011 with 4339. No score since then broke 4000 and there were two that didn't break 3000.

One interpretetation is that there's a lot more posting going on and it's hard for a single post to maintain a top spot as well as potential changes to the ranking alogrithm. Another option may be less engaged users. Maybe a mix of both.

<comment><USER21> It's affected by algorithm changes. For example, the software now downweights any story that's 18 hours or older, with the intention of flushing the front page so that the stories with largest inertia don't just sit there.

I doubt it's that users are less engaged. It appears that HN had its most active Sunday ever today in terms of unique visitors. I've been meaning to look at some graphs of number of comments over time because it feels like those have gone up lately, too. If anybody else wants to make them, the data's public...

<comment><USER20> Ah interesting. I was thinking even if the algorithm didn't change the volume could have had a side effect on it. Do you expose the history of the algorithm?

</comment></comment></comment><comment><USER22> Is Hacker News declining in terms of visits?

The voting seemed to peak out in 2012 / 2013\. Not just the top vote, compare all of them.

<comment><USER23> 2012 and 2013 were very sad years apparently and we had to make it clear that you can't do anything to "fix" the net.

</comment></comment><comment><USER24> This is missing dfranke's "How I Hacked Hacker News (with arc security advisory)" which was the top submission in 2009.

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

</comment><comment><USER25> What's funny is how many of them are from, about or feature something from Michael Arrington.

</comment><comment><USER26> More info on the Hacker News BigQuery dataset: [https://news.ycombinator.com/item?id=10440502](https://news.ycombinator.com/item?id=10440502)

</comment><comment><USER27> There seems to be a trend of increasing political posts over time.

</comment><comment><USER28> Notice any other trends while messing with the data?

<comment><AUTHOR> I had, but didn't publish. Any particular topics of interest?

</comment></comment><comment><USER29> Steve Jobs' death, rank 1; Dennis Ritchie's death, rank 18? That's a little sad.

</comment><comment><USER30> Many of em not available.

</comment><comment><USER31> It's arguable if Steve Jobs should get peace

<comment><USER21> Please don't post uncivil and/or unsubstantive comments here.

We detached this subthread from [https://news.ycombinator.com/item?id=11468952](https://news.ycombinator.com/item?id=11468952) and marked it off-topic.

</comment></comment><comment><USER32> Kinda disappointing, really. "Top" clearly doesn't mean best in this case.

<comment><USER15> "Top" rarely means best.</comment></comment>


PHP Sucks, But It Doesn't Matter - <AUTHOR> http://www.codinghorror.com/blog/archives/001119.html

<comment><USER2> One reason PHP is so popular, before 2005 there were four choices:

Java --all frameworks sucked at the time (I had to work on struts, it was painful).

.net --tied to MS world, and the first iterations sucked

php --it was quick and dirty and easy to get started

cgi,perl, python, C++ --required higher level of expertise, and they were hard

php, was the sensible choice for something quick, and the more "primitive" state of the web apps at the time, demanded less from the framework/language being used.

Right now there is much more choices, and Python (Django), and Ruby on Rails can be really quick to get started on, therefore php is loosing it's main advantage, yet Django and Ror are much more sophisticated and maintainable on the long run.

Even Java now has some nimbler frameworks (Wicket, Stripes etc.)

So, right now PHP is a very bad choice to do anything significant, as it lost its advantages over time, yet it is a mess to work with.

But, the main reason we still PHP used so much, is that a lot of sites were build before 2005, and a lot of web devs are used to it, so as a language it will keep its momentum, but at some point it will run out of steam.

It seems that even the newbies now prefer Ror over PHP.

<comment><USER3> There is one more reason PHP is popular, not mentioned often: PHP is an embedded language and is designed to work well with HTTP servers. When you first hear that, you say "ah, go embed any language, then write your mod_x for Apache, what's the problem with it?".

The problem is that it's not that simple. PHP is "embeddable" specifically for markup languages _by design_ , and it was also designed with Apache's modularity in mind (I supppose).

Perhaps Perl could have been a good candidate too, but it missed the train by not shipping the embedding feature in default installations.

Python, or any language that depends on newlines, sucks for embedding in markups.

So, PHP wins the battle because it was created with HTML and HTTP in mind. Could have been better, much better, much-much-much better. Okay. But that doesn't matter for now :)

<comment><USER4> _PHP is "embeddable" specifically for markup languages by design_

Not it is not! No it is not! Sorry to yell, but you're touching on one of my biggest peeves. The syntax that embeds PHP in the SGML family of markup languages was simply tacked on to an arbitrary syntax that vaguely resembles C and Perl. It was never designed.

I wrote a language that actually _was designed_ to embed dynamic strings in static strings. It doesn't get ugly the way PHP does when you embed static strings within dynamic code within your outer static markup. It doesn't look anything like PHP.

<comment><USER3> Well, Bruce, perhaps

 _...The best way to think of BRL is as a Scheme interpreter with an alternative syntax for strings_

is where you should look for reasons of BRL's unpopularity, I think.

Can you tell us please, what is really special about BRL other than it being "Scheme with square brackets"?

<comment><USER4> The define-input syntax makes form handling almost as easy as PHP with register_globals on, while at the same time being as secure as PHP with register_globals off -- the best of both worlds. It's arguably more secure because of how conveniently one can use validator functions.

The sql-repeat syntax with group-beginning? and group-ending? makes sophisticated use of result sets much more accessible than looking behind/ahead a row manually.

Hoisting a function definition you quickly made within a page out to a sitewide definition is fast and easy, so doing something quick-and-dirty doesn't lock you into dirt forever.

And don't underestimate those square brackets. They totally optimize the human "inner loop" of web development. They beat the tar out of <%, %>, and the mess of quotes, backslashes and dots that constantly trip up newbies.

<comment><USER3> I don't underestimate square brackets, in fact I liked them, but i think the main problem is that BRL is Scheme.

If Scheme is not popular among web programmers, there must be a reason behind it, more than one reason, maybe a hundred reasons. But it's a fact. So I think if you are going to bring Scheme/Lisp into the web development market, you (I mean, not you personally, but in general) have to bring 2-3 new killer features along with HTML embedding and the language itself.

I'll try to understand BRL better, but from what you say above, those things don't seem to be really killer features. Even square brackets thing isn't a killer, I think.

</comment></comment></comment></comment></comment></comment><comment><USER5> Apropos, from <http://www.joelonsoftware.com/articles/fog0000000006.html>

"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need. I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive. Michael and I had a good laugh today when we discovered somebody selling a beta crash-reporting product at $5000 for three months that Michael implemented in CityDesk in two days. (And we actually implemented a good part of ours in C++/ATL). And I also guarantee you that our Visual Basic code in CityDesk looks a lot better than most of the code you find written in macho languages like C++, because we're good programmers, and we write comments, and our variable names are well-chosen, and we do things the simple way, not the clever way, and so forth."

</comment><comment><USER6> Solving spaghetti PHP in spaghetti SQL in spaghetti HTML:

1\. Learn how MVC works.

2\. Write a basic MVC framework.

3\. Zip it up, put it aside, and learn Symfony, CodeIgniter, etc.

(Writing your own framework is an incredibly good learning experience.)

Spaghetti code is solved (mostly) by structured organization, ORM, views that simply display data, and the separation of the MVC parts.

</comment><comment><USER7> As a developer, I am frightened by PHP.

I assume that _it is possible to_ write clean, maintainable, secure code in PHP. But if I sat down and tried to write a web app on my own in PHP, what are the odds that I would do it right--particularly w.r.t. security? If I look for tutorials and reference materials that teach secure PHP programming, how do I know which of these documents are written by people who actually know what they're talking about?

And after taking into account all the effort to learn and use good PHP practices, is PHP really more difficult than one of the Perl, Python, or Ruby frameworks?

<comment><USER8> What makes Ruby, Python and Perl more secure than PHP? Frameworks? PHP has plenty of options there.

PHP is popular because of how easy it was to get started and how available it was in every dirt cheap shared hosting plan on the market. Sure, it's not the most elegant language and it does have plenty of issues but quite a few of these are solved with quality planning and the use of quality tools such as CodeIgnitor or CakePHP.

The low barriers to entry are what made PHP popular and the fact that you can code something robust and maintainable are allowing it to sustain.

<comment><USER9> _What makes Ruby, Python and Perl more secure than PHP?_

The fact that those languages don't have "magic_quotes" or "globals_on"?

<comment><USER10> For more than 3 year I've not seen "magic_quotes" or "globals_on" turned on anywhere. As far as I know in php6 there won't be globals option at all.

<comment><USER8> Neither have I. If you care one bit about security, that's the first thing you'll find out about PHP and as you said, they are being eliminated from the php.ini file in php6 and will need to explicitely turned on in your scripts.

</comment></comment></comment></comment></comment><comment><USER11> An excellent statement, as far as it goes.

The question remains, though: for a given application X, to be developed now, what is a better alternative, and why?

</comment><comment><USER12> "PHP Sucks"

Anyone can say this (and usually does).

"But It Doesn't Matter"

Thank you. In any language war, _this_ is the most important thing to say.

<comment><USER13> I don't buy the "it doesn't matter" part. A good language can effect your project's agility by an order of magnitude; and the gap widens exponentially after you've used it long enough to build up some custom libraries/tools.

<comment><USER14> Well, it doesn't really matter. If my competitors want to use inferior tools, that's fine with me.

<comment><USER4> Yeah, but when your partners are using inferior tools, you spend a lot of time waiting. OurDoings integrates with 9 other sites, so this means something to me.

</comment></comment></comment></comment><comment><USER15> This post to be honest is from someone who does not obviously use PHP on a day to day basis.

Why PHP? In the end the quote below summarizes its success,

\-- begin quote -- In many ways, the IETF runs on the beliefs of its participants. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". \-- end quote --

From the "Tao of IETF" <http://www.ietf.org/tao.html>

</comment><comment><USER16> To me, it seems PHP is the Windows of web languages. In many respects it "sucks", can be clunky, and has little to no elegance from a formal perspective, but it's everywhere and everyone knows how to use it. Thence lies its success.

(however, if you're willing to give up lambda's, some of the PHP frameworks like Cake are only mildly unpleasant)

P.S. Also, the author is inaccurate, as many of those functions are only included in certain modules and rarely found in common PHP builds.

<comment><USER17> So... worse is better? :)

<comment><USER16> No, "success" meaning its use is very widespread.

</comment></comment></comment><comment><USER18> The python code in the book Programming Collective Intelligence is aesthetically poor, with unclear naming, bad spacing, errors and some ugly duplication. But it doesn't matter. The algorithms work, the concepts get taught, and you still get to build your own little pageranking search engine in a single chapter.

Same deal with PHP. It seems that PHP gets the job done. (I say this never having coded anything significant in PHP.)

</comment><comment><USER19> In the early days, I can still remember my perl scripts failing with the "Premature end of script header" error. If they would have patched perl to ignore the newline encoding, nobody would have used php. I can imaging lots of newbiews turned down perl because of this error.

Php really is a mess. 20 functions for sorting, settings in php.in (each php installation should react the same way as the other does), etc...

</comment><comment><USER20> Nothing to see here. Religious opinion. Move along.

</comment><comment><USER21> I'm not keen on PHP, but in its defense it is much less headache inducing than perl or as tedious as the Java/.NET world

</comment><comment><USER22> One thing many people seem to forget when discussing PHP is that if PHP vast library of built in functions doesn't do what you need, you don't have to live without, you can just write an extension, recompile, and you're in business. PHP allows you to write important logic in C, giving me yet another reason use it.

</comment><comment><USER23> I once read "PHP takes 'Worse is better' to a new level." That about sums it up for me.

</comment><comment><USER24> _But It Doesn't Matter_

It matters to me.

</comment><comment><USER10> the main issue is in developer, not in language.

<comment><USER4> This is the same philosophy that blames users for mistakes they make with bad user interfaces.

<comment><USER10> it's not the same... I've seen ugly code in python and cpp and really great code in php using smarty and cakephp.

What does not allow you to write good code in php5, using unit testing and MVC framework?

<comment><USER4> Some pilots have crashed planes with good instrumentation. Some pilots have successfully flown planes with poor instrumentation. Nonetheless, instrumentation design is a very important issue to talk about.

Similarly, programmer skill may make a larger difference, but language design is a very important issue to talk about.

<comment><USER10> Actually php5 gives almost everything that was missing. The only thing is that a lot of pilots used to work with poor instrumentation and don't want to switch! If php sucks then why there are so many successful products/services written on it?

<comment><USER25> If windows sucks, why are there so many successful...?

If Chinese writing is so hard to learn, then why are there so many...?

If religious explanations for the origin of everything sucks, why do so many...?

<comment><USER10> Do you believe this questions share the same answer?

<comment><USER25> Nope. I'm just demonstrating how easy it is to come up with questions that have this structure, but which do not necessarily have the answer, "Because, really, it's actually awesome!"

<comment><USER10> The funny thing is that I do believe that Chinese writing and Zen are awesome :)

<comment><USER25> Not by the "orthogonal and easy to learn" metric.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Reckoning with climate change will demand ugly tradeoffs from environmentalists - <AUTHOR> https://www.vox.com/energy-and-environment/2018/1/27/16935382/climate-change-ugly-tradeoffs <comment><USER2> And may I point out that the fossil fuel industry will want to blow these conflicts up. If you're Joe ILoveNature and most of your exposure to climate change & climate action is the utility co. saying "we'll punch a hole in your nature", it'll maximize your disenthusiasm. So it's a problem, that there is so little outreach, so little understanding.

Also: I would like to see a whole lot more thought going into how to do things in ways that don't _unnecessarily_ get peoples' backs up.</comment>


A 19 basis point portfolio beats the average of most college endowments - <AUTHOR> http://awealthofcommonsense.com/2016/02/bogle-vs-golitath/ <comment><USER2> Blindly shoving all your money into Vanguard ETFs is a strategy that works well for almost every _individual_ who's retirement period maxes out at 70 years (for the MMM types).

An endowment is a fund of money designed to sustain operations of it's benefactor _forever_. Not 10 years. Not 50 years. Literally forever. When you're operating on an indefinite timescale your idea of "risk" changes considerably.

Take a look at the Harvard Endowment report[1], specifically the table on page 2. They are incredibly well diversified, across domestic and international public equities, as well as private equity, commodities, fixed income securities (bonds, etc), real estate, and a category they call "absolute return", which is where they've placed money into external hedge funds. If the US economy tanks, they'll be fine. If Europe falls apart, they'll be fine. A bunch of start up unicorns fail in Silicon Valley? Fine.

My point is that the article completely misses the goals of an endowment. They don't particularly care about matching or beating an index, nor do they care about risk (as measured by volatility). They care about wipe out risk, on the scale of centuries.

[1]: [http://www.hmc.harvard.edu/docs/Final_Annual_Report_2014.pdf](http://www.hmc.harvard.edu/docs/Final_Annual_Report_2014.pdf)

<comment><USER3> > They are incredibly well diversified, across domestic and international > public equities, as well as private equity, commodities, fixed income > securities (bonds, etc), real estate, and a category they call "absolute > return", which is where they've placed money into external hedge funds. If > the US economy tanks, they'll be fine. If Europe falls apart, they'll be > fine. A bunch of start up unicorns fail in Silicon Valley? Fine.

This does not appear to be true. See page 14 of this paper, which shows the 2008-2009 performance of six privately endowed colleges and universities in New England. The smallest loss was 18%, the largest was 30%. Between January 1, 2008, when the S&P500 was at 1,378.76, and January 1, 2009, when the S&P500 was at 868.58, the S&P500 lost 37%. A reasonable mix of stocks and bonds would have had a similar loss as the endowments.

[http://www.tellus.org/pub/Tellusendowmentcrisis.pdf](http://www.tellus.org/pub/Tellusendowmentcrisis.pdf)

<comment><USER4> Right, in 2008 when the entire economy tanked they also tanked. You can't really out-diversify the entire economy tanking. What happened in the years after that? Oh right that paper has no idea because it was last updated in 2010.

<comment><USER5> _You can 't really out-diversify the entire economy tanking._

Sometimes you can. Chart [1] shows the ratio of a particular diversified portfolio's value (4x25 Permanent Portfolio) to the three fund portfolio's value starting in 2005. The ratio increases sharply in 2008-2009 and retains its edge through the subsequent stock bull market.

[1] [http://morning- wave-7809.herokuapp.com/#iau,vti,shy,tlt/vtsm...](http://morning- wave-7809.herokuapp.com/#iau,vti,shy,tlt/vtsmx*4,vgtsx*2,vbmfx*4)

<comment><USER4> The major point of OPs statement is that while sometimes you can get lucky for a short period of time (which is what you just cherrypicked), for an endowment you can't really do stuff like that because you are so big and have such a long term perspective. Regardless, I'm not seeing the narrative you describe in your graph.

<comment><USER5> I agree with the OP's point, but you mentioned 2008 and what happens after that and I'm saying you can diversify in a way that handles those kinds of economic events. (The strategy I mentioned also got _really_ lucky in the 70s and held up cumulatively since then. Of course you can make it unlucky by picking different dates, too e.g. ignore the 70s or 2001 or 2008.)

The chart page doesn't explain things very well, so it takes a bit to unpack, but the point of the chart is actually to give a better idea of comparative performance over a time period rather than focusing on a particular number like average return. Basically it's dividing the current value of one portfolio by the other at each point. The ratio shows the ebb and flow of the two portfolios against each other. John Bogle's speech [1] and this forum [2] probably explain it better.

[1] [http://www.vanguard.com/bogle_site/sp20020626.html](http://www.vanguard.com/bogle_site/sp20020626.html)

[2] [https://www.bogleheads.org/forum/viewtopic.php?t=138973](https://www.bogleheads.org/forum/viewtopic.php?t=138973)

EDIT: cleaned up the first paragraph.

<comment><USER4> Sorry but your examples don't add up. You're showing a 20 year time frame of outperformance, and admitting there are places where performance is a negative, and then claiming all of this shows that there is a strategy that works well all the time. Definitionally this is not true. Correct me if I'm misunderstanding, totally possible.

<comment><USER5> Sorry the examples are confusing. I mention periods of relative underperformance as a nod to your cherrypick comment: yes, the time frames matter in both directions. The question is how much the strategy goes up or down relative to the benchmark and for how long.

My claim with respect to this thread is that there is a strategy that outperforms in certain conditions like the 2008 selloff and 1970s inflation and does so without the risk of losing the gains as soon as the market turns around.

Relative to stocks or 60/40 during a bull market, it doesn't look so good, but it still generates positive returns, holding for some time any edge gained during the earlier conditions.

The overall result is a smooth climb, so I do claim it works well (enough) all the time. I don't claim absolute outperformance long term.

The best chart for what I'm trying to show is beneath the data table in [1]. And the Envy calculator at [2] has great data back to 1972 for different assets (and lets you change the start date).

[1] [http://www.crawlingroad.com/blog/2008/12/22/permanent- portfo...](http://www.crawlingroad.com/blog/2008/12/22/permanent-portfolio- historical-returns/)

[2] [http://portfoliocharts.com/calculators/](http://portfoliocharts.com/calculators/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Anyone who looked at investing knows that you don't compare pure returns, you compare return per risk (say Sharpe ratio or some other measure). 10% return might be truly impressive if it does not involve much risk.

EDIT: For people who look first at comments - the article compared some endowment funds returns with broad market returns and found that funds did not outperform the market. My argument that this is flawed comparison since it ignored risk.

<comment><USER7> I work in investing and take issue with the standard deviation of returns being taken as equivalent to "risk". For example there were many quant funds that had great Sharpe ratios up until 2008, after which they got completely annihilated. But I have nothing else to add. It is hard to measure risk.

<comment><USER6> I agree that standard deviation might not be the best measure of risk. That's why there are many other measures exist that try to address issues. But you cannot compare returns without looking at risk.

Comparing fund performance is a tricky business and often you can cherry pick methodology easily to support any conclusion you desire.

</comment></comment></comment><comment><USER8> Be wary of reading this as "if endowments fired their managers and invested in Vamguard funds, they'd on average boost their returns". Perhaps true of the smaller, consistently-underperforming ones. But at the endowment side, a lot of planning goes into avoiding your size being felt by the markets.

<comment><USER9> What planning are the endowments able to do that Vanguard would not also be doing?

<comment><USER10> Anything. Vanguard index funds just track the market so there's no hedging.

The main planning I could see overlap is executing large trades since they're both moving massive amounts of money.

<comment><USER11> Surely Vanguard still need to make large trades whenever the make-up of the indices change?

When the (e.g.) 500th and 501st largest companies swap places, don't they need to sell one and buy the other to keep tracking a 500 share index?

<comment><USER12> Yes, rebalancing days involve some volatility.

The way these index ETFs work though is that broker dealers can trade a basket of securities matching the index for a share of the ETF (and vice versa). Because of this price mismatches get fixed very quickly. S&P announces also changes ahead of time so while there is initial price movement it's not all instantaneous.

</comment></comment></comment></comment></comment><comment><USER13> Index fund are a market basket of funds. The Index 500 fund is stock in the 500 largest companies in the US. It's intent is to give you the average across all those companies.

Lets look another way. If you are a golfer, the "average" score for a golf round is called PAR. Ask the regular golfer what would they do to be able to play par rounds all the time, most would sell you a beloved grand parent. The index funds are a way to play / invest in the market and get "average" returns.

The leverage that Vanguard has is that these index funds are pretty easy to manage, so they don't charge a lot of fees. Presently on the Index 500 fund, it's 17 basis points. So not much of your capital or your profit is going back to Vanguard. On the other side the big investment places are taking fees anywhere from 2 to 10 times what Vanguard gets. That can make a big difference in your annual rate of return.

Vanguard also has the advantage that in some cases Fund XYZ will be selling a stock while Fund ABC is buying a stock. So it ends up being an in-house purchase, so there is no brokerage fee, lower cost to both funds.

Mutual funds, and specifically index based mutual funds are a good way to get average results across a long period of time. Sure run wild some with that Gold Fund investment and those Oil funds, but be prepared for the downside)

(disclaimer: Long time Vanguard customer)

<comment><USER14> stupid question, but when it lists 5 year return at 10.7%, does that mean it returned on average 10 % per year for 5 years? So if someone started with 100k, they would now have about 160,000?

<comment><USER12> Correct, annual is the normal way of talking about it. If you see "total return" that would mean cumulative.

</comment></comment></comment><comment><USER15> You have to consider a few things:

1) one may be interested in the opportunity of above-average returns. If the average vanguard return is 7%, and the average self-managed return is 6.9%, on average of course vanguard is in your best interest. But what if you think you can do better? Harvard's ran a 12% return for 20 years, for example. Should they forgo it because the average is a more guaranteed, safe, and on average, better bet? Probably not. Does it signal to weaker funds to simply go with the Vanguard option? Yes.

e.g. check out this report: [http://www.hmc.harvard.edu/docs/Final_Annual_Report_2015.pdf](http://www.hmc.harvard.edu/docs/Final_Annual_Report_2015.pdf)

2) looking at just returns is myopic. You need to look at risk-adjusted returns, for which finance has proposed a whole bunch of measures. I would not be surprised if the endowment funds were less risky than the vanguard, although it's hard to tell. And guess which years generate brilliant performance for risky portfolios that are heavy on stocks? Post-crisis years where the market rebounds. Risk isn't the only thing, there are all kinds of objective funds can set. Most colleges for example set liquidity limits that would be unworkable for traditional hedge funds that invest in high-potential returns in illiquid assets. Limiting yourself like this changes your roi.

That having been said, there's obviously a lot of value in this simple perspective. And it completely confirms a new reality: outperformance is getting harder and harder and investors are less likely to beat the market and add value with their investing know-how. It's pretty recent that this has been happening to this extent.

<comment><USER16> A single outlier over a few years does not mean anything.

Harvard got 5.8% in 2015.

<comment><USER17> A single outlier over a single year does not mean anything either.

</comment></comment></comment><comment><USER18> There is a statistics smell that he initially shows also 1y and 3y performance for the endowments, but then doesn't show these for his alternative. Probably he cherry-picked the data that supported his point and hid the rest.

<comment><USER19> From the article "1 and 3 years returns are mostly noise". He focuses on a longer term since it's a much better comparison. On a growing market it's much easier to overperform the index but then get wiped when a crash happens.

<comment><USER18> For the endowments, the 1y and 3y returns didn't look like noise. Hiding the noisy data is hiding the fact that the ETF strategy is more risky than the endowments.

<comment><USER19> What do you mean ? The shorter term you look the more noise there is. I'm not sure that it's exactly the same 1y period, you are just averaging out a lot of funds. I would say the fact that ETFs overperformed on a long term means they are less risky not more.

</comment></comment></comment></comment><comment><USER17> The headline is misleading. The vanguard portfolio beats the average of all small endowments (under $1B) and is beaten by average of the large endowments. Endowment performance is impressively correlated to size.

<comment><USER20> Ok, we replaced 'every' with 'most' in the title.

</comment></comment><comment><USER21> This is true, both my bosses worked for a larger well respected endowment about a year ago. The firms are not doing well and at least this one is not and there is talk if going to the strategy here.

Basically a fund of funds with a bunch of mutual funds. They are facing competition for PE deals and maintaining higher risk trading desks with high cap costs.

I would note that while the numbers in the article did beat performance now could be the best time to have a trade desk. Most indices look like this

        /\/\/?

Not / / /

So having a group work on minimizing that could be profitable

</comment><comment><USER22> That only beats half of the endowments, I'd be more impressed if it be something like 75% to indicate it was truly a top tier product instead of just better than average.

<comment><USER23> To a first approximation, this is what one would expect of index funds, right? They're literally incapable of beating the broad market (they have _some_ expenses, so they have to lag a little). One point that's not addressed by these statistics is whether any given university endowment consistently beats the market, or whether they all fluctuate around that average over the long term (say, 20+ years).

The underlying question is, why should universities employ big teams of investment experts to manage their investments? (Those salaries are, I suspect, _not_ accounted for in these performance numbers: the source says they are "net of fees", but I assume that's only counting actual fees from the investment products themselves rather than the costs of in-house staff.) If you can get consistently average results with almost no investment strategy at all, what are all those salaries for?

</comment></comment><comment><USER24> I wonder if the returns quoted for endowments properly subtract out the salaries, build space, etc for the employees of the institution with the endowment, or just the explicit costs from outside management?

(See my clarification below. I'm talking about the costs only for the employees making investment decisions.)

<comment><USER17> Hmm? Money spent on university operations is not an investment expense.

<comment><USER24> I don't care about the label, I care for a fair comparison of the question, "Would Universities be better off with a simple mix of index funds or using their current approach?" To answer that question, you'd like to figure out what the performance would have been if universities used that simpler approach, and that might include saving a lot of money on the university employees who select managers or make investment decisions at the university. I hope it didn't seem like I thought you should subtract out the costs of random university employees.

(Rereading my words, I can certainly understand that interpretation. Sorry.)

</comment></comment></comment><comment><USER25> This would be more interesting if he had proposed the portfolio 10 years ago, rather than to do so in retrospect.

<comment><USER26> Warren Buffet made a similar bet 8 years ago on a 10 year horizon, betting on Vanguard against some top hedge funds.

Buffett is very likely to win that bet.

[http://fortune.com/2015/02/03/berkshires-buffett-adds-to- his...](http://fortune.com/2015/02/03/berkshires-buffett-adds-to-his-lead- in-1-million-bet-with-hedge-fund/)

[http://longbets.org/362/](http://longbets.org/362/)

<comment><USER27> This is interesting! Shoddy writing int he Fortune piece though.

"The amount handed over [to charity], though, is not likely to be $1 million, because of changes that Buffett and Protégé made in the wager a couple of years ago"

One paragraph later:

"Buffett also issued a guarantee: He will pay the winning charity $1 million if the Berkshire stock bought isn't worth that much at the bet's end."

Nitpicky I know, but it sounds like the winning charity is guaranteed $1 million.

<comment><USER28> Read a few more lines down and they state that the amount will most likely be _more_ than $1 million, thus keeping the previous two quotes consistent.

</comment></comment></comment></comment><comment><USER29> The overlooked discussion is that universities are supposed to make money by selling quality education. Their goal shouldn't be to make money by risking money.

Perhaps the lower return simply reflects the less aggressive nature of their portfolio. But ironically while waiting in the lobby of a prominent VC I met a college endowment fund manager who was currently using machine learning to trade options. I believe part of the endowment is now traded using his system (not 100% sure about this).

When I asked why his approach won't suffer the same fate as LTCM, an algorithm-based options-trading system run by Noble-prize winner Robin Scholes, he claimed that his approach relied on less leverage. But he didn't address the point on how his system would have predicted the Asian flu and Russian default that ended LTCM. I guess it would have been harmful but not fatal.

What's acceptable risk for a Wall Street fund isn't necessarily appropriate for an endowment fund regardless of the upside.

<comment><USER30> There is nothing inherently wrong with the LTCM algorithm. Using the same algorithm after the crash, it was eventually liquidated at a profit. The problem was how leveraged the investors were. Banks that invested in LTCM were so heavily leveraged in it that the temporary collapse of the fund was threatening the survivability of a few large institutional investors. The same fund likely would have performed very well for an investor that was not as heavily leveraged. The collapse would still be harmful but not fatal.

</comment></comment><comment><USER31> The site is blocked in Russia citing national law. Wonder what they've published.</comment>


Optical Microscope with 50-nanometre resolution demonstrated - <AUTHOR> http://www.bbc.co.uk/news/science-environment-12612209

<comment><USER2> Sort of reminiscent of squinting to see when you don't have your glasses.</comment>


"So I used to have the same drug dealer as the guy who invented Kickstarter." - <AUTHOR> http://www.youtube.com/watch?v=Puiky9-zi8E

<comment><USER2> I'm not sure how this is at all suitable for Hacker News but I really enjoyed that, so thanks :)

<comment><AUTHOR> Cheers and thank you! It is the first story in a whole collection called "Common Fantasies for Strong People."

<http://www.miraclejones.com/common.html>

I wrote code for the collection so that readers can comment on every paragraph, and also, the paragraphs light up to signify where the comments are. The darker the paragraph, the more comments that are lurking inside.</comment></comment>


Smarter search and recent object functionality - <AUTHOR> http://blog.twproject.com/2009/02/20/smarter-search-and-recent-object-functionality

<comment><USER2> Interesting way to produce a universal, non-browser solution; however, server- side web apps lose some of the functionality of browser extensions, particularly low-level features.

Standardization would be nice. I'm sick of developing for 4 different browsers in 4 different pseudo-languages.</comment>


History of Evolution - <AUTHOR> http://www.iep.utm.edu/evolutio/ <comment><USER2> >> The process of rejection is commonly considered to have begun with Descartes and to have culminated in Darwin's theory of evolution by natural selection.

That seems unlikely, as Descartes was a vocal gnostic and a proponent of a designer god idea. He did not believe that "potential being" could be construed as an actual being.</comment>


PowerShell: Windows Scripting Made Fun Again - <AUTHOR> http://mattiasgeniar.be/2009/02/27/powershell-windows-scripting-made-fun-again/

<comment><USER2> It may be a powerful shell, but I wish the examples were a bit more practical and enticing.

First of all, what's missing on Windows is a useful _interactive_ mode for the command prompt. Do they really expect people to type these kinds of lines at the prompt? If I wanted a verbose, object-oriented _interactive_ interpreter, I could use Python right now, on Linux or Windows or Mac. What I really want is for Microsoft to ship something in the box with Windows that is as useful as having bash or tcsh with a collection of Unix utilities.

The article's 5+ lines of Windows PowerShell could be replaced with the Unix command "date '+%m-%d-%Y %H:%M:%S'" to get roughly the same result. If you want to add 10 days (as in the article), "date -v+10d '+%m-%d-%Y %H:%M:%S'". If Microsoft wants to win over practical shell users, they'll have to come much closer to something like this.

<comment><USER3> You can do it in one line, if that is what you mean?

        (Get-date).AddDays(10).ToString()</comment></comment>


Why We Need Free Digital Hardware Designs - <AUTHOR> http://www.wired.com/2015/03/need-free-digital-hardware-designs/

<comment><USER2> I'm looking foward to it.</comment>


Ask HN: Hobbyist Cross Platform App Development - <AUTHOR>

Most enterprise app dev shops are going with paid systems such as Appcelerator Titanium, Xamarin, CoronaSDK where if you buy in, you get all of the goodies.<p>What is the best solution for hobbyist app developers who want to build cross-platform apps from a single code base and don't want large up-front costs? <comment><USER2> Titanium is free for building/distributed apps and hosting data using their mobile backend (ACS). The paid components are related to Appcelerator Platform, which is a suite of testing, performance, analytics, data and integration modules. If you're a hobbyist, you likely don't need the enterprise suite.

If you go with Phonegap / Cordova, I recommend looking into Appgyver's implementation which offers great tooling (cli), tight codebase (Angular) and an extended feature set for native components. They also have a great support for data integration and provide a nice visual editor (Composer).

Fwiw, I have been using Titanium since 2009 and have worked with many clients over the years as a consultant and trainer. I primarily use Titanium (Alloy) for rapid development and write native modules to extend the framework as needed. Expect about 85% cross-platform code coverage (business logic) and about 95% coverage for views/styles.

</comment><comment><USER3> Cordova is great. I work for an app dev shop. We do both native and hybrid.

If you dont want to mess with building for iOS and Android and XYZ then I would recommend looking into Phonegap. Phonegap uses Cordova to access all of the native apis etc. However what Phonegap does offer thats different is the entire build system. So if you are DIY with Cordova you run all of the build tasks but if you are doing it with Phonegap you can hook up your github repo and they will build for all of the supported platforms for you. No messing with XCode etc.

<comment><AUTHOR> That is exactly the kind of discussion that I'm looking for. Thanks for your great reply!

</comment></comment><comment><USER4> I would recommend developing your code base using Qt, which will export to Android and iOS. I think Windows Phone will be supported in the future, but has not been fully released yet. Qt is open source and free to use under LGPL.

<comment><AUTHOR> I have seen some really good things about Qt.

Are there any user paradigms that work better for Qt? For instance, CoronaSDK really excells at game development.

<comment><USER4> There are a wide range of modules in the Qt library including an OpenGL library if you want to do 3D games. I would say that Qt is strongest in doing basic apps with standard components like buttons, images, sliders, etc. since there is a large built-in library of Qt widgets to use. The down sides are that your apps may not look 100% native and the Qt libraries add a few MB of bloat to your app size.

</comment></comment></comment><comment><USER5> Having built apps with apps with phonegap my advice is don't. Pick a single platform and build natively unless you have a very very good reason you have to be cross-platform.

<comment><AUTHOR> What do you currently build?

Native Android or iOS?

What IDE do you use and what issues do you face?

Thanks for your comment!</comment></comment>


Ask HN: Where do you get your dose of CS academic papers? - <AUTHOR>

It's getting difficult to keep my dose coming without succumbing to an ACM membership. <comment><USER2> Specific conference websites to find out titles and typically the author's personal site.

<comment><AUTHOR> That's mostly what i've been doing too. But it's hard. for the new conferences, the article usually isn't available online. and for the older instances, the conferences' websites sometimes lack the history.

</comment></comment><comment><USER3> eprintweb: <http://eprintweb.org/S/rss/cs> in google reader. There are a few of the math/ and q-bio/q-fin feeds that are usually interesting reading.

I'm not sure why I didn't use the arXiv RSS feeds directly.

<comment><AUTHOR> Didn't know about that one. thank you!</comment></comment>


Startup Quote: Bart Decrem, co-founder, Tapulous - <AUTHOR> http://startupquote.com/post/6028219445

<comment><AUTHOR> Don't get ahead of yourself. Companies need time to figure out what they want to be.

\- Bart Decrem (@bartd)

<http://startupquote.com/post/6028219445></comment>


Swift: When Unused Code Is a Bug - <AUTHOR> https://www.peripheryapp.com/blog/2018/08/04/swift-when-unused-code-is-a-bug/ <comment><USER2> Wow, Heisen-Swift, where the Heisenbugs are in the language specification!

What an object is, which is roughly equivalent to its observed behavior, should never depend on how it is declared.

       let greeter = LazyGreeter()
       let greeter1: Greeter = greeter
       print(greeter)
       print(greeter1)
       greeter.greet()
       greeter1.greet()

UPDATE: just in case it's not clear, this prints the following:

       greeter.LazyGreeter
       greeter.LazyGreeter
       sup
       Hello, World!

So the same object responds differently to the same message, depending on how it is declared. Yikes!

<comment><USER3> > What an object is, which is roughly equivalent to its observed behavior, > should never depend on how it is declared.

This is actually a statement that strong typing should not exist. A "declaration" (really a _type_ declaration) indicates the type, and if observed behavior cannot depend on the types there is not much point to types. Or stated positively: in a strongly typed language, the types are part of 'what an object is'.

Or, stated by example:

        let a: Int = 3
        let b: Float = 3
        print(a/2) //prints 1
        print(b/2) //prints 1.5

Both a and b are "the same" value, insofar as they are `==` and they model the same underlying mathematical concept. But behavior varies because they differ in type.

OP's snippet actually works quite a lot differently than the way you may expect; LazyGreeter.greet() and Greeter.greet() are two completely independent functions that share the same name. Name resolution is a complex topic in any language, but in Swift if you wanted to override another function you would say `override`, in which case the compiler will complain there is nothing you can override in `BaseGreeter` at which point you will understand the whole mistake.

There is actually no way to "pick" LazyGreeter's implementation of the unrelated function (as perhaps you expect). The only function we can call on a Greeter is Greeter.greet (or its overloads, and there are none). So if Greeter.greet did not exist, we would not get LazyGreeter.greet() but rather a type error.

I do think a case can be made that we need a similar `implements` keyword like `override` to check that we are implementing a protocol requirement.

<comment><USER2> > This is actually a statement that strong typing should not exist.

Nope. It is a statement that objects shouldn't be different depending on how you look at them.

The example is a class, so a reference type. That means that greeter and greeter1 are just two references to the exact same underlying object.

Your example are two distinct value type instances that you happened to initialize from the same literal.

So not even close to comparable situations. Speaking of comparable:

> Both a and b are "the same" value, insofar as they are `==`

Also nope.

       let a: Int = 3
       let b: Float = 3

       let r=a==b
       print(r)

Let's compile this:

       swiftc numbers.swift
       numbers.swift:4:8: error: binary operator '==' cannot be applied to operands of type 'Int' and 'Float'
       let r=a==b
             ~^ ~
       numbers.swift:4:8: note: expected an argument list of type '(Int, Int)'
       let r=a==b
              ^

<comment><USER4> You may not be familiar with swift but a protocol isn't necessarily a class. Structs ( so, value type) can also implements a protocol, and so in effect you can not tell a lot about what you're manipulating, beyond what's declared at the protocol level.

<comment><USER2> From TFA:

       class BaseGreeter: Greeter {}

       class LazyGreeter: BaseGreeter {

</comment></comment></comment></comment></comment><comment><USER5> I'm reading the comments here about how the languages fails, or what it should have done better, but at the same time I'm feeling the same as I do when building up something with Kubernetes and the problem isn't really the language, it's the shortcuts we take with it to stay concise.

e.g. in Kubernetes you can give a Pod, Deployment, Service, Ingress, Volume, etc. etc. the exact same name and in fact many examples encourage that (because they are namespaced on the type). However this is practically just an artefact of a previous choice and when you're looking at your YAML files you may not immediately know that distinction unless you have some familiarity with the tech.

What it says is that you can call everything the exact same thing. And it will work, and it will seem nice or elegant.

So it is with this Swift example and having a protocol, an extension, and a base class all declaring the exact same thing. Even if the compiler figures it out, how would you without reading the spec or knowing where those files live (because in the real world they would be spread across the filesystem)? It's just poor consideration for comprehension.

<comment><USER6> You make a fair point, but isn't it part of a platform's responsibility to not make footguns quite so easy to grab? Especially given Swift's general (and mostly helpful) attitude of insistence on safe, explicit constructs. For example, it's a warning to ignore a function call result; it's an error to not chain up to a superclass's initializer; it's an error to re-implement a class member without the `override` keyword.

Doesn't this situation deserve similar compiler scrutiny?

<comment><USER7> The problem with this angle is that while sure, you can always make a compiler more intelligent in ambiguous situations, you must also now train all the humans interfacing with it to be equally as intelligent (or at least, able to sufficiently disambiguate).

We don't see many context-sensitive grammars for programming languages, not because very difficult to implement, but I suspect because they're hard for humans to understand.

There is something to be said for the simplicity of naming things to describe what they are (e.g. Hungarian notation), but I really think it's a mistake for languages (configuration, programming, etc.) to even allow identifiers to be reused for differing types.

<comment><USER6> > make a compiler more intelligent in ambiguous situations, [but] you must > also now train all the humans interfacing with it to be equally as > intelligent

I'm not sure what you mean here; probably I'm misunderstanding you somehow.

If you make the compiler more intelligent so that it can tell the humans about subtle problems, that lets the humans be _less_ intelligent (or at least have to think less). No?

</comment></comment></comment></comment><comment><USER8> Default implementations on protocols in Swift definitely can be a little dangerous. We've shied our team away from doing this unless the protocol is explicitly used as a mix-in type.

There's been some proposals around fixing these, one that comes to mind is: [https://forums.swift.org/t/introducing-role-keywords-to- redu...](https://forums.swift.org/t/introducing-role-keywords-to-reduce-hard- to-find-bugs/6113)

<comment><USER9> This doesn't seem to be about default implementations on protocols, I guess they do actually do virtual dispatch so you wouldn't hit this bug with default impls. The main issue is that we have an extension method on a type with the same name of a member of that type. So it can always be statically flagged whether or not the method is used anywhere else. This is easily reproducible in any language that supports extension methods (C#, for instance). I wonder if that could be useful at all.

</comment></comment><comment><USER10> Coming from the .NET world, where extension methods are just syntactic sugar for static methods, the "bug" described in the article wasn't surprising to me. However, it did make me stop and think about how the example would look in C#. This was what I came up with:

        public interface IGreeter {
        }

        public static class GreeterExtensions {
            public void Greet(this IGreeter greeter) {
                // If you have CA turned on,
                // you'll get a warning for not
                // using the parameter "greeter"
                Console.WriteLine("Hello, World!");
            }
        }

        public class BaseGreeter : IGreeter {
            public abstract void Greet();
        }

        public class LazyGreeter : BaseGreeter {
            public override void Greet() {
                Console.WriteLine("sup");
            }
        }

        IGreeter greeter = new LazyGreeter();

        // This has to be GreeterExtensions.Greet(greeter),
        // because IGreeter is an empty interface
        greeter.Greet();

I think the syntax in C# makes it clearer that you're doing something funky mixing inheritance with extension methods. If you wanted to do it the "correct" way, I think it would look something like:

        public interface IGreeter {
            void Greet();
        }

        public class BaseGreeter : IGreeter {
            // Edit: abstract method wouldn't be equivalent to example
            // public abstract void Greet();
            public virtual void Greet() {
                Console.WriteLine("Hello, World!");
            }
        }

        public class LazyGreeter : BaseGreeter {
            public override void Greet() {
                Console.WriteLine("sup");
            }
        }

        IGreeter greeter = new LazyGreeter();
        greeter.Greet();

Which is more complicated than the idiomatic way of providing default behavior with inheritance:

        public class Greeter {
            public virtual void Greet() {
                Console.WriteLine("Hello, World!");
            }
        }

        public class LazyGreeter : Greeter {
            public override void Greet() {
                Console.WriteLine("sup");
            }
        }

        Greeter greeter = new LazyGreeter();
        greeter.Greet();

I'm not a huge fan of the Swift syntax; specifically, IMO, the declaration `class BaseGreeter: Greeter {}` hides where the implementation of `greet` is coming from. Without the method declaration it looks like it's being inherited from the protocol extension, when it's really not.

<comment><USER11> C# is one of those languages that I absolutely love and wish I had any reason or excuse to use. But it only seems used in .NET apps which are inherently harder to write than web apps which is why I learned Electron instead.

</comment></comment><comment><USER12> If I saw this in a code review, I would flag it for re-design. Mixing composition and inheritance especially in this way is definitely going to confuse anyone who doesn't read every line to figure out what's going on.

<comment><USER13> I don't think there's anything wrong with mixing composition and inheritance _per se_ , if everything is obeying strict OOP principles (Open-Closed, etc.) If the mix-in was adding functionality to the base class, and then the subclass was there to _specialize_ the behavior of the base class without breaking any of the contracts the base class itself makes (i.e. any unit test that works on a Greeter should work on a LazyGreeter) then I don't think anyone would be confused.

But in this case, OOP principles _aren 't_ being followed—the subclass is attempting to override stuff from the protocol, which the superclass _didn 't_ override. Essentially, the superclass made an assertion, by not overriding that method, that it wanted the default behavior from the protocol extension. The subclass, by overriding that behavior, is breaking the contract that the superclass declares.

<comment><USER12> Yeah, A static analyzer should be able to figure out what's going on and throw an error.

</comment></comment></comment><comment><USER14> In general I've found protocol extensions to be an incredibly powerful concept. There's a couple of WWDC talks about 'protocol oriented programming' that highlight some great, practical use cases.

I've run into the author's problem a few times, and I'd like to think that this is just a bug or behaviour detail that a future Swift version could correct. Swift hasn't quite matured fully yet, and this is a great example of that (these examples are becoming fewer every year though).

</comment><comment><USER15> This is my favorite Swift gotcha :D

This bug bit me one time back before remote debugging came out when I was developing an app for a device that plugged into the lightning port. The only way to debug was to send log messages over the network to a log server running on my laptop, and the connected device sent messages to satellites where there was often a 10-minute gap in connectivity. And I couldn't reproduce it in tests. That took some time to diagnose!

I like to bring this issue up if an interview candidate seems extremely bought in to protocol-driven development. I wouldn't be surprised if any level of dev wasn't aware of it, but would be impressed if anybody identified it.

</comment><comment><USER16> Can anyone explain to me what the rationale for this is?

I can understand the advantage of using static dispatch, i.e. Greeter#greet(object), but I assume there is some mechanism that avoids calling Greeter#greet if BaseGreeter would implement greet and call BaseGreeter#greet(object) instead.

Why does extending a class which extends a protocol not make the extending class implement that protocol in Swift?

</comment><comment><USER17> I wonder if this behavior is working as intended. It does look like a bug to the language itself, isn't?

<comment><USER18> It appears the correct action would have been to use override func greet() { print("sup") }.

To be fair, I was primed to really think about the code execution given he'd indicated there was a trap in there somewhere, so it certainly would not have been immediately obvious on first glance. But I think, generally developers understand that override is necessary to override code from a parent class.

Typically XCode helps out with this sort of thing – adding override where it seems like it should be added – but perhaps not when a parent class is using a default protocol implementation.

But again, in this scenario where a class is inheriting from another class, it's typically known you need to override the function in order to use your own implementation, so this does seem a bit contrived.

<comment><USER12> > It appears the correct action would have been to use override func > greet() { print("sup") }.

That actually doesn't work because the greet function is implemented on an extension. You can only override class functions.

<comment><USER18> Oh, that's definitely weird then. Is there an RFC to have that fixed in some way?

<comment><USER12> I don't think there is. I think the code is functioning as expected — it's just written in a super confusing way. What should probably happen is that the compiler should throw an error about redefining a function in a super classes extension. I'm not a compiler engineer but a check for that seems like it would be intensive unless that information is codified in the AST somehow.

<comment><USER19> It's a bug - [https://bugs.swift.org/browse/SR-103](https://bugs.swift.org/browse/SR-103)

</comment></comment></comment></comment></comment></comment><comment><USER20> It's good that Periphery catches the unused code.

But if that's the only reason it catches the problem, I think it could have room for improvement. For example in one place the error could exist, but at a different place, the real function could be called because the variable is declared as a LazyGreeter. Then Periphery wouldn't catch the problem.

One way to fully catch it would be to give a warning if a base class implements a protocol but a derived class doesn't. I'm not sure how many false positives this would have. Possibly you might only do this if the derived class tries to override a function from the base class's protocol.

</comment><comment><USER21> This seems like a problem with using class inheritance more than anything else.

<comment><USER22> Or a problem of mixing class inheritance with protocol conformance, perhaps.

</comment></comment><comment><USER23> I've run afoul of this a couple of times in my Swift delegate protocols. A really nice hack to implement Objective-C's optional protocol methods in Swift is to use a protocol extension to create a default method that can come back to bite you when you subclass objects that conform to that protocol.

<comment><USER24> Yep, the old `fatalError("You need to implement this!")`.

</comment></comment><comment><USER25> Interesting. Swift has been my primary language for a couple of years now, but I've never run into this, mainly because I use subclasses far, far less often than I did under Objective-C. If this bug had existed in Obj-C back when It was still my primary language it likely would have bitten me.

</comment><comment><USER26> Providing a protocol with a default concrete implementation of the interface? That's not passing code review here.

Would I have caught the _bug_? Probably not. But it looks like bad form to me to provide that default implementation to Greeter, so please rewrite your code.

<comment><USER27> I'm curious to know why... Looks like typical mixin pattern, no?

<comment><USER26> An interface declaration is not the right place for implementation. If you want a default implementation, use a base class and inherit, overriding if you don't want the default.

This bug is now another good reason not to use default implementations on interfaces.

<comment><USER21> Protocol extensions are extremely powerful and safe if used correctly and not mixed with class inheritance as in this example.

</comment></comment></comment></comment><comment><USER28> If the concept is that protocol requirements represent the "customisation points" of a protocol, shouldn't this apply equally to conforming classes and subclasses with inherited conformance? So I would be in favour of fixing this. Conversely, perhaps protocol extension methods etc not declared as protocol requirements could e.g. elicit a compiler warning when "overridden" by conforming classes/subclasses with inherited conformance (since they are not intended as customisation points)? I think these changes would aid reasoning about protocols and reduce bugs.

</comment><comment><USER29> I don't know that you can really call this a bug? It just seems to be the design choice. Though I agree, it seems odd at first, and appears possibly accidental, it could have been on purpose.

My question to swifters: what if LazyGreeter had another method, say lazyGreet, and you typed it as Greeter? Then you called let greeter : Greeter = LazyGreeter(); greeter.lazyGreet();

Would you expect this to work or fail?

I'd expect it to fail.

In that sense, I assume its simply that extension methods override child overrides. And its just something you need to know. That can even have interesting utility in some scenarios.

<comment><USER30> In python, `greeter.lazyGreet()` would succeed, because python only has types at runtime. If you used mypy, you would get a warning for this. No warning would be issued for `greeter.greet()`, but since function dispatch is still done at runtime, this would call `LazyGreeter.greet()`.

I concur that the behaviour is a design decision, not a bug, but I think most programmers would in general prefer design decisions to bring the language closer to python.

</comment></comment><comment><USER31> How much different is this from slicing in C++?

IE:

      #include <iostream>
      using namespace std;

      struct Greeter {
        void greet() {
            cout << "Hello, World!" << endl;
        }
      };

      struct BaseGreeter: Greeter {};

      struct LazyGreeter: BaseGreeter {
        void greet() {
            cout << "sup" << endl;
        }
      };

      int main() {
        Greeter greeter = LazyGreeter();
        greeter.greet(); // Prints "Hello, World"

        return 0;
      }

<comment><USER32> In C++ world this is expected behavior AND it's documented. But in swift, protocols cannot declare default implementations but it's possible to define implementation to protocol using extensions. So in C++, it might look like this

      struct Greeter {
        virtual void greet() {
          cout << "Hello, world!" << endl;
        }
      };

      struct BaseGreeter: Greeter {};

      struct LazyGreeter: BaseGreeter {
        void greet() override {
          cout << "sup" << endl;
        }
      };

      int main() {
        Greeter *greeter = new LazyGreeter();
        greeter->greet(); // In C++ prints "sup", but in Swift "Hello, World!"
        delete greeter;
        return 0;
      }

</comment></comment><comment><USER33> The explanation is counterintuitive and it's one of those many Swift-ish things I've learned to be wary of. I find that Swift tries to be 'all things' and to often I get lost trying to cobble together a mental picture of what a class is supposed to be given all the various ways to annotate it.

</comment><comment><USER34> Another "unused code bug" would be when a locally scoped variable which is not supposed to be there shadows the intended global variable.

It's just a matter of global scoping and precedence. But yeah, sharing notation between inheritance and extension is a tad bit reductionist.

</comment><comment><USER35> I'm a little undecided on Swift extensions as a whole, and particularly protocol extensions. Maybe I'm just paranoid but it feels like it leads to a more complicated code layout.

<comment><USER36> I agree. I never worked with swift and had to look up the terminology. Most of what the article refers to maps to terms from C++ (which is already horribly complicated and offers way too many ways to shoot yourself in the foot) or Java. That PWT sounds an awful lot like a vtable. In C++ you mess up by forgetting to add "virtual" (luckily we recently got "override"), but it seems swift's protocols add another dimension to make it possible to mess up in.

It's weird how people preach over and over how arcane and cumbersome old languages like C(++) are, with the neckbeards defending it with "well you just have to adhere to this list of best practices and it's absolutely fine", and then when some new and hip language comes along and offers just as many traps, the same people giving the "old languages" crap suddenly go all "well it's bad design to do that! Just adhere to this list of best practices here..."

<comment><USER24> As someone who transitioned from Java to C#/.Net to Objective-C and finally to Swift, AMEN TO THAT!

I learned not to say anything as apparently every software engineer "generation" needs to follow something "hip" when very young. Some will grow to see the cycle as it repeats itself in front of them, others will die believing "my programming language was the best, you just had to stick to this list of best practices".

Also, "bad design" quite often means "not the way I'm used to and feel comfortable with".

<comment><USER6> There's an element of this even within the community of a single language, too. E.g., Apple's been doing Swift talks at WWDC where they sort of introduce their blow-your-mind-paradigm-of-the-year: "Protocol Oriented Programming" was two years ago; "Embrace Algorithms (subtitle: delete your for loops)" was this year.

It concerns me because these are such lush, ripe targets for cargoculting. The behavior in this article is problematic exactly because of the "Apple says we must not use inheritance for anything! I can just use a protocol extension; that's totally not inheritance" mindset.

</comment></comment></comment></comment><comment><USER37> This is an interesting demonstration of a hard edge of the language. It's not because Swift holds some sort of grudge against dynamic dispatch, but rather because it's trying to reconcile some subtly incompatible design goals:

1\. Adding a default implementation for a protocol requirement shouldn't stop existing types that correctly conform to that protocol from compiling. This is a reasonable user expectation and makes protocol composition a more powerful feature.

2\. "Retroactive conformance" should be possible: someone should be able to conform a type they didn't write to a protocol of their own creation. It's a nifty feature that makes Swift extensions very powerful but also sometimes difficult to reason about.

3\. Classes should inherit protocol conformances from their superclasses. As some of the Swift core team members have explained, this is not something that absolutely had to be the case, but it seemed sensible initially.

Points (1) and (2) preclude the language from requiring the `override` keyword for the subclass `LazyGreeter` to override a default implementation of a protocol requirement not itself overridden in the superclass `BaseGreeter`, since that would mean that (1) and/or (2) would become impossible. Getting rid of (3) would remove the surprising behavior but it is rather late in the evolution of the language to make such a large change.

The way to reason about this behavior is to consider what are intended "customization points" in the language. It isn't really covered in The Swift Programming Language, but (although not intuitive) it's a fairly teachable concept:

A separate but similar issue exists with the distinction between default implementations of protocol requirements (methods declared in both a protocol and a protocol extension) versus extension methods (methods not declared in a protocol but found in a protocol extension). The former is dynamically dispatched and is considered a customization point for conforming types, whereas the latter can only be shadowed by conforming types but is not a customization point. As described here: [https://nomothetis.svbtle.com/the- ghost-of-swift-bugs-future](https://nomothetis.svbtle.com/the-ghost-of-swift- bugs-future)

(The Swift standard library actually uses this concept to its advantage. For instance, the inequality operator != is not a customization point for the Equatable protocol and is implemented in an extension method, guaranteeing that !(a == b) is always equivalent to (a != b) in the generic context.)

When implementing subclasses of a third-party open class, only open methods are customization points. In that case, Swift provides compile-time checking to prohibit overriding non-open public methods. This is possible because Swift does not support "retroactive inheritance" from a superclass as it does retroactive conformance to a protocol. Also, the language allows later versions of a third-party open class to stop your existing subclasses from compiling because of a conflict between a later-added superclass method and a pre-existing method in your subclass that now lacks the `override` keyword. In other words, the compiler-enforced prohibition is possible because points (1) and (2) above were not design goals for subclassing as they were for protocol conformance.

In the case illustrated by the present article, where protocols are used in class hierarchies, a third notion of customization points arises. As demonstrated here, a protocol requirement not overridden by a base class is not a customization point for a subclass. The protocol requirement can be shadowed by the subclass but not overridden. Consistent with the design goals enumerated above, this allows for the vendor of a library protocol to provide additional default implementations at a later point without breaking user code. (But if the vendor of a conforming superclass then implements an overriding implementation, your subclass would cease to compile just as it would for any other conflict between superclass methods and subclass methods.)

<comment><USER6> > Adding a default implementation for a protocol requirement shouldn't stop > existing types that correctly conform to that protocol from compiling.

I would disagree with that; adding that default implementation is not a simply internal change. It flat-out changes compilibility; it makes invalid code into valid code:

        protocol P {
            func f()
        }

        class C : P {}    // Error!

\---

        protocol P {
            func f()
        }
        extension P {
            func f() {}
        }

        class C : P {}    // Okay

Given the trap demonstrated here, the converse should hold as well. Doubly so in light of the ways the compiler (mostly helpfully) enforces various aspects of subclassing, as you pointed out.

In many ways, protocols (right now at least) feel like Swift having its cake but not eating it: strictness floats around them in ways that do not help developers (ugh, PATs!) but is absent where it would:

        // This all compiles without any warnings?!
        protocol P {
            var i: Int { get set }
        }

        protocol Q : P {
            var i: Int { get }
        }

        class C : Q, P {
            var i = 10
        }

        // Now make a protocol that inherits from another,
        // where both are class/AnyObject constrained

        //---

        struct S : Hashable {    // Swift 4.1, synthesized
            let s: String
        }
        extension S : Equatable {
            static func == (lhs: S, rhs: S) -> Bool {
                // Hashable semantics, smashable semantics. Hold my beer.
                return lhs.s.first == rhs.s.first
            }
        }</comment></comment>


Ask HN: How did you validate your startup? - <AUTHOR> How did you validate your start-up?
I recently quit my job to try and start-up and I'm in the midst of trying to validate the idea, and I wanted to know how did you guys do it?
Did you identify a target market and then call them?  If so did you have a list of questions?
Did you just walk into a couple of businesses and ask them questions?
Did you follow a process that you created, or was laid out by someone else?
Also when you found someone to talk to how did you know if the problem was painful enough to charge money for without asking "how much money would you spend on this?" <comment><USER2> We just visited a lot of customers with ready demo's of our product tailored on their business and needs. We persuaded them to test it, and then they all loved it and the majority of them are now our customers. In the future, in order to open a new country market, I'll follow the same tactics.

</comment><comment><USER3> if consumer business you can create a 1 page google survey for $50-$75

or..

1\. I created a lead page with a question/pain point/offer.

2\. added 3 benefits with 3 bullets each.

3\. connected a button from the lead form to a page with a

3 page wufoo.com form.

4\. page one click 1 option choice or checkboxes.

5\. page 2 enter some information

6\. page lead info.

7\. used those leads to get an idea if there's a market.

then call or email them back.

</comment><comment><USER4> We did a meta campaign I.e. asked the community to help build the product , the website, test etc</comment>


Ask HN: How do you charge clients for hosting their mobile backend? - <AUTHOR> If you've developed a mobile app for a client and you handle the hosting. How do you sufficiently charge them while lowering your risk? if for example the app starts being resource intensive? <comment><USER2> Require pre-payment for a set number of API requests, bandwidth transfer and bandwidth throughput above what it costs you to deliver it. This insures you are covered for infrastructure upgrades, contract bandwidth increase costs, security and more as you grow. What ever bundles you create, insure that the pricing is enough to give you a good profit so all of your expenses are covered and you have money to put aside.

<comment><AUTHOR> Thanks for that advice man. I shall do exactly that

</comment></comment><comment><USER3> If paying for a client's hosting needs is a potentially high risk arrangement, my gut reaction is to have the client's account tied to their credit card and to invoice maintenance and other services separately. Because:

1\. It means that the client owns the resources and that is good for the client.

2\. It means if the client stops paying for hosting, you're not out the money.

3\. It means that if hosting gets expensive, you don't own the problem...you own the solution in the form of additional billable services.

4\. It means that the client can make the decision to pull the plug if usage gets to high and you're not involved.

I'd add that under this scenario, you can maintain the client's account on their behalf and charge a nice fee for doing so...maybe a fixed fee plus a percentage of hosting costs. If the client wants to move to a cheaper alternative, you can charge for that work too. The most important thing is that you do not own hosting costs when there is a problem.

Good luck.</comment>


Who is hiring a fully remote junior/entry-level full stack developer? - <AUTHOR> Hello,I am a full stack developer living in West Africa. Due to the lack of new tech stack and ecosystem of my country, I am looking forward to working in a startup remotely, wherein I can learn new skills, tackle new challenges and grow.
I have a associate degree in Telecommunications but I switched to software development career where I got pratical skills through online courses.
My skills are JavaScript, ES6/ES7, NodeJS, Express, ReactJS, Redux, MongoDB, Socket.IO, OAuth Systems, MySQL, Sqlite3, JQuery, Ajax. I am also familiar with TDD/BDD, Docker, Microservices and Message Queuing Protocols like RabbitMQ.
I would love to get my dream remote job. Can anyone help? <comment><USER2> There is a Monthly post on HN about job offers, check it out: [https://news.ycombinator.com/item?id=20867123](https://news.ycombinator.com/item?id=20867123) And one where you can put your info: [https://news.ycombinator.com/item?id=20867121](https://news.ycombinator.com/item?id=20867121)

<comment><AUTHOR> Thank you very much Nairus</comment></comment>


Twitter behavior can predict users' income level - <AUTHOR> http://phys.org/news/2015-09-twitter-behavior-users-income.html <comment><USER2> I can't say much of this is surprising, except for the bit about fear. Any thoughts about what would cause this?

<comment><USER3> Yes.

> for example, those who earn more tend to express more fear and anger on > Twitter.

That is to be expected. If you know your r/K selection theory, K individuals have larger-than-average amygdalae which is responsible for awareness, risk- assessment and consequentially fear.

K individuals in human beings are those who aren't promiscuous, marry early and have kids, and by consequence are infinitely less likely to be poor.

> Perceived optimists have a lower mean income.

This also makes sense, since r-individuals in human beings are more welcome to hope and change (optimism), and they tend to be less well-off financially since they switch their survival needs onto K-individuals (demanding help from them for paying their student loans, providing food stamps, etc).

</comment></comment><comment><USER4> Something as benign as your user agent, previous browsing activity, or individual site cookie can predict income more accurately than a regressional analysis of salary data as compared to twitter themes.</comment>