That's a really eloquent way of putting it. I like that.
12,404 karma · joined May 13, 2015
Author of murex (https://github.com/lmorg/murex, alt DevOps $SHELL). Contributor to open source. Also works on a few proprietary projects too.
Yes I know. I was there too. ;)
> But that does not stop people from doing 100% vibe-coded projects.
And why should it? Let people "code" however they want to "code". Just like some people will find creative ways to play the guitar while others will just play covers.
By the way, you haven't addressed the core point posed: if people like AI output then is it still "slop" (in response to comments where people describe all AI output as "slop")
This would have generated extra profit for Nvidia. So I doubt they'd care unless the US government chose to take legal action against Nvidia. And that's unlikely to happen under the current US administration.
I think the bigger risk is what happens when they retire if we are not training the next generation of professionals.
But we are talking about popular culture here. That was never an industry where quality was measured by artistic excellence. It's an industry that is entirely motivated by mass appeal. Thus something being popular IS the measure of success.
So if AI is slop, then so is 99% of the human-made content it's replacing.
Not going to comment on your workplace specifically, but I’ve found this to be an issue with other industries like real estate long before ChatGPT were a thing.
The problem is the people who pickup the phone, greet you at the shop door, or take the photos, they’re the lowest paid juniors and thus know nothing.
So in most industries, you were always lucky to get through to someone with knowledge on the first attempt.
And, playing devils advocate for a moment, does it matter if a robot or a human authored it if people like it? People loved Magic Eye pictures in the 90s and they were computer generated too.
Eg https://hn.algolia.com/?q=curl+sh
I probably commented in some of those threads too. It sucks being old :(
It's insane to me that people would argue "we don't know when to stop so lets not implement it at all" when you can literally just stop at one toggle if you wanted. It honestly feels like sometimes people look for problems where problems don't exist.
Do you make the same argument for everything?
"You shouldn't treat yourself to a takeaway because what if you want more takeaways?"
"You shouldn't buy a car because what if you want more cars?"
etc.
It's literally there in the doc
> It’s called “East Asian Width” for a reason. As the note in the Scope section begins:
Yes. I didn't claim it defines terminal cell widths. There's a reason you need a library to translate that into cell widths. What I said was you don't need to be pratt about with printing because Unicode does define widths and properly libraries pin against that (like POSIX does).
> Terminal emulators have piggy-backed onto it because it’s fairly close to what they want and definitely better than nothing,
That's a very convoluted way of agreeing with me :)
> but if they limit themselves to this definition, they do a bad job.
A large part of the problem here is you're introducing scope creep.
> To see the most extreme example, look through Google Fonts for U+FDFD <https://fonts.google.com/?preview.text=%EF%B7%BD> and see the radical differences in aspect ratio (and size!).
You're shifting goal posts again because you're no longer talking about fixed width typefaces. Terminals have to make some concessions for turning scripts (of any language) into fixed width. If that's an issue then you shouldn't be using the terminal to begin with. There are better standards for that, such as the web.
In short, nobody is going to disagree with you that Unicode is hard and full of edge cases. But the vast majority of the stuff you describe are either already solved, already have standards, or are already out of scope for terminals.
The story you mentioned wasn’t about exclusions from each and every dictionary. It was about tools that do entirely unique things.
I know HN has a long history of struggling with nuance, but surely people must understand that it’s entirely possible to have a toggle to enable/disable the autocomplete adult filter without needing to then have options for every…single…minor…variation of that filter.
So you shouldn't need knowledge of the type-face to know the size of the printed character. If other libraries are printing the characters and then extracting the width from that, then they're doing it wrong and you should look to use a different library instead.
The bigger problem I've run into is not different libraries making up their own width assumptions. It's been libraries built against outdated versions of the Unicode standard.
> The terminal emulator must handle a lot of RtL stuff to get it acceptable. In raw mode (where dimensions are knowable) you could almost leave it to the app, but outside raw mode it’s pretty obvious that the terminal has to be BiDi-aware. But even in raw mode, you really can’t treat it as you describe, because Arabic text rendering is rather complex, full of necessary ligatures.
I think RTL is a distraction from the actual point that we're discussing. But it's worth noting that there are already CSI sequences for enabling RTL behaviour in terminal emulators. It's not something I've personally implemented in my own projects because I have no personal need for it and have had no feature requests from people asking for it who could test the implementation's soundness (unlike Chinese characters, which have seen a reasonable degree of popularity in the projects I've built). But I'm sure some other terminals support it just fine since it was added decades ago as part of ECMA 48.
To which the obvious counterargument is just “well of course they can stop at just one toggle. That’s not an excuse to have zero toggles”.
I’ve not found that to be the case. Usually the issue is more around different libraries being out of date (ie pinned to an earlier version of Unicode)
> and once you get to things like Indic scripts and Right-to-Left there are no good answers, and no cell-based terminal produces even vaguely acceptable results.
That’s because right-to-left isn’t supported and in my opinion shouldn’t be supported my the terminal emulator itself.
Right-to-left support would be handled by the client application, not the terminal emulator. The terminal is just there to offer a grid of Unicode cells. It’s not a writing composition suite.
Just like how the terminal emulator isn’t readline, it isn’t emacs, it isn’t hexdump, and it isn’t vim.
> As for meanings of string width, I’d count at least four: Unicode code units, Unicode scalar values, Unicode extended grapheme clusters, and terminal cells.
I’d already touched on the fact that Unicode widths can vary depending on what you’re measuring. But your Unicode library would/should handle most of the pain there.
When writing software for a terminal, you’re really only interested in the characters you need to loop through, their cell width, and, in some languages, the number of bytes.
As I’ve said previously, I’ve written terminal emulators targeting a variety of different renderers like SDL (so not just js+canvas), as well as complex terminal software like $SHELLs. From what I’ve built over the decades, honestly Unicode support isnt as big problem as it used to be. Sure, there’s plenty of footguns that you need to be aware of, but that’s just the nature of working with technology originally designed in the 60s/70s. Like how you need to be aware of cell widths if you intend to do any manual text alignment in client software. But at least there are libraries to make that task easier.
And if you don’t case about text alignment, then the terminal emulator will handle that for you.
I know these are all typos because she’s a really close friend and easily the last person who would be offensive to other people.
So yes, you’d be surprised at what people can typo on a phone.
- [ ] Disable autocomplete swear filter.
But finely grained options are not Apple’s way.
And there are already definitions and APIs to decide the terminal cell width of different Unicode characters.
I’m not saying it’s easy, because you end up with 3 different string widths:
1. memory length in bytes
2. Number of Unicode characters (which is annoyingly also different to the number of Unicode code points since some codes can be combined)
3. terminal cell width
But as annoying as it is, there are a few relatively mature libraries you can use to solve this problem.
You’re right. I’ve been experimenting with Monaco lots lately and could have sworn it used a canvas. But it doesn’t.
> 2D canvas is consistently slower than letting the browser handle the rendering, so long as you avoid making the DOM too complex, and possibly monitor the viewport and only keep some of the content in the DOM at a time (though for most applications it’s somewhere between harmful and not useful, and it definitely adds a lot of complexity).
Interesting. I’ve found the reverse to be true. But it sounds like this is human error on my part. (probably doesn’t help that I’ve had more experience building high performance GPU applications in Dx, SDL, and similar than I have building high performance web apps.
Thanks for the correction.
> Why on earth would you build with web technology, if you’re then going to use canvas? I can’t immediately think of any that match your description (though I have no doubt that in-browser ones using canvas exist).
You answered your own question.
And I do know of at least one written using the canvas. Because I wrote it. I’m now interested in how others work though.
Like I said, I have zero issue being “AI first”. 90% of my day-to-day is using AI. But the part I objected to in the OP was “we don’t need to know things because we have AI” (to paraphrase. So I was asking the question: what if AI goes away?
I agree humans are resilient. But that’a not a good excuse for complacency.
Absolutely we should use all the tools at our disposal which enhances productivity. But that doesn’t mean we shouldn’t also learn how’re to do things for ourselves too.
To use a contrived example, there’s no shame in using a dishwasher. But if you cannot wash dishes by hand when the dishwasher breaks down, then you know you have problems.
Do we really want to put ourselves in the same situation?
If you did, then I apologise. But my point is about accessing that knowledge when AI isn’t available. Not about how AI discovered its corpus to begin with.
What’s our disaster recovery strategy in the event of war and loss of internet?
Or worse yet, a near extinction event and we are forced to rebuild civilisation from memory?
Some of these might seem like extreme edge case scenarios but then history is full of disasters that people didn’t prepare for because they assumed they were too big to fail.
The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is why Monaco (the editor widget behind VSCode) is a canvas. Why terminal emulators built with web technologies use canvas. And so on.
So I wouldn’t say the canvas part of the heading is a differentiator.
Edit: apologies, seems I was wildly wrong here. Please disregard the above.
If you think successful campaigns these days are always entirely done by humans, then I’m afraid you’re mistaken.
And home computers have had pictograms as part of their character set since the late 70s/early 80s. For example code page 437 (MS-DOS) had smilies, card suites, and other emoji. Likewise for the PETSCII (Commodore Pet) too.
And not just emoji’s, but full on drawing characters. In fact that was the only way to draw graphics on some early systems, such as Teletext, in the early 70s.
And then you have the question of what pictograms are part of writing systems. For example the media control symbols (play, pause, fast forward, etc). Or how about the fact that some emojis had been part of written text long before Unicode, in the form of “smilies”, eg :-)
I hope this illustrates that the problem was never an easy one to define boundaries for inclusion.