doubletgl's comments

The status quo, globally, is inequality and suffering for many. What a pathetic way of thinking that this must be defended with violence. It's unthinkable for you that this could be balanced out a bit more?

I'm very glad most of the HN content does indeed satisfy more narrow criteria than "it could be interesting to someone".

Agreed. Someone made a weird font, congrats. Artistic curiosity maybe, but putting this on HN really is a big stretch.

Thought the same, copy-pasting valuable blocks as a reference into a comment worked fine. If it exceeds a one block rewrite, make small dirty commits to keep track of things.

On one hand it's nice that there are tools to support devs who get lost in their undo-redo history, on the other I feel like it's a matter of good habits to not even have this problem.

of course changing habits is hard, so maybe tooling is justified in this case. I'm just happy I don't have nother "history" type mental model to deal with.

When breathing, always bet on air..

Agreed for map, filter etc. but reduce is the exception. There has been a fad of overusing it, until that article popped up which called it out.

Been through this process. Thing is, when you have a <Heading> component, you might as well simply write a css module for that component. Tailwind is great for "fast prototyping" and quickly styling a bunch of static HTML though. Wouldn't use it for a larger single page app.

The network kind.

Ok, so the implementation-awareness lies in the fake itself, not the code setting up mocks. But creating the fake is part of testing, if you follow this approach. So you're still doing implementation-aware testing in the end. Don't get me wrong, fakes are a cool idea. But the article is overselling their advantages a bit I think.

> why should anyone care about someone else’s test architecture, of all things. As long as you neither under- or over-testing, why on earth does it matter?

If you have to maintain tests written by other devs you might start to care. Devs apply different patterns to writing tests and show different amounts of discipline doing so. Some produce lots of duplication ("it doesn't matter, it's just a unit test"), others prefer a complete setup and tear-down before and after every little assertion. I've seen things..

How are fakes, as described in this article, not also implementation-aware testing?

Yeah of course, if I'm already in the process of acquiring some skill, willing to do all the exercises, look up what I don't understand somewhere else, etc., I will learn that skill and the book will help and be a good foundation or guideline.

But the point remains: Just reading the book, as in consuming page after page, is not enough.

Some books explicitly claim to teach you a specific skill. And some people have that general expectation towards books. This is what the author criticizes, as I understood their points.

> Only if you are familiar with programing language that has that same syntax does any of it make sense.

I'd argue that most relational DB users are familiar with a programming language, and therefore most likely familiar with the C-style syntax. It's better to build on something that most of the potentials users are familiar with already.

> There is no distinction between noun "users" and verb "find".

There is no such distinction in natural language either (if you see words purely as sequences of characters), you have to know what is what and infer it from the context.

> even educated non-programmers are gonna be able to read the SQL as SELECT "these things" FROM "this table" WHERE "these conditions are true".

Yeah SQL looks a bit more like natural language at first glance, but that's about it. That familiarity is a false friend, it doesn't really help with the learning curve.

This kind of thinking reminds me of the ruby community trend a decade ago when DSLs were created to look beautiful and like written language. It's useless and confusing for long-term, practical purposes. Same with BDD style testing languages. The promise that non-technical people will feel right at home and can start contributing rarely lives up to reality.

It's not really all that grey currently. The contrast has in fact gone way up.

Post title raises an expectation that is hardly met. So what are the psychological effects? Oh I don't know, here's some random thoughts about C++ code style.

This rather sounds like short term vs. long term decision making, or accumulating debt. What are the "coins" of Greshams's law in your example?

Yes, and it's nonsense.

"I needed something to convert markdown to html", "I like the component mental model", "I wanted to use Node libraries for date formatting etc.", "Next has a great developer experience"

None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".

We ended up painfully removing it from a large frontend project because the custom classes sprinkled everywhere got out of hand and the design started to look more and more inconsistent in a lot of places. Switched to CSS modules (and React components using them) and never looked back.

For the study with cars at an intersection, they simply used the model and make of the cars, so an old toyota vs. a new mercedes for example would be on opposite ends of the spectrum.