See also GOTO which is a wart 99.9% of the time but really useful for writing e.g. parsers.

Error handling.

In most languages there are better way to do this than goto. Among them - extracting code into smaller functions (yes, state has to passed around) - exceptions (yeah yeah, hate them or love them, but if used in your environment it makes sense not to avoid them) - RAII pattern or handling cleanup, which allows simple return and "automatic" resource handling - etc.

True, in a language like C these don't apply necessarily and goto still has some use -

Parsers (or more generally state machines) and error handling are the two places I've seen that are acceptable. We've managed to complete the list. :)

NPM themselves recently launched a new package called npx [0] which will download and execute packages directly from the registry if you don't already have them installed. So if you make a simple typo like this:

    npx crossenv foo

instead of

    npx cross-env foo

you'd have got the malicious version.

[0] https://www.npmjs.com/package/npx

crossenv was already running the script on post install, which means it was run on "npm i crossenv" anyway.

point is that npm are encouraging you to use npx, which is bundled with npm 5.2+ as a general tool for executing adhoc commands from the terminal. It just massively increases the chance of typos.

At some point there needs to be some trust, and NPM puts that boundary at installation. If you trust a package enough to install it, then it's allowed to act on your behalf with the permissions of your user.

`npx` doesn't change that dynamic. It's no different than installing an RPM or Debian package over the internet.

Imagine if Debian decided that `sduo rm *` meant it should apt-get install the sduo package and run immediately it.

I know my systrems system wouldn't last 5 minutes.

Surprising given that Slack's performance is something people regularly complain about

Or.... it's not surprising at all.

Surprising because it's probably the lowest hanging fruit possible

I fully agree.

My thoughts are that there must be a lot of low hanging fruit, judging by the way a chat app can rev up my maxed out Macbook Pro.

If you collapse all of the animated GIFs that does significantly reduce resource usage, even when the app isn't in the foreground.

At least there wouldn't be a crosswind

Not just the 80s, until at least 2000 and probably a lot longer

You did a great job with this, I started something really similar about 6 months ago because I wanted to port SabreDAV to js (I didn't quite get to the stage of self hosting PHP parser) but eventually came to the same conclusions, even with a good codebase idiomatic PHP does not map cleanly to idiomatic JS

Guessing you got downvoted because it's not really relevant - live editable code is nice for docs but doesn't explain why a property is poorly named.

I understood the OP as saying they couldn't figure out what "mb" meant because the author didn't define it in the text. I noted that there was another path to figuring out what it meant, by changing the live-editable code and seeing what it does.

Having a live-editable example is certainly nice, but you shouldn't have to fiddle around with a parameter to see what it does. It should be clearly documented so that you know what to expect and what the intention is. Otherwise, the behavior that you observe could be a bug for all you know.

Its also useless for discoverability. Sure, you might be able to figure out some code you read in an example through trial and error, but you won't learn what's actually available.

It would be nice to be able to use the annotations directly, we support this in flow-runtime[0] but I think it would be fairly straightforward to support in TypeScript too,

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...

Shouldn't the uppercase of a number be a string?

    const makeUpperCase = t.pattern(
      (input: string) => input.toUpperCase(),
      (input: number) => '' + input
    );

Otherwise you get odd behaviours like:

    makeUpperCase('1') + makeUpperCase('1') = '11' (probably what you want)
    makeUpperCase(1) + makeUpperCase(1) = 2 (probably not what you want)

...wait. Why would the uppercase of '1' be '11'? It would just be '1'.

I had to reread it a few times to parse it. Its result of "adding" the uppercase of 1 that should be 11, not the uppercase itself.

In other words, the result of "makeUppercase" should be a string, not a number.

I see it now.

Yeah probably, but it's just an example

Is this the most Hacker News title of the year so far?

Sometimes legitimate accounts trip a spam filter and get shadow banned, if you go directly to the comment's page (click the time link) there's a `vouch` link you can click to vouch for that person and restore their account.