Hacker News Reader

Comment by CydeWeys | Hacker News Reader

Maybe it's just my first-world-privilege at work, but, honestly, why would I want to put up with a language that makes all of my day-to-day coding tasks so much more difficult than it is in other programming languages? It seems like I'm losing more than I'm gaining. 99% of what I do is in English. Everything that's not in English is going through an i18n library to convert labels and such. It doesn't seem like I'm gaining much of anything, but I sure am losing a lot. No default indexOf, length, and substring methods? Ouuuch.

View on HN

Exactly. I understand where pilif and Lx1oG-AWb6h_ZG0 are coming from when they say that indexOf, length, and substring actually get a little ill-defined when Unicode is involved, but I can't see the logical leap from that to it being a good idea to exclude them entirely. The motto of a good API/SDK is "Make the easy case easy, and the hard case possible"; Swift seems to fail the first condition. Surely there are default assumptions for these methods that work most of the time, with the option for more complicated functionality if you need it.

Maybe all this complexity is necessary when you're writing huge i18n'd apps, but the point is that if it's too much bother to even do Hello World, I'm never going to get to the huge i18n'ed apps.

The problem with strings is that there is very little that is easy. The lesson is to avoid using strings as much as possible, although sadly fashions in programming seem to have been heading in the other direction for a long time.

I don't think hiding difficult operations behind an easy facade that sometimes breaks is a good idea. It makes people think that working with strings is easy. It results in lots of people writing broken or even insecure code[1].

The idea that you only have to deal with unicode strings if you are writing an i18n'd app is wrong. File names are unicode. The content of the pasteboard is unicode. The results of calling a web API are unicode. Text the user types into a text field is unicode. Unless your app doesn't handle outside text data at all then it's going to encounter non-ascii text. And if you aren't handling text from outside the app then you probably won't have much need for string operations anyway.

[1] do a github search for 'UTF8String' and 'length' to see how much code using NSString is passing the wrong length value into C apis.

Because you're making mistakes in those other languages? Because the world is not just English anymore, and "going through an i18n library" is all well and good until you need to accept literally any form of user input, which is kind of the point of programming.

> No default indexOf, length, and substring methods?

This makes me think you didn't read the post. There is no lack of those methods. There isn't a one size fits all version, because the problem space isn't generalizable.

Because it is harder to do the wrong thing. Same as the arguments for static typing and defensive coding. An i18n library will not save you if you are fiddling around with indexOf and substring.

I think want we actually want is a separate string type for ASCII-only strings.

Do you never deal with user input?

indexOf, length, substring, and all the rest are still in there. They just require you to pick which representation you want to work on first. This is often just a matter of typing .characters after the string variable.

In Europe we do localize our applications, no such luck with 99% English.

Reply on news.ycombinator.com