<hmmm-on-a-tangent/>

What if such nasty things also bring about an increased demand for program verification using formal methods?

Yes, it is difficult, but even partial solutions are helpful and way, way better than nothing.

By the way, I ought to look for any surveys on the use of assertions (the little cousins of program verification) in published program sources.

One old textbook I found well worth reading was the one about program specification and software development by Liskov and Guttag.
The first edition, using the CLU programming language.

#ComputerProgramming
#IHaveADream
#FormalMethods
#ProgramVerification
#SoftwareEngineering

@screwlisp

One of the many good uses of assertions is to catch cases that Should Never Happen.
The textbook example is the last branch of a multi-way conditional statement where one of the conditions before the final "else" must always be true.

Another, where there must always be an element to be found:
»    for each x in ...
»    »    if x satisfies ...
»    »    »    return x
»    assert false

#Assertions
#ComputerProgramming
#ProgramVerification

hear me out: a #searchengine that understands what you mean (or at least is coachable).

if I look for "heap state program verification" I certainly don't mean the Ohio Home Energy Assistance Program

#ProgramVerification #plt #proglang

There is a real lack of usability studies for doing program verification with dependently typed languages. But broadening our criteria a bit, there are a couple of very useful studies on the usability of other program verification systems such as Dafny, KeY, Frama-C, and others. You can find my attempt so far at a better overview of existing work here: https://researchr.org/bibliography/usability-of-verification-tools/publications. If there's anything that I missed, whether or not it's using dependent types, let me know!

#ProgramVerification #Usability #ProofAssistant

Usability of verification tools (researchr/bibliography/publications)

I am listening to the @ttforall podcast with Jimmy Koppel on which parts of CS theory all software engineers should learn about (see also his blog post from 2021 on why programmers should(n't) learn theory). Now I'm curious to learn which parts of "theory" you think are the most useful for a software engineer.

Please boost this so this also finds an audience beyond the types community!

#SoftwareEngineering #Education #TypeTheory #ProgramVerification #AbstractInterpretation #ProofAssistant #HoareLogic #ModelChecking #SMT #OperationalSemantics #CategoryTheory #DomainTheory

Type Systems / Type Theory
25.4%
Runtime Verification (monitoring, instrumentation, ...)
11.7%
Control-Flow and Data-Flow Analysis
13.2%
Abstract Interpretation
4.6%
Formal Verification for Functional Programs (Curry-Howard, dependent types, proof assistants, ...)
10.2%
Formal Logic for Imperative Programs (Hoare logic, separation logic, ...)
9.6%
Automatic Program Verification (model checking, SMT solvers, ...)
8.1%
Operational Semantics (small-step and/or big-step)
8.6%
Semantic Models of Computation (category theory, domain theory, ...)
5.1%
Something else (comment below!)
3.6%
Poll ended at .
Type Theory Forall - #29 Can PL theory make you a better software engineer?

Type Theory Forall is a podcast about Type Theory and Programming Language research in general. We interview relevant people in our field.