Officials: Dozens at WA nursing facility show possible coronavirus symptoms - <AUTHOR> https://www.kiro7.com/news/local/report-dozens-kirkland-nursing-facility-reporting-symptoms-that-might-suggest-coronavirus/2YXV65ZP6VBSZDVX53SUWXLYYU/ <comment><USER2> From another story on the nursing home outbreak:

> "If we had the ability to test earlier, I'm sure we would have identified > patients earlier," he [a Washington State health official] said.

[https://thehill.com/policy/healthcare/485302-officials- annou...](https://thehill.com/policy/healthcare/485302-officials-announce- possible-coronavirus-outbreak-in-washington-nursing)

This is a pattern playing out with striking regularity:

1\. Local authorities can't test for themselves.

2\. CDC adjudicates testing requests, rejects many (most) of them.

3\. People likely infected with COVID-19 are sent back home, to infect others.

Consider this case, posted to HN today:

[https://abc7ny.com/5974999/](https://abc7ny.com/5974999/)

This pattern of apparently deliberate suppression of information can only fan the flames of what looks like a rapidly escalating problem.

<comment><USER3> > _apparently deliberate suppression of information_

There's an alternative explanation: that the CDC massively dropped the ball on making enough test kits available.

The CDC comes off looking pretty bad regardless of whether it's deceit or incompetence, but they're pretty different things.

Hanlon's Razor ([https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)) would tell us which to prefer, although it's not always right.

<comment><USER4> I'm sure this is the reason. Not being honest about it is a problem.

<comment><USER5> Why didn't they buy working kits from other countries though? They had weeks to do that.

<comment><USER6> Probably because there's absolutely no reason to do so? It's not like the US has a shortage of labs that can produce these kits. Supposedly, the problem was that the CDC lab tasked with mass producing the testing kits wasn't competent to do so _and didn 't realise it_ \- if the government had known what the problem was, they could've contracted production out to another US lab sooner. With the benefit of hindsight we of course know that getting kits from somewhere else would've been better, but imagine how much harder this problem would be to diagnose if the kits were sourced from some foreign lab the FDA didn't have access to.

</comment></comment></comment></comment></comment><comment><USER7> Look at the timeline of the outbreak in China: [https://en.wikipedia.org/wiki/Timeline_of_the_2019%E2%80%932...](https://en.wikipedia.org/wiki/Timeline_of_the_2019%E2%80%9320_coronavirus_outbreak)

\- Patient 0 falls ill on December 1, 2019.

\- Patient 1 falls ill on December 8.

\- 8 total cases by December 18.

\- 45 cases by January 16, 2020.

\- 121 cases by January 18.

\- 1,287 cases by January 24.

\- 11,791 cases by January 31.

\- 24,324 cases by February 4.

\- 44,653 cases by February 11.

\- 70,548 cases by February 16.

\- 79,251 cases by today.

Right now, South Korea and Italy are basically where China was in late January and the US and most of the rest of the world reporting their first infections are where China was in mid January. The next few weeks are not going to be pleasant.

It's important to note that the Hubei lockdown started on January 23, and China is only recently seeing new cases plateau as a result. It's hard to imagine what the stats would be had they not taken such aggressive action to contain the spread, but we may find out given that the US, Europe, and most of the rest of the world seems to be taking a wait and see approach as opposed to prompt action.

<comment><USER8> This is accumulated stats, please include the number of active cases too.

And the most of the accumulated cases are from Hubei. I agree the quarantine seems to be effective.

</comment></comment><comment><USER9> I'm starting to take some precautionary measures even here in Virginia. Stocking up on food and other emergency supplies, avoiding public transit and walking everywhere, wiping down all surfaces I come in contact with with Clorox wipes I keep in my backpack. Hopefully I'm just going insane and there's no reason to panic, but a respiratory illness with no treatment protocol besides quarantine, an r nought of probably no less than 2 given lack of testing, and untraceable infection paths for new cases domestically sounds concerning to me. This isn't Ebola or Zika. This doesn't even look like SARS. It looks more like the first wave of Spanish flu. Second wave of Spanish flu made it land in the history books.

I really, really hope I'm just going insane and nothing will happen.

<comment><USER10> Definitely sounds insane to me. Stop reading the news mate.

>80% of cases are mild symptoms. A mild cold. Under 50 has a fatality rate of less than 0.5%. Almost all fatalities are over 70 or people who are already severely ill. You are about 25x more likely to die of the seasonal flu at this point.

This is media hysteria in a post fact world where all information from all sources is equally valid. Everyone is trying to be heard to make their case.

If you are 70+ or severely ill this IS pretty bad because, unlike the flu, their is literally no defense. If you don't fit that profile it's just a bunch of FUD.

<comment><USER11> > If you are 70+ or severely ill this IS pretty bad because, unlike the flu, > their is literally no defense. If you don't fit that profile it's just a > bunch of FUD.

The 34 year old Chinese doctor who spoke up about the virus died.

[https://www.bbc.com/news/world-asia- china-51403795](https://www.bbc.com/news/world-asia-china-51403795)

<comment><USER9> I've heard symptoms relate less with age and more with viral load. The sicker other people are and the more frequently you come in contact with them, the more lethal it becomes.

I'm checking reddit r/COVID19, which is a science based discussion forum with cited academic papers and flaired scientists. It started turning into a prepper forum but I think the mods are shutting that down pretty quickly. I go there for my news.

<comment><USER12> >> I've heard symptoms relate less with age and more with viral load. The sicker other people are and the more frequently you come in contact with them, the more lethal it becomes.

Are you sure that's accurate? I'm not disputing that as viral load increases, so do symptoms, and ability to infect others.

However, I'm finding it hard to model a scenario in which a virus is already replicating in one's system and external exposure to comparitively infinitesimal amounts of the same virus has an impact. Do you have any actual evidence to present which backs up your claims?

<comment><USER13> > However, I'm finding it hard to model a scenario in which a virus is already > replicating in one's system and external exposure to comparitively > infinitesimal amounts of the same virus has an impact. Do you have any > actual evidence to present which backs up your claims?

Who really knows, but there are genetic diversity effects in other diseases. We also know that being exposed to a tiny initial viral load has a better prognosis with many diseases than a massive one (including with past SARS).

Doctors could be facing a "quadruple whammy"\-- a disproportionate share of the worst strains (because they're meeting the most ill patients; exposure to greater viral loads; exposure to many patients with many slight variants of the disease; and sleep deprivation and overwork causing minor immune suppression.

But in the end, this is all speculation.

</comment></comment></comment></comment></comment></comment><comment><USER14> This hospital as about midway between Microsoft and Amazon headquarters.

The governor just declared a state of emergency and authorized use of the national guard:

[https://www.kiro7.com/news/local/department-health- confirms-...](https://www.kiro7.com/news/local/department-health-confirms- first-coronavirus-death-washington-state/XIDPHMLVOJAAREQ5YCL75367PU/)

<comment><USER15> Google has a sizable Kirkland office. A good chunk of Google Cloud is there.

Also, rather ironically, Costco is headquartered there.

EDIT: Costco was founded there, but current hq is a few miles away in Issaquah.

<comment><USER16> People are panic shopping. I think even though the president is downplaying it, seeing how fast it spread in China and Italy, people are preparing for it to be really bad here.

</comment></comment></comment><comment><USER17> >Health officials said that additional positive cases are not expected.

What does this mean? That everyone who could have got exposed are already sick? Or that two weeks have passed with no more new flu-like illnesses?

<comment><USER18> That's a misquotation. The original source says "additional positive cases _are_ expected":

[https://www.kingcounty.gov/depts/health/news/2020/February/2...](https://www.kingcounty.gov/depts/health/news/2020/February/29-covid19.aspx)

<comment><USER19> That's a pretty fucked up misquotation

<comment><USER18> KIRO has fixed the typo in the article.

</comment></comment></comment></comment><comment><USER20> I'm starting to get the impression that most countries are dealing with this outbreak professionally. Except for Iran and the US. Ironic.

<comment><USER21> Doesn't seem that way looking at the numbers regarding the US.

The US has and is handling it the best.

The administration shut down travel earlier than any other country.

There are much fewer cases than other countries even though we have a larger population, economic trade, and travel.

There was already a travel ban from Iran to the US. This morning they just banned travel if you've ever been in Iran, so they don't come through Canada.

Maybe Canada should shut down flights from Iran.

<comment><USER22> Numbers don't mean much. You don't have confirmed cases if you don't test. The same is true pretty much everywhere however, not only the US. You'd have thought we would systematically test people from at-risk region, but apparently not.

<comment><USER21> > Numbers don't mean much.

Really?

> You don't have confirmed cases if you don't test.

There's appropriate testing. You and some media outlets are just fear mongering.

There's less testing overall because there's less risk because the US government quarantined it so well.

Other countries did and have not. Yes there have been some blunders, but that's human.

I don't think blanket statements politicizing the situation helps.

<comment><USER23> > there's less risk because the US government quarantined it so well.

Can you elaborate on that? Up to now everything shows that US government did _not_ quarantine it very well, the chances for early testing and isolation of early cases were missed because of too restricted testing, and now we're getting severe patients who did not have any travel history, so they've been infected somewhere on US soil a week or two ago from sources who haven't been identified (possibly because they themselves have only mild symptoms and don't need hospitalization) and presumably have infected others. These "surprise patients" are evidence that community spread in USA has started some time ago already.

From what I see, countries like Singapore and South Korea are some examples of implementing somewhat effective quarantine measures, and USA has quarantined it _much worse_ than other countries, it's just that it's been hidden due to lack of testing and the time delay of severe symptoms, so we're just starting to see the consequences of that.

<comment><USER21> The total number of cases in each country indicates otherwise.

Currently compared to every other country on Earth, we have quarantined it the best.

Even if you assume there are some undetected cases in the US (which is likely), it's still not even close.

It WILL spread across America, it's just a matter of time.

You are speculating that the CDC will not be able to handle it.

Take a step back and calm down. Maybe evaluate where you get your news and why they are trying to fear monger.

<comment><USER24> > The total number of cases in each country indicates otherwise.

The number of cases in the US is wrong. We know it's wrong because if it was right, we wouldn't have cases stemming from unknown sources.

> Currently compared to every other country on Earth, we have quarantined it > the best.

No. We've put our collective heads in the sand, and hidden from testing any significant number of people.

> It WILL spread across America, it's just a matter of time.

This is the outcome of a bad quarantine.

> You are speculating that the CDC will not be able to handle it.

The CDC has already mishandled it. They created red tape making the criteria for administering testing very narrow. They coerced medical establishments to only use their test kits, rather than being able to pick from known working kits proven elsewhere in the world. Then, the kits they issued were flawed, and they forbade medical professionals from administering them. They have literally done nothing right yet. Have you seen their official webpage on Covid-19? It doesn't even describe the common chain of symptoms; instead it has multiple bullet points about Covid-19 Stigma... You get better and more complete information from reddit.

<comment><USER21> > The number of cases in the US is wrong. We know it's wrong because if it was > right, we wouldn't have cases stemming from unknown sources.

We know they are from other countries that weren't able to get their quarantine under control. Iran and South Korea. Flights from SK were banned this Saturday morning. Flights from Iran were already banned, but now those coming from Canada and other countries that have been in Iran can no longer enter either.

> This is the outcome of a bad quarantine.

So you agree that case numbers matter and the US has dealt with it the best so far, because it's spread across the world much more prevalent than here.

> You get better and more complete information from reddit.

Your reaction makes a lot of sense now.

<comment><USER24> > > The number of cases in the US is wrong. We know it's wrong because if it > was right, we wouldn't have cases stemming from unknown sources.

> We know they are from other countries that weren't able to get their > quarantine under control. Iran and South Korea. Flights from SK were banned > this Saturday morning. Flights from Iran were already banned, but now those > coming from Canada and other countries that have been in Iran can no longer > enter either.

No shit Sherlock. Unknown sources, as in none of the people that we suspected of being exposed could've come into contact with people who later tested positive.

> > This is the outcome of a bad quarantine.

> So you agree that case numbers matter and the US has dealt with it the best > so far, because it's spread across the world much more prevalent than here.

I'm really not sure why you think "bad quarantine = we're #1!", but no, there are many other countries that did a better job of the US, and now it's likely a good number of us will die from it.

> > You get better and more complete information from reddit.

> Your reaction makes a lot of sense now.

Yes, I'm wholly willing to vet sources by the quality of the information they provide, and the CDC is putting out platitudes and vague happy-go-lucky information, while a number of informal channels are putting out the highest quality information available.

Check out: [https://www.reddit.com/r/COVID19/comments/fakavo/compilation...](https://www.reddit.com/r/COVID19/comments/fakavo/compilation_of_information_for_health/)

Compare it to: [https://www.cdc.gov/coronavirus/2019-ncov/index.html](https://www.cdc.gov/coronavirus/2019-ncov/index.html)

I know at this point you're just trolling, but this really isn't the right place for it.

<comment><USER21> Your Reddit post links to the CDC. All of that information you can basically find on the CDC website.

You're very misinformed and you seem to have angst against the administration for little reason.

Get off the internet and stop trying to scare people. Go stock up on germ-x and spend time with your family. Stop politicizing a very serious situation, it's dangerous and tacky.

Good night.

<comment><USER24> > Your Reddit post links to the CDC. All of that information you can basically > find on the CDC website.

Before you edited your comment, you said that half of the links linked to the CDC. The other half linked elsewhere, where useful information was to be had.

> You're very misinformed and you seem to have angst against the > administration for little reason.

Gee thanks, nice to see you aren't above personal attacks. Having been a Marine for nearly a decade, I have quite a lot of experience with the US government.

> Get off the internet and stop trying to scare people. Go stock up on germ-x > and spend time with your family. Stop politicizing a very serious situation, > it's dangerous and tacky.

> Good night.

Truly a poet.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Based on the limited supply of test kits, and ability to use them in an rapid manner, I believe we are entering a phase where symptoms should warrant an immediate self-quarantine.

Waiting for a negative, or declaring that only those that may have traveled or contacted someone who was in china is test worthy is foolhardy. This thing dies after 9+ days in the environment, if we reduce exposure of those who may be infected; It is possible we can wait this out.

Companies without work from home policies should revisit them immediately. Forcing someone who is under the weather or feeling off to come into your office is risking your whole company site.

Also tell your co-workers to go home when they are sick! An office is not an ambulatory pneumonia wing of the local hospital. Sick people should be home!

</comment><comment><USER26> HN is really buying into the media hysteria on this one. I would have expected more.

<comment><USER27> don't know why you got downvoted. I have yet to see the opinion of a doctor explaining why this virus requires specific measures compared to other types of flu-like viruses ( hint: friend working in a hospital recently told me doctors there are amazed by the frenzy on this topic, that looks to them exactly the same as other kinds of flu).

It seems politics are forced to take the same kind of exceptional measures as in other countries for fear of being accused of not being responsible.

I won't mention the other topic, but it's the second time i've found HN lacking scientific rigor the same way the general public does. I guess it's the downside of being more popular..

<comment><USER28> The King County press conference today included a Q&A where this very question was asked ("why this virus requires specific measures compared to other types of flu-like viruses"). According to Dr. Francis Riedo, Medical Director of Infection Control and Prevention at EvergreenHealth, to paraphrase, "The difference between this Novel Coronavirus and Influenza is (1) there is no innate immunity, it is a completely vulnerable population, (2) there is no vaccine to prevent it, and (3) there is no currently effective anti-viral therapy. It is a perfect storm for a novel virus to come out without a vaccine, population base protection, or an effective therapeutic agent."

<comment><USER27> I'm not even sure what this "no innate immunity" sentence means. Old and fragile people are getting vaccined for flu every year, because they aren't immuned to the new strain of the year.

Now it is true that old and fragile people should be worried about coronavirus, but judging from death rates, it doesn't seem more deadly than the flu. So why put fear in the whole population ?

also, most people only experience nothing more than a cold symptoms. Which means most people actually have an immune system able to fight this virus quite efficiently.

<comment><USER28> Where are you getting your information? According to the Chinese CDC it is 20 times more deadly than the flu. And why does "most people only experience nothing more than a cold symptoms" imply that they "have an immune system able to fight this virus quite efficiently"? Younger and non-vulnerable people have gotten extremely sick (and died), one theory being that the more of the actual virus you are exposed to the more severe your symptoms.

<comment><USER27> influenza has 650k death over 3-5 million cases per year, according to wikipedia, which is around 16% casuality.

according to [https://www.worldometers.info/coronavirus/](https://www.worldometers.info/coronavirus/) coronavirus has 3k deaths over 86k, which is 3%. Or if you take the other metrics, which is 40k recovered, that's 3/43 around 7% death. still way lower than the flu.

as for my remark about immune system, my point is that the vast majority of people experience very mild symptoms. Which means that their body was perfectly able to fight back and produce the antibody, just like against the other flus.

<comment><USER28> Try again. That's 3–5 million _severe_ cases per year, not total cases.

<comment><USER27> i suppose the people that got diagnosed for the coronavirus at the moment are people that felt bad enough to go to the doctor or hospital. We probably don't know about most of the cases..

<comment><USER28> Science: [https://www.who.int/docs/default-source/coronaviruse/who- chi...](https://www.who.int/docs/default-source/coronaviruse/who-china-joint- mission-on-covid-19-final-report.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> How do you differentiate influenza from covid-19? These folks probably just have the flu. I live in WA state and I had the worst case of the flu I can remember about 3 weeks ago. Did I have covid-19? No way to really know.

<comment><USER30> Bellevue, WA here; I had a very bad case of the flu in early Feb (worst I can remember) and it took 3+ weeks to fully recover. Many cow-orkers were also affected (some meetings with 30+ people were down to a handful of people . . . not a bad thing under the circumstances).

Our "patient zero" was a dev who came into work for a day with a cough.

If you're sick, please stay home.

<comment><USER31> There's no way you can confirm it was the dev. Almost Everyone has had the flu this year basically regardless of flu shot status. I had a flu shot and got influenza A. It took a week to recover but the fever only lasted half a day. Tamiflu helped. My case corrresponded with a peak in cases in my state.

<comment><USER32> Most of my past flu "experiences" have been like that. Started of as a cold, two days of low fever, 8 hours of high fever (that waas the sucky part), and two to three days for everything to stabilize.</comment></comment></comment></comment>


Man discovers glasses-free 3D tech in the blink of an eye (video) - <AUTHOR> http://www.engadget.com/2011/01/15/man-discovers-glasses-free-3d-tech-in-the-blink-of-an-eye-video/

<comment><AUTHOR> Is it healthy for the eyes to blink for a prolonged period at high frequencies?

<comment><USER2> Instead of glasses, electrodes hooked up directly in the nerves that control blinking, sync'd with the video stream :)

</comment></comment><comment><USER3> I'm fairly sure it's a joke kids.

</comment><comment><USER4> I'd get RSI in my eyelids.</comment>


The Curious Phenomenon of Stochastic Resonance - <AUTHOR> https://medium.com/the-craftsman/the-curious-phenomenon-of-stochastic-resonance-b263449486eb <comment><USER2> Isn't this (just) dithering noise?

AFAIK, the reason it's so effective in the example is that adding the noise helps the quantization process in the posterization better represent the original color spectrum. Without the dithering the quantization error can keep adding up in a way that the posterization filter cannot control (but which the image author can engineer to be problematic, as surely was the case here). With the dithering you have a statistical guarantee that the quantization errors average out.

<comment><USER3> > With the dithering you have a statistical guarantee that the quantization > errors average out.

Could you point me towards somewhere this statement is made precise?

<comment><USER4> I don't know where to link you to, but here is a more detailed statement, which I think could be straightforwardly expanded into something precise.

Consider a signal S[i], i=1...N. The human eye isn't actually perceiving S[i], it's perceiving some convolution of it S[i] \conv w[i] (for a window function w). I.e., an area with 50% white pixels and 50% black pixels appears grey.

Suppose for simplicity w[i] = 1/k on i=0...k.

Now add noise g[i] to the signal in a region where S[i] = alpha. Then S[i] + g[i] = alpha + g[i]. The number of pixels above a threshold T within the window are then 1-cdf(T-alpha), where cdf is the cdf of the distribution of g.

Assuming your cdf is approximately linear near T, then 1-cdf(T-alpha) \approx C + alpha.

</comment></comment></comment><comment><USER5> Your eye already does this naturally to help you determine detail. There's a fascinating article about it here:

[http://accidentalscientist.com/2014/12/why-movies-look- weird...](http://accidentalscientist.com/2014/12/why-movies-look-weird- at-48fps-and-games-are-better-at-60fps-and-the-uncanny-valley.html)

</comment><comment><USER6> What's happening is the added noise causes the spectrum of the error to change. With uniform uncorrelated noise (and some constraints), you can prove that the error is also uniform + uncorrelated, which means that the signal distortion must be zero (because otherwise the error would not be uncorrelated).

You can see that this gives you a discernible image with only 1 bit of depth. The same technique gives digital audio extra range and lower distortion.

</comment><comment><USER7> The phenomenon is interesting, although the connection to UI is a little vague. Still, I think author has a good point.

Take bevels for instance. They may be considered a visual "noise", and in flat design they are frowned upon, but how do I know where I can click (push a button)?

Similar thing for window shadows, they help to recognize the window boundary.

<comment><USER8> If it communicates something helpful or necessary it cannot be considered noise.

The idea behind flat design is that we don't need to have a wooden texture to understand that something is a button.

The problem is when you forget to communicate that something is clickable/interactive, which seems to be a major issue with current flat design implementations.

But let's not forget that back in the day it was fashionable to only show that items were interactive through mouse hover. So the problem with designers forgetting useability is hardly something new.

</comment></comment><comment><USER9> There's a related phenomenon in astronomy called Eddington Bias. If you're doing a survey of stars in the sky, often times you are limited by the brightness of the stars, so there's some brightness below which you don't detect any stars.

Because photons arrive at your detector randomly, sometimes a few more photons arrive at the detector from a particular star than average, and sometimes fewer. One therefore sees small random fluctuations in the brightness of the star.

Because there are many more faint stars than bright stars, it is much more likely for a star just below your detection threshold to fluctuate up above your detection threshold than for a star just above your detection threshold to fluctuate down below your detection threshold. This ends up biasing the inferred median luminosity to higher values.

</comment><comment><USER10> I'm not sure how he makes the association to UI, but I agree that the minimalist and flat designs are way too far gone to be useful. Sure, I despise noisy and cluttered and fake leather bound UI too, but that doesn't mean we need to go full bi-polar swing and jettison everything.

Regarding noise and this post, I could see it as a metaphor against Google's tendency to significantly reduce the information density by adding white-space to every frigging things, everywhere, at all times. Take the bookmark boondoggle that they just backpedaled on; guess what Google, I would like to see more than 8 bookmarks per view and I don't see how a miniature thumbnail of the site really helps anyone. I want the "noise" in that case, which consists of density of information, which hopefully is of the relevant type. I want a quick overview with as much information as possible, but I also need it to be visually distinguishable. That is another big problem which this post maybe addresses, visual hierarchy, which is another one of those principles that has been jettisoned with the minimalist and flat design binge. The user should be able to pic out content and interactions in a relevant sequence without significant gaps in visual progression; each level of visual hierarchy should be an equal or relevantly spaced distance apart without significant gaps. /my2cent

</comment><comment><USER11> This is also reminiscent of the Gumbel trick[1] If your noise is Gumbel noise, you can actually get the probability to exceed the threshold to be proportional to the intensity of the pixel.

[1] [https://hips.seas.harvard.edu/blog/2013/04/06/the-gumbel- max...](https://hips.seas.harvard.edu/blog/2013/04/06/the-gumbel-max-trick- for-discrete-distributions/)

</comment><comment><USER12> It's also used in cochlear implants.

<comment><USER13> My dad actually did some work on this. When I was younger I couldn't believe that such a thing was true. Now that I'm much older and got a couple of engineering degrees and have worked for a while, it doesn't surprise me much at all.

The older I get the more I recognize that shit is weird. Intuition is extremely useful for "simple" deterministic systems. Once biology gets involved, though, intuition (at least in an engineering sense) tends to go right out the window.

</comment></comment><comment><USER14> Could someone expand on this phenomenon as it relates to noise machines? They normally help people sleep but could they actually make certain sounds more distracting based on this phenomenon?

</comment><comment><USER15> Professor Bart Kosko at USC is an active publisher in this area.

Example: sipi.usc.edu/~kosko/TSP_May2009.pdf</comment>


The Capture API (Video and Audio in Javascript) - <AUTHOR> http://dev.w3.org/2009/dap/camera/

<comment><USER2> Will this be part of HTML 5?</comment>


Understanding SOLID Principles: Dependency Inversion - <AUTHOR> https://dev.to/theodesp/understanding-solid-principles-dependency-injection <comment><USER2> "The drawback of dependency Inversion is that you need a dependency injection container, and you need to configure it."

This is simply wrong.

You can do dependency _injection_ without a container (using factories, or link-time polymorphism).

Dependency _inversion_ is a lot more general:

Depending on a header file (interface) instead of a specific implementation already is a kind of dependency _inversion_.

Having a language-independent IR in a compiler also counts as dependency _inversion_ (compared to an implementation where the frontend calls the backend): it prevents dependencies between the frontend and the backend (whose reasons to change generally aren't correlated), by making everybody depend on the IR instead.

<comment><USER3> Not only is it wrong, but it's wildly misleading about why dependency inversion is desirable. This article is trash; it's basically a copy/paste of the Wikipedia entry on dependency inversion, rewritten awkwardly (not to mention the usage of Comic Sans).

</comment></comment><comment> trevor-e My problem with blog posts on SOLID (like this one) is they overcomplicate ideas that should be simple. This entire article could be replaced with:

\- When trying to make code testable, it's easier to configure from the outside than inside.

There's no need to mention other topics like factories, DI containers, etc. All of those are obvious abstractions on top of the very simple idea.

<comment><USER4> They are only obvious after you see them.

My only criticism is about articles that confuse the principle with the means you use to obtain it. Yes, do talk about factories and containers, but separate them from the principle and keep in mind that there are many other ways to get it. You don't _need_ a DI container.

Besides, it only provides you an specific kind of testability, that may or may not be the best way to test your code.

</comment></comment><comment><USER5> Dependency Inversion ≠ Dependency Injection

</comment><comment><USER6> There's also "Dependency Rejection" [http://blog.ploeh.dk/2017/01/27/from- dependency-injection-to...](http://blog.ploeh.dk/2017/01/27/from-dependency- injection-to-dependency-rejection/)</comment>


Neugram – Scripting in Go - <AUTHOR> https://neugram.io/blog/neugram-briefly <comment><USER2> "Go is syntactically a big language. Neugram's front end has to match it, and that's a lot of work, much of which is still to do."

I appreciate the sentiment – that there's a lot of work left to do – but isn't the assertion about syntax size false? I thought Go's syntax was quite small compared to other popular languages? It only has 25 reserved words (Java has 50+) and was designed in part to be uniform and easy to read.

<comment><USER3> I made this point poorly, because I agree with you that Go is quite easy to read and very predictable.

With more words: I have written a parser and type checker for an ML-style language, with parametric types and several other neat tricks in it, and I've now written a parser and type checker for a good subset of Go. The latter has been far more work. I am not entirely sure how to explain the work. Go has lots of syntactic and type conveniences that are easy to use and read, but quite difficult to implement.

As there are few implementers and many users, I think the original designers of Go picked well when they put the work on us implementers.

<comment> ainar-g Can you elaborate on what syntactic conveniences are difficult to implement and why? Language design is on of my hobbies, so I really would like to know that.

<comment><USER3> One good example is untyped constants. They form a large extension to the type system only present at compile time. It is a good example because there is an excellent blog post describing them in detail: [https://blog.golang.org/constants](https://blog.golang.org/constants)

In particular note the difference between

        const hello = "Hello, 世界"

and

        const typedHello string = "Hello, 世界"

one of these can be assigned to named string types, the other cannot.

As a user of Go I find untyped constants to be extremely useful. They almost always do what I want without surprise. Implementing them however, is not trivial.

A tricker example is embedding. It adds a lot of complexity to the type system. As a user, it can be a bit surprising, but I admit it is very useful.

</comment></comment></comment></comment><comment><USER4> How does this compare with [https://github.com/cosmos72/gomacro](https://github.com/cosmos72/gomacro) which does something very similar? It seems fairly complete, or at least much further along than neugram + it does lisp style macros! If you ignore the macros its language is pretty much go except that main(){ ... } is elided just like in ng.

May be worth checking it out, at least for ideas/inspiration.

</comment><comment><USER5> 100% behind you on this, crawshaw. Although I've never missed having a Python style REPL for golang ("go run" usually fits the bill). You make a convincing argument for why it would indeed be a very powerful tool for any Linux admin's toolbox ;)

It's premature for feature requests I know. But I'd love to be able to view the Stack Trace of a live running goroutine. Typically something I log to disk using the "runtime" calls. To be able to probe that info from a command shell would be neat, don't you think?

</comment><comment><USER6> It's not clear to me where I would go from this page to try it out, or install it, etc.

<comment><USER3> Yes, that sounds like the kind of mistake I would make.

I put a tiny link at the bottom of to the home page: [https://neugram.io](https://neugram.io). I'll do something more elaborate when I'm done with this other bug I'm working on. Thanks.

</comment></comment><comment><USER7> This is really cool, but I can't help but suggest another language which works incredibly well for scripting: Nim[1].

Of course, I must put a disclaimer: I am incredibly biased as I am of Nim's core developers. But to help convince you, Nim has:

* Shebang support

* Error handling via exceptions

* A somewhat limited REPL

* Operator overloading

While I applaud the author's efforts, I can't help but wonder if Nim would fit their needs (or be easier to adjust to their needs).

1 - [https://nim-lang.org](https://nim-lang.org)

<comment><USER8> Nim has become so good that no one else should develop languages as pet projects? If that's what you're saying (which is how I read it), it's a very obnoxious sentiment.

<comment><USER9> I took it more like "if you clicked on that, you may also be interested in this" (which I in fact was).

</comment></comment></comment><comment><USER10> I like this. Especially the error handling. Since the focus on a scripting language can be brevity (Ala perl) I don't want to write all that error handling boilerplate. But I don't want to ignore issues either. So this is a compromise. I can check errors, I can capture errors (in _) to ignore them. But if I don't do anything, they turn into panics.

</comment><comment><USER11> this reminds me of the effort to replace a lot of the intel management stuff with linux and have userland all written in go

[https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...](https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf)

</comment><comment><USER12> Glad to see this using [http://github.com/peterh/liner](http://github.com/peterh/liner) for interactive line editing.

I used that package in an interpreter of my own and it works wonderfully to provide `readline` style keyboard interaction in a pure Go program.

<comment><USER3> It really is an excellent package. Does exactly what it says on the box.

I fear I may hit a wall with it eventually. For example, several interesting approaches to [https://github.com/neugram/ng/issues/49](https://github.com/neugram/ng/issues/49) would step outside what liner can do. But I'm going to use it as long as I can.

<comment><USER12> Among other things, I actually modified liner to stop using/swallowing all control codes, and to instead surface some of them to the client program to decide how to respond. e.g. liner stops doing anything with Ctrl-X (0x18 ?) and instead ng could respond to Ctrl-X by writing a docstring to stderr for an identifier under the caret in the input buffer.

[https://github.com/frou/liner/blob/master/common.go#L208](https://github.com/frou/liner/blob/master/common.go#L208)

</comment></comment></comment><comment><USER13> It seems like something like this would be useful for a Jupyter kernel. I don't think I'd use this as an embedded scripting language; it doesn't offer enough in terms of abstraction and conciseness to justify leaving Go. I'd probably try for a lisp.

<comment><USER3> Jupyter is a good idea that was only recently suggested to me: [https://github.com/neugram/ng/issues/16](https://github.com/neugram/ng/issues/16)

Definitely something to try.

</comment></comment><comment><USER14> This is awesome. I've been trying to reach for go instead of bash more and more and this is exactly what I need for the small stuff.

Any ideas how it could relate to the go toolchain? could I stick my Neugram files in a repo and go get them?

<comment><USER3> The relation to the go toolchain right now is your GOPATH is used to find Go packages when you import them. (It uses the go tool to build the package as a plugin for loading.)

You certainly could put your Neugram files in the same git repository as your Go code, and then "go get" would get them.

I think there is something to be said for something like:

        import "github.com/crawshaw/foo/mypkg.ng"

looking for the .ng file in your GOPATH. I need to think about that a bit more.

(Note that a Neugram package is limited to a single file, unlike a Go package. This is for a couple of practical reasons, notably init order, and one philosophical reason: which is Neugram packages shouldn't get as big as Go packages.)

</comment></comment><comment><USER15> No shebang support? What about this? Sure it's not "native" but it accomplishes the same thing.

[https://rosettacode.org/wiki/Multiline_shebang#Go](https://rosettacode.org/wiki/Multiline_shebang#Go)

</comment><comment><USER16> even cleaner python: with open("hello.txt","w"): f.write("Hello, World!")

</comment><comment><USER17> This will be amazing for plugins!

</comment><comment><USER18> Sometimes switching between Go and C is weird (because of the type order or the semicolons) but I've never had any trouble switching between Go and Python.

Go has an awesome ecosystem for writing servers and web applications but it's obvious that the libraries weren't built for scripting purposes and the language is more explicit (for good reasons).

Python, on the other hand has an ecosystem that's great for scripting and language features that are more compact and terse.

<comment><USER3> If you don't have trouble switching between Go and Python, then the concept of Neugram has much less to offer you than me.

Possibly you don't because you use both languages more than me. My scripting needs are approximately once every other week, sometimes even longer. That's enough time for me to forget what python package has the date/time functions I need.

I also wouldn't even begin to compare something in its infancy like Neugram with something as well-established as Python's huge collection of libraries. There are many years of work between here and there.

<comment><USER18> > Possibly you don't because you use both languages more than me.

It depends what the client or project demands. I've worked in Python, Javascript, PHP, VBA, Java, Go, and C (plus a few dialects of SQL). Spending months writing mostly one or two of those at a time. The only ones I enjoy enough to use in my hobby projects are Python, Javascript, and Go.

But in my experience the hardest part of toggling between languages like that is the ecosystem (libraries and tools).

In this case it seems like you're adding a new ecosystem which means I'd still have to stop and figure out "what's the right package to use for this?"

For the most part, language is easy. It's the idioms, libraries, and tools that I find myself googling the most.

<comment><USER3> My goal is very much to reuse Go packages. It is somewhat working today. The underlying mechanism is when you type something like:

        import "github.com/pkg/errors"

A .go wrapper file is generated, a Go plugin is built, and then loaded into the ng executable. You can then use the errors package in the Neugram evaluator. Under the hood the lifting is done by the reflect package.

Very much my goal is when scripting, to use the os.Open and ioutil.ReadFile I know, along with filepath.Join, time.Now, and friends.

</comment></comment></comment></comment><comment><USER19> You can already "go run program.go" from anywhere, even outside of a project structure, which is the same result as running an interpreted script.

It's a novel idea but I don't really see it taking off. Is there really that much benefit to having a shebang at the top of the file versus executing "go run" and is it really worth having a REPL for a fairly verbose language? I certainly don't see myself wishing for a Java REPL, and I don't particular see myself reaching for a Go REPL either.

<comment><USER3> The goal is to add other features that are also useful for scripting. The big one I've worked on so far is syntax for the os/exec package: [https://github.com/neugram/ng/blob/master/docs/shell.md#a-sh...](https://github.com/neugram/ng/blob/master/docs/shell.md#a-shell- session)

Another thing I'm interested in is operator overloading, for compact/pleasant matrix/table types.

<comment><USER20> Y'know, if you happened to accidentally create nice bindings for using TensorFlow in the process... :)</comment></comment></comment>


Shell script to automatically set wallpaper from 500px - <AUTHOR> https://github.com/amolgupta/500walls

<comment><USER2> This is for GNOME only. Can be extended to KDE easily.</comment>


The Profound Weakness of the .NET OSS Ecosystem - <AUTHOR> http://www.aaronstannard.com/post/2014/07/03/The-Profound-Weakness-of-the-NET-OSS-Ecosystem.aspx <comment><USER2> I get your message - that it's not about the platform, it's about the community getting lazy. And lazy is the key word here ... are all of these .NET devs out there hacking away at line-of-business CRUD apps really not capable of more? Is it that these things aren't being done or they are not being shared?

Originally I thought your piece was going to be solely negative, but I like the way you finished with a call-to-arms. You're right, .NET is a great platform and deserves better. Let's organize and build something worth porting the other direction :)

</comment><comment><USER3> This is what mealy-mouthed "best tool for the job" rhetoric misses. Different platforms have different communities with different people in them, who place emphasis on different aspects of development.

My personal hunch is that the things that get in your way as a developer on Windows add up and become very frustrating. So, good devs either get tired of this or don't want to deal with it in the first place. The rest of them wait for an open-source solution, rewrite it in C#, and prepend the name with an "N".

</comment><comment><USER4> Open source doesn't happen much on Windows. It mostly happens on Linux, _BSD and Macs, where_ free* and _fully-featured_ developer tools (including usable command line) were easily accessible for years.

.NET, on the other hand, is running pretty much only on Windows (I keep hearing that Mono is still not a production-ready thing). Don't expect people to write OSS for a platform they can't use for themselves. You have just chosen badly your environment for backend servers.

</comment><comment><USER5> Can't some of those problems be solved with something like NServiceBus and 0MQ? Aren't F# MailBoxProcessors similar to Scala's Akka?</comment>


VC Investmentsas a % of GDP - <AUTHOR> https://read.oecd-ilibrary.org/employment/entrepreneurship-at-a-glance-2017/venture-capital-investments-as-a-percentage-of-gdp_entrepreneur_aag-2017-graph109-en#page1 <comment><AUTHOR> So Israel/Telaviv is a known outlier with huge VC investment in a tiny economy.

But I am surprised by the high US & Canada %.</comment>


Automatically Create a Bit.ly URL for WordPress Posts - <AUTHOR> http://www.phpcmsframework.com/2015/09/automatically-create-bitly-url-for.html <comment><USER2> Curious how this is different, or what the advantage is to use this, than using something like the Yoast bit.ly plugin?</comment>


The MS Dilemma: how do you get a browser on a OS without a browser? - <AUTHOR> http://mrtopp.com/2009/06/23/the-microsoft-dilemma/

<comment><USER2> There are lots of minor browsers, most with miniscule market share, so the first question that must be answered is "how many competitors do we want to introduce". On the one hand, a healthy market will have a lot of competitors; on the other hand a lot of these potential competitors will be niche products for a Very Good Reason (i.e. they're crap) and it would be unfair to make Microsoft present them as valid alternatives when they clearly are not (and it might tarnish the reputation of other, better browsers included in the same list).

This is a very difficult question to answer in a fair, objective manner. One way might be to say "all browsers whose current market share on Windows is greater than x%", but you have to push the value of x pretty far down before your list of alternative browsers expands much beyond Firefox (ISTR Safari's ~4% share is almost exclusively on the Mac, and Opera is under 1% across all platforms). If it were possible to draw a convincingly fair line selecting Firefox, Opera and IE, that would be my preferred outcome.

As to distribution, since every PC needs a default browser, I think the only reasonable thing is to let the non-IE browsers selected in the previous step compete with each other for OEM bundling deals, then legally restrain Microsoft to compete on the same level (price must be the average of the other competitors, no sneakily giving discounts on Office in exchange for IE bundling, etc.)

Finally, this age-old misunderstanding from the article clearly needs to be addressed yet again:

        Surely if Microsoft is fined 900 million Euros for bundling a browser with
        an Operating System, the same should happen to Apple?

Ever heard the phrase "go pick on someone your own size"? If you have a monopoly, by definition there _is_ nobody your own size in your market, and hence there are things that other entities are allowed to do that you can't. APPLE IS NOT A CONVICTED MONOPOLIST, THEREFORE ANTI-TRUST RULES THAT APPLY TO MICROSOFT DO NOT APPLY TO APPLE.

</comment><comment><USER3> I seriously don't understand all the hullaballoo on the browser issue. All MS would have to do is insert a popup which shows the first time you run windows pointing out the fact that Explorer (the file manager bundled which is part of the windows shell) can very well be used to access the Internet. Ofcourse it's not going to be as convenient as a browser, so most people are just going to use it to google their favorite browser and install. Maybe MS could include a small Bing button on explorer using which you can search for any browser you want. Problem solved.</comment>


Are Standing Desks Better for You? - <AUTHOR> http://minutehack.com/opinions/are-standing-desks-better-for-you <comment><USER2> One interpretation: backpain and bloodflow issues are the price to pay for living longer.

I sit and stand as needed. At least I get comfort for now, and I'm pretty sure it has contributed to weight loss (particularly slipping the treadmill into use occasionally).

Current arrangement: Ikea bar table and bar stool (with cable tidy underneath). Big enough for second screen, lamp and monitor speakers. Just. Keeps the desk clutter more or less to a minimum, at least.</comment>


1066: Rationality Spring 2020 taught by Steven Pinker [pdf] - <AUTHOR> https://stevenpinker.com/files/pinker/files/gen_ed_1066_rationality_syllabus_spring_2020.pdf <comment><USER2> Wow, his grading policy is garbage.</comment>


Show HN: RD Workbooks: Free Cross channel data downloader for digital marketers - <AUTHOR> https://app.reportdash.com/data_downloader <comment><USER2> Love the demo you guys have made. Pretty easy way to test out the product.

</comment><comment><USER3> How is this different from Supermetrics?

<comment><USER4> One of the founders here. It is pretty much similar to SuperMetrics. But we are catering to marketers who are looking for something much simpler than excel for data crunching.</comment></comment>


Surveillance shows Chinese ships sell oil to North Korea - <AUTHOR> http://english.chosun.com/m/svc/article.amp.html?contid=2017122601156 <comment><USER2> I would wager that it's not actually the ships that are selling the oil.

And I wouldn't normally wager if it's a gamble.

</comment><comment><USER3> How long will the UN look the other way as china and nk continue to openly defy sanctions? I really don't understand the point of 'imposing' something you are unwilling or unable to enforce. It just makes them more boldface in their subtrifuge when we let it slide.</comment>


This device will automatically enter how much you chew for you - <AUTHOR> https://techcrunch.com/2017/06/20/this-device-will-automatically-enter-how-much-you-chew-for-you <comment><USER2> If the problem were a simple matter of sheer gluttony, this would make sense.

However, it's not a matter of people merely _choosing_ to eat more than they should. If that were the case, obese 6-month-old children would be an extraordinary rarity.

Fructose is the primary cause of the obesity epidemic: [https://www.youtube.com/watch?v=dBnniua6-oM](https://www.youtube.com/watch?v=dBnniua6-oM)

It's difficult to eliminate fructose from your diet because it's put into everything from mayonnaise to ketchup to bread. And people suffer from the twin delusions that consuming small amounts of fructose won't add up, and that healthy-sounding sweeteners such as "agave nectar" are somehow better for them than high-fructose corn syrup.

"Agave nectar" contains between 50 and 90% fructose, depending on the supplier. Although it contains slightly less fructose, honey is dangerous for exactly the same reason. And while eating a few strawberries is perfectly healthy, eating too many all at once, or separating the fructose from the fiber content through any kind of processing (blending, freezing, etc.) is enough to induce these same toxic effects on appetite control.

Oh, and one more thing. Food manufacturers have a LOT of different names that allow them to conceal the fructose content of their products. Here are but a few (61!)

Agave nectar, barbados sugar, barley malt, barley malt syrup, beet sugar, brown sugar, buttered syrup, cane juice, cane juice crystals, cane sugar, caramel, carob syrup, castor sugar, coconut palm sugar, coconut sugar, confectioner's sugar, corn sweetener, corn syrup, corn syrup solids, date sugar, dehydrated cane juice, demerara sugar, dextrin, dextrose, evaporated cane juice, free-flowing brown sugars, fructose, fruit juice, fruit juice concentrate, glucose, glucose solids, golden sugar, golden syrup, grape sugar, HFCS (high-fructose corn syrup), honey, icing sugar, invert sugar, malt syrup, maltodextrin, maltol, maltose, mannose, maple syrup, molasses, muscovado, palm sugar, panocha, powdered sugar, raw sugar, refiner's syrup, rice syrup, saccharose, sorghum syrup, sucrose, sugar (granulated), sweet sorghum, syrup, treacle, turbinado sugar, yellow sugar.</comment>


You're More Likely to Be a Disruptor If You Got Lower Grades in School: Study - <AUTHOR> https://www.inc.com/wanda-thibodeaux/study-says-you-dont-have-to-be-a-top-graduate-to-become-a-disruptor.html <comment><USER2> First of all, this is blogspam. The link to the "study" actually just links to another news article. This seems like it might be the actual study: [http://files.eric.ed.gov/fulltext/ED368304.pdf](http://files.eric.ed.gov/fulltext/ED368304.pdf)

Second, note the sample: > In addition to 51 valedictorians, study participants include 20 salutatorians and 9 top honor students.(Salutatorians were included on the urging of members of a pilot study of high school valedictorians. Nine students who were neither valedictorians nor salutatorians also were included on the advice of school administrators who identified these students as the "real" top students at their high school.

In other words, this study only included a relatively small number of people, at the top of their class, So how can it support the headline conclusion in the headline?

</comment><comment><USER3> There are more people with low grades than with high grades, so it is not surprising that if you are a disruptor you are probably a low grade type.

The interesting question.is: what is the percent of disruptors in low grade types? And in high grade types?

Still, not _that_ interesting, since you are not really a sample "low grade" or "high grade", but a more specific type ("you"), where maybe completely different characteristics dominate.</comment>


CoffeeScript Means Giving Up on JavaScript - <AUTHOR> http://www.w2lessons.com/2011/11/coffeescript-means-giving-up-on.html

<comment><USER3> It's very gratifying to see how overwhelmingly the comments are both positive and in disagreement with Michael's blog post.

If you'd like to see the most complete explanation of why CoffeeScript is all about working with and embracing JavaScript -- not giving up on it -- the best resource is probably Brendan Eich's and my joint talk at this year's JSConf:

<http://blip.tv/jsconf/jsconf2011-jeremy-ashkenas-5258082>

But the other interesting thing here is how many of the comments point to the fact that most people who write posts about fears of CoffeeScript have never actually tried it. Having experienced a good deal of this myself, I have a pet theory about why this is the case...

First, the caveat that CoffeeScript is just a fun little thought experiment: I have no vested interest in whether you use it or avoid it for your project -- whatever suits you best.

Most esoteric programming languages are non-threatening. As a hypothetical programmer working on web applications, I can feel safe and comfortable in my ignorance of Haskell, Erlang, D, Io, Arc, and so on. They're far enough outside of the realm of possibility of adoption for my company that I can shrug them off with an "oh, that sounds interesting", and little more. Wanting to adopt one of them would require a whole new development and deployment stack, a new or ported codebase, and new integration costs with the rest of our system. You wouldn't expect to see an article talking about how people using Erlang are creating a "knowledge gap" for Java programmers.

CoffeeScript feels threatening precisely because it _is_ so close to JavaScript, because the code can run with identical performance as hand- optimized JS anywhere that JavaScript can run, because any CoffeeScript library can interoperate seamlessly with any JavaScript library, and vice versa. It forces you, as a reasonable JavaScript programmer, to answer the harder question: Why haven't you tried it yet? Posts like these happen when folks try to rationalize an answer for themselves.

<comment><USER4> _Why haven't you tried it yet?_

I have tried it, and I love it (same goes for Backbone and Underscore, by the way - you are the developer who's work has impacted me the most positively in the past year) _but_ I haven't used it for anything serious yet, and here's why: the workflow is more complicated than "make change, refresh". Until very recently, my programming time was split about equally between the three major operating systems (I have since managed to phase out Windows almost entirely) and it's way more trouble than it's worth to set each of them to autocompile changes to .coffees. I know that I could import the compiler and use script type="text/coffeescript", I know about LiveReload for Mac (even though I couldn't get it working in the few minutes I tried it) but the bottom line is that I already know how to write Javascript, and it works great. Learning a new language is the sort of thing I like doing, but wasting time futzing around with build systems is not.

Anyway, I didn't mean to rant. I could easily love CoffeeScript - I don't feel threatened by it a bit. But there are some serious barriers to adoption, and Javascript isn't nearly painful enough for me to deal with them.

<comment><USER5> If that's truly all that's stopping you, try out Middleman (<http://middlemanapp.com/>) or my own Draughtsman (<https://github.com/stdbrouw/draughtsman>). Taking two minutes to install an app hopefully does not constitute "wasting time futzing around with build systems" :-)

Also, I think your problem is very particular to front-end devs and designers- that-code. If you're already doing back-end in your framework of choice, adding CoffeeScript or any kind of precompilation into the mix is usually just a one-liner in a config file away.

<comment><USER4> Cool, I will take a look!

And not every back-end dev is lucky enough to be working in their framework of choice ;) (I would actually call myself more of a front-end guy, but I do plenty of back-end work and the only time I get to use frameworks I enjoy - Django, Flask, etc - is for my side projects.)

</comment></comment></comment></comment><comment><USER5> > More importantly, [languages like CoffeeScript] all fail by requiring that > you be an expert in two languages.

Why does this mean they fail?

> learning CoffeeScript and its idiosyncrasies

Which idiosyncrasies?

> The problem is that many programmers are turned-off by the lax nature of > JavaScript

Maybe true of Dart, not of CoffeeScript

> but I urge you to ask yourself whether a move to CoffeeScript is sign that > you've given up on learning it properly?

It isn't.

> we rarely have problems caused by the very things that CoffeeScript aims to > eliminate

CoffeeScript is generally more readable and concise than JavaScript. It's just more pleasant to work with. Does it solve any problems for a narrow definition of "problem"? Probably not, but who cares?

I've noticed that most people who don't like CoffeeScript simply have a negative gut feeling about it, but have never really tried it. Or are trying to prove that they're better at JavaScript than you are (see <http://stdout.be/2011/08/23/macho-programming/>). I don't mind that: everyone is free to choose his/her own tools, and if one of the hot new tools everybody else seems to be using just looks ugly or stupid to you, whatever. I probably make my own fair share of weird toolkit choices. But I don't try to rationalize them with arguments that don't make sense.

</comment><comment><USER6> CoffeeScript _will_ mean giving up on JavaScript. The more popular CoffeeScript becomes, the less proficient the overall developer population will be at JavaScript,especially if they spend most of their time writing CS over JS. The problem at the moment is that the world still works in JavaScript, not CoffeeScript.

He rightly draws the analogy between jQuery and JS. I spend a lot of my time working on jQuery core, and we have definitely seen the phenomenon described in that blog. Five years ago when jQuery was created, just about every web developer knew JS quite well and understood the quirks of every browser and JS implementation. Now, they just assume that if something doesn't work consistently in IE6 then it must be a jQuery bug, because you know, _jQuery is cross browser_. People are now programming in jQuery and have given up on JavaScript.

If you're a CoffeeScript pioneer you don't see this. You already know the hard and ugly JS things that CS makes easy and beautiful, just like the early jQuery adopters. A few years from now if browsers haven't created native CS implementations but CS is popular, novice programmers will be dealing with the same jQuery-vs-JS dilemma. For example, programmers with weak JS skills will write CS and be baffled by the errors thrown from the bowels of the JS code they are forced to debug.

<comment><USER7> "In a few years," Chrome and Firefox will have support for source maps. The average CS developer will be debugging in CoffeeScript, not JavaScript. The original author's argument is much weaker when this feature is considered.

<comment><USER8> The original author's argument will be much weaker when this feature is implemented. But not today.

Promises of future solutions don't help fix the problems that exist today today.

<comment><USER9> The author of the people-will-forget-JS-in-the-future premise is specifically referring to the future. CS specifically solves a present-day problem--ugly JS syntax.

</comment></comment></comment></comment><comment><USER10> To quote the author: "For the extra effort you'll make learning CoffeeScript and its idiosyncrasies, why not put it towards really learning JavaScript?"

There are so many wrong saying in this statement.

First, understand that CoffeeScript _is_ JavaScript - but without its idiosyncrasies. If you know JavaScript really well, learning coffeescript takes minutes. CoffeeScript embraces closures and prototype inheritence; it just makes it less cumbersome to use.

Second, who said that programming in CoffeeScript means you don't _really_ know JavaScript? CoffeeScript let you write better code in less line. (By better I mean easier to maintain and read). Furthermore, CoffeeScript programmers tend to choose it because they enjoy coding in Javascript and want to keep using it. What is way more scary is maintaining codes of designers who use jQuery without understanding Javascript.

Third, I hate the "For the extra effort" part. It's like saying, either you learn Python or C++; you can't learn both so better spend the time learning C++. It's just totally wrong. Good programmers tend to enjoy learning new technologies and paradigms. I'd even go further by saying that learning CoffeeScript will make you a better JavaScript programmer.

<comment><USER11> > _Good programmers tend to enjoy learning new technologies and paradigms._

You've stumbled onto a pet peeve of mine. I think it's rather that people who like learning new programming languages like labeling people like them as "good".

The flip side of the coin is that there's a huge intersecting set of attention-deficit afflicted dabblers who play with a large number of technologies and master none of them. I enjoyed learning programming languages when I was 14. I'm 31 now, and now I like solving actual problems. If I need to learn a new technology to do so, so be it, but there's rarely much joy in such.

I believe you'd find the opposite true if you surveyed more mature fields: master craftsmen tend to be stubborn about the tools they use, but know them inside out.

<comment><USER12> I think software developers would be wise to be a little more flexible. The field is new enough that ideas change all the time. The worst projects I've worked on we're stilted by "we'll bring in a new tech if we need it (but we can always work around needing it)".

Conversely, the second worst projects I've worked on suffer from ADD: "Look, a shiney, new tech. We must embrace it!"

My philosophy is to continually learn new stuff for its own sake (I've focused on languages in the past, but I think it's time to switch to algorithms). I may never use something I've learned, but my tool chest is much more broad (and that Erlang tinkering is coming in handy now!).

I don't think I'm a better developer that a highly-focused compiler writer that knows YACC inside and out. We have different skills for different needs. But I still think the compiler writer would benefit from broadened education.

</comment></comment></comment><comment><USER13> This article screams of: "I dont want to learn CoffeeScript, Don't use it!"

His basis of not having to learn CoffeeScript is that he uses structural js frameworks? Like somehow CoffeeScript prevents you from doing that?

I'm all for sound reasoning showing pitfalls of certain languages - <USER2> despite its wordiness, the article demonstrates a severe lack of. IMO the biggest reason not to use CoffeeScript is the lack of a good debugging experience. Although that's about to get better with soon being able to write source debug symbols in js for transpiled languages.

At the same time the JavaScript language is constantly improving (albeit slowly), which ideally would mitigate the need for CoffeeScript / Dart / etc. But that's not going to be available in mainstream client js programming for years to come. In the meantime feel free to use what language you feel more productive in - and stop trying to impose your personal taste onto others.

</comment><comment><USER14> I really hope that we can finally end the tyranny of Javascript and allow programmer freedom. This is why PNaCl is so exciting -- just send LLVM bytecode which can be executed more directly and efficiently. You can choose whatever language you'd like! Imagine if every server (every. server.) had to run PHP on the backend and Java, Ruby, OCaml, even C just compiled to PHP. You would go insane. We don't have that situation on servers, but we have it on browsers.

It would not be so bad if the underlying language was more direct -- after all, we mostly run on the x86 ABI which is _also_ insane, but much less so. I don't use Javascript that much, but it appears to be a hacked-up version of Self that you need to include weird modules to do anything with?

<comment><USER15> Whoa, JavaScript is so much better then PHP.

<comment><USER14> From what I understand, working in Javascript is by default a terrible situation, and you have to go out of your way to do anything good (hence the plethora of structural frameworks). This is why you never see a book like "C: the good parts" or "Ruby: the good parts." And from my limited knowledge of it, the good parts of Javascript are Self (or, I guess, Coffeescript).

It's like people living near Albany NY who are "so close to Boston, NYC, and Montreal!" Yeah you may be close to "there," but you aren't _there_. I can assure you the people living in Boston, NYC and Montreal are never excited to visit Albany.

<comment><USER16> Working with the Javascript HTML DOM API is a terrible situation, and you have to go out of your way to work around that brokenness to do anything good with the DOM.

Javascript the language, and most libraries/APIs written for Javascript using Javascript idioms, are very pleasant.

<comment><USER9> I 100% agree that the DOM API is a terrible situation. I don't agree that JS is pleasant. When you run a marathon, your legs ache, and that's the DOM API (and all the other concerns of web programming). JS is the little blister on your foot. It hurts too. CS is the vaseline on that little blister. Sure, you still have to run the marathon, and it's gonna suck. But at least the blister is no longer a problem, so you can focus on the bigger issues.

</comment></comment></comment></comment></comment><comment><USER17> As someone who was never completely comfortable with JavaScript, let me say that since I started using CoffeeScript and Jasmine with Guard, I have probably written more js features in two months than ever before.

I understand the point though, but for me it's about shipping, and really: CoffeeScript has made me write a lot more client-side code and make it with confidence, with fewer "wtf" moments.

I'm fairly sure at some point I'll need the help of someone who is really proficient with JS, but the benefits are still so obvious to me I'm really more than ok with it.

EDIT: someone on twitter asked what are recommended resources to learn CoffeeScript - I made a gist of what worked for me here: <https://gist.github.com/1343059>

</comment><comment><USER18> I'm not sure that this conclusion follows nor am I sure that discussions like this accomplish anything. CoffeeScript makes it easier to write "correct" JS and patches an institutional bug: Javascript's development crawls along. Even if it didn't the browser-as-environment handcuffs developers from taking advantage of new language features. (Have you used JS array comprehensions? No, because browser support is spotty, unreliable). And even in the best of development climates -- a thousand genius hackers ardently updating the code base -- these environmental restrictions would persist, drawn over the frame of IE-Mozilla-Google conflict and competition.

So we have languages that compile to JS that let the language evolve. I use CoffeeScript sometimes and JS sometimes. I'm not going to waste the time in the write-compile CoffeeScript loop for 100 lines of JS that I can write correctly. However, I no longer have to work on a 2k LOC, complex JS app without all the niceties of CoffeeScript. Furthermore, if I'm doing something that benefits from the special expressivity of a Lisp, I'll use clojurescript. If I'm very adventurous (and I need to write, say, an H.264 decoder), I'll use emscripten after any language that compiles to LLVM first.

But these are all for different uses, often things you would never have used POJS for anyway. It's not a discussion of plain ol' JS versions of H.264 encoders vs those made originally with Emscripten. It's a discussion of them not existing at all before, and now having the ability to express them and compile to JS. It's not a question of the old enormous apps we built in JS to the new, simpler ones we express in CoffeeScript. It's a question of not being able to build/maintain 5k LOC in POJS across many developers (whereas this task is less substantial in CoffeeScript). Live and let live and everyone benefits.

</comment><comment><USER19> I like having things like list comprehensions. I like having a sane scoping system (as opposed to jsl and "best practices"). I'm also pretty fond of the syntactic sugar being offered (the existential operator in particular).

Coffeescript just gives syntax to common patterns being used in js. For the most part, it feels like a bunch of really nice macros that encapsulate those patterns, making them less error-prone, easier to read, and easier to maintain. I'm not really sure what the concern here is, since most of the post seems to assert that people who use coffeescript don't know js, or that these shortcomings could be addressed equally as well by a large framework system. I can't imagine anyone actually believes the former, and while the latter may be true I don't know why that framework will be so much easier to learn, use, and maintain than the equivalent coffeescript.

</comment><comment><USER20> You can't write a program in C without knowledge of assembly, unless you're willing to defer debugging to someone who does.

You can't write a line of code in any language if you don't know, on some level, what it's doing in the machine (whether physical or virtual). Sure, you _can_ , but you're not a programmer, you're a tinkerer. To really program, you need to know assembly.

But at some scale, your application becomes large enough that no one person, no matter how well they know the assembly it's compiled to, can hold the whole thing in their head at once. At that point, reliably adding a new feature isn't hard, it's _impossible_. There _will_ be side effects you can't predict.

Abstraction isn't there for making hard things easy. It does, and that's nice, but that's not what we need it for. We need it to make impossible things possible.

<comment><USER21> > To really program, you need to know assembly.

That's just an absurdly untrue statement.

<comment><USER22> All abstractions are leaky to some degree. There will be problems you don't understand if you don't know what's happening one layer down. This is not to say there's something wrong with being a tinkerer - but it is saying that there is a difference between a tinkerer and a professional. [http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html) for better writing on this topic.

</comment></comment></comment><comment><USER23> It's a false choice that's been presented many times: Learn CoffeeScript, or learn to do JavaScript _right_.

When I wrote the PragProg book on CoffeeScript (<http://pragprog.com/book/tbcoffee/coffeescript>), my aim from the start was to fill common gaps in JavaScripters' knowledge while introducing them to the new language. Brendan Eich himself said in his blurb for the book: "It helps readers become better JavaScripters in the process of learning CoffeeScript."

Far from distracting people from learning JavaScript properly, CoffeeScript is a terrific learning tool.

</comment><comment><USER15> Seriously, there needs to be something that shows the way to the future. The people working on the next version of ECMAScript look to languages like CoffeeScript as archetypes of the future.

More then anything CoffeeScript shows us what Javascript might look like someday.

We get to actually try out new idioms and see if they work for us. If they don't we have ample time to voice concerns. This is a huge departure from the past.

If anything CoffeeScript will make Javascript better.

</comment><comment><USER24> > CoffeScript Means Giving Up on Javascript

It absolutely does not.

There is one good point from this article :

"Anyone who uses a Javascript library should know Javascript well or they will run into problems with large applications"

The rest of the post is an attempt at instilling a granny-state fear for the Javascript scene.

There will always be people using technology they don't understand. Why are you so concerned about it?

</comment><comment><USER25> As much as I don't like the analogy of JavaScript as the assembly for the web, this feels like a fully general argument against learning any language besides Blub, where Blub is some 'base'.

"C means giving up on x86 assembly."

"If we're already willing to learn both languages and then spend time reading and debugging assembly code, why not just write good assembly code from the start? For the extra effort you'll make learning C and its and its compiler's idiosyncrasies, why not put it towards really learning assembly?"

I'll tell you why. Because while the initial cost of learning CoffeeScript (or my own preference, ClojureScript) may be high, once that barrier is passed the benefits of those languages mean at minimum that you're writing more-likely- to-be-correct code faster. A master C programmer beats a master assembly programmer.

One nice thing about ClojureScript is it lets you hook up a REPL with a browser window which is great for many debugging needs, you can't do that in JS without something like Firebug (which has its own quirks). The interesting note there is that ClojureScript, and I imagine CoffeeScript, are marching steadily toward the place where you don't need to know JS anymore, and learning it is something you only do if you want to.

At one point you did need to know at least some assembly to really do C, especially because you'd have to help the compiler out when it generated stupid code. That age is long gone (except in the microcontroller world but Arduino is making headway on that), many programmers learn C and never learn any assembly. (Not to mention the matter of _which_ assembly.) You might have to learn a bit about computers like the concept of memory and pointers to do C, but those aren't fundamentally assembly features, just like needing to learn about the DOM and browser events in ClojureScript/CoffeeScript isn't a fundamental JavaScript feature. (As anyone who has done anything with RhinoJS knows.)

</comment><comment><USER26> I too was a crotchety old, "get of my javascript lawn", type guy. I thought coffeescript was for lazy developers who just didn't want to write good javascript. Then I decided to use it when I was evaluating a framework, because that framework had chosen to dive fully into coffeescript. All of their examples were cs, so I figured, "what the heck." Even though I didn't stay with that framework, I am so glad I gave cs a try. It has been a huge blessing in rapid development. Having used it for five weeks now, I can definitely sing it's praises. You still need to have a good understanding of javascript, and there are obviously a few gotchas, but it has really changed my who coding experience. I'm in the minority in my office, in that I actually love javascript, but for those who hate it with a passion, introducing them to coffeescript has gotten them on the js train.

</comment><comment><USER27> This is like saying "JRuby is like giving up on Ruby's performance" or "learning Scheme means giving up on Lisp."

If you can write Coffeescript faster and better than you can write Javascript, why _wouldn't_ you write Coffeescript?

<comment><USER28> Posted a response:

Article: [http://paulbjensen.co.uk/blog/2011/11/06/my-response-to- coff...](http://paulbjensen.co.uk/blog/2011/11/06/my-response-to-coffeescript- means-giving-up-on-javascript) HN Link: <http://news.ycombinator.com/item?id=3203181>

</comment></comment><comment><USER29> Everyone who uses CoffeeScript knows JavaScript. CoffeeScript is there for our pleasure.

</comment><comment><USER30> I don't understand atl all his "you have to learn a new language" complaint. If you know JavaScript you'll know CoffeeScript almost instantly.

I "learned" CoffeeScript in, like, half an hour and I'm not even a good programmer.

</comment><comment><USER31> There are a lot of fair points here, but I know personally for me that I was using jQuery for a lot of websites, then saw the beauty of some .coffee files and got into it. Since then, I've cared more about just plain ol' JavaScript and have stopped using frameworks (most of the time).

So while the syntax of CoffeeScript may mean giving up on the syntax of JavaScript, it's brought me closer to vanilla JavaScript and made me more aware of it, without being in the context of a framework like jQuery or Prototype.

Just my two cents...

</comment><comment><USER32> I understand the gravitation for languages that compile to javascript, but personally I've really come to enjoy programming JS. One thing that I don't really get is the fact that most compile-to-js languages are seemingly just switching out the syntax and not actually improving what can be done with the language.

The only useful (as in, I would actually use it) project I've come across in this realm is parenscript (<http://common-lisp.net/project/parenscript/>) which compiles a variant of lisp into javascript. It seems to me the best way to go from language X to JS is to make sure X is actually a better language. From my (admittedly small) experience with CoffeeScript, I haven't really seen much of the benefit, and I tend to _NOT_ like CS syntax. Also, javascript is a superbly powerful language in my experience, and trying to replace it would take some real thought and work.

It seems to me that taking an extremely powerful (and terse) language and compiling it to javascript would be more useful than switching out JS' syntax and adding a few easily-replicable features. Then again, maybe I'm just ignorant.

I don't really see what's to replace, though. JS ain't that bad.

</comment><comment><USER33> We felt also the limits of Javascript especially for bigger projects. As we come from a Java background, we created the STJS project (Strongly-Typed Javascript : <http://st-js.sourceforge.net>). But as the author of the article, we felt that other frameworks doing similar job create a too big gap between the code in the source language and the generated code, so debugging directly in the browser becomes way too complicated. We want so far in our approach to stay as close as possible to Javascript that, for example, we forbid name of variables that are Javascript keywords, but not Java keywords (like var or prototype). What we needed was not to write less code (we don't use Notepad – in Eclipse Ctrl+Space and a lot of code comes from IDE), but to have more help from modern IDE . We do believe in the importance of continually refactoring our code, eliminating dead code, controlling executions paths, things that seem to be unattainable by Javascript or some similar source languages translating to Javascript (Coffescript for example)

</comment><comment><USER34> Let me try a little experiment here:

 _While many of you will probably disagree with me, I find the trend towards writing in languages that compile to machine language somewhat alarming. The most notable of these languages C, and it's one that has gained a good degree of traction over the last year or so.

While I like and applaud the intention of these languages, I question their necessity and worry about the knowledge gap they create. More importantly, they all fail by requiring that you be an expert in two languages. Let's face it, you can't just program C without knowing machine language, unless you're willing to defer debugging to someone who does. If we're already willing to learn both languages and then spend time reading and debugging compiled C, why not just write good machine language from the start? For the extra effort you'll make learning C and its idiosyncrasies, why not put it towards really learning machine language?_

Hmm?

</comment><comment><USER35> I think it's a good tool. It allows you to produce better code faster. Writing CoffeeScript while reading the resulting JavaScript can probably help you to learn "the good parts" faster. (I'm not saying you shouldn't learn JavaScript 'properly', if you need to deliver a significant quantity of it.)

I've been spending a lot of time writing Boo and reading C#. My intention was to put off learning C# for awhile, at least until after I ship my current project. I'm working on finishing my first game with Unity3D (and quickly developed an aversion to UnityScript).

Boo is an absolute joy to use, btw.

The funny thing is that I'm kind of learning C# by accident, by reading it (and the BCL docs) and writing Boo.

Will I at some point switch to C#? I strongly doubt it. Boo allows me to move much faster, produces cleaner, nicer-looking code, and compiles to equivalent CIL. It's all win, as I see it.

</comment><comment><USER36> programming languages are a way of thinking (among other things)

whenever i think in coffeescript i think the same thoughts like i would think in javascript, but in a much cleaner, straightforward, more beautiful, less forward/backward jumping way.

coffeescript is just javascript.

</comment><comment><USER37> I DON'T LIKE CoffeeScript either, it's more Ruby like, why can't people just love JavaScript for what it is. Please read the good parts by Crockford or listen to his talks!

<comment><USER38> it's a big fat "meh" for a lot of people, if you look at the coffeescript source even it looks like complete ass with the exception of the parser, which looks pretty nice and declarative. Some things are certainly nice to have, but those are neither unique nor necessary. The best thing to come out of coffeescript is the glaring "dont use me, I dont understand JavaScript" it places on libraries written with it, I like that.

<comment><USER39> I'm so waiting for your eventual "I was wrong, CoffeeScript is awesome" post. Someday TJ! Someday

</comment></comment></comment><comment><USER40> The compiled Javascript is very sensible. If you want to go back, just delete your coffee files, and you are good to go.

</comment><comment><USER41> Did C mean giving up on assembler? Maybe so. Some people still use assembler but it is good to have a choice.

JavaScript is just an 'ok' language. It has serious warts and it might have been great in 1998, but not now. But we are stuck with it. There are JIT compilers for it, it is on every browser out there so.

</comment><comment><USER42> Oh no, you have to learn two languages. The horror! If you know JS it takes about 10 minutes to learn CS, and all of that 10 minutes is learning about all the typing you don't have to do anymore. function function function function... I'm getting sick of it already.</comment>


This would never convince a real manager, would it? - <AUTHOR> http://www.island.net/~gordon/jmanage.htm A management perspective of the 'J' programming language - Updated 2004
Parts of it read like a lisper's gospel praising macros. <quote>Consider another typical case, the need to fill in a template with data from a record. This might be to create a customer statement or invoice to be mailed, an HTML form to be displayed, or some other such form. Replacing specific character locations on the template by character data from the record can do this. Where the "_" represents the characters to be replaced, code something like the following does the job.
into =: (# i.@#)@:=&'_'@:] }"1
That was the code needed when the original article was written. Now an even shorter equivalent is:
into =: I.@:=&'_'@:]}"1
This is simpler than before and incidentally, it is also faster and requires less space.
With a thing called "Record" containing an ASCII version of the record data with the same number of characters, as there are "_" positions on the character template called "Form". The phrase:
Record into Form
Then yields the desired result of a filled in form. </quote> <comment><AUTHOR> Parts of it read like a lisper's gospel praising macros.

Quote:

Consider another typical case, the need to fill in a template with data from a record. This might be to create a customer statement or invoice to be mailed, an HTML form to be displayed, or some other such form. Replacing specific character locations on the template by character data from the record can do this. Where the "_" represents the characters to be replaced, code something like the following does the job.

into =: (# i.@#)@:=&'_'@:] }"1

That was the code needed when the original article was written. Now an even shorter equivalent is:

into =: I.@:=&'_'@:]}"1

This is simpler than before and incidentally, it is also faster and requires less space.

With a thing called "Record" containing an ASCII version of the record data with the same number of characters, as there are "_" positions on the character template called "Form". The phrase:

Record into Form

Then yields the desired result of a filled in form.

</comment><comment><USER2> "To a manager, the important insight is the very small amount required to achieve a significant result."

I don't think I remember the last time my manager was impressed with how few lines of code solving a problem required. I think managers care more about how quickly a problem is solved, how well the solution works and how easy the code is to maintain.

"If other data manipulation is similarly simple, why should development require such large resources?"

I'm not sure if saving on typing by using few symbols will reduce the amount of time required to build non-trivial applications. The limiting factor most of the time seems to be how fast one can think (and how many tries it takes to get something right). Programming languages can help this by allowing one to think at higher levels of abstractions.

Another problem with developing non-trivial applications is the amount of time required for new people to get up to speed and understand the code base.

While J might be a better language that C for data processing, I can think of many languages far better than C, Basic or Java for the task (like Python). I'd be curious how the article might have been written if it attempted to compare J with Python.</comment>