APL for talking to LLM when? Also, this reminded me of that episode from The Office where Kevin started talking like a caveman to make communication efficient.
While I agree that monopolies suck, I _absolutely hate_ having to waste my time adjusting styles and writing workaround code just to make everything look and work consistently in a multitude of browsers. This is one of the reasons — among a hundred others — that I grew to somewhat hate front-end, doubly so with the rise of mobile devices. And the more rendering engines we have, the more developers will have to fight frustrating battles with inconsistencies and quirks.
Janitor Engineers [0] are already a thing? Damn. Also, all links in this article starting from the "Why AI code fails at scale" section are dead for some reason, even though it was written only 5 days ago. That raises some questions...
EDIT: Not trying to offend anyone with this [0], I've actually had the same half-joking retirement plan since the dawn of vibe coding, to become an "all-organic-code" consultant who untangles and cleans up AI-generated mess.
It also has catalogs feature for defining versions or version ranges as reusable constants that you can reference in workspace packages. It was almost the only reason (besides speed) I switched a year ago from npm and never looked back.
Personally, I'd be annoyed by both the resource-consuming animations and the blurry GIFs/canvas. Infisical does use the latter (canvas) for icons in their UI, and I somewhat hate it. I'd rather look at crisp, but static icons.
Ah, yes, that's totally fair. In case of JS (in browsers) it's sort of a big deal, I suppose, even if scripts being loaded are not render-blocking: the faster you lex and parse source files, the faster page becomes interactive.
P.S. I absolutely loved "Crafting Interpreters" — thank you so much for writing it!
Is lexing ever a bottleneck though? Even if you push for lexing and parsing 10M lines/second [1], I'd argue that semantic analysis and codegen (for AOT-compiled languages) will dominate the timings.
That said, there's no reason not to squeeze every bit of performance out of it!
[1]: In this talk about the Carbon language, Chandler Carruth shows and explains some goals/challenges regarding performance: https://youtu.be/ZI198eFghJk?t=1462
Looking at the source code of the code-editor [1], it seems to be embedding https://onecompiler.com via the iframe and delegating code compilation and execution to it. So I guess it's a question to onecompiler, whether they sanitize input or not. :)
Well, many people have complained about this very issue, and it was actually from this [1] discussion that I learned that Firefox handles big PRs just fine. No amount of jumping through hoops, including creating a new profile, helped to make it work in Chrome.
Speaking of 'works best in Firefox'... I mainly use Chrome (kinda have to), and it's practically impossible to use it for reviewing big GitHub PRs with many files changed (UI just freezes), but everything's perfectly fine in Firefox!
Ha-ha, thanks, I couldn't help but chuckle a bit at that intro. As for them taking their time... Well, yes, it's all rather sad, but I personally came to terms long ago with the snail's pace of JS proposals rolling out. And after all, working with dates and time zones is a rather complex matter in itself, so no judgment here.
I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...