I disagree, having the spec is the first step to building tooling around it. People can port plugins that support this format to vim, eMacs, VSC, etc.. and create functionality around it. For example: reorder into a date view

Still, why plain text? If the goal is “wrap it in UI” why a new white space, special characters.

Why not YAML or JSON and the vetted libraries to read and write the format?

As a user I don’t really have any concern with what underlying data format and structure it stores things in. I want to manage my todos!

This could be an SQLITE file for all I care.

Software engineering should be about more productive UX, not flexing one’s ability to parse arbitrary syntactic art.

> Software engineering should be about more productive UX, not flexing one’s ability to parse arbitrary syntactic art.

Tasks lists are generally useless without their context. It makes sense to have tasks along their context (be it plain-text, markdown, JS, python...) Also it's more maintainable and portable. YAML/JSON/SQlite will be a headache when the user decide to migrate to another tool. This approach only require a text editor, any text editor in any platform. You can plug in whatever you prefer for syncing and sugar.

For a very few cases I use YAML to store data that isn't parsed by any program (only by me). And I can write a comment like 'TODO: Do something.' or "FIXME: X isn't working.' On the terminal using a code searcher and a text editor I can easily find and jump on those.

UX creates context from the users perspective, not the back end data format. This format creates a headache in that nothing can parse or write it except the humans that learn it.

I can easily search an SQLITE file from a CLI (wrote me a tool a long time ago to fuzzy find). I doubt the YAML lib for Python is going to become obsolete soon. I can instantly work with that format on any machine with a common language. There’s already Taskwarrior.

It’s electrons in a machine, hundreds of different paths to porting it around, changing it, etc.

Look, don’t get me wrong; I’m not about to pour sugar down someone’s gas tank. I’m just walking through my inner monologue debating this format someone chose to put up for open review and discussion.

I write data that makes sense to have as normalized in YAML format even if I'm not parsing it in any program because I may do so in the future and YAML is ergonomic.

But for things that shouldn't be normalized I write then as plain-text notes using markdown notation. It isn't true that nothing can parse plain text. I wrote a tool to do that and it works as expected. Of course it's bad design if you look exclusively from the software engineering perspective but ergonomics also matter and parsing text isn't hard.

Don't get me wrong also. I'm just a guy with peculiar use cases and bad experiences migrating away from Evernote and later Joplin.

I think the viewpoints on that are wildly diverse. As far as I’m concerned, it’s the exact opposite. Hence, I think it’s great that there is a big variety of different approaches that everyone can pick from according to their own preferences.

Sure; I’m just expressing mine. The “glyphs and how to display or sort them wars” aren’t important enough to me to take real offense to alternatives. This is just idle discourse for me.

Lindy Effect type thoughts, why import another dependency; familiarity, existing portability, and habits with current formats; deep and wide tooling and language support… road built; let’s drive to shovel poetic drivel out the door.

I think the author is saying there is already a spec, just one abstraction layer above: Plain text. Anything that can read and write text can interact with the to-do list.

In some ways, it is more portable.

I don’t know, honestly I felt the opposite way, maybe because I’m not Ukrainian and it’s not my native language. But I found the level of deep fake we can achieve nowadays truly scary. Even if it was a shoddy job, I feel like that’s enough to convince a lot of people, or at least stir confusion

I don't understand a word of what he's saying, but there's a clear robotic sound to his voice. And that's ignoring that it looks like they put a moving head on a static body or that the lighting on the face doesn't match the rest of the scene.

I think the promise is there... but when I come across a deepfake right now, they often don't seem convincing to me. This one included

could be that you don't realise the convincing ones are deepfakes, and you only spot the bad ones?

The ones we can spot aren't really "deep", they're just fakes.

no doubt you're right about deepfake consequences, but i agree with parent, the quality of this particular one is bad.

IE was free as well, didn't prevent it from turning into a pile of garbage when it controlled like 90% market share, which in turn affected everyone (consumers, developers, etc..)

IE required an operating system I paid money for.

I can run Chromium on Linux with no layout of cash.

That page is not rendering for me on mobile Safari, it’s just giving me a blank page

Are you including the full path? The last part of the URL is the unique store id - It will render a blank page if that's omitted. On my mobile safari, HN doesn't show me the full URL, but when I click on it, it renders fine

Not sure why that would have to be done server side though, couldn’t the server only be used for coordination/maintain state and then submit the current state/positions to the client and the client would render the board?

In his example, there is no client browser. The users are just sending commands into a telegram chat, the app is presumably only able to send API calls based on chat events responses. Its unlikely the app would be sufficiently featured to do the board rendering itself, although I am not really familiar with this space so I'm making assumptions.

As such, the backend would do the heavy lifting of rendering the board, and send the rendered board back into the message group.

I think one’s constrained by the chat application’s functionalities. Telegram doesn’t allow a bot to perform such operations on the client, last time I built one at least.

Of course one might be able to use emoji or text as a representation of said state if the game allows for it.

> When you subsidize something, you get more of it. ... That leads to the question of what educational discounts subsidize. In effect, they subsidize going to very expensive universities.

I’m not sure I am following the point here. Are you suggesting people are signing up to a 4 year university, taking out tens of thousands of dollars in loans (as you mentioned) in order to get a student discount?

In my specific case, the subsidy would be very, very small. In aggregate, discounts, special offers, easier credit, grants, loans and a social affordances add up.

At the margins, subsidies lead more people to spend four (or often five to six) years of their life getting a credential. If you're interested in this topic, I highly recommend Bryan Caplan's book: https://www.amazon.com/Case-against-Education-System-Waste-e...

He also mentioned in the article that, he too, was a broke college student at one point and used to ask people for discounts while juggling multiple jobs trying to get by. Does he not see the hypocrisy in that?

> It should be possible for an amateur to quickly write an SQL validator as a starting project

I think the point he is trying to make here is the same as the post was making concerning orthogonality. Having a smaller set of special syntax, and therefore an easier validator to write, means easier queries to write for the user. I don’t think he was implying that everyone who makes use of the language should know how to write a lexer for it.

> The syntax is just not the interesting part. Any syntax that meets those criteria would do.

I have to disagree with this. If this was the case we would still be programming everything in BASIC or C because they’re just another imperative programming language and it gets the job done. Having sugar syntax, a consistent language, etc.. all makes it easier for a programmer (or data analyst) to get the job he needs quicker (and therefore reduces cost), makes a program easier to maintain, and so on.

The syntax is not the interesting part for programming languages either. Programming languages now have better semantics - things like runtimes, concurrency, data encapsulation, etc. - in addition to better syntax. SQL is not a programming language, its semantics boil down to the relational model. Don't get me wrong, there is room for improvement in the syntax, I have plenty of gripes with it, I just don't agree that it is a fundamental problem. It's already super useful as it is.

Indeed semantics is what matter but I think for example lack of composability is semantic problem too.

<snarky> Ability to manage persistency and correctness of SQL engines is very usefull while language interface not so much. </snarky>