261–270 of 667 posts
Earlier quoted context omitted.
Having on and no both be Boolean literals, but of opposite values sounds like a horrible decision, a typo doesn't result in a syntax error, but instead in a completely wrong semantic misconfiguration.
1 vs 0 is another typo of Boolean values with opposite meanings, in quite a few languages.
Earlier quoted context omitted.
> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious
I prefer to keep my json to one line without white spaces, saves on disk space.
Earlier quoted context omitted.
Like vim, for example? Which supports replacing tab inputs with spaces...
I code practically exclusively with vim. The replacement is buggy and has many corner cases that come up constantly. As in all editors. Tab indentation has no bugs or corner cases.
Some detail about the corner cases you've run into would be great, if they're happening constantly I can see how it would be a bugbear.
Earlier quoted context omitted.
Like vim, for example? Which supports replacing tab inputs with spaces...
I code practically exclusively with vim. The replacement is buggy and has many corner cases that come up constantly. As in all editors. Tab indentation has no bugs or corner cases.
Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead:
... some lines start with spaces, some with tabs. This looks fine in someone's IDE but the moment you use "diff" or "grep" which adds a prefix, things break and lines become jagged.
... one contributor uses tabs mid-line while other use spaces. It may look fine in their editor with 6 character tabs, but all the tables are misaligned when looking in app with different tab size.
Given how many corner cases tabs has, I always try to avoid them. Spaces have no corner cases whatsoever and always look nice, no matter what you use to look at the code.
(the only exceptions are formatters which enforce size-8 tabs consistently everywhere. But I have not seen those outside of golang)
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”,…
CoffeeScript fooled developers into thinking that transpilation was free and had absolutely no downsides whatsoever. The advantages of CoffeeScript over JavaScript were so incredibly marginal. I've never heard a single good argument about why it was worth adding a transpilation step and all the complexity that came with it.
I think even TypeScript isn't worth transpilation step and bundling complexity these days, especially not when modern browsers allow you to efficiently preload scripts as modules and bypass bundling entirely.
About YAML. It's also not worth it though it's not quite as infuriating as CoffeeScript. The advantage of JSON is that it's equally as human-friendly as it is software-friendly. YAML leans more towards human-friendliness and sacrifices software friendliness. For instance, you can't cleanly express YAML on a single line to pass to a bash command as you can with JSON. It's just one additional format to learn and think about which doesn't add much value. Its utility does not justify its existence.
Earlier quoted context omitted.
How does it compare to dhall?
Dhall's lack of any form of type inference makes it very verbose and difficult to refactor in my opinion. (I'm the author of dhall-kubernetes and never ended up using it in production; funnily enough). Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. This matters a lot to me. I find cue very ergonomic. Also it treating both types and values as valu…
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…
Pulumi is enticing because it allows you to write in your preferred language and abandon HCL, but it is strictly worse in my opinion. IaC should be declarative in my opinion. That allows for greater predictability, reproducibility and maintainability. In general, I think wanting to use Python or Ruby or whatever language you're going to use with Pulumi is not a good basis for choosing the tool. There are many graveya…
Indeed why? However the conclusion I have is not to use JSON but to use a type safe configuration language that can express my intent much better making illegal states impossible. One example of such lang is Dhall. https://dhall-lang.org/
If I’m going to use a whole language to generate my config already, why would I use anything but the language my application is written in? Everything can export JSON after all.
Earlier quoted context omitted.
Different requirements, different guarantees. Principle of least power. Have a look at https://docs.dhall-lang.org/discussions/Safety-guarantees.ht... .
This makes no sense to me. You have complex enough logic to warrant a language, you should use a real language. You'll have more support, less obscure issues, a solid standard library and whatever else you want, because it's a REAL language. If the argument is "someone in my team uses recursion to write the YAML files, so I'll disallow it", then the issue is not with the language, it's with the team. What I have foun…
Not sure what you mean. Dhall is a real language:
Dhall is not a Turing-complete programming language,
which is why Dhall’s type system can provide safety
guarantees on par with non-programmable configuration
file formats. Specifically, Dhall is a “total”
functional programming language, which means that:
You can always type-check an expression in a finite
amount of time
If an expression type-checks then evaluating that
expression always succeeds in a finite amount of timeTo 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”,…
Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates re…
But I agree, it'd be better if the template expansion was actually structural and not just text. The huge amount of "| indent 8" etc. in Helm charts is such a stench that by about the second time people encountered that they ought to have made a better template expansion mechanism top priority.