Alphabet overtakes Apple to become most cash-rich company - <AUTHOR> https://www.theverge.com/2019/8/1/20749831/alphabet-google-apple-cash-reserves-richest-company <comment><USER2> This reminds me of a talk I watched with Peter Thiel and Eric Schmidt. I know Thiel is controversial, but he was well-meaningly digging at Google for running out of ideas and no longer innovating.

The criticism was something like "You have so much cash on hand but no ideas to invest in. However, you can't pay a dividend because the second you do, you're admitting you've run out of ideas and are no longer innovating".

I think that may be somewhat of an overstatement, but given news like this, Thiel's got a point? Buying back their own stock (As mentioned by another commenter in [1]) is a better investment of that cash instead of investing in newer technology? Please prove me wrong with a good counterpoint because I don't want to believe its true.

The specter of technological and scientific stagnation that Thiel/Weinstein (Right and Left wing individuals) talk about so much really scares me.

[1]: [https://www.bloomberg.com/news/articles/2019-07-25/alphabet-...](https://www.bloomberg.com/news/articles/2019-07-25/alphabet-..).

<comment><USER3> This argument relies on a fallacy of binary thinking: either you have ideas or you don't.

It's perfectly fine to say that you have lots of investment ideas, but they don't add up to needing $100 billion to implement them. Especially when you are earning more cash every quarter.

<comment><USER4> Exactly, just because you have a lot of cash doesn't mean you should force investment into things that may not make sense. It's like if you had a huge buffet and force fed yourself until you threw up. If anything, Google probably gets flak for having too many ideas and being all over the place. People keep saying they need more focus, yet when they do that, they get accused of not having any more ideas...

<comment><USER5> Investors and board members would be way more wary of how the company is run if Google decided to do drastic things outside the scope of their core business (like Google Amusement Parks) for superfluous reasons, which would further make them lose money is the stock sinks.

At Google's size they can invest a lot in R&D and product iterations, but because they are so big the innovation seems way less drastic relative to their size. Put it this way, if I put a new motor, deck, and paint on a small boat, it would seem like I did a lot, whereas if a giant cruise ship did the same thing, it wouldn't really carry the same impact to outside viewers.

<comment><USER4> I mean, at the alphabet scale, they have pretty wild stuff like waymo, loon, verily, calico, wing, etc. Even at Google, there's pretty cool tech too like stadia, soli, duplex, and so on.

</comment></comment></comment></comment></comment><comment><USER6> Finance 101: Being cash-rich is a major advantage in environments where fundraising is a major hurdle, and where the funds can be put to productive use very quickly. For example, for a startup to raise funds for a major marketing campaign, it has to go through a lengthy and attention-demanding process of pitching to VCs and negotiating terms. Hence why having a big war- chest ready to fire, can be a competitive advantage for a startup.

For big public companies, it's the opposite. If a company wants to fundraise 10% of its market-cap, either for an acquisition or major investment, it doesn't require nearly as much effort. It can issue new shares, and immediately sell them to investors the next day for cash. The hard part is finding profitable investments, not raising the funds to make it happen. Hence why there's little competitive advantage in hoarding cash.

On the flip side, having a big cash hoard is bad for your investors' returns. It bloats your market-cap, without having any impact on earnings. This means that your P/E ratio is now inflated, and your earnings yield is reduced. From an investor's perspective, if you have invested $100 in the company, you're only only getting back $6 in profits every year, not $7 or $8.

Another way to look at this, is that Google/Apple invest their cash hoard very conservatively, in things like short-term treasuries, because of which their returns are very low. Whereas most of their investors would far prefer to invest the money in investments that produce better returns, such as the S&P 500. By not returning the cash hoard to its investors, Google is essentially forcing them to make low-return investments that they would never make otherwise. Of course, investors aren't going to be happy with this, and they will retaliate by lowering their valuation of GOOG stock, thus depressing the share price.

<comment><USER7> Ya, that's finance 101. But here's Finance 5400:

Smart, wealthy shareholders love cash hoarding. Especially if the cash is held tax free in overseas accounts.

The share price is boosted allowing them to get returns in the form of pure capital gains.

If the company were to pay dividends, sure, most of those dividends would be taxed at capital gains rates as well. But that money has to be taxed at the highest US corporate income tax rate first. Thus, significantly reducing overall value.

To go a step further, the wealthy don't even have to cash out their shares as the price climbs and climbs. They can get low interest loans using the shares as collateral. This deferring taxes indefinitely and leaving all their capital in these huge companies that are outperforming the SP500 anyway.

<comment><USER8> Dividends at taxed at income tax rates

<comment><USER9> In the U.S., if you've held the stock for at least one year, its dividends are taxed at a very favorable _long-term capital gains_ rate. Stock held for less than a year is however taxed like regular income.

<comment><USER7> It's not that favorable if all the corporate cash is stored overseas in low tax holding countries.

The corporation will have to repatriate the money and pay corporate income tax on it before they give you your dividends.

Alternatively, they could just grow that hoard of cash and let your stock appreciate after which you can sell a few shares and get capital gains rates on capital that didn't have to be double taxed.

</comment></comment></comment></comment></comment><comment><USER3> Probably not coincidentally, they also just announced a plan to buy back $25 billion.

[https://www.bloomberg.com/news/articles/2019-07-25/alphabet-...](https://www.bloomberg.com/news/articles/2019-07-25/alphabet- sales-top-analysts-estimates-calming-growth-concerns)

</comment><comment><USER10> In StarCraft, you always want to be at 0 minerals and 0 gas because that means you are maximizing your investment into buildings and units. People make fun of you if you don't have the skill to optimize for this.

<comment><USER11> Google is clearly ultra late game zerg. They are floating minerals, gas, and larvae to remax on a tech switch. This analogy is holding up surprisingly well.

<comment><USER12> Apple is about to drop their mineral line

</comment></comment></comment><comment><USER13> It's important to note that what they really mean is most cash-rich of companies for which public information is available. There are some state owned enterprises around the world that might be able to beat this amount of money even if they don't have the name recognition of Google or Apple.

Saudi Aramco may soon be publicly traded, so we have some information on them, but what is interesting is that while we know they are more profitable than Alphabet, we aren't sure exactly where they are putting all their money. It could be going to a holding scheme that could very well top Alphabet in terms of cash on hand.

There is probably a Russian entity that gives Alphabet a run for its money as well.

</comment><comment><USER14> This will come out as pure whining and probably off-topic, but how on Earth can they can have so much money (in cash no less) and at the same time can't sell some of their flagship products worldwide?

We're halfway through 2019, I'm sitting in a small eurozone country and still can't give them my money and order a Google Pixel properly from their site. Using this example because I consider a phone to be a relatively expensive device that probably generates a good profit over its lifetime. Other non- hardware products which produce smaller profits, such as activating a magazine subscription on the Google News application probably don't even register on their radar.

Apple, with all its failings, is always there and never misses the opportunity to ring the cash register. Sometimes they move slowly, but always make it eventually. Won't even go to non-hardware players like Netflix.

Come to think of it, maybe having so much cash is a mixed blessing for Alphabet, because it could be the actual cause if the above mentioned behaviour.

<comment><USER15> Presumably because making that product available in your region is not an NPV positive investment.

<comment><USER16> Most likely nothing Google makes other than their ad platform could be considered positive investment.

</comment></comment></comment><comment><USER17> Personal conspiracy theory: these tech companies are sitting on their piles of cash waiting for the next recession so they can go on a shopping spree for all the cheap startups unable to raise any further rounds and unprofitable IPO'd unicorns crashing on the stock market

<comment><USER18> That's not a conspiracy theory

<comment><USER19> And not even personal. I share it myself. :)

</comment></comment></comment><comment><USER20> Apparently Berkshire Hathaway has even more: $122B vs. Alphabet's $117B:

[https://www.bloomberg.com/news/articles/2019-08-03/buffett-s...](https://www.bloomberg.com/news/articles/2019-08-03/buffett- s-cash-pile-hits-record-as-berkshire-holds-122-billion)

</comment><comment><USER21> I've always wondered what Apple does with all the cash it has and this seems like a great place to ask. What do companies do with it all? Is there an article that goes into the details? Is it invested? In what? Hoarded in a bank vault? What precautions are in place for such large amounts?

<comment><USER22> Check out Braeburn Capital: [https://en.m.wikipedia.org/wiki/Braeburn_Capital](https://en.m.wikipedia.org/wiki/Braeburn_Capital)

<comment><USER21> Thank you very much.

</comment></comment></comment><comment><USER23> Why dont Google, Microsoft or Apple start operating more like Amazon? these companies have so much cash that thet could literally start 100s of startups within with small teams just like Amazon is doing.

<comment><USER24> Amazon still has >$40B in cash. Sure Google has 3x that, but it's still within spitting distance.

</comment></comment><comment><USER25> Google had a Earnings Per Share of $14.21 in the recent quarter. Google can return a dividend or share buyback of up to that amount. They can say that they have plenty of good ideas and are working on them but just don't have $20 Billion dollars worth of good ideas. Apple and Microsoft are strongly viewed companies that give dividends.

Due to the 3 classes of Alphabet shares, I'm not hanging my hat on this happening due to how voting rights are structured. Probably won't happen with Facebook or Snapchat either for the same reason.

</comment><comment><USER26> Maybe they can just convert a bunch of their contractors to fulltime and create new customers for their Pixel phones, Chrome laptops- like Ford did 100 years ago.

</comment><comment><USER27> [http://archive.is/5srXe](http://archive.is/5srXe)

</comment><comment><USER28> Imagine if someone will create an ideal ad blocking service.

How much wealth will be wiped out ...

</comment><comment><USER29> I feel like this perfectly makes the case for Andrew Yang.

</comment><comment><USER30> This is USD?

I know it seems like a doomsday scenerio, but if the US goes through a moderate hyperinflation, do these companies die?

<comment><USER31> If the economy was hyper-inflating large institutions and corporations would be the first to trade their cash for other securities and assets like real estate.

</comment></comment><comment><USER32> Apple has used most of it on share buybacks, while alphabet has most of it locked up in Gov't bonds

<comment><USER33> Alphabet just announced a buyback a few days ago: [https://www.bloomberg.com/news/articles/2019-07-25/alphabet-...](https://www.bloomberg.com/news/articles/2019-07-25/alphabet- sales-top-analysts-estimates-calming-growth-concerns)

<comment><USER32> Yeah but much less than Apple</comment></comment></comment>


Wordpress 3.2 drops support for PHP 4 and MySQL 4 - <AUTHOR> http://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/

<comment><USER2> This is great news. Many applications stopped supporting PHP4 in 2008, and the last release of MYSQL 4 was in March of 2005. Supporting legacy tech isn't a bad thing, but at some point we have to stop pulling plows with mules.

</comment><comment><USER3> Wonder if this will improve the experience hacking the code to customise things, which has always been very frustrating.

<comment><USER4> Hacking WordPress is frustrating because it's so poorly engineered, and that won't change for the foreseeable future. It's a sprawling mess of Spaghetti code that's indecipherable without the WordPress Codex and Google Search. But despite all my rage, clients keep asking for it, and it keeps paying my bills.

<comment><USER5> I think you struck on an important point. For clients Wordpress is a godsend. If you quit contracting or the client needs to change developers for one of a thousand reasons there's a massive pool of talent that can step right in and make adjustments. I've taken over Wordpress sites and the learning curve is almost flat (save a few weird plugins). Anyways, it's a whole lot better of a situation for clients, developers and productivity in general than the days when everyone had a custom framework that solved the same basic CMS issue.</comment></comment></comment>


RHUL: Particle Accelerator Modelling Tool - <AUTHOR> https://twiki.ph.rhul.ac.uk/twiki/bin/view/PP/JAI/BdSim <comment><AUTHOR> Just went to a great talk about building/simulating particle accelerators @ Royal Holloway University by Dr Laurie Nevay this is a link to the team wiki and source code for the simulation tool.</comment>


Decisions, Decisions or Why Baskets of Options Dominate - <AUTHOR> https://medium.com/@kentbeck_7670/decisions-decisions-or-why-baskets-of-options-dominate-9ac63658b593 <comment><USER2> There is an underlying assumption that a basket of features = sum(individual features). That is true sometimes, but other times a bunch of features launched together have a compound aggregate value - they're much more valuable launched together than individually.

But for cases where that's not true this is an excellent insight.

The part I didn't understand was the P50. Why do you get a demerit if you do 100% of everything, and how is discovering and solving an objective discovered along the way encouraged? I would love if the author or someone else explained it to me. Overall a great article.

Bit of advice: I'd mention early in the article and/or the title that this will apply to product thinking. I was curious about the financial part and pleasantly discovered that it uses this learning in product development - though way far down the page, I almost didn't finish reading it.

<comment><USER3> "P50 goals address sandbagging."

Hitting 100% when the expectation is ~50% means implies a really bad estimate, or that the estimates were a lie, probably in an attempt to look good.

<comment><USER4> Which on the face of it almost seems reasonable; but it seems that this would just introduce another form of sandbagging.

"What are your goals for this quarter?"

"Make the color of the button to be green instead of red and World Peace"

</comment></comment></comment><comment><USER5> Author makes a good point, but wouldn't the cost of decisions map to the options analogy as the cost of the option, which has to be paid no matter if you exercise or not?

I'm no financial wonk but in his example if the $1 stock has a $.1 option and holding the stock has an up/flat/down outcome of +$1/0/-$1 the option scenario goes from +$1/0/0 to +$.9/-$.1/-$.1. If the outcomes are evenly distributed expected value for holding is 0 and for the option goes from $.33 to $.23. It's still positive if the option is cheap enough. Back to the project planning metaphor maybe a road map has a single option cost but weekly cycles are a series of options that eat away at your expected outcome.

</comment><comment><USER6> Sounds like the "premium paid" on a basket of options is realized in more decisions. Quote: "The shift to options on baskets is consistent with people trying to minimize the number of decisions they make."

</comment><comment><USER7> Instead of saying that a basket of options is a minimization of decisions, I would say that it's admitting that most decisions are answered with a series of statistical odds. If you can play a game where you think that the system has missed the boat on some small chunk of statistical possibility, for instance, if you think that the market is missing the potential for wealth in genetic analysis with artificial intelligence, then you push some moderate percentage of additional wealth or leverage in that direction.

This is the actual state of the world. Most real world decisions aren't actually yes/no. It's probability analysis, which is a far more difficult yet more accurate model of decision making.

</comment><comment> t-h-e-chief It is a very interesting topic and a good article. I did prefer Don Reinertsen's discussion of it though (I was lucky enough to see and meet him at a Yow! conference in Melbourne)

There is a video of the talk here: [https://www.youtube.com/watch?v=wyZNxB172VI](https://www.youtube.com/watch?v=wyZNxB172VI)</comment>


How to create more qualified candidates for tech jobs - <AUTHOR> https://medium.com/teaching-learning/ec022871a473

<comment><USER2> Immersive Software Apprenticeship.

Programs similar to Hack Reactor and Flat Iron are trying to solve this problem as we speak.

[http://hackreactor.com/](http://hackreactor.com/)

[http://flatironschool.com/](http://flatironschool.com/)

</comment><comment><USER3> Agreed. We had a summer intern who is a CS major. There were a multitude of things that he had little to no experience in that are fundamental pieces of software engineering (things like version control, deployment environments, bug tracking, testing, DRY, etc). He was a smart guy so he picked things up, but would be great to have an academic grounding for this. I saw something similar at the grad level: [http://ecee.colorado.edu/~swengctf/](http://ecee.colorado.edu/~swengctf/) but haven't heard of any undergrad programs.

</comment><comment><USER4> Stanford's step towards addressing this:

[http://startup.stanford.edu/](http://startup.stanford.edu/)</comment>


Foursquare Hypertrending - <AUTHOR> https://enterprise.foursquare.com/intersections/article/introducing-hypertrending/ <comment><USER2> The visualization of the data is aesthetically pleasing, but I can't help but think "forsquare is around still" while looking at it.</comment>


Android in 2013: See how Jelly Bean took over the world - <AUTHOR> http://blog.getinch.com/infographic-android-version-history/

<comment><USER2> JB: almost 50 percent increase in one year.</comment>


Solution to Leetcode's Remove Duplicates from Sorted Array II - <AUTHOR> https://medium.com/@codechunkers/solution-to-leetcodes-remove-duplicates-from-sorted-array-ii-62deced592a1 <comment><AUTHOR> just published an article that explains how to solve Leetcode 80 which is to Remove Duplicates From Sorted Array</comment>


Twitter Halts User Verification Process, Saying It's 'Broken' - <AUTHOR> https://www.bloomberg.com/news/articles/2017-11-09/twitter-halts-user-verification-process-saying-it-s-broken <comment><USER2> Hmm.. if they claim that the blue tick is the sign of a verified account (not an important or exclusive account), then they should simply open up the verification process for everyone - not just important people. Ask for proof that you are who you claim you are in the twitter handle and lock down the handle and identity description from any changes once verified.

</comment><comment><USER3> The verification process should really be for everybody. Nowadays trolls or bots go after anybody and everybody with fake almost libelous accounts.

I suspect they have more important things going on after deactivating President's Twitter by a disgruntled employee.

Then the increasing the tweet character limit also seems like a bad move. I'm really questioning leadership at twitter. I don't mean Jack alone,since I doubt he is responsible for everything.

</comment><comment><USER4> I guess it took verifying a racist nazi and the ensuing lambasting of Twitter to get them to "review" the process. Funny how that's what it takes for Twitter and Facebook to ever change.

You'd think less horrific mistakes would get their attention sooner?

Not that this was the worst mistake they made this week - that would be increasing the tweet character limit.

<comment><USER5> I remember if you have a common name, that a celebrity also has, it is a better chance that they flag you as a troll or spammer and make you enter a cell phone number to verify your account.</comment></comment>


Lt. Col William Rankin Ejects Into a Thunderstorm - <AUTHOR> http://www.weatherimagery.com/blog/ejects-into-thunderstorm/

<comment><USER2> The really screwed up part was that once it was all over, and he got to a road, most drivers just passed him by without stopping.</comment>


The Karma system - some thoughts - <AUTHOR>

It seems to me that there are a number of different things that are desirable here at HN.

    Thoughtful posts
    On-topic posts
    Interesting posts
    Informed discussion
 It's clear that we want to reward people who provide thoughtful, on-topic (by some definition) contributions.
It's also, I think, desirable to have people generally do gnome-type work: finding cross-connections, remembering things that have gone for those who don't bother to search, flagging repeats, etc.  (I tend to do that without thinking because I've spent a lot of time on specialist wikis, there such behavior is essential.)
It's also really useful to find those comments that are "good(tm)" in some sense.  That doesn't just mean ones that one might agree with.  It means contributions and comments that enrich one's knowledge and, sometimes, one's soul.
The "Karma" idea doesn't exactly meet any of these.  It's obviously correlated, but it's one number trying to do more than one thing.
It's a well-known phenomenon that as soon as you start measuring somehitng, people adjust to make the measurements "better".  If you measure the wrong thing, you will probably get unexpected, possibly undesirable results. This is especially true of the ICXX (Entrepreneur, Torturer, Inventor, Hacker) types that we get here. ( http://news.ycombinator.com/item?id=443182 )
There are, I think, two fundamentals: "Value" and "Agreement".  The single value of "Karma" is conflating the two, and always will.  I can see no way to prevent that except via culture, and as HN grows, that won't work well.
Some measure of the rate of acquisition of karma might be useful, but there is still the risk that I'll only end up seeing the comment and submissions that the collective "agrees with" in some sense.
In short, usage will emerge, and all anyone can do is try to make the system - whatever it may be - simple, clear, and clearly correlated with those things that are desirable.  The current system mostly works, and tinkering might simply make it brittle, and easier to game.  Personally, I want to find comments by people I've come to trust, without necessarily agreeing with.  My assessment won't necessarily agree with yours, so we end up with a system that has to record individual preferences.  I think I know how to do that.
But is it worth it? <comment><USER3> I think we need to take a break from all the meta-discussion and let the new changes sift through to see how they work out. If they have a detrimental effect, let's discuss again in a few weeks... until then, I would suggest not posting any more meta-discussion posts about the karma system.

<comment><USER4> Or at least keep it all in the original thread ( <http://news.ycombinator.com/item?id=467181> ).

</comment></comment><comment><USER5> I'm far more annoyed by navel-gazing posts about the karma system, than I have ever been by the quality of the comments attached to the posts. If there is a major drawback to the "orange name" phenomenon that I can see, it's that it has given people yet another reason to explicitly start discussions about karma.

<comment><USER6> Easy for you to say - you've got an orange name. ;-)

I agree with you. There's no point to starting new threads about this that are essentially glorified comments. You're allowed to write a good long comment, you know. It actually makes commenting a bit better for all of us.

</comment></comment><comment><USER7> The thing that you are talking about is already in place in a very famous social bookmarking site - stumbleupon.com. It works on exact same principal - "Personally, I want to find comments by people I've come to trust, without necessarily agreeing with. My assessment won't necessarily agree with yours, so we end up with a system that has to record individual preferences."

It categorizes all the links marked and over a period of time it will show your surfing preferences. Every user has a profile and you can visit their profiles and view their preferences and subscribe to their 'stumbles' - <USER2> they liked.

The thing that's missing on stumbleupon is the discussion culture that present on HN.

</comment><comment><USER8> I think quality of HN comments would improve, if it has a

RED vote = TRUTH (Past & Present Context)

GREEN vote = HOPE (Positive Future from Win-Win Context)

YELLOW vote = OTHERS</comment>


The seL4 microkernel - <AUTHOR> https://github.com/seL4/seL4 <comment><AUTHOR> Please note that the formally proven model has been implemented also in Haskell, not only in C.

Formally-proven-correct code + Haskell + literate programming = [https://github.com/seL4/seL4/blob/master/haskell/src/SEL4/Ke...](https://github.com/seL4/seL4/blob/master/haskell/src/SEL4/Kernel/Thread.lhs)

</comment><comment><USER2> seL4 is "The world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement" originally developed (as far as I know) at UNSW, further developed at NICTA.

The original project home page is at [http://ssrg.nicta.com.au/projects/seL4/](http://ssrg.nicta.com.au/projects/seL4/) and the new page is at [http://sel4.systems/](http://sel4.systems/)

Downloads at [http://ssrg.nicta.com.au/software/TS/seL4/](http://ssrg.nicta.com.au/software/TS/seL4/)

<comment><USER3> This is excellent. While I'm still unsure about the seL4 model being the best for a secure system (a topic for another day), it's wonderful to see this development.

I hope "someone" will port this to RISC-V (32- or 64-bit).

Is [http://ssrg.nicta.com.au/software/TS/seL4](http://ssrg.nicta.com.au/software/TS/seL4) out of date or is the license really not open source (OPEN KERNEL LABS and National ICT Australia Limited (Licensors) NON-COMMERCIAL LICENSE AGREEMENT)?

<comment><USER4> Can you explain why you are unsure the seL4 model is the best for a secure system?

<comment><USER3> I guess today _is_ another day.

The fundamental issue is that, IMhO, security classification needs to be attached to the data at the lowest level -- OS level is simply to coarse. Take for example an encrypted channel. At the OS level the channel is treated opaquely whereas at the programming language level, after decryption the authenticated data can be assigned both a different level of secrecy and trust, and it can be data dependent. Strong type systems can ensure that secret data is never accidentally leaked, nor untrusted data used in a trusted context. (For a real-life simple subset of this, see tperl).

It may be possible to build such a system on top of seL4, but seL4 isn't sufficient.

I do intend on working on this eventually. Incidentally, D. J. Bernstein recently shared a similar complaint about the state of security - the models we use have practically not advanced since the 1950es.

<comment><USER5> You should have a look at the literature on capability security, especially [http://www.erights.org/elib/capability/duals/myths.html](http://www.erights.org/elib/capability/duals/myths.html)

There was hardly any computer security in the 1950s: it was before time sharing and networking. Your cynicism is over-done.

</comment></comment></comment></comment></comment><comment><USER6> This link to the GitHub repository doesn't give a lot of the context about why this is exciting.

As others have mentioned, seL4 is "The world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement." But for many years it was proprietary, and only available under commercial terms. The paper was published in 2009, so it's been five years that it was proprietary.

As of today at noon, the kernel was released under GPLv2 and userland under two-clause BSD. That is exciting.

<comment><USER7> "The world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement."

And as soon as one person makes a commit, that proof is invalid right?

<comment><USER8> Maybe they have automatic theorem prover running on Jenkins and they just refuse to merge changes which would be proven to be wrong? Anyway, I'm going to read more about what and how they did, it's fascinating to see a non- trivial software system proven correct.

<comment><USER9> Yes, that's how they did it. Quoting from the paper:

"Note that we have integrated all proofs into an automated proof checking suite, similar to an automated regression-test suite, but using machine- checked formal proofs instead of executable tests. This provides an automatic check, after each commit into the version control system, of the state of all the existing formal proofs, and identifies which specific portions of the proof must be re-established."

</comment></comment></comment></comment><comment><USER10> There was a project way back when to port Darwin to L4: [http://www.ertos.nicta.com/software/darbat/](http://www.ertos.nicta.com/software/darbat/)

along with the accompanying rumor that Apple would be "lifting" Mach's layer in XNU to run on top of L4. That was before the iPhone, of course.

I was always fascinated by the talks of L4 being specifically designed to avoid scrubbing your L1/L2 cache on operations such as IPC.

</comment><comment><USER11> Can someone explain to me what it means for a kernel to have an end-to-end proof of implementation? Does it just mean that the kernel is implemented bug- free? That it will never panic?

<comment><USER8> It won't. See here: [http://sel4.systems/FAQ/#verif](http://sel4.systems/FAQ/#verif)

It's actually a very impressive piece of work, I can't wait to read about the details of how it was done.

<comment><USER9> Then go read [http://www.nicta.com.au/pub?id=7371](http://www.nicta.com.au/pub?id=7371) :)

</comment></comment></comment><comment><USER12> I don't suppose anyone has, or know where to find, a generated pdf of the extensive Latex documentation? My own pdflatex skills are failing me. :/

<comment><USER13> Conveniently enough, I just generated myself a pdf of it: [http://avacariu.me/files/seL4-manual.pdf](http://avacariu.me/files/seL4-manual.pdf)

<comment><USER12> Thanks

</comment></comment></comment><comment><USER14> It's great to see more and more stuff come out of NICTA. For those who are unaware, it is a government funded research institution in Australia. A big difference from other research institutions is that they are especially focussed on commercially viable research (rather than purely theoretical stiff - although I'm sure they do some work on that too). It is a model that has been used for quite some time on Aus, with the CSIRO doing the same thing for more general (I.e. not specifically ICT) research. The CSIRO has done some beautifull research which forms the backbones of technology such as WiFi. So, putting aside recent budgetry and financial issues, it is great to see stuff like this being released by them. Here's to many more years of fruitful research.

</comment><comment><USER15> From the supported platforms it looks like it should work on a BeagleBone Black (arm, am335x, armv7-a, cortex-a8)--anyone been brave enough to try?

<comment><USER16> AFAIK the beaglebones load their entire executable environment, including bootloader, from removable flash media - there shouldn't be any bravery required to test out experimental software (even bootloaders and firmware) because you can always just swap out the entire card. There's no bricking them.

<comment><USER17> Yep, they can either load from removable flash (microSD) or from onboard eMMC flash storage, selectable by switch on boot.

</comment></comment></comment><comment><USER18> Is there any recent benchmark of an L4 implementation with servers compared to a modern monolithic Linux or *BSD kernel? I'm still thinking there's huge untapped potential in microkernels and I wonder how the "state of the art" stacks up against modern monolithic kernels on processors with a lot of cache.

</comment><comment><USER19> An OS that is proved to be essentially perfectly secure? For some reason this brings up thoughts of trusted computing, and not in a good way...

<comment><USER20> You seem to be misunderstanding the kind of security this is about. It's not about taking away control by the owner, just about preventing ways of control by third parties that you as owner didn't intend to give.

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

> TC is controversial as the hardware is not only secured for its owner, but > also secured against its owner.

Whereas here if you're not happy with what the OS does, you can wipe it and still have full control over the hardware. And the OS is OpenSource, accessible to the hardware owner to modify if some kind of control it asserts isn't satisfying.

<comment><USER21> Not the parent commenter, but: A proven kernel could be seen as taking control away on devices where root access cannot be legitimately obtained. I guess some might perceive it as scary given many people in tech circles root their phones (and similar devices), when root access is normally obtained through OS-level security bugs, and it is often (though I think somewhat decreasingly?) used to install third-party OSes on such devices.

<comment><USER20> Agreed, although the blame then still lies with the device the secure kernel is running on, or the company that produces it, or the client for choosing to buy it.

I guess you can say that proven software is power, and power can be misused.</comment></comment></comment></comment>


Ask HN: Do you think AI will be key for solving the problems mankind faces? - <AUTHOR>

I have been studying a lot about artificial intelligence, more precisely machine learning, and I am fascinated with all the possibilities. AI can help solve hard problems in our society.
From business problems, marketing, autonomous machines, to health related problems, AI seems to fit into everything. I have been amazed by all the new possibilities smart machines can have in order to help us improve our lives.
I am curious to know what you all think about this subject? Do you share the same excitement as me? <comment><USER2> Yes, but it's only as good as people's willingness to trust it. Look at the 'skeptical' response to climate change, where an imperfect but still quite impressive body of scientific work is dismissed as little more than hocus- pocus by people who feel their economic interests to be threatened by the obvious strategic responses.</comment>


Think You Understand the Single Responsibility Principle? - <AUTHOR> https://medium.com/@jim_ej/you-dont-understand-the-single-responsibility-principle-abfdd005b137 <comment><USER2> No, because it's too vague to be applied in any sensible way.

<comment><AUTHOR> I know what you mean, but every time we build a class, we have to decide how much functionality to contain within it, so something will be guiding us in that decision as to where to draw the boundary.</comment></comment>


Backbone and Angular: Demystifying the myth - <AUTHOR> http://www.nebithi.com/2012/12/27/backbone-and-angular-demystifying-the-myths/

<comment><USER2> The battle is not only between Backbone and Angular, there is place for more innovation. I prefer Angular approach (As you say: "Less code to write means less code to test means less code to debug means less code to maintain. It also means a lesser page-weight at the end of the day." ), but we are putting our passion to create a framework for complex applications (something in line with Angular but with better features) While still beta, we already have models that are doing type checking, better/maintainable code, correctness against asynchronous effects caused partially by the declarative style we love and simplify the code so much,etc: <https://github.com/salboaie/shape/>

I believe that Angular is still at the level of creating nice sites but not for big applications. We are trying to compensate JS weaknesses with features for big enterprise applications (boring CRUDs, sloppy and not so motivated developers for working on bigger enterprise applications).

We need all possible help from other programmers with code, tests, real life prototypes, help from native English speakers to create good documentation, to get infected with our passion and to speak about the framework to other developers, etc.

I know that it is a hard battle but it is a pleasure to work for such ideas anyway.

<comment><AUTHOR> Your project seems interesting. Until you create a sample application that shows off the good things about your framework, I cant comment much. Perhaps an article from you or someone else involved in the framework would be a good starting point? Perhaps a framework show-off?

If you want to do one even better, how about writing another article Angular vs Shape? :)

<comment><USER2> You have the classical todo MVC on github. In the first days next year I will send to people managing the official todo project but if you get the project, put on a web server, you can quickly run the todo project.

<comment><AUTHOR> I had a look at your todo-app. I did not get 100% of what you are doing but your project looks ambitious ( which I think is good! )to say the least.

One of the problems with ambitious projects is that getting adoption is kind of hard because people's inertia is directly proportional to the amount of change. I suggest you come up with compelling reasons to switch to this framework ( maybe better IDE support since type's is such a big part of your framework? ). I guess a video with a famous IDE providing code-completion seamlessly with your framework would work very well. Or how about rewriting your framework in typescript? Then your's will be the first Typescript framework and hence adoption will be easier.</comment></comment></comment></comment>


Is it possible to keep websockets connected on Node.js server restart? - <AUTHOR> <comment><USER2> I don't see how; they're attached to the Node process. You could _reconnect_ , but that may be it. I'm curious to find out if you hear differently.

This might also be a good question for Stack Overflow.</comment>


NPM module to prevent use of eval() in JavaScript - <AUTHOR> https://asciifaceman.github.io/noevaljs/ <comment><USER2> This is so important to JavaScript. This changes everything. This makes me weep with joy. To see a language conceived in 10 days by a bunch of caffeined- up Netscape engineers evolve into something like this is just... I'm feeling very emotional about this.</comment>


Creating a successful new online product - 13 tips - <AUTHOR> http://www.inter-sections.net/2008/05/07/13-tips-for-creating-a-successful-new-online-product

<comment><USER2> "The smaller the niche, the lower the bar to success."

And the smaller the success. Careful how small you go. Avoiding competitors is kind of admitting, "I can't build a competitive product, so I'll build a crappy one for people who don't have any alternatives." You may wow your target audience, because no one has ever paid any attention to them, but that doesn't mean you've built a successful business.

An old oil field and platform manager once said to me (after he'd been doing water table research work for municipalities for a few years), "You're going to bust your ass no matter what. You might as well bust your ass for $10 million as for $10 thousand."

Y'all can take all the 10 thousand dollar markets you want...I'll be over here working on cracking a billion dollar (and growing) market. I might not come out on top of the heap...but even second place is going to be a pretty penny.

<comment><USER3> Success in a small niche can enable success in a larger niche, which in turn can enable a larger success. One of the properties of a market niche (or segment) is that the members reference each other's buying decisions (in other words one member will be influenced by another member's testimonial). If you get to critical mass in a niche (typically about 1/6) before anyone else, then your marketing costs go down and your customer acquisition becomes easier. There is a lot of benefit for aiming at a small niche to get started, and it doesn't preclude serving a larger market later. By the way, 1% of a large market is a recipe for extinction. You have all of the cost of trying to reach a large market recouped over a tiny customer base.

<comment><USER2> "By the way, 1% of a large market is a recipe for extinction. You have all of the cost of trying to reach a large market recouped over a tiny customer base."

This is actually a different argument. 1% of any market is a recipe for extinction...but less so in a larger market. The problem with the "even if we only get 1% of the market we'll make X million" fallacy is that reaching each new customer costs a certain amount--it doesn't matter how many potential customers there are...you have to community your product and its benefits to each of them individually. In the end, every sale is an individual sale...you have to convince someone somewhere that your product provides greater value than its cost to them (even if it is free, they have to learn to use it, remember to come back, etc.).

I don't believe this really counters anything I've said above. There are plenty of niches that are so small that they won't even support a lifestyle business of two or three people in comfort...sure, you won't have many competitors, but you also won't get any vacations or live very large. In many tiny niches you'd probably even have to have a real job to make ends meet.

My argument was, and remains, "be careful how small you go".

<comment><USER4> Please tell me that "community" was just a typo of "communicate" and that you didn't really use it as a verb.

<comment><USER2> Typo, and past the edit period.

</comment></comment></comment></comment></comment><comment><USER5> It's funny, I think I have made all the mentioned mistakes up to number 8 over my 10 years of web development. I learned the hard way, and I can tell you that those are really great advice.

Point 1, 2, 4 and 12 are especially important. Developing a prototype quickly and and including the end user as early as possible make a huge difference in the success level of a project.

</comment><comment><USER6> "Creating a new, successful product is like writing a book, creating a movie, or raising a child. It's a fiendishly complicated task that requires great adaptability creativity. Rules can only get you so far. No amount of advice can guarantee you success. Sometimes, the rules fail, and you need to adapt to those situations and do what needs to be done, even if it flies in the face of accepted wisdom. For every rule of product development, there is a dozen examples of teams which did it differently and still succeeded."

</comment><comment><USER7> _You don't need job adverts, you don't need resumes, and you don't need contract negotiations. What you need is to network..._

I think I'll specifically avoid the shmoozers, thanks.

<comment><USER8> Networking doesn't necessarily mean schmoozing. It means hanging out with the folks who are in the same field as you and going to the same events they do. Most of the time, they'll have the same interests as you, so these'll be the folks you want to hang out with anyway.

Posting on news.YC or programming.reddit counts, for example.

<comment><AUTHOR> Absolutely. By networking I (I'm the author) meant putting yourself in situations where you will meet the kind of people you want to be working with and become friends with them.

If you go there with a pure agenda of "recruiting a co-founder", people will sniff you out and you won't make any friends. But if you go there to meet people in the community you probably will, incidentally, meet some who might end up being your cofounders.

Daniel

</comment></comment></comment><comment><USER9> I can list a whole lot of successful web-based companies that don't fit many of this guy's criteria. I'd suspect this was a DHH sock puppet writing it except that he thinks that small businesses on the web are a lousy market, and DHH's success with Basecamp probably proves otherwise.</comment>


I built this to help me find the perfect music for working out (mainly jogging) - <AUTHOR> http://jog.fm

<comment><AUTHOR> If you have any questions or tips, please let me know. I'm constantly looking to improve the site. I'm thinking of expanding it beyond just music and into all things jogging (or exercise).</comment>


Show HN: Benchmark your AngularJS application easily - <AUTHOR> https://github.com/RobinBressan/ng-benchmark

<comment><USER2> The benchmarks could be misleading, given that it stores a reference to the element and attrs - I'd expect it to possibly mess with the garbage collecting, thus not giving you a true benchmark.

</comment><comment><USER3> fyi you can do Date.now() instead of new Date().getTime()</comment>


How We Think with Bodies and Things - <AUTHOR> http://www.youtube.com/user/StanfordUniversity#p/u/147/Vhcubb00g6c

<comment><USER2> I don't think he's got Wittgenstein right. But it's interesting.</comment>


Why The Lucky Stiff's old blog (Aug. 2000 - May 2005) - <AUTHOR> http://www.advogato.org/person/whytheluckystiff/

<comment><USER2> "i love working on an obscure book. people cling to ideas, because they're supposed to be vouchers for a million dollars. no, write an obscure book. build something outside all that pressure. i guess treehouses for kids qualify." - _why 20 Sep 2004

<comment><USER2> Contex: [http://www.advogato.org/person/whytheluckystiff/diary/50.htm...](http://www.advogato.org/person/whytheluckystiff/diary/50.html)

<comment><USER3> There has always been some dark corners in _why's writing, with some dreary biographical detyails permeating.

I 2000-2001, his parents divorced, and his father went through a mental breakdown.

A bit later he writes that suicide would be the only thing preventing him from finishing some work.

Death is present in several chapters of the poingnant guide.

Then comes this: "narco+alco have turned kooky people i love into obliterated people i love. god, god, god, please keep her alive." in the post linked above.

The 4th version of shoes should have been nicked "murder". One of his last tweets was "i thought that RIP was strictly for cremation." ... An I find the Shoes book scary.

-

Overall, his universe wasn't as fun as he tried to present it.

I simply hope he's ok.

</comment></comment></comment><comment><USER4> I liked _why's code, his tools, shoes, hpricot I think was his (it is really a work of art, a truly great library). However I didn't find his writing helpful - never was able to learn anything from it and it mostly got in the way when I tried to search for things when trying to work out how to do something in ruby.

I guess I wasn't his audience, but some awesome libs.

<comment><USER5> I found his writing to be very, umm poignant, i.e: [http://www.advogato.org/person/whytheluckystiff/diary/41.htm...](http://www.advogato.org/person/whytheluckystiff/diary/41.html)

<comment><USER6> Something about that story is very Kaufmanesque.

</comment></comment></comment><comment><USER7> In all seriousness, this is why therapy and medication can seriously help a young person who's addressing difficult issues. When I was working on GNOME, we all knew _why was different. He used to come into #smooth and argue about colors and gradients, and use "beautiful rainbows" as argumentation, rather than progression, style and color theory.

After Reiser and seeing _why in action these last few years, I really think that there is a precedent for a very serious eye to be turned toward mental health in hackers. We spend so much time internalizing, focused into our worlds, that we hardly look outside, even when our colleagues are crying for help.</comment>


Giana Sisters Special Edition is available for download - <AUTHOR> http://pixelglass.org/GianaSistersSE <comment><AUTHOR> Via [https://www.reddit.com/r/amiga/comments/4wq525/giana_sisters...](https://www.reddit.com/r/amiga/comments/4wq525/giana_sisters_special_edition_is_available_for/)</comment>


Why You Hate Comic Sans - <AUTHOR> http://kadavy.net/blog/posts/why-you-hate-comic-sans/ <comment><USER2> The website is a little bit of an eyesore for me. First you've got the low-res white noise background. Then the looming semi-translucent navigation bar that goes behind embedded youtube videos. Then the egregious usage of drop shadows. And to top it all off, there is very little distinguishing headings from subheadings and the subheadings are smaller than the text.

Oh, you can take my ideas with a grain of salt by the way - I'm a cs guy, not a designer.</comment>


Why Python Runs Slow, Part 1: Data Structures - <AUTHOR> http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs-slow-part-1-data-structures/ <comment><USER2> If you're using Python for performance-critical applications, simple use of the integrated ctypes module (uses libffi in background) can make a world of difference. There's a modest performance overhead, but basically you're getting near C performance with proper use of ctypes.

Coincidentally, one of the usual examples given in the ctypes howto is a Point structure, just like in this post. It's simple:

      from ctypes import *

      class Point(Structure):
          _fields_ = [("x", c_int), ("y", c_int)]

Then you can use the Point class the same way you'd use a regular Python class:

      p = Point(3, 4)
      p.x == 3
      p.y == 4

Really, taking a half-day to learn how to use ctypes effectively can make a world of difference to your performance-critical Python code, when you need to stop and think about data structures. Actually, if you already know C, it's less than a half-day to learn... just an hour or so to read the basic documentation:

[http://docs.python.org/2/library/ctypes.html](http://docs.python.org/2/library/ctypes.html)

If you plan to write an entire application using ctypes, it'd be worth looking at Cython, which is another incredible project. But for just one or two data structures in a program, ctypes is perfect.

And best of all, ctypes is included in any regular Python distribution -- no need to install Cython or any additional software. Just run your Pythons script like you normally do.

EDIT: I was just demonstrating how to get an easy-speed up using ctypes, which is included in the Python standard library. To be clear, you would usually use this type of data structure in ctypes along with a function from a C shared library.

Furthermore, if you're serious about optimizations, and you can permit additional dependencies, you should absolutely look at cython and/or numpy, both of which are much faster than ctypes, although they do bring along additional complexity. Other commenters are also pointing out cffi, which I've never used but also bears consideration.

<comment><AUTHOR> This would be one of the approaches to use if you wanted to squeeze the last pieces of performance out of this class. I would recommend using Cython for this though.

The problem with both of these approaches is that, well, use this too often, however, and you suddenly realise you are not really coding in Python anymore.

Also, correct me if I'm wrong, overuse of tricks like these is one of the key reasons why we cannot have nice things like PyPy for all modules.

<comment><USER2> I actually agree with everything you write here. If I could re-write the post to include these points, I would.

I do think PyPy is very near to having full ctypes support, if they don't already.

</comment></comment></comment><comment><USER3> "My experience in working on Graphite has reaffirmed a belief of mine that scalability has very little to do with low-level performance but instead is a product of overall design. I have run into many bottlenecks along the way but each time I look for improvements in design rather than speed-ups in performance. I have been asked many times why I wrote Graphite in Python rather than Java or C++, and my response is always that I have yet to come across a true need for the performance that another language could offer. In [Knu74], Donald Knuth famously said that premature optimization is the root of all evil. As long as we assume that our code will continue to evolve in non- trivial ways then all optimization6 is in some sense premature.

For example, when I first wrote whisper I was convinced that it would have to be rewritten in C for speed and that my Python implementation would only serve as a prototype. If I weren't under a time-crunch I very well may have skipped the Python implementation entirely. It turns out however that I/O is a bottleneck so much earlier than CPU that the lesser efficiency of Python hardly matters at all in practice."

\-- Chris Davis, ex Google, Graphite creator

<comment><USER2> This is the key. Very often, the app is IO bound, and moving to C will make little difference.

This is one reason why I'm very excited about Python's new AsyncIO module in Python 3 only. It's asyncore done right, and is a great way to write network applications. I look forward to seeing what is built on top.

<comment><USER4> > Very often, the app is IO bound

I hear this all the time but it really doesn't square up with my personal experiences. I've had to re-implement dynamic language stuff in C++ many times to get acceptable performance. No real design changes, just straight ports to C++. The entire value proposition of Golang is that the scripting language dynamic type systems are too slow, and it seems like loads of folks agree.

<comment><USER5> That is why they never used Dylan, Lisp, SELF or any other dynamic language with native compilers.

<comment><USER4> Those dynamic languages are only performant when you add a bunch of type information. You wind up writing a simulacrum of C and it still under- performs.

<comment><USER6> The idea is that there is some useful speed for much of the application by using native compilers. Higher speed might be needed only in parts of the program. Then a type inferencer, etc. comes to use. If that's still not enough one calls C or assembler routines - but, say, 95% of the application can be written in Lisp.

</comment></comment></comment></comment></comment></comment><comment><USER7> What I find interesting here is that Python (and most other dynamically-typed languages) treat instances of classes as arbitrary bags of properties, with the negative performance implications of that, _even though that feature is rarely used_.

I'd love to have the time to examine codebases and get real data, but my strong hunch is that in Python and Ruby, most of the time every instance of a class has the exact same set of fields and methods. These languages pay a large performance penalty for _all_ field accesses, to enable a rare use case.

JavaScript VMs (and maybe Ruby >=1.9?) don't pay the perf cost because they do very advanced optimizations ("hidden classes" in V8 et. al.) to handle this. But then they pay the cost of the complexity of implementing that optimization.

I'm working on a little dynamically-typed scripting language[1] and one design decision I made was to make the set of fields in an object statically- determinable. Like Ruby, it uses a distinct syntax for fields, so we can tell just by parsing the full set a class uses.

My implementation is less than 5k lines of not-very-advanced C code, and it runs the DeltaBlue[2] benchmark about _three times faster_ than CPython.

People think you need static _types_ for efficiency, but I've found you can get quite far just having static _shape_. You can still be fully dynamically- dispatched and dynamically type your variables, but locking down the fields and methods of an object simplifies a lot of things. You lose some metaprogramming flexibility, but I'm interesting in seeing how much of a trade-off that really is in practice.

[1] [https://github.com/munificent/wren](https://github.com/munificent/wren) [2] [https://github.com/munificent/wren/blob/master/benchmark/del...](https://github.com/munificent/wren/blob/master/benchmark/delta_blue.wren)

<comment><USER8> Python actually comes static shapes for objects with __slots__

class vertex(object):

       __slots__ = ["x", "y", "z"]

I use __slots__ in most code after the first refactor for a very important reason - I'm a _hyper-caffeinated_ code monkey.

I wasted an entire day because I set self.peices in one place and self.pieces in another & couldn't figure out the bug, until I used the "grep method".

<comment><USER7> Right, but the problem here is you have to opt _in_ to that. The most terse, simple way to express something is also the slowest.

Most classes have static shapes, so for the few types that are more dynamic, I think it makes sense for users to have to opt _out_.

</comment></comment></comment><comment><USER9> It is of cause possible to write a faster Python, as PyPy proves, but some of the design choices in Python does make it hard to optimize. This is not inherently a problem with dynamic languages as the development of Julia proves. In Julia it is easy to write programs that is in the same ballpark as C efficiency wise, while still feeling very dynamic and having a REPL. Pythons problem is that both the interpreter and the language is quite old, and existed before modern JIT technology was developed, so that was not considered when designing the language and the interpreter.

That said, Python emphasis on fast development as opposed to fast running code is very often the right tradeoff, and is why it is so popular.

<comment><USER10> What language features would you have or not have if you designed a language with knowledge of "modern JIT technology"?

<comment><USER11> If I would guess, I would say that you want to design the language in such a way that things such as types are typically easy to guess for the JIT compiler.

</comment></comment></comment><comment><USER12> There's no silver bullet, but NumPy comes pretty close sometimes. Here's an example where I achieved a 300x speedup with regular old CPython: [http://stackoverflow.com/questions/17529342/need-help- vector...](http://stackoverflow.com/questions/17529342/need-help-vectorizing- code-or-optimizing/17626907#17626907)

The trick is often to somehow get Python to hand the "real work" off to something implemented in C, Fortran, C++, etc. That's pretty easy for a lot of numerical and scientific applications thanks to NumPy, SciPy, Pandas, PIL, and more. Lots of libraries are exposed to Python, and you can expose more either by compiling bindings (see Boost.Python) or using ctypes. If you do this well, nobody will notice the speed difference, yet your code will still look like Python.

And sometimes your performance problem is not Python's fault at all, such as this lovely performance bug: [https://github.com/paramiko/paramiko/issues/175](https://github.com/paramiko/paramiko/issues/175) \- a 5-10x speedup can be had simply by tweaking one parameter that is no fault of CPython or the GIL or anything else (in fact, Go had basically the same bug).

What I'm getting at here is that performance is not just one thing, and the GIL is a real and worthy spectre but hardly matters for most applications where Python is relevant. Your Python is slow for the same reason that your Bash and your C and your Javascript and your VBA are slow: you haven't profiled enough, you haven't thought long and hard with empirical results in front of you about where your program is spending its time, your program is improperly factored and doing work in the wrong order, or perhaps you should just throw some hardware at it!

</comment><comment><USER13> The part that really surprised me was this:

      We only had 23 years of Python interpreter development,
      how would things look like when Python is 42, like C?

C, which I always think of as an ancient venerable systems language, is less than twice as old as Python, which I think of as a hot new kid on the block.

In thirty years, when my career will probably be drawing to a close, Python will be 53 years old and C will be 72 years old. Barely any difference at all.

<comment><USER14> > _We only had 23 years of Python interpreter development, how would things > look like when Python is 42, like C?_

Well, mostly like it is today. Maybe a little better, maybe a little slower. Python hasn't progressed much. Compare it to the last 10 years and it's mostly a flatline, if not a slight decline with some 3.x versions.

Whereas C was from the onset one of the fastest or THE fastest language on any machine.

Getting fast is not usually due to some incremental effort. You either go for it or not. If you start from a slow language, incremental changes without a big redesign of the compiler/interpreter never get you that far.

Javascript got fast in 3 years -- not by incrementally changing the Javascript interpreters they had before, but by each of the major players (Apple, Google, Mozilla) writing a new JIT interpreter from scratch. In 2007 it was dog slow, and then in 2008 all three major JS interpreters got fast.

Sure, they have been enhanced since, but the core part was changing to JIT, adding heuristics all around, etc. Not incrementally improving some function here and some operation there.

<comment><USER15> >Whereas C was from the onset one of the fastest or THE fastest language on any machine.

You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly.

<comment><USER14> > _You can 't write performance critical code in C. C is great for high level > code, but if performance is important there is no alternative to assembly._

That statement makes no sense.

Of course you can write performance critical code in C. People write all kinds of performance critical code in C. Heck, kernels are written in C. What's more "performance critical" than a kernel? Ray traycers are written in C. Real time systems are written in C. Servers are written in C. Databases are written in C. Socket libraries. Multimedia mangling apps like Premiere are written in C (or C++). Scientific number crunching libraries for huge datasets are written in C (and/or Fortran).

The kind of "performance critical code" you have to write in assembly is a negligible part of overall performance critical code. And the speed benefit is not even that impressive.

<comment><USER16> That's true _now_ (and perhaps has been true for easily the past fifteen years). But up til the early-to-mid-90s, it was relatively easy for a decent assembly language programmer to beat a C compiler. In fact, it wasn't until the early mid-90s that general purpose CPUs broke 100MHz.

Just be very thankful you don't have to deal with C compilers under MS-DOS what with the tiny, small, medium, compact, large and huge memory models (I think that's all of them).

<comment><USER17> Even now performance-critical code is assembly. Just take a look at your libc's memcpy implementation, for example. Most likely there's a default C implementation that is reasonably fast and a bunch of assembly versions for individual architectures.

<comment><USER14> > _Even now performance-critical code is assembly._

The problem I have with this statement is that it implies other code, like the kernel, a ray-tracer, video editor, number crunching etc, stuff usually done in C/C++, are not "performance critical".

Let's call what you describe "extremely performance critical" if you wish.

With that said, MOST performance critical code is written in C/C++.

Code that's not that much performance critical is written in whatever.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Who would use a dictionary for a point? If it's a 2D grid, you are only going to have two axes and by convention x-axis is always first, and y-axis is always second. Perfect use case for a tuple.

       point = (0, 0)

<comment><USER19> It's just an example. There are many cases where you need more than what you can safely stuff into a tuple, which means the choice becomes 'naked dictionaries vs. classes', it's a tradeoff I've had to make many times writing python code.

Of course there are many cases where using tuples is the best way to represent some data item, (x, y) point data is an obvious example. But when your data structures become more complex, need to be mutable, need to have operations defined on them, have relations to other objects, etc, tuples are a bad choice. You don't want to end up with code that uses tuples of varying lengths, composed of elements of varying types, consumed and produced by functions that are hard-coded to rely on the exact length, ordering and element type of their their tuple inputs. Named tuples are one step in the direction of dictionaries, but they are still nowhere as flexible as mutable dictionaries or proper classes.

<comment><USER20> If you can't use a tuple, it's not like you could have really used a C-struct either. So the point is valid - the code should be using tuples and not dictionaries or classes.

<comment><USER19> Again, I assume the article only served as an example of how in Python you usually end up using dictionaries or classes, which have fundamentally different performance characteristics compared to C-structs. Yes, you could use tuples instead, in some cases, and get performance characteristics comparable to C structs. Often this is not an option though, and you would still have to use classes or dictionaries. There are many scenarios you could conveniently implement in C using structs, that would end up as an ungodly mess in Python if you would implement them using nothing but tuples.

Just as a thought exercise, try to come up with a way to represent and manipulate an hierarchical, mutable C-structure with 20 fields, using nothing but tuples in Python.

<comment><USER21> Like... named tuples? That's the nice thing about python, you're not restricted to using one data type. If you have a data structure that doesn't change, and speed matters, you can use something better suited to the task at hand.

Of course, you're not restricted to using one datatype in C either, but the constant comparison this article makes between structs and dictionaries is misleading. Comparing hash map implementations with dictionaries would be much more apt.

<comment><USER22> named tuples are classes, but they use __slots__ so they are sealed to extension thus using less memory. Take a look at the `namedtuple` source, it is a fun little bit of metaprogramming.

[http://dev.svetlyak.ru/using-slots-for-optimisation-in- pytho...](http://dev.svetlyak.ru/using-slots-for-optimisation-in-python-en/)

[http://hg.python.org/releasing/2.7.6/file/ba31940588b6/Lib/c...](http://hg.python.org/releasing/2.7.6/file/ba31940588b6/Lib/collections.py#l228)

I am _wrong_. namedtuple does NOT using slots. weird, wonder why?

Because it directly subclasses `tuple`

point = namedtuple("Point","x y z",verbose=True)

[http://blip.tv/pycon-us- videos-2009-2010-2011/pycon-2011-fun...](http://blip.tv/pycon-us- videos-2009-2010-2011/pycon-2011-fun-with-python-s-newer-tools-4901215)

</comment></comment></comment></comment></comment></comment><comment><USER23> The pythonic way of creating a Point like data structure is not

      point = {'x': 0, 'y': 0}

but instead, this

      Point = namedtuple('Point', ['x', 'y'], verbose=True)

The resulting class, I believe to be more performant than using a dictionary - but I haven't actually measured this.

<comment><USER24> I'm probably doing it wrong but I measured exactly this yesterday and the dict version was faster:

        $ python -m timeit --setup "from collections import namedtuple; Point = namedtuple('Point', ['x', 'y']); p = Point(x=0, y=0)" "p.x + p.y"
        1000000 loops, best of 3: 0.284 usec per loop

vs.

        $ python -m timeit --setup "p = {'x': 0, 'y': 0}" "p['x'] + p['y']"
        10000000 loops, best of 3: 0.0737 usec per loop

Maybe the use isn't right because I agree with your belief that namedtuple is suppose to be more performant.

<comment><USER25> You should be creating a dict vs. a namedtuple instance once, then accessing it many, many times. What you're doing is creating a lot of dict vs. namedtuple instances, then accessing each one only once. That's mostly testing the instance creation time, not the field access time.

<comment><USER24> That code should only create the dict/namedtuple instance once, then access it many, many times.

The creation occurs in the --setup portion. The field accesses occur in the actual looping portion of the timeit code.

<comment><USER25> Ah, ok, I see, for some reason my browser wasn't showing the namedtuple code snippet right. Now I need to go look at the namedtuple code to see why accessing the fields by name is slower than accessing them by index.

</comment></comment></comment></comment></comment><comment><USER26> The article was kind of interesting, it's always good to talk about why things are slow, since that might help highlight what you can do about it (short of switching away from Python, that is).

I was abit annoyed about the benchmarks part; there was no C-based benchmark for comparison, it was not clear how many points were being processed which made the exact time kind of pointless. Also, C and C++ _are not the same_ which the author seems to think.

<comment><USER27> > C and C++ are not the same which the author seems to think.

The part where he lost me was when he said this referring to C:

> Here we tell the interpreter that each point would have exactly two fields, > x and y.

Maybe I misread that, but I don't think I did, he was referring to the C struct when he said that. It's one of those glaring mistakes that is hard for me to look past when someone says something like this.

<comment><AUTHOR> Not sure why I put an "interpreter" there when C is compiled, of course, I fixed this now.

Again, this does not change the fact that structs and dictionaries are very different data structures.

<comment><USER28> [http://stackoverflow.com/questions/584714/is-there-an- interp...](http://stackoverflow.com/questions/584714/is-there-an-interpreter- for-c)

</comment></comment></comment></comment><comment><USER29> The sentence "Python run slow" is a little misleading. While is true that does more stuff than other languages (C, for example) for similar operations, it is also true that in the majority of cases, the relevant time consuming parts of execution are in other areas, like waiting for I/O, etc.

In most of the cases, a program done in Python (or Ruby, or JavaScript) is not slower than a program done in C or even assembly. Sure, for some cases, it may be necessary to take care of rough cases, but I think that just saying "Python is slow" is not very fortunate...

<comment><USER30> > the relevant time consuming parts of execution are in other areas, like > waiting for I/O, etc.

It's safe to assume that people complaining about a language's performance deal with CPU bound cases.

> In most of the cases, a program done in Python (or Ruby, or JavaScript) is > not slower than a program done in C or even assembly.

This is false: [http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=gcc&data=u64q)

<comment><USER31> > It's safe to assume that people complaining about a language's performance > deal with CPU bound cases.

That's a very unlikely assumption – many people will complain about the language before even profiling their code. I've seen people do things like complain about Python's performance before, say, realizing that they were making thousands of database queries or allocating a complex object inside an inner loop. Because they've heard "The GIL makes Python slow" it's incredibly common for even fairly experienced programmers to simply assume that they can't make their program faster without rewriting it in C and they never actually confirm that assumption.

>> In most of the cases, a program done in Python (or Ruby, or JavaScript) is not slower than a program done in C or even assembly. > This is false: [http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t..).

That's a micro-benchmark collection. It's interesting for low-level performance but it doesn't tell you much about the kind of programs most programmers write. For example, I serve a lot of images derivatives over HTTP – it's certain that are many operations which could be significantly faster if they were written in C (i.e. reading HTTP headers in place rather than decoding them into string instances) but in practice none of that matters because almost all of the total runtime is already spent in a C library.

<comment><USER32> > That's a micro-benchmark collection. <

No, it's a meagre dozen "toy programs". (See Hennessy and Patterson "Computer Architecture").

> ... many operations which could be significantly faster if they were written > in C ... none of that matters because almost all of the total runtime is > already spent in a C library. <

See Sawzall quote -- [http://benchmarksgame.alioth.debian.org/dont-jump-to- conclus...](http://benchmarksgame.alioth.debian.org/dont-jump-to- conclusions.php#jump)

<comment><USER31> > See Sawzall quote -- [http://benchmarksgame.alioth.debian.org/dont-jump-to- > conclus...](http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus..).

Agreed – my point was simply that over a couple decades I've only seen a handful of cases where a performance issue which was due to the language rather than the algorithm or simple data volume. Such problems exist but not for the majority of working programmers.

<comment><USER32> Incidentally -- [http://books.google.com/books?id=gQ- fSqbLfFoC&lpg=PP1&dq=Com...](http://books.google.com/books?id=gQ- fSqbLfFoC&lpg=PP1&dq=Computer%20Architecture&pg=PA37#v=onepage&q=toy%20benchmark&f=false)

</comment></comment></comment></comment></comment></comment><comment><USER33> Rather than using a better data structure from the start (class vis-a-vis dictionaries), why not move to a better Python implementation (PyPy vis-a-vis CPython)? When I need a data structure, I look for one that is a natural fit to the problem. Perhaps everything is implemented as a hash table in a certain language (not taking names here :)) but would I replace every data structure with a hash table for efficiency? That would be Premature Optimisation.

I would recommend to code in idiomatic Python as much as possible (in this case, use a tuple for Point). Primarily because it is easy for other fellow programmers and your future self to understand. Performance optimisations are best done by the compiler for a reason, it is usually a one-way path that affects readability.

<comment><USER34> I can't use pypy yet, I need scipy/numpy.

</comment></comment><comment><USER35> For my casual use, Python has been fast enough that I can be pretty carefree about how I program. But I had one shocking experience when I ported a program with a fair amount of math over to a Raspberry Pi, and it practically ground to a halt. That was a disappointment. It won't drive me away from Python, but it means I've got some learning to do on how to better optimize Python code.

<comment><USER36> Python and performance can be summed up as "just think about what it has to do to add two ints together". The I/O requirements of that vastly exceed the CPU requirements.

Basically any tight loop, heavy use of hash tables (so that's Python, Ruby etc.) or floating point (since this is a sore spot for ARM) is going to create an explosion in time used. C/C++/C#/Java can, by being careful about the types being used, be much faster.

<comment><USER4> I don't understand what I/O has to do with that. The issue is all the extra branching and copying with every op code. Python is going to be 20X to 100X slower than C++ at pretty much anything. It's an inevitability of the type system.

</comment></comment></comment><comment><USER37> This should be bringing up the classic array-of-structures versus structure- of-arrays debate instead of what was mentioned. If only NumPy were standard Python and so we could have an easy, standard answer that is usually fast enough.

<comment><USER38> what is stopping you from using NumPy?

<comment><USER37> I do use it - it's just that it can't quite be given as the 'standard' answer for cases like this. I just wish it could become the definitive rather than the de facto standard.

</comment></comment></comment><comment><USER39> I'm surprised that Python's interpreter tech isn't advanced enough to try and JIT some of this away. Python could probably learn a lot from various JS interpreter advances.

<comment><USER29> The PyPy project is doing that [http://pypy.org/](http://pypy.org/) (is mentioned on the article)

<comment><USER40> There is also Numba, which is a JIT python to LLVM compiler that supports optional type annotations. Unlike pypy, it is designed to seamlessly integrate with CPython.

</comment></comment></comment><comment><USER41> On a related note, the field of compilers seems to have ignored data optimization almost completely at the expense of code optimization.

Applying a few basic tricks lets a human typically save 50-75% off an object's storage requirements and a compiler could combine this with profile feedback data about access patterns & making it more cache friendly.

This would be a good fit for JIT where the compiler could do deopt when the assumptions are violated, and this would let you make more aggressive optimizations.

</comment><comment><USER42> This article is making a misleading comparison. Yes, dynamically typed languages have overheads that statically typed languages don't. But the better question to ask is why Python implementations are factors slower than leading javascript implementations, which have the same theoretical overheads that Python does.

The V8 is is now about a factor of 4 or 5 off of the speed of C for general purpose code, while CPython is 30x to 100x.

<comment><USER38> if Google would invest the same engineering effort in Python

</comment></comment><comment><USER43> Runs 'slowly'. Led by the population of the North American continent, the adverb is dying gradual.

</comment><comment><USER44> Yet another case of someone (the blog engine?) being too smart and replacing " with " and " in code.

</comment><comment><USER45> If you don't want to mess with ctypes, this sounds like a straightforward use case for namedtuple.

</comment><comment><USER46>
        std::hash_set<std::string, int> point;
        point["x"] = x
        point["y"] = y

This is a very interesting implementation of a set...

</comment><comment><USER47> if you ever watch Robert's talk [http://www.youtube.com/watch?v=ULdDuwf48kM](http://www.youtube.com/watch?v=ULdDuwf48kM) you will find that different version of Python can have different run time for the same code.

</comment><comment><USER48> Wouldn't a regular tuple be the most pythonic (and possibly most efficient) way to represent a point?

I think that's what most image libraries do (at least Pillow).

<comment><USER49> It was just an example to illustrate the problem. Pythons don't have legs. So they can't run, not even slowly.

It would have been more instructive if the author showed the alternate solutions classified by measured speed.

</comment></comment><comment><USER50> Wouldn't a tuple be more appropriate than a class?

<comment><USER51> Then you have stuff like point[0] and point[1] littered throughout your code, or you write getter functions and then you have function calls as an overhead which is roughly as expensive as the class. An instance of namedtuple is actually the Correct (tm) solution.

<comment><USER52> >An instance of namedtuple is actually the Correct (tm) solution.

Do you have an implementation to support that? Because a comment from TFA shows that's actually the worst idea in cpython. [http://lukauskas.co.uk/articles/2014/02/13/why-your- python-r...](http://lukauskas.co.uk/articles/2014/02/13/why-your-python-runs- slow-part-1-data-structures/#comment-1242618646)

<comment><USER51> Sorry, which comment are you referring to? All I see is a footnote saying "One would be right to argue that collections.namedtuple() is even closer to C struct than this. Let's not overcomplicate things, however. The point I'm trying to make is valid regardless" which doesn't really say it's a bad idea, just that he didn't decide to talk about it in that article.</comment></comment></comment></comment>


Ask HN: Have you developed with Squarespace? - <AUTHOR> I don't mean just choosing one of their templates and editing the content, but actually using their developer tools to create your own template/site from scratch.
Documentation: http://developers.squarespace.com/initial-setup
From what I can see it looks pretty solid and a much smaller learning curve than something like WordPress.
I was wondering if anyone here had any experience using Squarespace's developer tools to build your own site, or a client's site from scratch. If so, would you use it again? Would you recommend it to another developer? <comment><USER2> I've been using Squarespace's developer platform for a gallery site. It's decent. I used the blank developer template, so I built most of the CSS from scratch. In my opinion, some of the drawbacks are:

\- The editable text fields only support h1, h2, h3, and p tags. If you plan to have four font sizes or the people maintaining the site don't mind using the editable code blocks, this isn't a bad thing. \- If you use the built-in blocks then write your own CSS overrides, you are assuming those classnames (generated on squarespace's side) will be the same. Forever. \- I found myself overriding a lot of the system blocks with very bad css (some !importants)

The good things: \- Every post has an associated JSON endpoint. No heavy lifting on this side. \- In my experience, support gets back to you in a day or less with helpful answers. \- The support for custom post types (See the docs) is finally acknowledged.

In my opinion, the developer tools are great for your own site or if the client has familiarity with basic html tags. I am not sure I would use it again for a site to hand off to a non-technical client. If the system blocks (built in video, text, image types) were customizable, I would recommend Squarespace more heartily.

I have not used Squarespace's ecommerce functionality so I am unqualified to comment on those. I have heard good things about Webflow's CMS offering, so I would check that out to compare.

This post was very helpful to me in seeing how other people use the dev platform (I have no affiliation): [http://www.instrument.com/latest/creating- a-clean-custom-mai...](http://www.instrument.com/latest/creating-a-clean- custom-maintainable-site-with-squarespace)

Hope that helps!

<comment><AUTHOR> Thanks for answering! Definitely very helpful

</comment></comment><comment><USER3> I've worked on a client's Squarespace site on and off for the past couple of years. I initially stepped in when they had reached their own limits with customization.

At first I used the in-browser stylesheet and template editors Squarespace's free/low-cost plan had to offer. But almost immediately my clients had to step up to a plan that allowed me to access the Git-based developer platform. Unfortunately, they wanted to retain much of their existing markup and styling. It was all dependent on the system blocks johnny_utah mentioned, so I couldn't take the greenfield approach. This created some problems, but it still didn't take me long to put together a very nice brochureware site. And I am definitely no expert with the platform.

Yes, I would recommend Squarespace over WordPress. It seems very empowering to slightly-technical users who might want to do creative things that would be difficult with even a customized/fully-plugged-in WordPress setup. Also, avoiding WordPress security issues and third-party hosting headaches is a big plus.

</comment><comment><USER4> I'm working on this right now for my company. I have limited web developing experience though I've puttered around on Wordpress for about a decade and know some fundamental HTML and CSS. We're moving from Wordpress to Squarespace for both ease of theme customization (from a technically limited standpoint!) and overall more pleasing aesthetic. Our site as it stands is perfectly functional, but looks like it's from 2006, and we currently would rather not hire a web design company again and do it ourselves.

<comment><AUTHOR> That's good info, I really appreciate the feedback

</comment></comment><comment><USER5> If you play with their JSON Template thing, you'll suffer. Honestly, that pseudo language isn't even well documented. I had to go through so many posts or questions on different forums to find all its features. Their UI tool is still a good thing but it's definitely not that developer friendly.</comment>


Computer Chronicles - Operating Systems (1984) - <AUTHOR> http://cchronicles.com/files/97ec84b7124de49f040d1126b871403d-65.html

<comment><USER2> This is hilarious - [http://cchronicles.com/files/88e98b9390fca83cbb3e51ceb68772b...](http://cchronicles.com/files/88e98b9390fca83cbb3e51ceb68772b5-37.html)

</comment><comment><USER3> These were fantastic shows.</comment>


Students Make Atari Games Look Like Atari Again - <AUTHOR> http://www.digitallounge.gatech.edu/gaming/index.html?id=2824 <comment><USER2> > images might linger after they had moved or changed. Atari programmers took > advantage of this feature to "flicker" objects between frames.

Interesting that they turned this bug into a feature. Pacman's ghosts were literally "ghosting".

</comment><comment><USER3> For a cool example of CRT simulation, check out Xscreensaver's Apple II mode, written by tlb.

</comment><comment><USER4> I've seen similar filters in emulators for years.</comment>


Ask HN: Is there a RentAPhD.com type service? - <AUTHOR>

I know Russia/China are pumping out plenty of graduate students with experience in Machine Learning/NLP/distributed algorithms etc. It seems like it would be relatively cost-efficient to tap into this stream of expertise. I'm sure it wouldn't be cheap but probably still cheaper than hiring a local person with the same skillset.
Unlike normal outsourcing, it seems like it's possible with this sort of work to keep it tightly scoped and have a well defined target to hit which would cut down on miscommunication problems.
Does a site like this exist? <comment><USER2> Well, gee....everyone has champagne tastes on a beer budget, don't they?

If you truly need the expertise of a PhD to solve your technological problems, then why in the world would you think that the problems are easier to outsource than the mundane stuff where we _know_ that outsourcing fails miserably?

</comment><comment><USER3> I don't know of any site of the sort you're looking for, but if you need Chinese or English machine learning/NLP services, get in touch with us at Language Systems Ltd.

<http://languagesystems.net>

We help people with a subset of NLP problems involving translation, segmentation, content-extraction and search and have cost-advantages from being based in China. That said we can't help you with distributed algorithms and your desire to just hand-stuff-off-to-someone-else is a recipe for disaster unless you can be very clear about what it is EXACTLY that you need your systems to do.

Your best approach to working with NLP is generally finding the simplest solution to your problem and then iterating to make it more and more usable. As much work is needed getting and processing data as linking together algorithms. If you blindly outsource you'll get what you ask for, but not what you want.

</comment><comment><USER4> The problems that researchers generally solved are _not_ well defined or tightly scoped. Researchers do _research_ which often means the problem itself changes as they explore solutions.

</comment><comment><USER5> I suspect the results wouldn't be remarkably better than using normal freelancing sites and it'd be suspect to falsifying credentials. Beyond that, a PhD does say something about a candidate, but presuming you'd want them for a development task, it doesn't speak much to their suitability for performing that task.

One place that you might have luck would be on the ACM job boards. Many of the SIG announcement lists primarily cover open positions. While I'm often critical of the ACM, that would seem to have a similar target audience to what you're after.

</comment><comment><USER6> <http://www.liveperson.com/> ?

Or why not just contact graduate students directly?

</comment><comment><AUTHOR> timr: The difference between this and normal outsourcing is that I'm not outsourcing the design aspect of it, merely the algorithmic development. Think of it as a netflix challenge style problem. The problem would be specced roughly as:

"Here is an input vector, here is an output vector, write an algorithm that can translate input -> output with 98%+ accuracy". Of course, there would be validation data as well which they never get to see.

scott_s: Of course, lots of research is by necessity vague but a lot of it can be tightly scoped as well. Handwriting recognition, for example, simply involves trying to improve an accuracy measure.

sireat: There's what? 1000 universities in China and I don't read Chinese. Such an approach seems really hit or miss to me.

<comment><USER2> I understand what you want, but was restraining myself not to say something harsher, because I found your question rather offensive.

What makes you think that a PhD who has spent 20+ years of education becoming an expert in some particular research specialty, is going to want to solve your core business problems on spec, for crap pay and zero equity? If you think this stuff is so easy that you just can contract someone to solve your problems _"with 98% accuracy"_ the way you'd order a graphic design from eLance, then you have an extremely poor understanding of what a PhD is trained to do.

(In fact, somehow I doubt that you'd order a graphic design from eLance, because by now, most entrepreneurs know the value of developing an ongoing relationship with a skilled professional. A PhD is a skilled professional, too.)

<comment><AUTHOR> timr, I'm not coercing them into anything and I don't have any illusions that I'm going to get a PhD for less than minimum wage. If they don't want to solve my core business problem, that's fine, all they have to do is not bid.

An ongoing relationship is a great thing when it's part of your core business competitiveness. But for some tasks, it's simply a matter of getting something that meets a spec and I don't see why outsourcing is not an acceptable solution for this.

I short, I don't know where your anger is coming from.

<comment><USER4> If you outsource the core technology of your business, then you don't have a business.

</comment></comment></comment></comment><comment><USER7> How about contacting appropriate departments at Universities directly?

</comment><comment><USER8> its what academia.edu will become

</comment><comment><USER9> Yes. University of Phoenix. Err... wait, you want someone with PhD level knowledge? Can't help you there.</comment>