Re:Programming Languages as Constraints
by catnaroek on Friday June 03, 2016 @08:31PM
(#11834251)
> But that's why we have linters, static analyzers,
Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code.
> style guides,
Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide).
> compiler options and warnings,
No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations).
Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code.
> style guides,
Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide).
> compiler options and warnings,
No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations).
> and ultimately code reviews and good taste.
If only the latter weren't in short supply...