Re^4: Encoding is a pain.

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

Comment on Re^4: Encoding is a pain.

Replies are listed 'Best First'.
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]