Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

651–660 of 667 posts

Re: Why are we templating YAML? (2019)

#651

Post by incrudible »

mcculley wrote: post #341
incrudible wrote: post #296

Earlier quoted context omitted.

An XML document without a schema is strictly worse than JSON without a schema. JSON with a schema is strictly better than XML with a schema. XML structure does not map neatly into the data types you actually want to use. You do not want to use a tree of things with string attributes, all over your code. If you do have a schema, the first thing you will want to do is turn your data into native language data types. Aft…

> JSON with a schema is strictly better than XML with a schema. I am baffled by this assertion. XML Schema (XSD) is much more expressive than JSON Schema.

That is a bug, not a feature.

Re: Why are we templating YAML? (2019)

#652

Post by mcculley »

incrudible wrote: post #651
mcculley wrote: post #341

Earlier quoted context omitted.

> JSON with a schema is strictly better than XML with a schema. I am baffled by this assertion. XML Schema (XSD) is much more expressive than JSON Schema.

That is a bug, not a feature.

Not to me. I have lots of data exchanging going on where the format is expressed well in XSD and in JSON Schema it is expressed through documentation, code, and a history of angry emails.

Re: Why are we templating YAML? (2019)

#653

Post by ParetoOptimal »

BiteCode_dev wrote: post #610
ParetoOptimal wrote: post #599

Earlier quoted context omitted.

> Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. Everyone wants type-safety, but no one wants to wait for the type-checker :) Maybe in this case dhall with type checks equivalent to dhall would be slower, but I notice in many places people say "strong type-checking is valuable" while still expecting similar compile times as languages with weaker…

People always undervalue the beauty of a short feedback loop until it's taken away from them. And even then, they won't exactly pin point the problem, rather express their general frustration, without realizing that the dynamic system they used had indeed some great properties and were not popular for no reason.

I don't disagree with that either :)

I'm conflicted honestly. I find with dynamic languages it's easier to just spin your wheels and move quickly in the hole you are in.

With typed languages its easy to feel you are making less progress because the feedback loop can be longer, but generally the pieces you build are more likely to work correctly.

For me Haskell and ghci repl gives good properties from both areas, especially with something like Rapid for keeping state over repl reloads.

Re: Why are we templating YAML? (2019)

#654

Post by usrbinbash »

eviks wrote: post #649
usrbinbash wrote: post #647

Earlier quoted context omitted.

> You've argued that ugliness is a solution I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession. > while the problem that needs to be solved is ugliness That's your opinion. I never argued that this hack solves ugliness. I argued that it solves the problem of not having a way to comment in JSON...which it does. I never clai…

You just persist in failing to understand the issue > I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession. I can raise it to the level of the entire history of humanity when I say that people yearn for cleanliness and beauty > I never argued that this hack solves ugliness. Sure, because "you choose to ignore [the problem of…

> You just persist in failing to understand the issue

And you just persist in making a "counter" based on your opinion of what my argument is, as opposed to what my argument is actually about.

Re: Why are we templating YAML? (2019)

#655

Post by eviks »

usrbinbash wrote: post #654
eviks wrote: post #649

Earlier quoted context omitted.

You just persist in failing to understand the issue > I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession. I can raise it to the level of the entire history of humanity when I say that people yearn for cleanliness and beauty > I never argued that this hack solves ugliness. Sure, because "you choose to ignore [the problem of…

> You just persist in failing to understand the issue And you just persist in making a "counter" based on your opinion of what my argument is, as opposed to what my argument is actually about.

Not "actually", but as opposed to your opinion of what your argument is about

Re: Why are we templating YAML? (2019)

#656

Post by Dylan16807 »

PH95VuimJjqBqy wrote: post #648
Dylan16807 wrote: post #639

Earlier quoted context omitted.

I'm not interested in the effort to get that particular change in, I'm asking for you to elaborate in this broad effort you're implying beyond that. If I misread you, and you're not implying something broader and that's the only change they fought for, then yes it is quite small. To be extra direct there: I didn't say the effort was small, I said that change was small. You can have a big effort for a small change. So…

stop trying to weasel-word your way to being right, people fought MS and largely ignored them for years. There was a time when you didn't use the class keyword because it was non-portable because MS wasn't collaborating with anyone. But more importantly, this all started because I pointed out that javascript is a functional language. This remains true, which is why writing functional code in javascript ends up with a…

Asking what you meant is not weasel wording, goddamn.

(Some of the distinctions you're making still make no sense to me because you think they're so evident you won't elaborate, but at this point it's definitely not worth the effort.)

Re: Why are we templating YAML? (2019)

#657

Post by incrudible »

mcculley wrote: post #652
incrudible wrote: post #651

Earlier quoted context omitted.

That is a bug, not a feature.

Not to me. I have lots of data exchanging going on where the format is expressed well in XSD and in JSON Schema it is expressed through documentation, code, and a history of angry emails.

If it can't be expressed as a JSON schema, it's a bad idea. If it can be expressed by a JSON schema, it may be a good idea.

Re: Why are we templating YAML? (2019)

#658

Post by mcculley »

incrudible wrote: post #657
mcculley wrote: post #652

Earlier quoted context omitted.

Not to me. I have lots of data exchanging going on where the format is expressed well in XSD and in JSON Schema it is expressed through documentation, code, and a history of angry emails.

If it can't be expressed as a JSON schema, it's a bad idea. If it can be expressed by a JSON schema, it may be a good idea.

This does not match my experience.

Can you provide some clear explanation or examples of why having less power to express a schema is desirable?

Re: Why are we templating YAML? (2019)

#659

Post by incrudible »

boredtofears wrote: post #497
incrudible wrote: post #299

Earlier quoted context omitted.

Besides being aesthetically similar to SGML, because it maps to HTML, JSX has nothing to do with XML. It is Javascript.

It's literally shorthand for "Javascript XML" and its templating syntax is the same as XML. It has a lot to do with XML.

JSX stands for JSX. Your definition is something that people just imagine to be true. The React docs do not mention the word XML at all. The “templating” syntax is not XML. It has no defined semantics and does not generally support crucial XML features like namespaces.

Re: Why are we templating YAML? (2019)

#660

Post by oever »

unshavedyak wrote: post #630
oever wrote: post #545

Earlier quoted context omitted.

I see Nix as a powerful way to write config files. It is purely functional, so the only thing it does is create a build recipe. That build recipe is then run by other Nix tooling. A .nix file is either a config file itself or a function that returns a config file or a function. By passing in enough parameters, you get the configuration. I've not seen as clean a way of doing this anywhere else. Guix uses Guile which i…

The problem is (to me) it's entirely obtuse. I can't call the function and get back some configuration - which is insane to me. You have to pass in all sorts of state, and you have a lot of difficulty producing the exact same state as your config in question would see in a real execution. Or at least i do. I even asked on several forums and the answer kept boiling down to "Well, it's just not easy. Sometimes not poss…

The parameters you pass in define your dependencies. For a program to compile it needs the compiler and that is a complicated dependency. One might think that only passing the paths to the dependencies would be enough. That way the inputs could be much simpler indeed. I guess there's room for a simpler Nix.
Post reply on HN