Max Kreminskithe real value of publishing papers as a software person is that even if your code bitrots in two years, even if your company goes bankrupt in six months, you can still burn a record of what you did into the noosphere for your next-generation mindkin
the true audience of a paper is an enthusiastic undergrad in a country you’ve never been to working on something no one around them cares about twenty years after you’ve already left the field
Philip Guo@maxkreminski great thoughts. i teach this in my systems research seminar classes all the time. there's no way to practically run prototype code from even ~5 years ago, but papers from 30+ years ago can still be readable and comprehensible. and papers force us to distill down what's most essential (core interaction techniques or algorithms) and not incidental (e.g., fiddly npm version settings, webpack configs) about our novel contributions
chris martens@pg @maxkreminski
100%. unfortunately, a lot of papers don't even do this. i want to make every CS grad student read classic PL papers from the 1970s if for no other reason than to show concretely what it looks like to write down an idea in an implementation-independent way.
100%. unfortunately, a lot of papers don't even do this. i want to make every CS grad student read classic PL papers from the 1970s if for no other reason than to show concretely what it looks like to write down an idea in an implementation-independent way.
Lindsey Kuper@chrisamaphone @pg @maxkreminski Is it really necessary to go back to papers from the 70s for this, though? Do students get distracted or hung up on the fact that a newer paper will often *also* have an implementation section?
@lindsey @chrisamaphone @maxkreminski maybe because newer papers use languages / tools /platforms that they're more familiar with, so it feels more like describing a piece of software rather than something more generalizable? (at least for more applied sorts of software engineering / HCI tools papers)
@pg @chrisamaphone @maxkreminski I guess what I'm thinking of is that there's a genre of modern "describing a piece of software" PL paper that starts with concrete examples in language X, then a section with some language-independent formalism, and then a section describing an implementation, often also in language X -- so if you want students to just see what the language-independent formalism looks like, you could just point them to that middle section