Subject: Re: Common LISP: The Next Generation From: Erik Naggum <email@example.com> Date: 1996/09/30 Newsgroups: comp.lang.lisp,comp.lang.dylan Message-ID: <firstname.lastname@example.org> [James Toebes] | I beleive the best language is the one that gets the job done the | quickest. I have mixed feelings about this. Too frequently "gets the job done" means 90% of the job and exponential costs to approach 100% asymptotically. Too often, this is because getting 100% of the job done requires as much effort in a very powerful language (abstraction-wise) as is needed to get 90% of the job done in less powerful languages that focus on manual labor instead of mental labor to solve the problems. With the experience that getting 100% will mean skyrocketing costs, managers won't listen to arguments against "get the job done" until they know what it _could_ mean with very different tools. If you're an expert at hacking your way through the jungle around a mountain, and want to build a road there, it takes courage to investigate the option of digging a tunnel through the mountain, and vastly different tools. I wouldn't want the decision to be based on who gets to the other side first. | As for Microsoft, I have mixed feelings about them but I wont discuss | all of them now. There is one project that I have heard they are | undertaking but I do not know the full details. They are suppossedly | working on a method of 'UNICODE' where multiple languages can be | intermingled and allowed to work together. In theory this sounds good. | If anyone knows more, please enlighten me. That's ISO 10646 Universal Multiple-octet Coded Character Set (UCS), also known as Unicode 1.1, a character set standard that was intended to serve as the foundation for the next generation of computer representation of text, respecting all the world's written languages, extant and historic. It embraces natural languages and a rich array of mathematical and other symbols. I do not look forward to the time when programming language or utility designers discover that they can use all of these symbols in their syntax instead of inventing more and more complex multi-character "tokens", but other than my fears (and a fundamental problem of implementability and deployment in programming environments), it has very little to do with programming languages. #\Erik -- I could tell you, but then I would have to reboot you.