Meet the Bots That Review and Write Snippets of Facebook's Code (ieee.org)

Wave723 writes: To make its developers' jobs more rewarding, Facebook is now using two automated tools called Sapienz and SapFix to find and repair low-level bugs in its mobile apps. Sapienz runs the apps through many tests to figure out which actions will cause it to crash. Then, SapFix recommends a fix to developers, who review it and decide whether to accept the fix, come up with their own, or ignore the problem.

Comments

Automated coding

[Rockoon]

This has always and will always be how automated coding grows.

First it was canned code, such as generated by RAD gui designers. The intent of the code is explicitly defined by the programmers decisions.
Now we are on to some bug fixing. The intent of the generated code is implicitly defined by the programmers code.

Now it will happen quite rapidly. The leap from very explicit to slightly implicit is further than distance from slightly implicit to fully implicit.

Re:Automated coding

[Rockoon]

Yes, but in some countries, "human" bot assisted with scraping python scripts will always prevail and remain cheaper than bothering to develop and code an "AI" style bot.

The majority of user of our new AI Programming Overlords will not develop the AI bot, they will merely purchase a copy of it from one of the first that did.

Then a handful of folks (thats all it takes) somewhere in the world that are already familiar with several of the existing solutions, will write an open source alternative.

So I am not so sure that you've thought about the economics of this very much.

The language wars are going to return because none of the languages we use today are going to matter. Are you on the side of Sloppy Intent Description Language or are you of those garbage coders that uses GNALs Not A Language.

Re:Automated coding

[Junta]

Well, the animated gif (what a terrible way to provide concrete examples) suggest a far more simplistic helper than people are imagining.

Basically their example of it doing it's thing is just finding all instances where a method is called on something and prefacing that with 'if null, return immediately without data'.

Of course I've spent a non trivial time working in a language that pretty much lives that way: Perl. In perl if you go off the reservation, it just keeps on going... somewhere.

Funny thing happens, you don't get 'null pointer exception' behaviors, but you do end up with much harder to fix behaviors resulting from that undefined behavior propagating until it finally explodes in weird behavior for the user. Your application manages to avoid crashing, but the user would have probably been better off if the application crashed. At first I did think it was a blessing because it did save me a lot of tedium since *most* of the time something undef and false was what I'd want a screwup to look like, but now I appreciate a language that breaks immediately when there's any ambiguity possible.

Re:Automated coding

[swilver]

I worked on software like this, that didn't punish the caller (with an exception) when called with bad data. And you're right, the code will just keep going until it hits a brick wall somewhere leaving you scratching your head what went wrong.

The root cause of this is that the models used did not verify data was valid in them, in fact, nobody really knew whether some value would always be present or in what format it would be.

What was worse, the unit tests accompanying this code were the primary source of badly filled models requiring the bad data checks all over the place in the first place to keep them running.

When I became tech lead of my own project, I added verification to all data models used (upon construction) so it would be impossible to store bad or even unexpected data in them. This not only helped us learn what kind of data we could expect and what assumptions we were making about it, but we also discovered blatant bugs in dependent system that would feed us bad data as we would verify it before acting upon it further.

The nice part was that all this bad data checking happened in one spot, localized to the model involved, and all the other code could make assumptions about it without needing to do null checks or other checks. Cleanest code I ever saw.

The bot in the article is just promoting very bad coding practices, and making the problem worse. So much for AI.

Re:Automated coding

[Junta]

Yep, the 'ignore the fact the data came in useless' can create terrible behaviors and gigantic opportunity for security vulnerabilities.

"If (suspiciousthing) securityteam.alert()" clearly means that if somehow securityteam is null, then nothing should happen of course...

Particularly disappointing as the last time I read about this without concrete examples, I gave them the benefit of the doubt. They presumably did something that would be very sophisticated and detect the full obscure paths through execution and then you can determine how to accommodate. Now that I see they basically just preface every call with 'if null return', it's absurd how loud and proud they are about this mess. It's also amazing to call *not* doing that a 'coding error'.

"To make its developers' jobs more rewarding..."

[rsilvergun]

Also, each programmer will be given a parcel of ocean front property in Kansas.

Shouldn't data used to write better code?

[mykepredko]

The tools sound fascinating but rather than using them to discover bugs and propose fixes, shouldn't the data be used to figure out *why* the errors were made in the first place and come up with approaches, procedures & tools that avoid them in the first place?

A Null Pointer Exception is really a failure on the part of the programmer to keep track of their pointers, either they're not initializing them correctly or they are being inadvertently/incorrectly changed during execution. I would think that an analysis of the reason for the errors (ie using an unititialized pointer, setting a pointer to an invalid value either as an incorrect variable value or going outside the bounds of table) should be fairly easy to quantify and then put in procedural fixes that will lessen the probability that the error will be repeated.

Automating the detection process and suggesting fixes will not necessarily improve the quality of the code (unless the "fixes" are properly evaluated for not causing problems elsewhere in the execution of the application) but using the data to understand why the problems are being made and apply changes to eliminate the them from happening again in the future will.

Re:Shouldn't data used to write better code?

[angel'o'sphere]

procedures & tools that avoid them in the first place?
From a sane point of few: yes!
But probably is cheaper that way ... insane, isn't it?

A Null Pointer Exception is really a failure on the part of the programmer to keep track of their pointers, either they're not initializing them correctly or they are being inadvertently/incorrectly changed during execution.
No. They come from programmers not reading the docs. Or languages with no annotations like @NonNull.

Every dumb ass can call a library function that clearly states a parameter my not be null with a null intentionally or by accident.

or ignore the problem ...

[angel'o'sphere]

I like this!! Where can I apply for such a job?