General purpose language. 
Author Message
 General purpose language.


Quote:
> ---The best general-purpose language by far is PL/I.
> It allows the user to express algorithms clearly and
> easily[...]

I have to disagree.  PL/I was mostly a failure in terms of being a
general purpose language for several reasons:

1) Lack of simplicity -- PL/I is way too complex.  Most people use a
*tiny* subset of the language.  There are also so many ways to change
how your program is going to work that it is easy to get unintended
side effects.

2) Lack of security -- PL/I automatically coerces virtually
everything, allows manipulations of program labels, and other ghastly
things that made it quite unpopular.

3) The syntax was also not simple... in fact, PL/I requires arbitrary
lookahead to parse, since you can have function names that are the
same as keywords.

I'd go into more detail, and provide a few more points, but
unfortunately, I'm a bit pressed for time.  I'd encourage you to
explore the PL literature...

In today's context, PL/I fails to support more modern programming
features, most notably the object oriented paradigm.  PL/I's exception
handling mechanism was an experiment that proved that exception
handling was feasable to implement, but isn't very useful in
practice... a more modern/usable exception system would appeal to a
lot of people.

John

------------------------------------------------------------------------------|
|John Viega                            "Non-structurally equivolent types in C|

| http://www.*-*-*.com/ .{*filter*}ia.edu/~jtv2j/     entity, the core dump."               |
|University of {*filter*}ia                                  --George Williams    |
-------------------------------------------------------------------------------



Wed, 29 Jul 1998 03:00:00 GMT  
 General purpose language.

Quote:


>> ---The best general-purpose language by far is PL/I.
>> It allows the user to express algorithms clearly and
>> easily[...]
>I have to disagree.  PL/I was mostly a failure in terms of being a
>general purpose language for several reasons:
>1) Lack of simplicity -- PL/I is way too complex.  Most people use a

[...]

Quote:
>2) Lack of security -- PL/I automatically coerces virtually

[...]

Quote:
>3) The syntax was also not simple... in fact, PL/I requires arbitrary

[...]

Agreed. My fortune database said ;-)

: Speaking as someone who has delved into the intricacies of PL/I, I am
: sure that only Real Men could have written such a machine-hogging,
: cycle-grabbing, all-encompassing monster.  Allocate an array and free
: the middle third?  Sure!  Why not?  Multiply a character string times a
: bit string and assign the result to a float decimal?  Go ahead!  Free a
: controlled variable procedure parameter and reallocate it before
: passing it back?  Overlay three different types of variable on the same
: memory location?  Anything you say!  Write a recursive macro?  Well,
: no, but Real Men use rescan.  How could a language so obviously
: designed and written by Real Men not be intended for Real Man use?

Once I wrote a litte program that makes use of all the above. I don't
know what these features are good for.

-jo
--
-rw-r--r--   1 jo       users          75 Feb 11 12:25 /home/jo/.signature



Thu, 30 Jul 1998 03:00:00 GMT  
 General purpose language.


        >> ---The best general-purpose language by far is PL/I.
        >> It allows the user to express algorithms clearly and
        >> easily[...]

        >I have to disagree.  PL/I was mostly a failure in terms of being a
        >general purpose language for several reasons:

        >1) Lack of simplicity -- PL/I is way too complex.  Most people use a
        >*tiny* subset of the language.  There are also so many ways to change
        >how your program is going to work that it is easy to get unintended
        >side effects.

---While it is true that it is unnecessary to use the whole
of PL/I to do a great deal in PL/I, and it is true that one can
get by on a subset of the language, in general, it's not a tiny
subset.  That's not to say that the language is huge or large
or complex.  Compare it with fortran 90 or Ada.  Compare it with
COBOL.

   However, a given investment of learning of PL/I will give
a greater reward in that more of the language will be learned.
This comes about from its more uniform syntax and fewer exceptions
to the rules than other languages.

   It also comes about from the lack of reserved keywords in PL/I.
For a beginner, having a large vocabulary of reserved words can
be a pest.

        >2) Lack of security -- PL/I automatically coerces virtually
        >everything, allows manipulations of program labels, and other ghastly
        >things that made it quite unpopular.

  I think that this is a very broad generalization that is
unsupportable.  PL/I doesn't "automatically coerce virtually
everything".  First, the compiler routinely gives messages for
a number of potentially troublesome conversions.  Secondly, the
language comes with strongly typed data structures for
list processing.  Pointers are tightly bound to the structure
with which they are associated.

   A lot of people are finding that PL/I hasn't remained static
since it was first introduced.  There has been considerable
development over the years -- developments that went hand-in-hand
with improvements.  When it was first introduced,
PL/I was endowed with a number of modern features that have
kept it from becoming obsolete.

        >3) The syntax was also not simple... in fact, PL/I requires arbitrary
        >lookahead to parse, since you can have function names that are the
        >same as keywords.

---Whether or not the syntax is simple is not relevant to
whether or not the compiler needs to "look ahead" to parse
PL/I source.

   Most would agree that the syntax is simple.  The language
is easy to learn on account of this.  Examples of statements:
   DO K = 1 TO 10;
   GET (D);
   PUT(D);
   IF X > Y THEN PUT (X);

        >I'd go into more detail, and provide a few more points, but
        >unfortunately, I'm a bit pressed for time.  I'd encourage you to
        >explore the PL literature...

        >In today's context, PL/I fails to support more modern programming
        >features, most notably the object oriented paradigm.  PL/I's exception
        >handling mechanism was an experiment

---It was more than an experiment.  It's been one of the
important features of the language since the first PL/I
compiler.  And it's been enhanced in IBM's PL/I for OS/2
and AIX.

        >that proved that exception
        >handling was feasable to implement, but isn't very useful in
        >practice...

---In how many programming languages can you get the program
to tell you which line the program was executing when an error
occurs?  And in how many programming languages can you have
the values of variables printed at the time of the error?

   In how many programming languages can you press the interrupt
key and make an enquiry about a program?  (e.g., the program
might be stuck in a loop, or it might be a very long-running program,
& you want to see how far it has got).  And in how many
can you resume the program as if it was uninterrupted.  And in
how many can you change the values of variables, and continue?

   In how many prog. languages can you resume execution following
some computational error? (with a new batch of data).  For
real-time processing, you definitely need an interrupt-handling
mechanism.

   BTW, In PL/I, you can create your own conditions and signal
that condition (i.e. make a software interrupt).

   In short, the exception handling provided in PL/I is
exceptional (no pun intended) and *h*i*g*h*l*y* useful.
I suggest you take a look at Gerry Weinberg's book (PL/I -  A
Manual of Style) to see what can be done with exception handling.

        >a more modern/usable exception system would appeal to a
        >lot of people.  John

---As I indicated above, the exception handling in PL/I has been
extended (with new exceptions and a RESIGNAL statement, to mention
a few things).



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.


        >> >Algol was intended as a general purpose mathematical language,
        >> >and did not succeed, because too much was left out.
        >> Arguable.

        >Very arguable.  Algol 60 was moderately successful, but the CS
        >community then decided to devlop Algol 68.  Algol 68 was a _very_ large
        >language, which supported operator overloading, and even operator
        >precidence redefinition.  The specification was almost impossible to
        >decipher, decent compilers for the language were almost impossible to
        >write, and the language was notoriously difficult to learn (mainly due
        >to its unique terminology that book writers tended to adapt.)
        >Tannenbaum wrote a fairly decent tutorial, and there was a fairly
        >popular book called, "Algol 68 w/o Tears" or "Algol 68 w/ fewer Tears"
        >or something like that.

        >Anyway, Algol 68 failed due to the complexity, not because too much
        >was left out.  The Algols were actually fairly popular in Europe until
        >fairly recently.  

---I suspect that the original commenter was referring to Algol 60.

        >I think what you might be getting at in terms of "too much was left
        >out", was the fact that the revised report on Algol-60 failed to
        >include specifications on a few key things, such as I/O.  This is
        >because they wanted a common specification for all machines, and
        >thought I/O would be different enough from place to place that it
        >should be implementation dependant.

---I think that most would agree that this was a mistake, as I/O
has been defined in various languages, and implementers have been
able to get it to work more-or-less uniformly. The same could
have been done with Algol 60.

   The other notable omission from Algol 60 was strings.  This is
where PL/I came to the fore, because it not only implemented
character strings (two kinds -- fixed-length and varying-length)
but also bit strings (also fixed length and varying-length).
It also filled the Algol 60 gap in I/O with an excellent I/O
system (both sequential and random-access I/O). In fact,
the I/O implementation was vastly superior to FORTRAN.

        > While I haven't looked at the
        >Algol 68 report in some time, I do believe that Algol 68 did specify
        >I/O.  Also, both Unix based Algol-60's I've seen came with fairly
        >simmilar looking I/O...

---Every Algol 60 implementation I've seen implemented I/O
differently.



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.

Quote:
>---In how many programming languages can you get the program
>to tell you which line the program was executing when an error
>occurs?  And in how many programming languages can you have
>the values of variables printed at the time of the error?
>   In how many programming languages can you press the interrupt
>key and make an enquiry about a program?  (e.g., the program
>might be stuck in a loop, or it might be a very long-running program,
>& you want to see how far it has got).  And in how many
>can you resume the program as if it was uninterrupted.  And in
>how many can you change the values of variables, and continue?

Are you saying this is a good idea?

It might be useful to be able to tell the compiler to compile a
program in such a way that this information is available to a
de{*filter*}.  There is a significant overhead in maintaining such
information though.  It can cause variables to have storage
reserved for them even though there is no execution path that will
use them - because you might want to inspect their values with the
de{*filter*}.  If those values would normally be held only in registers
you are talking about time as well as storage penalty.



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.

                        .
                [assorted PL/I nightmares]
                        .
                        .
Quote:
>Once I wrote a litte program that makes use of all the above. I don't
>know what these features are good for.

                        .
                        .
                        .
Not much--now.  There was a time, when memory was impossibly
expensive, and coders relatively cheap (compared to CPUs, say),
that we regularly performed such monstrosities in assembly
language; some of this still goes on in the embedded systems
and compiler-writer worlds.  At that time, it seemed very
natural that one of the paramount goals for a compiler was to
be able to do all the things one can do in assembler.  Note
that Dr. Rubin has already expressed exactly this criterion
elsewhere in this thread.

The engineering concerns of the community at large have
shifted, and that time now seems very distant.
--

Cameron Laird           http://starbase.neosoft.com/~claird/home.html

                        +1 713 996 8546 FAX



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.

Quote:


> 3) The syntax of PL/I was also not simple...
>What about C ? Which code is more readable and easier to maintain ?

> In today's context, PL/I fails to support more modern programming
> features, most notably the object oriented paradigm.  PL/I's exception
> handling mechanism was an experiment that proved that exception
> handling was feasable to implement, but isn't very useful in
> practice... a more modern/usable exception system would appeal to a
> lot of people.

> John

We shouldn't compare languages used in DIFFERENT areas. While OOP is
very useful for GUI applications, it's hard to imagine why it's
necessary to re-write all legacy data processing aplications in OOP.
As I read in one nice article in Computerworld, you never go to a
groccery with a truck and to a farm with a bag. Why all Open Systems
people say that ONLY their C,C++,OOP environment should be used
EVERYWHERE ? There are systems where C++ OOP is the best and other
systems where PL/I is the best, and CAN NOT be replaced with C or C++.
We use both in our organization, so I can prove it. Especially -
Exception Handling.
(See my message 'RE:PL/I vs C: Power vs. Adventure' posted last week)

++ robin wrote ABSOLUTELY correctly in this thread:

Quote:
>>In how many programming languages can you get the program
>>to tell you which line the program was executing when an error
>>occurs?  And in how many programming languages can you have
>>the values of variables printed at the time of the error?

I tried (I was a 'pioneer') to switch from PL/I to C in our
department. It's IMPOSSIBLE ! We are a DIALOG - 400+ on-line
databases used 24 hr a day by large corporations all over the world.
We use HUGE (40G) source files from VERY differenet Providers - from
Chemical scientific articles to newspapers, patents, etc.

 All this data is in various formats and may (and often do) have errors.
So, I tried C:
  1) C doesn't have Exception Handling, so I can not 'catch' a source
     record where a failure occured, and cann't print an error code to
     know nature of this failure. So, if I use C, I must re-run entire
     update (files are HUGE) and investigate if Source file is
     responsible for this failure, not my code.
  2) C compiler DOES NOT tell me, WHERE in my code this error occured.
     And programs are parge...

 In PL/I, it usually takes me a half of a day or even couple hours to fix
 a Production failure - I see Source record where it happened, I see
 statement number.
 AND - these ARE NOT my programs ! They were written long ago and THEN
modified by SEVERAL other programmers !
Let me advice you to try to fix someone else's C or C++ program in 2 hours !
C and C++ are very hard to support, while PL/I code is readable and
easy to maintain.

When one of database update fails, we are getting customer calls from
all over the world, and usually have a day or less to fix it.
 So, in my opinion, C is good for a Research organization, where they don't
 have such time pressure, or for a software company that develops ONE package
 to sell it later on market. In ONE package of YOURS, you CAN figure
 out what part  is causing a failure, but if a company has 400+
 packages of DIFFERENT nature, and data IS NOT ours, it's not
 possible at all to use C and spend DAYS investigating a failure.
 Here is the area where PL/I IS the best !
--



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.

Quote:
>: Speaking as someone who has delved into the intricacies of PL/I, I am
>: sure that only Real Men could have written such a machine-hogging,
>: cycle-grabbing, all-encompassing monster.  Allocate an array and free
>: the middle third?  Sure!  Why not?  Multiply a character string times a
>: bit string and assign the result to a float decimal?  Go ahead!  Free a
>: controlled variable procedure parameter and reallocate it before
>: passing it back?  Overlay three different types of variable on the same
>: memory location?
>Once I wrote a litte program that makes use of all the above. I don't
>know what these features are good for.

Maybe BASIC is the language for you.  It forbids all the above.   With the
exception of free the middle third, which I believe you cannot do in PL/I,
I can see instances in which these each of these
would be very valuable and tidy facilities.  If
you can't maybe your problems are best coded up in a simpler language.

Now, to test you all:  Give an example of freeing and reallocating a controlled
parameter that otherwise requires much more complex coding (and less clear).



Fri, 31 Jul 1998 03:00:00 GMT  
 General purpose language.

Quote:

> ---While it is true that it is unnecessary to use the whole
> of PL/I to do a great deal in PL/I, and it is true that one can
> get by on a subset of the language, in general, it's not a tiny
> subset.  That's not to say that the language is huge or large
> or complex.  Compare it with Fortran 90 or Ada.  Compare it with
> COBOL.

This isn't a very important point, and as time has passed, it has
certainly become less true.  However, comparing it to Ada doesn't work
very well, as Ada had the problem of trying to be all things to all
people, as well, and is therefore about as big and bloated as PL/I.

As to the rest of your points, we are talking about two different
things.  I was talking about why PL/I was by all measures a failure.
I will grant to you that the language has evolved.  But the fact is,
almost no one outside of the IBM community uses PL/I.  And even IBM is
moving towards Rexx.

Quote:

>    >2) Lack of security -- PL/I automatically coerces virtually
>    >everything, allows manipulations of program labels, and other ghastly
>    >things that made it quite unpopular.

>   I think that this is a very broad generalization that is
> unsupportable.  PL/I doesn't "automatically coerce virtually
> everything".  

PL/I is famous for coercing floating point reals into
characters.

Quote:
> ---It was more than an experiment.  It's been one of the
> important features of the language since the first PL/I
> compiler.  And it's been enhanced in IBM's PL/I for OS/2
> and AIX.

Well, I certainly hope it's been enhanced, because, while it was an
important proof of concept, the original PL/I exception handling model
was quite poor.  However, w/o its existance, it might have been a bit
longer before a language w/ exception handling as good as CLU's would
come along.

Quote:
> ---In how many programming languages can you get the program
> to tell you which line the program was executing when an error
> occurs?  And in how many programming languages can you have
> the values of variables printed at the time of the error?

>    In how many programming languages can you press the interrupt
> key and make an enquiry about a program?  (e.g., the program
> might be stuck in a loop, or it might be a very long-running program,
> & you want to see how far it has got).  And in how many
> can you resume the program as if it was uninterrupted.  And in
> how many can you change the values of variables, and continue?

Any language with a de{*filter*}. Which is almost all of them.

Quote:

>    In how many prog. languages can you resume execution following
> some computational error? (with a new batch of data).  For
> real-time processing, you definitely need an interrupt-handling
> mechanism.

I'm not sure what you're talking about here.  Are you talking about
after an exception is handled proceeding on as if the exception never
occured? That is a feature that has surfaced in a language or two, but
every paper on exception handling that ever addressed the issue, so
far as I have seen, panned this really hard, with just cause.

If you're just talking about being able to catch an exception, a large
percentage of the languages developed since CLU have had exception
handling.  

Quote:
>    BTW, In PL/I, you can create your own conditions and signal
> that condition (i.e. make a software interrupt).

This is the case w/ any language w/ exception handling... which is a
lot of them.

Quote:
> I suggest you take a look at Gerry Weinberg's book (PL/I -  A
> Manual of Style) to see what can be done with exception handling.

Huh??  I was saying that PL/I's exception handling, while being a
proof of concept, wasn't what people who wanted exception handling
wanted, and in that respect was a failure.  I don't see where you
infered that I don't really know what exception handling is.  I use it
pretty much every day in a variety of languages.


Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.

Quote:
> ---I suspect that the original commenter was referring to Algol 60.

        Well, Algol 60 was fairly popular, but the whole CS community
was pushing Algol 68.  And Algol 68 took so long to develop a compiler
for, that people had moved on to other languages by the time it was
completed.

Quote:
>    >include specifications on a few key things, such as I/O.  This is
>    >because they wanted a common specification for all machines, and
>    >thought I/O would be different enough from place to place that it
>    >should be implementation dependant.

> ---I think that most would agree that this was a mistake, as I/O
> has been defined in various languages, and implementers have been
> able to get it to work more-or-less uniformly. The same could
> have been done with Algol 60.

20/20 vision with your hindsight.  This wasn't so obvious in the youth
of computer science.

Quote:
> ---Every Algol 60 implementation I've seen implemented I/O
> differently.

Hmm, I know of 2 Algol 60 implementations that had prints, printi, and
(I think) printr for printing string literals, integers and reals.

John

------------------------------------------------------------------------------|
|John Viega                           "Non-structurally equivolent types in C |

| http://www.*-*-*.com/ .{*filter*}ia.edu/~jtv2j/    entity, the core dump."                |
|University of {*filter*}ia                                  --George Williams    |
-------------------------------------------------------------------------------



Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.

Quote:

>3) The syntax was also not simple... in fact, PL/I requires arbitrary
>lookahead to parse, since you can have function names that are the
>same as keywords.

Keywords are also not 'reserved words' in REXX (which is in some ways a
mini-PL/1).  However, this does not require arbitrary lookahead because
keywords are only reserved in certain specific places and only in a couple
of cases do you need a single (nonblank) character lookahead to see whether
there is an '=' or ':' next.

Even if it does require a complex parser, that doesn't say anything about
how easy or hard the language is to program in.


http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html



Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.

Quote:

>almost no one outside of the IBM community uses PL/I.  And even IBM is
>moving towards Rexx.

What?!  Are you seriously suggesting REXX as the successor to PL/I?

I have programmed in both, and I can think of few applications for which
I would consider both languages equally appropriate.

By its very nature, REXX would be a dog for any application envolving
lots of I/O or serious number crunching.  PL/I, on the other hand, would
be over-kill for most of the on-line macro applications that are so often
written in REXX.

--
____________________________________
Carrington Dixon
Credit Union Services Division - EDS



Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.


Quote:


>> 3) The syntax of PL/I was also not simple...
>>What about C ? Which code is more readable and easier to maintain ?
>> In today's context, PL/I fails to support more modern programming
>> features, most notably the object oriented paradigm.  PL/I's exception
>> handling mechanism was an experiment that proved that exception
>> handling was feasable to implement, but isn't very useful in
>> practice... a more modern/usable exception system would appeal to a
>> lot of people.
>We shouldn't compare languages used in DIFFERENT areas.

                        ...................

Look at the subject of this thread.  It is GENERAL PURPOSE language.
I see no reason why we cannot have a sufficiently flexible language
to be able to produce quite readable and reasonably efficient code
for all purposes.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399



Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.

Quote:


>>: Speaking as someone who has delved into the intricacies of PL/I, I am
>>: sure that only Real Men could have written such a machine-hogging,
>>: cycle-grabbing, all-encompassing monster.  Allocate an array and free
>>: the middle third?  Sure!  Why not?  Multiply a character string times a
>>: bit string and assign the result to a float decimal?  Go ahead!  Free a
>>: controlled variable procedure parameter and reallocate it before
>>: passing it back?  Overlay three different types of variable on the same
>>: memory location?
>>Once I wrote a litte program that makes use of all the above. I don't
>>know what these features are good for.
>Maybe BASIC is the language for you.  It forbids all the above.   With the
>exception of free the middle third, which I believe you cannot do in PL/I,
>I can see instances in which these each of these
>would be very valuable and tidy facilities.  If
>you can't maybe your problems are best coded up in a simpler language.

Pardon, BASIC what's that?

Freeing the middle third of an array works and I can't find anything
that forbits it.

Maybe you didn't get my point: Almost anything is possible and that's
bad IMHO.

I've been programming in PL/I for several years. But in more than 90% of
all cases when I encoutered one of those `benefits' it was by
mistake. Surly I must be able to convert a string into some numeric
type. I don't have a problem telling the compiler about that.

At a time, where you could make about one compilation per day it was of
course useful to have a compiler that makes the best of an erroneous
source. But today I have to search for those `conversion done by
subroutine call'-messages to find my typos, where a stop of processing
would be appropriate.

Quote:
>Now, to test you all:  Give an example of freeing and reallocating a
controlled
>parameter that otherwise requires much more complex coding (and less clear).

Passing a pointer to a pointer by value or a simple pointer by reference
yields the same result in any case.

But what about freeing the middle third?

-jo
--
-rw-r--r--   1 jo       users          75 Feb 13 21:08 /home/jo/.signature



Sat, 01 Aug 1998 03:00:00 GMT  
 General purpose language.
Somebody several levels of quotation deep wrote

        >Very arguable.  Algol 60 was moderately successful, but the CS
        >community then decided to devlop Algol 68.  Algol 68 was a _very_ large
        >language, which supported operator overloading, and even operator
        >precidence redefinition.  The specification was almost impossible to
        >decipher, decent compilers for the language were almost impossible to
        >write, and the language was notoriously difficult to learn (mainly due
        >to its unique terminology that book writers tended to adapt.)
        >Tannenbaum wrote a fairly decent tutorial, and there was a fairly
        >popular book called, "Algol 68 w/o Tears" or "Algol 68 w/ fewer Tears"
        >or something like that.

This is disinformation.
With the exception of formatted I/O, Algol 68 is about the same "size" as
Pascal or C, as a language.  User-defined operators add very little to the
size of the specification of a language, and very little indeed to the size
of the compiler.  Overloading adds little to the size of the specification,
not a whole lot to the compiler, and _can_ add greatly to the clarity of the
program.

The language was very easy to learn.  The original report was actually dead
simple to read if you just ignored the formal details and concentrated on
the text; the revised report was clearer.  (The reason that it LOOKED
hard was that it specified detail that the Pascal standard simply left to
the reader's imagination.)  Decent compilers were hard to write _at the time_
because decent compilers for _anything_ were hard to write; a 50k machine
was considered large.  Despite that, there were several good compilers.
The RSRE compiler was particularly good.  I used the Cambridge Algol 68C
compiler for several years on a TOPS-10 system.  There was also FLACC.
Oh yes, the Algol 68C compiler was not particularly large either.  It ran
happily in a 300kbyte address space.

The terminology is part of the _report_, not part of the _language_.
I can't think of any words _in the language_ that would mystify a C
programmer, except possibly "entier", which was standard at the time.

"Algol 68 with fewer tears" was not a book, it was an article in
The Computer Journal.  The entry to Algol 68 for many of its admirers
was "Informal Introduction to Algol 68" by Lindsey and van der Meulen.

Algol 68 did not "fail" due to any defects of its own, but was stifled
by the explosive growth of Pascal.

Someone else wrote

Quote:
>---I think that most would agree that this was a mistake, as I/O
>has been defined in various languages, and implementers have been
>able to get it to work more-or-less uniformly. The same could
>have been done with Algol 60.

But there _was_ a standard for I/O in Algol 60.  It was a _separate_
standard, but it _did_ exist.  (Frankly, I loathed it, and if you want
to say that the standard for Algol 60 I/I was _bad_ I'd agree.  But it
was there all right.  I recall it as being published in CACM.)

--
"conventional orthography is ... a near optimal system for the
 lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



Sat, 01 Aug 1998 03:00:00 GMT  
 
 [ 55 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Forth as a general purpose language

2. General purpose language.

3. General Purpose Language

4. General purpose language.

5. GUI-aware general-purpose languages (was: Solaris 2.6 vs. NT: unbiased report?)

6. Sisal array optimsations in general purpose functional language

7. general-purpose vs. domain-specific programming languages

8. general-purpose vs domain-specific programming languages

9. Best general purpose OO lang

10. General Purpose DLL in C4 ?

11. pulse train generation without general purpose counters

12. Best general purpose OO lang

 

 
Powered by phpBB® Forum Software