New research on how mosquitoes find humans to bite - <AUTHOR> https://phys.org/news/2020-02-mosquitoes-humans.html <comment><USER3> I spend much of my time in Florida wetlands, aka swamp. The mosquitoes are perennially surreal on all but the coolest nights and simply bellicose throughout the summer. One can bathe in repellant, but must then wear earplugs to mute the bloodletting frenzy. Imagine exceedingly libidinous and hyper fecund GMO California raisins with fangs, ...on bathsalts and antigravity. Then give them 2-stroke weedwackers and encephalitis. Against my better judgement, I often pray that some rogue scientist will destroy them, earth be damned.

In the meantime, I use picaridin. Picaridin, in contrast to DEET, does not destroy plastics, isn't greasy, and is more effective at preventing the bastards from actually making contact. DEET, is more effective at preventing bites - but not contact. I prefer to remain less molested while incurring a few bites rather than function as a mosquito stadium. Other than deet and picaridin, nothing works. Ultrasound, lights, oils, permethrin, gasses - <USER2> are useless for me. My type comprises a potential gold mine for anyone who discovers an eco-friendly, dry, more effective solution. Please do!

<comment><USER4> Neem oil works 100% (and is a single-source natural plant oil), but it's a smelly oil (strong nutty smell) and, being oil, means you have to get all slicky in order to be effective.

With neem, they may fly around you, but they never land on you. They hate its smell, and also, the oil's compound kills them / makes them and all other small insects sterile.

So yeah if you're wearing clothes then they have to be ones you're prepared to get oil on and then wash it out using hot water and baking soda or whatever.

<comment><USER5> Burning neem-tree [0] leaves is in regular practice in most non-urban Indian neighborhoods, to stave off insects and flies, including mosquitoes. Not sure how effective it is, though.

I must point out that Wikipedia has a page on neem oil and warns of toxicity if consumed raw [1].

[0] [https://en.wikipedia.org/wiki/Azadirachta_indica](https://en.wikipedia.org/wiki/Azadirachta_indica)

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

</comment></comment></comment><comment><USER6> Do mosquitos have a predator? Are there birds that feed on them for example?

<comment><USER7> Bats are one.

<comment><USER8> Bats can carry rabies, but overall mosquitos are a lot more dangerous. I'll take the bats any day.

</comment></comment></comment><comment><USER9> Veritasium had an episode on the topic: [https://youtu.be/38gVZgE39K8](https://youtu.be/38gVZgE39K8)

</comment><comment> alok-g If something hot is placed in the room, mosquitoes should have a preference for that over the humans. Why would such a simple set up to avoid mosquito bites would not work (I do not think it does)? Genuinely looking to enhance my understanding.

</comment><comment><USER10> This is one of those topics where people should really learn from human history rather than jump to conclusions because they sound good at first thought:

 _The Four Pests Campaign, was one of the first actions taken in the Great Leap Forward in China from 1958 to 1962. The four pests to be eliminated were rats, flies, mosquitoes, and sparrows....[The resulting] ecological imbalance is credited with exacerbating the Great Chinese Famine, in which 15–45 million people died of starvation._ [1]

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

<comment><USER11> The full quote (and the rest of the article), when including the parts you omitted, implies that it was the campaign against sparrows, not mosquitos, that was the main problem:

> The four pests to be eliminated were rats, flies, mosquitoes, and sparrows. > The extermination of sparrows is also known as Smash Sparrows Campaign > (Chinese: 打麻雀运动; pinyin: Dǎ Máquè Yùndòng) or Eliminate Sparrows Campaign > (Chinese: 消灭麻雀运动; pinyin: Xiāomiè Máquè Yùndòng), which resulted in severe > ecological imbalance, being one of the causes of the Great Chinese Famine. > In 1960, Mao Zedong ended the campaign against sparrows and redirected the > fourth focus to bed bugs.

There's no suggestion in the article you referenced that attempting to eliminate mosquitos had anything to do with the famine.

<comment><USER12> >There's no suggestion in the article you referenced that attempting to eliminate mosquitos had anything to do with the famine.

Not directly, but assuming that what humans regard as pests don't have a function in the ecosystem, so I'd say his point is valid. Mess with the ecosystem in an extreme way and you might suffer dire consequences.

<comment><USER10> > Mess with the ecosystem in an extreme way and you might suffer dire > consequences.

This was exactly my main point.

Apparently the elimination of sparrows also led to a dramatic increase in mosquitos (since sparrows eat mosquitoes), so it had a domino effect of negative impacts. They didn't have the technology to obliterate mosquitoes at the time, and that's essentially what we're talking about here...so I'm saying there will likely be unforeseen consequences if people mess with this. (coming from a guy who hates mosquitoes - i actually bought mosquito pants last year bc they are so bad in the summer when I'm doing yard work)

</comment></comment></comment></comment><comment><USER13> So how do we use this information? Personal cooling vests? Or are they advocating an IR21 genetic inhibitor protocol?

</comment><comment><USER14> That's nice. But how do we kill them all? Whatever happened to that experiment with using CRISPR to make them sterile?

<comment><USER15> This seems like a phenomenally bad idea.

Many areas of rainforest are only protected against illegal logging operations because they are dense with malarial mosquitos.

<comment><USER14> Protecting the rainforest is fine, but relying on loggers being scared of mosquitoes isn't an effective way to do it. What if they find good repellents? Or start spraying the forest before logging? We can kill the mosquitoes and work to save the forest, they're not exclusive.

<comment><USER15> Yes - the mosquitos may one day not be effective in protecting the rainforest.

You are saying we should make that happen as soon as possible.

Killing the mosquitos is not exclusive with working to save the forest only if you have another way to save the forest.

Nothing has been able to prevent the illegal logging except mosquitoes. What is your suggestion?

</comment></comment></comment></comment><comment><USER16> Mosquito larvae are very important in aquatic ecology (1). While they are annoying as F they are important to our overall ecosystem.

Bees sting and kill people each year but no one would ever attempt to sterilize all of the bees. They are different, yes, but each play an important part on our planet.

(1) [https://www.google.com/amp/s/io9.gizmodo.com/what-if- every-m...](https://www.google.com/amp/s/io9.gizmodo.com/what-if-every- mosquito-on-earth-went-extinct-tomorrow-1646840383/amp)

<comment><USER17> You can disrupt ecosystems without ending the world ("life finds a way").

The logic in your linked article is a bit specious; certain species eat mosquito larvae, so without mosquitoes they won't have food, and the species eating them won't have food, and so on. But nothing is actually static, there would be some dynamic adjustment (arguably, hard to predict). Species will find something else to snack on.

In fact you could argue that those species eating mosquito larvae are detrimental to mosquitoes! Maybe they're preventing something else from happening by eating them before they develop.

<comment><USER18> Yeah I'm sure it's totally fine disrupting an entire ecosystem

[http://www.bbc.com/earth/story/20170516-when-wolves- return-t...](http://www.bbc.com/earth/story/20170516-when-wolves-return-to- the-wild-everything-changes)

[https://www.gorgeouscreatures.com.au/blogs/news/the- history-...](https://www.gorgeouscreatures.com.au/blogs/news/the-history-of- possums-in-new-zealand)

[https://en.m.wikipedia.org/wiki/Gorse_in_New_Zealand](https://en.m.wikipedia.org/wiki/Gorse_in_New_Zealand)

<comment><USER11> I'm a Kiwi, and whether gorse is a problem is a matter of perspective. It's not causing any harm to almost anyone at all. It's not what's native, so people don't like it - that's fine, but it's mostly aesthetics at the end of the day. I love our native plants and birds, but I also think gorse is really pretty when it's all in flower.

But that's not the point: gorse in NZ is not even slightly comparable to mosquito-borne illnesses. No-one ever died because of gorse in New Zealand. According to Unicef malaria kills 1,000,000 people every year. This is something we might want to disrupt.

<comment><USER19> In NZ, gorse is actually a fairly good nursery for native trees/bush that will eventually shade it out and take over from it. The main problem gorse caused was taking over grassy farmland.

Pine trees are another matter though, they make it very difficult for native plants.</comment></comment></comment></comment></comment>


Printing only what you like (Format any web page for printing) - <AUTHOR> http://www.printwhatyoulike.com/ <comment><USER2> Not that this isn't awesome or anything, but this is a hack for so people can print over poor designers. A print media CSS file should be included to clear all the garbage so that printing will only show what you want.

See: <http://www.w3.org/TR/CSS2/media.html#media-types>

<comment><USER3> It would be great if every site offered a printer-friendly view. The web would be so much more usable. But I also believe the ultimate authority on how a page looks and prints should be you. What if company policies force designers to include ink-draining advertisements on the printer-friendly version ( _cough_ cnn.com _cough_ )? What if you don't like the font a page uses, or only want to print part of the page, or want to merge multiple pages into one print job? A printer-friendly stylesheet won't do that for you, but PrintWhatYouLike will. I totally agree that PrintWhatYouLike will mostly be used to get around poorly designed sites, but print stylesheets are only part of the solution. The other part of the solutions is giving you the ability to take a designers page and customize it to suit your own unique needs.

</comment></comment><comment><USER4> This is really well done. Finally no more wasted paper with sidebars and footers on them...

Also, font changing is excellent. Trebuchet MT isn't easy on the eyes.

</comment><comment><USER5> It's also interesting that printwhatyoulike.com runs on Google's App Engine. (See [http://googleappengine.blogspot.com/2008/10/app-engine- commu...](http://googleappengine.blogspot.com/2008/10/app-engine-community- update.html))

<comment><USER6> yeah, this (currently printwhatyoulike's front page) "This Google App Engine application is temporarily over its serving quota. Please try again later." isn't exactly a great advertisement for the service

<comment><USER5> I'm surprised they didn't lift the quotas for printwhatyoulike, given they advertised it on the App Engine blog. Still, the "preview" status of App Engine is well known. If you don't want to worry about quotas, either wait until they allow payment, get them to significantly up your quota before you go public, or deploy on another system for now.

<comment><USER3> Aargh. I thought the over quota issues had been fixed :-( GAE is a great service, and it makes deploying and hosting an application dead simple, but how it actually works is a big mystery. GAE doesn't give any indication that your application is at or near the limit of a quota. Even now, while PrintWhatYouLike is giving over quota errors, the GAE dashboard for PrintWhatYouLike says that everything is a-ok. DocSavage, I wish I would have taken your advice a few weeks ago:)

</comment></comment></comment></comment><comment><USER7> This is great for those of us who print PG's essays. Now the column can fill the whole page, meaning less whitespace.

</comment><comment><USER8> Nice service. It was only yesterday that I was copy/pasting into word to print some slides.

</comment><comment><USER3> Thanks everyone for the fantastic suggestions!!! The inspiration for the site actually came from wanting a way to print pg's essays without wasting so much paper. If you find any bugs or can't believe we left out your favorite feature, please post it here or contact me at firstname.lastname@example.com.

</comment><comment><USER9> I wish I had this years ago. But now? The only things I print have an optimized print version (maps, boarding passes, etc). I can't remember the last time I experienced this problem...

<comment><USER10> I don't know about you, but when learning a new topic, I find it easier to print the content I want to read, and highlight it old-skool style with a highlighter. It helps me for reading comprehension, later referencing, and those off line meetings where you want to show something quickly out of your printed notes.

<comment><USER9> I can see the value in that, but I prefer a quantity over quality approach. When learning a new topic, I read as many materials about it as I possibly can. I don't worry too much about grasping it fully right away. I'll just survey as much land as possible. In the end, I have a much broader appreciation for a topic and have crystalized a far more sophisticated view of it. I also find that when I return to the earlier materials I read, they are much easier to understand.

I don't have time to print things...

</comment></comment></comment><comment><USER11> Design suggestion: On the print page the menu on left to Remove Background, Remove Images... and etc, all have different sizes (width). I think this makes your site to look unprofessional. I suggest to use the same width.

<comment><USER3> Thanks! This change will appear in the next release.

</comment></comment><comment><USER12> May i have "Save" button + unique url for every page i edit please?

</comment><comment><USER13> I find it hard to figure out some modern web startups, but this works well and it's easy to use. I'll be using it in future.

</comment><comment><USER14> Similar to Aardvark, a Firefox extension

<comment><USER3> Both Aardvark and Nuke Anything are super cool tools, and I stole a lot of ideas from them while creating PrintWhatYouLike. But PrintWhatYouLike also adds a whole bunch of new stuff no other service offers. Here are a few of the new features:

* pwyl is a webapp so you don't need to customize or install anything and you aren't tied to any particular browser

* merge pages together - you can combine multiple pages together into one page, and print them as one document. Your changes from the first page are automatically applied to any additional pages.

* pwyl is easy to use - there is a full toolbar, and you can see what you have selected. With Aardvark you have to memorize keyboard commands

* extra features like change text size, font, remove images.

</comment></comment><comment><USER15> Looks like Clipmarks but instead of bookmarking/blogging it's for printing.

</comment><comment><USER16> useful stuff - plugins for wordpress, drupal etc. might be useful for distribution

</comment><comment><USER17> This should be part of Firefox

</comment><comment><USER18> That might be a more userfriendly way of doing it, but my favourite way of dealing with pages like that is using Platypus with Greasemonkey to edit pages on the fly.

<https://addons.mozilla.org/en-US/firefox/addon/737></comment>


Google, Amazon topping Microsoft in pay for engineers - <AUTHOR> http://techflash.com/seattle/2010/04/study_google_amazon_now_tops_in_pay_for_software_engineers.html#disqus_thread <comment><USER2> As an insider I think those numbers also include bonuses for Microsoft numbers at least. And being on the inside we are told we are paid on average more than industry. That may be true at face value but I really think we need to compare ourselves like this post does: to those we directly compete with.

But money is silly. The best thing MS can do is create an environment in which Senior Developers don't leave. But the only way MS knows how to do that is with $$$. Which is not sustainable.

<comment><USER3> It certainly isn't the only way to keep developers, but I don't see how it's unsustainable. The nature of software development is such that huge margins are possible, and the productivity of a really good Engineer is that of many, many mediocre Engineers.

I remember last time I was working for a large corp, there was this one guy on the team who was really, incredibly good. Easily worth 5x me, in terms of work done. He made 20% more than I did. There was another guy who was probably closer to 1/5th my productivity. He made maybe 20% less than I did.

the thing is, determining productivity is difficult; but I think even allowing for a high margin of error, you could sustainably target only the best, and pay twice what the competition does.

<comment><USER2> What I meant by unsustainable is that I feel the retaining talent problem is less related to money. My guess is smart people are leaving mostly because of the environment and not because of pay and benefits. When those smart people leave, theoretically the quality of the product suffers and overtime the competitor with better people wins. If MS profits go down over time, and investing in things like Azure and Bing and Entertainment (all which loose money), I don't see how they can continue to throw money at the talent problem. But man if I could get paid more AND work in a better environment (one where I had an impact) I would go for it in a heart beat. So in that sense money DOES matter. I agree with the rest of what you said though about it being difficult to measure.

This is what I think of when the subject is talented people leaving MS: [http://www.techflash.com/seattle/2008/12/Key_data_center_arc...](http://www.techflash.com/seattle/2008/12/Key_data_center_architect_leaves_Microsoft_for_Amazon36057114.html)

[http://googletesting.blogspot.com/2009/06/james-whittaker- jo...](http://googletesting.blogspot.com/2009/06/james-whittaker-joins- google.html)

I think Amazon and Google are better because of it.

<comment><USER3> I agree with you that money isn't everything, and money, if it's just a little, like 10% or something probably doesn't matter much at all for the vast majority of the people.

I do wonder, though, what would happen if microsoft decided to start offering top search engineers from google twice what they are currently getting.

<comment><USER2> I think they would stay at Google (in its current state). Google is getting big but is still not as big as Microsoft (political). Google has more data (I would imagine that is something search folks want more of). Google seems to be the best environment for top search engineers for a variety of reason. My guess is that the top search folks (along with others in the top of their field) get to choose where they work and what they get paid because they are at the top of their game. So if Microsoft is where they wanted to be they would already be here. If it is where they want to be and they are not shame on us for not recognizing that.

<comment><USER3> maybe you are right; but personally, one of the big reasons I started my own business was that I saw really, really good people only made 20%-50% more than absolute mediocres, when they were 10-20 times more productive.

If it were possible to make big bucks without starting your own company would I have continued to work for others? maybe.

The thing is, some people say "Once I have enough, it doesn't matter" and certainly, the $100K/year that your average bay area computer person makes is 'enough' to live on... but double that and you will be able to retire in less than half the time. Retire and work on your own terms, if you like.

For me, that is what getting more money is about. I don't really care about having a nicer car or anything, but it sure would be nice to be able to, say, take a year off and travel, and not worry about what employers would think about the year-long gap in my resume.

</comment></comment></comment></comment></comment></comment><comment><USER4> The Seattle to MountainView comparison is interesting between Google and Microsoft. Consdiering 12% CA income tax, Microsoft pay is higher.

But from experience, Seattle Google and SVC Microsoft are both lower base than the motherships. So the results of the city level comparison can be explained by this factor.

<comment><USER5> Also, the cost of living in the Bay Area is significantly higher than Seattle; housing alone is a huge factor. Google employees are really paid peanuts compared to Microsoft's:

<http://www.city-data.com/city/Seattle-Washington.html>

      Estimated median house or condo value in 2008: $491,600 (it was $252,100 in 2000)
      Seattle: 	 $491,600
      Washington: 	 $308,100

      Dec. 2009 cost of living index in Seattle: 126.5 (high, U.S. average is 100)

<http://www.city-data.com/city/Mountain-View-California.html>

      Estimated median house or condo value in 2008: $755,200 (it was $464,800 in 2000)
      Mountain View:  $755,200
      California: 	 $467,000

      Dec. 2009 cost of living index in Mountain View: 164.0 (very high, U.S. average is 100)

Raw dollars, glassdoor says google pays more. Regionally adjusted, there's a lot more that raw dollars can't account for.

</comment></comment><comment><USER6> Please link to the article, not to the comments on the article. It's annoying to start halfway down the page.

<comment><USER7> It might be useful for the article submission page to ask you "Are you sure you're not accidentally linking to the comments section of an article?" when it detects an #anchor in the URL.

</comment></comment><comment><USER8> I get paid just a little below their averages and I'm not quite the calibre of a Google/MS/Amazon developer. Plus I'm on the east coast in NC where the CoL is definitely cheaper.

<comment><USER2> Google/MS/Amazon do have some VERY smart developers. But there are dolts too at the big ones. The fact that you realize there are better developers than you puts you above most. A lot at MS think that because they work at MS they are the best thing in the world for software.

</comment></comment><comment><USER9> Could this be because Google and Amazon promote faster? I ask because my Microsoft offer out of college was more.

<comment><USER10> Microsoft promotes faster than Amazon since Microsoft uses an internal numerical rating score that can potentially improve each review cycle.

Also, the offers I heard about (from a few years ago) from both companies were comparable with respect to base salary, with negligible differences. However, Amazon's stock-based compensation offers blew Microsoft's (laughable) offer out of the water.

<comment><USER11> You say "stock-based compensation", I hear "golden handcuffs".

<comment><USER3> You say "golden handcuffs" and I hear "an employee who doesn't plan on sticking around"

The point of golden handcuffs really is just that; you stick around a while and we'll give you a little extra.

(My problem with golden handcuffs is that most deals I've seen as an Engineer were pathetically small. The employer seemed to be unaware that I can buy stock options on the open market.)

</comment></comment></comment></comment><comment><USER12> How do the software companies compare to developer positions in other industries? I am pretty happy with my compensation at a bank :)

<comment><USER13> In most industries, expect to get less than the software industry as a software engineer. Software is just a lot more important to, say, Microsoft's business than it is at BOC Gases, and they pay proportionately well.

However, that's not necessarily true in every industry, and some industries can pay a premium just because they have good profits and want the best engineers. I wouldn't be surprised if banks paid better on average than the software industry.</comment></comment>


Ask HN:  Anyone using Haskell in production? - <AUTHOR> If so, what projects/products?  I'm curious to know what jobs you found that Haskell was awesome for and other languages couldn't keep up. <comment><USER2> I am using a Haskell/C combo for a distributed (on a "supercomputing" cluster) Machine Learning (commercial, non academic) project. About 20k lines of Haskell. A couple of 100K lines of C (Most of this will be moved to Haskell over time). Works like a charm.

As to why Haskell, I have not yet found any other language that combines its expressiveness and raw speed.

<comment><USER3> While kind of you to share this datapoint, the fact that there are 5 times more lines of C than Haskell is a bit less than compelling. Especially considering the fact that Haskell can achieve c-like performance (ie: not necessarily a glue language).

Good on you for using it in production though, that's more than most of us have achieved, I'm sure.

<comment><USER2> "While kind of you to share this datapoint, the fact that there are 5 times more lines of C than Haskell is a bit less than compelling"

Legacy Code (almost 10 - not 5 - times as much C than Haskell). Can't transform it instantly, much as I would like to. (I did explicitly state that most of this is being moved to Haskell).

Why should a pre existing code base preclude the use of Haskell in production and be "not compelling"? I don't get it. But hey if it helps there's even a few thousand lines of Fortran in there (accessed through a C interface). Even less compelling now? ;-)

Fwiw, The 20,000 lines of Haskell would be (at least) equivalent to another 100,000 lines of code in C. So at least 1/3 d of my project is in Haskell. And the ratio is increasing everyday. The OP asked for examples of using Haskell in production. I _am_ using Haskell in production. I didn't see any "purity constraints" in the OP's question. But maybe they were implicit who knows. I am just throwing out what I do with Haskell.

If you find it "less than compelling", that's fine. My clients (the users of the system) are delighted. Good enough for me!

<comment><USER4> Thanks for explaining. I guess rbxbx was just curious, and did not think about the possibility of legacy code.

</comment></comment></comment></comment><comment><USER5> I wrote a pure Haskell solution that implements a messaging middleware from a proprietary legacy DB system to a network for activating mobile devices.

It was my first real Haskell project, and although I had lots and lots of book knowledge about the language, the outcome was quite warty. Nevertheless, Haskell delivered what it promised: the software was completed much faster than a roughly comparable C product was before (by a better programmer than me) and making changes to a finished product was very easy and safe and did not cause new bugs.

Perhaps the worst problem was the lack of quality libraries for doing some practical things, such as simple socket listening (I had to pretty much code Haskell like it was C in that part), and I had some trouble (bad memory leaks) from the curl library.

And even worser than worst was the problem that only one person got interested enough in the language that he helped me with the project, and, although he was able to produce working code in a month from zero experience, he ended up disliking the language.

</comment><comment><USER6> Well-Typed, a Haskell consultancy, seems to do quite a bit of work exclusively in Haskell.

For instance, they have developed an air traffic analysis tool for NATS[1] which they briefly blogged[2] about.

[1] <http://www.nats.co.uk/>

[2] <http://www.well-typed.com/blog/39>

</comment><comment><USER7> I used Haskell on my every job last 12 years to quickly prototype various things to get problems exposed early.

This included: prototypes of image analyses (image registration), MIPS-alike CPU prototype, Direct3D pixel/vertex shader assembler language analysis (data flow patterns), prototyping various dynamic data flow CPUs, translator Fortran-to-Lisp (for our colleague who prototyped compiler analysis in Lisp), testbed for viodecontroller, VHDL-to-netlist translator (synthesable subset) for our modeling system, simple GUI for some kind of IDE for modeling system, DSeL for CPU model description.

I even tried to create integrator for "game physics" using infinite lazy lists using ideas from [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.4...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.4535)

Most of my pet projects start as a Haskell source. Often they get abandoned, sometimes they evolve into something big.

This "pettiness" of Haskell projects play an important role: they can be thrown away because they are cheap, and they can evolve into something pretty big - easily.

</comment><comment><USER8> <http://www.galois.com/>

</comment><comment><USER4> Citrix is using Haskell for XenClient. Drop me an email, if you want to know more. My team at Citrix is using OCaml for XenServer. Both teams are in Cambridge, UK.

We are looking for people.

</comment><comment><USER9> Barclays Capital uses Haskell to describe equity derivative instrument payoffs: <http://lambda-the-ultimate.org/node/3331>

</comment><comment><USER10> Here is the section on commercial users from the most recent Haskell communities report: [http://haskell.org/communities/05-2010/html/report.html#sect...](http://haskell.org/communities/05-2010/html/report.html#sect7)

</comment><comment><USER11> My co-founder uses it for scripting and we do a little data manipulation on our game dev toolchain with it.

We were planning to use it a lot for a server-side code, but as my Haskell is rusty, we decided to go mainly with Python.

</comment><comment><USER12> I think jrockway is if he wants to comment. Financial services seem like one of the few industries that can get away with it.

<comment><USER13> what is there to get away with?

<comment> loup-vaillant Lack of training and lack of awareness. Here at work (in France), probably less than 3% of programmers ever used Haskell or ML. Less than 10% knows they even exist. And no-one would be willing to train a team so these languages can be used in a new project.

Now, financial software may get away with those because they don't really have a choice: they are a narrow field, with a critical need for correctness.

Conversely, you could say that most projects get away with ignorance. They use sub-optimal languages, for the very short term benefit of not training people.

<comment><USER14> I'm shocked, shocked to hear there's such little ML going on in France. After discovering OCaml and its progenitor INRIA, I've always just assumed that MLs and functional programming was more of a European thing, especially since they're more oriented toward proofs and program correctness, which I also thought was more a characteristic of European CS and software engineering. But no?

<comment><USER15> One workplace != France != Europe

<comment> loup-vaillant 2 workplaces plus a good deal of acquaintances, in fact. In my niche (custom technical or scientific software, mostly for the government), I'm 99% confident that ML makes less than 0.1% of currently written code. 80% of my colleagues even never heard of ML.

</comment></comment></comment></comment></comment></comment><comment><USER16> My site isn't production ready yet, but I'm writing my back-end in Haskell. It's exposing a REST API via HappStack to the RoR front-ends.

What stops me from using Haskell for the front end is that I'm familiar with RoR (and so my prototyping is fast) and I haven't been amazed by any of the templating systems in Haskell yet.

</comment><comment><USER17> I am using Haskell to simulate data for a machine learning system. The project has other components we are planning to implement in Haskell.

You may fight hard with the compiler to get your program to compile, but after that "it just works". Also functional programs are bite-sized, so making changes feels easier.

</comment><comment><USER18> See also: [http://haskell.org/haskellwiki/Haskell_in_industry#Haskell_i...](http://haskell.org/haskellwiki/Haskell_in_industry#Haskell_in_Industry)

</comment><comment><USER19> Dammit... Avoid success at all costs?</comment>


Cicada, a Rust chess engine - <AUTHOR> https://github.com/mkyl/cicada <comment><USER2> I would like to see theory.md which is referenced in the comment in board.rs but i dont see it in the repo.

<comment><AUTHOR> Frankly that file is just the layout of the board, as in which ints correspond to which squares. I used it at the very start to make sure the pieces where moving correctly, before the code to connect to an interface was written.</comment></comment>


'Am I in the bad part of town?' Tourists shocked by what they see on SF streets - <AUTHOR> https://www.sfgate.com/local/article/is-san-francisco-dangerous-visit-sf-safe-crime-12995294.php <comment><USER2> Thanks to Reagan for not understanding or caring about compassion; just another celebrity whom guts systems they don't understand because an issue doesn't affect them.

[https://www.salon.com/2013/09/29/ronald_reagans_shameful_leg...](https://www.salon.com/2013/09/29/ronald_reagans_shameful_legacy_violence_the_homeless_mental_illness/)</comment>


Breath of the Wild has a metacritic score of 98 - <AUTHOR> http://www.metacritic.com/game/switch/the-legend-of-zelda-breath-of-the-wild <comment><AUTHOR> At the time of posting, there have already been 56 reviews factored into the score and it has definitely stabilized.

A score of 98 means the only game with a higher metacritic is The Legend of Zelda: Ocarina of Time, with 99.</comment>


The big advantage of the Chromebook over Windows, Macs - <AUTHOR> http://www.zdnet.com/the-big-advantage-of-the-chromebook-over-windows-macs-7000032585/

<comment><USER2> There was no evidence presented to defend the authors claim. Things like this were prevalent:

The lack of a "real" OS as the engine behind the Chrome browser is actually a good thing for me. My Chromebook runs Chrome faster, smoother, and without hiccups, better than my fast Macs and Windows PCs.

I call bullshit on this, and he should be showing us some benchmarks or something to give this argument any legitimacy.

Edit: I am not sure how to quote things here. So I made some attempts in this post to make the formatting obvious that the words after the colon are not mine.

<comment><USER3> Surround the quote with asterisks.

[https://news.ycombinator.com/formatdoc](https://news.ycombinator.com/formatdoc)

</comment></comment><comment><USER4> Too bad Sundar Pichai intends to ruin that whole "advantage" (and also the security one) by introducing Android apps into ChromeOS, instead of creating a use case based UI (taskbar, Android apps within windows) for Android, like they have for TVs, cars, and wearables, and then use _that_ as a more "full featured" OS (which Android already is compared to ChromeOS).</comment>


Queues are Databases (1995) - <AUTHOR> https://arxiv.org/abs/cs/0701158 <comment><USER2> One of the issues with modelling queue semantics over a database is performance. All that locking, key lookups and mutating of B trees is expensive.

The latest generation of durable messaging systems that offer queue semantics do so by modelling those semantics over a distributed, replicated log, such as Apache Pulsar and RabbitMQ's new replicated queue type called Quorum Queues.

A queue is different to a log in that reading from a queue is destructive, but reading from a log is not. So if I have two applications (shipping and auditing) that want a queue with all the shipping orders in, then each needs their own queue - so they don't compete over the messages. Whereas a log can be read by both, but both need to track their independent position in the log.

Apache Pulsar offers queue semantics to shipping and auditing by storing the shipping orders in one distributed log (a topic) and creating two separate subscriptions (also logs) that track the position (like Kafka consumer offsets). The destructive read of a queue is simulated by advancing the cursor (offset) of the subscription. The performance improvement this append-only log data structure offers compared to a mutable B-tree of the RBDMS is massive.

Quorum queues do it a different way, but still modelling queue semantics over a log.

Of course some future RDBMS storage backend wouldn't have to use B-trees and read_past locking etc, it could also use a log based data structure for message storage too.

<comment><USER3> Not all databases are relational. Not all relational databases are built on b-trees.

From the summary:

> Many people are building queue managers on file systems as a transactional > resource manager and a TP-lite monitor. An alternative approach is to evolve > an Object-Relational database system to support the mechanisms needed to > build a queuing system

The key word here is evolve.

The point is to think of a queuing system in the database as a concept sense, rather than the database as a specific implementation sense.

</comment></comment><comment><USER4> Websphere MQ has had DB2 as a dependency for ages. Not by accident.

OTOH as a sysadmin I hate when developers use queueing systems as databases. It's like keeping full courier vans circling around the city instead of having a warehouse. Messaging systems are pipes, not water towers. It makes monitoring difficult, makes browsing and modifying data difficult, and administration difficult. They may be sides of the same coin, but that doesn't mean you have to use only a side of it.

<comment><USER5> In the 90s, I worked in a little electronics shop where the owner had a "creative" scheme going. He would order all sorts of stock (cameras, computers, radios, etc) via cash-on-delivery (COD), but then he had a deal with the UPS man.

The UPS man would just keep all the goods in his truck for weeks and weeks. Then whenever we had a customer at the store who wanted to buy a given model of camera or whatever it was, I would be "dispatched to the stock room", aka, I would go out the back with cash in hand, get a money order from the post office next door, find the UPS truck (his turf was just a few city blocks), and then triumphantly come back with the item for the customer.

It usually worked well enough, but occasionally failed in unpredictable ways and sometimes spectacular ways. Like using a queue as a db -- that's not really how any of that was meant to work...

</comment></comment><comment><USER6> This is like saying "Prisons are Buildings". Yes they are. So what?

EDIT: Never mind, this paper is brilliant. EDIT2: Here's the point for my own future reference: to make a good Queue, you need a pile of parts. A reasonable construction plan for those parts is to assemble them into a Database, and throw a Queue thingy on top. This is the best way to build a Queue, because then you can use the good Database for other things too. This sort of happened and was called Redis.

</comment><comment><USER7> And we are still having this discussion in 2020 with Kafka [1].

A DBMS is one thing, but data platform components are something else.

And I think this is good, actually - IMHO the ability to use unbundled components of a "database" for different purposes has been huge. A distributed processing query engine - Apache Spark. A distributed "transaction log" that acts like a queue and can handle real time streaming and permanent storage - Kafka. Distributed file storage - HDFS. Efficient storage and open file formats for compressed data - Parquet for columnar data.. Snappy compression, ORC, etc.. etc..

As a result, we have tools that represent the unbundled components, and we still have traditional monolithic DBMS. And we still have queues that are transient (ex. nanomsg or ZMQ). They can and do coexist and this is good. We have lots of tools in the chest for different jobs, it's great!

[1] [https://dzone.com/articles/is-apache-kafka-a-database- the-20...](https://dzone.com/articles/is-apache-kafka-a-database- the-2020-update)

<comment><USER8> If in 2020 you still choose Kafka as your messaging infrastructure, you are well behind the times.

I get it, I really do. Your manager has heard of Kafka, as has your PM and CTO. Nobody has ever fired for buying Kafka. It's the new IBM.

"Buying Kafka? It's open source, so it's free!" you say, my naïve friend who hasn't heard of Confluent.

Yes, Kafka is free until you go to production and need things like mirror maker, for multi-site replication. Then it's time to pay up to the company that has taken over and monetized the project.

But its a pain to run, a pain to debug, uses avro as a binary schema, because everyone uses avro, right? And partitions are great! Until you need to change them and then you're in for a world of strange and potentially unnoticed bugs from a discontinuity in partitioning as the topic grows.

Or... you could have Pulsar. Dynamic partitioning, more expressive subscription models, multi-active as part of the core product. No BS marketing claiming "exactly once delivery semantics", aka more than once with receiver side deduplication, aka what TCP does and has always done.

There is no reason to be building something new on top of Kafka in 2020.

<comment><USER9> Wow, now pulsar as well. As someone who isn't full-time trying to keep up with this tsunami of names it's just impossible to keep up. Apache (or someone, anyone please) needs to make a matrix of all their own competing technologies and what the actual differences are between them. It's just impossible!

<comment><USER8> I feel ya. Software is a world that's constantly evolving.

Apache is great at software engineering, but sorely lacking in product design. Because open source software is almost definitionally not a product, but a tool.

With that comes increased bifurcation of the tooling when different requirements arise, and increased complexity with running it. Kafka and pulsar both have zookeeper as an external dependency, for instance. Pulsar has an extra dependency even in bookkeeper, one of the few things I'll readily fault it for. It's a stark contrast to openly commercial products like CockroachDB, which has a single static binary, with symmetric nodes, and built in management UI. It's a product, not a tool.

FWIW, Apache has a project directory - [https://projects.apache.org/projects.html](https://projects.apache.org/projects.html)

But it's a far cry from a comparison matrix as you (and I think many other confused and disheartened engineers) desire.

<comment><USER10> It's not due to bifurcation.

It's because Apache "adopts" products that are created independently by other companies who then want to open source their product, and leave to it someone else to look after.

Kafka was created at LinkedIn and eventually donated to Apache Foundation.

Pulsar was created at Yahoo and eventually donated to Apache Foundation.

</comment></comment></comment></comment></comment><comment><USER11> I really look forward to seeing what can be done with Postgres's pluggable storage backends that were recently added. It seems that some of the issues with treating a table as a queue could be mitigated with special storage backends designed for such a job.

<comment><USER12> FWIW, you already can use postgres' logical decoding / change data capture to make queuing more efficient. Depending on what you need.

If it's the type of queue that various consumers need to see in their entirety, then you can just use pg_logical_emit_message(transactional bool, prefix text, payload data/bytea) to emit messages , which logical decoding consumers then see either in time order (transactional = false) or in commit order (transactional = true).

If it's more the the job type of queue where exactly one subscriber is allowed to see a message it's a bit more complicated, but using logical decoding will probably still be more efficient than querying a queue table with ORDER BY etc.

Being able to do queue submissions as part of a transaction (i.e. queue submissions will only be visible after commit) can be really useful to integrate with external systems.

<comment><USER13> You could use logical replication for queuing but there are a lot of footguns. It's far from a general purpose queue. For a handful of consumers, fine, but you'll have trouble scaling this to hundreds or thousands of consumers, which other queues solve for handily.

</comment></comment></comment><comment><USER14> For the modern 2019 take: [https://youtu.be/05mVvkp6f2M](https://youtu.be/05mVvkp6f2M)

<comment><USER15> This sent me down a very informative rabbit hole, thank you.

<comment><USER14> You are most welcome.

</comment></comment></comment><comment><USER16> Recent work from Berkeley on AnnaDB and Martin Kleppman's OLEP stuff is a complete opposite of this idea. Something along the lines of - databases are just a queue topology with synchronization.

Queues do definitely seem like a more fundamental primitive.

<comment><USER16> Just to clarify slapping a queue on a database is still a bad idea IMO

</comment></comment><comment><USER17> I've done queuing using in-memory tables in MySQL. This allowed fair queuing to prevent one user hogging the system.

</comment><comment><USER18> remains me to: Martin Kleppmann | Kafka Summit London 2019 Keynote | Is Kafka a Database? [https://www.youtube.com/watch?v=BuE6JvQE_CY](https://www.youtube.com/watch?v=BuE6JvQE_CY)

</comment><comment><USER19> I feel like [https://aphyr.com/tags/jepsen](https://aphyr.com/tags/jepsen) really drives this home.

</comment><comment><USER20> I mean Queues are basically sequence with id that can be seen as monotonically incremental...

So they can be a database, but why is this claim surprising or insightful in anyway?</comment>


Is This Site Secure? - <AUTHOR> http://www.kermitproject.org/secure.html <comment><USER2> While at the begining I thought I sensed a bigger argument here, the further I read I am certain the author either prefers to discount MITM or lacks the understanding of the full scope of a MITM. I agree that there are other evils of the web but that does not mean we make trade-offs.

The last paragraph goes as far as to say

"The ad is not from the website; rather, it is inserted into the datastream — after it has left the Web server as it streams the web page to your computer — by your own Internet Service Provider (Optimum in my case). This is called "watermarking", a variation on the classic Man-in-the-Middle attack. So far it's an infrequent occurrence and not a major problem, and in any case definitely not a security risk, just Yet Another Annoyance"

You let go of your user's privacy and security the moment you make such a trade-off calling it just another annoyance. While visiting this site a MITM could possibly inject a malicius javascript or sticky cookie. How is that just an annoyance? Protecting this is the biggest selling point of HTTPS.

<comment><USER3> I don't agree with the article (mainly because I consider that switching to https is free enough for anyone doing web hosting), but still, the point is pretty clear. https feels like red herring.

When we say "MITM" who is this man? In most cases, the only two valid responses really are "my ISP", and "the service's hosting provider".

https doesn't securize against evil hosting provider.

When using Chrome+https, vs Firefox+http, in one case you give your data to your ISP, in the other case to Google.

Google's primary focus is using my personal data. My ISP's primary focus is giving me Internet. Google is making fuss about https, to feed noise about Google itself.

Yes, I totally agree that best is to simply Firefox https. Yes, I'm totally dismissing the issue of rogue networks. But >80% of the population uses Google, I believe that less than 20% of the population is using rogue networks. What about the issue of broken WiFi security? Well, the point stands: https is so much of a red herring, that everyone forgets to fix WiFi.

<comment><USER4> _> When we say "MITM" who is this man?_

Anyone in `traceroute`, even indirectly. Your state. A rival state. Your ISP. Your neighbor at the coffee shop. A rogue employee at a CDN. A poisoned cache. That little thing that no one noticed in the closet. The latest malware on your router. Any of those threats on any path between the visitor and any resource on the page.

 _> I believe that less than 20% of the population is using rogue networks._

The network is hostile. Believing that it's not contributes to its insecurity: you get an architecture with a hard shell and a gooey center. One box in your "safe zone" gets popped and you're done.

So make the safe zone _your box_ and nothing else. HTTPS helps you get there.

 _> What about the issue of broken WiFi security?_

What about it? Someone snooping on your WiFi can't see through your TLS. That's a reason to support HTTPS, not to dismiss it.

</comment></comment></comment><comment><USER5> > So Internet security has become a big and ongoing business, which has to be > paid for. If I want to have a secure E-commerce site so I can make money, I > have buy security services on top of the basic web services: an HTTPS > address instead of the original HTTP: — OK, fair enough.

Has this guy not heard of Let's Encrypt? HTTPS certificates are literally free. I was astounded when I got to the end of the article and saw it was published in 2020 and not 2015.

<comment><USER6> He is probably assuming that e-commerce sites must/should use EV certificates. It could be an additional trust source but how many users really care that the cert is EVed.

<comment><USER7> But hes not arguing against EVs (that argument would be very valid).

</comment></comment></comment><comment><USER8> Yes, the phrasing "secure/insecure" is an abbreviation that loses a lot of meaning, but to dismiss TLS based on that seems dishonest. Even if you don't care about your user's privacy, don't you at least want the authenticity and integrity TLS provides? The author doesn't only acknowledge MitM, but even show an example where they themselves are MitM'd.

Those same anti-TLS arguments have been rehashed often enough by now.

</comment><comment><USER9> This site also invites me to run a pile of code shipped from it: [http://www.kermitproject.org/ckscripts.html](http://www.kermitproject.org/ckscripts.html)

\-- so yes, it matters that I'm actually talking to kermitproject, and they should go get a LE cert.

</comment><comment><USER10> Seriously? And what about Man-in-the-middle attacks? I mean come on, there are files to download from that website? How can I know if the site I see is REALLY your site without https?

Really, I don't know why you just don't obtain a Let's Encrypt certificate, it's not difficult anymore...

<comment><USER11> > How can I know if the site I see is REALLY your site without https?

HTTPS has never been about non-repudiation or authenticity; it's always been about confidentiality. You get some half-assed "authenticity" if you didn't mistyped the domain, and your clock is correctly set, and the certificate authority wasn't compromised, and the web server wasn't compromised, etc.

You should use GPG or signify if you need authenticity.

HTTPS just prevents injection and monitoring, a bit (see SNI, sniffing downloaded sizes, etc.).

<comment><USER9> Non-repudiation and authenticity are terms of art. By redefining them well outside of what everyone else means by those terms, I don't think you're helping discourse along. HTTPS _absolutely_ guarantees non-repudiation and authenticity. Casually dismissing the most important protocol on the Internet as giving you some "half-assed authenticity" is pretty silly, especially when one of your suggested alternatives is GPG, which literally can not get a damn MAC right in any mode actually deployed anywhere and instead has some weird superstitious MDC nonsense.

<comment><USER11> > HTTPS _absolutely_ guarantees non-repudiation and authenticity

No it doesn't. Correct HTTPS (i.e. connecting to a site with no errors) guarantees:

* the entity that requested the certificate at the date it did had control over either the website or the DNS for a domain (if it is domain-squatting, it's even legal)

* the Certificate Authority that did deliver that certificate did not suffer a breach; and otherwise followed protocol (CAA - which might be under attack, etc.)

* the client connecting did either: not check for revocation (often), not encounter errors while checking, or silently ignored the absence of reply when asking for the CRL/OCSP responder

And it's precisely because HTTPS doesn't guarantee any kind of authenticity that browsers themselves are dropping visual clues for EV certificates. [0]

[0] [https://www.troyhunt.com/extended-validation-certificates- ar...](https://www.troyhunt.com/extended-validation-certificates-are-really- really-dead/)

<comment><USER12> And if someone palms your GPG private key, or the public key is not properly authenticated in the first place, you don't get any of the kind of absolute authenticity you're talking about either. You complain about CRL/OCSP, but a GPG keyserver has all the same flaws (with worse default configuration of clients).

</comment></comment></comment></comment></comment><comment><USER13> My own website is on HTTP because I mainly edit it and browse it on old computers where modern encryption is not available[0]. I assumed it would be the same reasoning here, as who else is using Kermit in 2020?

Is anyone here using Kermit? Would love to know what for. Website seems to suggest it's for embedded systems, but I've only seen TFTP used in those cases.

[0] [http://www.kalleboo.com/retrotech/screenshots/powerbook-145b...](http://www.kalleboo.com/retrotech/screenshots/powerbook-145b/netscape- mypage.png)

<comment><USER14> Well, if someone was bored enough they could mitm your downloads and have fun with whatever computer they were loaded on. That said your not much of a target, but are still and easy one if someone chose to do so.

</comment></comment><comment> cia-killer I wrote a script using mitmproxy to give the true answer. [https://i.imgur.com/muFLWBT.png](https://i.imgur.com/muFLWBT.png)

</comment><comment><USER15> Sounds like the author doesn't know about Let's Encrypt. Pretty simple and free way to secure your site with no disadvantage and it kills OPs primary argument.

</comment><comment><USER16> > Probably browser makers like Google get "rewards" from the security > companies for adding this feature.

This seems like quite a jump to me, and it underpins his entire argument. Is there any evidence of this?

<comment><USER7> Isnt it the opposite that googles policy of showing same icon for DV and EV certificates are making it a lot more difficult for security companies to make money selling expensive EV certs?

</comment></comment><comment><USER17> It surprises me how often Betteridge's law of headlines is true

> Any headline that ends in a question mark can be answered by the word no.

[https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

</comment><comment><USER18> This site serves executables and script files via HTTP. Those potentially dangerous files are thus neither encrypted nor - and that's the bad part - authenticated, meaning that any man in the middle can inject content that infects your machine.

I draw the line at this point. Serve with HTTP if you just have some text. Serve with HTTPS if you have logins, sensitive information or executables and scripts.

<comment><USER14> If I mitm you, your plain txt website now serves scripts.

That's what everybody seems to miss. I can change your content type headers online.

In theory the only way this would work is if browsers would not do javascript at all, or any other type of executable content on http sites.

<comment><USER4> Or modify a TIFF or JPEG or whatever to attack the parser. That ancient system with no modern crypto that can only do HTTP is fully patched, right?

</comment></comment></comment><comment><USER19> There is a big reason left out of his argument: privacy of the user who is reading the page. Essentially non-existing on HTTP.

</comment><comment><USER20> Another reminder that we should fight for encryption by default, without requiring a validated certificate. Just self-signed like most end-ro-end encryption schemes. For such sites, browsers could not display a padlock to differentiate them from validated certificates (DV/EV).

Thus without any additional configuration, the data sent over those connections would be safe.

<comment><USER5> No they wouldn't, because this is trivially easy to MITM. The whole reason CAs exist is to verify the identity of the domain owner, because any random MITMer can claim to be yourbank.com and you can't prove it either way.

Very technically this would be slightly better because it stops passive observers, but in reality I suspect it would be worse because tons of websites would use this broken by design solution and think they were perfectly secure because encryption.

What we really need is to stop making HTTPS so hard to setup. It has gotten better in the last 5-10 years, but you still have to do this whole rigamarole with Apache2/nginx to disable weak cipher suites, setup all the right TLS parameters, etc because the default configuration is so bad. Imagine a world where I just installed an HTTP server and it asks me if I wanted to get a cert from Let's Encrypt (or any other ACME provider) and just did all the setup correctly for me.

<comment><USER20> There are two aspects that are currently adressed by https: identity and privacy. What I'm proposing does indeed only solve the privacy aspect. And for some use-cases, that's fine. Not all use-cases (e.g. your bank), and we would still have CAs for that.

<comment><USER21> Privacy is really the wrong word in my opinion. What you mean is confidentiality. This might sound like nitpicking, but private communication might mean that some attacker does not know who is talking to whom, which is not what TLS even tries to provide (anonymous communication). The term is somewhat overloaded. You can have fully encrypted communications and still give away information you intended to be private.

TLS does try to provide confidentiality and part of that is authenticating who you are talking to. Without this your communication is not at all confidential, as anyone could impersonate your intended target. A passive adversary can't read your traffic, true, but an active attacker (of for example the coffee shop dwelling variety) is not a major step up and would undermine the confidentiality aspect entirely.</comment></comment></comment></comment>


PHP 7 word count benchmark - <AUTHOR> http://juditacs.github.io/2016/03/19/wordcount2.html?hello <comment><USER2> The algorithms differ considerably across language and the PHP one is particularly inefficient. The algorithms must be held constant in order for this "benchmark" to be valid.

As of right now this is just a programming competition across a variety of languages.

<comment><USER3> I'm imagining an alternate version of the Wizard of Oz, where Dorothy clicks her ruby keyboard and says, "All benchmarks are flawed. All benchmarks are flawed. All benchmarks are flawed."

This is not an uncommon technique for comparing programming languages. We are not just trying to compare the performance of different implementations, but we are trying to compare the performance of different idiomatic programming styles in different languages. The shootout does the same thing. And yes, the shootout is also flawed.

</comment></comment><comment><USER4> Surprised by Python and Go results. They should have tested with PyPy too.

<comment><USER5> It's only testing the quality of hash tables and sort, not much else. siphash beating FNV1 can only be explained with the table implementation

</comment></comment><comment><USER6> i wonder if you could do even better with PHP's SPL* functions like:

[http://php.net/manual/en/class.splfixedarray.php](http://php.net/manual/en/class.splfixedarray.php)</comment>


Bitcoin's Biggest Hack in History: 184.4B Bitcoin from Thin Air - <AUTHOR> https://hackernoon.com/bitcoins-biggest-hack-in-history-184-4-ded46310d4ef <comment><USER2> The change that invalidated the transaction was not a hard fork. It was a soft fork.

[https://en.bitcoin.it/wiki/Value_overflow_incident](https://en.bitcoin.it/wiki/Value_overflow_incident)

A hard fork expands the range of valid transactions. A soft fork narrows that range.

Remember the book _Javascript the good parts_? It proposes that developers ignore certain language features that can cause trouble. The interesting thing about this approach is that all the code you write by following the book's guidelines will run on all existing runtimes. Your code is backward compatible.

Had the book advocated new language constructs, then those applying them would not be able to run their software on existing runtimes.

This difference is roughly comparable to the difference betweeen hard and soft forks.

Prior to the Bitcoin update, no check was made for overflow conditions. After the update, only transactions obeying a narrower set of rules involving an overflow check were considered valid.

A soft fork can be deployed by miners censoring blocks containing the transactions which are longer valid. Nodes that don't generate blocks need not update for they will never see the now invalid transactions. Miners need to update to avoid generating blocks that will be rejected by the network.

A hard fork requires even non-generating nodes to update, for they will need to determine the validity of blocks with transactions applying an expanded rule set.

<comment><USER3> This is the clearest explanation of the distinction I've read, thanks.

</comment></comment><comment><USER4> It wasn't the last time that centralized decision-making saved the day. Another incident that is worth reading about if Bitcoin failures interest you is the 2013 Bitcoin fork: [https://freedom-to-tinker.com/2015/07/28/analyzing- the-2013-...](https://freedom-to-tinker.com/2015/07/28/analyzing- the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/)

Basically, a new version of Bitcoin Core software was released (v0.8) and only part of the network was running it. Then a block caused a divergence, where folks running v0.8 started mining on top of a different chain than the one mined by folks on v0.7. Amidst the chaos, 2 developers (Luke DashJr and Pieter Wuille), decided that miners should rollback to v0.7 and mine on top of the "v0.7" chain. Miners and other devs quickly fell in line.

One lesson gleaned from these two incidents (featured article and this one) is that centralized problem-solving clearly made these events less catastrophic than they would otherwise have been. If in 2013 there had been no leader to advise the crowd which chain Bitcoin should be, the divergence may have been permanent. And then people wonder why nowadays Bitcoin keeps forking, when history shows that strong leadership prevents persistent forks. A persistent chain fork is not a technical failure, it is a leadership failure.

<comment><USER5> Which raises the question: If strong leadership is needed to define the meta- consensus, what use is it that the technical consensus is decentralized?

<comment><USER6> Technical consensus provides an important backup / tie-breaker when meta- consensus isn't clear.

This has happened multiple times in the past with Bitcoin, most recently with Bitcoin Cash vs. Bitcoin Core. The user-base is split, there is lots of propaganda on both sides. However the technical consensus yields a single chain (Bitcoin Core).

<comment><USER4> Actually there were 2 persistent bitcoin chains to emerge from that conflict, one led by Bitcoin Core's consensus rules and one led by Bitcoin Cash's consensus rules. Nothing technical prevented the fork. And to claim one is more "bitcoin" than the other is moot. In fact the argument of which bitcoin chain is what Satoshi would have wanted is still being argued about every single day...

<comment><USER6> True both are still around, but a user can simply choose the fork with the longest chain (most PoW).

This is important because all other metrics such as choosing based on message boards, market cap, etc. can be more easily gamed.

</comment></comment></comment></comment></comment><comment><USER7> Now that so many coins are doing private encrypted transaction amounts, I wonder if a bug like this could go undetected. If you could find an inflation- causing bug in a popular private coin and exploit it, you could easily make tens of millions of dollars within a few days. Possibly hundreds of millions if you played it right. And even if you were later found out, it's not clear to me that it would be illegal or whether you could be prosecuted for it. It's the biggest bug bounty ever.

<comment><USER8> [https://zcoin.io/important-announcement-zerocoin- implementat...](https://zcoin.io/important-announcement-zerocoin- implementation-bug/)

<comment><USER9> ok that explains how they know pretty well.

</comment></comment></comment><comment><USER10> What always confused me about cases like this one is what is considered a hard fork. This was a software bug, and not a flaw in the design or protocol itself. When is it a bug fix, and when is it a hard fork? Is the client law, or is the protocol law?

\- If there were more than one clients would this be an issue?

\- If there were more than one clients and only one had the bug, would it still be a hard fork?

<comment><USER11> It's miner and user confidence in a specific chain that ultimately defines it.

Similar to country sovereignty, these things are defined only by how most people define it. You can't just stand up and say you are now your own country, you need to get other countries, other people, to agree with you. But at the same time, if a country changes its name/laws/maps, it doesn't become a "new country", it just changes.

You can fork bitcoin, but unless most users and miners out there agree to call your fork "bitcoin", then it won't be bitcoin. But if "bitcoin" decides to radically change, and most people agree with the change, then it is still bitcoin, despite the differences.

(as an aside, anywhere I say "most people" here, you can replace that with "most hash power" or "most users" or any other metric you want. I'm not trying to speak to specifics, but more the overall idea)

</comment></comment><comment><USER12> Off topic: I can't read stories on hackernoon. The bright green header makes my eyes watery and after closing my eyes I can see the afterglow. I can see it even right now with eyes open. The fact that I can't scroll away from it, makes it even worse. Why would you make this header sticky?

<comment><USER13> Permanently burning the logo into users' retinas - it's an advertiser's dream!

</comment></comment><comment><USER14> > Satoshi Nakamoto quickly hard forked the blockchain to remove the 184.467 > billion Bitcoins, which is the only thing that saved Bitcoin from dying an > early death that day.

Of course, if something like this happens today, I'm not sure the solution would be as simple as this…

<comment><USER15> I was there. Someone would post the code for the hard fork and most miners would switch to the chain without the bug. A chain that has infinite bitcoins on it is worthless... Just as it happened back then. I switched over as soon as I read the thread about it and saw the chatter on irc.

<comment><USER14> I understand that most people probably would switch. I'm actually looking it this from a different perspective: would Bitcoin be able to regain trust? A large hack might kill Bitcoin if everyone decides that they don't trust Bitcoin's security.

<comment><USER16> Yes. The trust is not in the code, it's in the hash power.

<comment><USER17> From a normal investor's standpoint, the hash power is an implementation detail. Trust has to be in the integrity of the blockchain.

<comment><USER16> Maybe that investor shouldn't invest in bitcoin or Proof of Work based chains.

These systems are nothing like PayPal and Venmo and investing in ignorance is just asking for losses.

<comment><USER17> I agree; nobody should be considering cryptocurrencies an investment. That's not the message coming from most Bitcoin enthusiasts, though.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> What was the problem exactly? The article is a bit shy about it. Integer overflows usually reduce the value instead of increasing it.

<comment><USER19> The transaction took an input of half a bitcoin, and had two outputs of roughly 2^63 each plus another output that got a tiny amount.

Skipping over a few details, that means you send 92 billion to one address, 92 billion to another address, and the total overflows back under .5 bitcoins.

</comment></comment><comment><USER20> Is there collateral damage when forks like this happen? Or can they precisely target just the one thing?

<comment><USER21> Yep. Transactions in subsequent blocks may be reordered or not included at all in the new chain forked from before the incident. Temporarily diverging forks are a property of Bitcoin anyway and must be expected. So your transaction being first confirmed but then dropping out is a possibility without assuming malfeasance.

Still it is also possible to revert transactions in Bitcoin if enough people agree. As demonstrated after this hack. The biggest collateral damage is in trust when this is demonstrated in vivo.

</comment></comment><comment><USER22> hard forking is consensus and the whole system is built on consensus. it's the democracy of the developers, the miners and the people with skin in the game.</comment>


Why programming is difficult (2014) - <AUTHOR> https://joearms.github.io/#2014-02-07%20Why%20programming%20is%20difficult <comment><USER2> I think there are a number of major problems with the industry.

Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so often precludes a lot of practitioners from gaining a deep experience and understanding with the tools they're working with. This may be the only industry I know where pertinent knowledge and experience matters little.

The notion of "Full Stack Developers" gives the impression that one can be proficient top to bottom. What I find interesting about the label is full seems to usually be bounded on the lower end at a place much higher than a place where I would use the term full. This is one of the many areas in our industry where hubris is in play. Specialization is usually preferable for quality and scaling.

Real world business continually drives the fast and cheap legs of the stool to be chosen by management. However, I think this grates against most practitioners who not only care about quality but would admit, the aspect of quality is one of the major reasons they are even in the field to begin with. There is a large natural tension at play here. I think it's this tension that Joe was articulating.

It's seems to me the most satisfied folks in this field are the ones fortunate enough to be compensated for working within a bounded context where over time they can gain more and more experience and knowledge. This naturally leads to a growing confidence and a sense of control over the context with which they work.

<comment><USER3> I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can).

From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is).

I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.

<comment><USER4> This is the other side of the coin. A lot of folks in the industry, especially on the younger side, tend to believe they are operating at FAANG levels of data and complexities. What happens is that you get convoluted, over- engineered architectures and applications which really do nothing other than pad resumes. The next time you are listening to a talk or reading a blog entry that drones on about how complex their stack is, stop and think for a moment: "Do they really have traffic/MAU levels that merit this approach? Are they really operating on data that is PB scale or just a few GBs?" More often than not, the answer is an emphatic No ... or "Can this application be distilled down to a vanilla MVC app with a few cronjobs running?" Yes.

<comment><USER5> > _What happens is that you get convoluted, over-engineered architectures and > applications which really do nothing other than pad resumes._

But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".

</comment></comment></comment></comment><comment><USER6> I think the reason programming is difficult is that really we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest.

Programming is not just understanding how the device, language, libraries work (ie. getting more complete information) but also limiting the ways the adversary can screw you and limiting the fallout.

Programming is difficult because developers don't appreciate how important the part of managing this incomplete information is. "I wrote this and it works! Yeay!" And then it goes in prod and fails instantly because you did not take this or that into account.

Some bright developers have the ability to manage this. But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way. This puts them in this untenable positions where they can either do something by themselves, very efficiently, or rely on extremely inefficient process if they want to work with other developers.

<comment><USER7> "I think the reason programming is difficult is that really we are dealing with incomplete information"

Dealing with uncertainty and incompleteness is a core part of the job.

The problem is that far too many programmers are gloryhounds and cowboys who think all that is beneath them; cramping their style when they're trying to be the coding heroes.

This is compounded by many programmers being lazy incurious bums who have zero interest in doing anything that isn't writing code. They don't want to learn the user's problem domain, so they don't. Instead they demand users describe exactly how the software should work down to the very last detail; but if users could do that for themselves then they wouldn't need programmers to write it for them!

Starting from ignorance, instead of writing software that encapsulates the users' expert requirements, they write clever code that solves their own problems: entertaining themselves, and getting paid.

Writing code is not hard. Any monkey can do that. The challenge is knowing _what code_ to write; and that's made needlessly hard by programmers who can't be arsed to understand their users, what they do and why they do it, learning their needs and problems in order to synthesize more effective solutions.

Instead of raising themselves up to users' level of knowledge, they drag the problem down to their level of ignorance and whale on it with their crappy tools to give the illusion of "productivity". Instead of being problem solvers, they're problem _multipliers_.

Slap on several more layers of equally useless management, marketeers, beancounters, etc, and factor in that while deadweight accummulates expertise walks, and it's no surprise most software projects are rolling Katamari disasters that makes _everyone_ miserable until finally put out their misery; only for the whole process to start over again, with zero lessons learned.

\--

TL;DR: Programming is hard because programmers _make_ it hard. Because they don't want to do the job right. Because they're children.

<comment><USER8> > Programming is hard because programmers make it hard

This has been the MBA's wish/dream/hope for about a half-century now: "if only programming were easy and programmers didn't take so long," they think, "I could be making millions off of this business." Since they want this to be true, they reason, it must _be_ true. They then insist, in spite of mountains of evidence to the contrary, that programming is easy, and the entire industry of programmers - every single one, including the ones who were educated recently, including the ones from foreign countries - are conspiring against them to make it seem like it's harder than it really is.

<comment><USER6> Also, MBAs assume then can hire anyone and then they complain the performance suffers.

The truth is, development is a high skill profession. It should take decades to master if we were really realistic about it.

</comment></comment></comment></comment><comment><USER9> There is a reason why people make a distinction between "Programming" and "Software Engineering". Programming is just the act of writing code. All you have to do is learn a programming language and you are set.

"Software Engineering" encompasses everything else on top of programming. You need knowledge of these things: build systems (Make/Gradle), filesystems, networking (IP/TCP/HTTP), Data formats (JSON/XML), Databases(SQL/KV), software architecture, layout/styling, documentation (both reading and writing). This list is just scratching the surface but we can agree that all of these things are critical to build applications.

These topics clearly aren't exclusive to "Programming" and knowing them doesn't mean you are a "Programmer". You could also be a sysadmin that is managing a large cluster for multiple applications. But if you are a Software Engineer and not just a mere "Programmer" you know that your job is much much more difficult than merely the "Programmer" part.

<comment><USER10> Is software engineering a real engineering discipline, though? I have a hard time saying yes when "software engineers" make mistakes that are well documented, no certification is necessary, and it isn't a legal definition.

<comment><USER11> Man, the people who push certification systems on the software engineering community really burn my biscuits.

I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).

No certification system is going to magically make large systems easier to write or whisk away bugs. _Writing software is hard_. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because _writing software is hard_.

You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?

Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.

<comment><USER12> It's not about being perfect, it's about being fault tolerant, just like regular engineering. I think especially for safety-critical situations ( _cough_ Boeing _cough_ ) there needs to be stringent, formal standards for quality, review, and training. It should not be possible to cheap out or ship a pile of duct-taped garbage in some situations, and that requires external review by subject matter experts. (Not necessarily government bodies, especially with the regulatory capture and brain drain going on right now.)

<comment><USER13> I think kabdib's point is that the incentives of certification authorities aren't aligned with the purported goal of the certification process. We already have all sorts of certifications (in specific technologies, "agile" practices, etc.) but I don't think most engineers see those certifications as providing any value.

The only thing I'm aware of that seems to actually work is to hold engineers accountable for results and _give them the autonomy to set their own process_. I would argue that even very rigorous methodologies like NASA's Systems Engineering[0] process match that description.

[0] [https://www.nasa.gov/connect/ebooks/nasa-systems- engineering...](https://www.nasa.gov/connect/ebooks/nasa-systems-engineering- handbook)

</comment></comment></comment></comment></comment><comment><USER14> "Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick." \- Bruce Lee

</comment><comment><USER15> Re- the Emacs config suddenly breaking... I do something getting more and more common: I put my entire Emacs config in Git. It's a bit more work when upgrading packages (because you have to commit them too) but then there's hardly ever any breakage that's not one Git checkout away (I'd say anyway that Emacs doesn't that often break at all: it's more the usual package dependencies SNAFU of our trade that bites Emacs users once in a while when they upgrade this or that package).

On a funny side note I had a very bad Emacs breakage recently and at first couldn't understand why checking out the latest known correct Git version wasn't working on my main machine. It was working on another computer (btw copying my entire Emacs config is, well, also one git command away, so is backuping). Turns out: for whatever reason the file containing the list of files recently opened by Emacs got corrupted in a very strange way and that's one of the rare Emacs file I'm not committing into Git. Took me a few minutes to sort out.

<comment><USER16> I do the same with my .vim folder. You can place your .vimrc file in there as .vim/vimrc and now everything is backed up in git. I've been working this way for a few years now and can get setup on a new machine in a matter of minutes.

</comment></comment><comment><USER17> For me, programming is difficult because once you reach a certain level of complexity it's very difficult to keep a robust enough model of the program in your head.

TDD has really helped me in this regard because it forces me to start building the model from ground up as opposed to in media res.

</comment><comment><USER18> I find this article beautifully written and it resonated with me. Writing maintainable code is damn hard for larger projects.

Also, I read a couple comments above, and I feel that people who wrote them have no idea who Joe was. To me Joe is an inspiration, and I think his words are usually not there to be debated ;), after all he cocreated Erlang, and Erlang and the OTP is a masterpiece imo.

</comment><comment><USER19> "After a week of struggling with a broken LDAP sever written in C and badly documented I had a lapse of memory and forget that my boss said and accidentally implemented a server from scratch in Erlang during my lunch break."

Joe was awesome, on so many levels. You have to love the healthy rebellious streak and the talent to back it up.

</comment><comment><USER8> It's kind of the worst of both worlds: it looks like it should be easy, but it's confoundingly difficult in ways that are impossible to see unless you're actually trying to practice it.

<comment><USER20> Is this not true of most difficult things?

<comment><USER8> When I look at the high regard most people hold, say, lawyers and doctors in, who also do hard things (that are accepted as hard), I'd have to say no.

</comment></comment></comment><comment><USER21> I agree that programming is difficult, but Im not sure he understands why he's finding it so difficult.

> "I Google a bit and after a while find a posting where some poor unfortunate > soul has encountered exactly the same problem that I have. My heart leaps > for joy. My trembling fingers enter the magic spell that will remove the > curse, and ... nothing. The problem remains."

and

> "I'm lazy, I'm a good for nothing slacker. But when I want to put a diagram > into LaTeX I don't want to have to read a 391 page manual first. Now I know > you will accuse me of laziness and of being of unsound moral character,"

I wouldnt go so far as questioning his morality. But if you're not constantly focused on learning, even the minor details of the stacks you're working with, you'll increase the difficulty enormously. He sums up the danger of that attitude perfectly in his closing remark

> "Fortunately eleven minutes with the Google casino worked. The second > suggestion of how to fix my problem worked - and I still don't know why > emacs could not find aspell - and life is too short to find out why."

He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.

<comment><USER22> >Next time he faces, even the same problem, he'll be back on Google trying his luck.

There isn't a next time because Joe died last year.

I think you misunderstand the point. Time is truly limited thing you have in life, and you are using much of that time understanding minor tool that are not the major point of what you are trying to do, that doesn't seem productive and is indeed infuriating.

About the final mark, those eleven minutes should even be needed, things break unfortuntatly, and if who has deep understanding of every single tool you put your hands on, you will not have the time to do whatever you need to do.

A few years ago, I had the "pleasure" of have to use docker on windows, on a complex stack, the docker windows client was always breaking with the solution always being revert to previous version, wait issue fix, update. Ofc, before that we needed to waste some time to check if it was I who broke something or if it was an update. The lesson was, only update sporadically, which also has its downsides. Or should I instead have a deep understand on how docker for windows client worker and submitting the fix myself? Do you know if I had the time for it?

Too many things in our field are held by duct tape that is always tearing. I'm also culprit of that. But saying that because tools not being newbie friendly, or some tools breaking it's the fault of the user is not really a good a approach. Being a programmer shouldn't be about fixing your editor every time it breaks, or spend hours learning arcane tools that are not about programming.

<comment><USER23> Webdev seems to be a duct tape paradise full of beginner tutorials that go nowhere. And when the hard problems popup the suggestion is to google search instead of KISS. I dont know somethings will always be difficult.

</comment></comment></comment><comment><USER24> Discussed at the time: [https://news.ycombinator.com/item?id=7197255](https://news.ycombinator.com/item?id=7197255)

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

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

</comment><comment><USER25> Love this article! I don't think the guy is playing a 'persona' at all in this piece. These are the kinds of things he thinks about on a daily basis. Heck, these are the kinds of things I think about on a daily basis too, and I'm sure most devs who have been writing code for a few years do.

In my daily work, I don't have time to understand everything. There, i've said it. I'm not lazy. I'm not stupid. I just don't have time when I'm trying to get a task/job/chore done. I appreciate good abstraction/encapsulation. A good tool does this. A bad tool fails to do this. Same with documentation, really.

Don't get me started!:)

<comment><USER26> FYI Joe died last year and is best known for inventing Erlang.

[https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer)](https://en.m.wikipedia.org/wiki/Joe_Armstrong_\(programmer\))

</comment></comment><comment><USER27> I feel like the constraints he added are a bit too restrictive, they would force a program to be _perfect_ whereas for most circumstances it would be enough for a program to be bug-free.

The real problem seems to be writing bug-free programs, which seems to be difficult mostly because it is hard to specify what a program should do formally (i.e. in code). Note that bugs are never about the program not doing what it is told, but are always a mismatch between the program and the programmers mental model of the program.

<comment><USER28> Not to mention, the program can be completely bug free but still terrible when put in real life because any one of the 10,000 things about its intended use was unknown or not prioritized.

</comment></comment><comment><USER29> My experience has been we have a big pile of complexity with some way of doing things. New shiny tech promises to eliminate this complexity. Perhaps it does, but also introduces new level of complexity. Old complexity hasn't fully vanished either, but now its problems have to be solved through the new level of complexity, resulting in a further emergent level of complexity.

Fortunately, there is a new shiny technology that will make all this complexity go away.

</comment><comment><USER30> Oh but many people will say it's child's play and management is where it's at. And then they you will have 10 people doing the work of 1.

</comment><comment><USER31> _\- The output of the program is beautiful._

 _\- The input to the program is beautiful._

 _\- The program is beautiful._

I think it would make more sense if the word _" beautiful"_ was replaced with the word _" correct"_...

It would also help strengthen his argument for why programming is so difficult!

<comment><USER32> I suspect ie didn't specify correct because correctness is impossible; with the following constraint (i'm surprised he didn't have as the last bullet point): _and it must run on top of an unreliable subsystem_.

<comment><USER33> On top of _several_ unreliable subsystems.

I think that's a big part of why it's so hard. You've got leaky, imperfectly understood, unreliable subsystems, and you're trying to build the best system you can on top of it. And what you produce inevitably is a leaky, imperfectly understood, unreliable system... which becomes somebody else's subsystem. And so it goes.

You say: We need to create perfect subsystems! Formal verification (or robust type systems, or better requirements, or mathematical reasoning, or some other approach) will save us! But it's not that simple. It starts clear down at the hardware level. How much can you formally prove about your CPU? _After_ taking into account it's errata sheet? The union of the errata sheets of _all_ the revs of the CPU? If you're running on PCs, the errata sheets of _every CPU that anybody could conceivably be running on?_

If you can't formally prove much about the CPU, how are you going to formally prove the OS and/or compiler? And if you can't formally prove those, how can you formally prove anything else?

It's leaky, unreliable, incompletely understood subsystems all the way down.

<comment><USER32> All the way down to quantum mechanics, unfortunately.

</comment></comment></comment></comment><comment><USER34> I think I'll start using the phrase "Google Casino" now.</comment>


Why developers hate being interrupted - <AUTHOR> http://thetomorrowlab.com/2015/01/why-developers-hate-being-interrupted/

<comment><USER2> I love the linked picture: [http://i.imgur.com/3uyRWGJ.jpg](http://i.imgur.com/3uyRWGJ.jpg)</comment>


Show HN: "New52":  My attempt to dive Wider, not Deeper - <AUTHOR> https://github.com/bussierem/new52/ <comment><AUTHOR> I've always been one of those people who has an absolutely terrible time coming up with side projects for myself, primarily for two reasons: I aim too high, and I love to stick with familiar technologies.

To this end, at the beginning of the year I started my NOT A NEW YEARS EVE RESOLUTION project (because NYE resolutions rarely see completion): I decided that I would spend all of 2018 learning entirely new technologies - one new one per week, every week, and spending at least 8 hours on the technology. I also set a hard line that I wouldn't "give multiple weeks" to anything, no matter how much I loved it. I would move on at the end of the week, and anything I wanted to pursue further would either have to wait, or would be tinkered with on TOP of the work I did for New52.

I am coming up on 1/4 of the way done with this project, and I figured now was a good time to share it, now that I'm confident I'm "sticking with it" (unlike many other NYE resolutions...)

I wanted to share it here for inspiration to others, but also for a selfish reason: I would _love_ to get people's advice on what to explore! I'll accept PRs to the README list of tech ideas I have - I have 40 weeks to go still, and nowhere near that many items left in my list!

Thanks for taking a look!</comment>


Free Tutorial: Pure JavaScript – Building a Real-World Application from Scratch - <AUTHOR> http://codingthesmartway.com/pure-javascript-building-a-real-world-application-from-scratch/ <comment><USER2> tl;dr pure javascript = using jquery and bootstrap

<comment><USER3> Yep, the first thing i thought too.

</comment></comment><comment><USER4> If you want to get started with web dev in 2017. You should avoid jQuery as much as possible. Take a look at [http://youmightnotneedjquery.com](http://youmightnotneedjquery.com) before deciding.</comment>


Why I use Python and enjoy it thoroughly - <AUTHOR> http://vascop.github.com/blog/2012/06/13/why-I-use-python-and-enjoy-it-thoroughly.html

<comment><USER2> Python is my first real attempt at learning to program. I _love_ it!</comment>


"Smart companies try to commoditize their products' complements." (2002) - <AUTHOR> http://www.joelonsoftware.com/articles/StrategyLetterV.html

<comment><AUTHOR> This is a perennial submission ([http://hn.algolia.com/#!/story/forever/prefix/0/http%3A%2F%2...](http://hn.algolia.com/#!/story/forever/prefix/0/http%3A%2F%2Fwww.joelonsoftware.com%2Farticles%2FStrategyLetterV.html)) but hasn't shown up in a while. I'm resubmitting it because it's part of the canon: you can't understand Silicon Valley big politics/business without understanding this concept in some way - otherwise, you'll be mystified by moves like Google's Android or big tech giants going into fields that seem only tangentially related to their core business.</comment>


Securely share files with the Guardian - <AUTHOR> https://securedrop.theguardian.com/ <comment><USER2> The same Guardian that allegedly butterfingered the passwords to the cablegate documents: [https://wikileaks.org/Guardian-journalist- negligently.html](https://wikileaks.org/Guardian-journalist-negligently.html)</comment>


Minimum Lovable Product - <AUTHOR> http://blog.forcerank.it/but-what-is-the-minimum-lovable-product

<comment><USER2> Interesting article, makes me curious to try the product.

But the article is written by the product guys about how they used their own product to determine what to put next into said product. A product intended to help groups determine priorities without meetings....

It's not exactly astroturfing, but....

Dogfoodturfing?

<comment><AUTHOR> Dogfoodturfing! But we don't call it dogfooding anymore right? We call it champagning? So Champagneturfing?

Anyway, quick clarification that this is a article written by the product guys about how they use their own product in their other job. So not exactly as self referential as suggested.

-one of the product guys

</comment></comment><comment><USER3> Nice! Excited to try it. I suspect software tools can help teams both make better decisions, spend less time, and have more fun than a conventional meeting.

</comment><comment><USER4> So much simpler if you simply remove 4 people from the 5-person team.

</comment><comment><USER5> Slightly off topic, but I really dislike that initial image that gets mindlessly retweeted around.

Without any info of what is trying to be built it's useless. The minimum viable product could well be the image on the right, if say your product was trying to scale the delivery of cute looking cupcakes.</comment>


Show HN: Jetstream – webcam live-streaming without the bullshit - <AUTHOR> https://jetstream.club/ <comment><AUTHOR> The idea here is that if you want to do a quick live-stream of something, you can just go on the web page, click the button, and share the link. You don't have to sign up, send money, download a streaming client, etc.

It's essentially "Facebook Live" for people who aren't on Facebook.

It's open source and self-hostable.

</comment><comment><USER2> It's probably a good idea for a site whose main message is "it just works" to have a better initial phone visit experience than the current unattractive pop up saying "No WebRTC support???" and an "OK" button.

<comment><AUTHOR> Sorry about that. What phone/browser are you using that doesn't have WebRTC support?

<comment><USER2> I'm running the Chrome browser on iOS (yes, I know it's a wrapper... I prefer the UI). Latest production versions of each.</comment></comment></comment>