D enters Tiobe top 20
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Fri Nov 8 16:33:48 UTC 2019
On Friday, 8 November 2019 at 16:10:32 UTC, Doc Andrew wrote:
> With sufficient pre & post-conditions on "unsafe" functions,
> (and maybe, as somebody pointed out, some asserts along the way
> to "nudge" the solver in the right direction), you can prove at
> that nothing bad happens with an automated solver.
If you talk only about memory safety and require that programs
are written in a certain way, then maybe yes.
In the general case this will not be possible though. You
certainly need to manually guide the verifier (e.g. "nudge" the
solver with asserts). The search space is vast. Keep in mind that
when humans do proofs in math they do a lot of pattern matching,
use a high level conceptualization of the problem space and only
do it on "toy-sized" problems.
> I'm not an expert, and it's only a hunch, but I suspect that
> DbC + CTFE could make formal verification of D code a lot
> easier to implement than trying to graft it on to other
> languages.
Formal verification is never easy, but certainly less difficult
when the programming language is designed with that in mind... D
is too flexible.
And that's only for single-threaded programs. Add multi-threading
and you basically need the programming language to be designed
for it to get anywhere realistic. Such languages do exist, but
they are not going to give you C-performance.
> My take is that formal verification is sort of where AI/ML was
> 20 years ago - academically interesting but of little practical
> use. Now it's a big deal, and I think in 10-20 years, FV will
> be too.
I think FV is where AI was 70 years ago...
But yeah, maybe neural networks can be used for matching up
verification problems with strategies so that the verifier
succeeds more frequently, but the fact that an automated verifier
frequently will fail to reach any conclusion will remain for
practical programming that aim for very high performance in the
forseeable future.
A more likely future is that processing performance will be in
abundance and that you therefore don't have to write programs
that maximize performance and can switch to languages and
algorithms that are easier to prove correct...
More information about the Digitalmars-d
mailing list