Re^3: Encoding is a pain.

I fail to see the problem ...

Which, itself, is a problem. That you have it isn't unusual (most people have it) but there is a problem.

People. People are the problem, or at least a large part of it.

Any solution that starts off "If only everybody did X completely differently than they do now" is doomed to failure as a universal solution. Won't work, and its 'universality' will die the death of a thousand cuts, some technical (and yes, Unicode has technical problems), some social, and some political. It'll be fought because it's sub-optimal in many cases, because people don't like it, because they resent what they see as someone saying "your solution sucks, and so do you -- mine is better", because universal solutions are universally riddled with design compromises, because... because people are ornery. On both (or all) sides of the issue.

Anyone who thinks they have a universal solution needs to get their ego in check, since it's visible from orbit. All solutions have flaws. Failing to recognize them doesn't mean they aren't there, and acting if they don't exist does noone any favors.

Comment on Re^3: Encoding is a pain.

Replies are listed 'Best First'.
Re^4: Encoding is a pain. by dragonchild (Archbishop) on Sep 20, 2004 at 19:48 UTC
I fail to see the technical problem. There are always problems in adoption of a new technology. VRML is an excellent example of this. It solved a problem, did it well, and died a horrible death. I was replying (somewhat facetiously, somewhat seriously) to hardburn who expressed doubt that a full solution would ever be devised. I took that to mean that there were insurmountable technical barriers - that it was NP-complete vs. merely very difficult. So, I proposed a solution-path that would solve the technical problems. I am fully aware that the solution I proposed would require a complete rewrite of every single application in existence and how they deal with strings. It, in fact, would require a complete rethinking of how to deal with strings in general. shrugs That the problem is undeployable doesn't mean it's unsolveable. Solving a problem, imho, requires the application of four different skills: Figuring out what problem to solve (Identification) Figuring out a solution to that problem (Theoretical Analysis) Figuring out how to implement said solution (Engineering) Figuring out how to deploy and encourage adoption of said solution (Politics) The problem has been identified for years. I proposed a solution and a high-level implentation. I have no idea how to go about encouraging deployment and adoption. It's a bootstrapping problem, as far as I can tell. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^5: Encoding is a pain. by Aristotle (Chancellor) on Sep 20, 2004 at 22:26 UTC
No, Elian is right. Your approach “solves” the problem by deferring all complexity to the expressiveness of the collation sets. Some languages will require collation logic that is very different from that in your standard-issue Western language. You cannot remove the complexity from a complex problem. It will come out somewhere. Makeshifts last the longest.	[reply]
Re^6: Encoding is a pain. by dragonchild (Archbishop) on Sep 21, 2004 at 00:34 UTC
I'm not certain I see the complexity, but I will defer to those who know more about non-Latin languages than I do. But, I will say this - confining complexity to only those places which add complexity is a design strength. There are many problems that have complex areas. As long as the complexity doesn't spill over, that's a good solution. Basically, I'm attempting to offer a new language, so to speak, with which to talk about the problem. If all symbols are assumed to have a unique expression in a set, then defining a subset is much simpler than it is to merge sets that don't have common ground. One has to start somewhere ... ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^5: Encoding is a pain. by Ytrew (Pilgrim) on Sep 21, 2004 at 15:43 UTC
If you have control over (4) (Politics), you might as well just declare by fiat that everyone must use the same language, period. This dissolves all the issues of encoding multiple written languages at a stroke. It's probably not significantly more dificult than getting everyone to agree to rewrite "every single application" in existance, and solves a more general problem ( ubiquitious global communication ). While you're dreaming, you might as well dream big. -- Ytrew Q. Uiop	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks