91–100 of 201 posts
It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call. The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.
Earlier quoted context omitted.
[flagged]
That's a very narrow view of the world. One example: In the past I have handled bilingual english-arabic files with switches within the same line and Arabic is written from left to right. There are also languages that are written from to to bottom. Unicode is not exclusively for coding, to the contrary, pretty sure it's only a small fraction of how Unicode is used. > Somehow people didn't need invisible characters wh…
Yes, it is. Unicode has undergone major mission creep, thinking it is now a font language and a formatting language. Naturally, this has lead to making it a vector for malicious actors. (The direction reversing thing has been used to insert malicious text that isn't visible to the reader.)
> Unicode is not exclusively for coding
I never mentioned coding.
> They didn't need computers
Unicode is for characters, not formatting. Formatting is what HTML is for, and many other formatting standards. Neither is it for meaning.
Unicode should be for visible characters. Invisible characters are an abomination. So are ways to hide text by using Unicode so-called "characters" to cause the cursor to go backwards. Things that vanish on a printout should not be in Unicode. Remove them from Unicode.
That ship has sailed, but I consider Unicode a good thing, yet I consider it problematic to support Unicode in every domain. I should be able to use Ü as a cursed smiley in text, and many more writing systems supported by Unicode support even more funny things. That's a good thing. On the other hand, if technical and display file names (to GUI users) were separate, my need for crazy characters in file names, code bas…
Sure, but more crazy stuff gets added all the time.
It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call. The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.
Earlier quoted context omitted.
Another dum dum Unicode idea is having multiple code points with identical glyphs. Rule of thumb: two Unicode sequences that look identical when printed should consist of the same code points.
If anything, Unicode should have had more disambiguated characters. Han unification was a mistake, and lower case dotted Turkish i and upper case dotless Turkish I should exist so that toUpper and toLower didn't need to know/guess at a locale to work correctly.
Earlier quoted context omitted.
> So you think that the letters in the Greek and Cyrillic alphabets which are printed identically to the Latin A should not exist? Yes. Unicode should not be about semantic meaning, it should be about the visual. Like text in a book. > And, for example, Greek words containing this letter should be encoded with a mix of Latin and Greek characters? Yup. Consider a printed book. How can you tell if a letter is a Greek l…
> Yes. Unicode should not be about semantic meaning, it should be about the visual. Like text in a book. Do you think 1, l and I should be encoded as the same character, or does this logic only extend to characters pesky foreigners use.
Earlier quoted context omitted.
Here's the big reason GitHub should do it: It makes the product better I know people love to talk money and costs and "value", but HN is a space for developers, not the business people. Our primary concern, as developers, is to make the product better . The business people need us to make the product better, keep the company growing, and beat out the competition. We need them to keep us from fixating on things that a…
I'd say that this is also true from a money-and-costs-and-value perspective. Sure, all press is good press... but any number of stakeholders would agree that "we got some mindshare by proactively protecting against an emerging threat" is higher-ROI press than "Ars did a piece on how widespread this problem is, and we're mentioned in the context of our interface making the attack hard to detect." And when the incremen…
Engineers and developers are especially sensitive. It's our job to find problems and fix them. I don't trust engineers that aren't a bit grumpy because it usually means they don't know what the problems are (just like when they don't dogfood). Though I'll also clarify that what distinguishes a grumpy engineer from your average redditer is that they have critiques rather than just complaints. Critique oriented is searching for solutions of problems, you can't just stop at problem identification.
> And when the incremental cost to build a feature is low in an age of agentic AI
Though we're also talking about an organization that couldn't merge a PR for a year that fixed a one liner. A mistake that should never have gotten through review. Seriously, who uses a while loop counter checking for equality?!? I'm still convinced they left the "bug" because it made them money
Earlier quoted context omitted.
> So you think that the letters in the Greek and Cyrillic alphabets which are printed identically to the Latin A should not exist? Yes. Unicode should not be about semantic meaning, it should be about the visual. Like text in a book. > And, for example, Greek words containing this letter should be encoded with a mix of Latin and Greek characters? Yup. Consider a printed book. How can you tell if a letter is a Greek l…
Unicode is about semantics not appearance. If you don't need semantics then use something different.
And that's where it went off the rails into lala land. 'a' can have all kinds of distinct meanings. How are you going to make that work? It's hopeless.
Earlier quoted context omitted.
And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript? Can you think of any reasons beyond performance?
I'd be surprised if there is a performance benefit of processing json with eval(). Browsers optimize the heck out of JSON.