Machine learning has become alchemy (2017) [video] - <AUTHOR> https://www.youtube.com/watch?v=x7psGHgatGM <comment><USER2> The problem with ML in my opinion is not that we're missing some sort of fundamental theory, but that there simply is none. ML is essentially fancy pattern matching roughly resembling the human visual system, which is why it happens to be good at tasks related to perception.

It's not some master algorithm, it's not going to produce sci-fi AI, and it probably isn't even suited to solve most problems in the realm of intelligence.

In fact it basically hits the worst possible spot on the problem solving scale. It barely learns anything given the amount of computation effort an data that goes into it, but it just happens to be good enough to be practically preferable to old symbolic systems.

It is completely mysterious to me how networks that approximate some utility function are a huge step forward to giving insight into cognition, reasoning, modelling, creation of counterfactuals and the sort of mechanisms we actually need to produce human like performance.

<comment><USER3> > It barely learns anything given the amount of computation effort an data > that goes into it, but it just happens to be good enough to be practically > preferable to old symbolic systems.

I don't follow this. Are you implying there haven't been absolutely massive gains in computer vision, nlg, nlp, etc?

<comment><USER4> Those massive gains have yet to considered reliable enough to be considered trusthworthy. Would you consider them trusthworthy in court, where lives are at stake? Gains are nice but we are still so far from the essence of AI systems and considering how much resources we are pouring into learning, at this point all of them appear as nothing more than massive fat expensive toys

<comment> another-one-off > Would you consider them trusthworthy in court, where lives are at stake?

Probably. Human intelligence is extremely fallible - based on the statistics the only reason we trust humans to do half the stuff they do is because there is literally no choice.

If we held humans to a high objective engineering standard We wouldn't:

* Let them drive

* Let them present their memories as evidence in a court case

* Entrust them with monitoring jobs

* Allow them to perform surgical operations

Humans are the best we have at those things, but from a "did we secure the best result with the information we had" perspective they are not very reliable. A testable and consistently performing AI with known failure modes might even be able to outperform a human with a higher failure rate (eg, we can reconfigure our road systems if there is just one scenario an AI driver can't handle).

Basically, you might be dead on the money that they are not 'trustworthy enough', but lets not lose sight of the fact that even being an order of magnitude from human performance might be enough after costs and engineering benefits get factored in. The weakest link is the stupidest human, and that is quite a low bar.

<comment><USER5> > Basically, you might be dead on the money that they are not 'trustworthy > enough', but lets not lose sight of the fact that even being an order of > magnitude from human performance might be enough after costs and engineering > benefits get factored in.

Ironically, the thing that is lost in this comment would be "accountability". In case of a human, you can go back / trace decision making criteria and hold someone accountable. In case of an algorithm, everyone washes their hands off. Performance is not the only criteria to make a decision if algorithms are "trustworthy" over humans.

<comment><USER6> Linear models are highly interpretable and an operator can be held accountable.

</comment></comment></comment></comment></comment></comment><comment><USER7> It is simple to say deep learning is based on "alchemy" or "engineering" or whatever it is that isn't strong theory. And it's reasonable to say deep learning has a lot of mathematical and statistical intuitions but doesn't have a strong theory - maybe just doesn't yet have a strong theory or maybe can never get one.

So this is by now a standard argument. The standard answers I think have been:

1) Well, we are discovering that you don't need a strong theory for a truth- discovery machine. We've discovered experimental thinking construction.

2) It's true deep learning doesn't have a strong theory now but sooner or later it will get one.

3) This shows that instead we need theory X, usually by people who've been pursuing theory X all along. But I think Hinton at least has thrown a bunch of alternatives against the wall over the years.

(I could swear this has appeared here before but I can't find it).

<comment><USER8> Worth also bearing in mind that we've been here before in other fields. Alchemy ultimately became chemistry.

Even in the Victorian era when, for fairly large swathes of the periodic table, and different types of compound, we already had a quite good experimental understanding of chemical reactions in terms of their constituent components and products, along with the conditions under which those reactions occur, we still didn't know the why. We didn't understand much about atoms or how they bond together, for example.

The point is this: science can often take a long time to advance, and AI is still a very young field, with the first practical endeavours only dating back to the post-WWII period.

Should we therefore be terribly surprised that ML seems a bit like alchemy?

As an aside, another normal facet of scientific advancement is the vast quantity of naysayers encountered along the way. Haters gonna hate, I suppose. (But don't misunderstand me: whilst I'm not an ML fanboi, I recognise that advances come in fits and starts, dead-ends _will_ be encountered, and overall it's going to take quite a long time and require a lot of hard work to get anywhere.)

Final aside: this video has definitely been posted here before but I've also been unable to find it.

<comment><USER7> _Worth also bearing in mind that we 've been here before in other fields. Alchemy ultimately became chemistry._

Indeed but that might be where the analogy breaks down.

I think one say that we just don't know how far we can take "experimental computer science" \- where the experimental part is making "random" or actually "seat-of-the-pants" programs and seeing what they do. This is simply new and one could create a physics on top of this particular kind of experimentation is yet to be seen.

</comment></comment></comment><comment><USER9> Even granting the claim that ML has become alchemy, consider what alchemy was: Misguided in its quasi-magical underpinnings and goals, but nonetheless an extremely important step in the founding of modern chemistry. And so what started out with poor understanding and numerous misconceptions evolved over a period of time, through trial and error and hard won knowledge into a massively important branch of science. And so if ML is indeed comparable to alchemy, the only salient question is how long, and what will it take, to turn into chemistry.

</comment><comment><USER10> Science is a combination of theory and experiment. Sometimes theory advances faster than experiment, sometimes vice versa. Right now in ML, experiment aka practice is advancing faster than theory. Theory will eventually catch up.

<comment><USER11> ML is a souped-up version of "draw a line through these points". We can get really efficient at drawing lines through points, but it's not like we'll suddenly realize some deeper fundamental theory about it!

<comment><USER12> The reason you don't expect to see a deep fundamental theory of drawing a line through a few points is because you can always do it. ML doesn't always work, and sometimes it is harder to get working than other times. What's going on?

<comment><USER11> You can always draw a line through the points, but it isn't always a good approximation. If the points are inherently bunched around a line, then a line through them will approximate them well. If they're a big random cloud, then the line won't. It's the exact same way in ML, except the points are in n-dimensional space and "line" is replaced by "higher-dimensional curve or manifold". Sometimes (e.g. in image processing), the n-dimensional points are inherently bunched around a curve or manifold of the form you're using, and then ML works great. There's nothing deeper going on!

</comment></comment></comment></comment><comment><USER13> The ML scene was more rigorous 10-15-20 years ago, because it was mostly confined to the world of academia and industrial R&D, and we had much less wide-reaching problems to work towards.

As tech evolves, more data is being generated, which in turn creates more problems that increases the demand for solutions.

To put it short: Solving "real world" problems is more/better rewarded than figuring out the underlying technology, so it's no wonder that we see a larger portion of practitioners that may lack the academic background - and that is understandable.

You could be a ML Ph.D (in Academia) for 5-10 year, earning gov. worker salary while trying to reach the next step - or hack together some ML-based product, until desired accuracy, and cash in 50-100 times the pay.

Now, with that said, I understand that Ali targeted his speech at the NIPS folk - but the industry / academia crossover in ML is massive, and it still stands that much of industry problems are of commercial interest - so the motivation for many is still the same.

</comment><comment><USER14> Making a serious, industrial scale web app in 2000 felt like alchemy. It was all arcane, there were no established patterns, nobody knew how to do it for sure, there were a lot of hustlers, most of them thankfully sincere.

When something is new, it feels like a mystery - eventually we'll have a language for wrapping our heads around neural networks, even if it's not as clear cut as we'd like.

<comment><USER15> We had the neural networks, and the language. The problem is with the rebranding and the amount of marketing bullshit comming with it. The null hypothesis is that apl of that most of it is a pile of crap, for an overengineered, overoptimized solutions that are probably applied at abstraction layer different from one they are marketed on. There may come solution out of it, but it's more wishfull thinking than not.

</comment></comment><comment><USER16> Sure - perhaps alchemy in the sense that many practitioners are simply throwing things against the wall and seeing what sticks, but not in the sense that there isn't anything real behind all the math or engineering.

Many advancements in machine learning have significant backing in theoretical proofs that a given algorithm will result in unbiased estimates, or will converge to such and such value etc.

On some level, the high amount of experimentation necessary in machine learning is not so much a sign that the practice is faulty in any particular way, but rather, that the world is a complex place. This is _especially_ true when attempting to predict anything that involves human behavior.

Long-story short - I'd cut ML some slack!

<comment><USER17> Alchemists could do a lot, making gunpowder for example is non trivial. They simply worked from a bad model with little understanding of what was going on.

Consider, lead and gold are very similar substances and chemistry lets you transform many things into other things so it must have seemed very possible. Unfortunately, I suspect the current AI movement is in a very similar state even if they can do a lot of things that seems magical it's built on a poor foundation. Resulting in people mostly just trying stuff and see what happens to work without the ability to rigorously predict what will work well on a novel problem.

</comment></comment><comment><USER18> Can someone give a concrete example of the kind of theoretical properties they desire of ``new-style'' machine learning? The kinds of properties that ``old- style'' learning methods guaranteed?

People often complain about interpretability: in what sense is an SVM interpretable that a deep neural network is not?

Or is the worry about gradient descent not finding global optima? But why is the global optimum a satisfactory place to be, if the theory does not also provide a satisfactory connection between the space of models and underlying reality?

The arbiter of good theory is ultimately its ability to guide and explain practical phenomena. Which machine learning phenomena are currently most in need of theoretical elucidation?

<comment><USER19> Most machine learning algorithms that aren't statistical base doesn't give a CI. From a statistical stand point it doesn't give a sense of how good your prediction is. You can get a general sense with just CV.

Also your parameter is not inferable like in statistical algorithm. This is where I see people saying Deep Learning isn't interprable and there are research into this area. If you compare time series stat forecast algorithm with deep learning you at least get a CI on stat algorithm.

Randomly dropping node is pretty magic in my mind.

While I don't know much about SVM I know it's mathematically proven so there should be a way to interpret SVM fitted model.

I sure as hell wouldn't use ML in clinical trial for drugs. That's why biostat is a thing.

</comment></comment><comment><USER20> We are still at the experimental stage, so trial and error without clear theories is not unexpected. Chemistry formed out of alchemy: people fiddled and noticed the patterns. The patterns were written down and shared, and different people began floating theories/models to explain the patterns, and the theories were further vetted by more experiments.

Another thing is that the industry should look at other AI techniques besides neural nets (NN) or find compliments to NN's. Genetic algorithms and Factor Tables should also be explored as well. Just because recent advances have been in NN's does not necessarily mean that's where the future should lead. Factor tables may allow more "dissection" & analysis by those without advanced degrees, for example. Experts may set up the framework and outline, but others can study and tune specifics. ([https://github.com/RowColz/AI](https://github.com/RowColz/AI))

</comment><comment><USER21> This video is great ! for me, not for the math though.. two things:

* multi-layer, automated "jiggering" with so many components that only a machine can contextualize them, might be great for finding patterns in some sets, but the industry HYPE, the DIRECTION+VELOCITY, and the human manipulation (including lies and pathologies) are gut-level PROBLEM.. and this guy says that! +100

* Alchemy itself rambles and spreads [1] Some variations of Alchemy included a ritualized, internal psychological and psychic experience by the human practitioner.. hard to stabilize, yet not always a bad thing, since you are reading this and are actually one of those ..

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

lastly, the selected slides encourage a student-minded viewer to look up some math and think a bit. Not a bad thing. Thanks for this video and thanks for the talk.

</comment><comment><USER22> The way I understand neural networks to work, they are actually series of connected infinitely valued logic gates, where given a numerical input from neg infinity to positive infinity, it spits out another number from neg infinity to positive infinity that feeds into the next set of logic gates, and at the end gives you a confidence interval from 0 to 1 of whether there was a pattern match or not.

To me it's very similar to Boolean logic circuits the way I was taught those in college except that there's too many gates to configure manually so you use supervised learning to find reasonable values and an arrangement of gates that works (aka your trained neural network).

I've never heard anyone else describe it this way but this is how I like to think about it. It really has nothing to do with how the human brain or much less human mind works. That's just marketing speak.

<comment><USER19> > That's just marketing speak.

Pretty sure it was the initial thinking when Neural Network was created and it have move beyond that. I think people who know surface level only repeating this tadbit that's out of dated.

It's even in the official wikipedia article ([https://en.wikipedia.org/wiki/Artificial_neural_network](https://en.wikipedia.org/wiki/Artificial_neural_network)).

Everything you've stated was basically a personal opinion that could have been verified via google...

</comment></comment><comment><USER23> We do understand how it works most of the time, but can't predict if certain changes will be beneficial or detrimental. After the fact it's pretty clear what e.g. CNNs do (find manifold transforms which, coupled with nonlinearities minimize error in the layer-wise output distributions when backpropagating loss of the minibatches of the training set). But you can't reliably say "if I add e.g. a bottleneck branch over here my accuracy will go up/down X%".

Fundamentally we have to contend with the fact that human ability to understand complex systems is fairly limited, and at some point it will become an impediment to further progress. Arguably in a number of fields we're past that point already.

<comment><USER24> That's all very cool.

But for safety critical systems you have to understand how these systems work to understand their limitations. You have to know when these techniques succeed, when they fail, and how badly they fail.

<comment><USER23> Do you feel like you understand human limitations in these critical systems? Are humans suitable? Would AI be suitable if it performs statistically better than humans?

<comment><USER24> > Would AI be suitable if it performs statistically better than humans?

In general yes, but it might depend on the pattern of failure - if your self- driving cars hunts me or my family personally, I might have problem with that.

But how can you determine that without releasing it to the wild and waiting for bodies? Worse, say you have a safe system, but you need to modify the network (to fix some bug). How can you determine that the new system is safe enough to put on the road?

<comment><USER23> But any technology can be deadly if you deploy it widely enough. _WhatsApp_ has resulted in "bodies" and it doesn't have any AI in it at all. First airplanes were basically flying coffins. Cars until early 90s had very little chance of survival in collision above 40mph. Many drugs have serious, sometimes deadly side effects. Quarter of a million people die in hospitals in US alone every year due to medical errors. 100% of those errors are currently made by humans.

It's remarkable that AI seems to be held to an arbitrarily high standard, often exceeding that of other technologies.

<comment><USER25> My guess is that most people feel AI should be held to a higher standard is because we feel the need to be able to audit the system in the case of mishaps. When ML becomes a high-level black box, we may not have the confidence in how to right that ship if it goes astray. With human errors, if we're (hopefully) empathetic creatures we at least have the hope of understanding the root of the error.

<comment><USER6> The good news is that these tools exist but they're called statistics.

<comment><USER25> Statistics applied to black-box component mishaps have a couple things going against them. 1) you need a relatively large number of failures to build a good sample of data and 2) even if you have the probabilities in place to quantify risk, you may never understand the root cause of the failure to fix or mitigate it.

For a large expensive system, the presence of either of the above may be unacceptable. Take something like the space shuttle program. If it was heavily reliant on black box AI, you might be able to build probabilities through tools like monte carlo simulations but you would be hard pressed for the government to put billions of dollars at risk without understanding the root cause of simulation failures

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> In my mind, machine learning is simply one class of algorithm primarily oriented towards multidimensional fuzzy pattern matching. This technique can easily be classed as a subset of digital signal processing concerns. Everything tacked onto the sides of this (LTSMs, etc.) in some attempt to increase the cleverness or scope of the ML network (aka self-driving cars and other assorted high magickery), seek to band-aid something that is fundamentally flawed for these purposes.

A ML network does not have intrinsic, real-time mutability in how it is defined, outside the scope of memory-based node weights, inputs, outputs or graphs over time. These nodes are added, removed or modified based on a predefined set of input, output and internal mappings. How would intermediate layers be defined in a dynamic way between input and output in such a network in an attempt to achieve these higher powers? Driving a car, for instance, is a task that requires learning entire new subsets of skills, many times ad-hoc, that require intermediate models to be dynamically developed which are potentially outside the capabilities of our understanding. The biggest challenge I see today is that we don't necessarily have a good way to dynamically construct models of the intermediate layers (such that we can map them to other layers), especially if these layers are being added and removed dynamically by algorithms at the edge of our capability to understand.

I've always felt that there needs to be some internal processing occurring at rates far higher than the input sample rates such that higher-order intelligence may emerge by way of adjusting the entities noted above multiple times per input sample (and potentially even in the absence of input). The problem is also going to come down to how a person would define outcomes vs how an AI/ML network would. For the future to really begin we will need an AI that can understand and reason with what success and failure _feel_ like in our abstract terms. This will require it to have the capacity to dynamically construct abstractions which we would have no hope of modelling ourselves, as we do not have very deep insight into the abstractions upon which the biological human brain implements virtually any behavior today. There is no amount of discrete math in the universe which can accurately model and assess the higher-order outcomes of decisions made in our reality. You can run ML disguised as AI in simulations and environments with fixed complexity all day, but once you throw one of these "trained" networks out into the real world without any constraints, you are probably going to see very unsatisfactory outcomes.

</comment><comment><USER27> Additional context from Ali Rahimi and Ben Recht: [http://www.argmin.net/2017/12/11/alchemy- addendum/](http://www.argmin.net/2017/12/11/alchemy-addendum/)

<comment><USER21> .. and a Jupyter Notebook [https://github.com/benjamin-recht/shallow-linear- net/blob/ma...](https://github.com/benjamin-recht/shallow-linear- net/blob/master/TwoLayerLinearNets.ipynb)

</comment></comment><comment><USER28> If someone turns in math homework consisting in answers only, the teacher will probably not give any credit, and will ask to show the work. Yet the AI/ML community insists on cargo cult test for intelligence - behaving like someone with a mind.

That can be traced to the "Turing test". It was flawed then, and it is flawed now. Reproducing the behaviour of a thinking agent does not prove that a putative AI will not fail in a more detailed test, as demonstrated in numerous papers about "adversarial images".

</comment><comment><USER29> Related: Debate at NIPS 2017 on "Interpretability is necessary for machine learning", by senior researchers in Machine Learning including Yann LeCun.

[https://youtu.be/93Xv8vJ2acI](https://youtu.be/93Xv8vJ2acI)</comment>


Stock Futures Were Halted Sunday Night After 5% Drop - <AUTHOR> https://www.nasdaq.com/articles/stock-futures-were-halted-sunday-night.-heres-when-sp-500-circuit-breakers-would-kick-in <comment><USER2> This happens against a backdrop of unprecedented manipulation of the financial markets since 2008. The signs are everywhere:

\- persistent negative-yielding long-term sovereign debt in Europe

\- Bank of Japan owns 80% of the Japanese ETF market

\- a Federal Reserve unable to contain the exploding repo market

\- price-to-earnings multiple at historic highs, even accounting for declines

\- stock buybacks galore field by ultra-accommodative central bank policies

\- all eyes on the Fed to see what kind of shock-and-awe they can deliver

\- a US administration doing everything in its power to undermine the independence of the Fed and bring on negative interest rates

The GFC never ended. It was never resolved. It was simply rolled over, like opening a second credit card account to paper over a hole in a personal budget.

Panic is a strong word. Market panics are very rare. Nevertheless, it would not be surprising to see a full-blown stock market panic this week.

</comment><comment><USER3> I think this is all very overblown, and think within 5 years most people (obviously not those directly effected) won't even remember this happening. Similar to the Swine flu of 2009. Global growth will have a 1-2Q hiccup and then we'll likely have a rubber band recovery. But markets are in panic mode, and a lot of governments are showing their ineptitude, which is causing even more panic.

<comment><USER4> Consider that career expert epidemiologists are predicting billions infected and millions if not tens of millions of deaths worldwide, unless something dramatically changes to deflect the current course or some of their assumptions turn out to be substantially wrong. That's more infected and 1–2 orders of magnitude more deaths than the 2009 swine flu.

<comment><USER5> But who is dying matters when looking at economic impact.

Median age of death in China is 75. Median age is 81 in Italy. This is around the expected life span of these countries.

Obviously a human life cut short is always worth mourning, but from an economic perspective, dying pensioners could actually be a stimulus.

<comment><USER6> At the risk of sounding worse, the younger folks who inherit that bequeathed wealth might actually spend it, rather than tying it up in markets. Putting the money to work in the "real economy".

<comment><USER7> Money tied up in markets _is_ spent in the real economy, that's why it's tied up to begin with. It's gone to buy things like labour and assets.

</comment></comment></comment></comment></comment><comment><USER8> I don't play the stock market (I invest monthly and hold), but doesn't all this kind of make you want to buy? Eventually everyone will get Coronavirus and 0.2% of us will be dead. Then it will be back to making things again.

<comment><USER9> A certain CNBC correspondent suggested as much:

> But maybe we'd be just better off if we gave it to everybody, and then in a > month it would be over because the mortality rate of this probably isn't > going to be any different if we did it that way than the long-term picture, > but the difference is we're wreaking havoc on global and domestic economies

[https://www.marketwatch.com/story/cnbcs-rick-santelli- sugges...](https://www.marketwatch.com/story/cnbcs-rick-santelli-suggests- giving-everyone-coronavirus-to-spare-the-economy-2020-03-05)

<comment><USER10> This is absolutely false and yet another reason why journalists shouldn't play epidemiology.

Mitigating the rate of spread leads to less deaths overall. If everyone got it at the same time, there wouldn't be enough healthcare system capacity to handle it. This isn't a new concept, it's well-known within epidemiology. Cities with early interventions in the 1918 flu epidemic had 50% lower peak death rates. If everyone got it at once, many more people would die than if the same number of people got it over a longer period of time.

The following is my speculation, but if we woke up tomorrow and _everyone_ suddenly had the coronavirus, then the economy would be in much bigger trouble than it would be with a slower rate of infection.

</comment></comment></comment><comment><USER11> The entire world has collectively decided that recessions are unacceptable, so all central banks will print as much money as necessary to ensure no pain is ever experienced by anyone except prudent savers. Watch the printing presses get ramped up, I assume everyone in the USA will be getting a few thousand bucks in the mail soon.

<comment><USER5> If we can avoid recessions, we should.

If we can create wealth without inflation, we should.

<comment><USER12> If you're not sure if you can, probably you can't. At this point nothing indicates that we've learned how to reliably avoid recessions. Quantitative easing and negative rates don't look like the Holy Grail, quite the opposite.

</comment></comment></comment><comment><USER13> My hot take is that the virus isn't affecting future cash flows enough to warrant a crash, but as is typical, it sure as heck is a big enough catalyst for "risk off" to take hold and most pent-up mispricings to finally normalize, which according to some would be a huge pullback or crash.

<comment><USER14> Your hot take is wrong. Cash flows are absolutely going to be impacted here. Initially, the thought was that this was only going to be a supply-side shock, but people are planning to completely hunker down, not booking flights, not traveling to work, taking time off.

This is going to be a large, if transitory, problem. Buy a little bit of the dip every day, and get ready to eat some losses in Q2. Summer is coming.

<comment><USER13> I misphrased that - I meant to say in the long term. I agree that we will see a quarter or two of eps impact due to virus. But for a true crash the market needs to price in a longer term impact due to the virus - which seems unlikely on its own. However we certainly can see a crash due to sentiment and valuation changes prompted by this as a catalyst.

<comment><USER14> This has introduced credit risk to impacted businesses as well. Credit risk means we could see less liquid debt markets which could decrease employment, investment, and long run GDP growth. All of this especially concerning given that the fed has only 1 - 2 more pulls at monetary supply via interest rates before they have to introduce more QE.

There are too many connections here to simply discount the long-run risk to the economy which is why you're seeing a sell off.

PwC's audit lead gave a great interview on Bloomberg the other day that I thought summed this situation up well. Paraphrased: Those that have been fixing their roof while the sun is shining are going to be just fine, but a lot of businesses didn't do that.

Businesses with high leverage, unsteady cash flows, flaky customers, and inefficient cost structures could be in trouble here.

I'm a buyer in this market, but I'm a buyer precisely because I have a long horizon. There's no guarantee that we get back up to these rich valuations any time soon.

</comment></comment></comment></comment><comment><USER15> Time in the market not timing the market.

\- here for future reference

<comment><USER16> I have been holding S&P puts as a hedge since the S&P was at 3330, and my portfolio value is at the same level as it was near early Feb highs because of them even though my stock holdings are down.

The idea that you should just sit back and be ok with a 20% haircut isn't something that I will just "take" if I can help it.

<comment><USER5> Congrats on winning the lottery.

Long term yours is a losing strategy.

<comment><USER17> Insurance through options is not a losing strategy. They are designed for hedging, and some basic attention to trends (all-time highs and coronavirus) can provide nice gains or protection from losses.

<comment><USER18> What you are referring to is "timing the market", which is a strategy I suppose. Just not one a lot of investors consider valid.

<comment><USER17> Yea, because people interpret it as extremes.

Anytime _in the last quarter_ with constant news about all time highs, record low interest rates, overbought stocks with extreme ratios, and a global pandemic affecting supply chains was enough to try and allocate _some_ attention towards a downturn with cheap bets or portfolio protection. 1-5% on puts is well within standard risk management.

You don't need to be a daytrader or prophet for any of this. If you missed the drop and positions have lost value then sell covered calls for income. Then wait it out because we have an entire summer of disrupted global trade coming. Don't think about buying in until that's over.

</comment></comment></comment></comment></comment></comment><comment> the-dude Nikkei down 6% at the moment.

</comment><comment><USER19> I can't see why this wouldn't be the biggest crash for 50 years.

All the other ones were largely human caused and largely controlled by sentiment, and did not cause everyone around the world to avoid contact with everyone else.

This will last until a vaccine is developed which might take 12-18 months and in the meantime many many businesses will die around the world.

The domino effects will be huge. Remember that lots of people and companies are up to their eyeballs in debt, what if that starts to run out of control with bad debt everywhere cause businesses and people are bankrupt?

This is very long term and very damaging to all economies and there's not really much governments can do to change people's behaviour.

This one is caused by sentiment, but that sentiment is driven by a virus which is out of human control. Unlike for example a war, which can be controlled by politicians.

Thar's a big one blowin in, batten down the hatches.

<comment><USER20> Forecasts are for testing a vaccine in six weeks, rollout in 3-4 months.

But billions of people will suffer before this blows over.

<comment><USER21> Source on vaccine timing? My understanding is anyone who claims a viable vaccine is trying to pump their favorite pharma.

<comment><USER20> Heard it on NPR, I think.

</comment></comment></comment></comment><comment><USER22> So late last year after about 3 attempted rallies, around one of those local peaks I decided enough is enough and I basically liquidated everything so now I'm 100% cash. This was all before the coronavirus. My rationale for this was simply that we were in the longest bull market in modern history, we were likely closer to the top than the bottom and because of certain FIRE tendencies [1] I decided my time horizon had shrunk to less than 5 years, at which point I decided it was more prudent to get out of equities.

For the last several years I wondered what triggered the eventual correction. By "correction" I mean there'll eventually be a reversion to mean that will, for a time, cause the market to be oversold. Traditionally this is a good time to buy but it can be hard to get anywhere near the local bottom (this is where the term "dead cat bounce" originates).

I didn't think it would be anything like 2000. We have some tech giants around $1T market caps now but they are money generating machines the likes of which probably hasn't been seen since the era of Standard Oil and the rail barons (whereas 2000 was purely speculative). It didn't seem like real estate would be the trigger either.

I thought it might be the possibility of a trade war with China but, on further inspection, it seems China may well be more vulnerable to that than the US. Still, China has a way of thinking long term that's simply nonexistent in US politics.

Certainly when I heard about this new virus, I didn't think it would be it. AFter all, we'd had SARS. But SARS was in some ways too effective and it basically burned out really quickly so never threatened a pandemic.

But this? The problem here isn't the disease. After all, for most people, it'll likely just be a bad flu. The problem is the changing behaviour it will cause because there seems to be such a long period of being contagious while asymptomatic while being highly contagious.

Some airlines are down 40%+ this year. Some cruise lines are even worse off than that. With travel being impacted, so are hotels, restaurants, tourism, etc. Any large public gatherings are likely to be curtailed (either officially or just effectively as people stay away).

As soon as I saw there were cases in California where the source couldn't be identified I thought "well that's game over for containment". The same with the Italian cases.

Oil prices have plummeted due to lower demand so all oil-dependent economies are now at risk of recession. The Fed's attempt last week to jump start the economy with a surprise 0.5% rate cut basically did nothing and there's only so low rates can go.

So best case I think we're in for a bad 6 months, maybe as much as 18-24 months.

Personally I'm disappointed I didn't end up shorting the market in the last week, I honestly don't really know why I didn't. But it could be worse.

It'll be interesting to see how the anti-vaxxers spin this as it unfolds.

What I do know is that it's way too early to go bargain hunting on the stockmarket.

[1]: [https://www.daveramsey.com/blog/what-is-the-fire- movement](https://www.daveramsey.com/blog/what-is-the-fire-movement)

<comment><USER21> I agree with all of this, though I am also looking forward to understanding why I'm wrong.

</comment></comment><comment><USER23> There needs to be a discussion about how China is going to compensate the world for covid19. Given the thousands of lives lost and billions of lives disrupted, it seems unfair and unwise to let the source of the loss escape shouldering the cost.

<comment><USER24> That's a real stones in glasshouses argument.

</comment></comment><comment><USER25> All 4 of the major US index futures are at limit down: /ES, /NQ, /RTY, /YM (S&P 500, Nasdaq 100, Russell 2000, Dow 30)</comment>


Experience: I learned to play the piano without a piano - <AUTHOR> https://www.theguardian.com/lifeandstyle/2019/nov/22/experience-i-learned-to-play-piano-without-a-piano <comment><USER2> I'm guessing he had the advantage of his young brain that he could train to make sounds from a paper piano. I wonder if this would be as easy for an adult.

<comment><USER3> I think it is a remarkable achievement regardless of young or old. I think it would be difficult for both adult and children, but achievable by both, just very tedious.

</comment></comment><comment><USER4> [https://youtu.be/34jTT-G6m7I](https://youtu.be/34jTT-G6m7I)</comment>


Europe's Largest IT Company To Ban Internal Email - <AUTHOR> http://slashdot.org/story/11/11/29/0232205/europes-largest-it-company-to-ban-internal-email?utm_source=slashdot&utm_medium=twitter <comment><USER2> On a similar note, many years ago I worked for the research labs of a European telco. The head of the lab decreed that we should strive to go paperless and bragged that he had achieved this himself in his own office. Indeed he had, his secretary however, couldn't move for filing cabinets.

There was also a harsh quota on email storage to prevent people hoarding 'old, useless' emails. This, inevitably, increased the amount of stuff printed out 'just in case'.

Shortly before leaving I opined loudly in a meeting where this was raised that the paperless office made as much sense as the paperless toilet. Didn't solve anything but was enjoyable in a naughty boy sense.

</comment><comment><USER3> They cite that their employees get 200+ emails a day. Yet they want them to revert to a chat based system.

They'll still get the same amount of communication but be expected to give an immediate response.

How long will it be before people just mark themselves as "Away" and treat their IM's as a new mailbox.

</comment><comment><USER4> The worse use of email: having automated build and test systems email every little status change and hiccup. I would much rather have a web app with a concise status/warning, etc. display. On the other hand, I like to work uninterrupted so I often turn off email clients, Skype, and my cellphone anyway.

</comment><comment><USER5> I'm an old fart, but I don't get why so many people don't see the advantages of asynchronous communication.

</comment><comment><USER6> Reminds me of the moronic edicts I used to have to deal with.</comment>


Seven IPv6 networking myths that don't match reality - <AUTHOR> http://searchtelecom.techtarget.com/tip/0,289483,sid103_gci1420201,00.html?track=sy781&utm_source=twitterfeed&utm_medium=twitter&utm_campaign=Feed:%20781%20(SearchTelecom.com:%20Telecom%20news%20and%20technical%20information)&utm_content=Twitter&ShortReg=1&mboxConv=searchTelecom_RegActivate_Submit&

<comment><USER2> Myth #7: He claims that residential IPv6 routers and the computers behind them are almost impossible to find because there are so many available addresses and therefore, random portscans are ineffective.

There are, however, enough other ways of obtaining random inhabited IP addresses. P2P networks, for example.

<comment><USER3> True; at the same time, though, implementing a simple firewall on a router with equivalent security to NAT is actually simpler than implementing NAT itself: block incoming connection initiation packets by default, e.g. SYN packets in TCP, UDP packets whose destination & source IP & port don't match recent previous packets. (and just drop unknown transport layer protocols) That logic is identical to NAT, except the packets just need to be accepted or dropped, never rewritten.

<comment><USER4> Still NAT is useful for creating "virtual machines", where more than one machine maps to the same IP address. Sure, the DNS can be used to do this at a higher level. But NAT does it much more dynamically.

<comment><USER5> Are you describing a load balancer, or something else? If not a load balancer (which has a different job to do), I just read this as "NAT is useful because it does NAT".

<comment><USER4> So, yes, a load balancer. Thus the term "virtual machine" - meaning several machines provide a single service, spread over clients, time or whatever.

</comment></comment></comment></comment></comment><comment><USER4> Stanford has the Clean Slate program to address the broken IP stack.. Still in its infancy. cleanslate.stanford.edu

</comment><comment><USER6> Didn't even bother reading because I couldn't get to the content. An iterstitial ad decided to take over and there was no way to remove it on the iPhone. Enjoy the half-penny or so you made from that, website marketing guru.

<comment><USER7> It's not just the iPhone; the same thing happened in Safari 4 on the Mac. Once I got rid of it, there was an annoying 'sign up to see more than the first paragraph' which I gave up on.</comment></comment>


New co-living space for startups on Rhodes Island - <AUTHOR> http://work-and-relax.com

<comment><USER2> I would love to find someone willing to actually split a place for a month + time. I'd even be willing to do a suite!</comment>


Why We Start Indexing from 0 in Computer Science - <AUTHOR> http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

<comment><USER2> I suspect the real reason has more to do with the pragmatics of machine code.

It's extremely common to want to refer to some dynamic offset of a fixed location in memory, like if you have an array of equal-length items stored consecutively. If you have two literal addresses called Start and Index, you'd like to be able to say something like "Start[Index]" and have it mean "Read from Index, and whatever number is there, move that many spaces forward from Start, and give me that". It's handy that if Index is a cleared region of memory, you can say "Start[Index]" and have it mean the same thing as just "Start". More importantly, if "Start[Index]" only meant "Start" when Index was 1, that would imply that if Index were 0 that Start[Index] would refer to the spot right _before_ Start, which is not only useless but outright dangerous.

<comment><USER3> Right, it makes sense when dealing with machine code and when making the compiler do extra work for you (converting one-based to zero-based indexing) would be too much work for the compiler implementer or is too slow (like on machines back in the 70s and 80s) or it would abstract too far from what is happening underneath the hood, possibly leading to errors.

But like many features of programming languages and operating systems (case- sensitivity, global menu bar, python's colon...), zero-based indexing is something that made perfect sense in the context and time in which it was _originally_ designed and implemented, but it's really no longer necessary in most cases today, and only survives because of tradition and blind cargo cult- like copying of what others did before.

<comment><USER2> You're _vastly_ oversimplifying. In physics and finance, the "initial time" has always been t_0, not t_1. This has absolutely nothing to do with machine code, or with "blind cargo-cult copying". There are intrinsic reasons for doing it this way, which I'll leave for you to ponder yourself, ideally in a quiet room in a lotus position.

Traditions are not always arbitrary. Don't dismiss them until you're damned sure why they've survived, especially when you know for a fact that quantitative fields filled with high-order geniuses haven't bothered to scrap them. "Cargo-cult" thinking is a pernicious influence, but it's exceptionally rare that it's the complete explanation of anything.

<comment><USER3> I'm addressing the topic of the post: the use of indexes in programming, not names used for variables that store an initial time.

myarray[2] doesn't mean 'myarray at time 2'

<comment><USER4> One advantage I think the parent is alluding to, is that zero-based indexing makes it a bit easier and more natural to generalise between continuous (functions on R) and discontinuous (functions on N) situations.

Since the latter are often used to approximate the former, this is quite handy.

</comment></comment></comment></comment></comment><comment><USER5> Can't resist this classic quote by Stan Kelly-Bootle: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration."

</comment><comment><USER6> A helpful way to think about this, especially when working in languages that have an array slice syntax, is that arrays are like rulers for measurement.

Like a ruler, the array has markers (ticks) going from 0 to N, and the array elements are stored _between_ ticks. So the index numbers simply refer to points, while the array elements have a "one-dimensional" extent.

With that mental model, starting at 0 falls into place very naturally.

</comment><comment><USER7> "an element's ordinal (subscript) equals the number of elements preceding it in the sequence."

That is going to make the "the 2nd item is number 1" thing SO much easier to explain when teaching. Thanks! (And it's good to have the rest of the reasoning there to answer the particularly curious students...)

Definitely falls into the "wish I'd thought of that" and "wish I'd heard someone say it that way 5 years ago" camps.

</comment><comment><USER8> I'll repeat my comment from a different thread:

"I've never really agreed that numbering should start at zero (or at one), I think people use indices way too much and it gets in the way of clarity. I much prefer whole array or list operations with no fiddling with indices and off by one errors. I like Haskell's array API, for example. You can index by whatever is natural in each case and you can always get the whole list of valid indices for an array x by using "indices x". I think that's much nicer, and it's also what D is doing: instead of having a(n implicitly paired) starting and ending iterator to indicate a range of positions like the C++ library does, D's library uses a range object. Basically I'm saying you can represent a range of indices as a pair of indices, one pointing to the first valid position and the other pointing past the last valid one, but that's an implementation detail you don't need to expose, make a range abstraction and you'll be happier."

"I should also point out that mathematicians don't number at zero unless there is some advantage (the default is to start at one), but more importantly, the preferred style in mathematical arguments is to avoiding fiddling with indices as much as possible (since it's so easy to mess something up working at such a low level of abstraction)."

<comment><USER4> > I should also point out that mathematicians don't number at zero unless > there is some advantage (the default is to start at one)

I disagree. While this may depend a little on which areas of mathematics you study, I've found that in situations where there _is_ a reasonably clear / natural / non-arbtirary preference, it tends to be for zero-based natural numbers.

On the other hand, situations in which 1-based numbers are used, tend to look more like arbitrary aesthetic preferences. They tend to be situations where no particular `origin' is any better than any other, and one could (despite the ugliness) use 2- or 3-based numbering without adding any additional corner- cases.

My personal favourite `reason' that the set of natural numbers should include zero (and that numbering should start at zero) comes from set theory, where cardinal numbers are equivalence classes of sets of the same size. 0 is the smallest such number corresponding to the empty set. (For numbering sequences, 0 is also naturally the smallest ordinal number).

These kinds of reasons tend to crop up in category theory and other foundational topics too, which are some of the areas of mathematics closest to theoretical computer science.

Interested in counter-examples though; I'm sure at least some exist.

<comment><USER8> Well, whole numbers come up in mathematics in different ways. Of course if you're talking about cardinality you should include zero: it simply _is_ the cardinality of some set, you can't avoid that.

I was talking about a completely different use of numbers: numbering, that is assigning numbers as labels to things. There I think mathematicians on the whole prefer to number starting at 1 (or not to number at all and work with abstract indexing sets). Sometimes it is convenient to number starting at zero if it simplifies some formulas, but usually it doesn't matter.

<comment><USER9> To continue with your example, take cases where a (finite) collection of discrete objects is summed over (unioned over, whatever).

You'd let N be the number of such objects, and then twenty following pages of text would contain summations from 1 to N. This is more compact than summations from 0 to N-1. And in a certain sense, there's one less "token" to remember (i.e., if you start at 1, you have 1 and N to remember, but when you start at 0, you have N, 0, and N-1 to remember).

The one that's more compact tends to be discipline-specific.

</comment></comment></comment></comment><comment><USER10> The note is really about the best way to specify a range/sequence of integers, not why we start from 0 as an index.

But it is an excellent example of thoughtful reasoning to choose between multiple (seemingly arbitrary) design options. I think we all benefit when language (and API) designers are as thoughtful as this.

<comment><USER11> > The note is really about the best way to specify a range/sequence of > integers, not why we start from 0 as an index.

Dijkstra deals with what index start with as well, but it comes out as a consequence of which bounds to choose for a range, so it's rather short.

From the article:

 _When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N._

</comment></comment><comment><USER12> My main issue with the start-from-0 convention is that while it makes sense if you consider an array as a pointer with more pointers coming after it, it doesn't make as much sense when it is simply a list of objects.

When I have a five-page document, I number the pages as one, two, three, four, five, and say that the length of the document is five pages. If I have an "empty" document (assuming such a thing makes sense in the real world), it would have length zero, and since there are no elements to assign indices to, I would not assign them numbers.

I have to admit that I much prefer the Lua convention: in a sequence of N items, they are numbered 1, 2...N-1, N. The length of the sequence is equal to the index of the last item in the sequence. "Negative" indices are treated as if one was counting backwards from the end of the sequence, such that the items are numbered -N, (-N)+1, (-N)+2...-2, -1, i.e. the spoken forms "last," "second-to-last," "third-to-last..." This means that 1 to -1 encompasses the whole sequence. This does have the unfortunate side effect that 0 refers to no item, but even when describing an array implemented as a pointer we refer not to the "zeroth" element, but to the first and the last.

This also has an added benefit that the range notation used by Lua's numeric for loops makes perfect sense when compared to the notation used by Python's range statement. In Lua,

        for n = 1, #tbl

produces all of the indices in the given table, as does

        for n in range(len(ls))

in Python, for a list. In Lua, this can simply produce the numbers 1, 2, 3, 4, 5, 6 for a table of six elements, which is intuitive even when using the numeric for to simply generate a series of integers:

       for n = 1, 6

However, in Python, the fact that range is used to generate the indices also means that range(1, 6) produces 1, 2, 3, 4, 5 ("Where the heck is the 6?") and a simple range(6) produces 0, 1, 2, 3, 4, 5 ("Still no 6, and where did that 0 come from?") To get 1, 2...6, you need range(7) ("What does this have to do with 7?")

<comment><USER13> So... you prefer Lua because half-open ranges confuse you?

<comment><USER14> If we're going for half-open ranges, range(n) ≝ 0<i≤n would make more sense than 0≤i<n. But then again, sign(0) is still a point of disagreement today.

Dijkstra argued against this by noting that that makes adding 0 to the range impractical, but then he was considering natural numbers, not the half-open ranges we're talking about and using notation for here.

Me, I prefer integers and the a..b style, despite the off-by-one error.

</comment></comment></comment><comment><USER15> Easier to read: [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html)

<comment><USER16> Although this is indeed much easier to read, the handwriting in the original is beautiful. Love the 'f'.

<comment><USER17> You are not the only person to think so, it has been turned into a font multiple times (for example, here: [http://www.fonts101.com/fonts/view/Uncategorized/34398/Dijks...](http://www.fonts101.com/fonts/view/Uncategorized/34398/Dijkstra.aspx)).

</comment></comment></comment><comment><USER18> Just to pile on: 0-based indexing is also more convenient when you want to build a multi-dimensional array from a one-dimensional array primitive using the integer division and modulo operators to map between 1D and nD indices. E.g., a matrix with M rows and N columns can be mapped to the range 0 <= i < (NxM) by letting i = (row * N) + col, and the backward mapping is row = i / N, col = i % N.

If instead you use 1 <= i <= (NxM), 1 <= row <= M, 1 <= col <= N, then the mappings aren't nearly as clean. Sure, you could hide all this behind some kind of API, eg. Image.getPixel(x,y), but if you work with multidimensional arrays very often, eventually you'll need to marshal arrays back and forth between different containers that use different access APIs, and the simplest common representation to use for this kind of data is as a 1D array, so being able to work with nD data that is stored in a 1D array comes up fairly often.

</comment><comment><USER19> We index from zero because it requires the least translation to machine code. One idea in this note, however, is pernicious: 2 <= i < n. In the for statement - for (int i = 0; i < n; i++) a[i] = i - i must take on a value that is not in the range of indices of the array, 0..n-1, to terminate the loop. This doesn't help reasoning about the loop. The problem is worse when pointer arithmetic is involved - e.g. for (p = start; p < end; p++) *p = 0 - as the final value of p may not even be a valid address. We would be better off with closed intervals and index types that restrict the range of values to those intervals.

</comment><comment><USER20> Matlab, which is commonly used for numerical computing, uses one-based indexes. Just one of the little gotchas when switching between Matlab and "real" programming languages.

In mathematics and physics the usage varies. Zero is used when it is really the beginning of something, like t0 for the start time of an experiment. In most other cases lists count from one and up. Matrix elements too are generally denoted from (1,1) to (n,m).

<comment><USER13> > Except deadlocks have nothing to do with sharing memory, and everything to > do with sharing state.

Other languages using 1-indexed arrays: Fortran, Cobol, Smalltalk, XPath, Erlang[0] and Lua (and a bunch of other very old languages like PL/1 or Algol).

All Wirthian languages (Pascal, Oberon, Ada, etc...) use configured index ranges (and provide primitives to query the array for its bounds), but I believe the convention is to use 1-index arrays when there are no special index semantics due to their strings being 1-indexed.

VB has configurable index ranges as well, but defaults to 0-indexed arrays.

You can also "configure" initial array index in Perl by setting `$[` I believe. Doing this will lead to you being beaten to death with ethernet cables by your colleagues. And if it does not, it should.

[0] though direct indexation is rarely used in erlang

</comment></comment><comment><USER21> Lua, the oh so nice "rebel" among languages, uses 1 as the first element in its indices :)

<comment><USER22> Nasty. But it's the same for substring text offsets, array indices etc in Postgres.

<comment><USER23> Nasty? In a language without pointers it makes total sense. An index is no longer an offset from an array (or string) pointer, so the first element being 1, the second being 2, just makes more sense.

Sure, it's a departure from mainstream languages, but in my opinion it's a perfectly sensible one.

<comment><USER13> > Nasty? In a language without pointers it makes total sense. An index is no > longer an offset from an array (or string) pointer, so the first element > being 1, the second being 2, just makes more sense.

Not necessarily. The reasoning in e.g. Python is that the index is not to an element, it's to one of the intervals around an element. The "first interval" (right before the first element) is 0, which naturally leads to -1 being right before the last element, thus arr[-1] being an array's last element, and arr[:-1] being everything _but_ the last element.

</comment></comment></comment></comment><comment><USER24> Seems pretty well reasoned to me.

</comment><comment><USER25> 2..13 2:13 2->13

Again we fall in the trap of endless discussions about bitheads, numheads and charheads.

The bithead will always think in zeros and ones, he is a hardcore c or c++ programmer, and his brain is damaged beyond repair. Avoid all discussions with that kind of specimen.

The numhead accepts both conventions, he is a python or ruby programmer, practical and gets the job done, he may ask why that weird convention but still goes on using it since it solves all his problems as it is.

The charhead is a vb or js programmer by luck, not by choice, he will never understand why we start from zero and will curse everytime he writes a for loop.

I've been in the three camps luckily escaping without any brain damage (I believe) and after 20 years programming I still prefer to count starting by one, like any human being.

<comment><USER26> > I've been in the three camps luckily escaping without any

I'm not convinced that people count starting at one.

Count the number of elephants in your bedroom. Assuming that there weren't any, how can you say that you started counting at 1 when the result of said counting was 0?

<comment><USER23> But do I call the first elephant I get into my room elephant 0 or elephant 1?</comment></comment></comment>


Ask HN: Which books are the best to learn Python Django? - <AUTHOR> I am learning Django framework. What are the books, tutorial or videos to learn Django? <comment><USER2> Also, check out-

\- Official Django Tutorial: [https://docs.djangoproject.com/en/1.10/intro/tutorial01/](https://docs.djangoproject.com/en/1.10/intro/tutorial01/)

\- Tango with Django: [http://www.tangowithdjango.com/](http://www.tangowithdjango.com/)

\- Real Python: [https://realpython.com](https://realpython.com) (note: I am the co-founder/author)

<comment><USER3> Tango with Django is the best.

</comment></comment><comment><USER4> For beginners, I recommend either "Hello, Web App"[0], or "Two Scoops of Django"[1].

[0] [https://hellowebapp.com/](https://hellowebapp.com/)

[1] [https://www.twoscoopspress.com/products/two-scoops-of- django...](https://www.twoscoopspress.com/products/two-scoops-of-django-1-8)</comment>


Facebook Says Its New Data Center Will Run Entirely on Wind - <AUTHOR> http://www.wired.com/wiredenterprise/2013/11/facebook-iowa-wind/ <comment><USER2> When they say 'wind' do they mean all the hot air produced by all the people using it?</comment>


The Mystery of Zach, New Zealand's All-Too-miraculous Medical AI - <AUTHOR> https://thespinoff.co.nz/the-mystery-of-zach-new-zealands-all-too-miraculous-medical-ai/ <comment><USER2> It does sound a lot like an imposer story.

Actually, it reminds me of something we saw in the Netherlands not too long ago. On television, a so-called cybersecurity expert was introduced as the "superwoman of cyber security". When she then started talking about how DDOS attacks on banks would be a prelude to ATMs spitting out money, it was quite hard to take her seriously.

That wasn't enough though. She closed off her interview with the remark that a 'smart blockchain' would soon be able to fix all of our security concerns.

As it turns out, the woman was unknown in the cybersecurity space in the Netherlands, with no digital footprint. She had recently written a book with a former member of parliament on the basics of cybersecurity. The online book sales were spammed by fake positive reviews and it turned out to be mostly plagiarised a little while later.

I suspect that there's a growing trend underneath the few cases such as this. Imposters will become more common as general awareness of such topics starts to grow, with its accompanying lack of depth.

I could only find a source in Dutch, as it was a local incident, but here it is: [https://saltmines.nl/2018/01/31/het-cyber-verhaal-van- rian-v...](https://saltmines.nl/2018/01/31/het-cyber-verhaal-van-rian-van- rijbroek-nieuwsuur-en-waarom-het-niet-klopt/)</comment>


Why we were the first Medium publication to move 100% to Members - <AUTHOR> https://betterhumans.coach.me/why-we-were-the-first-publication-to-move-to-100-medium-members-a324cd2ef27d <comment><USER2> Do the fixed banner/footer get removed in premium membership ?</comment>


Lightsaber + Kinect + robotic arm = JediBot - <AUTHOR> http://www.extremetech.com/extreme/90204-lightsaber-kinect-robotic-arm-jedibot

<comment><USER2> I was hoping this would have moved faster. Still kinda neat.

<comment><USER3> That's probably the limitation of the robot. I would wager that the same software with a different (faster) robot could move way faster, and that would probably look more like sword fighting (this does not to me ...)

<comment><USER4> It doesn't because it isn't ;-)

In real sword fights the defenders jobs is to deflect the attackers stroke (more or less). If you'd just try to stop it (physically reversing the attacker's impulse) that would either not work at all (because you don't have strong enough muscles) and the sword would still hit you. Or equally bad, the sword or your bones break due to mechanical overload.

Now according to the description the robot simply pulls back if it hits resistance, which results in the fake looking moves. Deflecting a stroke probably wouldn't work because of the robot's mechanical structure is much more rigid than a human's.

Slow-motion sword combat works/looks much better if the fighters are aware of how it actually works when not simulating the moves.

Amend: The "physically reversing the impulse" is a bit hand-wavy. You just have to put an equal momentum into your own sword directly opposing the momentum of you opponent's sword. Now if your attacker goes in for the long haul, he has about a meter of movement to put the momentum into his sword, whereas the defender usually has much less. This therefore requires much more force resulting in the above consequences.

</comment></comment></comment><comment><USER5> What language is that (shown around 1:52)?

<comment><USER6> Probably Kuka: [http://drstienecker.com/tech-332/11-the-kuka-robot- programmi...](http://drstienecker.com/tech-332/11-the-kuka-robot-programming- language/)

</comment></comment><comment><USER7> I'd love to build this. Does anyone know where I can get plans for a robot arm like the one they use ?

<comment><USER7> Seriously guys. Why is there no open source robotic arm? And/or how do I learn how to design one?</comment></comment>


Ask HN: What (if any) analytics provider do you use on your websites? - <AUTHOR> <comment><USER2> Not really a provider as it's self-hosted, but I use my own tool: [https://usertrack.net](https://usertrack.net)

</comment><comment><USER3> [https://usefathom.com/](https://usefathom.com/) (the hosted version 2, their version 1 is open source)</comment>


Ask HN: Developer Wiki? - <AUTHOR> What are some of the Wikis for Developers and dev teams ? I want to document our entire infrastructure/code for internal dev. team and not sure where to start. Other than Github and some generic PM tools, we don't have anything geared towards developers. I want to change that. <comment><USER2> My company is using Confluence, I was a bit skeptical at first, but it is quite easy to use, and there are interesting plugins like Gliphy to draw models, or sw architectures. And this is also usable by non technical people. But this is likely a costly solution for a small team.

For my personal note taking, I am using a free tier gitbook[0]. What I like is that, under the hood, it is "only" git managing markdown files and you can sync with a github account.

So even if gitbook stop working tomorrow, you still have your knowledge base in MD files, which is nice.

[0] [https://www.gitbook.com/](https://www.gitbook.com/)</comment>


Should we interrogate the 'Diversity in Tech' narrative? - <AUTHOR> http://www.breitbart.com/london/2015/04/04/thankyouellenpao-now-we-can-interrogate-the-diversity-in-tech-narrative/

<comment><USER2> I read this piece when @Nero posted it on Twitter recently. I generally find his content and that of Allum Bokhari to be pretty on point with regards to the current narrative being slung at the IT industry. The rest of Breitbart is disappointingly awful though, admittedly.

This article is spot on. The "diversity in tech" narrative is toxicity fueled by "journalists" sitting on the fringe of the industry looking for clicks to bait. There is not the supply of candidates to satiate the socialist race and gender quotas those pushing the narrative demand. In fact, they're almost mandating that people be hired simply because they belong to a certain race, or to a certain gender.

You're not allowed question or interrogate the narrative. In their own words - "Listen and Believe".</comment>


Ask HN: how do you know about China's Startup - <AUTHOR>

i want to know more about China's Startup,expecially mobile startup.
Thanks! <comment><USER2> Check this out.

<http://www.worldstartupreport.com/>

Only resource I know of that may be on track with what you are looking for. Good luck!

<comment><AUTHOR> thank you.i will get it</comment></comment>


Three bugs in the Go MySQL driver - <AUTHOR> https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/ <comment><USER2> While the second and third problems sound specific to Go's `database/sql` API, the first problem (server-closed connections) is an issue any MySQL client library (that implements connection pooling) has to deal with.

My .NET MySQL connector ([https://github.com/mysql- net/MySqlConnector](https://github.com/mysql-net/MySqlConnector)) "solves" it at the MySQL level by sending a PING packet, but as the post points out, this adds extra latency.

The TCP-based approach of performing a non-blocking read sounds like a much better approach; I'm glad the author shared this, and I want to see if that technique can also be implemented in MySqlConnector: [https://github.com/mysql- net/MySqlConnector/issues/821](https://github.com/mysql- net/MySqlConnector/issues/821).

<comment><USER3> The non-blocking read is a bad hack to an ill-defined problem.

For starters, if a read would fail, so would a write. Your write path has to handle errors anyhow, so the non-blocking read is a contrivance. I understand the reason for the contrivance--it's because the typical SQL driver API requires first dequeueing a connection from a pool, passing ownership to a caller, and the caller sending a query. The proper and better API is to combine the "dequeue connection" and "send query" steps, returning a handle back for the response, which may include (as an optimization) assigning the connection to the caller for any additional requests. Additionally, any hack that prevents the majority of write failures, but not all, leaves time bombs around by not stressing the write failure paths of the caller.

Secondly, IME a far more common reason in the wild for a connection disappearing is either a) the server crashing or b) NAT association timeout. In either case it's typical for the remote end to simply disappear, and unless TCP keepalive is enabled, a read won't return any error until you first attempt a write and wait for the TCP stack to figure out that the remote end is gone. In the best case that's a R/T, in the worst case some eager firewall rules in the middle or on the remote peer silently drop packets for unassociated connections and/or the ICMP response and you're stuck waiting for TCP timeout.

Thirdly, and related to #2, absent TCP keepalive or an application ping (not ICMP ping), connections are far more likely to get dropped on the floor while sitting in the pool. And an application ping is more reliable because some firewalls and application and NAT gateways drop or ignore TCP keepalive.

I've written client libraries with connection pooling for HTTP, MySQL, SMTP, RTSP and generic TCP. I learned all this the hard way.

<comment><USER4> The article says the non-blocking read resolved the problem they were having while only introducing five microseconds of latency per borrow from the connection pool.

For a consumer-facing, latency-sensitive application, that sounds like much easier-to-stomach hack than introducing a network round-trip at the start of every connection borrow.

<comment><USER5> It's funny you say it resolves the problem because if you read the bug report from the author opened since 2017 [https://github.com/go-sql- driver/mysql/issues/657](https://github.com/go-sql-driver/mysql/issues/657)

It's repeatedly pointed out by one maintainer that his server and application are misconfigured and should be fixed. Yet the author doesn't consider it and goes on a project to redo the connection pool (the library can certainly benefit from better error detection but he would be better off fixing the root cause of connections dropping).

Ergo the issue is not fixed. If you look at the chart provided, it's still erroring every few minutes, instead of every minute. It's an improvement but a far cry from zero. [https://user- images.githubusercontent.com/42793/57318792-6e3...](https://user- images.githubusercontent.com/42793/57318792-6e3b6800-70fb-11e9-87f7-f9d69e8a3c7b.png)

<comment><USER6> There's a fundamental unfixable race there: a connection can be picked from the pool while a FIN is already on its way to the client.

This is "caused" (as in, not mitigated) by the intersection of a naive protocol, as pretty much all SQL protocols are, and the nature of distributed programming.

<comment><USER5> You realize the database server was misconfigured to drop connections transparently after 30 seconds? If it were not for that, TCP race conditions are extremely rare.

</comment></comment></comment></comment></comment></comment><comment><USER7> Bug #3 (The race) was silently introduced by a _semantic change_ in Go's database/sql in January 2018: [https://github.com/golang/go/commit/651ddbdb5056ded455f47f9c...](https://github.com/golang/go/commit/651ddbdb5056ded455f47f9c494c67b389622a47)

It took until December of the same year until we got the first bug report and figured out what was going on. While the semantic change might look subtle, it was certainly not from our (driver maintainer's) perspective. We were quite disappointed that such a change was made 1) without informing the driver maintainers 2) making sure the changes were in place before this change made it into a Go release.

We regularly test against Go's master (now using a Travis CI cron job), but that only helps if the existing tests fail. We don't have the time to constantly monitor all changes in the Go repo.

If there is a need to make such changes (not just in database/sql and not just in Go), PLEASE actively communicate early with the community / the direct users.

<comment><USER8> A comment on the original issue[1] promises to "[open] some tickets for various drivers". Did this not happen?

1: [https://github.com/golang/go/issues/23519#issuecomment-36057...](https://github.com/golang/go/issues/23519#issuecomment-360572590)

<comment><USER7> I really appreciate the work that is done to improve the database/sql package. It is still rather young and not as mature as for example JDBC. I would rather thank the people who work on it for the work they do, than to point fingers for anything that is not done. The original design of database/sql was sometimes a bit too simplistic and will probably require some more ugly changes or workarounds in the future.

This specific change was a bit unfortunate. It tried to fix another bug caused by the introduction of Context cancellation support, but it unfortunately caused some other major bugs due to the changed semantics. Like the very same comment already indicates, other drivers also required changes. In retro- perspective I think it would have been better to try to handle the original issue entirely in database/sql, instead of changing the "contract" with the drivers.

Go MySQL Driver was, and I believe still is, developed mostly by some random programmers in their free time (I originally started it as a side-project during high school and until now was never paid for any work on it). It probably makes anyone who worked on it proud that now some major companies, not just GitHub, employ it. But like many such projects, it is not a perfect or finished product. If you use community-driven open source software at work, try to convince your management to set some work hours aside for actually contributing back to those, like GitHub did.

<comment><USER9> Go is still undergoing intensive R&D, especially in the runtime. Its releases are quietly tested against internal Google projects, but not formally tested with widely-used open source projects.

Any org that deploys Go apps should designate someone to watch the Go issue tracker, and subscribe to all issues that might affect them.

[https://github.com/golang/go/issues/](https://github.com/golang/go/issues/)

</comment></comment></comment></comment><comment><USER10> FYI: Go 1.15 will have idle timeout: [https://tip.golang.org/pkg/database/sql/#DB.SetConnMaxIdleTi...](https://tip.golang.org/pkg/database/sql/#DB.SetConnMaxIdleTime)

The driver interface also separates out the session resetter and the connection validator concepts. [https://tip.golang.org/pkg/database/sql/driver/](https://tip.golang.org/pkg/database/sql/driver/)

Please do have drivers implement the Connector.

</comment><comment><USER11> The work-around for the first issue might work well in practice, but due to asymmetry of tcp streams, is still open for a race where the server will idle- close a connection while a new (non-idempotent!) query is just in-flight.

The correcter solution would let the client manage the idle-timeout and disconnect once reached. Depending a bit on how controlled the client is, this might be a good or bad idea.

Note that this problem is very generalizable to http (1) upstream servers. If you need to support non-idempotent requests and want persistent connections to your upstream, it's not a good idea to have the upstream manage the idle timeout (and disconnect if reached).

In practice, I would have the client manage an idle-timeout of 30s, and server of 40s as an extra protection against misbehaving clients.

<comment><USER2> Some MySQL clients offer this; for example MySqlConnector has a `ConnectionIdleTimeout` setting that controls how long a connection can be alive in the pool: [https://mysqlconnector.net/connection- options/](https://mysqlconnector.net/connection-options/)

This is generally useful to "prune" the number of open connections in the connection pool after a burst of activity has happened, so I'm surprised more clients don't offer it; I couldn't find an equivalent setting on go-sql- driver/mysql or MySQL Connector/J.

</comment></comment><comment><USER5> >>> Keep in mind, we run our production MySQL clusters with a pretty aggressive idle timeout (30s)

Number one source of connectivity issue with MySQL. That setting alone is the source to every bug they encountered.

It's marvelous the amount of applications that have a low timeout and wonder why the (idle) connections are dropped all the time.

The timeout works fantastic when software prepare connection to the database, spend maybe 30 seconds initializing and doing other stuff, then send the query. The carefully prepared connection is guaranteed to be broken consistently. But the most impressive use case is with connection pools, whose purpose is to maintain idle connections, that gets butchered every 30 seconds.

MySQL should remove this fatal setting and enable TCP keepalive by default.

At least have mercy on the developers to set a sane default and cap the minimum value to 5 minutes.

<comment><USER12> It looks like they don't need the aggressive idle timeout anymore, now that they have ProxySQL for connection pooling:

> ... ProxySQL, which is responsible for connection pooling ...

[https://github.blog/2020-03-26-february-service- disruptions-...](https://github.blog/2020-03-26-february-service-disruptions- post-incident-analysis/)

More worryingly, it looks like they just rewrote the authz functionality from ruby to golang, and have both the monolith and the microservice accessing the same database?

</comment></comment><comment><USER13> Cancellation is always such a big issue regardless of language or environment, and whether it's due to a timeout or some other action.

In C, when using threads and thread cancellation there are a lot of subtleties involved: [https://ewontfix.com/2/](https://ewontfix.com/2/)

Even in Haskell where there's generally a focus on well designed abstractions, asynchronous cancellation can fail due to badly written code that wants to catch all exceptions.

</comment><comment><USER14> These bugs are not specific to MySQL. The bug around context closing the connection resulting in a txn not having an explicitly successful abort / rollback is a problem as well because conn.Close gets called in a goroutine when context expires.

We've experienced this in pq as well.

<comment><USER15> This as well, a recently fix for this scenario

[https://github.com/golang/go/issues/34775](https://github.com/golang/go/issues/34775)

</comment></comment><comment><USER16> Bug #1 doesn't seem solved. They just narrowed the window for the race condition.

I don't see how you can fix this without the client first calling db.Ping() if within some proximity to its estimation of the connection's expiration.

</comment><comment><USER17> > A quick Code Search for rows.Close() on GitHub shows that pretty much nobody > is explicitly checking the return value of rows.Close() in their Go code.

Seems to be a pattern in all languages. Plenty of C code ignoring the result of the close system calls, or Java code that just wraps exceptions from close calls in try/catch blocks that do nothing with the exception.

<comment><USER18> Well, what _should_ the code do there?

At that point, the status is uncertain, there's potentially a problem but IMHO there's nothing the code can do to reliably recover from it.

<comment><USER19> The code should throw away the data it read from the connection just before it closed it, because there's a high chance of it being corrupt.

<comment><USER20> That's just crazy. How do you define "just before" ?

<comment><USER19> The last iteration before the current check. But I'd assume the foolproof way would be to return an error if the Close() returns an error, erroring out the entire read. I don't know if a partial read is ever a good thing.

</comment></comment></comment></comment></comment><comment><USER19> Why aren't these problems applicable to Postgres? Is the connection model different or do the libraries already do all this?

<comment><USER21> Why is Postgres relevant to this post at all?

<comment><USER22> Because Go uses the same _provided_ abstraction layer for all SQL databases. If the errors are in the abstraction layer and not the driver it would be odd for them to be MySQL specific.

<comment><USER23> Not really that odd. The abstraction layer provides functionality common to all. Perhaps something common didn't work for mysql.

<comment><USER24> Entirely possible.

If you've ever looked at an ORM or even complex MicroORM that supports multiple database you get an appreciation for how many 'little' differences everyone has in the SQL standard itself.

And if that's the "industry standard" (Yeah, I know it's not, but it's at least a spec/guideline) with that much deviation, I can only imagine how dissimilar each DB's nonstandard protocol might be.

</comment></comment></comment></comment></comment><comment><USER25> I'm sure there are a lot of reasons to hate it but I like how Go does the different database types and the base type

<comment><USER26> A lot of languages do this under the hood, because sql abstraction layers need it for network, query discrepancies.

</comment></comment><comment><USER27> I encountered this same issue a few years ago when using the Go mysql driver, and the simple fix was calling db.Ping() before doing a query, which checks the connection and allows the query to proceed.

<comment><USER28> So you have to make a round trip to the database before making a query? Yikes.

<comment><USER29> You don't need a round-trip, you can push a ping request into the pipe immediately followed by your actual query. You don't care about the actual result of the ping unless your query fails - "if the ping also failed, this was a dead connection so I can retry the query, but if the ping was OK and the query was not, the query failed"

</comment></comment></comment><comment><USER30> I really don't understand the discussion around the first bug. Either something is over simplified, or is it just an issue of a bad abstraction?

This issue (other side closes connection) is so fundamental to all networking code, I don't see how the use specific use case (MySQL idle timeout) is special. The connection pool also doesn't sound relevant - the same would happen if the caller is keeping the same connection (socket) and using it.

For this class of issues - this is the easiest case to deal with - the other side sent a FIN and we got it! Our kernel knows that this socket is closed (doesn't matter if fully closed or only half for this case).

So if you would do a select (or equivalent) call for the socket it will not return as writable (and will probably return in the exception case), and you'll reconnect.

If you don't use select - the write will fail immediately, and I would guess that at the worst case, you can see that 0 bytes were written?

So the problem here was just that the wrong error was returned through the multiple layers of abstractions? Why not propagate the error correctly? Or handle the re connection in a lower level? Trying to "Ping" on the application level is such an overkill and misuse of resources. Do we really want to have an extra round trip for every action we do on a DB?

Of course, as someone else pointed out, there are much harder issues to consider - silent disconnects, proxied connections where the proxy didn't propagate the error, failures on the DB level, and so on.

EDIT: I see now that another comment mentions that there is a specific error code in MySQL clients for lost server.

</comment><comment><USER31> >> Instead, make sure that every SQL operation in your app is using the QueryContext / ExecContext interfaces

I've been wondering if this is indeed a best practice or something that should be used only when necessary. Should every database query really abort if the connection to the client fails?

In addition, if you follow this advice you now need to check if the returned error is context.Cancelled which warrants an HTTP 400 response.

<comment><USER32> Of course it is up to the application to decide case-by-case.

Just keep in mind that if your query is started by a user request, but does not need to terminate in the context of the user request that triggered it, you can move the query to a separate goroutine and decouple it completely from the triggering user request.

Also, aborting a query is safe: the transaction gets rolled back, removing unwanted side effects. You cannot do harm by cancelling, bu you can do harm if you don't cancel.

</comment></comment><comment><USER33> Dumb question, but you can't listen for a close socket event in Go?

<comment><USER34> A TCP half-close, with a FIN? I think that's a limitation of the socket system call API itself.

<comment><USER33> Yeah, I wasn't sure. I was looking at a Dart MySQL connection pool implementation, and that's what's done.

      socket.listen(onData, onDone: onSocketDone);

      onSocketDone() {
        _closed = true;
      }

      write(Buffer buffer) {
        if (_closed)
          throw StateError('Cannot write to socket, it is closed');

        ...write
      }

      onData(RawSocketEvent event) {
        if (event == RawSocketEvent.READ_CLOSED) {
          _closed = true;
        }

        // Other events handled as well, READ, CLOSED, WRITE
      }

But I don't know what's going on under the hood there.

</comment></comment></comment><comment><USER35> One consequence of reinventing the wheel (go) is going through the same problems others stumbled over years ago.

<comment><USER31> As someone who is currently transitioning from Go to Java/Kotlin I agree with you to an extent. However, I was surprised that I wasn't able to find anything in the Java/Kotlin universe that is comparable to Go's web request context cancellation.

<comment><USER36> Loom will have superior context cancellation and deadline handling than golang. [https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1....](https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html)

<comment><USER35> I didn't read all of it, but I was wondering: In a virtual loom thread, am I allowed to call currentThread().sleep(...); or will it block the system thread? Or is there some magic like currentThread().sleepAndThen(..., ()->{}); ?

</comment></comment></comment></comment><comment><USER37> Just curious - are any of the these bugs possible in Rust?

<comment><USER38> Rust SQL drivers (when they exists) are mostly not production ready, they just have not the human resources. For example the leading driver (diesel) do not support elementary SQL such as GROUP BY

<comment><USER39> I thought Diesel was just an ORM, but investigating your comment I discovered that they've implemented their own drivers in-tree. That surprises me, and also seems like a mistake. Steven Fackler's PostgreSQL driver, for instance, is widely considered to be quite solid.

</comment></comment></comment><comment><USER38> The justification for going to go given here is very weak. Firstly if they really cared about performance they would go to jruby or truffleruby, secondly most of the performance of a language are in its library ecosystem beyond being the language itself. Ruby has had decades of optimisation for the server that the nascent go has to reinvent

</comment><comment><USER40> Go: Yet another Google language.

What's it going to be next week?

<comment><USER26> They have Dart, which is alive and well after 9 years and Go, which is alive and well after 11 years.

What point were you trying to make?

</comment></comment><comment><USER41> As someone running MySQL with Go in production and seeing random MySQL connection loss exceptions, is there a summary of how they fixed this? It's an insanely long article and I appreciate the detail and effort, but if someone has read it all and have a gist that would be insanely helpful .

<comment><USER42> You have production issues related to the article but you dont have the time to read the article?

<comment><USER41> Sorry if I came across as lazy. It's a sporadic issue that's more easily fixed with a service restart. Did not mean to come off as entitled. My intent was just to ask for some help from the community.</comment></comment></comment>


The Art, Science and Business of Recommendation Engines - <AUTHOR> http://www.readwriteweb.com/archives/recommendation_engines.php Is this really the best that's out there? <comment><USER2> I think it is interesting that some people cherish the Amazon recommendations above everything, whereas others are fundamentally unhappy with it. Unfortunately I belong in the later category. Sure, sometimes Amazon comes up with something interesting to me, but in general it does not. I wonder if I am just too weird for a recommender system to grasp, or if it hints at the system still being very imperfect.

<comment><AUTHOR> I agree: I rarely find that suggestions based off of anonymous, aggregrate consumer "social" data helps "pick" worthwhile suggestions for me. If a category of shopping is completely new to me, then what everyone else knows can make me more aware of the commonplace options (which is helpful). But if I know anything about the category of items I am looking at, I really don't care what the anonymous masses already know because I know it already too or it's a very "obvious" connection.

</comment></comment><comment><USER3> Great article. Generalized personalization is going to be an increasingly big deal. In a few years, I think it'll be expected that almost any site you visit already knows who you are and what you're like.</comment>


97%ers fighting back :) - <AUTHOR>

Yeah, totally sucks to not even get that interview.  We got our rejection earlier this afternoon too.
But for those of us who still want to play YC's game, the best way to "get back at" YC for the rejection is: get our product launched, get a bunch of enthusiastic users, and get in YC for the Winter 2013 class.  Best way to do that?  Build a stronger team.  Come on guys, let's start now.
This is an open invitation to those who PG should've picked but somehow missed.  Let's Occupy King of Thai Noodles (Grant & Columbus) at 7pm this Thursday.  Remember though, we're not getting together to moan. Bring your passion, your skillz, your totally-off-the-wall-world-changing ideas, we'll see how we can help each other.
Shoot me an email if you decide to come (starcatcher88 AT gmail).  I'll be the girl in the yellow blazer.  Look forward to meeting you. <comment><USER2> I got rejected, I'm close, I'll go. Just sent you an email!

</comment><comment><USER3> The best way to get back at YC is to bootstrap your company to IPO, with YC having no equity in it.

</comment><comment><USER4> Did you just make a new account or are you trolling? Your profile was created 30 min ago.

<comment><AUTHOR> Not trolling, friend (hope that's obvious from my post). Just wanted to protect my primary email account which is the same as my HN login. Hope you can join us.</comment></comment>