>His two front teeth (red box) are different shapes and sizes. The teeth on the right side of his mouth have not been rendered properly at all. An analysis of Max’s facial features suggests he has more in common with an AI-generated fake than with a real person.
I do understand it but, for my colleagues and friends who don't have English as their first language, it adds another caveat to learn and remember without a logical basis. That's another place to introduce ambiguity and errors.
I don't get angry at non-standard usage but I think it's important not to ignore the purpose of consistent style.
>the people who needed it more and were willing to pay more got it
And there the idealism breaks down. Willing to pay more - which you always are if it becomes a life-or-death situation - does not mean able to pay more; able to pay more does not mean deserves it more.
I only know not to write things so complex because either I have made the mistake or some generation of someone I've learned from has made the mistake. It's not a logic problem, where the less complicated, better understood and more general rules of precedence allow writing equations that are terse, objective, and easily parsed by humans: it was born with C's invented, abstraction-breaking rules of precedence. You only learn it with a C-like language. What's a bit to a mathematician?
I'd argue the practices that are most popularly known as 'good practices' are to avoid mistakes that are common.
Isn't that the same for most open-source software[1]? To a Wikipedia editor going into a programming project to correct documentation, it might seem absurd that we want them to 'pass CI', 'squash the commits and correct the message column width to pass the code style', or 'sign the CLA'.
[1] It's a very prettied-up domain-specific language but it's still copyleft software.
If there are multiple ways of achieving the same result (e.g. assignment) and you want to be consistent, you have to choose a subset. If there are features that time has shown to be less-than-ideal (e.g. malloc/free) you choose a subset while the language avoids removing breaking backwards-compatibility.
So when you go to another project that made different decisions, what you should do is understand the decisions. It's quite easy. And that's why it's what people do do, and it's why people are capable of contributing to projects other than their first.
If you program in C++, it's the same skill you used to learn one or more of {CMake, Makefiles, scons, bash, python} except it's easier because you already understand the programming language's model.
Much as I didn't mean to insult anyone with my post, I'm sure you meant to add value by calling it petty and fallacious.
Picking up features in a language you already use is easier than learning the language to begin with which itself is easier than learning to program at all. If you were able to read the documentation to get to 50%, you have all the skills needed to pick up the rest and get to the difficult part of picking up a new project: understanding the problem space. If you're capable of learning the meaning of an API you've never seen before - and you will, if you're not writing your last project verbatim - then you're capable of learning what a lambda means. This is not me saying that all programmers should be able to do this, it's me saying that doing this is a predicate of engineering software.
>I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device.
You would be amazed how many of the big players are doing exactly that. But I shouldn't talk about it any more, I work for one.
Or a real person who didn't have braces?