🚀 go-pugleaf

In article <l.712> cik@l.cc.purdue.edu (Herman Rubin) writes:
>  However, the
>first requirement for an _adequate_ programming language is that if I start
>with a reasonable mathematical construct, [...]

Imperative languages are built around the concept of a state machine --
statements in the language are transformations from one state to the next.
There's nothing inherently un-mathematical about that.  In fact, Floyd,
Hoare, and others have developed a rather interesting mathematical structure
around such machines.  If you would argue that it isn't "reasonable", well,
many persons smarter than I am have varying opinions on what is "reasonable",
and they don't necessarily agree with you.  (I use the term "state machine"
in its more general sense -- I am not refering to the FSM of language theory.)

>There are two different aims of a programming language.  One is the description
>of the procedure.  For this, the current languages are totally inadequate.
>They are much too restrictive, as well as lacking in scope.

Did you ever wonder why those "restrictions" are there?  Do you think it's
because those who designed the languages ``just weren't smart enough to do
the job right?''  It's very very easy to design a language which is
internally inconsistent.  Many of the inconsistencies do not become apparent
until one actually tries to *implement* the language.  Some are not even
known until much later than that.

Another thought, people use programming languages for many different purposes.
Does this mean that we should look for that one "reasonable" mathematical
structure which subsumes all possible uses for computers?  Ridiculous!  Some
languages attempt to do just about that (Ada and PL/I immediately come to
mind), but it is questionable that they succeed at it.

>It is necessary to restrict portability.  Semi-portability
>may still be desirable.

You may consider this a desireable feature, but I, for one, do not.

>In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes:
>> If you think you really can do better than ``C'' or some other successful
>> language, *** DO IT ***. 

>If you provide me with the necessary programmers, I will.

Here I am.  If you come up with a language description sufficiently precise
that it can be implemented, I'll be happy to produce a working compiler.

It doesn't require an army of programmers to *design* a language.  Besides,
why are you trying to foist this part of the task on others -- you're
supposed to be the one with the ideas.  Even writing a compiler for your
proposed language shouldn't be that much of a problem for you -- unless
you have no idea how a compiler works.  If this is the case I would be a bit
more skeptical about your ability to design a language.  (Yes I realize that
some compilers require many man-years of effort.  One needn't implement a
full-blown all-the-bells-and-whistles compiler the first time around.)

>The ability to define types as needed
>and operators as needed, to ignore types when necessary, to use such machine
>hardware as the language designer does not know about, to use condition codes
>when convenient if available, etc., are extremely important.

These are noble goals, and they have been incorporated into various languages
with varying success.  (Roll-your-own-operator is done in Prolog, define-
your-own-type is a feature of CLU and (I think) Ada, ``C'' allows you to
ignore types when you really want to, plus it allows access to the "bare
metal", etc.)

>We also need to be able to write the necessary constructs with a reasonable
>number of keystrokes, and the notation should be reasonably easy to read.

Some argue convincingly that verbosity is an advantage.  Others argue
against it.  Some think ``C'' is easy to read but Pascal isn't; others
believe the reverse.  Everyone seems to have an opinion on this stuff.
I have not recognized much in your postings that was not opinion.  If
you have something more substantial than gut feelings, please share it
with us.

As best I can tell you have not yet proposed much beyond a number of vague
design goals with a small set of "features".  You haven't even described
your language's intended use.  This is one reason why I suggest you flesh
out your ideas a bit more.  Your ideas may very well be dead on the mark --
gut feelings are sometimes right.  If you did work out more of the details
we would be better able to consider your ideas a bit more objectively.

Through this whole article I have spoken strongly, but without intent to
offend.  If for any reason something I have said gives offense, please
accept my personal apology.
-- 
Doug Pase  --  ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu (CSNet)