This paper is excellent for many reasons, but I want to emphasize how approachable it is. Anyone working as a developer can read this and get insights.
This stands in s t a r k contrast to other disciplines (e. g. Physics) where papers are usually ultra dense, making it hard to read even for subject-matter experts.
It's also the language. This paper is written in a way I can easily skim through it and google whatever specific term I don't know. And I'm not even a software or IT professional and don't know what MAKE is.
Physics is a hard science. Software development is applied engineering. I’m sure there are applied engineering fields adjacent to physics where papers are fairly readable by practitioners.
Most developers would struggle quite a bit to read typical theoretical computer science papers.
Computer science is a formal science with empirical elements, as much as I'd like to think of it as a branch of mathematics. I'm not sure what to make of "software engineering" or "software development", academically, but it doesn't really seem to be applied engineering; software engineering students don't study general engineering and then apply it to software, and finally layer some software-specific focus on top. And most developers are still nominally trained in "computer science" rather than "software engineering" or "software development" anyway!
Rather than engineering, the academic discipline of software engineering grows out of computer science, which was born as an area of interest in mathematics. It shows! Because most developers who prepare for their jobs by their choice of major in school typically study computer science, let's consider a typical curriculum: a tiny bit about how hardware works, a small amount of "low-level" software stuff in a class where students work in assembly language, some management science-ish stuff (typically part of the software engineering classes, focused on the development lifecycle, development methodologies, etc.), and a little bit about "design patterns", which is engineering-y but often more qualitative than quantitative in nature. You can often get cross-listed credit for some electrical and computer engineering electives, but they're very much optional. (And many schools don't even have a software engineering program per se, only a computer science program.)
To the extent that software engineering even is a theoretical discipline that can be "applied" on the job, it doesn't share much, ancestrally or methodologically, with engineering. The most they really have in common is that they are broadly speaking puzzle-solving disciplines that often rely heavily on fairly sophisticated formal reasoning.
> Most developers would struggle quite a bit to read typical theoretical computer science papers.
This is probably true, though, perhaps especially because even those who study computer science as undergraduates don't aim to be computer scientists. Their emphasis is reflected in their electives, and they don't continue to study computer science once they join the workforce.
Is this unusual? Can most nurses not only competently but effortlessly read and understand the research output of working medical scientists? Can a one-time biology major typically read and understand contemporary research on micro-organisms without "struggling quite a bit"?
I wrote a paper about how I think trust should work for software dependencies.
It very much builds on the hash-based cache lookup mechanism this paper calls constructive traces (in contrast to what they call deep constructive traces) to eliminate transitive trust relationships.
This paper is excellent for many reasons, but I want to emphasize how approachable it is. Anyone working as a developer can read this and get insights.
This stands in s t a r k contrast to other disciplines (e. g. Physics) where papers are usually ultra dense, making it hard to read even for subject-matter experts.
That's because it's a review paper. There are plenty of computer science papers that are impenetrable, or leave out all the important details.
Build systems don't involve anything really complex. Go and read some papers on unbounded model checking if you want unapproachable.
Most of what we call "computer science" today is nothing more than digital carpentry.
> is nothing more than digital carpentry
Or you could just call it what everyone has been calling it for the past 20 years and say "software engineering."
perhaps although this is a fairly cutesy paper and there are cutesy physics papers too
If physics paper were not dense, they would be 400 pages long. It's still hard to read but in a different way.
It's also the language. This paper is written in a way I can easily skim through it and google whatever specific term I don't know. And I'm not even a software or IT professional and don't know what MAKE is.
Physics is a hard science. Software development is applied engineering. I’m sure there are applied engineering fields adjacent to physics where papers are fairly readable by practitioners.
Most developers would struggle quite a bit to read typical theoretical computer science papers.
Computer science is a formal science with empirical elements, as much as I'd like to think of it as a branch of mathematics. I'm not sure what to make of "software engineering" or "software development", academically, but it doesn't really seem to be applied engineering; software engineering students don't study general engineering and then apply it to software, and finally layer some software-specific focus on top. And most developers are still nominally trained in "computer science" rather than "software engineering" or "software development" anyway!
Rather than engineering, the academic discipline of software engineering grows out of computer science, which was born as an area of interest in mathematics. It shows! Because most developers who prepare for their jobs by their choice of major in school typically study computer science, let's consider a typical curriculum: a tiny bit about how hardware works, a small amount of "low-level" software stuff in a class where students work in assembly language, some management science-ish stuff (typically part of the software engineering classes, focused on the development lifecycle, development methodologies, etc.), and a little bit about "design patterns", which is engineering-y but often more qualitative than quantitative in nature. You can often get cross-listed credit for some electrical and computer engineering electives, but they're very much optional. (And many schools don't even have a software engineering program per se, only a computer science program.)
To the extent that software engineering even is a theoretical discipline that can be "applied" on the job, it doesn't share much, ancestrally or methodologically, with engineering. The most they really have in common is that they are broadly speaking puzzle-solving disciplines that often rely heavily on fairly sophisticated formal reasoning.
> Most developers would struggle quite a bit to read typical theoretical computer science papers.
This is probably true, though, perhaps especially because even those who study computer science as undergraduates don't aim to be computer scientists. Their emphasis is reflected in their electives, and they don't continue to study computer science once they join the workforce.
Is this unusual? Can most nurses not only competently but effortlessly read and understand the research output of working medical scientists? Can a one-time biology major typically read and understand contemporary research on micro-organisms without "struggling quite a bit"?
Or you know, computer science papers. They're all science and no computer.
I wrote a paper about how I think trust should work for software dependencies.
It very much builds on the hash-based cache lookup mechanism this paper calls constructive traces (in contrast to what they call deep constructive traces) to eliminate transitive trust relationships.
https://dl.acm.org/doi/10.1145/3689944.3696169
Co-author Simon Peyton Jones is an ACM Fellow known for the Glasgow Haskell Compiler. https://en.wikipedia.org/wiki/Simon_Peyton_Jones
Neil Mitchell is also an author of Shake which is based on this paper.
Buck and Buck2 from Meta are descendants. Buck2 is an excellent piece of software. Too bad it is still niche.
[dead]