Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Plain Text Project

plaintextproject.online

Post reply on HN
Print view View original

161–170 of 208 posts

Re: The Plain Text Project

#161

Post by Aardwolf »

tubbs wrote: post #11

I recently just upped my StandardNotes subscription (the Black Friday ad is still active), and I'm now locked in for ~5.5 years. It's a very plain-text webapp/mobile app that aims to be simple and long-lasting, yet feature-full by means of optional extensions. It's not perfect, but I've been using it for a few months now without any data loss/major bugs encountered, and was excited to use it to ditch Google Keep/Goog…

Markdown is not plain text. Markdown destroys your single newlines. Plain text does not.

Re: The Plain Text Project

#162

Post by geraldbauer »

xg15 wrote: post #9
geraldbauer wrote: post #5

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

If your dataset is mostly a list of strings, sure. If it's anything more structured, why exactly? I'd argue that using "plaintext" for structured data (a.k.a, inventing your own data representation) will set up both you and the users of your dataset for unnecessary pain dealing with unescaping and parsing.

> If it's anything more structured, why exactly?

It is way easier to input / type and change / update. And compared to lets say JSON, YAML or friends at least 5x times more compact (less typing is better). See the world cup all-in-one page schedule in .txt [1] and compare to versions in JSON, XML and friends that are page long dumps, for example.

[1]: https://github.com/openfootball/world-cup/blob/master/2018--...

Re: The Plain Text Project

#163

Post by geraldbauer »

xg15 wrote: post #148
enriquto wrote: post #34

Earlier quoted context omitted.

if the dataset is "more structured" you can try to simplify this structure for great gains. As a byproduct, you get to use text files for the data.

Could you give an example?

See above the world cup match schedule [1], for another other examples with geo tree (e.g. country/province/city/district/etc.), see the Belgian Football clubs, for example [2] or for yet another example the Football leagues [3] with tiers (1,2,3, etc.) and cups and supercups, playoffs, etc. The .txt version are pretty compact with "tight" / strict error checking and JSON, YAML and friends I'd say it would be 2x, 3x or even more effort / typing. [1]: https://github.com/openfootball/world-cup/blob/master/2018--... [2]: https://github.com/openfootball/clubs/blob/master/europe/bel... [3]: https://github.com/openfootball/leagues/blob/master/europe/l...

Re: The Plain Text Project

#164

Post by geraldbauer »

nly wrote: post #151
geraldbauer wrote: post #5

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

The football data looks easy for a human to read but a pain in the arse for a program to consume. Personally I think it's terrible, and the fact that they have had to develop a custom 'sportsdb' tool to manage it rather than using something generic like 'jq' is telling. https://github.com/openfootball/england/blob/master/2019-20/... To properly parse this file you need to write a parser that cut fixed-width fields (w…

Good point. See the football.csv project :-) @ https://github.com/footballcsv Here's, for example, the Premier League 2019/20 match schedule example - https://github.com/footballcsv/england/blob/master/2010s/201...

The point is as you say - the .csv format is easy to read / parse / write with a script for automation BUT it's way harder to start from scratch to input / type and keep it up-to-date. That's why you need both type of formats (one for hand-writing and one for easy auto-generation).

Re: The Plain Text Project

#165

Post by geraldbauer »

drongoking wrote: post #21
geraldbauer wrote: post #5

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

I'm confused about what plain text means if JSON and YAML don't qualify. They are non-binary and non-proprietary. Is CSV plain text? And the example URL of openfootball has data files with fixed column positions and square brackets. Looks like you're packing semantics implicitly into the parser rather than leaving it explicit. I don't see why that's an argument in favor of plain text.

JSON and YAML qualify as plain text, for sure. Plain text is a spectrum. Let's say from "free form" english text as your comment to more machine-oriented structured formats like JSON and YAML. YAML, for example, tries to be a more human plain text format than JSON e.g. it supports keys without enclosing quotes or it supports comments and it supports variants and many shortcuts and much more. JSON is pretty "inhuman" if start hand-editing from scratch and NOT recommended, see Awesome JSON Next for "Why JSON is NOT a good / great configuration format" or "How to fix JSON" and so on - https://github.com/json-next/awesome-json-next

Re: The Plain Text Project

#166

Post by geraldbauer »

nly wrote: post #151
geraldbauer wrote: post #5

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

The football data looks easy for a human to read but a pain in the arse for a program to consume. Personally I think it's terrible, and the fact that they have had to develop a custom 'sportsdb' tool to manage it rather than using something generic like 'jq' is telling. https://github.com/openfootball/england/blob/master/2019-20/... To properly parse this file you need to write a parser that cut fixed-width fields (w…

> rather than using something generic like 'jq' is telling.

The best generic tool for managing (structured) data is SQL. Once you have the datasets imported (via the custom readers / loaders) it's just plain SQL (and works with SQLite, PostgreSQL, MySQL, etc.)

Re: The Plain Text Project

#167

Post by markosaric »

loh wrote: post #15

I think more and more people are realizing that simpler is almost always better, and not only when it comes to software. I've found that this approach works best for nearly all aspects of life. The hard part is simplifying complex things. We have so many odd pieces (usually due to legacy reasons or conflicting designs) which don't quite fit into an otherwise simple solution. Plain text could probably work for most fo…

Completely agree. Everything I publish starts with plain text.

I use the basic text editor that comes with the OS or Ghostwriter [1] when I really want no distractions. It's a great, minimal and distraction free editor I discovered recently when I switched to Linux (it does exist on Windows too and there's a macOS beta).

I put it on full screen with dark theme and focus mode on (it highlights the current line and fades everything else away). When I want to go gung-ho I also enable Hemingway mode which disables the backspace key. Love it.

[1] https://github.com/wereturtle/ghostwriter

Re: The Plain Text Project

#168

Post by geraldbauer »

grenoire wrote: post #6
geraldbauer wrote: post #5

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

As great as such formats are for human consumption, they should come with reference specifications and parser implementations to be usable.

You might like the Comma-Separated Values (CSV) Format Specifications (and Tests) org @ https://github.com/csvspecs Trying to improve the world's most popular plain text format (and - surprise, surprise - nobody cares).

Re: The Plain Text Project

#169

Post by JTbane »

chch wrote: post #134
mntmoss wrote: post #33

Recently I decided that I was going to solve the problem of: I easily write inline TODO comments while I work on code, but then have difficulty keeping track of them and getting my head back into the state of things later. While there is IDE support for such things, it's usually not exactly the right interface I want. So I made a tiny CLI app that scans the source for TODO and FIXME lines and presents a menu of files…

Just be careful about Microsoft's Patent US6748582B1; it doesn't expire for another few months. ;) From the patent (edited down a bit): > According to various example implementations of the invention, a task list facilitates code development by assisting developers in keeping track of and managing a variety of tasks, such as errors to be corrected, opportunities for optimization, and other user-defined tasks. As the…

That is one of the dumbest patents I have ever seen.

Re: The Plain Text Project

#170

Post by nojvek »

arminiusreturns wrote: post #160
chch wrote: post #134

Earlier quoted context omitted.

Just be careful about Microsoft's Patent US6748582B1; it doesn't expire for another few months. ;) From the patent (edited down a bit): > According to various example implementations of the invention, a task list facilitates code development by assisting developers in keeping track of and managing a variety of tasks, such as errors to be corrected, opportunities for optimization, and other user-defined tasks. As the…

How is it you are aware of this? Affiliation with MS or a project that ran into it? Wouldn't the key part: " and in response to completion of a task, modifying the task list during the interactive code development session to indicate that the task has been completed." mean it doesn't apply? Worst case, just put a US exclusionary clause in the release so US copyright law doesn't apply. At least Europe is ahead of the…

I am an X-Microsoft employee. Pre-Nadella era, most teams had a patent budget. People would file patents for all sorts of reasons. The game was who can get away with vague-ish patents and collect the most cubes. There was a cube you got per patent.

Needless to say the number of cubes someone had, the more clout they had and it became a dick measuring contest.

There are VPs and distinguished engineers with 100s of cubes.

Post reply on HN