7,416 karma · joined October 23, 2009
Email: charles@codemix.com
In 1998 the Mars Climate Orbiter[0] failed because of a fairly simple software error - an imperial value was treated as metric causing the spacecraft to calculate an invalid trajectory and burn up on entry to Mars orbit. This bug was not detected in testing.
With opaque types this could never have happened, it would have produced a compiler error long before the bug ever made it into production. They eliminate an entire category of bugs.
That is - it is possible that the reason you were discussing the topic is the same reason that advertisers were targeting that particular phrase at that time. The Frequency Illusion could explain why you noticed that particular ad and why you were surprised. Also you presumably discuss topics all the time that you don't see ads for, but the probability of seeing an ad for any of those topics is quite high (the birthday problem).
[0] https://english.stackexchange.com/questions/153166/what-is-t...
npx crossenv foo
instead of npx cross-env foo
you'd have got the malicious version.It looks like this:
import t from 'flow-runtime';
const makeUpperCase = t.pattern(
(input: string) => input.toUpperCase(),
(input: number) => input
);
console.log(makeUpperCase("foo bar"));
console.log(makeUpperCase(123));
console.log(makeUpperCase(false)); // throws
[0] https://codemix.github.io/flow-runtime/#/docs/pattern-matchi...I made a plugin to do this here - https://github.com/codemix/flow-runtime/tree/master/packages...
Edit: Looks like this is targeting compiler output, so Flow types would typically be gone by that stage. Integration with Flow could come via a babel plugin that emits `__assumeDataProperty()` when it encounters a convertible Flow type.
- https://github.com/gcanti/tcomb
- https://github.com/gcanti/io-ts (for typescript)
- https://github.com/codemix/flow-runtime (i wrote this)
And another alternative is to use Design by Contract, like Eiffel:
3 years ago you committed the offence of punning on HN, https://news.ycombinator.com/item?id=5144413
1. Write a long and angry rant about how terrible the software is on a public forum.
2. File issues, participate in the community, ask questions on the mailing list, submit pull requests to improve the docs, try and understand the design decisions behind the software you're using - it's possible that the author knows more about the problem than you, and there are perfectly good reasons for why things are as they are.
One of these things is more productive than the other.