HN user

2zcon

58 karma
Posts0
Comments47
View on HN
No posts found.

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

Pizza Effect 6 years ago

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

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.

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.

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.

The History of Git 6 years ago

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.

The History of Git 6 years ago

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?