[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[arnold]

	Seek and ye shall find.

	Ask and ye shall receive.

Brian Kernighan was kind enough to find for me everyone's favorite
Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
My Favorite Programming Language".

Attached is the file and his macros.  This will not immediately
format using groff etc.; I hope to create a version that will, sometime
in the next few weeks.

In the meantime, Warren, please add to the archives when you are able.

Enjoy!

Arnold
-------------- next part --------------
.fp 1 PA
.fp 2 PI
.fp 3 PB
.ds pf CW
.so /usr/bwk/src/cprog.mac
.if n .ls 2
....ND "April 2, 1981"
....TM 81-11272-12 11173 39199-11
.TR 100
.TL
Why Pascal is Not My Favorite Programming Language
.AU "MH 2C-518" 6021
Brian W. Kernighan
.AI
.MH
.AB
.PP
The programming language Pascal has become the dominant language
of instruction in computer science education.
It has also strongly influenced languages developed subsequently,
in particular Ada.
.PP
Pascal was originally intended primarily as a teaching language,
but it has been more and more often recommended as a language
for serious programming as well,
for example, for system programming tasks and even operating systems.
.PP
Pascal, at least in its standard form, is just plain not suitable for serious programming.
This paper discusses my personal discovery of some of the reasons why.
.AE
.CS 1 0 1 0 0  18
.NH
Genesis
.PP
This paper has its origins in two events \(em
a spate of papers that compare C and Pascal
.[
%T A Comparison of the Programming Languages C and Pascal \(em Part I: Language Concepts
%A Feuer, A. R.
%A N. H. Gehani
%D September 1979
%R Bell Labs internal memorandum
.]
.[
%T A Comparison of the Programming Languages C and Pascal \(em Part II: Program Properties and Programming Domains
%A N. H. Gehani
%A A. R. Feuer
%D February 1980
%R Bell Labs internal memorandum
.]
.[
%T Pascal versus C: A Subjective Comparison
%A P. Mateti
%J Language Design and Programming Methodology Symposium
%O Sydney, Australia
%D September 1979
%I Springer-Verlag
.]
.[
%T A Comparison of Language C and Pascal
%A A. Springer
%R IBM Technical Report G320-2128, Cambridge Scientific Center
%D August 1979
.]
and a personal attempt to rewrite
.ul
Software Tools
.[
kernighan plauger software tools addison
.]
in Pascal.
.PP
Comparing C and Pascal is rather like comparing
a Learjet to a Piper Cub \(em one is meant for getting something done while
the other is meant for learning \(em
so such comparisons tend to be somewhat farfetched.
But the revision of
.ul
Software Tools
seems a more relevant comparison.
The programs therein were originally written
in Ratfor,
a ``structured'' dialect of Fortran implemented by a preprocessor.
Since Ratfor is really Fortran in disguise, it has few of the
assets that Pascal brings \(em
data types more suited to character processing,
data structuring capabilities for better defining
the organization of one's data,
and strong typing to enforce telling the truth
about the data.
.PP
It turned out to be harder than I had expected
to rewrite the programs in Pascal.
This paper is an attempt to distill out of the experience
some lessons about Pascal's suitability for
programming (as distinguished from learning about programming).
It is
.ul
not
a comparison of Pascal with C or Ratfor.
.PP
The programs were first written in that dialect
of Pascal supported by the Pascal interpreter
.ul
pi
provided by the University of California at Berkeley.
The language is close to the nominal standard
of Jensen and Wirth,
.[
jensen wirth pascal report 1978
%O (2nd edition.)
.]
with good diagnostics and careful run-time checking.
Since then, the programs have also been run, unchanged
except for new libraries of primitives, on four other systems:
an interpreter
from the Free University of Amsterdam
(hereinafter referred to as VU, for Vrije Universiteit),
a VAX version of the Berkeley system (a true compiler),
a compiler purveyed by Whitesmiths, Ltd.,
and UCSD Pascal on a Z80.
All but the last of these Pascal systems are written in C.
.PP
Pascal is a much-discussed language.
A recent bibliography
.[
%A David V. Moffat
%T A Categorized Pascal Bibliography
%J SIGPLAN Notices
%V 15
%N 10
%P 63-75
%D October 1980
.]
lists 175 items under the heading of
``discussion, analysis and debate.''
The most often cited papers (well worth reading) are
a strong critique by Habermann
.[
habermann pascal critical
.]
and an equally strong rejoinder by
Lecarme and Desjardins.
.[
%A O. Lecarme
%A P. Desjardins
%T More Comments on the Programming Language Pascal
%J Acta Informatica
%V 4
%P 231-243
%D 1975
.]
The paper by Boom and DeJong
.[
%T A Critical Comparison of Several Programming Language Implementations
%A H. J. Boom
%A E. DeJong
%J Software Practice and Experience
%V 10
%N 6
%D June 1980
%P 435-473
.]
is also good reading.
Wirth's own assessment of Pascal is found in
.[ [
%T An Assessment of the Programming Language Pascal
%A N. Wirth
%J IEEE Transactions on Software Engineering
%V SE-1
%N 2
%D June, 1975
%P 192-198
.]].
I have no desire or ability to summarize the literature;
this paper represents my personal observations
and most of it necessarily duplicates points made by others.
I have tried to organize the rest of the material
around the issues of
.DS
types and scope
control flow
environment
cosmetics
.DE
and within each area more or less in decreasing order
of significance.
.PP
To state my conclusions at the outset:
Pascal may be an admirable language for teaching beginners
how to program; I have no first-hand experience with that.
It was a considerable achievement for 1968.
It has certainly influenced the design of recent languages,
of which Ada is likely to be the most important.
But in its standard form (both current and proposed),
Pascal is not adequate for writing real programs.
It is suitable only for small, self-contained programs
that have only trivial interactions with their environment
and that make no use of any software written by anyone else.
.NH
Types and Scopes
.PP
Pascal is (almost) a strongly typed language.
Roughly speaking, that means that each object
in a program has a well-defined type which implicitly
defines the legal values of and operations on the object.
The language guarantees that it will prohibit illegal values and operations,
by some mixture of compile- and run-time checking.
Of course compilers may not actually do all the checking implied in
the language definition.
Furthermore, strong typing is
.ul
not
to be confused with dimensional analysis.
If one defines 
types
.UL apple
and
.UL orange
with
.P1
type
	apple = integer;
	orange = integer;
.P2
then any arbitrary arithmetic expression involving
.UL apples
and
.UL oranges 
is perfectly legal.
.PP
Strong typing shows up in a variety of ways.
For instance, arguments to functions and procedures are checked
for proper type matching.
Gone is the Fortran freedom to
pass a floating point number into a subroutine that expects an integer;
this I deem a desirable attribute of Pascal,
since it warns of a construction that will certainly cause an error.
.PP
Integer variables may be declared to have an associated range
of legal values, and the compiler and run-time support
ensure that one does not put large integers
into variables that only hold small ones.
This too seems like a service,
although of course run-time checking does exact a penalty.
.PP
Let us move on to 
some problems of type and scope.
.NH 2
The size of an array is part of its type
.PP
If one declares
.P1
var	arr10 : array [1..10] of integer;
	arr20 : array [1..20] of integer;
.P2
then
.UL arr10
and
.UL arr20
are arrays of 10 and 20 integers respectively.
Suppose we want to write a procedure
.UL sort
to sort an integer array.
Because
.UL arr10
and
.UL arr20
have different types,
it is not possible to write a single procedure
that will sort them both.
.PP
The place where this affects
.ul
Software Tools
particularly, and I think programs in general,
is that it makes it difficult indeed
to create a library of routines for doing common, general-purpose operations
like sorting.
.PP
The particular data type most often affected is
.UL array
.UL of
.UL char ,
for in Pascal a string is an array of characters.
Consider writing a function
.UL index(s,c)
that will return the position in the string
.UL s
where the character
.UL c
first occurs, or zero if it does not.
The problem is how to handle the string argument of
.UL index .
The calls
.UL index('hello',c)
and
.UL index('goodbye',c)
cannot both be legal,
since the strings have different lengths.
(I pass over the question of how the end of a constant string
like
.UL 'hello'
can be detected, because it can't.)
.PP
The next try is
.P1
var temp : array [1..10] of char;

temp := 'hello';

n := index(temp,c);
.P2
but the assignment to
.UL temp
is illegal because
.UL \&'hello'
and
.UL temp
are of different lengths.
.PP
The only escape from this infinite regress
is to define a family of routines
with a member for each possible string size,
or to make all strings
(including constant strings like
.UL 'define' )
of the same length.
.PP
The latter approach is the lesser of two great evils.
In
.IT Tools ,
a type called
.UL string
is declared as
.P1
type string = array [1..MAXSTR] of char;
.P2
where
the constant
.UL MAXSTR
is ``big enough,''
and
all strings in all programs are exactly this size.
This is far from ideal,
although it made it possible to get the programs running.
It does
.ul
not
solve the problem of creating true libraries of useful routines.
.PP
There are some situations where it is simply not acceptable
to use the fixed-size array representation.
For example, the
.ul
Tools
program to sort lines of text
operates by fill\%ing up memory with as many lines as will fit;
its running time depends strongly on how full the memory can be packed.
Thus for
.UL sort ,
another representation is used,
a long array of characters and a set of indices into this array:
.P1
type	charbuf = array [1..MAXBUF] of char;
	charindex = array [1..MAXINDEX] of 0..MAXBUF;
.P2
But
the procedures and
functions written to process the fixed-length representation
cannot be used with the variable-length form;
an entirely new set of routines is needed to
copy and compare strings in this representation.
In Fortran or C the same functions could be used for both.
.PP
As suggested above, a constant string is written as
.P1
\&'this is a string'
.P2
and has the type
.UL packed
.UL array
.UL [1..n]
.UL of
.UL char ,
where
.UL n
is the length.
Thus each string literal of different length has a different type.
The only way to write a routine that will print a message and clean up
is to pad all messages out to the same maximum length:
.P1
error('short message                    ');
error('this is a somewhat longer message');
.P2
.PP
Many commercial Pascal compilers provide a
.UL string
data type that explicitly avoids the problem;
.UL string 's
are all taken to be the same type regardless of size.
This solves the problem for this single data type,
but no other.
It also fails to solve secondary problems
like computing the length of a constant string;
another built-in function is the usual solution.
.PP
Pascal enthusiasts
often claim that
to cope with the array-size problem
one merely has to copy some library routine
and fill in the parameters for the program
at hand,
but the defense sounds weak at best:
.[
%A O. Lecarme
%A P. Desjardins
%T ibid
%O p. 239
.]
.QS
``Since the bounds of an array are part of its type
(or, more exactly, of the type of its indexes),
it is impossible to define a procedure or function
which applies to arrays with differing bounds.
Although this restriction may appear to be a severe one,
the experiences we have had with Pascal tend to show that it
tends to occur very infrequently.
[...]
However, the need to bind the size of parametric arrays
is a serious defect in connection with the use of program libraries.''
.QE
.PP
This botch is the biggest single problem with Pascal.
I believe that if it could be fixed,
the language would be an order of magnitude more usable.
The proposed ISO standard for Pascal
.[
%A A. M. Addyman
%T A Draft Proposal for Pascal
%J SIGPLAN Notices
%D April 1980
%V 15
%N 4
%P 1-66
.]
provides such a fix
(``conformant array schemas''),
but the acceptance of this part of the standard is apparently
still in doubt.
.NH 2
There are no static variables and no initialization
.PP
A
.ul
static
variable
(often called an
.ul
own
variable in Algol-speaking countries)
is one that is private to some routine
and retains its value from one call of the routine to the next.
.ul
De facto,
Fortran variables are internal static, except for COMMON;\(dg
.FS
\(dg Strictly speaking, in Fortran 77 one must use
.UL SAVE 
to force the static attribute.
.FE
in C there is a
.UL static
declaration that can be applied to local variables.
.PP
Pascal has no such storage class.
This means that if a Pascal function or procedure intends to remember
a value from one call to another, the variable used
must be external to the function or procedure.
Thus it must be visible to other procedures,
and its name must be unique in the larger scope.
A simple example of the problem is a random number generator:
the value used to compute the current output must be saved
to compute the next one,
so it must be stored in a variable whose lifetime includes
all calls of the random number generator.
In practice, this is typically the outermost block of the program.
Thus the declaration of such a variable is far removed from the place
where it is actually used.
.PP
One example comes from the text formatter described in Chapter 7 of
.ul
Tools.
The variable 
.UL dir
controls the direction from which
excess blanks are inserted during line justification,
to obtain left and right alternately.
In Pascal, the code looks like this:
.P1
program formatter (...);

var
	dir : 0..1;	{ direction to add extra spaces }
	.
	.
	.
procedure justify (...);
begin
	dir := 1 - dir;	{ opposite direction from last time }
	...
end;

	...

begin { main routine of formatter }
	dir := 0;
	...
end;
.P2
The declaration,
initialization
and use
of the variable
.UL dir
are scattered all over the program,
literally hundreds of lines apart.
In C or Fortran,
.UL dir
can be made private to the only routine
that needs to know about it:
.P1
	...
main()
{
	...
}

	...

justify()
{
	static int dir = 0;

	dir = 1 - dir;
	...
}
.P2
.PP
There are of course many other examples of the same problem on a larger scale;
functions for buffered I/O,
storage management,
and symbol tables all spring to mind.
.PP
There are at least two related problems.
Pascal provides no way to 
initialize variables
statically
(i.e., at compile time);
there is nothing analogous to Fortran's
.UL DATA
statement or initializers like
.P1
int dir = 0;
.P2
in C.
This means that a Pascal program must contain explicit assignment statements
to initialize variables
(like the
.P1
dir := 0;
.P2
above).
This code makes the program source text bigger,
and the program itself bigger at run time.
.PP
Furthermore, the lack of initializers exacerbates the problem
of too-large scope caused by the lack of a static storage class.
The time to initialize
things is at the beginning,
so either the main routine itself begins with a lot of initialization code,
or it calls one or more routines to do the initializations.
In either case,
variables to be initialized
must be visible,
which means in effect at the highest level
of the hierarchy.
The result is that any variable that is to be initialized
has global scope.
.PP
The third difficulty is that there is no way
for two routines to share a variable unless
it is declared at or above their least common ancestor.
Fortran 
.UC COMMON
and
C's external static storage class both provide
a way for two routines to cooperate privately,
without sharing information with their ancestors.
.PP
The new standard does not offer static variables, initialization or non-hierarchical communication.
.NH 2
Related program components must be kept separate
.PP
Since the original Pascal was implemented with a one-pass compiler,
the language believes strongly in declaration before use.
In particular, procedures and functions must be declared (body and all)
before they are used.
The result is that a typical Pascal program reads from the bottom up \(em
all the procedures and functions are displayed before any of the code that
calls them,
at all levels.
This is essentially opposite to the order in which
the functions are designed and used.
.PP
To some extent this can be mitigated by a mechanism like the
.UL #include
facility of C and Ratfor:
source files can be included where needed without cluttering
up the program.
.UL #include
is not part of standard Pascal, although the UCB, VU and Whitesmiths compilers
all provide it.
.PP
There is also a
.UL forward
declaration in Pascal that permits separating the
declaration of the function or procedure header from
the body;
it is intended for defining mutually recursive procedures.
When the body is declared later on,
the header on that may contain only the function name,
and must not repeat the information from the first instance.
.PP
A related problem is that Pascal has a strict order
in which it is willing to accept declarations.
Each procedure or function consists of
.P1
.ta .6i
label	\f2label declarations, if any\fP
const	\f2constant declarations, if any\fP
type	\f2type declarations, if any\fP
var	\f2variable declarations, if any\fP
procedure \f2and\fP function \f2declarations, if any\fP
begin
	\f2body of function or procedure\fP
end
.P2
This means that all declarations of one kind (types, for instance)
must be grouped together for the convenience of the compiler,
even when the programmer would like to keep together
things that are logically related
so as to understand the program better.
Since a program has to be presented to the compiler all at once,
it is rarely possible to keep
the declaration, initialization and use of types and variables
close together.
Even some of the most dedicated Pascal supporters agree:
.[
%A J. Welsh
%A W. J. Sneeringer
%A C. A. R. Hoare
%T Ambiguities and Insecurities in Pascal
%J Software Practice and Experience
%V 7
%P 685-696
%D 1977
.]
.QS
``The inability to make such groupings
in structuring large programs
is one of Pascal's most frustrating limitations.''
.QE
.LP
A file inclusion facility helps only a little here.
.PP
The new standard does not relax the requirements
on the order of declarations.
.NH 2
There is no separate compilation
.PP
The ``official'' Pascal language does not provide separate compilation,
and so each implementation decides on its own what to do.
Some (the Berkeley interpreter, for instance) disallow it entirely;
this is closest to the spirit of the language
and matches the letter exactly.
Many others provide a declaration
that specifies that the body of a function is externally defined.
In any case, all such mechanisms are non-standard, and thus done
differently by different systems.
.PP
Theoretically, there is no need for separate compilation \(em
if one's compiler is very fast
(and if the source for all routines is always available
and if one's compiler has a file inclusion facility so that multiple copies
of source are not needed),
recompiling everything is equivalent.
In practice, of course,
compilers are never fast enough
and source is often hidden
and file inclusion is not part of the language,
so changes are time-consuming.
.PP
Some systems permit separate compilation
but do not validate consistency of types across the boundary.
This creates a giant hole in the strong typing.
(Most other languages do no cross-compilation checking either,
so Pascal is not inferior in this respect.)
I have seen at least one paper (mercifully unpublished) that on page
.IT n
castigates C for
failing to check types across separate compilation boundaries
while suggesting on page
.IT n +1
that the way to cope with Pascal
is to compile procedures separately
to avoid type checking.
.PP
The new standard does not offer separate compilation.
.NH 2
Some miscellaneous problems of type and scope
.PP
Most of the following points are minor irritations,
but I have to stick them in somewhere.
.PP
It is not legal to name a non-basic type
as the literal formal parameter of a procedure;
the following is not allowed:
.P1
procedure add10 (var a : array [1..10] of integer);
.P2
Rather, one must invent a type name, make a type declaration,
and declare the formal parameter to be an instance of that type:
.P1
type	a10 = array [1..10] of integer;
\&...
procedure add10 (var a : a10);
.P2
Naturally the type declaration is physically separated
from the procedure that uses it.
The discipline of inventing type names is helpful
for types that are used often,
but it is a distraction for things used only once.
.PP
It is nice to have the declaration
.UL var
for formal parameters of functions and procedures;
the procedure clearly states that it intends to modify
the argument.
But the calling program has no way to declare that a variable
is to be modified \(em
the information is only in one place, while two places would be better.
(Half a loaf is better than none, though \(em
Fortran tells the user nothing about who will do what
to variables.)
.PP
It is also a minor bother that arrays are passed by value
by default \(em the net effect is that every array
parameter is declared
.UL var
by the programmer more or less without thinking.
If the
.UL var
declaration is inadvertently omitted,
the resulting bug is subtle.
.PP
Pascal's
.UL set
construct seems like a good idea,
providing notational convenience and some free type checking.
For example, a set of tests like
.P1
if (c = blank) or (c = tab) or (c = newline) then ...
.P2
can be written rather more clearly and perhaps more efficiently as
.P1
if c in [blank, tab, newline] then ...
.P2
But in practice, set types are not useful for much more than
this, because the size of a set is strongly implementation
dependent (probably because it was so in the original CDC implementation:
59 bits).
For example, it is natural to attempt to write the function
.UL isalphanum(c)
(``is 
.UL c
alphanumeric?'') as
.P1
{ isalphanum(c) -- true if c is letter or digit }
function isalphanum (c : char) : boolean;
begin
	isalphanum := c in ['a'..'z', 'A'..'Z', '0'..'9']
end;
.P2
But in many implementations of Pascal (including the original)
this code fails because sets are just too small.
Accordingly,
sets are generally best left unused if one intends to write
portable programs.
(This specific routine also runs an order of magnitude slower
with sets than with a range test or array reference.)
.NH 2
There is no escape
.PP
There is no way to override the type mechanism when necessary,
nothing analogous to the ``cast'' mechanism in C.
This means that it is not possible to write programs like
storage allocators or I/O systems in Pascal,
because there is no way to talk about the type of object
that they return,
and no way to force such objects into an arbitrary type for
another use.
(Strictly speaking, there is a large hole in the type-checking
near variant records, through which some otherwise illegal 
type mismatches can be obtained.)
.NH
Control Flow
.PP
The control flow deficiencies of Pascal are minor but numerous
\(em
the death of a thousand cuts,
rather than a single blow to a vital spot.
.PP
There is no guaranteed order of evaluation of the logical operators
.UL and
and
.UL or
\(em nothing like
.UL && 
and
.UL ||
in C.
This failing, which is shared with most other languages,
hurts most often in loop control:
.P1
while (i <= XMAX) and (x[i] > 0) do ...
.P2
is extremely unwise Pascal usage,
since there is no way to ensure that 
.UL i
is tested before
.UL x[i]
is.
.PP
By the way, the parentheses in this code are mandatory \(em
the language has only four levels of operator precedence,
with relationals at the bottom.
.PP
There is no
.UL break
statement for exiting loops.
This is consistent with the one entry-one exit philosophy
espoused by proponents of structured programming,
but it does lead to nasty circumlocutions or duplicated code,
particularly when coupled with the inability to control the order in which
logical expressions are evaluated.
Consider this common situation, expressed in C or Ratfor:
.P1
while (getnext(...)) {
	if (something)
		break
	rest of loop
}
.P2
With no
.UL break
statement, the first attempt in Pascal is
.P1
done := false;
while (not done) and (getnext(...)) do
	if something then
		done := true
	else begin
		rest of loop
	end
.P2
But this doesn't work, because there is no way to force
the 
.UL not "" ``
.UL done ''
to be evaluated before the
next call of
.UL getnext .
This leads, after several false starts, to
.P1
done := false;
while not done do begin
	done := getnext(...);
	if something then
		done := true
	else if not done then begin
		rest of loop
	end
end
.P2
Of course recidivists can use a
.UL goto
and a label (numeric only and it has to be declared) to exit a loop.
Otherwise, early exits are a pain,
almost always requiring the invention of a boolean variable
and a certain amount of cunning.
Compare finding the last non-blank in an array in
Ratfor:
.P1
for (i = max; i > 0; i = i - 1)
	if (arr(i) != ' ')
		break
.P2
with Pascal:
.P1
done := false;
i := max;
while (i > 0) and (not done) do
	if arr[i] = ' ' then
		i := i - 1
	else
		done := true;
.P2
.PP
The index of a
.UL for
loop is undefined outside the loop, so
it is not possible to figure out whether one 
went to the end or not.
The increment of a
.UL for
loop can only be
.UL +1
or
.UL -1 ,
a minor restriction.
.PP
There is no 
.UL return
statement,
again for one in-one out reasons.
A function value is returned by setting the value of a pseudo-variable
(as in Fortran), then falling off the end of the function.
This sometimes leads to contortions to make sure that all paths
actually get to the end of the function with the proper value.
There is also no standard way to terminate execution
except by reaching the end of the outermost block,
although
many implementations
provide a
.UL halt
that causes immediate termination.
.PP
The
.UL case
statement is better designed than in C,
.ul
except
that there is no
.UL default
clause and the behavior is undefined 
if the input expression does not match any of the cases.
This crucial omission
renders the 
.UL case
construct almost worthless.
In over 6000 lines of Pascal in
.IT "Software Tools in Pascal" ,
I used it only four times,
although if there had been a
.UL default ,
a
.UL case
would have served in at least a dozen places.
.PP
The new standard offers no relief on any of these points.
.NH
The Environment
.PP
The Pascal run-time environment is relatively sparse,
and there is no extension mechanism except perhaps source-level
libraries in the ``official'' language.
.PP
Pascal's built-in I/O has a deservedly bad reputation.
It believes strongly in record-oriented input
and output.
It also has a look-ahead convention that is hard to
implement properly in an interactive environment.
Basically, the problem is that the I/O system believes that
it must read one record ahead of the record
that is being processed.
In an interactive system, this means that when a program is started,
its first operation is to try to read the terminal for the first
line of input,
before any of the program itself has been executed.
But in the program
.P1
write('Please enter your name: ');
read(name);
\&...
.P2
read-ahead causes the program to hang, waiting
for input before printing the prompt that asks for it.
.PP
It is possible to escape most of the evil effects of
this I/O design by very careful implementation,
but not all Pascal systems do so,
and in any case it is relatively costly.
.PP
The I/O design reflects the original operating system
upon which Pascal was designed;
even Wirth acknowledges that bias,
though not its defects.
.[
%A N. Wirth
%J ibid.
%O p. 196
.]
It is assumed that text files consist of records,
that is, lines of text.
When the last character of a line is read, the 
built-in function
.UL eoln
becomes true;
at that point, one must call
.UL readln
to initiate reading a new line
and reset
.UL eoln .
Similarly, when the last character of the file is read,
the built-in
.UL eof
becomes true.
In both cases,
.UL eoln
and
.UL eof
must be tested before each
.UL read
rather than after.
.PP
Given this, considerable pains must be taken to simulate sensible input.
This implementation of
.UL getc
works for Berkeley and VU I/O systems,
but may not necessarily work for anything else:
.P1
{ getc -- read character from standard input }
function getc (var c : character) : character;
var
	ch : char;
begin
	if eof then
		c := ENDFILE
	else if eoln then begin
		readln;
		c := NEWLINE
	end
	else begin
		read(ch);
		c := ord(ch)
	end;
	getc := c
end;
.P2
The type
.UL character
is not the same as
.UL char ,
since
.UL ENDFILE
and perhaps
.UL NEWLINE
are not legal values
for a
.UL char
variable.
.PP
There is no notion at all of access to a file system except for predefined files
named by (in effect) logical unit number
in the 
.UL program
statement that begins each program.
This apparently reflects the CDC batch system in which
Pascal was originally developed.
A file variable
.P1
var	fv : file of \f2type\fP
.P2
is a very special kind of object \(em
it cannot be assigned to, nor used except by calls to built-in procedures
like
.UL eof ,
.UL eoln ,
.UL read ,
.UL write ,
.UL reset
and
.UL rewrite .
.UL reset "" (
rewinds a file and makes it ready for re-reading;
.UL rewrite
makes a file ready for writing.)
.PP
Most implementations of Pascal provide an escape hatch
to allow access to files by name from the outside environment,
but not conveniently
and not standardly.
For example, many systems permit a filename argument
in calls to
.UL reset
and
.UL rewrite :
.P1
reset(fv, filename);
.P2
But
.UL reset
and
.UL rewrite
are procedures, not functions \(em
there is no status return and
no way to regain control if for some reason
the attempted access fails.
(UCSD provides a compile-time flag
that disables the normal abort.)
And since
.UL fv 's
can not appear in expressions like
.P1
reset(fv, filename);
if fv = failure then ...
.P2
there is no escape in that direction either.
This straitjacket makes it essentially impossible to write programs
that recover from mis-spelled file names, etc.
I never solved it adequately in the
.ul
Tools
revision.
.PP
There is no notion of access to command-line arguments,
again probably reflecting Pascal's batch-processing origins.
Local routines may allow it by adding non-standard procedures to the environment.
.PP
Since it is not possible to write a general-purpose storage allocator
in Pascal
(there being no way to talk about the types that such a function
would return),
the language has a built-in procedure
called
.UL new
that allocates space from a heap.
Only defined types may be allocated,
so it is not possible to allocate, for example,
arrays of arbitrary size to hold character strings.
The pointers returned by
.UL new
may be passed around but not manipulated:
there is no pointer arithmetic.
There is no way to regain control if storage runs out.
.PP
The new standard offers no change in any of these areas.
.NH
Cosmetic Issues
.PP
Most of these issues are irksome to an experienced programmer,
and some are probably a nuisance even to beginners.
All can be lived with.
.PP
Pascal, in common with most other Algol-inspired languages,
uses the semicolon as a statement separator rather than a terminator
(as it is in PL/I and C).
As a result one must have a reasonably sophisticated notion
of what a statement is to put semicolons in properly.
Perhaps more important, if one is serious about using them
in the proper places, a fair amount of nuisance editing is needed.
Consider the first cut at a program:
.P1
if a then
	b;
c;
.P2
But if something must be inserted before
.UL b ,
it no longer needs a semicolon, because it now precedes an
.UL end :
.P1
if a then begin
	b0;
	b
end;
c;
.P2
Now if we add an
.UL else ,
we
.ul
must
remove the semicolon on the
.UL end :
.P1
if a then begin
	b0;
	b
end
else
	d;
c;
.P2
And so on and so on,
with semicolons rippling up and down the program
as it evolves.
.PP
One generally accepted experimental result in programmer psychology
is that semicolon as separator is about ten times
more prone to error than semicolon as terminator.
.[
%A J. D. Gannon
%A J. J. Horning
%T Language Design for Programming Reliability
%J IEEE Trans. Software Engineering
%V SE-1
%N 2
%D June 1975
%P 179-191
.]
(In Ada,
.[
%T Rationale for the Design of the Ada Programming Language
%A J. D. Ichbiah, et al
%J SIGPLAN Notices
%D June 1979
%V 14
%N 6
.]
the most significant language based on Pascal,
semicolon is a terminator.)
Fortunately, in Pascal one can almost always close one's eyes
and get away with a semicolon as a terminator.
The exceptions are in places like declarations, where the separator vs. terminator problem
doesn't seem as serious anyway,
and just before
.UL else ,
which is easy to remember.
.PP
C and Ratfor programmers find
.UL begin
and
.UL end
bulky compared to
.UL {
and
.UL } .
.PP
A function name by itself is a call of that function;
there is no way to distinguish such a function call from a simple variable
except by knowing the names of the functions.
Pascal uses the Fortran trick
of having the function name act like a variable within the function,
except that where in Fortran the function name really is a variable,
and can appear in expressions,
in Pascal, its appearance in an expression
is a recursive invocation:
if
.UL f
is a zero-argument function,
.UL f:=f+1
is a recursive call of
.UL f .
.PP
There is a paucity of operators (probably related to the
paucity of precedence levels).
In particular, there are no bit-manipulation operators
.UC AND , (
.UC OR ,
.UC XOR ,
etc.).
I simply gave up trying to write the following trivial encryption program
in Pascal:
.P1
i := 1;
while getc(c) <> ENDFILE do begin
	putc(xor(c, key[i]));
	i := i mod keylen + 1
end
.P2
because I couldn't write a sensible
.UL xor
function.
The set types help a bit here (so to speak), but not enough;
people who claim that Pascal is a system programming language
have generally overlooked this point.
For example,
.[ [
%A J. Welsh
%A W. J. Sneeringer
%A C. A. R. Hoare
%T ibid
.], p. 685]
.QS
``Pascal is at the present time
[1977]
the best language in the public domain
for purposes of system programming and software implementation.''
.QE
seems a bit naive.
.PP
There is no null string, 
perhaps because Pascal uses the
doubled quote notation to indicate a quote embedded in a string:
.P1
\&'This is a '' character'
.P2
There is no way to put non-graphic symbols into strings.
In fact, non-graphic characters are unpersons in a stronger sense,
since they are not mentioned in any part of the standard language.
Concepts like newlines, tabs, and so on are handled on each system
in an
.ul
ad hoc
manner,
usually by knowing something about the character set
(e.g., ASCII newline has decimal value 10).
.PP
There is no macro processor.
The
.UL const
mechanism for defining manifest constants
takes care of about 95 percent of the uses of
simple
.UL #define 
statements in C,
but more involved ones are hopeless.
It is certainly possible to put a macro preprocessor on a Pascal compiler.
This allowed me to simulate a sensible 
.UL error
procedure as
.P1
#define  error(s)  begin writeln(s); halt end
.P2
.UL halt "" (
in turn might be defined as a branch to the end of
the outermost block.)
Then calls like
.P1
	error('little string');
	error('much bigger string');
.P2
work
since
.UL writeln
(as part of the standard Pascal environment)
can handle strings of any size.
It is unfortunate that there is no way to make this convenience
available to routines in general.
.PP
The
language prohibits expressions in declarations, so it is not possible
to write things like
.P1
const	SIZE = 10;
type		arr = array [1..SIZE+1] of integer;
.P2
or even simpler ones like
.P1
const	SIZE = 10;
		SIZE1 = SIZE + 1;
.P2
.NH
Perspective
.PP
The effort to rewrite the programs in
.ul
Software Tools
started in March, 1980,
and, in fits and starts, lasted until January, 1981.
The final product
.[
%A B. W. Kernighan
%A P. J. Plauger
%T Software Tools in Pascal
%I Addison-Wesley
%D 1981
.]
was published in June, 1981.
During that time I gradually adapted to most of
the superficial problems with Pascal
(cosmetics, the inadequacies of control flow),
and developed imperfect solutions to the significant ones
(array sizes, run-time environment).
.PP
The programs in the book are meant to be complete, well-engineered
programs that do non-trivial tasks.
But they do not have to be efficient,
nor are their interactions with the operating system
very complicated,
so I was able to get by with some pretty kludgy solutions,
ones that simply wouldn't work for real programs.
.PP
There is no significant way in which I found Pascal superior to C,
but there are several places where it is
a clear improvement over Ratfor.
Most obvious by far is recursion:
several programs are much cleaner when written recursively,
notably the pattern-search, quicksort, and expression evaluation.
.PP
Enumeration data types are a good idea.
They simultaneously delimit the range of legal values
and document them.
Records help to group related variables.
I found relatively little use for pointers.
.PP
Boolean variables are nicer than integers for Boolean conditions;
the original Ratfor programs contained some unnatural constructions because
Fortran's logical variables are badly designed.
.PP
Occasionally Pascal's type checking would warn of a slip
of the hand in writing a program;
the run-time checking of values also indicated errors
from time to time, particularly subscript range violations.
.PP
Turning to the negative side, recompiling a large program from scratch to change a single line
of source is extremely tiresome;
separate compilation, with or without type checking,
is mandatory for large programs.
.PP
I derived little benefit from the fact that
characters are part of Pascal and not part of Fortran,
because the Pascal treatment of strings and non-graphics
is so inadequate.
In both languages, it is appallingly clumsy to initialize literal strings
for tables of keywords, error messages, and the like.
.PP
The finished programs are in general about the same number
of source lines as their Ratfor equivalents.
At first this surprised me,
since my preconception was that Pascal is a wordier and less expressive
language.
The real reason seems to be that Pascal permits arbitrary expressions
in places like loop limits and subscripts
where Fortran (that is, portable Fortran 66) does not,
so some useless assignments can be eliminated;
furthermore, the Ratfor programs declare functions while Pascal ones do not.
.sp
.PP
To close, let me summarize the main points in the case against Pascal.
.IP 1.
Since the size of an array is part of its type,
it is not possible to write general-purpose routines,
that is,
to deal with arrays of different sizes.
In particular, string handling is very difficult.
.IP 2.
The lack of static variables, initialization
and a way to communicate non-hierarchically
combine to destroy the ``locality'' of a program \(em
variables require much more scope than they ought to.
.IP 3.
The one-pass nature of the language forces procedures and functions
to be presented in an unnatural order;
the enforced separation of various declarations scatters program
components that logically belong together.
.IP 4.
The lack of separate compilation impedes the development of large programs
and makes the use of libraries impossible.
.IP 5.
The order of logical expression evaluation cannot be controlled,
which leads to convoluted code and extraneous variables.
.IP 6.
The
.UL case
statement is emasculated because there is no default clause.
.IP 7.
The standard I/O is defective.
There is no sensible provision for dealing with files or program arguments
as part of the standard language,
and no extension mechanism.
.IP 8.
The language lacks most of the tools needed for assembling
large programs, most notably file inclusion.
.IP 9.
There is no escape.
.PP
This last point is perhaps the most important.
The language is inadequate but circumscribed,
because there is no way to escape its limitations.
There are no casts to disable the type-checking
when necessary.
There is no way to replace the defective run-time environment
with a sensible one,
unless one controls the compiler that defines the ``standard procedures.''
The language is closed.
.PP
People who use Pascal for serious programming
fall into a fatal trap.
Because the language is so impotent, it must be extended.
But each group extends Pascal in its own direction,
to make it look like whatever language they really want.
Extensions for separate compilation,
Fortran-like
.UC COMMON ,
string data types,
internal static variables,
initialization,
octal numbers,
bit operators,
etc.,
all add to the utility of the language
for one group,
but destroy its portability to others.
.PP
I feel that it is a mistake to use Pascal for anything much
beyond its original target.
In its pure form,
Pascal is a toy language,
suitable for teaching but not for real programming.
.SH
Acknowledgments
.PP
I am grateful to
Al Aho,
Al Feuer,
Narain Gehani,
Bob Martin,
Doug McIlroy,
Rob Pike,
Dennis Ritchie,
Chris Van Wyk
and
Charles Wetherell
for helpful criticisms
of earlier versions of this paper.
.[
$LIST$
.]
-------------- next part --------------
.ig

	brian's sleazy book macros

..
.ds d .
.nr PS 10	\" text point size
.nr VS 12	\" text vertical (inter-line) spacing
.ps \n(PS
.vs \n(VS
.nr P1 .4i	\" program indent in .P1
.nr dP 1	\" delta point size for program
.nr dV 2p	\" delta vertical for programs
.nr dT 5	\" delta tab stop for programs
.	\" the following are book values
....pl 9.2i	\" page length; this gives 7.2i of text
....nr LL 4.8i	\" line length.  this gives 6x9 book size
....nr LT 4.8i	\" ditto
....FL 4.8i	\" line length in footnotes
....po 1.5i	\" page offset
....nr PD 0	\" paragraph space is zero
....nr PI .2i	\" paragraph indent
.hy 14		\" hyphenation: 2=not last lines; 4= no -xx; 8=no xx-
.hw semi-colon
.hw hexa-decimal
.hw estab-lished
.hw multi-line
.ig
	the next several are all called the same way
	.UC arg
		prints arg in smaller size
	.UC arg right
		prints arg in smaller size, right in regular
	.UC arg right left  [sic]
		prints left regular, arg smaller, right regular
		as in .UC UNIX ) (
..
.de UC		\" print argument in small size but keep surround in regular
\&\\$3\s-1\\$1\\s0\&\\$2
..
.de CW		\" puts first arg in CW font
\%\&\\$3\f(CW\\$1\f1\&\\$2
..
.de IT		\" ditto to italicize argument
\&\\$3\f2\\$1\f1\^\&\\$2
..
.de BI		\" bold italic
\&\\$3\f(BI\\$1\f1\^\&\\$2
..
.de UI		\" CW then italic
\&\f(CW\\$1\f2\\$2\f1\\$3
..
.ig
	programs are displayed between .P1/.P2 pairs
	default is to indent by 1/2 inch, nofill, dP smaller
	.P1 x causes an indent of x instead.

	.P3 can be used to specify optional page-break points
	inside .P1/.P2
..
.nr DV .5v	\" space before start of program
.nr dT 5
.de P1
.nr P1 .4i	\" program indent in .P1
.if \\n(.$ .nr P1 \\$1
.br
.nr v \\n(.v
.di p1
.in \\n(P1u
.nf
.ps -\\n(dP
.vs -\\n(dVu
.ft CW
.nr t \\n(dT*\\w'x'u
.ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu
..
.de P2
.br
.ps \\n(PS
.vs \\n(VSp
.vs \\nvu
.ft 1
.in
.di
.br
.sp \\n(DVu
.br
.if \\n(.$=0 .ne \\n(dnu  \" -\\n(DVu
.p1
.sp \\n(DVu
.br
.fi
..
.de P3	\" provides optional break in P1/P2
.nr x \\n(DV
.nr DV 0
.P2
.P1 \\n(P1u
.nr DV \\nx
..
.de Q1	\" simple version for use within exercises, etc.
.nr P1 .4i
.if \\n(.$ .nr P1 \\$1
.br
.di p1
.sp \\n(DVu
.in \\n(P1u
.nf
.ps -\\n(dP
.vs -\\n(dVu
.ft CW
.nr t \\n(dT*\\w'x'u
.ta 1u*\\ntu 2u*\\ntu 3u*\\ntu 4u*\\ntu 5u*\\ntu 6u*\\ntu 7u*\\ntu 8u*\\ntu 9u*\\ntu 10u*\\ntu 11u*\\ntu 12u*\\ntu 13u*\\ntu 14u*\\ntu
..
.de Q2
.sp \\n(DVu
.ps +\\n(dP
.vs +\\n(dVu
.ft 1
.in
.di
.if \\n(.$=0 .ne \\n(dnu-\\n(DVu
.br
.p1
.br
.fi
..
.ig
	the .get macro permits inclusion of programs or parts thereof
	usually within .P1/.P2.  Call is
	.get name
		to get contents of file name
	.get name line
		to get line of file;  line is a number or /regexp/
	.get name line1 line2
		get from line1 to line2 inclusive
	.get name line1 line2 exitline
		ditto, but stop when first exitline is seen
	"name" is relative to directory given in \*d
		default name of code directory is Code
	NOTE THAT THE MACRO IS CALLED AS .get.  The "t" is \\$1.
..
.
.de ge	\" get file
.sy /usr/bwk/bin/trget \\n(.$ \\*d/\\$2 '\\$3' '\\$4' '\\$5' >junk.\\n($$
.so junk.\\n($$
..
.de ru	\" .run command, insert input.  note arg 1 is "n"
.sy \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9 >junk.\\n($$
.so junk.\\n($$
..
.\"
.am EM	\" wrap up at end of input
.sy rm -f junk.\\n($$ /tmp/foo\n($$	\" remove temporaries
..
.de ix	\" the index macro.  period.
.ie '\\n(.z'' .tm ix: \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9	\\n(pn
.el \\!.ix \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
..

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Eric Wayte]

When I was a budding Computer Science major at UCF in 1983, I requested a
copy of this paper through Interlibrary Loan.  A few weeks later, a copy of
the paper arrived from Bell Labs, with a nice AT&T / Bell Laboratories
cover!

I still have my copy!

On Wed, Aug 30, 2017 at 8:34 AM, <arnold at skeeve.com> wrote:

>         Seek and ye shall find.
>
>         Ask and ye shall receive.
>
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
>
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.
>
> In the meantime, Warren, please add to the archives when you are able.
>
> Enjoy!
>
> Arnold
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/cd134aad/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On 30 Aug 2017 06:34 -0600, from arnold at skeeve.com:
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
> 
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.

For those who are impatient and don't want to wade through the markup,
I see that there is a copy at
<https://www.lysator.liu.se/c/bwk-on-pascal.html>. I haven't verified
that it's the same one, but at least the date matches.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Eric Wayte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Interesting, my paper copy is dated July 18, 1981 on both the title page
and after the abstract.

On Wed, Aug 30, 2017 at 10:30 AM, Michael Kjörling <michael at kjorling.se>
wrote:

> On 30 Aug 2017 06:34 -0600, from arnold at skeeve.com:
> > Brian Kernighan was kind enough to find for me everyone's favorite
> > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > My Favorite Programming Language".
> >
> > Attached is the file and his macros.  This will not immediately
> > format using groff etc.; I hope to create a version that will, sometime
> > in the next few weeks.
>
> For those who are impatient and don't want to wade through the markup,
> I see that there is a copy at
> <https://www.lysator.liu.se/c/bwk-on-pascal.html>. I haven't verified
> that it's the same one, but at least the date matches.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/4aa0bfde/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Mutiny]

check out: https://www.lysator.liu.se/c/bwk-on-pascal.htmlhttp://doc.cat-v.org/bell_labs/why_pascal/https://github.com/bitemyapp/Articles-1/blob/master/General/Why%20Pascal%20is%20Not%20My%20Favorite%20Programming%20Language%20(Kernighan).pdfFrom: arnold at skeeve.comSent: Wed, 30 Aug 2017 18:08:26To: tuhs at tuhs.orgSubject: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!   Seek and ye shall find.   Ask and ye shall receive.Brian Kernighan was kind enough to find for me everyone's favoriteComputing Sceince Technical Report, CSTR 100, "Why Pascal is NotMy Favorite Programming Language".Attached is the file and his macros.  This will not immediatelyformat using groff etc.; I hope to create a version that will, sometimein the next few weeks.In the meantime, Warren, please add to the archives when you are able.Enjoy!Arnold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170830/9bbc7ad1/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Michael Parson]

On 2017-08-30 07:34, arnold at skeeve.com wrote:
> Seek and ye shall find.
> 
> 	Ask and ye shall receive.
> 
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".
> 
> Attached is the file and his macros.  This will not immediately
> format using groff etc.; I hope to create a version that will, sometime
> in the next few weeks.

I was able to get it to format with groff/refer on my OS X 10.11.6 
system (groff 1.19.2) with a single edit to cstr100, changing the path 
to cprog.mac in line 5 to './cprog.mac'.  It produced a few warnings, 
but produced what seems to be reasonable output:

$ refer < cstr100 | groff -Tps -ms | ps2pdf - cstr100.pdf
refer:<standard input>:70: no matches for `kernighan plauger software 
tools addison'
refer:<standard input>:112: no matches for `jensen wirth pascal report 
1978'
refer:<standard input>:141: no matches for `habermann pascal critical'
refer:<standard input>:1531: found `$LIST$' but not accumulating 
references
<standard input>:10: warning: can't find font `B'
<standard input>:12: warning: can't find font `I'
<standard input>:14: warning: can't find font `R'

The errors in the refer output seem to be legit problems in the source 
file.  I've not been able to figure out what's going on with the font 
errors, those lines seem OK to me, but my (g|t)roff is rusty.

A little bit of searching on Google let me fill in the missing bits for 
refer, but I still haven't fixed the font warnings.

-- diff output --
--- cstr100.orig        2017-08-30 17:32:29.000000000 -0500
+++ cstr100     2017-08-30 17:30:47.000000000 -0500
@@ -2,7 +2,7 @@
  .fp 2 PI
  .fp 3 PB
  .ds pf CW
-.so /usr/bwk/src/cprog.mac
+.so ./cprog.mac
  .if n .ls 2
  ....ND "April 2, 1981"
  ....TM 81-11272-12 11173 39199-11
@@ -66,7 +66,11 @@
  .ul
  Software Tools
  .[
-kernighan plauger software tools addison
+%T Software Tools
+%A B. W. Kernighan
+%A P. J. Plauger
+%I Addison-Wesley
+%D 1976
  .]
  in Pascal.
  .PP
@@ -107,7 +111,9 @@
  The language is close to the nominal standard
  of Jensen and Wirth,
  .[
-jensen wirth pascal report 1978
+%A Jensen Wirth
+%T Pascal User Manual and Report
+%D 1978
  %O (2nd edition.)
  .]
  with good diagnostics and careful run-time checking.
@@ -137,7 +143,11 @@
  The most often cited papers (well worth reading) are
  a strong critique by Habermann
  .[
-habermann pascal critical
+%A A. Nico Habermann
+%T Critical Comments on the Programming Language Pascal
+%D 1973
+%J Acta Informatica
+%V 3
  .]
  and an equally strong rejoinder by
  Lecarme and Desjardins.

-- end diff --

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Nemo]

On 30 August 2017 at 18:33, Michael Parson <mparson at bl.org> wrote:
> On 2017-08-30 07:34, arnold at skeeve.com wrote:
[...]
>> Attached is the file and his macros.  This will not immediately
>> format using groff etc.; I hope to create a version that will, sometime
>> in the next few weeks.
>
>
> I was able to get it to format with groff/refer on my OS X 10.11.6 system
> (groff 1.19.2) with a single edit to cstr100, changing the path to cprog.mac
> in line 5 to './cprog.mac'.

I tried the following on  my Solaris 10 box:

refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost >cstr100.ps

It composes fine until the first underline (.ul) but puts the
bibliography at the end with the error message "No files Ind"..
Without refer, it composes the entire document fine but without the
references.  No font errors.

N.

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> Brian Kernighan was kind enough to find for me everyone's favorite
> Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> My Favorite Programming Language".

If I may comment on the paper itself....

I used Pascal heavily for about 5-6 years and was also
involved in implementing a variant of Pascal for a couple of
years.  And I have used C since 1981.  I have to say I was
quite happy using Pascal. Some of bwk's criticism (e.g.  re:
sets) applies to pascal compilers, not the language. There is
also some misunderstanding (e.g.
    type apple = integer; orange = integer;
This is renaming, not a new type).  The array problem got
fixed somewhat in the 1985 standard, while arrays are not
even first class objects in C.  Most implementations added
separate compilation as well (1985 standard considers this an
implementation issue but does allow you to declare external
references).

Things I missed in C that were in Pascal:
- enumerated types (type color = (red, blue, green))
- subranges
- nested functions (even if limited)
- first class arrays (even if limited)
- sets
- lexical non-local goto
- bounds checking
- arrays that didn't start at 0.
- function argument checking (K&R C)
- tagged variant records

All in all, both languages are quite comparable.  Each
language had their strong points and weak ones. Basically Pascal
was easier to use /right/ and C more flexible. Pascal code is
easier to read than C code (even today). It was harder to
"cheat" in Pascal but the same is a useful feature of C for
low level work.  To be frank the *main* thing that attracted
me to C was its conciseness :-) If Unix was written in Pascal
I would've happily continued using Pascal!

--bakul

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[arnold]

Nemo <cym224 at gmail.com> wrote:

> I tried the following on  my Solaris 10 box:
>
> refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost >cstr100.ps
>
> It composes fine until the first underline (.ul) but puts the
> bibliography at the end with the error message "No files Ind"..
> Without refer, it composes the entire document fine but without the
> references.  No font errors.

You should probably use refer -e to get the references at the end.

The original PS is in the http://www.skeeve.com/cstr.tar.gz tar ball,
for comparison purposes. :-)

I will eventually set up a github repo with this doc and I hope
instructions for formatting with groff.

Thanks,

Arnold

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

I did a lot of programming in Turbo Pascal (because it was so fast
to compile) and I liked the language OK.

I was taught data structures in Pascal and later taught using Pascal
and it was a fine teaching language.  I agree with the comment that
it is easier to use right, more guard rails.

But as you grow up, you want to take off the guard rails once in a 
while and Pascal didn't let you do that.  C does that routinely,
which one could argue isn't that great, but it sure is handy.

On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > Brian Kernighan was kind enough to find for me everyone's favorite
> > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > My Favorite Programming Language".
> 
> If I may comment on the paper itself....
> 
> I used Pascal heavily for about 5-6 years and was also
> involved in implementing a variant of Pascal for a couple of
> years.  And I have used C since 1981.  I have to say I was
> quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> sets) applies to pascal compilers, not the language. There is
> also some misunderstanding (e.g.
>     type apple = integer; orange = integer;
> This is renaming, not a new type).  The array problem got
> fixed somewhat in the 1985 standard, while arrays are not
> even first class objects in C.  Most implementations added
> separate compilation as well (1985 standard considers this an
> implementation issue but does allow you to declare external
> references).
> 
> Things I missed in C that were in Pascal:
> - enumerated types (type color = (red, blue, green))
> - subranges
> - nested functions (even if limited)
> - first class arrays (even if limited)
> - sets
> - lexical non-local goto
> - bounds checking
> - arrays that didn't start at 0.
> - function argument checking (K&R C)
> - tagged variant records
> 
> All in all, both languages are quite comparable.  Each
> language had their strong points and weak ones. Basically Pascal
> was easier to use /right/ and C more flexible. Pascal code is
> easier to read than C code (even today). It was harder to
> "cheat" in Pascal but the same is a useful feature of C for
> low level work.  To be frank the *main* thing that attracted
> me to C was its conciseness :-) If Unix was written in Pascal
> I would've happily continued using Pascal!
> 
> --bakul

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Eric Wayte]

In the mid 80's when I took Programming II as part of my CS degree, I used
every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
(mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
my Atari 800XL.

Fun times!

On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:

> I did a lot of programming in Turbo Pascal (because it was so fast
> to compile) and I liked the language OK.
>
> I was taught data structures in Pascal and later taught using Pascal
> and it was a fine teaching language.  I agree with the comment that
> it is easier to use right, more guard rails.
>
> But as you grow up, you want to take off the guard rails once in a
> while and Pascal didn't let you do that.  C does that routinely,
> which one could argue isn't that great, but it sure is handy.
>
> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > > Brian Kernighan was kind enough to find for me everyone's favorite
> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > > My Favorite Programming Language".
> >
> > If I may comment on the paper itself....
> >
> > I used Pascal heavily for about 5-6 years and was also
> > involved in implementing a variant of Pascal for a couple of
> > years.  And I have used C since 1981.  I have to say I was
> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> > sets) applies to pascal compilers, not the language. There is
> > also some misunderstanding (e.g.
> >     type apple = integer; orange = integer;
> > This is renaming, not a new type).  The array problem got
> > fixed somewhat in the 1985 standard, while arrays are not
> > even first class objects in C.  Most implementations added
> > separate compilation as well (1985 standard considers this an
> > implementation issue but does allow you to declare external
> > references).
> >
> > Things I missed in C that were in Pascal:
> > - enumerated types (type color = (red, blue, green))
> > - subranges
> > - nested functions (even if limited)
> > - first class arrays (even if limited)
> > - sets
> > - lexical non-local goto
> > - bounds checking
> > - arrays that didn't start at 0.
> > - function argument checking (K&R C)
> > - tagged variant records
> >
> > All in all, both languages are quite comparable.  Each
> > language had their strong points and weak ones. Basically Pascal
> > was easier to use /right/ and C more flexible. Pascal code is
> > easier to read than C code (even today). It was harder to
> > "cheat" in Pascal but the same is a useful feature of C for
> > low level work.  To be frank the *main* thing that attracted
> > me to C was its conciseness :-) If Unix was written in Pascal
> > I would've happily continued using Pascal!
> >
> > --bakul
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>



-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/9d2a65bf/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Warner Losh]

I did a lot of Pascal programming back in the day on my DEC Rainbow with
Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
language in my CS compiler's class, which was fun. But by then I'd
transitioned to C (once Turbo C was available for the IBM-PC, I hacked
together a TSR so I could run it on the not-too-compatible Rainbow). I
liked the low level access, but honestly, when I was a kid programming, I
liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
END more than anything else...  Also, the generally mono-case of C (at the
time, this was before I discovered X11's bletcherous CamelCaseStyle) was
easier on the eyes....  But these days I'm more mellow about this stuff
since I know that the time to type in the code is tiny compared to the time
spent chasing down a bug because ++*++foo--; didn't work like you'd
expected making all the cleverness that went into it wasted...

Warner

On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:

> In the mid 80's when I took Programming II as part of my CS degree, I used
> every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
> (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
> my Atari 800XL.
>
> Fun times!
>
> On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> I did a lot of programming in Turbo Pascal (because it was so fast
>> to compile) and I liked the language OK.
>>
>> I was taught data structures in Pascal and later taught using Pascal
>> and it was a fine teaching language.  I agree with the comment that
>> it is easier to use right, more guard rails.
>>
>> But as you grow up, you want to take off the guard rails once in a
>> while and Pascal didn't let you do that.  C does that routinely,
>> which one could argue isn't that great, but it sure is handy.
>>
>> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
>> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
>> > > Brian Kernighan was kind enough to find for me everyone's favorite
>> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
>> > > My Favorite Programming Language".
>> >
>> > If I may comment on the paper itself....
>> >
>> > I used Pascal heavily for about 5-6 years and was also
>> > involved in implementing a variant of Pascal for a couple of
>> > years.  And I have used C since 1981.  I have to say I was
>> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
>> > sets) applies to pascal compilers, not the language. There is
>> > also some misunderstanding (e.g.
>> >     type apple = integer; orange = integer;
>> > This is renaming, not a new type).  The array problem got
>> > fixed somewhat in the 1985 standard, while arrays are not
>> > even first class objects in C.  Most implementations added
>> > separate compilation as well (1985 standard considers this an
>> > implementation issue but does allow you to declare external
>> > references).
>> >
>> > Things I missed in C that were in Pascal:
>> > - enumerated types (type color = (red, blue, green))
>> > - subranges
>> > - nested functions (even if limited)
>> > - first class arrays (even if limited)
>> > - sets
>> > - lexical non-local goto
>> > - bounds checking
>> > - arrays that didn't start at 0.
>> > - function argument checking (K&R C)
>> > - tagged variant records
>> >
>> > All in all, both languages are quite comparable.  Each
>> > language had their strong points and weak ones. Basically Pascal
>> > was easier to use /right/ and C more flexible. Pascal code is
>> > easier to read than C code (even today). It was harder to
>> > "cheat" in Pascal but the same is a useful feature of C for
>> > low level work.  To be frank the *main* thing that attracted
>> > me to C was its conciseness :-) If Unix was written in Pascal
>> > I would've happily continued using Pascal!
>> >
>> > --bakul
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
>
>
> --
> Eric Wayte
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/c079f85b/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

+1 on everything he said.  Especially the bug chasing.  As a leader,
a lot of what I've done has been to push back on "clever".

On Thu, Aug 31, 2017 at 10:12:43AM -0600, Warner Losh wrote:
> I did a lot of Pascal programming back in the day on my DEC Rainbow with
> Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
> language in my CS compiler's class, which was fun. But by then I'd
> transitioned to C (once Turbo C was available for the IBM-PC, I hacked
> together a TSR so I could run it on the not-too-compatible Rainbow). I
> liked the low level access, but honestly, when I was a kid programming, I
> liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
> END more than anything else...  Also, the generally mono-case of C (at the
> time, this was before I discovered X11's bletcherous CamelCaseStyle) was
> easier on the eyes....  But these days I'm more mellow about this stuff
> since I know that the time to type in the code is tiny compared to the time
> spent chasing down a bug because ++*++foo--; didn't work like you'd
> expected making all the cleverness that went into it wasted...
> 
> Warner
> 
> On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:
> 
> > In the mid 80's when I took Programming II as part of my CS degree, I used
> > every Pascal compiler I could get my hands on:  Waterloo Pascal on VM/CMS
> > (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on
> > my Atari 800XL.
> >
> > Fun times!
> >
> > On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> >> I did a lot of programming in Turbo Pascal (because it was so fast
> >> to compile) and I liked the language OK.
> >>
> >> I was taught data structures in Pascal and later taught using Pascal
> >> and it was a fine teaching language.  I agree with the comment that
> >> it is easier to use right, more guard rails.
> >>
> >> But as you grow up, you want to take off the guard rails once in a
> >> while and Pascal didn't let you do that.  C does that routinely,
> >> which one could argue isn't that great, but it sure is handy.
> >>
> >> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> >> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> >> > > Brian Kernighan was kind enough to find for me everyone's favorite
> >> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> >> > > My Favorite Programming Language".
> >> >
> >> > If I may comment on the paper itself....
> >> >
> >> > I used Pascal heavily for about 5-6 years and was also
> >> > involved in implementing a variant of Pascal for a couple of
> >> > years.  And I have used C since 1981.  I have to say I was
> >> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> >> > sets) applies to pascal compilers, not the language. There is
> >> > also some misunderstanding (e.g.
> >> >     type apple = integer; orange = integer;
> >> > This is renaming, not a new type).  The array problem got
> >> > fixed somewhat in the 1985 standard, while arrays are not
> >> > even first class objects in C.  Most implementations added
> >> > separate compilation as well (1985 standard considers this an
> >> > implementation issue but does allow you to declare external
> >> > references).
> >> >
> >> > Things I missed in C that were in Pascal:
> >> > - enumerated types (type color = (red, blue, green))
> >> > - subranges
> >> > - nested functions (even if limited)
> >> > - first class arrays (even if limited)
> >> > - sets
> >> > - lexical non-local goto
> >> > - bounds checking
> >> > - arrays that didn't start at 0.
> >> > - function argument checking (K&R C)
> >> > - tagged variant records
> >> >
> >> > All in all, both languages are quite comparable.  Each
> >> > language had their strong points and weak ones. Basically Pascal
> >> > was easier to use /right/ and C more flexible. Pascal code is
> >> > easier to read than C code (even today). It was harder to
> >> > "cheat" in Pascal but the same is a useful feature of C for
> >> > low level work.  To be frank the *main* thing that attracted
> >> > me to C was its conciseness :-) If Unix was written in Pascal
> >> > I would've happily continued using Pascal!
> >> >
> >> > --bakul
> >>
> >> --
> >> ---
> >> Larry McVoy                  lm at mcvoy.com
> >> http://www.mcvoy.com/lm
> >>
> >
> >
> >
> > --
> > Eric Wayte
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Nemo]

On 31/08/2017, arnold at skeeve.com <arnold at skeeve.com> wrote:
> Nemo <cym224 at gmail.com> wrote:
>
>> I tried the following on  my Solaris 10 box:
>>
>> refer  cstr100 | troff -ms -Tpost | /usr/lib/lp/postscript/dpost
>> >cstr100.ps
>>
>> It composes fine until the first underline (.ul) but puts the
>> bibliography at the end with the error message "No files Ind"..
>> Without refer, it composes the entire document fine but without the
>> references.  No font errors.
>
> You should probably use refer -e to get the references at the end.

I tried that but still no references.  Strings showed me the path
/usr/lib/refer/papers/Ind in refe but no Ind exists in
/usr/lib/refer/papers.  Any comments on this from anyone?

(By the way, why all the ^M is the files?)

N.


>
> Arnold
>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7535 bytes --]

Without reliving the Pascal/C war of the day, I have to admit that I too
loved Brian’s piece when we wrote it and love it still.   But you have to
understand the context.




>>  If Unix was written in Pascal I would've happily continued using Pascal!

>Amusing in the context of Brian's piece, which essentially says if Unix
>could have been written in Pascal, then Pascal wouldn't have been Pascal.

Doug amen.


There really are a few pieces of information that I think are lost from
history.    Pascal was and is still as difficult to match as a teaching
language.   Brian says exactly that in is piece – it is like a ‘Piper
Cub.’   I *still* use it for just that when I teach scouts, nieces, nephews
or anyone else that asks me, where to start.  Today’s "Free Pascal" system
is pretty hard to beat - runs on anything and "just works."



When BWK wrote that paper, other than MIT stubbornly hanging on to LISP,
all the major CS departments used Pascal as the language that they taught
freshman CS courses.   Cooper and Clancy’s “Oh Pascal” was pretty much *de
rigor* as the text (I still have a couple of editions from when I taught
with it).  I fear that many (?most?) of the traditional language types
hated C as ‘dirty’ if not ‘almost industrial.’   No one but an “OS-weenie”
would use it.



But the problem was that in those days, because Wirth had designed it for
complete small student programs, it was hard to write large real programs
(as Brian points).  So people fixed it and every fixed it differently.
Pascal was hardly standardized.   So it ended up being a terrible
production language.   In 1979, one weekend a couple of us at one of the
famous Tektronix/HP - McCoy/Hatfield parties that Steve Glaser hosted in
Oregon, a couple of us (TW Cook from HP, Steinhart from Tek, myself, *etc*.)
got into a contest to see if there were more incompatible flavors of Tek
Pascal than there were of HP Basic (I remember, we counted over 10 Tek
Pascals and 14 HP Basics when stopped).



And this was the root of the real problem.


You could not write “real” programs in it and really make them run on
actual systems.   Brian was writing that paper, after an exercise in
exactly that task – rewriting the Software Tools into Pascal.   That paper
was his lessons learned.



BTW:  I’ve always thought part of the reason C++ and Java got the jump they
did, was because the language type could say “C didn’t win.”   But I do
find it interesting that they now use Python as a teaching language, which
I think is almost ‘dirtier’ than C ever was.

On Thu, Aug 31, 2017 at 1:51 PM, Larry McVoy <lm at mcvoy.com> wrote:

> +1 on everything he said.  Especially the bug chasing.  As a leader,
> a lot of what I've done has been to push back on "clever".
>
> On Thu, Aug 31, 2017 at 10:12:43AM -0600, Warner Losh wrote:
> > I did a lot of Pascal programming back in the day on my DEC Rainbow with
> > Turbo Pascal. Also wrote a compiler for an 'extended subset' of the
> > language in my CS compiler's class, which was fun. But by then I'd
> > transitioned to C (once Turbo C was available for the IBM-PC, I hacked
> > together a TSR so I could run it on the not-too-compatible Rainbow). I
> > liked the low level access, but honestly, when I was a kid programming, I
> > liked that { was 4 characters shorter than BEGIN and } was 2 shorter than
> > END more than anything else...  Also, the generally mono-case of C (at
> the
> > time, this was before I discovered X11's bletcherous CamelCaseStyle) was
> > easier on the eyes....  But these days I'm more mellow about this stuff
> > since I know that the time to type in the code is tiny compared to the
> time
> > spent chasing down a bug because ++*++foo--; didn't work like you'd
> > expected making all the cleverness that went into it wasted...
> >
> > Warner
> >
> > On Thu, Aug 31, 2017 at 9:26 AM, Eric Wayte <ewayte at gmail.com> wrote:
> >
> > > In the mid 80's when I took Programming II as part of my CS degree, I
> used
> > > every Pascal compiler I could get my hands on:  Waterloo Pascal on
> VM/CMS
> > > (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan
> Pascal on
> > > my Atari 800XL.
> > >
> > > Fun times!
> > >
> > > On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm at mcvoy.com> wrote:
> > >
> > >> I did a lot of programming in Turbo Pascal (because it was so fast
> > >> to compile) and I liked the language OK.
> > >>
> > >> I was taught data structures in Pascal and later taught using Pascal
> > >> and it was a fine teaching language.  I agree with the comment that
> > >> it is easier to use right, more guard rails.
> > >>
> > >> But as you grow up, you want to take off the guard rails once in a
> > >> while and Pascal didn't let you do that.  C does that routinely,
> > >> which one could argue isn't that great, but it sure is handy.
> > >>
> > >> On Wed, Aug 30, 2017 at 06:13:39PM -0700, Bakul Shah wrote:
> > >> > On Wed, 30 Aug 2017 06:34:54 MDT arnold at skeeve.com wrote:
> > >> > > Brian Kernighan was kind enough to find for me everyone's favorite
> > >> > > Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not
> > >> > > My Favorite Programming Language".
> > >> >
> > >> > If I may comment on the paper itself....
> > >> >
> > >> > I used Pascal heavily for about 5-6 years and was also
> > >> > involved in implementing a variant of Pascal for a couple of
> > >> > years.  And I have used C since 1981.  I have to say I was
> > >> > quite happy using Pascal. Some of bwk's criticism (e.g.  re:
> > >> > sets) applies to pascal compilers, not the language. There is
> > >> > also some misunderstanding (e.g.
> > >> >     type apple = integer; orange = integer;
> > >> > This is renaming, not a new type).  The array problem got
> > >> > fixed somewhat in the 1985 standard, while arrays are not
> > >> > even first class objects in C.  Most implementations added
> > >> > separate compilation as well (1985 standard considers this an
> > >> > implementation issue but does allow you to declare external
> > >> > references).
> > >> >
> > >> > Things I missed in C that were in Pascal:
> > >> > - enumerated types (type color = (red, blue, green))
> > >> > - subranges
> > >> > - nested functions (even if limited)
> > >> > - first class arrays (even if limited)
> > >> > - sets
> > >> > - lexical non-local goto
> > >> > - bounds checking
> > >> > - arrays that didn't start at 0.
> > >> > - function argument checking (K&R C)
> > >> > - tagged variant records
> > >> >
> > >> > All in all, both languages are quite comparable.  Each
> > >> > language had their strong points and weak ones. Basically Pascal
> > >> > was easier to use /right/ and C more flexible. Pascal code is
> > >> > easier to read than C code (even today). It was harder to
> > >> > "cheat" in Pascal but the same is a useful feature of C for
> > >> > low level work.  To be frank the *main* thing that attracted
> > >> > me to C was its conciseness :-) If Unix was written in Pascal
> > >> > I would've happily continued using Pascal!
> > >> >
> > >> > --bakul
> > >>
> > >> --
> > >> ---
> > >> Larry McVoy                  lm at mcvoy.com
> > >> http://www.mcvoy.com/lm
> > >>
> > >
> > >
> > >
> > > --
> > > Eric Wayte
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/ebc3da67/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

Clem Cole <clemc at ccc.com> wrote:
 |Without reliving the Pascal/C war of the day, I have to admit that \
 |I too loved Brian’s piece when we wrote it and love it still.   But \
 |you have to 
 |understand the context.   
 |
 |>>  If Unix was written in Pascal I would've happily continued using Pascal!
 |
 |>Amusing in the context of Brian's piece, which essentially says if Unix
 |>could have been written in Pascal, then Pascal wouldn't have been Pascal.
 |
 |Doug amen.
 |
 |There really are a few pieces of information that I think are lost \
 |from history.    Pascal was and is still as difficult to match as a \
 |teaching 
 |language.   Brian says exactly that in is piece – it is like a ‘Piper \
 |Cub.’   I still use it for just that when I teach scouts, nieces, nephews \
 |or 
 |anyone else that asks me, where to start.  Today’s "Free Pascal" system \
 |is pretty hard to beat - runs on anything and "just works."

So, please, let me disagree absolutely.  I had only experience of
some Microsoft Basic in the 80s before i had to (should) learn
some Pascal (i dropped that qualification), and i still hear
myself asking the teacher "What?  A language without goto?"  Even
with closures or inner functions and/or whatever may exist i think
it is a grace that the simplicity of goto: can also be used in
a higher level language.

Despite anything else, my brain also works that way.  It also did
not like sitting still in school at 10 o'clock in the morning or
in the afternoon, of course, but if it is like that?  That became
better over time, but it was not like that in school.  Now the
following is perl(1) which warns since some version on goto: into
a loop, but i would not want to teach young human beings such in
school, it is weird enough that people lseek(2) an O_APPEND
descriptor to SEEK_END because they became socialized with stdio,
in my humble opinion.

      my $ogoditisanewperl = 0;
      if(defined($nl = $self->begin_line)){
         $self->begin_line(undef);
         $self->seen_endl(1);
         $ogoditisanewperl = 1 #goto jumpin;
      }
      while($ogoditisanewperl || ($nl = readline $self->infh)){
         if(!$ogoditisanewperl){
            ++${$self->__lineno};
            $self->seen_endl($nl =~ s/(.*?)\s+$/$1/)
         }
         $ogoditisanewperl = 0; #jumpin:

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On 2017-08-31 2:40 PM, Clem Cole wrote:
> Without reliving the Pascal/C war of the day, I have to admit that I too
> loved Brian’s piece when we wrote it and love it still.   But you have
> to understand the context.   
> 
> 
> 
> 
>>>  If Unix was written in Pascal I would've happily continued using Pascal!
> 
>>Amusing in the context of Brian's piece, which essentially says if Unix
>>could have been written in Pascal, then Pascal wouldn't have been Pascal.
> 
> Doug amen.
> 
> 
> There really are a few pieces of information that I think are lost from
> history.    Pascal was and is still as difficult to match as a teaching
> language.   Brian says exactly that in is piece – it is like a ‘Piper
> Cub.’   I /still/ use it for just that when I teach scouts, nieces,
> nephews or anyone else that asks me, where to start.  Today’s "Free
> Pascal" system is pretty hard to beat - runs on anything and "just works."
> 
>  
> 
> When BWK wrote that paper, other than MIT stubbornly hanging on to LISP,
> all the major CS departments used Pascal as the language that they
> taught freshman CS courses.   Cooper and Clancy’s “Oh Pascal” was pretty
> much /de rigor/ as the text (I still have a couple of editions from when
> I taught with it).  I fear that many (?most?) of the traditional
> language types hated C as ‘dirty’ if not ‘almost industrial.’   No one
> but an “OS-weenie” would use it.
> 
>  
> 
> But the problem was that in those days, because Wirth had designed it
> for complete small student programs, it was hard to write large real
> programs (as Brian points).  So people fixed it and every fixed it
> differently.  Pascal was hardly standardized. ...
> 
>  
> 
> And this was the root of the real problem.
> 
> 
> You could not write “real” programs in it and really make them run on
> actual systems.   Brian was writing that paper, after an exercise in


Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
(using his literate programming toolset, but that did not extend the
language much).

I suppose Apple's Pascal and Object Pascal -- used for Lisa and
Macintosh applications and systems software -- comes under the "so
people fixed it" category?

--Toby


> exactly that task – rewriting the Software Tools into Pascal.   That
> paper was his lessons learned.
> 
>  
> 
> BTW:  I’ve always thought part of the reason C++ and Java got the jump
> they did, was because the language type could say “C didn’t win.”   But
> I do find it interesting that they now use Python as a teaching
> language, which I think is almost ‘dirtier’ than C ever was.
> 
> ...

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were apt: drivers aren’t quite the same as a filter, even a Knuthian-style program.

I thought the world would end up using some post-Pascal, strongly typed language.  Maybe Oberon or Modula would fix things.  (I don’t think any of a decade’s worth of Pascal programs I wrote ever had a buffer overflow vulnerability.)

I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.

> On 31Aug 2017, at 3:47 PM, Toby Thain <toby at telegraphics.com.au> wrote:
> 
> 
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> (using his literate programming toolset, but that did not extend the
> language much).
> 
> I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
> 
> --Toby

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/346e9634/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au>
wrote:

>
>
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> ​ ​
> (using his literate programming toolset, but that did not extend the
> language much).
>
​Indeed - problem was it ​was in a PDP-10/20 *flavor* and would compile on
a Vax, without *much* hacking - I know I moved it once.  It was a real
PITA.    Eventually folks would migrate to C implementations.



>
> I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
>
​That was the issue, everyone 'fixed it' and the fixes were all all
different.   Eventually market place pressure of the PC made Turbo Pascal
enough of a standard because so many people were using it, but by that
time, the war had been lost.

All the things Brian points out that made C great, made it the language
commercial folks used for both the PC and UNIX.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/dcfe43ef/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

On Thu, Aug 31, 2017 at 4:37 PM, William Cheswick <ches at cheswick.com> wrote:

> I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were
> apt: drivers aren’t quite the same as a filter, even a Knuthian-style
> program.
>
> I thought the world would end up using some post-Pascal, strongly typed
> language.  Maybe Oberon or Modula would fix things.  (I don’t think any of
> a decade’s worth of Pascal programs I wrote ever had a buffer overflow
> vulnerability.)
>

​ditto, Pascal and Mod-II and Mod-III were pretty slick.   They were a
little wordy compared to C, but I admit the programs we wrote in them "just
worked" and I can not think any security issues in any that we wrote.

>
> I look to the likes of go and rust to get us back on track.  C is a pretty
> good assembly language.
>

​+1

But Ches, that leaves the open question of what to teach?   My daughter
loves it and that's what college taught her, but I cringe when I look at
what she and her peeps do with Python.   To me that's more like shell
scripting.   Maybe its my inner curmudgeon showing.

I have not seen anything like Clancy's "Oh Pascal" book in the key of Go,
much less Brinch Hansen's "Java for Everyone" ​which I still think are two
of the best teaching text out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/dc514abe/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On 2017-08-31 4:37 PM, Clem Cole wrote:
> 
> 
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     ​ ​
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> ​Indeed - problem was it ​was in a PDP-10/20 /flavor/ and would compile
> on a Vax, without /much/ hacking - I know I moved it once.  It was a
> real PITA.    Eventually folks would migrate to C implementations.
> 

Those were mechanical translations from the Pascal. You're right though,
that this could improve things when the C compilers were better than the
Pascal compilers or where only a C compiler was available.

(I ported TeX in this way a couple of times and did a lot of hacking on
a Pascal-to-C translator.)

--T

>  
> 
> 
>     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
>     Macintosh applications and systems software -- comes under the "so
>     people fixed it" category?
> 
> ​That was the issue, everyone 'fixed it' and the fixes were all all
> different.   Eventually market place pressure of the PC made Turbo
> Pascal enough of a standard because so many people were using it, but by
> that time, the war had been lost.
> 
> All the things Brian points out that made C great, made it the language
> commercial folks used for both the PC and UNIX.​

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.

So what chaps my grumpy old hide is why the heck do a whole new language
when you have one that is pretty good?  Suppose we took C and added a
dialect via options:

	--no-ptrs	// use arrays and indices, you get bounds checking
	--strings	// system managed memory for strings, like tcl
	--perlisms	// if (buf =~ /re/) and unless (it_worked())

etc.  Why create an entirely new language, new syntax, new linkage, etc,
instead of fixing C's shortcomings?

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Arthur Krewat]

On 8/31/2017 3:25 PM, Steffen Nurpmeso wrote:
> "What?  A language without goto?"

It always made me wonder what they were hiding - piles of stuff being 
pushed/popped to the stack that a goto would leave hanging?

I eschew gotos myself, especially in C. I don't use them. When I get to 
the point in a program that I think about using one, I go back and 
re-write the logic so it doesn't need one.

I do not, however, look down on people who DO use them. I've used them 
in the past for efficiency, just not lately. You can get away with them 
in C because there's no magic going on, besides what the optimizer does.

--

On 8/31/2017 5:46 PM, Larry McVoy wrote:
> Why create an entirely new language, new syntax, new linkage, etc, 
> instead of fixing C's shortcomings?

I never understood the "crash and burn" logic either.

Maybe you should come up with a new C standard ;)

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

> >Why create an entirely new language, new syntax, new linkage, etc, instead
> >of fixing C's shortcomings?
> 
> I never understood the "crash and burn" logic either.
> 
> Maybe you should come up with a new C standard ;)

I sorta did, though it could use some polish:

http://www.little-lang.org/

example that I use to do my photo layout:

http://mcvoy.com/lm/photos.l

which does stuff like:

http://www.mcvoy.com/lm/hockey-portraits/
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

On Aug 31, 2017, at 1:51 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Thu, Aug 31, 2017 at 4:37 PM, William Cheswick <ches at cheswick.com <mailto:ches at cheswick.com>> wrote:
> I wrote a plotter driver for the CDC in Pascal.  Brian’s comments were apt: drivers aren’t quite the same as a filter, even a Knuthian-style program.
> 
> I thought the world would end up using some post-Pascal, strongly typed language.  Maybe Oberon or Modula would fix things.  (I don’t think any of a decade’s worth of Pascal programs I wrote ever had a buffer overflow vulnerability.)
> 
> ​ditto, Pascal and Mod-II and Mod-III were pretty slick.   They were a little wordy compared to C, but I admit the programs we wrote in them "just worked" and I can not think any security issues in any that we wrote.

"Just working" and no security issues is something that was/is harder in C (and C++). We continue to pay an enormous cost due to the prevalence of C/C++ programs. May be security was not a big concern in 1983 but buggy programs were already a big issue....

> 
> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> ​+1
> 
> But Ches, that leaves the open question of what to teach?   My daughter loves it and that's what college taught her, but I cringe when I look at what she and her peeps do with Python.   To me that's more like shell scripting.   Maybe its my inner curmudgeon showing.

IMHO every programmer should learn (and learn well)
a) assembly language. pick one processor architecture. C is not low level enough. This really teaches you the nuts and bolts of how computers actually work.
b) Scheme. This really teaches you prototyping, conceptualizing, experimenting etc. And there are lots of books that use Scheme to teach you programming. Still my goto language for fun!
c) Some newly popular/upcoming compiled language. Go or Rust or Nim or Julia or Erlang or Haskell...

Rationale: a) is bottom up. b) is top down. c) is getting things done. This way they get a broad spectrum programming skill set.

and may be
d) javascript / C++ / Cobol / Java / C -- whatever the market currently desperately wants

> I have not seen anything like Clancy's "Oh Pascal" book in the key of Go, much less Brinch Hansen's "Java for Everyone" ​which I still think are two of the best teaching text out there.

FWIW: I was able to bootstrap 3 highschool grads just with the Kergighan, Donovan Go programming book. With some mentoring in 7 weeks they wrote a car driving simulator (random road map, traffic signals, random number of cars, stopping at lights, waiting to safely turn right or left, zoomable openGL view). They had some prior experience with C/C++ and one knew openGL as well. They actually produced far more code than the our team of regular employees!

Go ecosystem quite well engineered and a joy to use. What newbies need is a "duolingo" for programming!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/b5c75616/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[David Arnold]

Like C++?  Or D?



d

> On 1 Sep 2017, at 07:46, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> So what chaps my grumpy old hide is why the heck do a whole new language
> when you have one that is pretty good?  Suppose we took C and added a
> dialect via options:
> 
> 	--no-ptrs	// use arrays and indices, you get bounds checking
> 	--strings	// system managed memory for strings, like tcl
> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> 
> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> instead of fixing C's shortcomings?

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

I think of Alan Demer's comment: "There are two kinds of programming
languages, those that make it easy to write good programs, and those
that make it hard to write bad ones."

When teaching, you want the latter.  Doing anything real, you want
the former.

Re Python:  I think we old fogeys have to realize that programming
today has little in common with programming a few decades ago.  Back
then, when we programmed, we typically wrote algorithms.  There were
a few libraries for things like sin and cos, but if you wanted a
matrix multiply, you dashed off a triply-nested loop.

Programming languages now are used primarily to create a scaffold on
which to hang library calls.  The libraries are incredibly attractive
because the world is more complicated now, expectations are higher,
machines vastly faster -- so the languages are rarely used to write
algorithms.  A case in point is Google's TensorFlow -- a Python
front-end to a vast number of mathematical functions, where almost all
the "real work" is done by C++ programs with Python wrappers.  The
fact that Python is largely interactive means that modest sized bells,
whistles, warts and other disgusting things can be slipped into the
language and be unnoticed as long as they don't have much effect on
the human reaction time.  But doing these same things a billion times
really hurts.

On the other hand, most of TensorFlow was prototyped first in Python
and then C++ was called in to get the job done.  I suppose there's a
place for that...  But C++y TensorFlow add-ons like Keras are very
clean -- easy to write good programs at that level, but disappointing
when you see how badly they are delivered by TensorFlow.

Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/6f490e68/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> 
> So what chaps my grumpy old hide is why the heck do a whole new language
> when you have one that is pretty good?  Suppose we took C and added a
> dialect via options:
> 
> 	--no-ptrs	// use arrays and indices, you get bounds checking
> 	--strings	// system managed memory for strings, like tcl
> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())

Such a language would stop being C.

In Go you can use slices instead of arrays (but slices are only one dimensional).
Ptrs are relatively safe as memory is garbage collected so e.g. a function can
return &local_variable. No perlism.

Go provides other features which are quite useful: concurrency, channels,
interfaces, packages.

People who like C tend to like Go. But Go is not low-level enough. No one
is writing a kernel in it! Or doing bare metal programming. AFAIK.

> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> instead of fixing C's shortcomings?

C has too many problems. If you try fixing them, none of the "dusty decks"
would run on such a compiler + the new language would be severely
hampered in its evolution due to its C legacy.

Algol family, class based, prototype based, functional, array, logic,
visual, ... programming language are just what we have tried so far. 
I don't think we are anywhere near the end of programming language
evolution.

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> 
> > On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> >> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> > 
> > So what chaps my grumpy old hide is why the heck do a whole new language
> > when you have one that is pretty good?  Suppose we took C and added a
> > dialect via options:
> > 
> > 	--no-ptrs	// use arrays and indices, you get bounds checking
> > 	--strings	// system managed memory for strings, like tcl
> > 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> 
> Such a language would stop being C.

Indeed.  But it builds on C.

> In Go you can use slices instead of arrays (but slices are only one dimensional).
> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
> return &local_variable. No perlism.
> 
> Go provides other features which are quite useful: concurrency, channels,
> interfaces, packages.
> 
> People who like C tend to like Go. But Go is not low-level enough. No one
> is writing a kernel in it! Or doing bare metal programming. AFAIK.

Exactly.

> > etc.  Why create an entirely new language, new syntax, new linkage, etc,
> > instead of fixing C's shortcomings?
> 
> C has too many problems. If you try fixing them, none of the "dusty decks"
> would run on such a compiler + the new language would be severely
> hampered in its evolution due to its C legacy.

So I'd need to understand more to believe that claim.  And for the record,
what I'm going for is a new C that is still C enough to be useful but
fixes the problems enough to be a new language.  Someone asked about
C++ and D, nope.  Too far from C.  I just want a C that fixes enough
of the problems that it is more acceptable to modern programmers but
is still C.  Not sure if I'm explaining that well enough.

> Algol family, class based, prototype based, functional, array, logic,
> visual, ... programming language are just what we have tried so far. 
> I don't think we are anywhere near the end of programming language
> evolution.

Yep.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Kurt H Maier]

On Thu, Aug 31, 2017 at 06:26:55PM -0700, Larry McVoy wrote:
> 
> So I'd need to understand more to believe that claim.  And for the record,
> what I'm going for is a new C that is still C enough to be useful but
> fixes the problems enough to be a new language.  Someone asked about
> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> of the problems that it is more acceptable to modern programmers but
> is still C.  Not sure if I'm explaining that well enough.

To "fix the problems" without losing functionality you need to pick a
new set of abstractions.  If you pick a new set of abstractions you've
stopped being C.  This is the gulf between C fans and the "modern"
language set.  When you file off the sharp edges, you have fewer
accidents, but you have to solve some problems differently.

khm

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Nemo]

Shades of Myfol vs. Yourtran!

On 31/08/2017, Steffen Nurpmeso <steffen at sdaoden.eu> wrote (in part):
> and i still hear
> myself asking the teacher "What?  A language without goto?"

Pascal has always had goto.  (One of Wirth's pascal compilers even
jumped from within one function to a label inside another function!)

The construct was removed in Modula.  (As Parnas has said, the problem
is not having a comefrom to go with the goto.)

N.

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

> On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
>> 
>>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
>>> 
>>> So what chaps my grumpy old hide is why the heck do a whole new language
>>> when you have one that is pretty good?  Suppose we took C and added a
>>> dialect via options:
>>> 
>>> 	--no-ptrs	// use arrays and indices, you get bounds checking
>>> 	--strings	// system managed memory for strings, like tcl
>>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
>> 
>> Such a language would stop being C.
> 
> Indeed.  But it builds on C.
> 
>> In Go you can use slices instead of arrays (but slices are only one dimensional).
>> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
>> return &local_variable. No perlism.
>> 
>> Go provides other features which are quite useful: concurrency, channels,
>> interfaces, packages.
>> 
>> People who like C tend to like Go. But Go is not low-level enough. No one
>> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> 
> Exactly.
> 
>>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
>>> instead of fixing C's shortcomings?
>> 
>> C has too many problems. If you try fixing them, none of the "dusty decks"
>> would run on such a compiler + the new language would be severely
>> hampered in its evolution due to its C legacy.
> 
> So I'd need to understand more to believe that claim.  And for the record,
> what I'm going for is a new C that is still C enough to be useful but
> fixes the problems enough to be a new language.  Someone asked about
> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> of the problems that it is more acceptable to modern programmers but
> is still C.  Not sure if I'm explaining that well enough.

See below. I think it would be not easy to build a simpler language
that is consistent and regular. I just touched on a couple of things
but there would be many more such small decisions....

1. Ptrs. If you remove them completely, functions can become
   pure and can not change anything. Most likely you'd end up
   adding "ref" parameter, which would be sorta like Pascal's
   var parameters.

       int f(var int x) {
                x++;
                return x
       }

        ...
        int z = 1;
        int y = f(z);   // y should be 2
        int x = f(z);   // x should be 3

   The benefit is that now you can not clobber the ptr but
   otherwise the same result.

   Do you allow declaring refs? You should for consistency.

        int x1;
        ref int x2 = x1;

   But if you allow this, either this assignment behaves
   differently from a ref int parameter or it would crash
   since x2 doesn't really point anywhere on initialization.
   So now you will be tempted to say

        ref int x2 = ref x1;

   This is almost exactly like

        int *x2 = &x1;

   A bit ugly.  IIRC Algol68 had something similar and well
   defined rules for how multi level refs were handled.

2. Passing Arrays. Now you need a way to pass subarrays.

        int z[] = {1,2,3,4};
        int g(int x[]) {
            ...
        }
        ...
        int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].

   Now you need a way to iterate through the array in g.

        int g(int x[]) int {
            int sum = 0;
            for (int i = 0; i < len(x); i++) sum += x[i];
            return sum;
        }

   But what happens if in g you change x[i]? Does z change?
   If you don't allow this, x[] becomes a constant but a
   scalar variable can be changed. So this is inconsistent.

   If you allow this, int x[] almost acts like var int x[]!
   For consistency with scalars you should copy z[3:5] but
   that can be expensive for large arrays. So now you will be
   tempted to use const (now a ref can be impllicitly passed
   since array won't be written over).

   Then there is the issue of multidimensional arrays.

        int z[4][5];
        int h(int x[][]) {
            ...
        }
        int w = g(z[2:4][1:3]);

   If you are fixing arrays, you may as well do them right
   so that fortran code can be easily ported.  So what about

        int h(int x[][]) {
                int s = g(x[1][]);
        }

   Here we're passing a column of z as a vector to g.
   You'd end up with a illife vector or something! But
   if you do this, vector access can slow down...

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Larry McVoy]

No offense intended but I pretty much dealt with all of this in L.
little-lang.org

I'll freely admit it is not perfect but it certainly touches on your
comments and would not be hard to bring into C.

On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
> 
> > On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> >> 
> >>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >>> 
> >>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> >>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> >>> 
> >>> So what chaps my grumpy old hide is why the heck do a whole new language
> >>> when you have one that is pretty good?  Suppose we took C and added a
> >>> dialect via options:
> >>> 
> >>> 	--no-ptrs	// use arrays and indices, you get bounds checking
> >>> 	--strings	// system managed memory for strings, like tcl
> >>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> >> 
> >> Such a language would stop being C.
> > 
> > Indeed.  But it builds on C.
> > 
> >> In Go you can use slices instead of arrays (but slices are only one dimensional).
> >> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
> >> return &local_variable. No perlism.
> >> 
> >> Go provides other features which are quite useful: concurrency, channels,
> >> interfaces, packages.
> >> 
> >> People who like C tend to like Go. But Go is not low-level enough. No one
> >> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> > 
> > Exactly.
> > 
> >>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> >>> instead of fixing C's shortcomings?
> >> 
> >> C has too many problems. If you try fixing them, none of the "dusty decks"
> >> would run on such a compiler + the new language would be severely
> >> hampered in its evolution due to its C legacy.
> > 
> > So I'd need to understand more to believe that claim.  And for the record,
> > what I'm going for is a new C that is still C enough to be useful but
> > fixes the problems enough to be a new language.  Someone asked about
> > C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> > of the problems that it is more acceptable to modern programmers but
> > is still C.  Not sure if I'm explaining that well enough.
> 
> See below. I think it would be not easy to build a simpler language
> that is consistent and regular. I just touched on a couple of things
> but there would be many more such small decisions....
> 
> 1. Ptrs. If you remove them completely, functions can become
>    pure and can not change anything. Most likely you'd end up
>    adding "ref" parameter, which would be sorta like Pascal's
>    var parameters.
> 
>        int f(var int x) {
>                 x++;
>                 return x
>        }
> 
>         ...
>         int z = 1;
>         int y = f(z);   // y should be 2
>         int x = f(z);   // x should be 3
> 
>    The benefit is that now you can not clobber the ptr but
>    otherwise the same result.
> 
>    Do you allow declaring refs? You should for consistency.
> 
>         int x1;
>         ref int x2 = x1;
> 
>    But if you allow this, either this assignment behaves
>    differently from a ref int parameter or it would crash
>    since x2 doesn't really point anywhere on initialization.
>    So now you will be tempted to say
> 
>         ref int x2 = ref x1;
> 
>    This is almost exactly like
> 
>         int *x2 = &x1;
> 
>    A bit ugly.  IIRC Algol68 had something similar and well
>    defined rules for how multi level refs were handled.
> 
> 2. Passing Arrays. Now you need a way to pass subarrays.
> 
>         int z[] = {1,2,3,4};
>         int g(int x[]) {
>             ...
>         }
>         ...
>         int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].
> 
>    Now you need a way to iterate through the array in g.
> 
>         int g(int x[]) int {
>             int sum = 0;
>             for (int i = 0; i < len(x); i++) sum += x[i];
>             return sum;
>         }
> 
>    But what happens if in g you change x[i]? Does z change?
>    If you don't allow this, x[] becomes a constant but a
>    scalar variable can be changed. So this is inconsistent.
> 
>    If you allow this, int x[] almost acts like var int x[]!
>    For consistency with scalars you should copy z[3:5] but
>    that can be expensive for large arrays. So now you will be
>    tempted to use const (now a ref can be impllicitly passed
>    since array won't be written over).
> 
>    Then there is the issue of multidimensional arrays.
> 
>         int z[4][5];
>         int h(int x[][]) {
>             ...
>         }
>         int w = g(z[2:4][1:3]);
> 
>    If you are fixing arrays, you may as well do them right
>    so that fortran code can be easily ported.  So what about
> 
>         int h(int x[][]) {
>                 int s = g(x[1][]);
>         }
> 
>    Here we're passing a column of z as a vector to g.
>    You'd end up with a illife vector or something! But
>    if you do this, vector access can slow down...

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au>
wrote:
[snip]

> > But the problem was that in those days, because Wirth had designed it
> > for complete small student programs, it was hard to write large real
> > programs (as Brian points).  So people fixed it and every fixed it
> > differently.  Pascal was hardly standardized. ...
> >
> > And this was the root of the real problem.
> >
> > You could not write “real” programs in it and really make them run on
> > actual systems.   Brian was writing that paper, after an exercise in
>
>
> Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
> (using his literate programming toolset, but that did not extend the
> language much).
>

To be fair, I think that Knuth originally wrote both TeX and METAFONT in
the SAIL language for the PDP-10. He switched to Pascal (again on the
PDP-10) later.

I've often wondered to what extent (natural) language shapes thought; for
instance, to what extent does grammatical gender influence patriarchy or
matriarchy of the society that speaks that language, etc. If some thought
is relatively harder to express in a given language, will less attention be
given to areas associated with that thought? It is my limited understanding
that linguists and social scientists have studied this and seen a positive
correlation between language and culture/society (I don't know if it's
causal).

But if we go out on a branch and assume that it *is* causal for a moment,
it naturally raises the question: is the same true of other types of
languages? How about programming languages or mathematical notations (or
other similar domain specific languages)?

I have long suspected that it is true of programming. While most of the
languages we use are Turing complete (I suppose that in the limit one can
write a Common Lisp implementation in C, for example), it is unarguable
that some languages make it *easier* to express some things than other
languages. In some cases this is deliberate: consider languages with
strong, static type systems versus dynamic but strongly typed languages (or
statically but weakly typed). Here the language designers have
intentionally made it hard to escape the tyranny of the type system in
order to prevent bugs.

Anyway, I wonder if Knuth would have produced the same TeX and METAFONT had
he started in Pascal; perhaps he would have, but maybe he would have given
up on some of the more ambitious parts of both because the language made it
much less convenient (not knowing SAIL, I'm speculating). Perhaps having
gone through the exercise of producing TeX in SAIL gave him insight that
inspired him to work around Pascal's expressive limitations. Or perhaps the
opposite is true.

Regardless, comparing the work of a Knuth to the industry average is more
than a bit unfair. :-)

I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> Macintosh applications and systems software -- comes under the "so
> people fixed it" category?
>

Object Pascal, Delphi and Free Pascal (which seeks to implement the best of
both) seem to have definitely fallen into that category.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/f3953d8c/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

On Thu, Aug 31, 2017 at 9:22 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>
> [snip]
> People who like C tend to like Go. But Go is not low-level enough. No one
> is writing a kernel in it! Or doing bare metal programming. AFAIK.


There are a few different projects: at least two under current
investigation at MIT; an earlier project out of Spain using a modified
version of the language. I'd be surprised if there were not others.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/f844a654/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

I did a quick read of the language spec but I didn't see a rationale or
nit picky details.... Would have to study it more but I'm not convinced
it is better..... I believe Go has pretty much everything L has (+ I like
its support for concurrency).

Stroustrup's C with classes did seem better but then it became C++.

> On Aug 31, 2017, at 7:27 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> No offense intended but I pretty much dealt with all of this in L.
> little-lang.org
> 
> I'll freely admit it is not perfect but it certainly touches on your
> comments and would not be hard to bring into C.
> 
> On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
>> 
>>> On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
>>>> 
>>>>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>>>> 
>>>>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>>>>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
>>>>> 
>>>>> So what chaps my grumpy old hide is why the heck do a whole new language
>>>>> when you have one that is pretty good?  Suppose we took C and added a
>>>>> dialect via options:
>>>>> 
>>>>> 	--no-ptrs	// use arrays and indices, you get bounds checking
>>>>> 	--strings	// system managed memory for strings, like tcl
>>>>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
>>>> 
>>>> Such a language would stop being C.
>>> 
>>> Indeed.  But it builds on C.
>>> 
>>>> In Go you can use slices instead of arrays (but slices are only one dimensional).
>>>> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
>>>> return &local_variable. No perlism.
>>>> 
>>>> Go provides other features which are quite useful: concurrency, channels,
>>>> interfaces, packages.
>>>> 
>>>> People who like C tend to like Go. But Go is not low-level enough. No one
>>>> is writing a kernel in it! Or doing bare metal programming. AFAIK.
>>> 
>>> Exactly.
>>> 
>>>>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
>>>>> instead of fixing C's shortcomings?
>>>> 
>>>> C has too many problems. If you try fixing them, none of the "dusty decks"
>>>> would run on such a compiler + the new language would be severely
>>>> hampered in its evolution due to its C legacy.
>>> 
>>> So I'd need to understand more to believe that claim.  And for the record,
>>> what I'm going for is a new C that is still C enough to be useful but
>>> fixes the problems enough to be a new language.  Someone asked about
>>> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
>>> of the problems that it is more acceptable to modern programmers but
>>> is still C.  Not sure if I'm explaining that well enough.
>> 
>> See below. I think it would be not easy to build a simpler language
>> that is consistent and regular. I just touched on a couple of things
>> but there would be many more such small decisions....
>> 
>> 1. Ptrs. If you remove them completely, functions can become
>>   pure and can not change anything. Most likely you'd end up
>>   adding "ref" parameter, which would be sorta like Pascal's
>>   var parameters.
>> 
>>       int f(var int x) {
>>                x++;
>>                return x
>>       }
>> 
>>        ...
>>        int z = 1;
>>        int y = f(z);   // y should be 2
>>        int x = f(z);   // x should be 3
>> 
>>   The benefit is that now you can not clobber the ptr but
>>   otherwise the same result.
>> 
>>   Do you allow declaring refs? You should for consistency.
>> 
>>        int x1;
>>        ref int x2 = x1;
>> 
>>   But if you allow this, either this assignment behaves
>>   differently from a ref int parameter or it would crash
>>   since x2 doesn't really point anywhere on initialization.
>>   So now you will be tempted to say
>> 
>>        ref int x2 = ref x1;
>> 
>>   This is almost exactly like
>> 
>>        int *x2 = &x1;
>> 
>>   A bit ugly.  IIRC Algol68 had something similar and well
>>   defined rules for how multi level refs were handled.
>> 
>> 2. Passing Arrays. Now you need a way to pass subarrays.
>> 
>>        int z[] = {1,2,3,4};
>>        int g(int x[]) {
>>            ...
>>        }
>>        ...
>>        int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].
>> 
>>   Now you need a way to iterate through the array in g.
>> 
>>        int g(int x[]) int {
>>            int sum = 0;
>>            for (int i = 0; i < len(x); i++) sum += x[i];
>>            return sum;
>>        }
>> 
>>   But what happens if in g you change x[i]? Does z change?
>>   If you don't allow this, x[] becomes a constant but a
>>   scalar variable can be changed. So this is inconsistent.
>> 
>>   If you allow this, int x[] almost acts like var int x[]!
>>   For consistency with scalars you should copy z[3:5] but
>>   that can be expensive for large arrays. So now you will be
>>   tempted to use const (now a ref can be impllicitly passed
>>   since array won't be written over).
>> 
>>   Then there is the issue of multidimensional arrays.
>> 
>>        int z[4][5];
>>        int h(int x[][]) {
>>            ...
>>        }
>>        int w = g(z[2:4][1:3]);
>> 
>>   If you are fixing arrays, you may as well do them right
>>   so that fortran code can be easily ported.  So what about
>> 
>>        int h(int x[][]) {
>>                int s = g(x[1][]);
>>        }
>> 
>>   Here we're passing a column of z as a vector to g.
>>   You'd end up with a illife vector or something! But
>>   if you do this, vector access can slow down...
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

On Thu, Aug 31, 2017 at 9:26 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> > > On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > > So what chaps my grumpy old hide is why the heck do a whole new
> language
> > > when you have one that is pretty good?  Suppose we took C and added a
> > > dialect via options:
> > >
> > >     --no-ptrs       // use arrays and indices, you get bounds checking
> > >     --strings       // system managed memory for strings, like tcl
> > >     --perlisms      // if (buf =~ /re/) and unless (it_worked())
> >
> > Such a language would stop being C.
>
> Indeed.  But it builds on C.


Not only would such a language be C-based but not C, it would beg the
question: why?

I saw a very interesting presentation a few months back by someone on the
C++ standards committee. He was describing *how* the standards process
works, but at one point described some of the upcoming features. If I
recall, one proposal was to add list comprehensions, more or less because
"Python has them." I couldn't resist asking in the Q&A, "Why?" The idea
being that if I want Python, I know where to get Python (or Haskell, for
that matter). Why does every language need to evolve to be every other
language and in so doing grow into an uncontrolled and uncontrollable mess?
I wasn't trying to be confrontational (I phrased my question somewhat more
politely than what I just wrote here) but the answer was a tad defensive.
As I recall, something along the lines of, "well, that's what the kids
coming out of schools that teach Python expect these days, and we need them
to stay relevant." I don't find that particularly compelling: languages are
kind of like tools, and as such, often serve different purposes. If I want
to solve a problem that is best suited to C, then I'll use C; if I want to
solve some problem that's best suited to a different language (stronger
type system, a richer set of built-in abstractions, first-class concurrency
primitives, etc) then I'll reach for that instead. Why is that
controversial? If I want to drive a screw, I reach for a screwdriver, not a
hammer.

Anyway, I for one am perfectly content for C to remain the high-level
assembler that it mostly is. Call me a heretic, but I don't particularly
want to write large programs in it anymore. That said, I also don't want it
to grow too large, because then it makes it harder to use for low-level
things. For example, I'm a little nonplussed about thread support in C11:
what if I want to work in a world where a pthread-like thread isn't the
concurrency model? Similarly with the semantics around atomics. Is
compliance with the language standard going to force something on me that
makes it hard to experiment with new ways of doing things?

Anyway, I like the idea of multiple languages that occupy different niches.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170831/b95ce3a8/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 

My point was that these are very much "real world" programs in a rather
vanilla Pascal.

(And if you want to bring SAIL into it as another substrate for "real
world" programs, we might learn something from contrasting it with
Pascal and C. I don't remember anything about it.)

--Toby


> 
>         - Dan C.
> 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]

On Thu, Aug 31, 2017 at 10:38 PM, Dan Cross <crossd at gmail.com> wrote:

> ​....​
>
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
>
> ​Dan, True enough but .... having learned Pascal on the 10 (well 20 at
that point) and SAIL on the 10s, the differences between them were minor in
this case.   I suspect the conversion was done in a few days in emacs.
SAIL basically was the Python of its day - with a load of libraries that
people used.  But it was just an extended Algol with a number of
PDP-10isms.  I have a the manual if you are curious (and I even had
??have?? a working compiler for the Masscomp [68000] at some point).

​

> ​...​
>
> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> had he started in Pascal; perhaps he would have, but maybe he would have
> given up on some of the more ambitious parts of both because the language
> made it much less convenient (not knowing SAIL, I'm speculating). Perhaps
> having gone through the exercise of producing TeX in SAIL gave him insight
> that inspired him to work around Pascal's expressive limitations. Or
> perhaps the opposite is true.
>
​An interesting thought, but in this case, I'm not so sure.   I think the
more interesting question is if we had developed it on a 16/32 bit system
instead of a 18/36 bit system.​   If I think back about moving things from
the 10s (or the CDC systems) of that day, the problem was almost always an
issue of 16/32 not being 'enough' when you move the code to the PDP-11 or
Vax later.   It was less the pure language, and more the processor
representation that caused me trouble.

Funny, I remember in those days, we obtain a really nice Pascal compiler
that generated code for the 68000 that had been written on the CDC systems
somewhere in Europe ??CERN maybe??.   But moving it was damned near
impossible because it was assuming the word size of the CDC system.  It was
written in Pascal but because it *how* it was written, it could not even
compile itself.

We switched to Modula-II shortly there after as the C alternative, in Tek
Labs.

>
> Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> of both) seem to have definitely fallen into that category.
>
>         - Dan C.
>
​+1 Indeed - this why I still use it as a teaching tool.  I start them with
a pure Pascal variant with all the bumpers and other shielding in place
that a beginner should have.   If they are more interested in systems
stuff, I'll let them learn C, if they want to start to do more
applications, then I continue with Delphi or simple Java (PBH's subset) so
they learn OO before I throw C++ at them.

Ches' comment about using Rust or Go is possible, but I have not found a
book I trust.  If PBH or Clancy would would redo one of their text, I'ld
feel a lot more comfortable.

Clem   ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/ff2ad4e8/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Steffen Nurpmeso]

Nemo <cym224 at gmail.com> wrote:
 |Shades of Myfol vs. Yourtran!
 |
 |On 31/08/2017, Steffen Nurpmeso <steffen at sdaoden.eu> wrote (in part):
 |> and i still hear
 |> myself asking the teacher "What?  A language without goto?"
 |
 |Pascal has always had goto.  (One of Wirth's pascal compilers even
 |jumped from within one function to a label inside another function!)
 |
 |The construct was removed in Modula.  (As Parnas has said, the problem
 |is not having a comefrom to go with the goto.)

No, no, not the Pascal that we had to use there.  Definitely not.
Anyway, that is my rememberance, and i had to work with this for
a few months, and it (the GUI) surely had that command index page,
too.  I surely have looked for goto.  It was running under DOS.
(It was a German school, no University.  Thus.)  Hm.  Maybe
a castrated educational version?  Could that be?  Has such thing
ever existed?  Possibly even with the possibility for the teacher
to activate an extended command set for the progressed learners??
Interesting.

Sorry for the rest.

  I am coming from the holistic side anyway so that purely
  intdoctrinating education without cultivating heart and soul "i"
  (thus, say, since maybe 15 or 16, or 17) never liked.  I recall
  Smalltalk being proposed for education, but regardless of the
  language i think the most important part is that the children
  becomes curious and tries to discover and develop.

  I personally do not think that automatisms are good at all.  If
  you cook, you have to clean the kitchen.  If you tinker with
  your car or motorcycle you have to clean your tools at least.
  If you want to reap you have to sow.  If you want to use dynamic
  memory you have to release it.  Some things have to be let.
  That is also something important to be learned.  You can say
  bees are dying and that is good, let's just kill the rest and
  anything else that interferes, because the computer managed
  bee-drones that are being developed will not need no neutral
  zones at all, so a field with genetically manipulated seeds and
  massive crop eh protection can be layed out right beside an
  organic farming one.  They exactly follow the desired plan.  So
  to say.  Or you let, and possibly even create living willow
  fences surrounding them and the one or the other accompanying
  tree, too.  Like Prince Charles promotes since at least the
  1970s, if that remark is allowed.  To me the latter sounds more
  healthy, also mentally.  Admittedly all that needs fresh water,
  an emerging of the increasing problems.

  So nice and tiny, controllable and fully understood little
  objects are surely something good, letting them play together is
  like bouncing balls in the circus, but omnipotence dreamings
  should be targeted in the educational process also in the
  western world, me thinks.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

The subject has (yet again) come up in this discussion about buffer 
overflows and security when it comes to C.

I contend that if you do this:

void foo(char *a, char *b) {
     strcpy(a,b);
}

You're foolhardy and should be fired from your programming job.

I've been lazy when I need to write something quickly for my own use. I 
would never EVER blindly copy strings around without limiting their lengths.

It never occurred to me in my early years that this was more "secure" - 
it was just the right thing to do. Coming from a PDP-10 MACRO background 
as a teenager, I couldn't imagine a world where you blindly excepted 
strings or any other data from an outside source and didn't sanity check 
it for length or content.

It amazed me when I'd run into something written by someone else that if 
you put the wrong data into it would SIGSEGV or SIGBUS. Blasphemy!

;)

We don't need no stinkin' safety rails, we're smart enough not to walk 
off that cliff in the first place. And who knows, we may need to walk 
off that cliff at some point in the future.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/e7d91055/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 
> I've often wondered to what extent (natural) language shapes thought ...

> I have long suspected that it is true of programming. 

I don't think any of the above is in doubt.


> While most of the
> languages we use are Turing complete (I suppose that in the limit one
> can write a Common Lisp implementation in C, for example), it is
> unarguable that some languages make it *easier* to express some things
> than other languages. In some cases this is deliberate: consider
> languages with strong, static type systems versus dynamic but strongly
> typed languages (or statically but weakly typed). Here the language
> designers have intentionally made it hard to escape the tyranny of the
> type system in order to prevent bugs.

(Tyranny is not the word I would use. A more modern viewpoint would
include topics like parametric polymorphism, typeclasses and so on.)

> 
> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> had he started in Pascal; perhaps he would have, but maybe he would have
> given up on some of the more ambitious parts of both because the
> language made it much less convenient (not knowing SAIL, I'm


It seems inconceivable to me that there are "ambitious parts" of TeX and
METAFONT that Professor Knuth had to omit because he was using Pascal.
Knuth has shown himself in various ways (including MIX, but also his
literate programs in Pascal and C) to prefer programming at low levels
(by modern standards) but his code amply shows that Pascal barely
presented any impediment to doing so -- though he now uses literate C.

Of course his programs would look different in, say, Haskell or Ocaml.

I have not compared the codebases but wouldn't one expect that the final
production TeX rewrite is *more* ambitious than the early SAIL version?
(By the time I began using/porting TeX in the 1980s, the older version
was completely obsolete.)


> speculating). Perhaps having gone through the exercise of producing TeX
> in SAIL gave him insight that inspired him to work around Pascal's
> expressive limitations. Or perhaps the opposite is true.

I honestly don't know what limitations you mean. If you mean "different
style of expression," sure. (Maybe if SAIL had lexically scoped lambda
closures, there'd be a difference worth talking about...)

> 
> Regardless, comparing the work of a Knuth to the industry average is
> more than a bit unfair. :-)
> 
>     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
>     Macintosh applications and systems software -- comes under the "so
>     people fixed it" category?
> 
> 
> Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> of both) seem to have definitely fallen into that category.

I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
but it was certainly extended with many intrinsics, casts, and pointer
operations, bringing it essentially into parity with C for systems and
application programming.

--Toby


> 
>         - Dan C.
> 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

I think we have 30 years’ experience that clearly shows that dangerous languages
will be misused in critical areas, even if most of us are very careful.

Marcus Ranum once wrote a one-page version of inetd that he thought was secure.  He was and is as committed to security as anyone, and had long experience writing software important to the early Internet.  Steve Bellovin found a security hole in that one-page program.

I am convinced that a safe language with very tiny holes allowing access to dangerous stuff (like memory management in the kernel) is simply safer.  Clearly, we are no where near that right now.

> On 1Sep 2017, at 10:28 AM, Arthur Krewat <krewat at kilonet.net> wrote:
> 
> We don't need no stinkin' safety rails, we're smart enough not to walk off that cliff in the first place. And who knows, we may need to walk off that cliff at some point in the future.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/cc8cfcfc/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au>
wrote:

>
> I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
>
​It wasn't.


> but it was certainly extended with many intrinsics, casts, and pointer
> operations, bringing it essentially into parity with C for systems and
> application programming.
>
​Which was my point...​ the problem was the every Pascal compiler of the
day was different.  strings where the worst.   If you came from the folks
that believed strings should carry a length, then you defined them that
way, if you believed in a token at the end, you did that.   Moving code was
really, really hard...  So know "Pascal" was not good enough -- you had to
know N different flavors and since there was no preprocessor, writing code
that could be portable between the different flavors was basically not
going to happen.

Go back and read BWK document...   for real programming Pascal sucked in
practice (theory and practice and all that).  I'm saying that and I loved
it (and still do) Pascal as a language.   It's straight forward, safe,
clear, easy to read, *etc*. - but like Brian said, it is not my *favorite*
language.   It is not practical for a great deal of what I do.

To go back to Brian analog, one of my coworkers is a former Air-Force
fighter pilot.   She still to fly small plane like Piper Cubs for fun and
for small short flights.   She loves them.   She also used to love going at
Mach X and dog-fighting and I gather was extremely good at it.  (She was
also the first woman to graduate from the Air Force Academy).   Two
different tools.

The point is that there is nothing wrong with us having multiple tools to
functionally do the same job (programming or flying), nor is there anything
wrong with liking one tools better than another (teaching or professionally)
  ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/d82adafe/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Fri, Sep 1, 2017 at 10:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>
> Marcus Ranum once wrote a one-page version of inetd that he thought was
> secure.  He was and is as committed to security as anyone, and had long
> experience writing software important to the early Internet.  Steve
> Bellovin found a security hole in that one-page program.
>
> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

​+1​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/e55d62f0/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Arthur Krewat]

On 9/1/2017 10:48 AM, William Cheswick wrote:
> early Internet.

I had to chuckle at the above.

This was back in the day when I could telnet into almost any TOPS-20 
system using user account ANONYMOUS and a password of FTP (or something 
similar depending on the system). It wasn't more than a few minutes 
before I found an unprotected file somewhere that could be altered and 
lay in wait for someone to run it. TOPS-10 systems were even easier. VMS 
wasn't a big deal either. Even the UNIX systems at the time were never 
really secure.

I was the ARPANET's and early Internet's worst nightmare. TELENET was an 
even better source of stuff to look at. Thankfully, I was not malicious 
nor profit-driven.

I still posit that C in the hands of the right people is not prone to 
buffer overflows any more than some library issue in C++ or higher 
languages.

Higher languages that put up safeguards are only as good as the 
programmers who write the compiler/interpreter. Because deep down, the 
libraries themselves, or the kernel itself is written in something 
without hand-guards to keep you from cutting your fingers off. It's all 
machine code in the end with, for example, no limits on pointers except 
those that are constructed by more programmers or the memory protections 
built into the processor (i.e. DEP).

In other words, by using a "safe" language you are just putting your 
security in the hands of other people who may or may not be as concerned 
as you are about it.

You can only put a certain amount of bubble-wrap around a razor blade. 
In the end, there's still a razor blade under all those layers.

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

On Thu, Aug 31, 2017 at 11:59 PM, Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2017-08-31 10:38 PM, Dan Cross wrote:
> > On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> > <mailto:toby at telegraphics.com.au>> wrote:
> > [snip]
> >
> >     > But the problem was that in those days, because Wirth had designed
> it
> >     > for complete small student programs, it was hard to write large
> real
> >     > programs (as Brian points).  So people fixed it and every fixed it
> >     > differently.  Pascal was hardly standardized. ...
> >     >
> >     > And this was the root of the real problem.
> >     >
> >     > You could not write “real” programs in it and really make them run
> on
> >     > actual systems.   Brian was writing that paper, after an exercise
> in
> >
> >     Professor Knuth seemed to manage OK, writing TeX and METAFONT in
> Pascal
> >     (using his literate programming toolset, but that did not extend the
> >     language much).
> >
> > To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> > the SAIL language for the PDP-10. He switched to Pascal (again on the
> > PDP-10) later.
>
> My point was that these are very much "real world" programs in a rather
> vanilla Pascal.
>

Well, naturally. My point is to wonder whether that was in spite of the
language.

(And if you want to bring SAIL into it as another substrate for "real
> world" programs, we might learn something from contrasting it with
> Pascal and C. I don't remember anything about it.)


That would be an interesting exercise, albeit a bit far afield from TUHS,
but perhaps the relevance is that one point Pascal and C were rivals for
marketshare (or so it seemed to me early on). Surely, C and Unix were
influenced by other competing technologies of the time.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/5cf9a6e6/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

On 2017-09-01 11:57 AM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 11:59 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
>     On 2017-08-31 10:38 PM, Dan Cross wrote:
>     > On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au <mailto:toby at telegraphics.com.au>
>     > <mailto:toby at telegraphics.com.au <mailto:toby at telegraphics.com.au>>> wrote:
>     > [snip] 
>     >
>     >     > But the problem was that in those days, because Wirth had designed it
>     >     > for complete small student programs, it was hard to write large real
>     >     > programs (as Brian points).  So people fixed it and every fixed it
>     >     > differently.  Pascal was hardly standardized. ...
>     >     >
>     >     > And this was the root of the real problem.
>     >     >
>     >     > You could not write “real” programs in it and really make them run on
>     >     > actual systems.   Brian was writing that paper, after an exercise in
>     >
>     >     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     >     (using his literate programming toolset, but that did not extend the
>     >     language much).
>     >
>     > To be fair, I think that Knuth originally wrote both TeX and METAFONT in
>     > the SAIL language for the PDP-10. He switched to Pascal (again on the
>     > PDP-10) later.
> 
>     My point was that these are very much "real world" programs in a rather
>     vanilla Pascal.
> 
> 
> Well, naturally. My point is to wonder whether that was in spite of the
> language.


I think *everything* we do is "in spite of" the language we're using. :)

We will never reach a point where programming language evolution stops,
imho.

--T


> 
>     (And if you want to bring SAIL into it as another substrate for "real
>     world" programs, we might learn something from contrasting it with
>     Pascal and C. I don't remember anything about it.)
> 
> 
> That would be an interesting exercise, albeit a bit far afield from
> TUHS, but perhaps the relevance is that one point Pascal and C were
> rivals for marketshare (or so it seemed to me early on). Surely, C and
> Unix were influenced by other competing technologies of the time.
> 
>         - Dan C.
> 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Nevin Liber]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

On Fri, Sep 1, 2017 at 9:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>

"Be careful" is a euphemism for "be perfect".


> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

While I agree with this, safety is only one of the concerns we have when
developing software.  For instance, we may care about low latency, high
throughput, low memory consumption, low power consumption, etc., and they
are all competing goals.
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  +1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/479e2be7/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2017-08-31 10:38 PM, Dan Cross wrote:
> [snip]
> > While most of the
> > languages we use are Turing complete (I suppose that in the limit one
> > can write a Common Lisp implementation in C, for example), it is
> > unarguable that some languages make it *easier* to express some things
> > than other languages. In some cases this is deliberate: consider
> > languages with strong, static type systems versus dynamic but strongly
> > typed languages (or statically but weakly typed). Here the language
> > designers have intentionally made it hard to escape the tyranny of the
> > type system in order to prevent bugs.
>
> (Tyranny is not the word I would use. A more modern viewpoint would
> include topics like parametric polymorphism, typeclasses and so on.)


The specific use of the word "tyranny" was meant to be tongue-in-cheek.
Apologies if it did not come across.

> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> > had he started in Pascal; perhaps he would have, but maybe he would have
> > given up on some of the more ambitious parts of both because the
> > language made it much less convenient (not knowing SAIL, I'm
>
> It seems inconceivable to me that there are "ambitious parts" of TeX and
> METAFONT that Professor Knuth had to omit because he was using Pascal.
>

But he wasn't using Pascal. The point was to wonder whether TeX and
METAFONT would be different programs if he were. Clem seemed to imply that
he thought that was unlikely, based on his previous use of SAIL.

[snip]
>
> I have not compared the codebases but wouldn't one expect that the final
> production TeX rewrite is *more* ambitious than the early SAIL version?
> (By the time I began using/porting TeX in the 1980s, the older version
> was completely obsolete.)


I don't know, but that's besides the point: the question was more about how
the initial programming language shaped the design of the program.
Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX have
been different? To put it another way, to what extent was he constrained,
freed, or otherwise influenced by his medium?

> speculating). Perhaps having gone through the exercise of producing TeX
> > in SAIL gave him insight that inspired him to work around Pascal's
> > expressive limitations. Or perhaps the opposite is true.
>
> I honestly don't know what limitations you mean. If you mean "different
> style of expression," sure. (Maybe if SAIL had lexically scoped lambda
> closures, there'd be a difference worth talking about...)


Formally speaking, Pascal is no more limited than any other Turing-complete
language. But there's a difference between *formal* expressiveness and
*informal* expressiveness. Some languages require proportionally more
effort to produce the same program than others. I'm told that sed is
Turing-complete; I'd sure hate to write TeX in it.

The specific "limitations" I'm referring to are mostly covered in the BLTR
#100; things like array length being part of the array object's type; lack
of compile-time initializers, statics, etc.

As an illustrative example, consider the case of a simple dispatch loop
where I want to do some work based on the entry of some string key. In C,
one might write something like this:

typedef struct Cmd Cmd;
struct Cmd {
        const char *cmd;
        int (*thunk)(void);
};

int acmd(void);
int bcmd(void);
// Etc....

Cmd cmds[] = {
    {"a", acmd},
    {"b", bcmd},
    // ...etc...
};

#define nelem(A) (sizeof(A)/sizeof((A)[0]))

int
dispatch(const char *cmd)
{
        for (size_t k = 0; k < nelem(cmds); k++) {
                if (strcmp(cmds[k].cmd, cmd) == 0)
                        return cmds[k].thunk();
        }
        return -1;
}

But how would one write this in Pascal? For a completely unrelated task, I
actually tried to write something like this in Pascal a few weeks ago and
found the lack of compile-time initializers to be an impediment. It struck
me that I could create a record type of some kind or another and
dynamically create a dispatch table via an initialization procedure (say,
building up a linked list or create an array of pointers to functions), but
it struck me that it was possibly more work than just avoiding the
table-driven approach and having a bunch of hard-coded test cases inside of
a loop. Etc.

> Regardless, comparing the work of a Knuth to the industry average is
> > more than a bit unfair. :-)
> >
> >     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
> >     Macintosh applications and systems software -- comes under the "so
> >     people fixed it" category?
> >
> >
> > Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> > of both) seem to have definitely fallen into that category.
>
> I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
> but it was certainly extended with many intrinsics, casts, and pointer
> operations, bringing it essentially into parity with C for systems and
> application programming.


This confuses me; Apple Pascal and Object Pascal are distinct but related
languages. I specifically referred to Object Pascal, Delphi and Free Pascal
but not Apple Pascal. It strikes me in re-reading what I wrote earlier that
my comments were a bit of a non-sequitur. My bad.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/97391328/attachment-0001.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Fri, Sep 1, 2017 at 10:48 AM, William Cheswick <ches at cheswick.com> wrote:

> I think we have 30 years’ experience that clearly shows that dangerous
> languages
> will be misused in critical areas, even if most of us are very careful.
>

I think I would amend this to say something along the lines of, "we have
40+ years of experience clearly showing that dangerous languages cannot be
used safely in critical areas without a disproportionate amount of care and
effort, despite the best efforts and skill of our best programmers."

Marcus Ranum once wrote a one-page version of inetd that he thought was
> secure.  He was and is as committed to security as anyone, and had long
> experience writing software important to the early Internet.  Steve
> Bellovin found a security hole in that one-page program.
>
> I am convinced that a safe language with very tiny holes allowing access
> to dangerous stuff (like memory management in the kernel) is simply safer.
> Clearly, we are no where near that right now.
>

Moreover, as Steve said, what we consider "programming" these days is
different than it was even 20 years ago: the programs we write are largely
glue tying together a dizzying array of complicated and powerful libraries.
There was a time that whenever I wanted a linked list in C, well, I'd just
add a 'next' pointer to a struct; if I wanted a tree, I'd add 'left' and
'right' pointers. For the *vast* majority of programmers, those days are
gone but our languages don't really reflect that.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/3f2c0e24/attachment.html>

[TUHS] Future Languages (was Pascal not Favorite...)

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3337 bytes --]


 "Toby Thain:  We will never reach a point where programming language
evolution stops, imho."

I may just be a grumpy old fart, but I think programming languages
today are holding us back.   Nearly all of them...

I'm currently working for a hardware company (Wave Computing).   We
are building a chip with 16K 8-bit processors on it, and have plans to
build systems with up to 1/4 million processors from these chips.

Nevertheless, most programs today are still written pretty much like
they were 25 years ago.   And they are, for the most part, based on
threads where the programming task is to set out a number of steps: 
do this, do that, do something else, test this and if true do this,
...      A single serial thread.  Things like multicore CPUs are
a desperate attempt to preserve this model while the hardware world
has blown past us.

Recall that parallelism is the natural state of hardware.  It takes
effort to make things work sequentially.  In the old days, when
hardware and software used pretty much the same model, many if not
most of the hardware innovations came from first being done in
software, and then moved into hardware -- index registers, floating
point, caches, etc. etc.    That process has effectively stopped. 
The single thread model simply no longer fits the sweet spot of
today's hardware technology.

Just to underscore how far hardware has advanced:  If cars had become
as much cheaper and faster as computers from 1970 to today, we could
buy 1000 Tesla Model S's for a penny and they would go 0-60,000
mph!   A petabyte of data, if punched onto punch cards, would make a
card deck whose height would be 6 times the distance to the moon.  
If the recent estimate of the number of bytes of data produced by the
human race _every day_ (2.5 quintillion bytes) is correct, when
punched up _that_ card deck would be 9 times the distance to the sun.

I'm not saying that there isn't a place for languages like GO and
Python.  Most people will continue to think serially and design
things that way.  But when it comes to implementing these designs,
the current "systems" languages are left at the starting gate.   In
the same way that we invented abstraction methods like functions and
processes for the old computers, we need to invent newer abstraction
methods that go far beyond co-routines and threads and message
passing.  If we get bogged down in telling tens of thousands of
processors "do this, do that" we will perish long before our program
works.  Of particular relevance is the role that abstractions play in
debugging --they partition the job into pieces with known interfaces
and behavior that can be tested in isolation before being assembled
into complete systems.

Yes, I have some ideas (and not much time to work on them...) but,
even if I had a perfect solution available today, I suspect it would
take decades before it caught on.   In order to accept a solution,
you first have to believe there is a problem...

Steve

----- Original Message -----
From: "Toby Thain" <toby@telegraphics.com.au>

 We will never reach a point where programming language evolution
stops,
 imho.

 --T


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/5cde7436/attachment.html>

[TUHS] Future Languages (was Pascal not Favorite...)

[ron minnich]

On Fri, Sep 1, 2017 at 11:16 AM Steve Johnson <scj at yaccman.com> wrote:

>
>
> I'm not saying that there isn't a place for languages like GO and Python.
> Most people will continue to think serially and design things that way.
>

What I have found interesting, in the several Go projects I've been on, is
how quickly people walk away from the CSP-like ideas (goroutines and chans)
to all the old school shared memory techniques, mutexs, linked lists, and
such,  based on microbenchmarks.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/6adb7b41/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

On 2017-09-01 12:22 PM, Dan Cross wrote:
> On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> 
>     On 2017-08-31 10:38 PM, Dan Cross wrote:
>     [snip]
>     > While most of the
>     > languages we use are Turing complete (I suppose that in the limit one
>     > can write a Common Lisp implementation in C, for example), it is
>     > unarguable that some languages make it *easier* to express some things
>     > than other languages. In some cases this is deliberate: consider
>     > languages with strong, static type systems versus dynamic but strongly
>     > typed languages (or statically but weakly typed). Here the language
>     > designers have intentionally made it hard to escape the tyranny of the
>     > type system in order to prevent bugs.
> 
>     (Tyranny is not the word I would use. A more modern viewpoint would
>     include topics like parametric polymorphism, typeclasses and so on.)
> 
> 
> The specific use of the word "tyranny" was meant to be tongue-in-cheek.
> Apologies if it did not come across.
> 
>     > Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
>     > had he started in Pascal; perhaps he would have, but maybe he would have
>     > given up on some of the more ambitious parts of both because the
>     > language made it much less convenient (not knowing SAIL, I'm
> 
>     It seems inconceivable to me that there are "ambitious parts" of TeX and
>     METAFONT that Professor Knuth had to omit because he was using Pascal.
> 
> 
> But he wasn't using Pascal. The point was to wonder whether TeX and

I mean in the mid-80s rewrite, of course.

> METAFONT would be different programs if he were. Clem seemed to imply
> that he thought that was unlikely, based on his previous use of SAIL.
> 
>     [snip]
> 
>     I have not compared the codebases but wouldn't one expect that the final
>     production TeX rewrite is *more* ambitious than the early SAIL version?
>     (By the time I began using/porting TeX in the 1980s, the older version
>     was completely obsolete.)
> 
> 
> I don't know, but that's besides the point: the question was more about
> how the initial programming language shaped the design of the program.
> Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX
> have been different? To put it another way, to what extent was he
> constrained, freed, or otherwise influenced by his medium?

Maybe Professor Knuth himself has written about that, I'm not sure. A
great question for him, anyhow.

He's in an excellent position to contrast these 3 languages.

> 
>     > speculating). Perhaps having gone through the exercise of producing TeX
>     > in SAIL gave him insight that inspired him to work around Pascal's
>     > expressive limitations. Or perhaps the opposite is true.
> 
>     I honestly don't know what limitations you mean. If you mean "different
>     style of expression," sure. (Maybe if SAIL had lexically scoped lambda
>     closures, there'd be a difference worth talking about...)
> 
> 
> Formally speaking, Pascal is no more limited than any other
> Turing-complete language. But there's a difference between *formal*
> expressiveness and *informal* expressiveness. Some languages require
> proportionally more effort to produce the same program than others. I'm
> told that sed is Turing-complete; I'd sure hate to write TeX in it.
> 

I'm well aware of that, which is why I specifically mentioned lexical
closures as (one of many) ideas with a powerful effect on expressiveness
and style.

--Toby

> [snip]

[TUHS] Future Languages (was Pascal not Favorite...)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On Fri, Sep 1, 2017 at 2:15 PM, Steve Johnson <scj at yaccman.com> wrote:

>
> I may just be a grumpy old fart, but I think programming languages today
> are holding us back.   Nearly all of them...
>
​
I don't disagree with the idea or intent, but I don't think it's technology
that is hold us back Steve, it is economics.​


   1. When I was at CMU in the 70s, my Profs told me Fortran was dead.  In
   2017, it is still is the #1 *production* programming language on the
   supercomputer systems my customers purchase.   Nothing else even comes
   close.  My words - Fortran still pays my salary.
   2. Why is that?   The math has not changed.   Open up those codes from
   #1 and most of them are doing pretty much the same thing -
   solving simultaneous partial differentials with a lot of unknowns.   What
   has changed is the size of the data sets, how to generate them and how
   manipulate them.   But the guts of the code, be it weather, bio, chem,
   physics, *etc*.. its the same as it was years ago.
   3. As importantly, the Chief Metallurgist for the US Gov at NIST is a
   good friend of mine.   As Dr. Fekete says -- the problem is we have years
   worth of data that has been checked and worked on with those codes, if we
   throw them out, we have revalidate the codes and the data with them.  I can
   not afford to do that.


So until you can create a new system that is not only blazing fast to do
the new job, you have to be able to go back and revalidate all the old
datasets too.   That's going to be even harder.    That's not an excuse to
not try mind you, but the economics are not in your favor.

That said, Moore's law is not going to help the way it did before.  So, to
continue to give people 'speed ups' something has to change.   The problem
is can we afford to change the code base and the data too?  I don't think
that is likely unless something really, really disruptive happens.

And that's is the problem.  In the high end,  we have never had a "
Christensen   Style" disruption.  Remember, a true Christensen disruption
starts off as a 'worse' technology that a new (and different) group of
people care about which don't care that 'sucks' compare to the established
technology.   It is that new market that makes it valuable, but it grows so
fast that  it eventually over takes the old market.

So far it really has not happened in the high end  in my career because
there has never been a 'new group'  that has cared about that style of
computing. The high end is the same folks as it has been since the 1940s.

Maybe a new group will appear in my children's time, but I suspect I will
not be here to see that occur as I just don't see anyone on the horizon
that I think could become such.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170901/2033f00c/attachment.html>

[TUHS] Future Languages (was Pascal not Favorite...)

[Chris Torek]

>What I have found interesting, in the several Go projects I've
>been on, is how quickly people walk away from the CSP-like ideas
>(goroutines and chans) to all the old school shared memory
>techniques, mutexs, linked lists, and such, based on
>microbenchmarks.

Well, "Go channels are bad" :-)
http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/

Seriously, the above article is really quite good.  It shows you how
nice channels are, and also how annoying they are for real world
code.

(There's also some annoyances colleagues using Go have hit, but I
have not actually used Go for anything.)

I was going to mention something that others have covered: TeX
papered over Pascal's inadequacies using Knuth's Tangle.  When you
ported the Pascal-ish TeX to your own system, you:

 - defined your system-specific methods of accessing files
 - defined your Pascal compiler's default-case keyword (`otherwise`
   or `else` or `default` or whatever it was)

and so on, in a system-specific file.  Tangle would read your
system-specific definitions, mix them in with the TeX source, and
produce a `.p` (or whatever name) file to compile.  It was like
having a somewhat klunky variant of the C preprocessor.

Along similar yet different lines ...

For current $job, I've been reading up on Rust.  There is a lot to
like here: it's like C++ in terms of compile time type safety, and
the language attempts, with lifetime declarations and annotations
and the idea of memory ownership, to guarantee memory safety and
even thread safety.

(The build system also handles versioning directly.  This seems to
be a big vacuum in the Go ecosystem.)

There is a lot to dislike too.  The syntax is klunky in several
places and there's a fair amount of bondage-and-discipline that
can be handled easily with appendages like ".unwrap", which is
fine but quite verbose.  The type and lifetime inference rules are
a bit arcane, and don't work for all the desirable cases.  (E.g.,
instead of C++'s solution that "x = &&(expr)" extends the lifetime
of the temporary holding the expression to the entire function,
Rust, well, just doesn't, and then complains that the expression
evaporates too soo, even though the reference to it evaporates
just a moment later, and holding the expression for just a bit
longer would have solved the problem.)

I'm not far enough along yet to decide how I feel overall, but it
is definitely a big *syntactic* improvement over C++ (which I am
also using for current $job), and the semantics actually seem less
klunky.  (C++17 is trying to improve this but they're painted into
many corners simultaneously, so adding allocator decorations and
better variable forwarding and so on is just nightmarish.  The
lvalue / rvalue / prvalue / glvalue / xvalue stuff, yikes.  All
because it's such a big deal to avoid copying heavy temporaries...)

(See: http://en.cppreference.com/w/cpp/language/value_category
http://en.cppreference.com/w/cpp/language/implicit_conversion
especially the "since C++11" and "since C++17" sections)

Chris

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dave Horsfall]

I vote this the longest thread ever :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dan Cross]

On Fri, Sep 1, 2017 at 3:07 PM, Toby Thain <toby at telegraphics.com.au> wrote:

> On 2017-09-01 12:22 PM, Dan Cross wrote:
> [snip]
> > But he wasn't using Pascal. The point was to wonder whether TeX and
>
> I mean in the mid-80s rewrite, of course.


But by then the major design decisions would have been made.  Was TeX after
that rewrite an appreciably different language?

> METAFONT would be different programs if he were. Clem seemed to imply
> > that he thought that was unlikely, based on his previous use of SAIL.
> >
> >     [snip]
> >
> >     I have not compared the codebases but wouldn't one expect that the
> final
> >     production TeX rewrite is *more* ambitious than the early SAIL
> version?
> >     (By the time I began using/porting TeX in the 1980s, the older
> version
> >     was completely obsolete.)
> >
> >
> > I don't know, but that's besides the point: the question was more about
> > how the initial programming language shaped the design of the program.
> > Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX
> > have been different? To put it another way, to what extent was he
> > constrained, freed, or otherwise influenced by his medium?
>
> Maybe Professor Knuth himself has written about that, I'm not sure. A
> great question for him, anyhow.
>
> He's in an excellent position to contrast these 3 languages.


I'll shoot him an email.

I'm well aware of that, which is why I specifically mentioned lexical
> closures as (one of many) ideas with a powerful effect on expressiveness
> and style.
>

Hmm, it seems there are a number of more fundamental issues with the
language. I listed a number, mostly cribbed from Kernighan's paper and my
own experience.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170902/ba0b295c/attachment.html>

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 
> I've often wondered to what extent (natural) language shapes thought;
> for instance, to what extent does grammatical gender influence
> patriarchy or matriarchy of the society that speaks that language, etc.
> If some thought is relatively harder to express in a given language,
> will less attention be given to areas associated with that thought? It
> is my limited understanding that linguists and social scientists have
> studied this and seen a positive correlation between language and
> culture/society (I don't know if it's causal).
> 
> But if we go out on a branch and assume that it *is* causal for a
> moment, it naturally raises the question: is the same true of other
> types of languages? How about programming languages or mathematical
> notations (or other similar domain specific languages)?
> 
> I have long suspected that it is true of programming. ...

This is why, as our ideas grow in sophistication, our languages must
also. I think the history of mathematical notation is a perfect example.

Lots of people are on this wavelength, e.g. this presentation:

Metaphors We Compute By, Alvaro Videla
https://www.youtube.com/watch?v=okUmXP1vAic&feature=youtu.be
33 minutes + Q&A

  "The main thesis of Lakoff... [is that metaphors] permeate all of the
language, furthermore they dictate in a way how we live, how we see the
world comes from the metaphors ... How our conceptual system is built.
... A metaphor can thus be used to identify a structure in a domain that
would not have been discovered otherwise.
  ... Master the art of meaning amplication."

This talk also mentions Dr Barbara Liskov's paper, "Programming with
Abstract Data Types":

  "The motivation behind the work in very-high-level languages is to
ease the programming task by providing the programmer with a language
containing primitives or abstractions suitable to his problem area. The
programmer is then able to spend his effort in the right place..."


Finally, a favourite quote:

  "Programs must be written for people to read, and only incidentally
for machines to execute" -- Hal Abelson

https://twitter.com/old_sound/status/903919515884544000


--Toby


> 
>         - Dan C.
> 

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dave Horsfall]

On Thu, 31 Aug 2017, Nemo wrote:

> (By the way, why all the ^M is the files?)

Err, because CR/LF was the line terminator?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[arnold]

Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 31 Aug 2017, Nemo wrote:
>
> > (By the way, why all the ^M is the files?)
>
> Err, because CR/LF was the line terminator?

There aren't any CRs in the original files. Something got mangled in
the email maybe.

Check out the files from https://github.com/arnoldrobbins/cstr100.  I'm up
to 3 bugs fixed in the 1979 MS macros and one in the paper.  I have also
brought all the references into line with the original, and added the PostScript
of the original as well.

There remains one troff glitch; the inline CW is formatting as underlined
Roman text.  No idea why, and I haven't had time to investigate.  I suspect
the MS macros in use when BWK wrote the paper had evolved somewhat.

HTH,

Arnold

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Dave Horsfall]

On Sun, 3 Sep 2017, arnold at skeeve.com wrote:

> There aren't any CRs in the original files. Something got mangled in the 
> email maybe.

Then it must've passed through an MS/DOS gateway :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> wrote:

 |On Sun, 3 Sep 2017, arnold at skeeve.com wrote:
 |
 |> There aren't any CRs in the original files. Something got mangled in the 
 |> email maybe.
 |
 |Then it must've passed through an MS/DOS gateway :-)

Or it has been base64 re-encoded along the way (many do this
without being asked) and that process (i think correctly)
converted to the said, and some stupid mailer took that data for
granted.  (E.g., my one does, yet, it only has a hack to remove
the CRs when going to display the data.  Iirc.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Future Languages (was Pascal not Favorite...)

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]

> On Sep 1, 2017, at 11:15 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> 

> I may just be a grumpy old fart, but I think programming languages today are holding us back.   Nearly all of them...

I think the problem is much wider than just programming languages.

Most of our PLs, programs & tools are basically for single machine things. Our compilers, linkers, debuggers can only handle this case well. With a few exceptions.

This is not a good fit for a major class of applications today: service software. This is typically composed of a number of loosely coupled programs running on a set of networked machines. Managing this is done in a very ad-hoc & complicated manner (e.g. kubernetes). A service is implemented with essentially a distributed program but our tools don’t make it easy to compose or debug such programs. Things like dockers, containers, jails are complicated ways of dealing with problems we run into re: security, fault isolation, resiliency, scalability etc.

At the other extreme, dealing with GPUs or specialized processors with zillion cores, each with a small amount of memory etc. is also painful and ad-hoc.

In this context even if you prove a single component to be bug free, how can you have confidence in the whole system? It is well-nigh impossible to test all the gazillion ways a system can fail on a small scale or large (e.g. a java based component ran out of file descriptor or a packet gets misrouted or firewall rules are not quite right). Moving to something like Cloud would be an improvement over docker & VMs but that still leaves open the composition aspect.

Now likely there isn't a single silver bullet for all of this but our present systems are far more complicated than they need to be.

> On Sep 1, 2017, at 11:15 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> 
> "Toby Thain:  We will never reach a point where programming language evolution stops, imho."
> 
> I may just be a grumpy old fart, but I think programming languages today are holding us back.   Nearly all of them...
> 
> I'm currently working for a hardware company (Wave Computing).   We are building a chip with 16K 8-bit processors on it, and have plans to build systems with up to 1/4 million processors from these chips.
> 
> Nevertheless, most programs today are still written pretty much like they were 25 years ago.   And they are, for the most part, based on threads where the programming task is to set out a number of steps:  do this, do that, do something else, test this and if true do this, ...      A single serial thread.  Things like multicore CPUs are a desperate attempt to preserve this model while the hardware world has blown past us.
> 
> Recall that parallelism is the natural state of hardware.  It takes effort to make things work sequentially.  In the old days, when hardware and software used pretty much the same model, many if not most of the hardware innovations came from first being done in software, and then moved into hardware -- index registers, floating point, caches, etc. etc.    That process has effectively stopped.  The single thread model simply no longer fits the sweet spot of today's hardware technology.
> 
> Just to underscore how far hardware has advanced:  If cars had become as much cheaper and faster as computers from 1970 to today, we could buy 1000 Tesla Model S's for a penny and they would go 0-60,000 mph!   A petabyte of data, if punched onto punch cards, would make a card deck whose height would be 6 times the distance to the moon.   If the recent estimate of the number of bytes of data produced by the human race every day (2.5 quintillion bytes) is correct, when punched up that card deck would be 9 times the distance to the sun.
> 
> I'm not saying that there isn't a place for languages like GO and Python.  Most people will continue to think serially and design things that way.  But when it comes to implementing these designs, the current "systems" languages are left at the starting gate.   In the same way that we invented abstraction methods like functions and processes for the old computers, we need to invent newer abstraction methods that go far beyond co-routines and threads and message passing.  If we get bogged down in telling tens of thousands of processors "do this, do that" we will perish long before our program works.  Of particular relevance is the role that abstractions play in debugging --they partition the job into pieces with known interfaces and behavior that can be tested in isolation before being assembled into complete systems.
> 
> Yes, I have some ideas (and not much time to work on them...) but, even if I had a perfect solution available today, I suspect it would take decades before it caught on.   In order to accept a solution, you first have to believe there is a problem...
> 
> Steve
> 
> 
> 
> ----- Original Message -----
> From: "Toby Thain" <toby at telegraphics.com.au>
> 
> 
> We will never reach a point where programming language evolution stops,
> imho.
> 
> --T
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170904/36212d03/attachment.html>

[TUHS] Future Languages (was Pascal not Favorite...)

[ron minnich]

On Fri, Sep 1, 2017 at 4:33 PM Chris Torek <torek at torek.net> wrote:

>
>
> Well, "Go channels are bad" :-)
>
> http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/
>
>
>
thanks. Great article. He does hit on many of the things I've found
annoying.

It leads me to wonder: maybe Go 2 should fix this stuff.

And now I stop, as I am totally off the topic...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170904/27670aaf/attachment.html>