That’s not to say all eras are the same. Clearly there’s better and worse times to be alive, but it’s hard to be objective about our childhoods.

get name() { return this.#name; }

Half of this article seems to be based on the author’s unawareness of JS class syntax.

Most of my questions relate to web development — how to do something in HTML/CSS/JS. When I Google, I can almost always find a related questions on Stack Overflow, but both the question and the answers are usually from a decade ago. The techniques they recommend are totally anachronistic by modern standards.

For example, search "how to vertically center a div". The top Stack Overflow result is a question from _14 years ago_, wanting to know how to do it in all browsers "including Internet Explorer 6". And the the accepted answer is a horribly convoluted hack that could be replaced with a couple of line of CSS nowadays.

Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions.

I don't think there's an easy solution, but more empathy on all sides might be a start.

Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I've submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for years.

Fork it? Well there is a big, big difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical.

Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you're stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying "no" to a request, especially a bug fix, no matter how convincing you argue that it's not your fault or under your control.

I don’t eat at McDonalds, but that doesn’t make me think they’re going to collapse. In fact they’re likely successful for precisely for the reasons I don’t eat there.

So yes, LAB will produce more perceptually uniform gradients than RGB, but browsers are exacerbating the problems of RGB gradients by not implementing them properly.

It does.

Eventually it seems the UK gov woke up and blocked a Chinese attempt to take over the board and move the company to China[2]. Now it seems there's a plan to IPO again in London or Nasdaq[3] so the Chinese owners can exit.

[1] https://www.bbc.co.uk/news/business-52275201 [2] https://www.ft.com/content/654a6d68-ef26-47b2-9da5-9029c570f... [3] https://www.ft.com/content/e0c48d30-866d-4efd-9d78-21e49d366...

Also, a few years ago Gilbert and many of the others working on this new game made a retro-styled point-and-click adventure game called Thimbleweed Park[1]. It wasn't a smash hit in terms of sales, but I thought it was a lot of fun, and had some very sharp dialogue and design, and reassures me that the creative team haven't lost their touch and this won't be another Underworld Ascendant debacle.

[1] https://thimbleweedpark.com/

https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...

It appears to me that when it comes to language models, intelligence = experience * context. Where experience is the amount what's encoded in the model, and context is the prompt. And the biggest limitation on Copilot currently is context. It behaves as an "advanced autocomplete" because it all is has to go on is what regular autocomplete sees, e.g. the last few characters and lines of code.

So, you can write a function name called createUserInDB() and it will attempt to complete it for you. But how does it know what DB technology you're using? Or what your user record looks like? It doesn't, and so you typically end up with a "generic" looking function using the most common DB tech and naming conventions for your language of choice.

But now imagine a future version of Copilot that is automatically provided with a lot more context. It also gets fed a list of your dependencies, from which it can derive which DB library you're using. It gets any locatable SQL schema file, so it can determine the columns in the user table. It gets the text of the Jira ticket, so it can determine the requirements.

As a programmer a great deal of time is spent checking these different sources and synthesising them in your head into an approach, which you then code. But they are all just text, of one form or another, and language models can work with them just as easily, and much faster, than you can.

And one the ML train coding gets running, it'll only get faster. Sooner or later Github will have a "Copilot bot" that can automatically make a stab at fixing issues, which you then approve, reject, or fix. And as thousands of these issues pile up, the training set will get bigger, and the model will get better. Sooner or later it'll be possible to create a repo, start filing issues, and rely on the bot to implement everything.