Derek Jones

I would also really love to read a statistics-based approach to all of modern software engineering. Like, does SOLID actually increase bugs? Is Agile more likely to slow things down? Etc. This is the closest I’ve ever found: http://www.knosof.co.uk/ESEUR/

Those kind of discussions have various effects, some of which I believe to be far from moot. First, they permit that some people even take notice about this situation. Few developers read the standard and even less write it or follow the discussions to change it (are they even open?) or write a compiler for it. The rationales are not even tracked [1]. It actually would be insanely hard to get a good understanding of those subjects by e.g. just reading the standard, without having those kind of discussions on forums typically used by more devs than just a few dozens of compiler writers... [1]: but while I'm thinking about it, an impressive independent book as been written by Derek Jones: The New C Standard: An Economic and Cultural Commentary http://www.knosof.co.uk/cbook/cbook.html

I do agree, that book is really great, both very in-depth and at the same time entertaining to read. Unfortunately, it appears to have been out of print for a while now. Another book I can highly recommend is "The New C Standard: A Cultural and Economic Commentary" (http://www.knosof.co.uk/cbook/cbook.html). It takes apart the C language standard (C99) pretty much sentence by sentence, explains what it means and also contrasts how C99 is similar to or different from other languages (C++ mostly, but also, say, Fortran or Pascal).

> Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. Actually, the people saying "you won't see the parentheses after a while" are a significant subset of advocates of Lisp, who know the language well! Here's a quote from the old Common Lisp FAQ: "After you've written and read enough Lisp, you stop seeing the parentheses. (Reports vary from a few days to a few weeks.) They don't disappear in some magical way, but you start to see the structure of the code rather than just "lots of fingernail clippings". We all agree that it's important to be able to see the structure of code. But if your goal is to not see the only marker with important information, then there's a problem. > Infix languages introduce a set of context-dependent symbols. That is not required at all. That conflates infix with precedence. What developers want is infix, not necessarily precedence. In practice many developers avoid using precedence, in fact, a large percentage don't understand the precedence rules of the language they're using all. In Algol-like languages, they just use parens to force all evaluation orders even when they are not necessary. If your infix system doesn't support a built-in precedence, there are no context-dependent symbols. For example, in curly-infix, {2 + 3 + 4} => (+ 2 3 4), but there is nothing special about "+". The expression {2…

This has to be the best, industrial study comparing programming languages that I’ve seen. They’re doing it on the same system. There’s details to assess what was difficult, what got fixed the most, and so on. Summary: the developers collectively had more C experience than Ada experience, many were using Ada for first time, the Ada developers had fewer defects with gap getting wider with experience, and the Ada features cost less. A clear win [in one project] for Ada. That conclusion also brings to mind the practice we’ve seen (eg at NASA) about using C over Ada so developer familiarity with C reduces risk. The idea was learning a new language with its gotcha’s will increase error rate in their project. It was a good hypothesis but was refuted in this particular project. Worth some studies to test it further. Got it out of Derek Jones' references on empirical data in software engineering if anyone wants to dig out more good ones. That's a huge list of papers to go through. http://www.knosof.co.uk/ESEUR/ESEUR-references.html

You might like to review the book Evidence-based Software Engineering, which is freely available online: http://www.knosof.co.uk/ESEUR/

Critical thinking, as it applies to the practice of software development. Reading/watch list: - Thought and Knowledge: An Introduction to Critical Thinking, by Diane F. Halpern - Understanding Arguments: An Introduction to Informal Logic, by Walter Sinnott-Armstrong, Robert J. Fogelin - Predictably Irrational, by Dan Ariely - Evidence-based Software Engineering - http://knosof.co.uk/ESEUR/ESEUR.pdf - A Philosophy of Software Design, by John Ousterhout - https://www.coursera.org/learn/mindware This is research for a book I'm writing on that topic.

Evidence-Based Software Engineering: based on the publicly available data http://www.knosof.co.uk/ESEUR/

Lack of empirical results is a recognized problem. I do however know of one effort to dig out and bring together data sets - http://www.knosof.co.uk/ESEUR/ Even in experiments where it's very easy to make a study replicable by simply sharing the code, many people do not. I take this as evidence that the goal of research is rarely good science.

Well yes, but that kind of testing has also proven to be a waste of resources(1). So an automated tool may be the only path forward as far as testing goes. Whether this one adds value or not is hard to say as their documentation is extremely sparse (probably why they made the tool in the first place). 1) http://www.knosof.co.uk/ESEUR/

Have you checked out the book (PDF here: http://knosof.co.uk/ESEUR/ESEUR.pdf )? There are 2000 footnotes referencing published studies. It's not perfect, but hopefully there are enough different views all triangulating on "truth" to provide value.

Actually somewhat interesting is The New C Standard: An Economic and Cultural Commentary - http://www.knosof.co.uk/cbook/cbook.html