3 ms·

> Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea t

> Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die. I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another. I know, I'm not actually editing those plain text files directly. I can, however.

TeMPOraL 3y ago
Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention. Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.) The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously. The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.
- rusk 3y ago
  > The solution is to have a storage format optimized for storage Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it. > writing and editing to be done through tools that render you a representation best suited for what you need at the moment. XML? XSLT? This has been tried and it’s easily done if you want nobody to like you. The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle. The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.

TeMPOraL 3y ago

Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention. Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.) The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously. The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.

rusk 3y ago
> The solution is to have a storage format optimized for storage Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it. > writing and editing to be done through tools that render you a representation best suited for what you need at the moment. XML? XSLT? This has been tried and it’s easily done if you want nobody to like you. The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle. The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.