7 ms·

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / parse / read in many ways - Python has survived this by the skin of its teeth by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't had this - it remains a mess. However, both have that very attractive property of not requiring terminators, which can't really be understated. > if you really care about conciseness, there’s TOML. Are there any serious advantages of YAML over TOML? TOML's got some good properties but its handling of structures with a depth > 1 is far from concise, and pretty terrible if I'm honest.

mjevans 3y ago
TOML's sections remind me of the directory part of a filename and keys files. For the content that belongs in a typical configuration file this or the INI style roots are probably the most human approachable formats. For anything more complex maybe a database (such as SQLite?) is preferable past application bootstrap?
fsniper 3y ago
Reading yaml has the enjoyment of reading a love letter where else json has the deterimental feeling of a solicitor email. For writing, yaml is like putting out the draft, you only focus on the meaning not care for else or the form, but for json it is like finishing up your thesis with hard defined structure.
anoopelias 3y ago
> why anyone ever used Coffeescript CoffeeScript was the front runner for 'Compile to JavaScript' technology. It was the first time we could write some sane frontend code. Of course things like TypeScript came along and now we cannot unsee what we have already seen.
jeroenhd 3y ago
> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.
- lucideer 3y ago
  > it was an advancement That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.
  - jeroenhd 3y ago
    Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, . I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code. I may disagree (_heavily_) with the Pythonesque syntax Coffeescript chose, but it took a while for ES6 to be widely available, and Coffeescript made ES6 features work on most browsers without any additional effort. It's easy to take today's Javascript for granted, but the web was very different back in 2009.
    - d_k_f 3y ago
      In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS. I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.
      - 3y ago
hitchstory 3y ago
>by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't This is why I created StrictYAML. A lot of the pain of changing YAML goes away if you strictly type it with a schema but you keep the readability. Counterintuitively that also includes most indentation errors - it's much easier to zero in on the problem if the error was "expecting status code or content on line 334, got response", for instance.
- _ea1k 3y ago
  That makes a lot of sense, though I'd guess that a lot of yaml-ops types wouldn't want to have to write schemas.
- lucideer 3y ago
  StrictYAML is a great initiative. On the other side of the fence I also love JSON5, for opposite reasons - it's essentially "UnstrictJSON". JSON5 has achieved a reasonably high level of adoption (though I think it's plateaued & I don't see it ever becoming the standard way people do JSON). Would be great to at least see StrictYAML hit a similar level of adoption though - the network effect is so hard to overcome.

mjevans 3y ago

TOML's sections remind me of the directory part of a filename and keys files. For the content that belongs in a typical configuration file this or the INI style roots are probably the most human approachable formats. For anything more complex maybe a database (such as SQLite?) is preferable past application bootstrap?

fsniper 3y ago

Reading yaml has the enjoyment of reading a love letter where else json has the deterimental feeling of a solicitor email. For writing, yaml is like putting out the draft, you only focus on the meaning not care for else or the form, but for json it is like finishing up your thesis with hard defined structure.

anoopelias 3y ago

> why anyone ever used Coffeescript CoffeeScript was the front runner for 'Compile to JavaScript' technology. It was the first time we could write some sane frontend code. Of course things like TypeScript came along and now we cannot unsee what we have already seen.

jeroenhd 3y ago

> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.

lucideer 3y ago
> it was an advancement That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.
- jeroenhd 3y ago
  Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, . I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code. I may disagree (_heavily_) with the Pythonesque syntax Coffeescript chose, but it took a while for ES6 to be widely available, and Coffeescript made ES6 features work on most browsers without any additional effort. It's easy to take today's Javascript for granted, but the web was very different back in 2009.
  - d_k_f 3y ago
    In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS. I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.
    - 3y ago

hitchstory 3y ago

>by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't This is why I created StrictYAML. A lot of the pain of changing YAML goes away if you strictly type it with a schema but you keep the readability. Counterintuitively that also includes most indentation errors - it's much easier to zero in on the problem if the error was "expecting status code or content on line 334, got response", for instance.

_ea1k 3y ago
That makes a lot of sense, though I'd guess that a lot of yaml-ops types wouldn't want to have to write schemas.
lucideer 3y ago
StrictYAML is a great initiative. On the other side of the fence I also love JSON5, for opposite reasons - it's essentially "UnstrictJSON". JSON5 has achieved a reasonably high level of adoption (though I think it's plateaued & I don't see it ever becoming the standard way people do JSON). Would be great to at least see StrictYAML hit a similar level of adoption though - the network effect is so hard to overcome.