dekimir

Author here, AMA.

I looked into this while making RamFuzz[1], but parameter generation (QuickCheck) is quite different from input-blob evolution (AFL). It wasn't clear to me how best to leverage a parameter mutation that happens to increase coverage. Ultimately, I decided that random generation (without guidance by coverage) coupled with AI classification of test outcomes is the most interesting approach.

[1] https://github.com/dekimir/RamFuzz

I like Beck's vision for the future, and I agree that we should keep experimenting in order to learn which tests tend to work and why. But we don't need to do it all manually -- we can use computers to automate and speed up such experiments. To that end, I've started a project to automatically generate unit tests from C++ source: https://github.com/dekimir/RamFuzz

Right now the generated tests are pretty superficial and silly, but the key is that they are randomized. Because of this, we can run millions of variations, some of which will prove to be good tests. Right now I'm hacking an AI that will pick those good instances from many random test runs. If it works, we'll be able to simply take source code and produce (after burning enough CPU cycles) good unit tests for it. This will be a huge help in letting the human programmer only do "enough" test writing -- the AI will take care of the rest. Additionally, the solution can be unleashed on cruft code that no-one dares touch because of a lack of tests and understanding.

(Yes, there will be a business built around this, but that's for next year. :)

Before I left Google, I worked on this briefly and produced this PR: https://github.com/WebAssembly/design/pull/708

It summarizes the discussion so far between various stakeholders. I've since moved on to other things, and I don't know where the effort currently stands.

> it's almost always possible to reason and quantify and weigh the cost versus the benefits

I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.

> despite many share references, most people are in environments which apply Scrum in a slightly different way

Exactly. In fact, the linked text is a prime example: it professes to address the "standard Scrum as described in the official guide", and then goes on to condemn the notion of story points. Now, I happen to agree with those story-points criticisms, but guess what: that official guide says nothing about story points at all! :o

In my day, we'd use moderators: put the forum/list in a mode where every new post goes through a human review first. After a while, things calm down, and you revert to the anything-goes default.

I don't know how well that would work for high-traffic forums of today, but it can scale pretty easily by employing many moderators.

http://www.netlingo.com/word/moderated-mailing-list.php

There is an effort under way to ensure wasm debugging is at least as easy as JS debugging: https://github.com/WebAssembly/design/pull/708

It's hard to speculate how the culture and philosophy of web development will change, so let's leave that aside and consider what's possible to do. It's certainly possible to compile into wasm a desktop program in a high-level language, even a program with a GUI. When the browser runs that wasm, the user will interact with your GUI instead of HTML elements. See webassembly.github.io/demo.

More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.