Earlier quoted context omitted.
Sounds like another short sighted decision. Why don't they support an intermediatory representation that many languages can support. Even yaml would be fine if other languages can generate it. If they had to absolutely use something why not something more main stream and popular like Python. Helm asks too much for the functionality it provides.
-1 for Turing complete config languages.
YAML: Probably not so great after all
391–400 of 457 posts
Re: YAML: Probably not so great after all
#392Earlier quoted context omitted.
I don't aversion to braces. Rather, my issues with JSON is that it doesn't have comments and that you cannot use a optional trailing comma.
And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.
Re: YAML: Probably not so great after all
#393Earlier quoted context omitted.
I take the idea of “design defense” from Pyramid (Python Web Framework) [0], and have incorporated it into documentation on my projects. Basically, it’s a narrative discussion of how this solution came to be, the trade offs involved, and perhaps its relationships with prior art. [0] https://docs.pylonsproject.org/projects/pyramid/en/1.10-bran...
Do you know if this is called something else? (perhaps in other disciplines) Googling "Design defen{c,s}e" just got me a whole lot of military contractors.
Re: YAML: Probably not so great after all
#394Earlier quoted context omitted.
Any reason why you think they're bad? Sounds enticing to me to be able to have a bit of logic in configuration file.
Programming language design and implementation is a huge and hard problem. What you get is an incomplete frustrating language full of semantic oddities and confusions without any serious support tooling to help you out. If you use it in anger, you quickly need all language features e.g. importing libraries, namespaces, functions, data-structures, rich string manipulation etc. But you rarely get these. At run-time, yo…
Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.
So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.
https://web.archive.org/web/20100226023855/http://lutt.se/bl...
>Bad things you accomplish when using Smarty:
>Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn.
>Not really making the code more readable for the designer.
>You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites).
https://web.archive.org/web/20090227001433/http://www.rantin...
>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?
http://www.ianbicking.org/php-ghetto.html
>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
Re: YAML: Probably not so great after all
#395Earlier quoted context omitted.
I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?
I don't aversion to braces. Rather, my issues with JSON is that it doesn't have comments and that you cannot use a optional trailing comma.
Re: YAML: Probably not so great after all
#396The points in the article are pretty solid. But here is a big question. Imagine you can influence the switch of the configuration formats for projects like Ansible, Kubernetes, Docker Compose, AWS CloudFormation, Google Cloud Deployment Manager, et al. You can take any project with huge user base and all of those project will have one thing in common: JSON-based configuration with an option to write this configuratio…
Re: YAML: Probably not so great after all
#397Regardless of the reasoning laid out in the OP, it's difficult to argue in YAML's favor comparing it with JSON. I'm not an ardent fan of JSON either -- both YAML and JSON have issues wrt inconsistencies: - what draft of JSON Schema are you using 4? 7? Neither? - what version of Swagger or OpenAPI are you using? - etc. Sure, it's great to see ongoing development of schemas, but with each new development we have yet an…
JSON Schema is not affiliated with JSON and should not be confused with it. JSON is a data format, like YAML, and there is only one version of it: the spec at http://json.org/ .
Sadly, this is utterly wrong.
https://tools.ietf.org/html/rfc8259 https://tools.ietf.org/html/rfc7159 https://tools.ietf.org/html/rfc7158 https://tools.ietf.org/html/rfc4627 http://www.ecma-international.org/publications/files/ECMA-ST... https://www.iso.org/standard/71616.html
Re: YAML: Probably not so great after all
#398I have a completely unrelated question with the topic but derived from the font-face used in the article. https://arp242.net/yaml-config.html#can-be-hard-to-edit-espe... In the heading, how was sp ligatures in the `espcially` written, is there a name for this? How do you connect the beginning of a `s` to the beginning of a `p`?
These are discretionary ligatures [0]. They're turned on in html with the following two css lines (though on firefox, either one is enough to have them happen): font-variant-ligatures: common-ligatures discretionary-ligatures; font-feature-settings: 'liga' on, 'dlig' on; [0]: https://www.fonts.com/content/learning/fontology/level-3/sig...
Re: YAML: Probably not so great after all
#399Earlier quoted context omitted.
ini if needs are crazy simple, YAML if you need a structure like JSON's but with something any human ever needs to interact with. JSON if humans aren't in the loop. TOML, in my opinion, is like a weird mishmash of JSON, ini, and bashisms. Though I have worked with it a lot less than the other formats, so YMMV.
Since when is JSON not human readable/maintainable??