561–570 of 667 posts
To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…
I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…
> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports
I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my…
GitHub actions would suck whatever you "configured" them in, because you are trying to describe a program in a data structure. Ansible makes the same mistake, as do countless other tools.
Earlier quoted context omitted.
Tabs aren't a problem Spaces aren't a problem. What is a problem is not picking one or the other. There's arguments for both sides but it is critical to just take a side. I'm sorry your side lost but it makes everything better to just go along with the consensus.
At one of my internships in the 90's, a developer I worked with solved the problem by never indenting. Every single line of code started at column 1.
I would have given a lot to have the environment people have today to do science.
Earlier quoted context omitted.
At work we're currently expanding to another country. Which means that many services now need a country label etc., which is fun when you're adding "no" to all our existing services. Luckily it's quick to catch, but man... why?
Yeah, I'm pretty sure there are exactly two substantive problems with JSON for (static) configuration file use cases, which are comments and multiline strings (especially with sane handling of indentation). YAML fixes these, but it adds so much complexity in the process including such a predictable footgun of unquoted strings (the no/false problem is particularly glaring/absurd, but it's also easy to forget to quote…
Earlier quoted context omitted.
implicit in my responses is an assumption that you've worked extensively with jquery so you understand the syntax and how it's functional. If you don't the only response I can have is to go learn it. This isn't about functional being better, it's about functional being more fluid to use in javascript.
I've used it a moderate amount. But I'm not here to argue about how fluid functional code is, I'm here say that OOP works fine, and making slight changes to improve that experience is good. We don't need to actively discourage OOP by making it awkward. Especially when you're not dealing with the DOM, sometimes objects work quite well. The original awkwardness does not show that javascript "was never designed to be us…
this is disingenuous and I'm ending it here. MS spent years trying, and initially failing, to get javascript to work in a more traditionally OOP way.
describing that as slight is something else.
Earlier quoted context omitted.
I have seen this post on HN before and I wasn't received very well AFAIR. But I can't help agreeing with its main point: so much complexity to support a few basic data types that are not sufficient for anything complex anyway.
If you haven't checked it out, NestedText is a great format that offers no handling of types beyond string/list/dict, leaving all that to the application reading in the values. No character needs escaping.
Earlier quoted context omitted.
Ansible has a great module/plugin system. It's trivial to handle complex tasks or computations in a custom module or action.
So why is there this massive ecosystem around not writing modules then? RedHat invented automation controller just so they didn't have to implement proper error handling with Ansible.
Earlier quoted context omitted.
StrictYAML is great (and the author is in these comments!), but ultimately it's one specific library, not a format spec, so to depend on it for a project you need every person/tool doing the writing/parsing to commit to use that library (and the programming language it was written for). Again, it's a great project, but I wanted something similar that is a language-agnostic format specification, so moved on to using N…
It is on my to do list to make a spec and a language independent test suite but both of these things take time.
Earlier quoted context omitted.
I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables. I understand that Ansible was designed for non-programmers, but there is…
I agree. And to make matters worse, the DSL on YAML has grown so large in features, it may as well be a programming language now.
I thought I remembered more comments on that thread, but I guess nothing more than what's there needs to be said.