4 ms·

I read the first few pages of the language spec and skimmed the whitepaper and I cannot find any compelling use case for the system. Even worst, some ideas pres

I read the first few pages of the language spec and skimmed the whitepaper and I cannot find any compelling use case for the system. Even worst, some ideas presented are actively anti-features. For instance the inclusion of all materials that was read: in theory it looks cool, in practice this is a copyright nightmare. Again, the ability the reply every edit is creepy as hell. As an academic (whose job is thus churning papers), hiding how the sausage was made is a nice property of a PDF. Also, important thing is idea laid out in papers, not the exact stream of text that express them.

_pmf_ 7y ago
> I cannot find any compelling use case for the system "Fact checking" is probably the magic word du jour for getting grants and funding.
- jpalomaki 7y ago
  I would assume many high profile publishers would be concerned in getting the facts right. Especially if working with freelancers, there might be interest to see in more detail the creative process. Just a random example for Google about a case, where journalist had been faking things [1]. Maybe there would be also use in areas like technical writing, rules and regulations or contracts. Having errors in these can actually have big financial consequences. [1] https://www.theguardian.com/world/2018/dec/19/top-der-spiegel-journalist-resigns-over-fake-interviews https://www.theguardian.com/world/2018/dec/19/top-der-spiege...
  - _pmf_ 7y ago
    Relotius produced exactly the right facts; they just weren't true.
Cybiote 7y ago
It's worth reading Vannevar Bush on the value of associative trails: https://en.wikipedia.org/wiki/As_We_May_Think#Concept_realization https://en.wikipedia.org/wiki/As_We_May_Think#Concept_realiz...
austincheney 7y ago
> Again, the ability the reply every edit is creepy as hell. As an academic (whose job is thus churning papers), hiding how the sausage was made is a nice property of a PDF. As somebody familiar with version control and open source this is common practice. Perhaps the chain of custody of document edits scares people who do not value transparency, but open source demands that level of transparency and criticism.
- bachmeier 7y ago
  Programming and writing documents are different activities. One reason you don't want to see everything you've ever written is because it is wrong, or maybe you changed your views in the process of writing, or no longer important to the point you're making. I don't see how transparency with respect to edits you've made to a document are relevant if you've explicitly decided that you don't agree with the part that was edited.
  - danShumway 7y ago
    > One reason you don't want to see everything you've ever written is because it is wrong, or maybe you changed your views in the process of writing, or no longer important to the point you're making. I'm not necessarily disagreeing with the main point, but all of these things happen with code too. I've had to counsel people before who were scared to commit code until it was perfect, and I've had to try and push into their head that it's not bad to have Git commits that they aren't proud of. Part of breaking them of that habit was teaching them to be OK with allowing people to see their bad code and bad ideas, but another part of it just came down to teaching them how `rebase` works. On the text side of things, I already publicly commit any edits I make to blog posts, documentation, and any websites I make after publishing -- even if they're embarassing. Occasionally I'll also publish rough drafts if they're not sensitive content. Part of that is getting over the fact that people might see bad writing. If I was worried about people seeing my bad ideas, I wouldn't publish anything in the first place. 10 years from now, I hope that I'll have matured enough that I can look back at my blog and be embarrassed about some of my writing. If I don't have anything to be embarrassed about, I probably haven't grown much as a person. But of course, for particularly sensitive or complicated topics I generally don't push rough drafts. And that's where rebasing comes in. Version/edit tracking isn't just about public transparency. Even with sensitive topics, I still put rough drafts of blog posts in local branches and commit edits while I'm building them. My workflow with private and public content is exactly the same. It's just that when I eventually push to a public repository, I first squash the branch down into a single commit. Transparency with edits is relevant to me because edit history is a personal/org-wide organizational tool. Those edits don't need to be pushed to the public, sometimes they don't even need to leave my computer, but sometimes I like to look over my writing and see how a site/post/article has evolved. History isn't necessarily static. It's very common in version control to rewrite history when needed, and to push different parts of history to different remotes where people have different levels of access.

_pmf_ 7y ago

> I cannot find any compelling use case for the system "Fact checking" is probably the magic word du jour for getting grants and funding.

jpalomaki 7y ago
I would assume many high profile publishers would be concerned in getting the facts right. Especially if working with freelancers, there might be interest to see in more detail the creative process. Just a random example for Google about a case, where journalist had been faking things [1]. Maybe there would be also use in areas like technical writing, rules and regulations or contracts. Having errors in these can actually have big financial consequences. [1] https://www.theguardian.com/world/2018/dec/19/top-der-spiegel-journalist-resigns-over-fake-interviews https://www.theguardian.com/world/2018/dec/19/top-der-spiege...
- _pmf_ 7y ago
  Relotius produced exactly the right facts; they just weren't true.

Cybiote 7y ago

It's worth reading Vannevar Bush on the value of associative trails: https://en.wikipedia.org/wiki/As_We_May_Think#Concept_realization https://en.wikipedia.org/wiki/As_We_May_Think#Concept_realiz...

austincheney 7y ago

> Again, the ability the reply every edit is creepy as hell. As an academic (whose job is thus churning papers), hiding how the sausage was made is a nice property of a PDF. As somebody familiar with version control and open source this is common practice. Perhaps the chain of custody of document edits scares people who do not value transparency, but open source demands that level of transparency and criticism.

bachmeier 7y ago
Programming and writing documents are different activities. One reason you don't want to see everything you've ever written is because it is wrong, or maybe you changed your views in the process of writing, or no longer important to the point you're making. I don't see how transparency with respect to edits you've made to a document are relevant if you've explicitly decided that you don't agree with the part that was edited.
- danShumway 7y ago
  > One reason you don't want to see everything you've ever written is because it is wrong, or maybe you changed your views in the process of writing, or no longer important to the point you're making. I'm not necessarily disagreeing with the main point, but all of these things happen with code too. I've had to counsel people before who were scared to commit code until it was perfect, and I've had to try and push into their head that it's not bad to have Git commits that they aren't proud of. Part of breaking them of that habit was teaching them to be OK with allowing people to see their bad code and bad ideas, but another part of it just came down to teaching them how `rebase` works. On the text side of things, I already publicly commit any edits I make to blog posts, documentation, and any websites I make after publishing -- even if they're embarassing. Occasionally I'll also publish rough drafts if they're not sensitive content. Part of that is getting over the fact that people might see bad writing. If I was worried about people seeing my bad ideas, I wouldn't publish anything in the first place. 10 years from now, I hope that I'll have matured enough that I can look back at my blog and be embarrassed about some of my writing. If I don't have anything to be embarrassed about, I probably haven't grown much as a person. But of course, for particularly sensitive or complicated topics I generally don't push rough drafts. And that's where rebasing comes in. Version/edit tracking isn't just about public transparency. Even with sensitive topics, I still put rough drafts of blog posts in local branches and commit edits while I'm building them. My workflow with private and public content is exactly the same. It's just that when I eventually push to a public repository, I first squash the branch down into a single commit. Transparency with edits is relevant to me because edit history is a personal/org-wide organizational tool. Those edits don't need to be pushed to the public, sometimes they don't even need to leave my computer, but sometimes I like to look over my writing and see how a site/post/article has evolved. History isn't necessarily static. It's very common in version control to rewrite history when needed, and to push different parts of history to different remotes where people have different levels of access.