pre-requestie for learning C...

[Richard Bos]

Like many I was taught programming in school using TP, and I think I
was taught well. What lost features are you referring to?

Mostly strictness. In order to become a borderline useful language, it
had to add some features. Now, the thing which made standard Pascal so
useful for teaching was that, being limited in what it would allow, it
forced you to program structurally. The extent to which it did this was
an irritant in real use, but very applicable in teaching.
To name but one example, in Pascal, it is not possible to jump out of a
function or procedure. You _must_ follow the one entrance-one exit
philosophy. This is, of course, unpleasant to use, but it does force the
learner to be structured approach. Borland added an "exit" keyword which
circumvented this, like C's return keyword. Very useful for the normal
programmer, but not good for someone who hasn't had clarity of structure
bashed into him yet.

Of course, it's perfectly possible to learn programming using Turbo
Pascal, just as it's perfectly possible to do so using C. It's just that
you have to exert control over yourself - or have a good teacher - in
order not to pick up bad habits just because you can. With real Pascal,
this is made a lot easier for you, simply because many of the hacks and
spaghetti junctions you can create in more real-world-useful languages
aren't possible in Pascal in the first place.

Richard

 

[CBFalconer]

.... snip ...


Mostly strictness. In order to become a borderline useful
language, it had to add some features. Now, the thing which made
standard Pascal so useful for teaching was that, being limited
in what it would allow, it forced you to program structurally.
The extent to which it did this was an irritant in real use, but
very applicable in teaching. To name but one example, in Pascal,
it is not possible to jump out of a function or procedure. You
_must_ follow the one entrance-one exit philosophy. This is, of
course, unpleasant to use, but it does force the learner to be
structured approach. Borland added an "exit" keyword which
circumvented this, like C's return keyword. Very useful for the
normal programmer, but not good for someone who hasn't had
clarity of structure bashed into him yet.

Of course, it's perfectly possible to learn programming using
Turbo Pascal, just as it's perfectly possible to do so using C.
It's just that you have to exert control over yourself - or have
a good teacher - in order not to pick up bad habits just because
you can. With real Pascal, this is made a lot easier for you,
simply because many of the hacks and spaghetti junctions you can
create in more real-world-useful languages aren't possible in
Pascal in the first place.

I disagree. The points you raise caused minor problems. The basic
fault was failure to implement standard Pascal, especially the use
of f^, get, and put. Other relatively minor problems included the
failure to properly terminate the action of input routines for
numbers, or the length format for string output. The result of
this sort of thing is that Turbo users learned to program C in
Pascal words, rather than real Pascal with all its advantages (and
some disadvantages).

The proper i/o provisions allowed standard Pascal to use almost
anything as an input/output file. I implemented file versions for
interrupt driven, non-interrupt driven, windows driven, with all
sorts of useful i/o provisions. I needed nothing but the standard
interface to effectuate them. I did need the capability to write
i/o drivers, which interfaced with the system proper with five
routines, if I recall correctly.

 

[Richard Bos]

I disagree. You never seem to have learned to use standard
Pascal. I used it for about a dozen years, largely in interactive
embedded systems.

You did? Gosh. You must be even more intelligent than Brian Kernighan.
Enlighten us mere mortals - how _did_ you solve the problems mentioned
in paragraph 4 of WPINMFPL?

Richard

 

[Keith Thompson]

You did? Gosh. You must be even more intelligent than Brian Kernighan.
Enlighten us mere mortals - how _did_ you solve the problems mentioned
in paragraph 4 of WPINMFPL?

That would be "Why Pascal is Not My Favorite Programming Language", by
Brian W. Kernighan. The 4th paragraph, by my count, is a single
sentence describing the origins of the paper. Did you mean section 4?

 

[Pascal J. Bourguignon]

You did? Gosh. You must be even more intelligent than Brian Kernighan.
Enlighten us mere mortals - how _did_ you solve the problems mentioned
in paragraph 4 of WPINMFPL?

You (and WPINMFPL's author) are unfair.

There is a C standard, and if follow it strictly, C is a language as
useless as Pascal. The proof is in all the kernels, where
non-standard extensions to the standard C language have to be used to
actually work.

The same is true with Pascal. Implementation on systems other than
punch-card/line-printer/batch computers include extensions to make it
easy to use Pascal in interactive environment.

Hey! Stop the bullshit about Pascal, MacOS was written in Pascal!
Apart from the low level layers (drivers, file system) which were
written in Assembler, and Quickdraw which was prototyped in Pascal,
and optimized in assembler, the whole toolbox GUI and utilities were
written in Pascal. Actually there was no C compiler available for Mac
until a couple of years after its introduction.

 

[Richard Bos]

That would be "Why Pascal is Not My Favorite Programming Language", by
Brian W. Kernighan. The 4th paragraph, by my count, is a single
sentence describing the origins of the paper. Did you mean section 4?

Sorry, Dutch/English confusion. What you call a paragraph we call an
alinea; what we call a paragraaf you call a section. I don't _usually_
confuse those, these days. So yes, I did mean section 4.

Richard

 

[Kenny McCormack]

I agree with that. I can't think of any useful software, open source
or otherwise, that's been written purely in ISO C, even if that
software could have been written purely in ISO C. I suspect encryption
algorithms and some scientific programs would come the closest.

Which underscores what I have always said is the real problem with
comp.lang.c. It is not that the newsgroup as it exists is wrong to
exist as it is exists. It is simply that it is incorrectly named.

If the name of this group were comp.lang.c.iso-c-only, nobody would
complain. In fact, they would laud it as a place where those who like
such obscurely academic and useless things can discuss them in peace.

But to have and keep the "top level" name (comp.lang.c, which sounds to
all the world like a place to discuss C) for this obscurely academic
small dark corner of C, is just plain wrong.

 

[CBFalconer]

You did? Gosh. You must be even more intelligent than Brian
Kernighan. Enlighten us mere mortals - how _did_ you solve the
problems mentioned in paragraph 4 of WPINMFPL?

I have no opinions on that, but expect there is no great
difference. And, if you expect an answer, I suggest you express
the problems in a manner understandable to all - i.e. words.

 

[Keith Thompson]

Richard Bos wrote: [...]

You did? Gosh. You must be even more intelligent than Brian
Kernighan. Enlighten us mere mortals - how _did_ you solve the
problems mentioned in paragraph 4 of WPINMFPL?

I have no opinions on that, but expect there is no great
difference. And, if you expect an answer, I suggest you express
the problems in a manner understandable to all - i.e. words.

He did, in response to my query. READ THE WHOLE THREAD.

 

[CBFalconer]

Richard Bos wrote: [...]

You did? Gosh. You must be even more intelligent than Brian
Kernighan. Enlighten us mere mortals - how _did_ you solve the
problems mentioned in paragraph 4 of WPINMFPL?

I have no opinions on that, but expect there is no great
difference. And, if you expect an answer, I suggest you express
the problems in a manner understandable to all - i.e. words.

He did, in response to my query. READ THE WHOLE THREAD.

I see no such reply. All I see is "So yes, I did mean section 4."

 

[Keith Thompson]

Richard Bos wrote: [...]
You did? Gosh. You must be even more intelligent than Brian
Kernighan. Enlighten us mere mortals - how _did_ you solve the
problems mentioned in paragraph 4 of WPINMFPL?

I have no opinions on that, but expect there is no great
difference. And, if you expect an answer, I suggest you express
the problems in a manner understandable to all - i.e. words.

He did, in response to my query. READ THE WHOLE THREAD.

I see no such reply. All I see is "So yes, I did mean section 4."

Ok, you didn't indicate that you had read that reply. The parent of
that reply explains what WPINMFPL means. I presume you can find a
copy of the document; if not, see
<http://www.lysator.liu.se/c/bwk-on-pascal.html>. So what was
unclear?

 

[James Dow Allen]

Actually there was no C compiler available for Mac
until a couple of years after its introduction.

I wrote code in C for Macintosh in 1985. Sorry -- remember little
about compiler I used except that ... it did exist! (I *think* I
got it via Apple Developers' organization; anyway it wasn't
hard to get.)

I called Pascal ToolBox routines from the C code; the calling
convention was completely reversed -- I don't remember whether
I wrote my own assembly glue, or if it was compiler-supplied.
Apropos of a recent c.l.c thread, I had the "best" (worst?) of
both worlds for character strings, using (length : string : null)
so both Pascal and C could use them!

James Dow Allen

 

[Phil Carmody]

You did? Gosh. You must be even more intelligent than Brian Kernighan.
Enlighten us mere mortals - how _did_ you solve the problems mentioned
in paragraph 4 of WPINMFPL?

Given
"""
I simply gave up trying to write the following trivial encryption program in Pascal:

i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end

because I couldn't write a sensible 'xor' function.
"""
I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly
know the language at all. All it needs is addition and
equality test operators, and either modular reduction or an
odd() predicate (which I believe the languge does have).

Phil

 

[James Kuyper]

Phil Carmody wrote:
....

Given
"""
I simply gave up trying to write the following trivial encryption program in Pascal:

i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end

because I couldn't write a sensible 'xor' function.
"""
I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly
know the language at all. All it needs is addition and
equality test operators, and either modular reduction or an
odd() predicate (which I believe the languge does have).

That declaration would carry more weight if accompanied by actual Pascal
code for the xor function. I'm not saying whether it is or is not
possible - I don't remember enough about Pascal to judge.

 

[Pascal J. Bourguignon]

Phil Carmody wrote:
...

Given """
I simply gave up trying to write the following trivial encryption program in Pascal:
i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end
because I couldn't write a sensible 'xor' function. """
I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly know the
language at all. All it needs is addition and equality test
operators, and either modular reduction or an odd() predicate (which
I believe the languge does have).

That declaration would carry more weight if accompanied by actual
Pascal code for the xor function. I'm not saying whether it is or is
not possible - I don't remember enough about Pascal to judge.

const
byteSize = 8;


function bitXor(a:integer;b:integer;bit:integer):integer;
begin
if ((a=0) and (b=0)) or ((a<>0) and (b<>0)) then
bitXor:=0
else
bitXor:=bit;
end; { bitXor }


function byteXor(a:integer;b:integer):integer;
var
c : integer;
i : integer;
n : integer;
ab : integer;
bb : integer;
begin
c:=0;
i:=0;
n:=1;
while i<byteSize do begin
if odd(a) then ab:=1 else ab:=0;
if odd(b) then bb:=1 else bb:=0;
c:=c+bitXor(ab,bb,n);
i:=i+1;
n:=n+n;
a:=a div 2;
b:=b div 2;
end;
byteXor:=c;
end; { byteXor }


function charXor(a:char;b:char):char;
begin
charXor:=chr(byteXor(ord(a),ord(b)));
end; { charXor }

 

[Ben Bacarisse]

You did? Gosh. You must be even more intelligent than Brian Kernighan.
Enlighten us mere mortals - how _did_ you solve the problems mentioned
in paragraph 4 of WPINMFPL?

Given
"""
I simply gave up trying to write the following trivial encryption
program in Pascal:

i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end

because I couldn't write a sensible 'xor' function.
"""
I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly
know the language at all. All it needs is addition and
equality test operators, and either modular reduction or an
odd() predicate (which I believe the languge does have).

The key here will be the word "sensible". Is your method "sensible"
in the context of that quote? I.e. sensible enough that the claim
being refuted (that Pascal is a good systems programming language) no
longer looks naive?

 

[Phil Carmody]

Phil Carmody wrote:
...

Given """
I simply gave up trying to write the following trivial encryption program in Pascal:

i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end

because I couldn't write a sensible 'xor' function. """
I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly know the
language at all. All it needs is addition and equality test
operators, and either modular reduction or an odd() predicate (which
I believe the languge does have).

That declaration would carry more weight if accompanied by actual
Pascal code for the xor function. I'm not saying whether it is or is
not possible - I don't remember enough about Pascal to judge.

I've never even known pascal, except to know enough that I never
wanted to learn any more.

Completely off the top of my head (or more, straight out of my arse):

function xor(a:integer;b:integer):integer;
var
bit : integer;
build : integer;
begin
bit:=1;
build:=0;
while a<>b do begin /* what's the <> operator in pascal? */
/* D'oh - what's the comment syntax? */
if odd(a)<>odd(b) then build:=build+bit;
bit:=bit+bit;
a:=a div 2;
b:=b div 2;
end;
xor:=build;
end;

Not even tested, for the obvious reason; E&EO, but the idea should
be bleedin' obvious.

Phil

 

[CBFalconer]

.... snip ...

I simply gave up trying to write the following trivial encryption
program in Pascal:

i := 1;
while getc(c) <> ENDFILE do begin
putc(xor(c, key));
i := i mod keylen + 1
end

because I couldn't write a sensible 'xor' function.

I hereby proclaim myself to be more intelligent than Brian
Kernighan. xor's trivial to write in Pascal, and I hardly know
the language at all. All it needs is addition and equality test
operators, and either modular reduction or an odd() predicate
(which I believe the languge does have).

That's not even Pascal. Try:

DO BEGIN
output^ := xor(input^, key); i := (i mod keylen) + 1;
put(output); get(input); END;
WHILE NOT eof(input);

(which you can't do in Borland/Turbo Pascal, because they don't
implement Pascal.) Note that the i/o rules are different from C.
Note that xor is a system function.

In C, you might try, with appropriate defines and #includes:

int ch;

while (EOF != (ch = getc(stdin))) {
ch ^= ((i mod keylen) + 1);
putc(ch);
}

 

[Harald van Dijk]

In C, you might try, with appropriate defines and #includes:

int ch;

while (EOF != (ch = getc(stdin))) {
ch ^= ((i mod keylen) + 1);
putc(ch);
}

Why did you rely on a custom mod macro, yet not on the standard xor_eq?

 

[CBFalconer]

Why did you rely on a custom mod macro, yet not on the standard
xor_eq?

Hunh? What macro? I don't understand.