3 ms·

> I’ve never heard of DAG, yet it’s used as if it’s commonplace. DAG, as in direct acyclic graph, is indeed a basic concept of computer science. But indeed th

> I’ve never heard of DAG, yet it’s used as if it’s commonplace. DAG, as in direct acyclic graph, is indeed a basic concept of computer science. But indeed the author could do a better job with the text. One of the very basic principles of technical writing is to always introduce the definition when an acronym is first presented, something like "blablabla a direct acyclic graph (DAG)".

mananaysiempre 4y ago
Wouldn’t really call it a “basic principle”: as with anything else, it really depends on what you assume your audience knows (and you will need to make assumptions about that). If you are describing advantages of your new CRDT over past ones, most likely expanding that into “conflict-free replicated data type” will not help any of your readers; if you’ve come to a statistical physics lecture, “BBGKY hierarchy” might be even more evocative than Bogoljubov-Born-Green-Kirkwood-Yvon (seriously, I know the concept but just had to look up one of the surnames). Of course, it’s possible to speak about either of those things without assuming this knowledge, but this is then a very different talk, most of which will be useless to most of the people who do already have it (not all—it’s useful to occasionally read introductory stuff on topics you think you know!). This is essentially the same thing as power-user usability: it can and does evolve into gatekeeping if left unchecked, and a fresh perspective is a useful check, but assuming everyone is a novice is not the right approach either. (Some mathematics books choose the worst of both worlds: you really do need to know X to read this book, but “to make this book self-contained” we just included a short two-chapter summary of X that instills horror in anyone who doesn’t know it and forces everyone who does to dig through every word searching for conventions or non-standard assumptions. I’ve been in both categories, sometimes simultaneously. On the other hand, other introductory sections of this kind are remarkably crisp summaries that I go around recommending to everyone.)
- arinlen 4y ago
  > Wouldn’t really call it a “basic principle”: as with anything else, it really depends on what you assume your audience knows (and you will need to make assumptions about that). Directed acyclic graphs are a basic computer science topic. There is no way around it. DAGs are introduced in intro to algorithms and data structures courses, right on the first semester of any first year course. Arrays, linked lists, trees, graphs. Far from obscure topics. Well, DAGs lie right between trees and graphs, and are typically the very first type of graph presented to freshmen. Also, DAGs pop up all the time in practical applications.
  - mananaysiempre 4y ago
    I think you misunderstood what I meant (and I failed to check the surrounding language to make sure it was unambiguous where the quote was from). I was referring to you saying (emphasis mine) > But indeed the author could do a better job with the text. One of the very basic principles of technical writing is to always introduce the definition when an acronym is first presented and saying that no, not expanding the acronym is not always a mistake or sign of inferior writing.

mananaysiempre 4y ago

Wouldn’t really call it a “basic principle”: as with anything else, it really depends on what you assume your audience knows (and you will need to make assumptions about that). If you are describing advantages of your new CRDT over past ones, most likely expanding that into “conflict-free replicated data type” will not help any of your readers; if you’ve come to a statistical physics lecture, “BBGKY hierarchy” might be even more evocative than Bogoljubov-Born-Green-Kirkwood-Yvon (seriously, I know the concept but just had to look up one of the surnames). Of course, it’s possible to speak about either of those things without assuming this knowledge, but this is then a very different talk, most of which will be useless to most of the people who do already have it (not all—it’s useful to occasionally read introductory stuff on topics you think you know!). This is essentially the same thing as power-user usability: it can and does evolve into gatekeeping if left unchecked, and a fresh perspective is a useful check, but assuming everyone is a novice is not the right approach either. (Some mathematics books choose the worst of both worlds: you really do need to know X to read this book, but “to make this book self-contained” we just included a short two-chapter summary of X that instills horror in anyone who doesn’t know it and forces everyone who does to dig through every word searching for conventions or non-standard assumptions. I’ve been in both categories, sometimes simultaneously. On the other hand, other introductory sections of this kind are remarkably crisp summaries that I go around recommending to everyone.)

arinlen 4y ago
> Wouldn’t really call it a “basic principle”: as with anything else, it really depends on what you assume your audience knows (and you will need to make assumptions about that). Directed acyclic graphs are a basic computer science topic. There is no way around it. DAGs are introduced in intro to algorithms and data structures courses, right on the first semester of any first year course. Arrays, linked lists, trees, graphs. Far from obscure topics. Well, DAGs lie right between trees and graphs, and are typically the very first type of graph presented to freshmen. Also, DAGs pop up all the time in practical applications.
- mananaysiempre 4y ago
  I think you misunderstood what I meant (and I failed to check the surrounding language to make sure it was unambiguous where the quote was from). I was referring to you saying (emphasis mine) > But indeed the author could do a better job with the text. One of the very basic principles of technical writing is to always introduce the definition when an acronym is first presented and saying that no, not expanding the acronym is not always a mistake or sign of inferior writing.