skysight-inc/HackerNews huggingface dataset:
I don't know if it's what Thomas is referring to, but I ran OpenBSD in production for several years at a previous job. I found that, in practice, actually getting our platform to do what we wanted involved large amounts of ports (ie, outside the base system) to be installed. Sometimes, dozens of them. And this is where obviously your mileage will vary, because that depends what your servers are doing.

OpenBSD's incredible code quality quite obviously doesn't apply to the ports tree (and that's not their fault) but we quite often ran into less popular products and third party libraries where the ports were updated in the order of weeks later than things like RedHat RPM for the latest vulnerability.

At point I backported a hotfix myself, the requirement of which was not conducive to security.

Disclaimer: This was years ago, things may have changed.
Do you think eyeglasses work?

How does that fit into your theory? It seems like glasses are an improvement over nature, using very simple (by modern terms) technology.
Appears to still be there, please try going to:
https://news.ycombinator.com/favicon.ico to see what comes up.

Resource Request Information:
Location: https://news.ycombinator.com/favicon.ico
Size: 256px x 256px,
Cached:No,
Type: X-ICON image,
HTTP/1.1 200 OK,
Date: Sun, 24 Jul 2016 03:04:01 GMT
Because C doesn't have type-safe enums.

edit: for the downvoters, I'd LOVE to be happily corrected with a link to documentation about C language support for a type safe enum.
I view ethereum as a tool for automation: It lets us automate legal contracts, currencies, synthetic assets, etc.

All forms of automation in our world go wrong sometimes: This is why we have car repair shops and appliance repair technicians, for instance.

Saying that ethereum is only useful if the automation holds 100% of the time is like saying cars are useless if you have to occasionally take them to the shop for a tune-up. I agree that having a car that never needs a repair would be AWESOME but it would probably be unrealistic to try and build one.

That said, ethereum is still extremely good for writing immutable computer code involving financial assets, it's just that there is now some philosophical (and practical) controversy as to whether it is 100% good or just 99.9999% good (depending on whether you view the code or the community as the ultimate arbiter of "good".)
>They all had good features, but none had all of my desired features.

Many intercepting proxies like The Fiddler with FiddlerScript and the Burp Suite through Burp Extender can be extended to have any feature you want by writing your own code or leveraging someone else's. Personally the only time I've found myself thinking I might need nginx for a debugging proxy is when I need scale. I'd rather use something that's close enough, write stuff where I need to, then focus on doing really cool things with them like finding vulnerabilities for fun and profit.
Just wondering why you can't use React directly if that is the case
An actionable takeaway is to disable eval in php.ini. Not always practical but i doubt everyone needs it.
The article itself throws some self-doubt with a link to http://danluu.com/empirical-pl/

It's also a bit of a pain that it's just a summary of a video, and there's no citation to any text anyway.

From what I can tell, the first bit of evidence is from a researcher's toy language.

The second was a scan of GitHub for issues that included type errors. There's no mention of actual methodology, but I'm imagining that means 3% of Python issues in GitHub have a copy-and-pasted stacktrace that contains a type error? This is clearly not a great indicator, since it won't count issues with less description, or any bugs related to, say, a bad type coercion.

On the other hand, you're right, I've not read any research that points to static typing being a net-gain. Every static-type advocate probably remembers being burned by a dynamic-type issue, but that doesn't mean the advantages might not outweigh disadvantages - experience and intuition don't cut it here.
That's what the benefit of using openresty is. I can print and hack on http requests in an already mature ecosystem.

It's two ways to do the same thing, but I like my way, and mine uses software that is production ready as a proxy :)
Test coverage is crucial as code matures and is finalized, not necessarily when it is prototyped - which is exactly where a type system gets in the way.

I disagree with the idea that you need to write more tests because of dynamic typing, my claim is that the tests you have to write anyway also cover type errors. Just running your code yourself covers most type errors.
I don't know why this is downvoted. Several of the author's claims about C are just wrong. Modern C compilers can warn you about most of these, and literal initializers eliminate the missed zero initializations.
> It doesn't seem too long ago when Java Developers
> rushed to Ruby because it wasn't statically typed.

IMO they were rushing away from:

1) Java's verbose syntax (not the type system itself; static typing and verbose syntax are technically orthogonal),
2) The J2EE + FooFactoryFactory mess that infected the Java ecosystem at the time, and
3) Enterprise software in general (a lot of Ruby was in startups, so fun greenfield development, away from the J2EE/enterprise mess).

For Java itself, the syntax is finally getting better (Sun really screwed that up, and let C# get way ahead in innovation), and J2EE is finally over AFAIU, so Java development is generally/in theory not as bad as it was when everyone left. </Stockholm syndrome>
Just to add to the issues with this statement, Vulkan doesn't necessarily target a "GPU" since a CPU can also render frames just fine. More accurately, Vulkan, like DX12 is a graphics/compute API, with the distinction between graphics and compute pretty blurred at this point.
Pessimistic answer: The robot wakes up, the humans are dead. Oh well.

Optimistic answer: The robot wakes up and tries to find a bank. The robot goes to downtown San Francisco and can't find any, eventually asking a bald man wearing a strange-looking red and black leotard where the nearest bank is.

"Bank? I don't believe there have been any banks here for some time." The man talks to you and quickly finds out the robot is from another time. He smiles wryly, and begins, "The economics of the future are somewhat different; you see, money doesn't exist in the 24th century..."
Sorry, but, many of these companies are not as ethical as you claim.

Xiaomi sent user data to China without consent. [1]

Palantir proposed an illegal campaign agaisnt Wikileaks [2] and its very industry is by its nature fairly dubious and shady, though that doesn't mean it's doing things that are strictly illegal aside from what is known.

Snapchat ignored and didn't fix various privacy and security issues. [3]

Pintrest operates in a dubious copyright gray area. [4]

Spotify pays artists very little and most money gets sent to record labels. Even labels see almost nothing. [5]

Like Uber, Lyft engages in unethical treatment of its workers. [6]

I can go on. The badness of these things varies significantly. Not all of them indicate a company is totally unethical. But I think the assertion "most Silicon Valley companies are doing at least some illegal, scammy, or otherwise unethical things in order to get ahead" is completely true.

[1] http://www.zdnet.com/article/xiaomi-under-investigation-for-...

[2] http://www.forbes.com/sites/andygreenberg/2011/02/11/palanti...

[3] http://www.nytimes.com/2014/11/27/style/uber-facebook-and-ot...

[4] http://www.businessinsider.com/pinterest-illegal-faq-2012-2?...

[5] http://www.hearya.com/2012/11/28/david-macias-enlightening-l...

[6] https://www.reddit.com/r/Lyft/comments/2y16r3/lyfts_highly_u... (aggregates news articles)
The responses by the neighbors make this seem to me not to be such a simple black and white case. They seem to have been minorly inconvenienced and then went about grasping for every possible bylaw and regulation and proceeded to pump up the charges ("he created a haven for criminality!") in order to give themselves an ounce of credibility. This was their autopilot response.

Im with the OP here, in a less litigus/hyper-regulated community and most importantly a more socially laid back one this would not be such an overblown problem.

Most likely a problem like this could easily be dealt with by being approached by the neighbors and being politely told of their problems with it. Reasoning with him first and resorting to law only for extreme situations. Even in the article he said he's doing it because a neighbor complained. That makes you question the value of immediately jumping to the leg system to solve all of your minor problems. As Americans seemed to have been raise to do.

No wonder the legal system is continually bursting at the seems from demand for court time.
Not sure if you're being serious but GitHub truncates to 1000 files/directories.
UL Certifies First Hoverboard to UL 2272 Standard (in May 2016)
How is this distinct from Hystrix (https://github.com/Netflix/Hystrix)? Why should I use one over the other?
It isn't type-safe in the sense you're used to in C++. But common pitfalls can be avoided if you don't destroy the type information by assigning through a vanilla integer.

enum a { A };
enum b { B };

static enum a a = B;

$ clang -Wenum-conversion -Werror a.c

b.c:4:19: error: implicit conversion from enumeration type 'enum b' to different enumeration type 'enum a' [-Werror,-Wenum-conversion]
static enum a a = B;
~ ^
1 error generated.
Such easy things to say when you're just dealing with a hypothetical. You almost certainly do care what your neighbors do(or don't do).
"Early optimization is the root of all good" is a grossly misleading title. It's only a context-specific quote deep within the article.

The actual title of the article is "id Software Tech Interview: DX12, Vulkan, Mega-Textures, PBR, Global Illumination & more"
I think many of us who use Windows take for granted the number of tools we use to cover over our pain points.

I use Msys2, Cmder, a bunch of custom tool builds, and some Powershell scripts. This setup works great; I'm productive with it and my command line feels fantastic. However, I have been tweaking my setup for years. WSL makes all of that learning, setup, and tweaking unnecessary.

All of your tools are available out of the box, and you don't have to configure anything, hunt down binaries, or make your own builds.

This isn't about making you and I more comfortable - we already are. This is about making it easier for other devs to find a happy setup on Windows.
Linking to some old HN submission from a known troll blog "The insecurity of OpenBSD" doesn't inspire much confidence.

What I think is that you're stuck in denial and holding onto some preconceived notions, I think you have no clue about the present climate.
The problem is that Vulkan isn't so much a replacement for OpenGL as it is a library that you can use to write OpenGL in the first place, it's another layer removed, and hence requires quite a lot of work to integrate.
I remember TypeScript creator(forgot his name) mentioned that it's extremely difficult to do refactoring right in JS.

Edit: https://youtu.be/lT07c3OREL8?t=713
In the same sense that a C-section is a "stretch".
My personal website was on StartSSL. When the cert expired, I just put almost every VirtualHost on the machine on Let's Encrypt certs.

It's so easy to do and works with multiple Apache sites really well.
>> "The exact sequence of events that led to her losses is complex, so Telegraph Money enlisted the help of fraud expert James Freedman to piece together with Ms Jefferys what is likely to have happened."

This is not how an investigation is done, regardless of if you're law enforcement or not.

Further, none of the statements from the victim support the speculation provide by the expert, nor does the experts speculative commentary appear to be based on investigation in how the bank process works, what information the bank provided, what information the bank has on record to recover an account, how the account was deactivated without information from the customer, etc.
-----

More importantly, this conflicting statement from the expert:

>> Mr Freedman added, “With these frauds, there always comes a point when the victim 'buys’ the story. From that point, evidence to the contrary is ignored or explained away. [...] In cases such as this, it is not the bank’s system that has been hacked, it is the victim.”
You don't unlock reporting comments with the downvote. Source: only have the downvote myself...
In the absence of evidence, what else do you have besides experience and intuition?

I'm not actually making a claim one way or the other, I'm rather questioning one argument in favor of static typing.

There are other arguments for static typing which I agree with, but which are too domain-specific.
In order for TypeScript to understand the types it is interfacing with (especially in the case of libraries) there has to be a type definition created for each library. Dismissing my complaint because "TypeScript is a superset of JavaScript" shows a lack of understanding regarding how the system works.
You made an "edgy" but incorrect generalization based on sparse anecdata. It was good for your comment karma, but it's silly to stand by it.

AirBNB's CAN-SPAM violating email was clearly unethical. A media company showing up on Facebook more than you would prefer is, at worst, mildly annoying. There's an important difference.

Ethical people do not need to leave Silicon Valley. Dishonesty is not prerequisite to success. Your claims are wrong.
Space Emerging from Quantum Mechanics
Problem I have with this is web UI work doesn't greatly benefit from typing - and when it's introduced in whichever way - the apps frequently start using type in conditionals, and generally leads to extra code for no clear benefit.
I've seen a couple of Japanese jaywalk during my trip. But I guess not at 3am though.
Where do you live? If you are in the US then there is plenty of fee free banks, mostly online banks. You seem to be paying more in fees than necessary.
Nothing.

Ethereum/DAO/blockchain's main differentiator is its purported immutability. Tired of traditional actors setting the rules of your financial system? Let some "smarter" more "neutral" hackers set those rules for you in stone cold code.

Discard the DAO and start anew from first principles, but make it clear and transparent that the code is written by humans that can also change that code, and that it's not a magic immutable "distributed autonomous organization" but a collection of dudes on their computers who tinker with the rules of one big excel spreadsheet.

Different dudes than the ones who currently control the markets. Tell me why I should trust these new dudes to have enough gravitas to run a more efficient market.
I think the DAO experience was just one step towards adulthood. We are being very parsimonious thinking that a software application can't be changed as if it was governed by god. In this case it was pure negligence from the Slock and Ethereum people, but this is what happens when babies learn to walk. Probably the next time there will not be a bailout. If you don't like these rules you can move to another cryptocurrency and Ethereum pricing includes this kind of potential events.

"Fool me once shame on you. Fool me twice shame on me"
The threat of hard forks undermines not only confidence in the governance of the cryptocurrency, but also of any application (in the 'make-use-of' sense) of the blockchain.

Specifically, Ethereum was designed with the explicit purpose of running distributed applications that commit their applicaton state into the blockchain. If this state can be subject to a rollback, in the form of forking from a block in the past -- community consensus notwithstanding -- then then you can never rely on the blockchain as storage.

Now, of course, cryptocurrencies only have value if participants believe in them; and these supposed 'smart contracts' of 'state-in-the-blockchain' work the same way. Since we lack the technological means to prevent forks, we need human stewardship to avoid them, and that's clearly not what Ethereum has done.
You can already create legal contracts easily - sign on a piece of paper. This piece of paper is interpreted by a relatively robust legal system with a long history. How is Ethereum going to do better than that if a disagreement is settled not by inspecting the code, but by the opinion of an arbitrary community of miners?
You can add bartenders to that list. But yeah, our society is generally pretty terrible at listening to others. We're very selfish and self-centred, often the only people who listen are those who are paid to.

Oh, should add, not sure if anyone is religious or not but priests and monks are generally good listeners, and free. Sometimes short on life experience though.
http://games.greggman.com/game/dynamic-typing-static-typing/

So we've got data plus my experience plus my team's experience in a large, very successful enterprise on one side, and we've got snark and defense of existing habits on the other? I'll take the risk, I think.
Good question. Someone asked that recently on Github - here's a quick comparison:

https://github.com/jhalterman/failsafe/wiki/Comparisons#fail...
https://en.wikipedia.org/wiki/Yoda_conditions

Yoda code, Wordpress introduced me to the phrase.
There was no hack. The contact executed as designed.

The "hack" was the scramble to figure out how to scuttle a valid transaction.
I paused at that one because I don't like the state's intelligence arm, or it's sub-contractors.

However, I decided it was ethical for the context of this conversation, because to my knowledge they don't lie to grow revenue. They claim they'll charge a huge pile of money to analyze data, and that's precisely what they do.
It is, but that means less than most TS advocates realize.

I mean Objective-C is something like 97% a superset of C... doesn't make the transition any easier.
> Very very small cost.

I've gone back and forth a few times in my career (currently preferring dynamic languages) and would say that the cost is considerable, even with type inference. The trouble is, we don't notice the costs of approaches we're habituated to or prefer, so it feels like they're much smaller than they are. And we don't account for the costs we don't notice, so our cost/benefit analyses (on both sides of the question) are skewed. We all unconsciously put a finger on the scale.

This doesn't stop everyone from making grand, confident claims about static vs. dynamic typing. Such studies as there are don't support these claims, but the studies are weak in so many ways that it's easy to dismiss the ones you don't like and stick to your previous opinion, so that's what we all do.

For these reasons, the debate is pure tribalism and cargo cult. We should stop pretending that our views have any objective support and just talk about them in terms of taste. That's unsatisfying to the technical mind, though, so none of us will!
Using TypeScript in Angular 2 is completely seamless, and I think most consider it the default, so 'b)' is likely close to what you describe. I don't think you could come close to approximating Angular 2's level of TypeScript integration with Ember.

The one caveat is that templates have no type checking or refactoring support. This is fairly standard in html templates in any statically typed language framework, but it is still frustrating and unfortunate. You can safely rename a symbol in TypeScript files, and yet not be able to catch the references in templates without find and replace.
>Once you have some solid offers lined up

Does this actually work for people? My experience interviewing for software engineering roles is that it's a time consuming and tedious process. I can't imagine juggling a full time job while interviewing with more than one company at a time.
That's not true. Even without tree-shaking, Rollup produces bundles that are smaller and faster to execute than the equivalent Webpack bundle, because Webpack needs to inline a module loader whereas Rollup moves all the code into the same scope. They're fundamentally different designs.
Anyone who works with code will know that bugs happen all the time. Semantic bugs can be hard to anticipate, and are sometimes not obvious even to highly knowledgeable reviewers.

The big fallacy underlying the hard fork is the idea that bugs like this will only happen this one time and so the benefit of stealing the money back and giving it to community early adopters outweighs the costs to the institutional credibility of Ethereum.

In reality, there will be many, many more bugs in smart contracts where the intent of the coder does not completely match the behavior of the smart contract in the real world.

The Ethereum community, and notably its core team who wrote the code for the hard fork while claiming to be neutral in the matter, has sent a strong message that it will meddle in the outcome of contracts in which there was no VM bug.

Human institutions are relatively vulnerable to corruption. There is all sorts of graft, favoritism, etc., throughout most human institutions. Ethereum, because of the concentration of power among early adopters, is still vulnerable to this sort of corruption. We've seen it happen with the hard fork.

Is it a big deal? Well, the invisible hand should have awarded the spoils of the theft to the talented hacker who exploited the contract. Those who lost money in the DAO are people who followed a herd mentality and did not insist that the smart contract they trusted be vetted.

Formal verification will help somewhat, as will the improvement of coding practice. I saw some code written by someone involved in the DAO that was written in a way that made it hard to understand the side-effects of various calls. I'd highlight this if doing code review for a simple e-commerce cart, and it suggests that semantic clarity and readability were ranked low on the list of priorities, favoring a denser style that is much more demanding of the reader's understanding of the subtleties of the language.

What is missing is the simple idea of insurance. Suppose investors in the DAO had been allowed to buy insurance against the DAO malfunctioning... This could have been written as a simple smart contract "future" and could have been offered by anyone. So long as there was demand for both sides of the outcome, a price would have emerged to insure one's investment.

So I think we're on a slippery slope, most notably because of the silly idea that this was the last smart contract bug that will be highly significant or controversial.

Cryptocurrencies bootstrap by appealing to speculators who don't really care about the principle of how it's supposed to work, they just want to buy it early and wait for it to get big (as many did with BTC but many more wished they had). This is fine, but we saw the same sort of greed infect a lot more people, and a hard fork (bailout) occur soon after. You can call it adaptability, you can call it a bailout, it doesn't matter. The bottom line is that at present Ethereum is still vulnerable to it and will be for a while. Let's hope Ethereum grows to the point where a small cabal of people who made a bad investment (or hold a particular political view) can't undermine the system.
>Ethical people do not need to leave Silicon Valley. Dishonesty is not prerequisite to success. Your claims are wrong.

Again, you're implying things that I simply didn't say.

>A media company showing up on Facebook more than you would prefer is, at worst, mildly annoying

You're right, that's not spam, but that's not what I was referring to either. I'm not going to write a massive explanation here of the specific Facebook spamming techniques employed by Buzzfeed et al, but suffice it to say that they are actively and aggressively spamming to "prime the viral pump" with certain stories.