Not sure if this is insightful, informative or funny. Or all three.

Lucas scripts for the prequels sucked badly. But modern Disney scripts are not much better.

Which is kind of the whole point of the programming languages: getting the message across. Telling computer to do the job.

Knowing language != being able to write good program in it. Real programmer can write good program in any language.

And "using the language well" is just meaningless statement, highlighting the modern focus on the form rather than content. AKA good program as beautiful programs vs. good program as working/useful program.

Why write several lines that do the job - when we can create beautiful class hierarchies spread across numerous libraries, use modern concepts and paradigms to accomplish the same?

There is a significant number of Tizen devices in the real world. Several car manufacturers use it for IVI (in-vehicle infotainment) systems.

MS Windows? G+? Refinement from the actual use in the wild: zero.

Samsung would never become Tizen-only shop. They would go on making all possible devices, Android and WinPho included.

Otherwise, Nokia lost its #1 position because they have failed to adapt their devices to new markets. That is precisely what Samsung tries to avoid with the Tizen. Since there is no Google to set the rules what can and cannot be an Android device and OS, Samsung (and others) can tweak Tizen to fit pretty much any device they like. After all, Tizen is larger than Samsung and is not exclusively a phone OS.

How much an Android device is worth without the Google Play store? Not much.

If you disable all the accounts/etc, pure Samsung device wins hands down over the Google one, because most Google apps these days are crap. While Samsung's apps for the most part try to be simply useful.

And if you wish to have the up-to-date with the Android version, the Google account and oftentimes G+ account are strongly suggested. Because occasionally Google forgets that not everybody is a Google/G+ user and in absence of the account some basic features simply do not work. That was experience of some of my friends who updated their Galaxies to the Lollipop, only to find that some stuff simply doesn't work because they are do not have the G+ account.

I think generic programming is destined to be second class citizen. IMO the human side of the problem is not the biggest out.

The biggest one is that there is no compiler which can untangle such code and generate something efficient out of it.

This is basically the attic where all the "everything is an object" languages have stuck. On one side, development is made easier in many places because everything is an object. On the other side, the performance and memory consumption degrade, to the point where developers end up counting and optimizing object usage of every code line and function. Because there are no compilers which are capable of deducing from the human readable code what the hell developer actually wanted to accomplish.

That brings me to the other bigger issue. Most concepts and paradigm, including the generic programming, which occupy the minds of researchers do NOT help solve the ultimate problem of the computer programming: efficiently communicating with the CPU, efficiently telling it what needs to be done.

If developer is a writer, CPU is a reader, and assembler is the spoken language, then most simple programs, with 10-50K instructions, are close the novel size. Think of it: the usual "Hello World" program, to a CPU is close in size to the novel! And if it's in an interpreted language, the CPU might end up reading a whole frigging roman, just to deduce that all what developer wanted was to print the "Hello World" on screen.

Man, I come from the BE world. You do not need to tell me that there is still abundance of the BE hardware.

Most modern CPUs I had to deal with, except the Intel, are bi-endian. BUT. Most (by model number) are used in BE mode. (But since ARM also has settled on the LE, now it is effectively a LE world.)

Yet.

1st. The endianness of the CPU is not related to the endianness of an data exchange format.

2ns. The endianness of the data exchange format does not relate to the internal presentation of the data in the application's memory.

You folks lump it all together. There are two sides to it: internal presentation and external conversion.

For internal presentation, one goes with whatever makes your life as developer easier. UCS-4 is definitively an option. UTF-8 (aka "I do not care, just passing data through") is also OK. Most applications fall into the later category. But if one ever starts pondering use of the widechars, when one needs to actually peek at the data, then there is simply no point using the UTF-16. And UTF-8 has disadvantages whne .

For external conversions, all what matters that the internal format can be easily converted into the widely used encodings. Application doesn't have any direct control over it - it is user controlled. User might pick UTF-8. Or JIS. Or win-1257. And application has to make sure that when it spews the data to outside, they come out in the encoding requested by the user.

Naive notion of that utf-8 is used by everybody is extremely naive. And IMO it is rooted in the same arrogance which held back the *nix world for decades in the dark ages of the 7-bit ASCII.

So what you propose?

Go with utf-8 which doesn't alleviate any of the problems? But adds its own one?

Beside, I doubt very much that anybody is going to use any of the fancy characters in the NetHack.

Ha! Not relevant to me, actually. But very informative. Thanks.

Overall, most customers are aware of the problems (and in my experience better than me). Simple handling I had in my software had worked and was sufficient.

The Thai language specifically is a cool example. Why not relevant? My company refused to do Thai localization. (And thanks to you now I know fully why.) To do the localization we were told that we have to buy a special Thai language library. The library costs huge money. When we told customer that they would have to pay for it, they have refused and canceled the project, because for them it was too too expensive.

So basically what you (and others) are saying, is that since there are some edge cases foreseen in the standard, nobody should try to make life easier even by a bit?

Combining characters (and the rest of the crap) pretty much never occur in real life. Only in some sadistic test case for the Unicode libraries, probably.

The main purpose of Unicode, why both users and developers want it, is to represent as much as characters as possible with least hustle possible. And that's pretty much what everybody's shooting for.

Indeed I've only scratched surface. And that alone gave me headaches for months.

For example?

It is the same problem as with the fancy acute/agrave/etc special symbols.

And the special white-space/no-space characters. And the special writing direction change characters.

They are generally removed during normalization/conversion into canonical presentation.

The thing is, after the normalization, which is needed for any Unicode text anyway, UCS-4 becomes a plain array of characters. But UTF-8 - still not.

Check the game history. Literally decades between major releases.

Everybody has already settled on the little-endian presentation.

With UCS-4 you do not even need any tests.

Extracting a character - trivial.

Length of string - trivial.

Normalization - much simpler than the utf-8.

The sad reality that libraries I have seen actually implement the utf-8 handling by using internally utf-32. You can't avoid it: Unicode is specified in the code points, which as you point it out are already as good as 32 bit long.

Frankly, I haven't even used C library for the purpose. We had already one library developed in-house, because portable support for utf-8 is patchy at best.

The sanest portable approach is to link with iconv and convert everything from some internal presentation to external. Because you can never know what encoding user needs. Unless you really need to save the RAM (one has shitload of string data), utf-8 simply sucks as internal presentation.

P.S. I have had very little experience with Unicode. But several month of dealing with it, have simply convinced me that if one has to deal with l10n/i10n, then utf-16/utf-32 are very good choices. Ditto, if one has to deal with the Unicode. If application really doesn't care what it prints or reads - then pass-through binary (utf-8) works too. But as soon as one has to take the length of utf-8 string (real length), then it is time to start switching from utf-8 to utf-32.

Considering the length of their release cycle, seems to be a safe choice.

It's not like the difference 1/2/4 bytes would make much performance difference for the application like NetHack.

Using the utf-32 internally would save them from some of the silliness the alternatives like utf-8 bring with them.

Since some money are actually made of actual paper, this is a factually correct statement!

Two years is a life time?

Let me guess: you are from red neck state with life expectancy under 35?

One can succeed in life without the cable. But not without the education.

Actually some school and medical institutions already give away free condoms.