Yeah, this is the problem with frankensteining two systems together. Giving an LLM a prompt, and giving it a module that can interpret images for it, leads to this.

The image parser goes “a crossword, with the following hints”, when what the AI needs to do the job is an actual understanding of the grid. If one singular system understood both images and text, it could hypothetically understand the task well enough to fetch the information it needed from the image. But LLMs aren’t really an approach to any true “intelligence”, so they’ll forever be unable to do that as one piece.

Same honestly. And if I ever ask a question that someone might think is a duplicate, I link to that question and say something like “I found X, but the answers here don’t reflect Y”.

I’d be very surprised if anything functional actually comes out of this. Far more likely they get scammed out of the money by garbage like the current “AI writing detection” methods, with terrible success rates that cause more societal problems than they solve.

Oh, what an interesting idea! I like this, on Monday I’ll test out switching to this as my main search engine for work and try to report back how it goes!

Seems like a sensible overhaul, hitting the major issues with the fee, but still going ahead with a version of it. Big points for me:

• Not retroactive. Only affecting the next version of Unity, and you can even opt out of updating to skip the fee.
• Data is now reported by the customers. Still not sure how that plan to enforce this, but it’s a hell of a lot better than some arbitrary data collection scheme being baked into the game.
• Free version is excluded. No charging tiny side projects, or students or something, it only affects already paying customers.

Still not sure I love charging per install as a concept, and they’ve already overplayed their hand and burnt many bridges, but at least this implementation isn’t insanely hostile. Guess we’ll see how this plays out from here.

Having used tailwind a little bit, I have nothing but praise for it. Effortless copy/pasting of components with confidence, really nice look by default, easy tweaking, absolutely no management or planning required to organize your CSS, and it’s all right there, directly on your html, never anywhere you have to hunt for it. Feels very freeing to just… not think about CSS at all.

And the “clutter” really is fine, modern IDEs with good syntax highlighting, plus a tailwind extension to help complete the class names and clean up accidental duplicates or conflicting properties, and you’re good.

This is very intriguing… I actually work in CBC (nowhere near content or with the social media people who’d make these kinds of decisions), but as a developer I get 20% time to dabble with anything I think might be useful. I haven’t used it in a while, but a CBC ActivityPub instance may be just the right project, especially if it can auto-publish our content from the same feeds that power our site.

I also feel like a lot of the value of chronological is lost if I think it’s algorithmic recommendations. If I don’t know I’m browsing the latest? I’ll likely just think the algorithm is serving up some garbage. Especially somewhere like Facebook, where people haven’t really been curating their feed for years, just… following whoever to be polite and letting the algorithm take care of it.

Eh, I’d assume the comparison isn’t flattering. I think the point of this article is to argue you don’t need ElasticSearch to implement a competent Full Text Search for most applications. Splitting hairs over a few milliseconds would just distract from that point, when most applications should be prioritizing simplicity and maintainability over such tiny gains in a reasonable dataset.

Might be interesting to try to analyze at exactly what point elasticsearch becomes significantly useful, however. Maybe at the point where it saves a full tenth of a second? Or where it’s returning in half the time? Could be an interesting follow up article.

Eh, the python one will probably perform better, because sum is probably written in native C under the hood.

Great read!

I think a bonus point in favour of composition here is the power of static typing. Introducing advanced features like protocols can bring back some of that safety that this article describes as being exclusive to inheritance.

Overall, I think composition will continue to be the future going forward, and we’ll find more ways to create that kind of compilation-time safety without binding ourselves into too restrictive or complicated models.

Alright, guess I’ll reiterate my usual beats here. AI code assistance is interesting, and I’m not against it. However, every current solution is inadequate, until it does the following:

1. Runs locally, or in an on-prem instance. I’m not taking it up with legal or security if I’m allowed to send our proprietary code off to be analyzed on a foreign server. And I’m not doing it without asking. It just isn’t happening.
2. It has to be free, or paid for by my company. It’s cool, and it might help me work, but paying a subscription fee on something that only benefits me at work is essentially the same as a pay cut. Not interested.
3. It has to analyze the entire repo. In my current tests of ChatGPT, for most cases I’ve spent long enough giving it context that I could’ve just… solved the problem myself. It needs to have that context already.

What a fantastic read! Quite funny throughout, and genuinely insightful.

Oof, so counterproductive. I’m a hard reviewer, always try to hold others to the standard of code I’d like to work in, and be held to myself, but every once in a while I see a PR that’s just… no changes required.

I love just hitting accept without making any feedback, it means my coworker valued my feedback and actually internalized it. Trying to laser in and nitpick something unnecessary would be a waste of all our time.

Ah, that _is _interesting. Thanks for the heads up, I had no idea!

Maybe I’m missing something, but what corps stand to make a lot of money here? This sounds like it’ll cost the social media networks a fair bit of money, and the benefactors are Canadian news networks, none of which are worth a fortune, as far as I’m aware. Seems to me that Meta would’ve been lobbying against this a lot harder than any news sites could’ve afforded to lobby for it. Heck, even news sites seem shaky on it, at least based on the CBC reporter quoted in the article.

Happy to be corrected, I’m just finding it hard to figure out who the “big corps” are that would stand to benefit from this.

Yeah, true. If the definition of “news” here is really as poor as “posted by a “News” site”, then you’re likely right that that would incentivize much of the same behaviour.

Even still though… even companies like Buzzfeed will occasionally fund “hard hitting journalism”. Handing them money blindly like that, though obviously inefficient, may still serve to make more “real journalism” financially viable. And I think there’s still people out there with a passion to do that, provided they could survive doing that.

Agreed in general though, even as a first pass at the idea, this is an awkward and subpar stab at it, with some obvious issues.

Y’know, I’m not nearly as against this concept as this suggests. News is… clearly unprofitable in the modern era, and the quality of the average news outlet has fallen drastically in the past few decades. So I’m down for some drastic attempts to recapture that value and reward good reporting.

Obviously this isn’t perfect, it might even be full-out stupid, but I don’t think perfect exists here, and it’s worth trying something here.

I used an extension a while ago that changed CSS colour values (#ababab) into little coloured dots, that became a colour picker when clicking on them (while still letting you input RGB or Hex, ofc), and it was pretty awesome!

So, I could unironically see this being really nice. Although… I think this would need a pretty narrow context, something like if x == true would look pretty confusing as a toggle, I imagine. But assigning x = true? Bring it on.