Hacker Newsnew | past | comments | ask | show | jobs | submit | frej's commentslogin

Nitpick you wonder why yaml is preferred to ini files when it is lined up to each other.


because inin files have no or very limited support for nesting

there are also some issues with keys being all string by default making some things like linting harder and allowing more less standard ways to get something done, e.g. in json true is true in init files all of true, 1, yes, y and others might be true depending on the application (but then yaml no problem is worse)

also there is no clear single standard for init files

through this is where toml comes from it took the general layout ideas behind init files but give it a strict standard and strict string vs. bool vs. float types and a bit more nesting capabilities and fixes some string distance escape issues, etc


you might want to read this fine piece of propaganda https://github.com/madmurphy/libconfini/wiki/An-INI-critique...


is that satire?

I'm really not sure.

I mean some of the critique is very reasonable like inline tables needing to be inline but inline arrays do not.

But then they present something as INI file which most INI parser will not parse and is directly against much of their previous critique.

and why do I have the feeling that the author is constantly screaming for help internally while writing this article?


INI files are not specified anywhere, so it ends up being a implementation-defined free-for-all.

Also, YAML supports data structures that INI files don't.

I don't understand the hate that YAML gets. If you're not tasked with writing a parser, the data format just works as expected.


> I don't understand the hate that YAML gets

https://noyaml.com/ is a decent overview of exactly how shit it is.

But outside of that, using spaces for logic is extremely error prone if you go past 10-15 lines and 2-3 levels deep.


>https://noyaml.com/

I'm not sure this is the criticism you think it is. Wow, so you basically have to add quotes to get strings in some ambiguous situations?

Yeah sure you could probably improve YAML by getting rid of these weird pitfalls, but that is a minor improvement. The alternative isn't something like TOML, because YAML is optimized for hierarchical configuration. It's every vendor implementing a different syntax such as Hashicorp with their HCL [0].

[0] https://github.com/hashicorp/hcl


> https://noyaml.com/ is a decent overview of exactly how shit it is.

If that site lists all the complains that nitpickers managed to put together, it sounds like YAML is virtually perfect.

Also, to underline how silly and futile these nitpicking complains are, some YAML parsers already explicitly address silly things like the Norway problem.


This has literally never been a problem for me despite writing considerable amounts of YAML.

Frankly, this is a phantom benefit: the first thing people do in brackety-languages is define an indent standard. And it's not like a brackety language magically saves you from mis-nesting things if a bracket ends up misplaced.


just the No string is that it? Other than that I've never encoutered any other problem.

> 2-3 levels deep.

Same to python, all non-trivial code is like 4 level+ depth, big deal!

I normally write javascript and I switch to python easily from time to time. I cannot understand people who complain about spaces.


What about?

    NI: Nicaragua
    NL: Netherlands
    NO: Norway
or

    python: 3.2.3
    numpy: 2.1
or

    octal: 042
Tell me those are well defined or not confusing.


I don't know if it's yaml or jinja, but variations of https://mastodon.communick.com/@raphael/111059057995356737 keeps me wishing that we dropped all these formats and just adopted some type of lisp that could be embedded in all languages.


It's not type safe.


> It's not type safe.

I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.


Yaml coerces values (the string "on" is coerced to bool true for example), with ini you do any conversion from strings yourself


> with ini you do any conversion from strings yourself

INI isn't specified, thus you cannot claim that the INI format does something a certain way.

The best shot at a specified INI file format might be TOML, and even that format is subjected to the same type of criticism.


So is JSON, and all mainstream config formats actually. However, that stopped being a problem with JSON schema, which, despite the name, works on yaml too.


>> It's not type safe.

> So is JSON

Blink. I beg your pardon, JSON is strongly typed per RFC 8259 standard:

> JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).

The type system does not align well with any other type system out there (float/int ambiguity, no timestamps, etc.) but it's still better than any coercion.


It could be that this is plain marketing :).


links are broken :). Looks very cool though.


How can a compiler course not be requeried for a comp.sci degree? We had that. And i’m surprised others do not.


We didn't have compilers in undergrad, but we had formal languages being required.


It's been quite a while, but I believe my school required Automata Theory, which is at least diffeomorphic to Formal Languages.


Ocaml not unbearably slow when say running 10 simple tests. Ocaml is actually amazingly fast and a pleasure to work with.

Sbt is actually worse than dune+opam .

Ocaml has type inference globally so you are not required to spray type annotations at everything.

But Scala does have type directed lookup (type classes/ implicits).

Both have the curse of implementation/typing choices that stops you from doing the actual job ;)


Which feature is prevalent in the go runtime that you must have? Or is it the ecosystem that is larger in go?


Authors wants to bring types to where people are. Simply justifying their work.


I dont think expirements are a way to qualify decades of research that went before.

Second what Sun choose to implement was a smaller subset and not that close to Featherweight Java/pizza compiler. It was only generics, not first class functions at the time, nor algebraic types/pattern matching.


How women are represented in these ads. It is just awful....


Awful? I think you might need to get your outrageometer checked.

I’m old enough to remember being lectured on how prude we are in the States not to have topless women in ads like the enlightened Europeans and Japanese.


Can you be a bit more specific? I took a quick look through all 266 pages, about half of which is advertisements.

Do you mean the ad where:

-p8 a woman sites behind a computer and talks to man/a woman leans on a monitor ?

-p12 a woman reads a print-out next to a man?

-p16 a woman and a man look at a child enthusiastically operating a computer?

-p42 a woman in a gown leans on a computer; text contains the word "beautiful"?

-p62 a woman holds up a piece of hardware?

-p246 a woman sits behind a computer?

Unless I missed quite a few advertisements, or your general meaning, I don't understand the purpose of your comment.


I looked through the pages and saw two ads that had a woman standing with the product. Seems reasonable and unoffensive, especially for 40 years ago and compared to other industries/magazines.


"A Beautiful Way to Interface". Ugh. Yeah, it's really terrible.


or you can think, at least some parts of the culture are moving in the right direction--even if we're not where we should be.


You can set your shell per user in /etc/passwd (or similar, can't remember the name)


It's easy to change your default shell, but if you got a shell script that explicitly specifies #!/bin/sh (and they all do) then /bin/sh will be invoked, regardless what your default shell is. So your options are to modify every script file to invoke your default shell (usually #!/usr/local/bin/sh ) or to install your default shell in /bin.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: