To have a good paper, either one must have a very compelling result (which usually means solving a problem that someone else posed and whose solution is regarded as important and non-trivial by the community), or be able to tell a 'story' that motivates why the paper is worth reading.
After much work, I came up with
We give a rational reconstruction of some common (and
not-so-common) data-structures that arise in functional
programming. Our categorical approach also leads us to defining
standard functions which ought to be in all reasonable libraries of
data-structures. Being systematic in the exploration of the design
space reveals quite a lot of structure and information about
data-structures and their origins.
as a solid approach to our story. In fact, I then spent quite a bit of time crafting a few paragraphs (see the contents of TandDS.tex) laying out that story for our audience.
And then I read something entirely different in POPL19.org. It talks about Abstract Syntax Trees, serialization, remote execution, compositionality schemes, dynamical systems -- all neat stuff, but also all over the map, with no coherent thread. It has neat "slogans" that are correct -- but belong to a different story altogether.
Then the write-up falls prey to a simple diseases: what-I-learned-last disease. Just because one's most recent 'discovery' is at the top of ones' mind, and seems really cool [especially when it is], does not automatically make it the best thing to start the story with! (I see you, dynamical systems). One needs to carefully think about the audience, and lead them along from knowledge they likely already know towards new knowledge. Papers like T&DS need to be very pedagogical.
Upshot: Either we,
Go with the story I started in TandDS.tex, or
You propose a different story to @WolframKahl and I that you think is better.
Then when all 3 of us agree on what story to tell, we all write that story, and stick to it.
JacquesCarette
commented
4 years ago
To have a good paper, either one must have a very compelling result (which usually means solving a problem that someone else posed and whose solution is regarded as important and non-trivial by the community), or be able to tell a 'story' that motivates why the paper is worth reading.
After much work, I came up with
as a solid approach to our story. In fact, I then spent quite a bit of time crafting a few paragraphs (see the contents of TandDS.tex) laying out that story for our audience.
And then I read something entirely different in POPL19.org. It talks about Abstract Syntax Trees, serialization, remote execution, compositionality schemes, dynamical systems -- all neat stuff, but also all over the map, with no coherent thread. It has neat "slogans" that are correct -- but belong to a different story altogether.
Then the write-up falls prey to a simple diseases: what-I-learned-last disease. Just because one's most recent 'discovery' is at the top of ones' mind, and seems really cool [especially when it is], does not automatically make it the best thing to start the story with! (I see you, dynamical systems). One needs to carefully think about the audience, and lead them along from knowledge they likely already know towards new knowledge. Papers like T&DS need to be very pedagogical.
Upshot: Either we,