Nope... Because rule 1 of negotiating for a better salary is "don't tell the recruiter either how much you currently get paid, or how much you expect/want".

And where's your evidence that these people who have high end robotics and AI skills in the apropriate research areas actually exist?

So you're saying that it's impossible to ever have a skills shortage, because there's no such thing as a skills shortage? Even if there's only 1 person capable of doing the job, and 1000 companies want to hire them, that's 999 companies' fault for not being commercially or economically viable, and not a skills shortage, right?

What would be wrong with saying Pac-Man AI?

So then who can CMU hire to replace the people that Uber hired?

Both CMU and Uber want 40 people with these skills, there are only (at least according to Uber's hiring practices) 40 people available. That's 80 jobs, and 40 people. In what way is that not a skills shortage?

You realise that this very article is pointing out a skills shortage.

The reason that Uber paid them a huge amount of money was because there's more than one job available per person capable of doing that job, so they needed to pay a huge amount.

In paying a huge amount they didn't magically change the fact that there's a shortage of people to do that job, they just (temporarily) came out on top of the pile in terms of who actually gets to employ someone.

To be fair, the cutting taxes one is pretty insane.

The country can't afford to provide health care for everyone. It can't afford to look after its veterans. It can't afford to keep its freeways in serviceable condition (in fact, in such bad shape that the bridges are collapsing!).

America doesn't need tax cuts. It needs tax hikes, and military spending cuts.

Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem-

EXACTLY! That is why you do not want "N characters". I don't understand what your problem is here.

It is true that for this example most programmers would scan from the start, finding the longest string that fits with an ellipsis at the end.

What I was trying to point out is that if you want to be clever, you can guess as to an insertion point. But 11 bytes is just as good of a guess as 11 "characters" and since 11 characters requires scanning you are not saving any time.

You are perfectly correct that after you stick the ellipsis in there you need to test to see if the rendering fits and perhaps try another guess. The idea is that you will do fewer measurements, but that such insertion can be done using byte offsets, and "N characters" is a useless concept that never enters into it.

Yes

Do you really think 12 happy faces fit in the same space as 12 letter 'i'?

This is why it is pointless to do such counting.

And what you propose would split betwen a letter and a combining accent, so it really isn't any better for trashing strings.

Basically as soon as the words "N characters" come out of your mouth you are wrong. All your description just does that for many paragraphs. Don't feel too bad however as there are many many other people, including ones working for Apple, who are wrong as well.

PS: the surrogate order does not depend on they byte order in UTF-16. You might want to check what you are doing if you thought that.

A lot of misinformed programmers use the term "Unicode" to mean encodings other than UTF-8, typically UTF-16 or UCS-2. For instance a function called "toUnicode" often is a translator from UTF-8 to UTF-16. Therefore when people say "Unicode strings" they almost always mean non-byte strings. I propose the best solution is to eliminate all such strings. It is true that byte strings would encode UTF-8 and thus be "Unicode" but the hope is that this would be so standard that there would be no need to ever specify this and they would be called "strings".

Yeh, for anything that produces heat, and hence requires a lot of power, this really isn't going to work. 250A cabling to a little electric fire place is a non-starter.

I don't think there are any useful algorithms that need random access, except for searches that do not require the index to be "exact". Therefore you certainly do not need a reliable string[i]. You can make it return a pointer to byte i, which will work for most uses (ie searches for ASCII and replacing one ASCII byte with another).

Some complex searches do want to jump arbitrary amounts ahead, but do not require any "exact" location. Instead they want "a character near the middle" and so forth. In this case it might be useful to produce an iterator that points near byte i. A simple UTF-32 one would jump to byte i and then back up to the last non-continuation byte, unless there are 3 or more in which case it would stay where it first went (as that is the start of an error). Ones that return normalization forms would be much more complex. Something like this:

      utf16_iterator i(string, string.length()/2); // i now points near middle of string

Yes, we have UTF-8. You do know that it can hold non-English, right?

No you are wrong. What I propose does not fail any worse than what I think you are proposing, which is "search N Unicode code units forward and put the ellipsis there".

My scheme will not add an error. Either it will find the start of a character, or if there is enough trailing continuation bytes it will know that the string ends with an error and add the ellipsis after that (thus not adding an error and not removing it). As other posters here point out there is absolutely no need to count Unicode code points as it has nothing to do with how many "characters" there are.

A better scheme would be to actually measure the rendered string to see if it fits, and then do a weighted binary search for the correct location to place an ellipsis to get the longest string containing an ellipsis that fits. This still assumes that shorter strings render in a shorter area, which is still not true, but true enough that I think this may work.