phpnode

Computerised spreadsheets were inevitable, we've been using spreadsheets in some form for thousands of years. Visicalc is recognised as being the first, but Excel has been the dominant product for decades now, for all its warts it has had a massive impact on humanity.

Cool article. I'm the author of https://github.com/codemix/babel-plugin-typecheck mentioned and the next version of the plugin (WIP) takes this kind of approach, so that you can reference a type at runtime:

    type User = {name: string, isAdmin: boolean};

    // compiles to
    const User = t.object(
      t.property('name', t.string()),
      t.property('isAdmin', t.boolean())
    );

    // which you can then use with
    User.check({name: 'Alice'}); // boolean
    User.assert({nom: false}); // throws

Ultimately it should be possible to use this to implement pattern matching in JS based on flow types, for example:

    type User = {
      name: string;
      roles: Role[];
    };

    type Role = {
      id: number;
      name: string;
      users: User[]
    };

    const url = match(someInput, 
      (user: User) => `/users/${user.name}`,
      (role: Role) => `/roles/${role.id}`,
      (_) => `/` // default URL
    );

The really hard thing is to do this whilst maintaining perfect compatibility with flow.

It's a full dress rehearsal, the only difference between static fire and a real launch is that they do not release the hold-down clamps and shut down the engines instead. The cameras would have been rolling.

> Aren't the Babel people trying to define a common standard format for the AST so different parsers and code generators can better work together?

Actually kind of the opposite - babel used to use the common ESTree AST format, but they've moved away to something similar but incompatible.

It's not a random sequence of characters, there are only 12 words in there. The cracker is trying words, not just random bytes and so the search space is much smaller

Rainbow tables aren't really a thing any more, you can calculate a hash much faster than you can download one

That's a very different attack vector to the one in this post - buffer overflow vs legit service running on open ports unbeknownst to the user

Still waiting for you to make good on this promise :)

GDC = Global Development Centre

We're all here to learn, if you've got some insight into what the article got wrong then why don't you school us?

Looks refreshing! http://d2ydh70d4b5xgv.cloudfront.net/images/2/c/vintage-mark...

I've never seen a type system expressive enough to cover all the things that contracts can do, e.g does a type system exist which can assert the existence and size of a particular file on disk?

Contracts are just structured assertions, they're very similar.

Your argument seems more like one against transpilers in general.

Contracts are useful during development, they're typically stripped out in production builds, so there's no performance overhead there. If you find a bug in production, turn on your contracts and you'll quickly discover the source of the error. Contracts can validate the state of the world at runtime in a way that can never be covered by unit tests, unless your tests cover all possible inputs to your program. It doesn't mean you don't need unit tests too, they are yet another layer of safety.

I use this in combination with Flow, which means I have to transpile regardless, so the overhead is very low for me. Of course I'd like them to be part of the language proper, but for that to happen there needs to be developer demand first.

Limited Partners

It's definitely most useful when combined with type annotations. They're complementary tools, annotations can ensure type safety at compile time, but type safety is only one part of program correctness, whereas contracts can validate just about any aspect of program operation because they have access to all of the runtime information. They're like unit tests that run all the time (until you strip them in production at least).

This thing can be used alongside Flow[0] and other babel plugins which use flow syntax.

[0] https://flowtype.org/

It's always baffled me why more people don't seem interested in adopting design by contract, it is a ridiculously powerful tool for writing quality software.

Here's a Babel plugin which adds design by contract to JavaScript, squeezing it into existing JS syntax (the result is really similar to Eiffel) - https://github.com/codemix/babel-plugin-contracts

and here's what it looks like in a reasonably complicated program - https://github.com/codemix/malloc/blob/master/src/index.js

(disclosure: I wrote this)

No SIMD intrinsics yet

Fried. Not deep fried. No one would do that.

You wanted to open a bank account in Germany, yet couldn't ask even the most basic questions in German? And you characterise this as a failing of the other party (the bank)? That is insane!

I think you'd run into escaping issues like that. It would have to be:

    <JavaScript src={`[1, 2, 3].map(n => n + 1)`} />

Do you have a link to that poem?

It bothered me more than it should have that you used isuckat@passwords.com instead of isuck@passwords.com for your example :)

That doesn't need to be true for this to have happened. Zuck is a high profile target, probably the hackers just prioritised cracking his account and such a weak password would be found reasonably quickly even using bcrypt

You are asking a question, I do not owe you an answer, it's up to you to find out whether this stuff matters for your use case. I've done these tests myself, it is trivial for you to do the same. Do your own homework.

By the same token, why do I owe you any further evidence?

Check out the Bluebird benchmarks [0], or you can easily try it for yourself - create a simple web server which does some makework async task, like stating a bunch of files, then benchmark with ab or something better.

[0] https://github.com/petkaantonov/bluebird/blob/master/docs/do...

The call itself is relatively expensive, but as you say it's a one off call at startup time and the methods it produces are faster than explicit promisification using `new Promise`, they are blazing fast :)

Bluebird's `promisifyAll()` is just a way to generalize that pattern, so that you don't need to write it yourself. And if you care about performance it's substantially faster too. If you want to learn about the pattern then fine, but personally I don't want to write that for every single `fs` function I use in a project, it's much more convenient to just `Bluebird.promisifyAll(require('fs'))`.

Presumably instances of `MyObject` can be accessed by functions which are running while this function is suspended, waiting for the network call. It's single threaded, as in only one thing happens at a time from JS's point of view, but other functions can be invoked (by a request coming in, or a UI event etc) while an asynchronous operation is awaiting completion.