the 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
@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
@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.
@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 @pg @maxkreminski oh, no, i don’t think it’s necessary in order to find good examples of implementation-independent descriptions (and there are certainly many nicer things about modern papers in this regard, like syntax highlighting and searchable text). older papers just help make the point that it is possible to write a paper in such a way that 50+ years later, students/practicing researchers can still read and get something out of it
@chrisamaphone @pg @maxkreminski oh, yeah, good point
@lindsey @chrisamaphone @maxkreminski more generally i think it would be cool to have a paper viewer that exposes 'slices' of the paper for different audiences, like a toggle to "only show me the implementation-independent crux" or a toggle to show just the intro + figures + conclusion for easy skimmability, especially on mobile devices. bonus if it works on tons of existing PDFs (rather than needing authors to adopt new HTML5-based workflows). reminds me of some of @tonofcrates 's ideas