Hacker News Reader

Comment by noway421 | Hacker News Reader

This is dangerous. Instead of acquiring understanding, a tool like this lets the programmer just write the code which passes tests. Without the deep understanding of algorithm you can't write sufficiently full tests which assess program's correctness. TDD wouldn't save here, because instead of being a tool of discipline it becomes a list of instructions for codegen.

Would anyone want to ride in a car or fly in a plane written by set of sporadic tests? I wouldn't risk it.

View on HN

Of course nobody should write production software with this, that's why the project loudly says that this is a PROTOTYPE. It is experimental software.

These kinds of tools are the future IMO. It's a higher layer of abstraction. Most programmers have no idea how their programs are actually executed--we write in a high-level language and rely on voodoo to execute it, without a "deep understanding" of how it's really executed, and without writing instruction-level tests. And it works great. I don't see how this is theoretically different, it's just a higher level of abstraction. Of course, its utility greatly depends on the practicality of its implementation (which includes performance)...

> it becomes a list of instructions for codegen

That describes exactly the everyday programming languages that we all use.

You don't need understanding of all deeper levels, you just have to know the system til the first non-leaky abstraction.

Concrete concepts are a good foundation of correct code, no matter how high level they are.

Fun fact: when you board on a plane, you have no idea how good its hardware, software and test suite is beyond common “it didn’t crash n-thousand times before” knowledge.

the engineers who made and maintain it know everything about it

Given how large those systems are, how much layers (OS) of code there are, and the turn-over in software companies, I am pretty confident that no single engineer know everything about.

"engineers" - it's been decades since anyone on the planet could know everything about a whole system, but each engineer knows everything about their subsystem

Which is why I won't fly on certain airlines :-). As a Software Engineer who worked at an avionics company, I know who our big customers were and what bugs are in the products they bought, so I avoid them whenever possible.

most hardware and plenty of software for that hardware is sourced all around the world...engineers involved make assumptions based on how that stuff should behave, perhaps even run it through tests of their own...but they hardly know _everything about it_

You might be surprised by how much safety critical software is built by code generation tools like SCADE. It's not entirely the same thing, but the programmer is pretty removed from the final product and it is very spec driven.

As a TDD, I really don't care too much about the implementation as long as my tests pass. Performance however is another issue, but that's something that can be optimized and re-written into something like this depending on the language.

But how do you know you have sufficiently full tests which assess program correctness, to paraphrase the parent?

That is a skill requiring study and practice.

I call it "being a good programmer."

Property-based testing, preferably with with heavy use of design-by-contracts style pre/post/invariants checking. Ideally also mutation testing.

Reply on news.ycombinator.com