2zcon

>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.

Or a real person who didn't have braces?

I know it's useful because I used it every day during a holiday in Japan. Menus, tickets, signs.

>you have to trudge through two decades of websites to discover anything

>type :help<Enter> or <F1> for on-line help

This is not for show!

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.

Where have you seen this?

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.

I didn't interpret the letter as laying out a plan that must work.

I understood:

- If governments stop funding coal, coal goes down.

- Governments are likely to stop funding coal.

- Coal is likely to go down.

- This risk isn't adequately represented.

That's out-of-scope for an email to bank leaders.

If you don't know already: we (in the UK) have our own NRA. It's much more like CAMRA than the US NRA.

Then you spend the whole movie obsessing about if it's true or not, making it even worse.

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.

OK but if you're a competent, adult software engineer it should be fairly easy to overcome that problem.

Having been in a taxi with a driver who bragged about staying up all night on stimulants, I disagree.

>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.

I don't see Singapore's public housing system coming to the Western world any time soon

The intro screen tells you exactly how to open help and exit. Man gives you even clearer instructions.

It's over 50% at £50k if you have a plan 2 student loan

Do you know a rough percentage for how many wind-turbines in use are modern turbines like these?

But we're not intuitively familiar with what happens when those stars get really big and start being black holes and exhibiting relativity. Fortunately, like waves, we can manage the maths.

If you get pulled over and have your fake plates ran you've already lost any gains from skipping tolls. If they're using ANPR, they don't even need to pull you over.

I had this exact discussion at work.

Say you have test(X). X is a random number in range A to B.

Say someone else has test_range(A, B). Instead of running for one input, it runs test for the full range of inputs.

Actually, both tests run on the same set of inputs. The difference is that, for the first test, you're not running all of the inputs at once. You're running some of the inputs with your commit, some with a colleague's later commit, some when a customer downloads the program and tries to run it... by making the input random, you're accepting the possibility of merging code that sometimes fails the tests.

And, actually, it will take you far more time running code to run the full set of inputs because there's nothing preventing you from running the same test twice.

So then I'd ask why you're not just running the full set before you commit. If it's too expensive to run, my opinion is one or more of:

A) You should be running fuzzing 24/7

B) You're using randomness as a means of avoiding deciding the inputs yourself because you don't the problem space

C) There's not actually a need to test the full set, X being 222348 is isomorphic to X being 222349.

>On the one hand, I understand the argument that random data makes your test irreproducible; so if something breaks the test, it make take a while to figure out exactly what and why fails the test.

Usually I see random tests saving the seed if they fail.

There have been multiple other UK cities with proposals for congestion charges which have been rejected. Transport doesn't really work the same way outside of the M25.

Payment providers already sell this data to the finance sector.

And the other IO device? People absolutely will tell you you're typing the wrong way.

>that's a pretty obvious hint that there's something wrong with the tool.

Or that the problem space is inherently difficult.

That's definitely a possibility I didn't give the proper consideration. On the other hand, if I wrote that sentence with that intention, I would strip 'actually' it for being unnecessary.

Overthinking? Well I can hardly characterise this tangent as important.

>random three-letter combination that is pronounceable, and not actually used by any common UNIX command.

>actually

Many native French speakers use 'actually' when they mean 'currently' because of the 'actuellement' false-cognate. This looks like the same mistake but neither Swedish nor Finnish have a word that looks like 'actually' when I machine-translate 'currently'.

Any ideas?