There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.
The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.
I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.
(Holocene or) Human Era calendar
That would represent all human history as one.
And also, the Dekatrian calendar
Where we would have a less broken, more regular, year calendar that is almost align with the moon cycle.
Oh many years ago in school I created something like that for an arts/creative writing project once, a calendar with 12, 30 day month based on sailor moon. Having it based on a magical girl manga gave me the freedom to declare the rest of the days to โdays of evilโ Was a fun project because I created a whole religion around it. ๐
That sounds interesting, would most likely not be very popular with lots of people and a pain in the butt to implement but interesting.
Thereโs a cool video from In a Nutshell about it some years ago.
What resource did you use to master it? As every time I have to use regex I want to cry.
Unicode editors for notes/todo formats, making markup unnecessary.
Does unicode have bold/italics/underline/headings/tables/โฆetc.? Isnโt that outside of its intended goal? If not, how is markup unnecessary?
Does unicode have bold/italics/underline/headings/tables/
Yes, and even ๐๐๐๐ป๐ป ๐๐๐๐ ๐ ฃ๐ ท๐ ๐. And table lines & edges & co. are even already in ASCII.
Isnโt that outside of its intended goal?
๐คท<- this emoji has at least 6 color variants and 3 genders.
If not, how is markup unnecessary?
Because the editor could place a ๐ฏ๐ผ๐น๐ฑ instead of a **bold**, which is a best-case-scenario with markdown support btw. And i just had to escspe the stars, which is a problem that native unicode doesnโt pose.
What about people who prefer to type **bold**
rather than type a word, highlight it, and find the Bold option in whichever textbox editor they happen to be using?
AV1 video codec !
TOML instead of YAML or JSON for configuration.
YAML is complex and has security concerns most people are not aware of.
JSON works, but the block quoting and indenting is a lot of noise for a simple category key value format.
TOML is not a very good format IMO. Itโs fine for very simple config structures, but as soon as you have any level of nesting at all it becomes an unobvious mess. Worse than YAML even.
What is this even?
[[fruits]]
name = "apple"
[fruits.physical]
color = "red"
shape = "round"
[[fruits.varieties]]
name = "red delicious"
[[fruits.varieties]]
name = "granny smith"
[[fruits]]
name = "banana"
[[fruits.varieties]]
name = "plantain"
Thatโs an example from the docs, and I have literally no idea what structure it makes. Compare to the JSON which is far more obvious:
{
"fruits": [
{
"name": "apple",
"physical": {
"color": "red",
"shape": "round"
},
"varieties": [
{ "name": "red delicious" },
{ "name": "granny smith" }
]
},
{
"name": "banana",
"varieties": [
{ "name": "plantain" }
]
}
]
}
The fact that they have to explain the structure by showing you the corresponding JSON says a lot.
JSON5 is much better IMO. Unfortunately it isnโt as popular and doesnโt have as much ecosystem support.
Youโre using a purposely convoluted example from the spec. And I think it shows exactly how TOML is better than JSON for creating config files.
The TOML file is a lot easier to scan than the hopelessly messy json file. The mix of indentation and symbols used in JSON really does not do well in bigger configuration files.
YAML is complex and has security concerns most people are not aware of.
YAML is racist to Norwegians.
If you have something like country: NO
(NO = Norway), YAML will turn that into country: False
. Why? Implicit casting. There are a bunch of truthy strings thatโll be cast automagically.
Thatโs โcountry-istโ. Nothing to do with the genes of people living over there.
People bitch about YAML but for me itโs still the preferred one just because the others suck more.
TOML like said is fine for simple things but as soon as you get a bit more complex itโs messy and unwieldy. And JSON is fine to operate on but for a config? Itโs a mess. Itโs harder to type and read for something like a config file.
Heck, Iโm not even sold on the S-expressions compared to yaml yet. But then, I deal with so much with all of these formats that I simply still prefer YAML for readability and ease of use (compared to the others.)