Hacker News Reader

Comment by keithnz | Hacker News Reader

I learned to stop worrying and don't really care, I'll happily use xml, json, yaml or toml . To me, it doesn't really make a lot of difference, and yes, there are a bunch of reasons why various formats have different advantages, but it really doesn't take much of my life, things don't really go wrong with any of them, and while I have a preference, pragmatically, I just don't care.

View on HN

Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter what. Every time a framework makes one thing easy, it makes a couple of other things hard. No matter what tech you're using, there are some generalizable skills that are indispensable for project longevity: good testing, organization of files, consistency in concepts, and thoughtful comments that tell you why things are the way they are.

The idea that we can replace skillful software engineering with the right abstraction just hasn't panned out for me.

Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.

well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.

Standardized parts sound a lot like libraries implementing common interfaces.

Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well.

Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.

While I agree, I always find picking tens of libraries for a project and making sure the dependencies work out to be somewhat difficult.

What would be the way to orchestrate those libraries? Some sort of orchestration library?

I think "orchestratability" is a property of a library. If you start using a library and you find it hard to make it play nicely with other libs, it's probably not a well-designed library.

So you introduce a layer for interoperability. And now your library perf has tanked.

I don’t see how this comment makes sense in context. Surely GP isn’t suggesting that you include an additional tool to orchestrate library dependencies, but to choose libraries that don’t have complex dependency burdens.

If you want two incompatible tools to work you need an abstraction. However because of extra layer of abstraction you suffer performance loss.

> Libraries over frameworks.

I currently maintain a minimalistic website, and using a static site generator has been golden.

I consider that a framework. The moment I need to do anything the framework author didn't think of, I'll end up spending hours. But because I make so few changes, the bulk of the website content is Markdown, and the very limited styling is done with the HTML/CSS templating system. Basically, because this website is a low priority, anything that proves complicated is a bad investment. A framework is great here.

The problem with this is that either you use a framework or you end up writing one ad hoc using your libraries.

Say you use a web server library to help you handle requests on the wire, you’ll probably end up writing something generic where you set up a server, and pass in just the application code to receive the request and return the response which the library will send back.

You just wrote code that surrounds your application code — you made a framework. Then you realize that handling things like logging shouldn’t be in every handler so you invent middleware, you realize that your big ole block of app code is actually lots of small ones in if statements about the path so you factor that out and invent routes, etc. etc.

> or you end up writing one ad hoc using your libraries.

I hear this argument a lot, but I don't think it really ends up working that way. You build an application with some abstractions, not a framework. The difference is that the code you write does what you need, and doesn't need to support a bunch of different use cases. When you need to change it, you can, without worrying that you're breaking someone else's use of it.

And because you only need to support the one application, you can make it as simple as it can be to support that application.

>Libraries over frameworks.

I agree with this but it does have tradeoffs as well. Libraries, especially if they are many and small, can get out of sync a lot. I feel like I spend too much time on dependency maintenance.

The mechanical engineers at my work can barely use a computer. I think I'm good.

That's how you spend days debugging npm dependency hell between libraries instead of coding with your framework of choice.

Have you see how modern cars are built? This [0] is a marketing blog but explains pretty well that in fact they do lean heavily into the "reuse the thing for all the things"

[0] https://www.carexpert.com.au/car-news/platform-sharing-the-m...

You are still looking for the right abstractions just not in the code that makes the application work.

Shameless self-promotion: this is exactly the problem our team hit and is trying to solve at kurtosistech.com. It still Just Sucks to build microservices because you need to know a) what you need to write b) what components you need to glue together (do I want a Dockerfile? what testing framework? what CI/CD?) and c) how to actually implement them (how do I write my Github Actions config? how do Dockerifles work again?).

The Kurtosis hypothesis is that we can abstract away most of these things with automation (e.g. force devs to update the changelog, force versioning of the API, handle all the automated client generation) while still allowing users to pop the hood and do the low-level if they really need to (but popping the hood shouldn't be easy).

Just a bit of feedback: micro service architecture isn’t universally hated (I love my Skaffold setup), and “popping the hood shouldn’t be easy” makes the devops engineer inside of me want to refuse to even read more about your product on principle.

If you’re not building a tool for junior developers only, you might want to change the tone of your pitch to more of a “we make this super slick” instead of “we built black box #93784583”

That's exactly how I feel, except you're always running a risk. Somebody on the team might read the YAML standard and discover a bunch of cool features to use, and next thing you know, you have a lot of lines of YAML that are a razor's edge away from an edge case, and half the people on your team don't understand why. In your config files, no less, the last place you should have to devote scarce time and technical brainpower.

Any sufficiently powerful language has the same hazard. It's natural to want to know everything about the technology you use and want to use everything you know. It's how we expand our skills, and the sheer pleasure of it is why a lot of us got into programming in the first place. But not everybody considers the interests of their team and their coworkers when they choose outlets for that impulse. A single selfish person can run a C++ or Scala codebase clean off the rails.

It takes strong management to make sure the team has good collective boundaries and to crack down on people who go too far. Since senior developers are now largely left to manage themselves, you're at the mercy of the savant who knows 98% of the YAML standard to understand why they're being asked to only use it 70% of it, and to pay attention to the opinions of people who know less (about YAML) than them. Or you can just use JSON or TOML.

Might be worth it to enforce StrictYaml [1], which fulfills all the major use cases and doesn't include the weirder, more complex features

[1]: https://hitchdev.com/strictyaml/

Hum... That's one parser, in one language.

Between all those links there doesn't even seem to exist a design document, much less a full specification for the language.

That is really not enough. If it solves your specific use case, great, use it. But it's not a solution to the YAML problems.

That doesn't seem like anything house rules and code reviews can't fix.

"No fancy YAML bullshit allowed" aaaaaaaand done.

The “code” rot creeps in over the years. Especially so if you work with a lot of people on the team. If they view the infrastructure-as-“code” parts of the project as somehow lesser in stature than the rest of the actual code, then they more than likely see the YAML as a legitimate place to make drive-by tweaks without much care for “code” quality.

Because they are programmers though, they might actually try to make the “code” better:

First they refactor everything using ‘extends:’ to use inheritance for infrastructure “code” sharing.

Then they started sharing “code” between blocks by using YAML references. This removes duplication, except for the edge cases that need to be different. Hmmm.

Then the YAML file became a Jinja / Jsonnet / M4 / C-preprocessed template. That means there’s now another programming language involved so on the upside there’s some hope of finally being able to express computation, but with the downside that it somehow plays second fiddle to the YAML despite the latter having nothing to do with computation.

The downsides of trying to prematurely capture your ideas as config are real. If you don’t focus on all of the key variation points you’re going to see people start hacking and templating at some point. It’s inevitable. I like how Ansible didn’t even try to avoid templating and ran with it straight off the bat.

Config DSLs are hard. OpenSMTPD’s is beautiful but they didn’t get it right until version 6. Even then I bet some people are generating the config. Caddy’s dual approach of letting you use their DSL or give it generated JSON is nice. They have a config DSL for the use cases they could think of, but recognise that there will probably be other cases they didn’t think of, and so support you calling their API with machine built configs instead.

Configuring a system with a programming language is difficult too. If you had a Python module to set up Apache, and your config was particularly lengthy, you can guarantee someone on your team is going to come up with a “clever” abstraction at some point via a pull request that links to the DRY Wikipedia page.

It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right.

VimL carries its scars from this process. At first just a configuration DSL for settings, nowadays the language truly sophisticated plugins are written in.

I'm not decided whether I'd want something vim-like for infra as code. On one hand, in VimL, simple things remain simple and complex things are possible, alas you could say perfect design. On the other hand, everyone who has programmed something non-trivial with vim knows the pain.

I agree with pretty much everything you wrote but:

> It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right.

Are they, though? My impression from various projects involving a good amount of YAML files (for CI pipelines, k8s deployment and such) has been that countless things that take me seconds in python (declare and pass around a variable, find out what a line of code does, find out where else a variable is used) take me orders of magnitude longer in declarative DSLs (like anything YAML-based) than in imperative languages like Python. In 99 of 100 cases I have to either consult the docs (because I don't understand what a given declaration means) or resort to string search (yes, string search) across one or – god forbid – multiple repositories. Meanwhile, imperative code at least tells me what it does and tooling support (usage search etc.) also tends to be very good.

YAML hell is real.

This feels tangential to the article. The article doesn't situate YAML against XML, JSON, TOML etc but against general purpose languages. The differences between the configuration approach and the GPL approach are pretty substantial compared to the differences between individual config formats.

To me that is the axis of discontent though.

To me the badness is something like:

- just want a static unconditional config -> YAML

- ah but I want to pass around some variables -> YAML with some custom syntax for vars

- ah but I want conditionals based on system properties -> ...

And you end up with an awkward programming language with YAML syntax. I don’t much care if it’s XML or JSON at this stage, I just don’t want to write programs this way.

I am very confused by everyone abusing YAML for weird crap. For me YAML is just an alternative to writing an application.properties file (in Spring or Micronaut).

Yes I do use environment variables for secrets/passwords but that is about it.

Yeah, I think 99% of the real-world usage of YAML would trivially convert to JSON. Just static data.

If you need weird complex stuff, use a real scripting language like Lua or something. It should be faster than a YAML parser, at least.

#2 onwarda means you need an API or a library or something. Unfortuntely many app creators dont recognize when their app has passed to stage #2 so we get all these unholy hacks.

In a team of engineers, find one that complains about the configuration formats or linting rules, and with 100% confidence, you know who will ruin your meetings.

Source: empirical study from me

Thanks for not being that person.

The one that sent out the invitation

I'm that person and I don't ruin meetings. I find it's the opposite - there are one or two people that obstinately refuse to allow any improvements and derail meetings with endless naysaying and stuck-in-the-muddery. It's wearing.

Beware the cost of those improvements. I never want to have another discussion about whitespace layout.

I'll accept 2, 4, 8 spaces or tabs, but it should be consistent.

Here's my rule of thumb:

* for new projects, use a well-established, reputable standard

* for existing projects, use what is already in place if it is consistent

* in case of inconsistency, fix to the closest industry standard

My favorite:

* Use an auto-formatter and enforce it in CI

Yeah this is what I was trying to enact. They had sort of done that but the autoformatter had been broken for years and they wouldn't let me fix it and reformat everything.

Git supports revision ignore files for tools like git praise/blame, so that excuse that they don't want to reformat everything to avoid git praise blowout can be easily worked around by checking in an ignore revisions file and pointing them how to use it.

Github even has public beta support for it, though they require a specific name for the ignore revs file: https://docs.github.com/en/repositories/working-with-files/u...

Definitely, as long as it's consistent - I personally like to go for 4 spaces everywhere, I would say it makes the code look easy and readable.

Me, too, it's the default for almost every editor and code formatter. That makes it the most likely choice for projects.

But if this project made a weird decision I'm ok with it, as long as it's enforced consistently.

I can't say that I've ever complained about any one of the rules; it's the constant churn of them that drives me insane.

that's the thing, i wish yaml was just a config format, that it does other weird shit like calling functions is the problem

The article makes excellent points on this very topic.

That's just it, a lot of things are optimized for maintainability or "what if", but in practice, a lot of code or config is written once and only occasionally tweaked; sometimes the whole codebase is just rewritten for something else. In the past ten years or so, I'd guess that the average lifetime of a customer facing website or -app is about five to ten years before it's rewritten by a new generation, a new IT director, or a new batch of overpriced consultants.

I've had one project - consumer investing web application - that has had a number of iterations. a Flash / Flex app, then when the ipad came by and Flash died, a BackboneJS + Bootstrap app, then rewritten to AngularJS, then some ex googler came by and decided it should all be rewritten again in Polymer for some reason. Last I heard is there was "rebellion" and they were building things in React.

I mean I kinda knew it was all futile anyway, but that experience, where years of my own labor was just discarded in favor of an experimental and unfinished technology, made me real jaded about things.

You’re generally lucky then I’d say. The point of the article was to try and see the other side of the equation for those people who do spend a lot of their lives writing long long YAML documents.

If you just need a configuration format for your application then none of this applies, there is however a whole school of tech job that has to deal with this every single day

I 100% agree. They are all just data to read from a flat file. I wish we could just pick one already.

Agreed, so many wasted cycles on all these yak shaves.

Reply on news.ycombinator.com