Idea validation? - <AUTHOR>

Ok, so I have yet-another-idea and trying to research whether it makes sense to continue with it (yeah, I already started it and spent some time and money on it).
I am researching it myself on the internet and by talking to people, but I would love to hear your opinions about it.
So here we are.
I would not be able to disclose certain details I've developed that could be a kind of competitive advantage, but I will try to provide as much information as I can do.
The fundamental idea is very simple: you assess your level of wellness (the state or condition of being in both good physical and mental health) and your location on the globe (unless it was specified by you in your previous assessment, of course) and this assessment is reflected on an overall "wellness synoptics" map (i.e. all assessment are synthesized in some way and all you see is some map with transparent colored overlays).
Basically, that's all. A global map that tells how do people feel at different locations.
Of course, I have some features-to-add and some promotion/monetization strategies in my mind (I do really enjoy this project), but I'd really like to ask you guys, what do you think about it? <comment><USER2> If you focus your idea more, I think you might have something. I founded and funded a company that did something along these lines, although I think our portfolio company was a bit more focused on trying to solve specific problems and generate revenue.

Our portfolio company developed watches and mobile (cellphone) software that worked with biofeedback attachments to monitor various aspects of health for users. It all integrated with an online system, which tracked location and company/community trends, among other things. There were games that helped people lower their blood pressure, etc. There were also systems to monitor wakefulness, to predict heart attacks and strokes, etc. I think we had around 80 specific use cases. We were working with an EAP company and several wellness/insurance companies.

All of this is past tense, because the company never made it to market. We presented at a single tradeshow and were promptly sued by about a dozen companies. We also got cease-and-desist letters from quite a few major companies (Nokia has several patents in this area, for example.)

Just like with location-based apps, there are a slew of overly broad patents that seem to tie up most of the basic functionality you would want in such a device/service. Many startups don't realize the unbelievable amount of 'IP' that has already been sewn up by companies in these areas. The patent holders don't usually go after you until you announce a big funding round or gain some traction in the market. We had to write off most of our investment because we weren't equipped to fight the legal battle at the time.

There are a ton of startups that are still working in this area, though...and I think there is a huge market. If someone can figure out a way to circumvent the existing patent mess, I would be interested in investing again.

From a hacker point of view, there are some interesting open-source projects. OpenEEG, for example:

<http://openeeg.sourceforge.net/doc/sw/>

<comment><AUTHOR> good point about patents, thanks!

</comment></comment><comment><USER3> My only question is what problem are you solving? It would no doubt be cool but who is the target for this, who is truly in need of it?

<comment><AUTHOR> I am trying to make some people at least a bit happier — _at least_ by understanding that they are not alone (note that I said "at least")

Different people might need it:

* those who feel bad

* those who want to validate some area's "wellness climate" — like "where to go today?"

* those who want to express their happiness/wellness somehow

<comment><USER3> I feel like if you have the capability to create this, then you also have the capability to create something else that will actually improve people's state of happiness not just something that will show people that other people feel like crap too.

<comment><AUTHOR> pardon me? I am not sure I understood your statement completely.

though yes — you're right — only _showing_ people that other people feel like crap too wouldn't help them much; but in order to add some features/services that might actually help somehow, I anyway need this map first, right? just as a thing to start at.

<comment><USER3> I meant that I think your talents can be applied to something that creates happiness and not just shows or maps it. Solve a problem for people that's making them unhappy or frustrated.

<comment><AUTHOR> everybody has his/her own reason to be unhappy or sick, I guess

</comment></comment></comment></comment></comment></comment><comment><USER4> A different approach, but this may be worth a look from the emotional perspective, at least.

<http://www.wefeelfine.org/></comment>


Calif. woman who sold food on Facebook facing possible jail time – NY Daily News - <AUTHOR> http://www.nydailynews.com/life-style/calif-woman-sold-food-facebook-facing-jail-time-article-1.2860989 <comment><USER2> Clickbait title (it's not selling _on Facebook_ that was the issue) ignores the broader risk of contamination in homemade foods, especially in seafood and dairy products. There have been many such cases in that area alone, so much so that the nickname "bathtub cheese" came into the local vernacular starting in the 1980s.

Here is one such CDC warning:

[http://www.cdc.gov/mmwr/preview/mmwrhtml/mm5026a3.htm](http://www.cdc.gov/mmwr/preview/mmwrhtml/mm5026a3.htm)</comment>


Unemployment Is Killing 45,000 People Each Year - <AUTHOR> https://news.vice.com/article/unemployment-is-killing-45000-people-each-year <comment><USER2> If like me your first thought is how many people does employment kill: about 4.5-7000 a year.

Though that doesn't seem to cover military/law enforcement or secondary deaths like suicide.

[http://www.bls.gov/iif/oshcfoi1.htm](http://www.bls.gov/iif/oshcfoi1.htm)

<comment><USER3> And it is precisely the number those secondary deaths (eg. suicides caused by stress at work) that would be really interesting.

<comment><USER4> So far as I know Japan has a category for deaths by overwork in their statistics, but US, conveniently, does not.

<comment><USER5> That's because in Japan a number of people actually work to death. Laeve work 11pm get up at 5am work on weekends.... Those people feel an obligation to do that, occasionally you get the odd person who dies from overwork.

So they have that statistic out of necessity. It's a common enough phenomenon.

<comment><USER4> I would say that reasoning is a little suspect. This is often considered a uniquely Japanese phenomenon, but there's a growing body of work suspecting that isn't the case.

In Japan part of the classification involves unlogged or extreme amounts of overtime, something we also have in the US (I have personally worked for years at companies that required a lot of unlogged/unpaid overtime from all of their employees). The cause of death is often stress related heart attack or stroke, again something we also have in the US. We know excessive job stress can cause permanent degenerative damage to the heart. So the fact that the Japanese choose to classify it as work-related and Americans don't doesn't necessarily mean such deaths don't exist in the US, or are necessarily too small to be worth measuring. They just simply aren't measured.

</comment></comment></comment></comment></comment><comment><USER6> I would say they're not even trying to serve mobile users anymore, except that ruining the mobile experience this badly takes a lot of effort. [https://twitter.com/lwahonen/status/566315464825913344](https://twitter.com/lwahonen/status/566315464825913344)

<comment><USER7> You can just close the subscription dialog popup.

</comment></comment><comment><USER8> Title suggest causation, but reading the article it sounds like it's a contributing factor to preexisting mental health issues:

 _" What we see with unemployment is that it increases the risk because it makes already bad situations worse for some people," he said. "Any kind of economic strain or unemployment, to the degree that there are already mental health or substance abuse or relationship problems, can make it worse."_

<comment><USER5> The interesting part is that it's saying that people unused to unemployment are more affected than those where unemployment I common.

So a country region,city where unemployment is already high, becoming unemployed there has less effect than exhibited in an area with traditionally high employment --people not acclimated to unemployment take the experience harder.

</comment></comment><comment><USER9> In other news, all-cause mortality has been steadily declining in all developed countries throughout our lifetimes,[1] so with that in mind, maybe unemployment today is less dangerous than it ever used to be.

[1] [http://www.nature.com/scientificamerican/journal/v307/n3/box...](http://www.nature.com/scientificamerican/journal/v307/n3/box/scientificamerican0912-54_BX1.html)

<comment><USER10> It is also interesting that there have been published pieces showing that most of those gains have been correlated to income. People in the top 50% of income makers are living significantly longer than those in the bottom.

So I would caution against viewing this whole population study as a complete indicator that long-term unemployment is now an insignificant problem.

<comment><USER4> 100% agree. Really any kind of knee-jerk rationalizing away of deaths, like that by the OP, should probably be taken cautiously.

</comment></comment></comment><comment><USER11> Not unepmloyment, but rather lack of means caused by not being given them unless you work but at the same time not allowing to work.

<comment><USER12> Yea, it is almost certainly more desperation. If you give someone a stable home, food, power, etc - they will find their own thing to do. It is when you owe thousands in debt, have no income, lost your car, are losing your house, etc that you become depressed and desperate enough to self harm.

I mean, you can have people who have huge downs immediately after losing a job, but someone who has just left unemployment compensation would not be considering suicide if they weren't losing everything.

</comment></comment><comment><USER13> And 4,383 workers died only in USA from job injuries in 2012 (wikipedia)

<comment><USER14> the size of both populations should be considered

</comment></comment><comment><USER15> Just to emphasize: " _statistics of 63 countries_ "</comment>


Why Tesla Is Worth More Than GM - <AUTHOR> https://www.technologyreview.com/s/607954/why-tesla-is-worth-more-than-gm/ <comment> tuna-piano It is just not true that Tesla is worth more than GM in the common understanding of that. The real answer to "Why Tesla is Worth More Than GM" is one sentence: GM has more debt than Tesla.

People understand (and the article gives reasons why) "worth more than" to be that the GM brands + factories + assets + future prospects are worth less than Tesla brands + Tesla factories + Tesla assets + Tesla future prospects. But this is not true in actuality. This is because Tesla is worth more than GM based on Market Capitalization, not Enterprise Value. The difference between these companies is that GM has $51B in net debt while Tesla has $2.6b.

If GM wanted to be "worth more than Tesla" (using market cap), they could do it tomorrow by issuing $51B in new stock and paying off their debt. Why doesn't GM do this? Because they actually believe their stock is undervalued, and would rather buy their own stock than sell it.

Debt (leverage) is different across different companies. If you aren't familiar with how different debt levels affect the market cap, the following pages are worth a read:

[https://medium.com/@ruzbehb/tesla-is-not-valued-at-more- than...](https://medium.com/@ruzbehb/tesla-is-not-valued-at-more-than-general- motors-and-ford-hint-enterprise-value-c89c2d21222e)

[http://www.investopedia.com/exam-guide/cfa- level-1/corporate...](http://www.investopedia.com/exam-guide/cfa- level-1/corporate-finance/debt-effects-capital-structure.asp)

[http://www.investopedia.com/terms/l/leverage.asp](http://www.investopedia.com/terms/l/leverage.asp)

<comment><USER3> Your premise is entirely wrong.

GM has _positive_ $37 billion in net tangible assets. That has climbed from $27b, to $33.9b, to $37b over the last three fiscal years. Their net balance sheet is not only improving, it's dramatically in the positive.

To go with that, they have $24 billion in cash and are currently capable of earning around $12 billion in net income on an annualized basis (meaning they can easily afford the debt they have just on an income basis).

GM's balance sheet is in dramatically better shape compared to market capitalization vs Tesla. To make matters worse for Tesla, they're still bleeding immense red ink vs sales, having to regularly either raise debt or dilute shareholders to keep operating (GM doesn't have that problem, and doesn't need to eat its balance sheet to operate). That by itself tells you everything you need to know about Tesla vs GM when it comes to balance sheet vs market cap.

Tesla is worth more than GM for one reason: the potential to one day be more profitable than GM, namely that enough shareholders are buying into that premise.

<comment> tuna-piano You may know much more about this than me.

Is Enterprise Value too simple a calculation to compare the companies? (you seem to be looking at the entire balance sheet, not just cash/debt)

Certainly GM could issue stock tomorrow to increase their market cap to be more than Tesla's?

Market cap just seems a bit arbitrary of a metric (as it doesn't take into account cap structure) when you're comparing the value of the digital economy and digital monopolies, etc (as the article does).

<comment> tuna-piano @adventured

But certainly if the GM entity had $10B more cash tomorrow, it might not be worth $10B more, but certainly it would be worth $5-$10B more (or at the very least >0 more)?

And of course, they could use that $10B to pay off $10B of their existing debt as well.

All I'm trying to say is that you probably shouldn't compare market caps of companies with vastly different capitalization structures to try and deduce a bigger picture idea of the economy. You should look at enterprise value.

[http://www.investopedia.com/terms/m/marketcapitalization.asp](http://www.investopedia.com/terms/m/marketcapitalization.asp)

[http://www.investopedia.com/terms/e/enterprisevalue.asp](http://www.investopedia.com/terms/e/enterprisevalue.asp)

<comment><USER3> > But certainly if the GM entity had $10B more cash tomorrow, it might not be > worth $10B more, but certainly it would be worth $5-$10B more (or at the > very least >0 more)?

No, again, that's not how it works. Shareholders value companies primarily based on a multiple of earnings with an overwhelming tilt toward future expectations, not based on cash. Cash can receive anywhere from a medium to a near-total discount, depending on the context & company. As an easy example: Apple's cash has stopped growing at the rate it used to (they're paying a lot of it out), while it has taken on immense debt in a short time, and its earnings have not expanded in years (in fact they've fallen as with sales, re fiscal 2016 vs fiscal 2015) - meanwhile, its stock has been given an increased multiple lately, AAPL is up 47% (adding $200+ billion in market cap, while earnings went down and debt went up) in the last year despite those theoretical negatives. Why? Shareholders mostly don't care about the accumulated debt or the slowdown in cash accumulation.

There are a few exceptions, for example if a company is under serious bankruptcy risk. That can dramatically damage the valuation given to a company via its income. In that specific case, adding a ton of cash to relieve the bankruptcy risk, can produce a greater than 1x release in value as shareholders shift back to operating fundamentals & future expectations. Valeant Pharmaceuticals is a walking example of that right now. To the extent Valeant manages to lift the dark cloud of bankruptcy off of it, their market valuation will rise (every time they announce they've paid down some debt, or sell an asset for a good price, their stock tends to spike; they have something like $29b in long-term debt and the debt interest is threatening their existence; if they magically added $10 billion in cash tomorrow, their market cap would expand by something near a 1 to 1 basis or likely greater (depending on the bankruptcy pressure, relief from it can generate an amplified upside)). Another exception example: Las Vegas Sands (LVS), the casino giant, was under serious risk of bankruptcy during the economic crash in 2009; its founder, Sheldon Adelson, decided to back the company with a large amount of money, the stock proceeded to increase by 5x to 6x in a matter of a few months afterward, due to the relief that bankruptcy was no longer nearly so likely (shareholders shifted back to valuing the company on its future earnings/growth/operating expectations). LVS gained so much so quickly, because the risk of bankruptcy was viewed as being so severe it had drastically depressed the market cap of the company.

<comment> tuna-piano Certainly if there were two identical companies, and one had $10B more in cash, the one with $10B more in cash would be worth more than the other company? I understand it's not 1-1.

I'm thinking completely theoretically, so if the world doesn't work like finance theory, fine. But I just can't see any way in which leverage, debt, cash, etc don't substantially alter the market cap of a company.

<comment><USER4> adventured is having a really hard time with your phrase "two identical companies". The answer to your question is yes, if you had two identical companies and then gave one of them $10B in cash, that company would be worth $10B more.

<comment><USER5> Actually adventured is right on non-operating cash being usually discounted. In general the second company will not be valued at $10bn more than the first.

Would you rather have a $1 in cash and a $9 share in the first company, or a $10 share in the second company where $1 is the cash per share? The second case is more risky so you wouldn't pay the full extra $1 for the second share.

Of course it could also be the case that the spread is larger than $1, if the first company is too short on cash and there is a liquidity risk depressing the valuation.

<comment><USER4> > The second case is more risky

Not if they're otherwise identical companies, it isn't. There may be reasons to expect a correlation between risk and cash holdings, or something to that effect, but ultimately a share in a company is a share of ownership of that company's assets. If a company didn't become $10B more valuable when given $10B in cash, where exactly did that value disappear to? Value doesn't vanish into thin air simply because it's now owned by a company.

<comment><USER5> Your loss is limited to $9 in the first case, but you can lose $10 in the second case. If you think this is not more risky, fine.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Nothing to see here. The only thing the author actually says about Tesla is that they collect a lot of data from their cars. The only thing he indicates that may be useful for is self driving. Most of the text is just rambling about how awesome tech companies are and he obviously he doesn't consider GM or anyone in the auto industry to be a tech company either.

Really almost a content-free piece with respect to the headline.

</comment><comment><USER7> Tesla is worth more than GM largely due to speculation that Tesla will be able to ramp up revenues, margins and cash flows unbelievably quickly and expand far beyond a car company. Whether or not they have any chance of doing this is unknown, but the market is a huge fan of Elon Musk given his history of delivering innovation.

Historically, betting on immense multiples of revenue and earnings on negative cash flow companies has not worked out on average, but Tesla may not be average.

Regardless, I wouldnt invest in either company. Autos have historically been a terrible investment due to large capital requirements, low margins, a cyclical operating cycle, ugly pension requirements, and fairly expensive labor... We shall see what the future brings.

</comment><comment><USER8> A minor point, but "...because of things like online shopping, which has put hundreds of thousands of retail workers out of a job."

Makes me wonder... the method of product selection and delivery have changed from in store browsing and carry out, to online browsing and delivery. Instead of sales personnel and cashiers, it involves warehousing (to a larger degree) and delivery vehicles. Employment in sales/cashiers therefore would drop, while employment in warehouses and delivery companies would have increased.

What are the relative ratios? For every x retail jobs lost, how many y 'logistics' jobs are created? Once automatic warehouses and autonomous vehicles are pervasive, is it a 100% loss?

<comment><USER9> Employment in warehouses stays unchanged, because people are not buying more. They don't have more money to spend just by switching to online browsing.

<comment><USER8> I'm not sure this is true. Online prices tend to be lower than in store. So the cost of goods overall is lower and consumers effectively can buy more items.

Also, when considering retail, the shipments from warehouse to store are in bulk, whereas shipments direct to consumer are small numbers of discrete items, which requires more handling for picking, packing and shipping.

</comment></comment></comment><comment><USER10> > How did we end up with a digital economy dominated by a few big players? The > simplest explanation focuses on what are called network effects

The simplest explanation is that antitrust enforcement started to lag in the '80s and became seriously deficient after 2000. Electricity, oil, telephony also had network effects.

</comment><comment><USER11> This reminds me of the many reasonable-sounding articles in the late 1990's that rationalized the sky-high valuations of dot-coms. For example:

[https://www.theatlantic.com/magazine/archive/1999/09/dow-36-...](https://www.theatlantic.com/magazine/archive/1999/09/dow-36-000/306249/)

[https://hbr.org/1999/11/the-new-economy-is-stronger-than- you...](https://hbr.org/1999/11/the-new-economy-is-stronger-than-you-think)

A few months after these articles were published, the stock market crashed... and it took the better part of two decades to recover.

</comment><comment><USER12> > What's more, where GM's production led to eight jobs in its supply chain for > every one person it employed directly, the ripple effects of the Big Five's > businesses, with the exception of Apple, are much smaller.

Would Amazon's ripple effect be pretty big too? All the products it sells have manufacturers (who have employees). Or is it better described by disintermediation, where a product that is sold via Amazon now would have been sold via brick & mortar before?

<comment><USER13> I think you've mostly answered your own question.

To some extent, Amazon presumably creates new sales (and hence new jobs in production) but this is almost certainly offset by the jobs it destroys (middlemen of various kinds).

AWS might have greater ripple effects (enabling new tech companies) but they themselves aren't large employers.

</comment></comment><comment><USER14> It remains to be seen whether Tesla will be able to sustain the success in cars. I'm more optimistic in the rocket business as the competition is limited. The automobile business is complex and scaling out their operation is going to be hard. Tesla's competitors have scale, suppliers who also invest and broad customer brand acceptance. They also have woken up.

China will soon provide battery capacity for cars in excess of what Tesla is producing. Autonomous driving on a broad basis requires a regulatory framework and that may well take time to emerge until there are other brands. The horizontal structure of the conventional car industry makes it likely that alternatives to Teslas autonomous drive will quickly spread across the traditional car companies.

Tesla may well build the best electric car for a long while but volume upside may be limited.

</comment><comment><USER15> Conflating market cap and total worth is a pet peeve of mine.

Market cap is "price of _one_ share" multiplied by the total number of shares outstanding.

If you want to buy a small number of shares, you can probably just multiply to find the total price you would pay.

If you want to buy a large number of shares, or the whole company, you can't just multiply. You would need to get the current owners to sell to you, and they might either charge you a premium or refuse to sell. The total worth of a company depends on the distribution and type of ownership (among many other things).

Market cap is a fine shorthand, but serious analysis about comparing worth should control for several other things.

</comment><comment><USER16> 1) Because investors with too much money in their pockets believe the self- driving hype.

2) Because GM (and Ford and Chrysler) has a lot more unknowns and risks given its increasingly outdated dealer-based sales channel, along with decades of pension liabilities, and is ultimately in a precarious situation, see: the near collapse of the US auto industry in 2008.

3) Maybe most importantly, investors believe that ultimately Tesla will be purchased by a big tech company with money to burn (or by a traditional automaker in full panic mode). Apple could pay _cash_ for all of Tesla's outstanding stock and still have the biggest cash stockpile of any corporation in the world.

<comment><USER17> " _Apple could pay _cash_ for all of Tesla 's outstanding stock and still have the biggest cash stockpile of any corporation in the world._"

Apple doesn't even want to be in the business of manufacturing iPhones - <USER2> outsource it to Foxconn. So why would they suddenly be interested in owning Tesla's huge car and battery manufacturing factories that employ thousands of workers?

</comment></comment><comment><USER18> There are as many reasons as there are investors. Apart from financial returns, not everyone is in it for the same thing.

My reason for giving Tesla a higher valuation is different to the next guy. However, Tesla is a better starting point for capitalising on a low carbon future. Even the GM pension obligations factor into my hunch. Ultimately it is all about belief, in my case a belief in a zero carbon future.

</comment><comment><USER4> > The digital economy is giving us a world in which the benefits are > concentrated among consumers and the Big Five who serve them. Everyone else > just lives in it.

This is a really weird phrase. "Concentrated among consumers"? More than 80% of Americans use the internet, not exactly "concentrated".

</comment><comment><USER19> Apples to oranges. GM is a car company, while Tesla is an energy company.</comment>


"On iteration": Why people leave Python - <AUTHOR> http://brehaut.net/blog/2010/on_iteration <comment><USER2> That article makes some really good points, but I disagree. To me, Python is quickly becoming a good middle ground where I can use these powerful functional ideas, then drop down to imperative whenever I need to. In particular, this means that I can use Python to do scientific computing or to easily work with native libraries while still maintaining a lot of the functionality of more pure languages.

<comment><USER3> Compared to traditional static languages (C++, Java), Python offers an order of magnitude of improvement in productivity.

Compared to older scripting languages (Perl), Python offers a sane language and a rich programming environment.

Compared to other current popular scripting languages (Ruby), Python offers a solid runtime and better out-of-the-box performance at the expense of some elegance and fluency.

Comprare to some very interesting languages (Haskell, Erlang, Scala) Python is more widely available and allows you to produce good, portable, well- performing code quickly and easily.

It's a state of flux. Right now Python is my language of choice (after ten years of Ruby) and it touches that sweet spot of expressiveness and performance. However, the bolted-on features (verbose object system, clumsy metaprogramming) deliberate crippling of language (e.g. one line lambdas) and the underlying message of "there's one way to do it" (which is my way, because I know better than you) will, for me, mean that eventually I will move on. More expressive, coherent and flexible languages will eventually reach Python's current level of maturity and performance, and then it will be time to switch. It could be MacRuby, Scala or F# (but probably not Haskell or Erlang). Who knows.

But, for now, Python is a good choice.

Edit: typos.

<comment><USER4> May I suggest Lua with metalua? It seems to have most of what you're looking for (and luajit is very fast).

<comment><USER5> Lua has a library problem for many tasks.

<comment><USER4> Such as?

<comment><USER6> Many/most libraries in Python are built in, so you don't need to hunt them down and install. More importantly your users need only have "Python", nothing more or less and don't have to fiddle to get things working.

<comment><USER7> But unlike Python, _Lua is smaller than SQLite._ You can just put it in a DLL and install it with your project. Any users that even notice it would be shocked to see how many installations of SQLite they probably have. :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The reason Python is such a joy to use is that it hasn't felt the need to be all things to all people.

Those of us who use python are often coming from C++, perl, etc. and know all too well what happens to languages that try to add every feature that someone might find useful.

If you want to use a lazy purely functional language, you know where to find one. It's not python.

If you want a language that allows you to express your inner emotions by using your personal pet programming style, this isn't it either.

<comment><USER9> "If you want a language that allows you to express your inner emotions by using your personal pet programming style, this isn't it either."

That would be Lisp. ;-)

<comment><USER10> Oh really? I would have said perl or perl-reloaded (aka ruby)? ;-)

</comment></comment></comment><comment><USER11> Is there any evidence for this supposed trend? Or will these "many" programmers remain merely a vague hand-wave?

<comment><USER12> i've found that demanding empirical evidence from a blog post often leads to disappointment ;)

<comment><USER13> As additional anecdotal evidence, this is true for me, though I'm still using Python for my next project simply because it's a proven language with proven libraries.

But I'm certainly ready and interested in moving toward a more functional language -- I've always been interested in the Lisps, and have always tended to write code in the functional style, where possible (even though my first language was Java...)

<comment><USER14> _this is true for me ... though I'm still using Python for my next project_

i think you must mean "false", then.

<comment><USER15> No, he said he's using python, so it's False

<comment><USER14> it's taken me a day to "get" that - i'd been thinking it was a confused comment rather than a (questionable quality!) joke... have a vote back to 1 since i suspect you've been downvoted by others as confused as me.

</comment></comment></comment></comment></comment></comment><comment><USER16> I've had the opposite experience with C#. MS' adding of lambdas and deferred list operations in 3.5 has delayed my switching to F# for all of my heavy number crunching work (For those who have yet to try ruby, python, scala, c# et al-- being able to switch between imperative and functional style on a per task basis is a wonderful way to work).

In the real world, suffering a few weeks of diminished output due to learning new syntax, idioms and best practices is not always (dare I say, rarely) feasible so making an existing language more powerful through the addition of functional constructs can only extend their productive life.

</comment><comment><USER17> As a programmer who has used variants of SML (F# is Microsofts variant), Haskell, and Python, I would say that in terms of concise expressiveness, you have a point that the functional languages match Python's. However, the true power of programming in Python is that the programming logic is easy to understand. If you are actually experienced in functional programming, you'll realize that it is, in all definitions, code. Python is more like english and thus, the appeal will always be there.

<comment><USER18> _"Python is more like english"_

Having written non-trivial programs in Haskell, ML, and Python, I agree with this, but I would add: _Functional programming is more like mathematics._

English expresses some ideas more clearly, while mathematics is better for others. And notations that are more "mathematical" often have other nice properties like composability and equational reasoning.*

*The best example of what I mean by equational reasoning is the Sudoku functional pearl: [http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/s...](http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/sudoku.pdf)

<comment><USER19> The paper you posted is a good example. The conclusion is:

        sudoku = map (map head) . search . prune . choice

Note how the "code" never mentions the data to which it is applied, namely the Board object. This is why I can't agree with the GP's argument that FP is closer to "code" than anything else -- I think it's as far from "code" as you can get. There are no "instructions" here, just an equation representing something complex ("the solution to sudoku"), in terms of slightly simpler parts. The simpler parts are, earlier in the paper, the complex parts; and are of course described there by simpler parts.

And, this is not just something that's useful for esoteric mathematics papers; my "enterprise" code in Haskell looks very similar.

</comment></comment></comment><comment><USER20> Functional programming simply isn't any better than the usual style of python development.

I have used much of itertools. When you need to do some complex iteration through lists, itertools is great. When you need to pull an address out of a web page, itertools does absolutely nothing to make that easier, nor does any other functional programming technique.

So here is the difference. Procedural style is better for dealing with a problem. Functional style is great for applying a solution to lots of pieces of data in a structure that can be iterated over or recursed into. The hard part is dealing with each problem, not the part where you apply it.

<comment><AUTHOR> > When you need to pull an address out of a web page, itertools does > absolutely nothing to make that easier, nor does any other functional > programming technique.

I'd say an approach like "iterating through all nodes, filtering for the one(s) you want" is quite functional. Add lazy iteration to that, so you're only parsing/consuming as much of the document as necessary, and on-demand, and you've got a really nice, _functional_ solution.

[edit: toned it down a little.]

<comment><USER20> Ok, that is great so long as you are processing XML. Actually, it isn't great even if you are processing xml.

What is the functional way to get the 3rd - 8th li in the 2nd ul where the ul has id="foo" and is in a div (either directly or as a decedent) where the div is directly before the 'comment' <\-- content area --> ?

You use XPath, or CSS after finding the comment with a regex. People get incredibly retarded about functional languages, but in reality the only software that I have used that is written in one is XMonad. So in your mind everyone who actually gets things done is using the 'wrong language'? Or an inferior one?

Name one big success story of functional programming. There isn't one. Nobody uses it who actually cares more about getting things done than reading self congratulatory blogs between CS classes.

[in no way toned down]

<comment><USER21> "Name one big success story of functional programming. There isn't one."

Map Reduce. It is _implemented_ in C++ (and other languages) but MapReduce itself is very functional. The users of mapreduce do "functional programming". Maybe you wanted success stories of functional programming _languages_? (which is a different question).

Another : SpreadSheets

Yet Another: SQL . SQL is (at the core) relational rather than functional, but functions are relations. This keeps getting rediscovered every now and then (witness all the noise around Rails3 and Arel)

"Nobody uses it who actually cares more about getting things done"

It must be nice to be so certain and knowledgeable about such things. You are a lucky man ;-)

<comment><USER22> I think he meant software. SQL is a standard on paper, not software. Map Reduce is a framework, ok. But written in C++?

A software project that i would say counts is ejbabberd. But, that's the only one i can think of.

Somehow i never looked at it in this way, but Lisp has been around since 1958, Erlang and Haskell are not new either. Still there is not much software written in those languages compared to other languages.

<comment><USER23> It sounds to me like you're the kind of person who has trouble recognizing OO code written in C.

Once you truly understand a programming paradigm you can express it in any Turing-complete language you want to. If you find yourself unable to do this, then you don't really understand that paradigm. And I assure you that the people at Google who implemented the map reduce framework understood functional programming very well.

Incidentally the fact that you disqualify SQL from the discussion because there is a paper standard seems to me to be silly. It is about as silly as saying that C isn't really a software language because there happens to be a written standard defining the language. The existence of the paper standard doesn't change the fact of a lot of _software_ is being written with that piece of programming technology.

<comment><USER22> The fact that you compare SQL to C tells me that we clearly have a different understanding of programming languages, yes. There are people that say "i code HTML". Yes, call it coding and programming if you like. I won't. Clearly SQL is powerful and great but you don't write software in it, which is my point of differentiation.

Yes yes, and there are probably a lot of programs writen in Ada and Fortran that have millions of lines of code and are reliable. But, you can argue with me or not, it still is a niche.

C appeared in 1972.

Lisp (as one of the oldest i can think of) appeared in 1958.

Can we agree to say that there are far more programs written in C then in Lisp? I don't argue which language is "the best" (because clearly, it's more subjective then objective to state on that). But somehow, there is probably a reason, that C, as a newer language than Lisp, has by far more "followers" then Lisp. If Lisp (as the grandfather of functional programming, but you can replace lisp with haskell, erlang or whatever you like) is so easy, creates better, more reliable code, etc. etc. Why did C take off and Lisp didn't? In fact why do younger languages like Ruby have the bigger growth? Clearly people look for new languages, the people that nowadays learn ruby or c#. Why don't they learn Haskell?

For example: Look at [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) The really brand new language Go made it to #13. Lisp/Scheme after decades is #18. It's becoming more popular it seems, but i bet it won't be in the top10 for the next years.

Now, my simple and plain question is: Why is it like it is?

I actually don't want to argue what the best language is, there is no sense in that. And i can't code functional. See me as an observer from the outside. I'd like to learn erlang some time, for sure.

<comment><USER20> I agree. It's like saying that a Porsche is 'better' than a Ford, but you own a Ford because the Porsche costs more money than you make in a year.

I think functional language proponents want to compare languages using one set of metrics, even though they actually pick a language to write software in on an entirely different set of metrics. I mean they must either do that, or be entirely all talk, since very little software is being written in functional languages.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> The only reason I'm starting to leave Python is because of performance. When you see a program that used to take 2 hours to run in python now taking 10 minutes in Java, it kind of makes you realize you've been making a mistake by using it places it doesn't belong.

<comment><USER25> There's always Jython for occasions like this one...

<comment><USER9> Jython is closer to Python's speed than Java's.

Or if you mean Jython with the speed-critical bits written in Java...well, there's always C for that.

</comment></comment></comment><comment><USER26> Python holds a strategic middle ground. It's far more productive, expressive and concise than the traditional procedural and OO languages. Although not as expressive and elegant as the new FP languages like Clojure and F#, the latter lack massive libraries and modules that have been written for Python. That makes them useless for any 'real' work.

Python is seeing some heavy use by the scientific community due to tools like NumPy, matplotlib, libsvm and what not. Good luck finding that range of independent libraries for a new FP language. I am not dropping Python in the near future, but I am watching.

<comment><AUTHOR> Clojure can use (with very little mismatch) any available Java/JVM libraries.

F# can use anything available for the CLR/.NET.

Libraries are not really an issue.

</comment></comment><comment><USER27> I am a Python programmer. I have toyed with functional languages (Scheme, SML) for many years. Over the time my code is becoming more and more functional, in every language I code in. Nevertheless, I do not plan to quit Python at all. Readability counts in my book and I do not see Clojure to be more readable than Python. Moreover, I am not considering F# since it is platform specific and I do not develop on Windows. In my experience Python is not losing programmers; perhaps 0.1% of them are moving to functional languages, but more are coming from C++, Java and even Ruby.

</comment><comment><USER28> I am an active contributor to www.RosettaCode.org where I browse many languages. What I have seen of the functional languages doesn't make me want to switch.

Despite knowing Pythons functional tools, it wasn't Python that introduced me to that style. I find Pythons mix comfortable and happily switch between programming in Python 3 and Python 2. Maybe the OP hopes to start a trend?

\- Paddy.

</comment><comment><USER29> Judging from the comments, people leave Python to do toy projects in functional languages.

My guess is that after using functional languages in real projects, most of them will go back to Python.

</comment><comment><USER30> Well, on blogs Haskell, F# and clojure are popular, but in the words of past decades:

Show us the code.

<comment><USER19> I've gotten paid to work on a lot more Haskell than Ruby or Python. The languages you see depends on the languages you want to see.

Haskell is really quite adequate for real work these days. It has the libraries you'd expect, and it's a nice language with a nice runtime.

It's also worth noting that blog-popular languages are blog-popular for a reason. The people that blog about programming are the ones that need tools that give them a bit more productivity between the occasional nap or meal; the people that use the more esoteric languages want to solve so many programming problems that a sharper tool is essential to their survival. (There is only finite time, after all, and programming languages are easier to build than time machines.)

In contrast, the "popular" languages are mostly used by people whose goal is to warm their chair for 8 hours and receive a paycheck. There are a lot more people that want money than that want creative time with a cold, unloving machine, so it follows that the languages where you can get paid and not care are going to be most popular.

But if you are the second type of person, there is little advantage in worrying about what is "popular" in "the real world". You don't want to be in the real world.

<comment><USER28> Python, popular!!! that is just so great! I've watched it grow for over a decade and a half. Python got were it is, largely without the big initial push of large companies.

Maybe people now blog about python because the community has always tried to be friendly. It is usually nice to blog about Python, and have fellow enthusiasts give measured, polite feedback.

"... so it follows that the languages where you can get paid and not care are going to be most popular."

But it does not follow that there are less caring, articulate, and productive souls in a more popular languages camp.

\- Paddy.

<comment><USER19> Before you get too upset, the "popular" languages I'm thinking of are C# and Java. Python is in the "smart people" category :P

</comment></comment></comment></comment><comment><USER31> Is this like the exodus of the Ruby programmers? Remember Ruby was on rage couple years ago? But suddenly became out of favorite due to various issues. Looks like Python is the same way. People play around with it and find out all kinds of issues. When a new language appears (Clojure), people leave in doves. Just another fad.

<comment><USER32> I've been using python for about 8 years before feeling like i wanted to move. I think that puts me well outside the fad window.

</comment></comment><comment><USER33> False: "There is an observable trend in Python programmers that results in a reasonable section of them moving to functional programming languages."

True: There is an observable trend that more and more people are using Python, and there is a smaller set of people that is not a subset of Python in any way that is toying with functional programming, usually for academic or masturbatory purposes.</comment>


An Epidemic of Fear: How Panicked Parents Skipping Shots Endangers Us All - <AUTHOR> http://www.wired.com/magazine/2009/10/ff_waronscience/ <comment><USER2> How did the duplicate thread detector miss the previous submission?

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


Get 35% discount on C# Smorgasbord [Book]  - <AUTHOR> http://blog.filipekberg.se/2012/10/08/c-smorgasbord-october-sale/

<comment><USER2> Is there any decent review about this? I'd rather read a good review than know that something I dont care about is cheaper for a limited time.

<comment><AUTHOR> There are the Reviews on Amazon Us ( [http://www.amazon.com/C-Smorgasbord- Filip-Ekberg/product-rev...](http://www.amazon.com/C-Smorgasbord-Filip- Ekberg/product- reviews/1468152106/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1) ) and Amazon UK ( [http://www.amazon.co.uk/product- reviews/1468152106/ref=dp_to...](http://www.amazon.co.uk/product- reviews/1468152106/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1) )

Other than that there's a DZone article with an interview with me here <http://dotnet.dzone.com/articles/meet-author-c-smorgasbord>

Hope that helps, if you have any questions about the book feel free to ask!

<comment><USER3> Is there an eBook only version?

<comment><AUTHOR> Yes, there's an ebook bundle that includes PDF, ePub and Mobi available here: <http://books.filipekberg.se/#ebooks>

It's also available on Kindle here: [http://www.amazon.com/C-Smorgasbord- ebook/dp/B008Z4TOPK/ref=...](http://www.amazon.com/C-Smorgasbord- ebook/dp/B008Z4TOPK/ref=tmm_kin_title_0)

<comment><USER4> In the preview of the text version, the code formatting looks good. In the preview for the Kindle version, the code formatting looks awful.

This is the number one problem I look for in programming ebooks.

<comment><AUTHOR> That's because the Kindle previewer uses one of the oldest Mobipocket/Kindle viewers to generate the preview.

I've worked a lot on trying to make the content look as good as possible on all possible Kindle versions, the later Kindle versions support HTML5/CSS3 which makes it very easy to make it look like the Print/PDF version.

<comment><USER4> Good to know. I bought it.

On the Nexus 7 the formatting is good. Even on the smallest font, you can't get much code on the screen. But most of the code snippets are small and it works.

On the Kindle for PC app it looks great.

On the Cloud Reader (read.amazon.com) it is still awful.And maybe there is nothing you can do about that.

Anyway, thanks for all the hard work. Look forward to reading it.

<comment><AUTHOR> Thank you! I hope you enjoy the read. I'm glad to hear it looks good on Nexus 7! Unfortunately there's not much to do about it, since it lacks support for a lot of things that is needed to make the typesetting for a programming book good.</comment></comment></comment></comment></comment></comment></comment></comment>


Preact: Fast 3kb React Alternative with the Same ES6 API. Components and vDOM - <AUTHOR> https://preactjs.com/ <comment><USER2> We provide 3rd party widgets to sites and originally built them all to leverage jQuery, which has been on 100% of them so far.

However, we prefer React components. Within a week, we were able to convert the jQuery widgets into React components and bundle with Preact.

What's funny is that it ended up being a smaller bundle due to complex logic it took to make jQuery render and update the DOM from existing state. (React's bread and butter)

</comment><comment><USER3> Fast and broken.

<comment><USER4> Broken how?</comment></comment>


GitHub Down with a 503 - <AUTHOR> https://status.github.com/ <comment><USER2> Random somewhat on-topic question. How does one measure ones technical capability to keep up services that are more available and dependent than third party solutions? I mean obviously starting out, almost everybody can benefit from doing a lot of stuff not in-house, but at some point you'd be able to do better yourselves. But then maybe for certain services from certain providers, raw technical capability never catches up?

How do you know when that point is? Is there even data out there on how frequently big providers go down? (Not just Github, but stuff like aws, etc)

<comment><USER3> By the time you're talking about 99.9% uptime there is only 9 hours downtime a year so there isn't much wiggle room for failure. There is never a reason any one person should assume they can do better than a third party because you're likely sleeping 2920 hours a year. Basically, you're never good enough on your own. If you care about uptime you're going to need to pay good money for it.

<comment><USER4> But, hypothetically speaking as of now, could this be automated? And if so, how?

<comment><USER3> In short, no, unless you think people replacing broken hardware or patching bugs in your software can be automated.

Your question is too vague. Github is up enough that I don't care. However, it's down enough I wouldn't want to not be able to deploy because it's down. Therefore, I may mirror my repo somewhere else. That's easy because git is decentralized. It's a lot cheaper than running some alternative that I guarantee is always running. You can do this by simply pushing to a mirrored remote branch.

If you're just interested in the subject, research high availability.

</comment></comment></comment></comment><comment><USER5> Reminds me of the classic bumbling quote: "Why don't they just host GitHub where they host the status page?"

<comment><USER6> "Why don't they make the whole damn plane out of the black box?"

<comment><USER7> I'm always impressed that life support systems on star trek fail, but artificial-gravity never ceases to work.

<comment><USER8> Probably there are a handful of gravitons or something embedded right in the floor, or there is massive inertia to the system. We tend to forget that not all solutions require active power.

<comment><USER9> This does makes one wonder that if you need to make an app that has as little downtime as possible perhaps the best solution is to port as much as possible functionality client-side with client-side caching of data.

(theoretically, if I could cache every repo I visit using squid-proxy, even if github has an hour downtime I can still access the repo's I visited in the past, not perfect, but it's something!)

</comment></comment></comment></comment></comment><comment><USER10> Alright...well, it looks like this whole programming thing was a bust. Was good while it lasted, but yeah, uh, I guess I'm gonna go home, er, something - so...see you guys later?

</comment><comment><USER11> Haha, I wonder how many of us came here because we couldn't push or pull commits, so just taking a HN reading break... and boom the top post is about Github!

<comment><USER12> When Github appears down, I come to HN to find out if it's affecting everyone :p

<comment><USER13> 'Gee, github is down. Is it just me? Better check HN!' Exactly what I just did too.

<comment><USER14> This is what I do as we'll. :)

</comment></comment></comment></comment><comment><USER15> It's amazing how often github actually goes down - 90% of the time they don't log it on their uptime / status page - it got so bad at one point I added it to our Nagios monitoring to prove a point to our devs that they shouldn't rely on external services for builds when our internal git(lab) server hasn't gone down once this year.

<comment><USER16> How does one depend on Github for builds if git is, um, distributed?

<comment><USER8> go get, npm install

BTW the official standing on dependencies in Go is to actually fork all deps you need, possibly using submodules or even vendorizing by adding src/* to your project VCS.

</comment></comment></comment><comment><USER17> I was waiting for this post :)

Let's see who the Saturday team is!

<comment><USER18> We have an amazing team of people who are available and on-call 24/7 for these sorts of incidents.

<comment><USER17> Oh I don't doubt that. I meant finding out who was lurking around HN on a late Saturday early Sunday. The team at Github does great work!

</comment></comment></comment><comment><USER19> [https://twitter.com/shit_hn_says/status/421116237792284672](https://twitter.com/shit_hn_says/status/421116237792284672)

</comment><comment><USER20> Exception percentage just got over 100%, new record! (?) [http://i57.tinypic.com/4hphtd.png](http://i57.tinypic.com/4hphtd.png)

<comment><USER21> It is now up to 175% a couple minutes later (and 205% a couple minutes after that). The issue seems to be that it is actually currently more like 10000%, and is being averaged down throughout the month to a mere 100-200%. What is this even measuring?!

<comment><USER22> If I were implementing something tracking the rate of exceptions a reasonable thing to measure it against is the total number of requests. In such a system, if each request generated multiple exceptions you would have >100% exception rate.

</comment></comment></comment><comment><USER23> I was wondering why my `bower install` was failing... :/

<comment><USER24> Doesn't bower install from a local cache if network request fails? npm on the other hand...

per docs at [https://github.com/bower/bower](https://github.com/bower/bower) oh....

<comment><USER23> Yeah it does pull from cache, but I didn't have the packaged cached yet.

As for the docs, it is somewhat crazy to think how much documentation is hosted by GitHub these days...

</comment></comment></comment><comment><USER25> Yep. All metrics down and exception rate is up gentlemen: [http://imgur.com/Ncm5Rrx](http://imgur.com/Ncm5Rrx) . I just noticed when SQLMap install was hung and every tarball/zip download on their site also leads to Github , oy vey!

<comment><USER26> At least webhooks are becoming faster..!

</comment></comment><comment><USER27> Could Github store mirrors of all repositories on some third-party service, like S3?

Even if they were only updated every 24 hours and had a limited history for each repo, it still seems like it would be a really useful fallback that they could put up when things like this happen.

<comment><USER28> It's actually not _that_ hard to set up your git to push to both Github and another repository at the same time.

<comment><USER27> Sure, it's easy to do with your own code. But what about apps that don't vendor their dependencies? If you need to pull in third-party dependencies when you deploy or test, it's still possible to maintain your own mirror, but it would be nice if you could depend on the code being "up".

</comment></comment></comment><comment><USER29> Somehow I opened the GitHub Status Page subconsciously early this morning, then everything suddenly became 503 in less than 10 minutes!

I still have the tab opened now, saying "All systems operational"...

<comment><USER29> Seems like it's back now. (3:13 UTC)

</comment></comment><comment><USER30> Why have they gone down so often in the past few months? Is this another DDOS?

I've personally wondered about their stack but I imagine that has little to do with that--mostly Ruby though right?

<comment><USER31> It seems to be MySQL related this time:

"github.com is currently unreachable. We are investigating mysql cluster issues."

</comment></comment><comment> 4dl0v3-p34c3 I hope it was just an error or something. Nothhing political, like this:

[https://gist.github.com/kyledrake/e6046644115f185f7af0](https://gist.github.com/kyledrake/e6046644115f185f7af0)

More info:

[http://www.theverge.com/policy/2014/5/9/5699510/web- hosting-...](http://www.theverge.com/policy/2014/5/9/5699510/web-hosting- company-puts-fcc-in-slow-lane)

<comment><USER32> the gist link is also a 503

</comment></comment><comment><USER33> Tempted to deploy via rsync on my laptop

</comment><comment><USER34> I'm wondering if this will give bitbucket a boost in unique visits.

</comment><comment><USER35> Right in the middle of a major push to production. Awesome.

<comment><USER36> It's too bad git requires a central server.

<comment><USER26> How is this a useful comment? Everybody knows that Git is distributed. Everytime Github's down, somebody feels the urge to remind everybody else about that.

Github's not only Git. Lots of services integrate with Github. Stuff like continuous integration, continuous deployment. If your system is built on those things, Github being down will prevent you from deploying.

What's the alternative, replicate everything in-house/self hosted? Should startup stop using third party service providers?

<comment><USER36> If your workflow involves services that integrate with GitHub, you should have a plan for when GitHub is not available. You've got your source code elsewhere, you should have docs and procedures for running the tests in your own dev environments and for utilizing whatever staging/deploy process you prefer without GitHub as an intermediary.

I continue to post comments like that because while I love GitHub, watching the community put all their eggs in GitHub's basket, especially when GitHub lives on top of a tool designed to avoid SPoFs, is concerning.

<comment><USER37> 100%. GitHub is amazing. GitHub is a wonderful tool. GitHub is also just a service cooked up by a handful of jokers who got enough funding to make it happen, and they do a reasonable job of keeping it running most of the time. I wish them all the best, and yet making my own company's infrastructure reliant on it is not something I'm comfortable with. Sometimes they're going to blow it, and that's ok. If them blowing it means my business is affected, _I 'm_ the dummy.

<comment><USER38> > _jokers who got enough funding to make it happen_

While I agree with the general gist of your comment, GitHub was entirely self- funded up until about a year ago or so. they didn't "get" funding, they made real money and reinvested it and grew.

<comment><USER37> Fine, bootstrapping jokers are my favorite kind of jokers. No offense intended. My point is it's just a small company with no SLA, express or implied. It could have been anybody with the same great idea, and just because they had a great idea doesn't make them automatically reliable enough to pin your infrastructure on.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> Curious, which chart lib is GitHub using for those charts?

<comment><AUTHOR> They make calls to d3 in the chart snippet, so I assume it's that. Here's the relevant code from application.js: [http://pastebin.com/ApL9SxXs](http://pastebin.com/ApL9SxXs)

</comment></comment><comment><USER40> all the overachieving engineers working on a saturday...

</comment><comment><USER41> Oh damn. The Github team is in for a rude awakening...

</comment><comment><USER42> > We are investigating mysql cluster issues.

</comment><comment><USER43> Yeah seems so.. [https://status.github.com/](https://status.github.com/)

<comment><USER41> Thats what the link above goes to

</comment></comment><comment><USER44> It's all over now.

</comment><comment><USER45> GitHub now available.

</comment><comment><USER46> and right when I wanted to clone something. damn.

</comment><comment><USER47> It's back!

</comment><comment><USER48> you are really the early bird.

<comment><AUTHOR> I was setting up a new repo, and then everything stopped working. Lucky timing, I guess.</comment></comment>


Apache.org hit by targeted XSS attack, passwords compromised - <AUTHOR> http://blogs.zdnet.com/security/?p=6123

<comment><USER2> To me this seems pretty frikin huge. The number of sysadmins and developer's using bugzilla, jira, confluence... I would assume a good number of them are using very crackable passwords (common words etc.), even if it's just a minority, which could then expose countless other systems managed by each of those sysadmins / devs who had their password hacked, because they probably also use a rotation of 1-3 passwords for other services...

\- or -

Am I just on crack?

<comment><USER3> I told them not to mess with their .htaccess unless they knew what they were doing!

</comment></comment><comment><USER4> Today is the day that tptacek gets to run around screaming "I told you so" :-).

I don't remember when or why I created it, but I have an account on the compromised server. It was a non-unique password, but fortunately one that I've never used on any account of value, and one that I rotated out a while ago on every account that I ever use at all.

</comment><comment> brown9-2 The Apache team was nice enough to be pro-active and send me an email alert:

 _You are receiving this email because you have a login, '...', on the Apache JIRA installation,<https://issues.apache.org/jira/>

On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:

<https://blogs.apache.org/infra/entry/apache_org_04_09_2010>

We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password you set when signing up as '...' to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it should be assumed that the attackers can guess your password from the password hash via brute force.

The upshot is that someone malicious may know both your email address and a password of yours.

This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online banking sites, or sites known to be related to your email's domain, gmail.com._

<comment><USER5> I also got the same letter. But I haven't used it in years. Are you supposed to use your email to log in? I need to find out which password I was using in this account.

<comment> brown9-2 the actual email contained my login/username, I assume you could just use that

</comment></comment></comment><comment><USER6> A little disturbing that Slicehost wasn't responsive to Apache.org telling them they had a compromised image.

<comment><USER7> Really?

* Passwords hashed with SHA-512 _unsalted_

* No lockout / notification after hundreds of thousands of failed logins

* XSS vulnerability

* Able to change the configuration to upload executable scripts

* SSH password authentication enabled

And your top concern was that Slicehost didn't immediately shut down a machine? Would it have really slowed the hackers down for more than an hour anyway?

<comment><USER8> fwiw, 4/5 of your points are specific issues to Atlassian JIRA, a commercial product :)

The 5th point, as explained in the post... We actually tried to disable Password based authentication -- It is the ASF's standard policy for it to be disabled! -- we just failed at testing the configuration on Brutus. On our other machines, we had a block of configuration options we appended to the END of the sshd configuration, and these options successfully turned off password authentication, requiring ssh keys only.

On brutus however, we were missing a "UsePAM no", which meant pam went in and fell back to password authentication. This was a mistake, and we didn't realize until after the vulnerability when we were testing the machine, that its sshd was misconfigured.

<comment><USER7> I didn't mean to criticize. There were mistakes made - there always are. But amongst the list of mistakes, I would not put Slicehost's slow response anywhere near the top, and I'm surprised that anyone (particularly someone whose opinions I normally respect) could choose that as the lesson to highlight.

Anyway, when is Apache going to get serious about a bug tracking project? :-)

</comment></comment></comment></comment><comment><AUTHOR> A real case illustrating what Jerf helpfully explained to me just 45 days ago: <http://news.ycombinator.com/item?id=1154379>

</comment><comment><USER9> "The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights."

I may be wrong here, but isn't using a session cookie to authenticate a login which allows one to upload files to an executable directory a bad idea?

Wouldn't asking for the user's password again when the he needs higher privileges (a la popular bulletin board software) stop the whole attack in its tracks?

</comment><comment><USER10> I always find it fascinating how fast security falls when you find the one weak spot. They were lucky to spot them so fast (relatively) I'm sure minotaur would have fallen with time too.

<comment><USER11> This wasn't the case of a single weak spot. There where numerous issues with their security setup on this server. See <http://news.ycombinator.com/item?id=1262784> for a short list.

<comment><USER10> It's a lot _lot_ easier to exploit those weaknesses when your inside some of them.

The XSS exploit was like the stopper in the dam.

</comment></comment></comment><comment><USER12> Every shortened URL is a dangerous URL!</comment>


Australia Has Slower Internet Than Kenya, Russia and Hungary - <AUTHOR> https://www.bloomberg.com/news/articles/2017-10-03/digital-doom-threatens-australia-where-internet-speeds-lag-kenya <comment><USER2> So disappointing. It's amazing that we can have a government claiming that innovation and a space agency will be our future when they just want to lie to us about the NBN and it's being a failed project. One of the largest and most important infrastructure projects in Australia that got gutted because Tony Abbott is a wanker. I really hope the LNP split and Tony joins Cory's conservatives. Telstra and the LNP have lost me forever because of this. I really believe that they have betrayed the country.</comment>


Every NIMBY's Speech at a Public Hearing - <AUTHOR> https://www.mcsweeneys.net/articles/every-nimbys-speech-at-a-public-hearing <comment><USER2> I've been to this meeting in my town more than once. Second place is "I moved here because I love everything about this place, except for the things that made it possible (diversity, taxes), so we need to get rid of the things that I don't like...".</comment>


Fourier Features Let Networks Learn High Frequency Functions in Low Dim. Domains - <AUTHOR> http://people.eecs.berkeley.edu/~bmild/fourfeat/ <comment><USER2> > We show that passing input points through a simple Fourier feature mapping > enables a multilayer perceptron (MLP) to learn high-frequency functions in > low-dimensional problem domains. These results shed light on recent advances > in computer vision and graphics that achieve state-of-the-art results by > using MLPs to represent complex 3D objects and scenes. Using tools from the > neural tangent kernel (NTK) literature, we show that a standard MLP fails to > learn high frequencies both in theory and in practice. To overcome this > spectral bias, we use a Fourier feature mapping to transform the effective > NTK into a stationary kernel with a tunable bandwidth. We suggest an > approach for selecting problem-specific Fourier features that greatly > improves the performance of MLPs for low-dimensional regression tasks > relevant to the computer vision and graphics communities.

I don't know what some of those words mean but had been wondering why neural networks did not have Fourier transform blocks. Convolutions become point-wise multiplication when the functions are decomposed into their frequency components so it seemed like an obvious thing to do. It's good to see I wasn't insane.

> In this paper, we train MLP networks to learn low dimensional functions, > such as the function defined by an image that maps each (x, y) pixel > coordinate to an output (r, g, b) color. A standard MLP is not able to learn > such functions (blue border image). Simply applying a Fourier feature > mapping to the input (x, y) points before passing them to the network allows > for rapid convergence (orange border image).

Technically a Fourier feature mapping is not a Fourier transform but the idea of decomposing functions into their frequency components before feeding them into a neural network seems to hold up.

Fun paper. Thanks for posting.</comment>


A curated list of Python frameworks, libraries and resources - <AUTHOR> https://github.com/vinta/awesome-python

<comment><USER2> Pytables should be on this list</comment>


10,795 iOS apps submitted, 3,123 schemes, 98 contributors, * and other odd CURLs - <AUTHOR> http://tumblr.com/x5h33nfz2z

<comment><USER2> "There are 7 different apps that respond to "fb259197467584""

From [1] we know this is a Facebook app with appID 259197467584. From [2] we know that the app is something called AppMakr which from [3] looks like some sort of crappy iOS app generator.

[1] <https://github.com/facebook/facebook-ios-sdk>

[2] <https://graph.facebook.com/259197467584>

[3] <http://www.appmakr.com/>

</comment><comment><USER3> How does iOS handle scheme collisions?

I couldn't find any information on this after a quick search.

<comment><AUTHOR> [http://stackoverflow.com/questions/5103260/how-ios-handle- ur...](http://stackoverflow.com/questions/5103260/how-ios-handle-url-scheme- duplication)

Although in all fairness I have to mention that this hasn't happened to me personally, so I can't verify that it works exactly like that</comment></comment>


Goldman Sachs trade secret thief claims codes were 'open source' - <AUTHOR> http://www.bloomberg.com/apps/news?pid=20601087&sid=a1wLXjWnp_5E <comment><USER2> What, they're running this? <http://www.marketcetera.com/site/>

</comment><comment><USER3> His first mistake was leaving Goldman to begin with. In my opinion Goldman is one of the more evil corporations out there. And there's no better place to avoid their bubble building and bursting than to work for them, depending on how you feel about that ethically.

</comment><comment><USER4> What the heck are codes?</comment>


Hidden Costs That Engineers Ignore - <AUTHOR> http://www.theeffectiveengineer.com/blog/hidden-costs-that-engineers-ignore?utm_source=Founder+Weekly+Newsletter&utm_campaign=1a5eed15d1-Founder_Weekly_Issue_163_December_31_2014&utm_medium=email&utm_term=0_286b01fd3e-1a5eed15d1-331306269 <comment><USER3> What worked for us was to do two versions of the program at the same time.

Version one had simple functionality. Version two had all the bells and whistles dreamt up by the programmers and the customer while we were working on version one. Those were added to a todo list for version two. They were not implemented in version one.

That kept up the flow of ideas but didn't disrupt the project. It made the programmers feel appreciated while giving us an outline for the next version so our competitors couldn't keep up.

What surprised me was that the whole team got into the spirit of the thing. When someone came to me with an idea, cries of "Version two! Version two!" echoed around the programming room.

<comment><USER4> We were doing something similar but the result was a mess. Sometimes version 1 needed something that depended on unreleased stuff in version 2. It lead to fragmentation where we developed two implementations of the same functionality.

</comment></comment><comment><USER5> The problem is that as requirements grow, class structures are often kept the same but the 'glue logic' which operates on these structures becomes increasingly complex (you have to handle a growing number of edge cases).

There is a point where the glue logic becomes very complex (and brittle) - <USER2> that point, the best thing to do is to redesign part of the system's class structure.

If your components (at all levels of your class hierarchy) are specific about their own behaviors, it means that you can use simpler glue logic to make them work together.

When you need to handle a lot of complex use cases, it's often useful to have many specific classes which share the same interface and can be used interchangeably.

<comment> cam- If we get several bugs or the team recognizes that an area is becoming brittle we make a bug that one/two team members work on for the sprint to clean that entire area up. The PO has become used to these kinds of bugs/user-stories and prioritizes them.

</comment></comment><comment><USER6> Unfortunately, sometimes the simpler system is the one you don't yet understand, and the more complex system is the one you can create on your own using tools you do know. This is the reason we still see homegrown business rule systems despite the fact that they were pretty much perfected them by the late 70s, with several open source implementations as of the late 90s. It is also the reason you still see deadlocks and race conditions in parallel code. And it is the reason you see matrix factorizations using hadoop map reduce instead of MPI.

And when these bullshit foundational design decisions are made, the "improvements" that the engineers make to the system later are almost always a reduction in fidelity to the real world process that is being modeled, instead of a move toward a system that drastially simplifies your system while simultaneously improving fidelity to the real world but might mean you have to read a wikipedia article for a few minutes.

</comment><comment><USER7> There is a good book about this. It changed my thinking about complexity. The key insight is that if you don't manage complexity you will drown in it. Complexity is OK as long as it really earns its keep. And a lot of complexity is not worth it. (I speak as a person who just spent 20 hours - less than the IRS's estimated 30 hours - filling in form W-8IMY for the IRS, a form which started as a bright idea by someone in congress).

"Conquering Complexity in Your Business: How Wal-Mart, Toyota, and Other Top Companies Are Breaking Through the Ceiling on Profits and Growth Paperback" by Michael L. George and Stephen A. Wilson

<comment><USER8> Thanks for this, very interesting, I'll give it a read. I've long wondered if the aversion to complexity in SV is at times pathological, that is, "it adds complexity" is often used as a reason not to commit to building something that would absolutely add long term benefits that outweigh the costs. I guess it's just harder to quantify potential future benefits against immediately obvious complexity, but all the same, I think pathologically avoiding complexity is just as bad as pathological complexity :)

</comment></comment><comment><USER9> The notion of holding a Code Purge Day (as Quora did) is excellent. Searching out and removing cruft in the code base results in a benefit that's hard to measure but easy to understand. Having more compact code without confusing distractions leads to easier comprehension and ought to make for faster bug fixes.

<comment><USER10> Exactly. The best line of code is the one you dont have to write. The second best is the one you can delete.

<comment><USER11> My favorite aphorism for this is "There's no code like no code."

</comment></comment></comment><comment><USER12> _Matching passengers and drivers while adjusting prices to balance supply and demand is a complex and hard problem. So is routing questions and answers to the people most likely to answer and read them_

I used to work with a guy who worked on the compute infrastructure that CERN uses to sift the petabytes of data they get from the LHC. That's a hard problem.

And that's the problem with web guys, they think the web is all of computing, yield management has been done by airlines and hotels for DECADES. It is very, very far from breaking novel ground at this point.

Now the points he makes about the TCO of a new feature are valid but please, if you're going to brag, be prepared for people to yawn.

<comment><USER13> This point is quite nitpicky, no? The sentence you quoted could have been removed from the article and the article would have largely been unchanged - my point being it seems dubious to critique an article for a tangential point in the introduction which has nothing to do with the premise of the article.

I think what it really is, is some people just like to complain about "web guys" every opportunity they get. And while your criticism may have been perfectly valid, it is entirely irrelevant to this article.

<comment><USER12> Not at all; the structure of the piece is, these are all the impressive things I've done, so you should listen to my ideas. It would have been a stronger piece of writing if he'd just jumped straight in. Or, actually had done some impressive engineering.

There's a bit of ageism there too. Über's yield management code could probably have been written by one grey haired guy from United Airlines or Marriott. Instead they got a whole bunch of twenty something's who think they're doing "data science".

</comment></comment></comment><comment><USER14> You can't do this for games. Sometimes a game needs a particular feature that has a ton of states and complexity.

The only thing you can do is 1)Mitigate that by isolate it 2)Separation of concern

You could have a component that's fuck-all complex, but as long as it's a single, isolated component, that can be disabled by

messedUpComponent.isEnabled = false, then I'm ok.

<comment><USER15> > You can't do this for games.

Sure you can. For example people need to move around in the game. You can add rideable objects - or not. Usually you don't need to ride something for the game - it's just cool. So this is complexity you can remove.

You can take it a second step - assume riding is required. Do you want various types? Say you ride a horse - do you need multiple colors and sizes of horses?

Or something as simple as allowing the character to change hats.

</comment></comment><comment><USER16> As a one man army indie game developer I basically can no longer maintain my code-base without going crazy because it's grown to the point where it's no longer a one man job. I knew this would be a problem, so keeping code complexity to a minimum has always been a priority, but it's no longer possible to keep up. Thankfully it's reached maturity as a product and is a fun and profitable game. Many people think i'm 'brilliant' when they see the product and they hear i'm the only the developer and it's a custom 3d engine. But truth of the matter is much of my brilliance was stubbornness and cleverness in keeping things simple and code complexity to a minimum. The problem is you run out of memory in your brain. You forget how systems work. You have to trace back through the code and "reload things". When you have to make a modification.

When I hit my human ram capacity so to speak, i was extremely frustrated that I couldn't make the boundlessly quick progress that I used to. But then you get used to it, and just accept that it will take time when you switch from one subsystem to the other, to load up the relevant parts of the code into your human ram in order to do be able to do the work you want to do.

The simpler and more straightforward the program architecture, the easier it is to jump into and out of and write new code. Of course understanding what your product is and is going to be helps tremendously in making sure you can design your program in a sensible way.... I've been lucky enough to have a firm intuitive understanding of future the design of the game and it's features as it was being formed. (not being at the mercy of clients or bad managers is a wonderful thing)

What i've noticed is a big difference from me and friends with small development studios that accomplish less with a lot more sweat. Is that I don't develop fully featured flexible systems when simple ones will do, I don't roll my own code when good/simple libraries or apis exist. I'm trying to make my product a work of art, and the code is functional and simple. Where often I see other good engineers try to make their code the work of art. Which leads to lots unnecessary code complexity because they engineer systems designed to be future proof for everything, instead of of what realistically will be necessary for the future of the project or projects. A system with 30 components is easier to understand and easier to maintain than a system with 100. More functions, more objects, and more abstractions. Often mean more components and code complexity. Which ultimately means it's going to take more brainpower to get anything done. Which is why it takes teams of 100s to maintain large enterprise software projects where the incremental updates change very little even though the engineers working on it are educated well trained people. _shrug_

<comment><USER17> > Which leads to lots unnecessary code complexity because they engineer > systems designed to be future proof for everything, instead of of what > realistically will be necessary for the future of the project or projects.

This has been a bane for me in my work. I have termed it lasagna code: lots of layers with a little filling in between each. Often, each layer is isolating things for which there is little-to-zero reason to ever suspect that they will need to change. I've even seen attempts to abstract away data model... As if the entire program wouldn't have to be modified if the data model changed. I have learned to design and code only to known requirements. All the extra time saved in design, coding, and maintenance of the easier reduced system more than pays for the small redesigns necessary when things shift.

</comment></comment><comment><USER18> In the world of enterprise software it's also easy to overlook the cost of implementation/setup of features on the services teams and customers. Is helpful to define nonfunctional requirements that deal with these ancillary concerns.

Also all of these issues highlight why product management needs to have a working knowledge of technology and the related costs of various trade offs.

</comment><comment><USER19> I am totally agree with 'Use data to prune unused features' point.

It might happened that some features were introduced years ago based on demand. But It would be not usable for now. Still those features are maintained. I believe those features should be removed which eventually gives you space to work on innovative features for same product.

</comment><comment><USER20> currently it looks like they ignored the hidden cost of being on the hn frontpage.

</comment><comment><USER21> This article repeats a meme, but is total BS. It's similar to saying "the hidden costs of being a founder" and then stating that if you do ever make a successful exit, you will have a lot of your time wasted by having to select bedlinen and other hidden costs of having made an exit. (the hidden cost to being a founder - you will be forced to work unpaid hours shopping for luxury bedlinen. so consider carefully.) Well guess what: that's not real technical (or founder) debt!

The idea of calling this stuff technical debt is simply laughable. there's no debt. you don't owe shit.

hint: if you code something up in 20 minutes you still don't have to do all that other stuff, you can just ignore it, and throw away the twenty minutes of code if it's not better than not having it. if you become a millionaire you don't have to do all that stuff, you can just ignore it.

Let me put it another way. Say you're an MBA who can't code anything but excel formulas, yet you figured out how to get excel and powerpoint onto the web as a web app (wat). you create something and get 5,000 paying users and raise a $500,000 investment.

Have you created technical debt? No. You're at the same square as if someone gave you $500,000 to spend on developers against your mockups, except that you've validated them as well. There's no debt here. This article had it right:

[http://www.higherorderlogic.com/2010/07/bad-code-isnt- techni...](http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical- debt-its-an-unhedged-call-option/)

The people that call this scenario (excel on the web) technical debt, think that somehow the MBA 'borrowed' the web app from a real dev, and now owes it in real development costs. That's a wrong way to think about it. In fact it's a ridiculous way to think about it.

<comment><USER22> While I agree with you that the notion of 'technical debt' is being overused, I don't think the article is talking about hidden costs as technical debt, but is instead about how product and code complexity incurs hidden costs, some of which but not all can be construed as technical debt.

Code complexity is a good example. A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. That does not incur technical debt, but there is a hidden cost to maintain it given it's complex. On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase, which in the future he/she must pay down by refactoring / writing tests.

<comment><USER23> > A part of a codebase can be complex (sometimes the problem that is being > solved necessitates a complex algorithm / codebase) but yet well written.

I tend to use the following terminology to distinguish necessary an unnecessary complexity:

                      | Easy Problem | Hard Problem
        Easy Solution | Simple       | Simplistic
        Hard Solution | Complicated  | Complex

<comment><USER24> Is a hard problem with an easy solution really a hard problem? A more accurate chart might look like this:

                         | Simple Problem | Complex Problem
        Simple Solution  | Easy           | Elegant
        Complex Solution | Stupid         | Necessary

<comment><USER25> I think simplistic was meant to imply that it wasn't really a solution, just good enough for you.

That said, you can say the same case for your matrix: if there's a simple solution to a complex problem that actually solves it, is it really a complex problem?

<comment><USER24> Sure. "Complex" problems are problems with many facets/moving parts (I recommend watching the Rich Hickey talk "Simple Made Easy"). These problems can in some cases have simple (as in, few facets/moving parts) solutions, although those solutions may not be easy to implement.</comment></comment></comment></comment></comment></comment>