slver

It doesn't seem that logical statements matter:

https://news.ycombinator.com/item?id=27722154

What matters is just grabbing some pitchforks and cancelling someone.

If you look for racism, you'll find it, even when it's not there. Skin color is a function of two things:

1. Amount of environmental sunlight (latitude).

2. Amount of circumstantial exposure to sunlight (lifestyle).

If the assumption is that early humans have lived more outdoors than sitting in caves all day like the modern human does in practice, then yes they'll have darker skin overall.

Is it racist to just state basic facts, or should we brainwash everything to be uniform and average across time and space?

You're describing features that many other animals have. Being bipedal, hunting, using projectiles, and so on.

Clockrate is not a bottleneck on how fast your computer is. It's just a synchronization primitive.

Think about it like the tempo of a song. The entire orchestra needs to play in sync with the tempo, but how many notes you play relative to the tempo is still up to each player. You can play multiple notes per "tempo tick".

That's kinda the case with Copilot, or I'd just type:

    // Unify relativity with quantum mechanics.

Programming is like working in a team. You try to communicate with your teammates, and then everyone does what they can according to their skills, and how they understood the task.

The shift to higher-level communication in programming is inevitable, will it look like Copilot, I don't know.

Yes, it literally isn't a match. It's also not a match for a pepperoni pizza.

Programming is already conversational. I'm telling a computer what I want, it does it, I see what it does, and elaborate or correct myself where necessary. Repeat endless times, until product exists.

Well, "never" is a long time.

Copilot is definitely no replacement for anything except copying from Stack Overflow for juniors.

But in the long run, AI is us basically us creating our own replacement. As a species. We don't realize it yet. It'll be really funny in retrospective. Too bad I probably won't be alive to see it.

A lot of these edge cases are about theoretical concerns like "how many digits we need in decimal to represent an exact IEEE binary float".

In practice a double is 15.6 digits precise, which Excel rounds to 15 to eliminate some weirdness.

In their documentation they do cite their number type as 15 digit precision type. Ergo that's the semantic they've settled on.

Excel rounds doubles to 15 digits for display and comparison. The exact precision of doubles is something like 15.6 digits, those remaining 0.6 digits causing some of those examples floating (heh) around.

Business types hate dealing with programmers, that's a fact. And these claims of "we'll replace programmers" happen with certain precise regularity.

Ruby on Rails was advertised as so simple, startup founders who can't program were making their entire products in it in a few days, with zero experience. As if.

So, nothing new, is your point?

It's very easy: don't use copilot code verbatim, and you won't have GPL code verbatim.

And these are the hand picked examples. This product seems like it needs some more thought.

Everyone's self-preservation instincts kicking in to attack Copilot is kinda amusing to watch.

Copilot is not supposed to produce excellent code. It's not even supposed to produce final code, period. It produces suggestions to speed you up, and it's on you to weed out stupid shit, which is INEVITABLE.

As a side note, Excel also uses floats for currency, so best practice and real world have a huge gap in-between as usual.

Google is interested in eliminating native applications in favor of web apps that it can control by providing analytics, SEO, ads, and so on.

So they're very aggressive to introducing "app-like" APIs to Chrome even often at the expensive of user experience, performance and security.

As you said, their very goal is turning the web into ChromeOS. And the web is everywhere.

Honestly, that's NOT a good thing for the future of either the web or applications.

And ironically we have no types for units in most languages. Instead we need to wrap numbers in objects making them extremely cumbersome to work with.

The number of sets we can represent with fingers is 11, including the empty set.

As for bijective base 10, it's interesting, but it's still not the base 10 we're using, so we can't quite blame this on our fingers.

The thing I can't seem to get across to you, is that you don't query a graph by specifying a join expression. Graph databases aren't built for that. So no, SQL is not "capable of querying a graph". It's capable of deriving a graph out of relational data. Two completely different things. It's a bit like confusing a restaurant's chef with the restaurant's customer. They both have a meal in common, but one is consuming what the other is producing.

And no, arbitrary join expressions are not a feature that "haunts" SQL databases, because unlike graph databases, relational databases ARE built for that, and it's one of the primary reasons SQL databases are very resilient to change in face of constantly changing ad-hoc query requirements. And it's an important feature of relational algebra that is used every day by countless applications.

SQL and GraphQL serve different purposes at different application layers. Both do precisely what they have to do. The fact they're a bit similar is not coincidental, but also they're not mutually replaceable.

What customers hate is tier 1 support acting as a brick wall between them and the people with the solution to their problem. Or at least that's how they perceive it.

While I don't shout at tech support, as I know what the script is, you better believe my blood is quietly boiling as I'm rebooting various devices that have nothing to do with the issue on their instruction, just so I can get to an appointment with technicians to fix my real issue.

Same thing occurs with GP doctors, and basically every other system in tiers, where it inevitably organizes to basically stall you, so people don't overload the higher tiers.

Sounds like a customer support person just made up a reason.

This happens a lot, I find. People just hate having no answer for you. So they make up one.

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things.

A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query.

GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it backed by graph, RDBMS, file system, NoSQL, etc. etc.) without burdening said structure with capabilities that are not characteristic to it.

Like, if you query a graph, the idea the query may provide any arbitrary join expression would completely drive that graph's performance into the ground.

Everyone is thinking about a "shifted" base 10, yes.

But every base starts with 0, there's no such thing as "shifted base" because then you literally can't represent 0.

Also "zero fingers" is still a thing that exists in this shifted base 10. So it remains base 11.

This is like the classic "0-based indexing" vs. "1-based indexing" dilemma. The "first" thing is represented by 1, we think.

But the "first" year of our life, we're zero years old. The "first" hour after midnight is 0 o'clock. Building your "first" million as a business is the period before you have 1 million. And so on.

Most of us are programmers here, you are just as used to hex.

Also technically we don't have that many fingers. We have one more finger. We don't have a number digit for ten right? They go zero to nine. But out fingers go zero to ten.

If our numeric base matched our fingers, we should've used base eleven. Not many people think this through :)

I think the real breakthrough is having "order of magnitude" in numbers. So indeed the Roman Numerals suck and probably wouldn't last regardless.

By keep up I mean in terms of standards.

Edge was always usable, but you'll always get second-grade experience if apps switch to the "fallback mode" on your browser.

Google is playing this game of quickly introducing standards they're already implementing in Chrome, and choking out the competition. And it worked with Microsoft. Worked with Opera.

Firefox is last man standing.

Typical speeds for "current G + 1" is always high and mysteriously gets significantly lower when "current G + 2" gets introduced. Rinse and repeat.

I'm not sure how come everyone is so highly interested in this churn of networking equipment, it's especially bizarre that telecoms are interested in it (it's a major expense for them), but there you go.

To me 5G is a bit like IPv6. Technically it's better, technically we need it, but in practice we're good enough already. And this is why still a lot of Internet is on IPv4. But thanks to this constant marketing, 5G doesn't have this issue. I'm neutral about it, but I can't care less if my next phone has 5G or not.

If Mozilla no longer plans to move forward with it and use it, it's dead. Nothing can save it. So what does it mean "don't let it die". I mean are bunch of people supposed to develop a modern browser engine on the side as a hobby or something? That's hilarious considering even MICROSOFT couldn't keep up, and switched to Chromium.

The amount of people who think that GitHub Copilot is a good idea is just frightening. Just shows how many people never thought about the semantics of their programs for even a second.

I think it's an excellent idea. People who copy-paste from Stack Overflow will also copy lots of shitty code or use it incorrectly.

But those of us with a clue, have a neat prototyping system where we can modify the solution until it's coherent. It's still on us. Copilot never claimed to produce the best code. And doesn't have to. That's the whole point behind the "pair programming" metaphor.

Poor thing has to move the other figures around so the knight can move. I have lots of sympathy for this machine.

We need to get rid of the idea that websites are designed to work on any one technology.

Otter-Browser uses QtWebKit.

So it's still another entry using the "one" technology, WebKit (which Blink is a fork of as well).

Otter-Browser doesn't change anything at all about the erosion of standards. The only WebKit-independent engine we have still is Firefox Gecko.

Technically it is. But in a very restricted way.

Any graph, when you traverse it from a specific node, with fixed depth, and you don't explicitly work with node references, but rather node "values", looks like a tree that sprawls from that node.

Anyway, PathQuery is a completely different beast regardless.