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
Elliot Cuzzillothe 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
Not a Spring Onion@maxkreminski
Actually, that computer vision/contour detection algorithm paper (that I tried to reimplement) was also written by a German 30 years ago.
Actually, that computer vision/contour detection algorithm paper (that I tried to reimplement) was also written by a German 30 years ago.
Peter Brett@wakame @maxkreminski Hang on *precisely* which computer vision/contour detection algorithm?
Thanks to my perfectly organized system (I lied, took me a while):
Zamperoni, Piero (1981):
"A note on the computation of the enclosed area for contour-coded binary objects"
(Okay, that's more than 40 years, but I re-implemented it in 2017, so... still closer to 40. 
)
@wakame @maxkreminski Hah, I was wondering whether it was the same German ridge detection algorithm that I had to reimplement in 2010–2012 for my PhD research. Apparently not!
The #ImageProcessing literature is full of papers that give you half of the mathematics you need (incorrectly) and then some pretty pictures of what you might get if you spend 6 months figuring out how to implement it from scratch.
The paper I mentioned contained a list of numbers that (incorrectly, IIRC) described half of the algorithm
Publishing raw data, source code and similar essential artifacts should be a requiremnt for publication...
Åsa M Larsson@maxkreminski
Honestly, I was this undergrad. 😊
That obscure paper about Latvian Neolithic pottery in a conference publication no one had checked out in 20 years was fascinating! 🙏
Honestly, I was this undergrad. 😊
That obscure paper about Latvian Neolithic pottery in a conference publication no one had checked out in 20 years was fascinating! 🙏
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.
@chrisamaphone @maxkreminski ohhhhh yeah! even my Ph.D. work now feels 'old' but i'm glad i wrote it down in a somewhat 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
@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
@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
Dr. Dan Killam@maxkreminski I was like this as a grad student talking to a guy who was previously a prof but became a sysadmin. Talked clams with him a few times
Fabio G.@maxkreminski It's me. I'm the enthusiastic undergrad
Huh. What do you mean i'm a PhD student