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

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

[Norman Wilson]

Steve Johnson:

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

====

I'm (still) with Larry Flon on this one:

  There does not now, nor will there ever, exist a programming language
  in which it is the least bit hard to write bad programs.

-- SIGPLAN Notices, October 1975, p. 16.

There are certainly language that make it easier to avoid
trivial mistakes, like buffer overruns and pointer botches,
but the sort of nonsense Kernigan and Plaugher demonstrated
and discussed about the same time in The Elements of Programming
Style shows up in any language.

I'm afraid I see that nearly any time I look in source code.
To be fair, these days I rarely have the time to look at
someone else's source code unless it's buggy, but it is
nevertheless appalling what one finds in critical system
software like boot environments and authentication code.

There is no royal language to good programs.  Programming
well takes discipline and skill and experience.  Languages
like Pascal that prevent certain classes of sloppiness like
overrunning arrays and string buffers may be better for
teaching beginners, but only because that makes it easier
to focus on the real issues, such as how to structure a
program well and how to write clearly.  I have yet to see
evidence that that actually happens.

Norman Wilson
Toronto ON

[TUHS] Future Languages

[Steve Johnson]

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


"From: "Norman Wilson" <norman at oclsc.org>

 I'm (still) with Larry Flon on this one:

 There does not now, nor will there ever, exist a programming language
 in which it is the least bit hard to write bad programs."

Well, there's bad and there's bad.   Programs that are the result of
flawed thinking or a misunderstanding of the language or the
environment can't be helped by a programming language.  Programs with
a well thought-out and appropriate set of concepts and structures can
be hard to write if the language doesn't support these concepts and
structures.  That was the point of Brian's note.  If the language
doesn't support what you want to, danger may lie ahead.

A particularly vivid example for me is string handling -- I mean real
strings, with concatenation and the ability to add characters onto the
beginning, middle or end of the string .  At one point in the past,
Bell Labs and Xerox Parc were two groups that had produced some
impressive programs.  I spent some time at Parc, and ended up envious
about the ability of LISP programmers to dynamically add on to almost
anything with a high degree of safety.  This really changed the way
one thought about some programs.  Doing strings in C usually involves
pointers pointing at small things, which, given how easy it is to
index past the end, was like playing with razor blades.   C++
allowed you to surround such things with safety nets, but sometimes
the performance impact was unfortunate.   A similar example  is the
ability to grow an array.  This plays very badly with C's pointers --
if you move the array, then anybody pointing to it (and, often, there
are many such) has a stale pointer-bomb that could go off at any time
without warning.  If you don't move the array, but add on additional
pieces, then it is no longer contiguous, so some operations (like
scanning all the elements) get very complicated as well.

I don't think there would be much argument that writing a garbage
collector from scratch in plain C is hard and dangerous.  Using a
language that has garbage collection built in makes sense, assuming
you can afford the performance penalty.  Using a better algorithm is
a better bet, but may be impossible.

The C/C++ model of a single large common address space has caused
problems for parallel programs for decades, first with message passing
and later with multicore.  In multicore, the "solution" is
increasingly sophisticated caches and cache coherency circuits that
can end up thrashing and making things slower if not well
understood.  And the best solution may well be dependent of the
particular chip.

These are, for the most part, examples of how powerful and useful
models don't fit into C's world view very comfortably.  A lot of C's
power, and Pascal's deficiencies, come because C doesn't prevent you
from doing things that are outside of its model, and Pascal does.

Maybe it would be more precise to say that some languages strictly
enforce their world view, making programs that accord with that world
view easy and others difficult.  And other languages loosely enforce
their world view, making it possible to do more than the former
languages, often with performance advantages, but with more danger
that bugs will not be detected.

I guess I like Demer's wording better...

Steve 


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

[TUHS] Future Languages

[Larry McVoy]

On Mon, Sep 04, 2017 at 02:28:23PM -0700, Steve Johnson wrote:
> A particularly vivid example for me is string handling -- I mean real
> strings, with concatenation and the ability to add characters onto the
> beginning, middle or end of the string .?? At one point in the past,
> Bell Labs and Xerox Parc were two groups that had produced some
> impressive programs.?? I spent some time at Parc, and ended up envious
> about the ability of LISP programmers to dynamically add on to almost
> anything with a high degree of safety.?? This really changed the way
> one thought about some programs.?? Doing strings in C usually involves
> pointers pointing at small things, which, given how easy it is to
> index past the end, was like playing with razor blades.???? C++
> allowed you to surround such things with safety nets, but sometimes
> the performance impact was unfortunate.???? A similar example?? is the
> ability to grow an array.?? This plays very badly with C's pointers --
> if you move the array, then anybody pointing to it (and, often, there
> are many such) has a stale pointer-bomb that could go off at any time
> without warning.?? If you don't move the array, but add on additional
> pieces, then it is no longer contiguous, so some operations (like
> scanning all the elements) get very complicated as well.

So we have some source (that you can have as well, Apache license)
that handles not strings but vectors of strings (or structs or whatever).

I need to write up how it works, it's sort of clever.  It stores both
the size of the vector (always a power of 2) in part of the bits of the
first entry and the actual length in the other part.  Because we can
express powers of two in very little space we can support both values
in a 32 bit unsigned with a max length of used space of around 134M.

So the vector is

	[0] = [size, used]
	[1] = first element
	[2] = second element
	...
	[0.used] = last element (I might be off by one)

You use it like so

	char	*v = 0;
	char	buf[MAXLINE];

	while (fgets(buf, sizeof(buf), stdin)) {
		/*
		 * v starts as null, the first one will reset it to a vector,
		 * as it grows, if realloc fails then the value of v will
		 * change.
		 */
		v = addLine(v, strdup(buf));
    	}

There are interefaces to do all the perl stuff, push, pop, shift,
unshift, sort, join, search, remove, insert, sort, reverse.  There is a
split that takes a blob and returns a vector, there is a shellSplit that
splits the way the bourne shell would, there is an interface to spawn a
program and return a vector, there is one to slurp a file into a vector
and the other way, etc.  There is pretty much everything you could want,
we used this everywhere in BitKeeper so it's very old, tested, stable.

It should be pretty easy to lift all that stuff out and stick it in a
library.  It's handy as heck and pleasant in that it's pretty small for
small stuff but scales up nicely for larger stuff.  I suppose you could
think of it as Lisp's list, i was never a Lisp fan, I think of it as 
Perl lists plus the supporting stuff.

lines.h:

http://repos.bkbits.net/bk/dev/src/libc/lines.h?PAGE=anno&REV=574729199TRQBrjF_tJiHFtKPHiJzQ

lines.c:

http://repos.bkbits.net/bk/dev/src/libc/utils/lines.c?PAGE=anno&REV=56cf7e34BTkDFx47E54DPNG51B2uCA

[TUHS] Future Languages

[Noel Hunt]

Some little while ago, I mentioned the example of Doug McIlroy's
solution to the problem of finding words in a dictionary with vowels
in vowel order, and in an access of gushing enthusiasm said it
showed 'genius'. Doug McIlroy disabused me of this idea, claiming
it was simply 'experience' and that other people at the labs at
the time would have come up with similar solutions. But he
cannot deny the level of 'creativity' or 'innovativity' involved
in the solution he provided, and I daresay the people employed at
the labs were chosen because they were similarly creative or
innovative.

I believe this is exactly what Norman Wilson was talking about:
'Programming well takes discipline and skill and experience' to
which I would add 'creativity'. The first three can be learned to
a great extent. Thus, 'There is no royal language to good programs'.


On Tue, Sep 5, 2017 at 7:28 AM, Steve Johnson <scj at yaccman.com> wrote:

>
> "From:
> "Norman Wilson" <norman at oclsc.org>
>
>
> I'm (still) with Larry Flon on this one:
>
> There does not now, nor will there ever, exist a programming language
> in which it is the least bit hard to write bad programs."
>
> Well, there's bad and there's bad.   Programs that are the result of
> flawed thinking or a misunderstanding of the language or the environment
> can't be helped by a programming language.  Programs with a well
> thought-out and appropriate set of concepts and structures can be hard to
> write if the language doesn't support these concepts and structures.  That
> was the point of Brian's note.  If the language doesn't support what you
> want to, danger may lie ahead.
>
> A particularly vivid example for me is string handling -- I mean real
> strings, with concatenation and the ability to add characters onto the
> beginning, middle or end of the string .  At one point in the past, Bell
> Labs and Xerox Parc were two groups that had produced some impressive
> programs.  I spent some time at Parc, and ended up envious about the
> ability of LISP programmers to dynamically add on to almost anything with a
> high degree of safety.  This really changed the way one thought about some
> programs.  Doing strings in C usually involves pointers pointing at small
> things, which, given how easy it is to index past the end, was like playing
> with razor blades.   C++ allowed you to surround such things with safety
> nets, but sometimes the performance impact was unfortunate.   A similar
> example  is the ability to grow an array.  This plays very badly with C's
> pointers -- if you move the array, then anybody pointing to it (and, often,
> there are many such) has a stale pointer-bomb that could go off at any time
> without warning.  If you don't move the array, but add on additional
> pieces, then it is no longer contiguous, so some operations (like scanning
> all the elements) get very complicated as well.
>
> I don't think there would be much argument that writing a garbage
> collector from scratch in plain C is hard and dangerous.  Using a language
> that has garbage collection built in makes sense, assuming you can afford
> the performance penalty.  Using a better algorithm is a better bet, but may
> be impossible.
>
> The C/C++ model of a single large common address space has caused problems
> for parallel programs for decades, first with message passing and later
> with multicore.  In multicore, the "solution" is increasingly sophisticated
> caches and cache coherency circuits that can end up thrashing and making
> things slower if not well understood.  And the best solution may well be
> dependent of the particular chip.
>
> These are, for the most part, examples of how powerful and useful models
> don't fit into C's world view very comfortably.  A lot of C's power, and
> Pascal's deficiencies, come because C doesn't prevent you from doing things
> that are outside of its model, and Pascal does.
>
> Maybe it would be more precise to say that some languages strictly enforce
> their world view, making programs that accord with that world view easy and
> others difficult.  And other languages loosely enforce their world view,
> making it possible to do more than the former languages, often with
> performance advantages, but with more danger that bugs will not be detected.
>
> I guess I like Demer's wording better...
>
> Steve
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170905/96cd1568/attachment.html>

[TUHS] Future Languages

[Richard Tobin]

> So we have some source (that you can have as well, Apache license)
> that handles not strings but vectors of strings (or structs or whatever).
> 
> I need to write up how it works, it's sort of clever.  It stores both
> the size of the vector (always a power of 2) in part of the bits of the
> first entry and the actual length in the other part.  Because we can
> express powers of two in very little space we can support both values
> in a 32 bit unsigned with a max length of used space of around 134M.

I have something similar.  It allocates space for two ints (number
allocated and used) at ((int *)array)[-1] and [-2].

Typical use is

    LTVectorAndInit(char *, names);

    while(...)
      LTVectorPush(names, s);

    for(i=0; i<LTVectorCount(names); i++)
      ... names[i] ...;

    LTVectorFree(names);

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.