Subject: Re: Common LISP: The Next Generation
From: Erik Naggum <erik@naggum.no>
Date: 1996/09/30
Newsgroups: comp.lang.lisp,comp.lang.dylan
Message-ID: <3053078000286291@naggum.no>


[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.