C is not a low level language

In message , Eric Stevens
writes:
[]
C is a write-only language. :-)

Like all programming languages, it is possible to write something that's
indescribably elegant, and pleasing to the eye - but, as another has
said, virtually impossible to understand how it works when you come back
to it after a while.

(I remember seeing a line of BASIC - I think it was NASCOM BASIC or
similar - that achieved decimal to Roman numerals conversion in one
[albeit long] line. [Actually, partly by the nature of BASIC, that _was_
understandable.])

As another has said, _commenting_ is important - certainly for anything
collaborative, but even for yourself if you intend to come back to the
code after even a relatively short time. I'd disagree that the comment
should show what it's supposed to do rather than how it does it: if the
latter is in any way obscure (including clever), it should explain that
_as well_.

Advice (and manuals, and sometimes even company procedures) often
recommend)s( a ratio of comment to code; whatever ratio is recommended,
of course, few of us follow that, and _usually_ without problem. It
_can_ be argued that well-written code is its own comment, and that can
_sometimes_ be the case - though efficient C does lend itself to
impenetrability. Also, the arguments about whether the compiler can
match the coder for efficiency will go on for ever, too. (Certainly I
used to think I could do better than any compiler, but that was decades
ago - though what I've seen recently of automatically-generated HTML has
certainly not impressed me.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"The wish of the lazy to allow unsupervised access [to the internet] to their
children should not reduce all adults browsing to the level of suitability for a
five-year-old." Yaman Akdeniz, quoted in Inter//face (The Times, 1999-2-10): p12

"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

"Mayayana" on Sun, 24 Feb 2019 08:51:59
-0500 typed in alt.windows7.general the following:
"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

And then there is obfuscated code.

--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

In message , pyotr
filipivich writes:
"Mayayana" on Sun, 24 Feb 2019 08:51:59
-0500 typed in alt.windows7.general the following:
"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

That _can_ depend on the compiler; less-good ones may produce more steps
for more readable code.

And then there is obfuscated code.

Deliberately so, you mean? I thought that was usually done by not giving
access to the source code.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

You cannot simply assume someone is honest just because they are not an MP.

"J. P. Gilliver (John)" wrote

| And then there is obfuscated code.
|
| Deliberately so, you mean? I thought that was usually done by not giving
| access to the source code.

I wondered about that, too. Though it is common
these days for javascript to be obfuscated and
deliberately complicated. Or it's pseudo-encrypted
by doing things like including a string of byte values
or Base64 in the script which is then reconstituted
to the original.

It also gets "minified",
allegedly for compactness, but I think it's really
for obfuscation. When you're pulling in 2 MB of
javascript to do a simple task in a webpage,
minifying is hardly relevant.

"J. P. Gilliver (John)" on Sun, 24 Feb 2019
15:35:10 +0000 typed in alt.windows7.general the following:
In message , pyotr
filipivich writes:
"Mayayana" on Sun, 24 Feb 2019 08:51:59
-0500 typed in alt.windows7.general the following:
"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

That _can_ depend on the compiler; less-good ones may produce more steps
for more readable code.

And then there is obfuscated code.

Deliberately so, you mean? I thought that was usually done by not giving
access to the source code.

There used to be an "Obfuscated Code" competition, where the idea
was to write code so convoluted, that reading it was between really
difficult and "Are you sure we're not going to summon one of the Elder
gods doing this?" I recall one where the code listing looked like the
letter Pi. But it compiled. Output was the value of Pi to some large
number of places.

I understand that back when memory was on a drum, legendary
Programmers of Yore, would include the physical characteristic of the
drum in their coding, so that rather than wait for the memory location
to come round, it would read the memory location under the head,
because the next instruction had been calculated to be there. But
reading said code was very difficult unless you too were intimately
familiar with the engineering of the memory system.

There were Giants in those days. Also complete wackos.

tschus
pyotr
--
APL is a mistake, carried through to perfection. It is the language of the
future for the programming techniques of the past: it creates a new generation
of coding bums.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

pyotr filipivich writes:
[...]
There used to be an "Obfuscated Code" competition, where the idea
was to write code so convoluted, that reading it was between really
difficult and "Are you sure we're not going to summon one of the Elder
gods doing this?"

There still is. https://ioccc.org/

I recall one where the code listing looked like the
letter Pi. But it compiled. Output was the value of Pi to some large
number of places.

Here's the program, from the 1989 contest:

https://ioccc.org/1989/roemer.c

That's not quite what it does, but I don't want to spoil it.

(It seg faults when I compile it with gcc or clang, but it runs when I
compile it with tcc.)

[...]

(followups to comp.lang.c only.)

--
Keith Thompson (The_Other_Keith) http://www.ghoti.net/~kst
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

pyotr filipivich writes:
[...]
There used to be an "Obfuscated Code" competition, where the idea
was to write code so convoluted, that reading it was between really
difficult and "Are you sure we're not going to summon one of the Elder
gods doing this?"

There still is. https://ioccc.org/

I recall one where the code listing looked like the
letter Pi. But it compiled. Output was the value of Pi to some large
number of places.

Here's the program, from the 1989 contest:

https://ioccc.org/1989/roemer.c

That's not quite what it does, but I don't want to spoil it.

(It seg faults when I compile it with gcc or clang, but it runs when I
compile it with tcc.)

[...]

(followups to comp.lang.c only.)

--
Keith Thompson (The_Other_Keith) http://www.ghoti.net/~kst
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

"J. P. Gilliver (John)" on Sun, 24 Feb 2019
15:35:10 +0000 typed in alt.windows7.general the following:
In message , pyotr
filipivich writes:
"Mayayana" on Sun, 24 Feb 2019 08:51:59
-0500 typed in alt.windows7.general the following:
"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

That _can_ depend on the compiler; less-good ones may produce more steps
for more readable code.

And then there is obfuscated code.

Deliberately so, you mean? I thought that was usually done by not giving
access to the source code.

There used to be an "Obfuscated Code" competition, where the idea
was to write code so convoluted, that reading it was between really
difficult and "Are you sure we're not going to summon one of the Elder
gods doing this?" I recall one where the code listing looked like the
letter Pi. But it compiled. Output was the value of Pi to some large
number of places.

I understand that back when memory was on a drum, legendary
Programmers of Yore, would include the physical characteristic of the
drum in their coding, so that rather than wait for the memory location
to come round, it would read the memory location under the head,
because the next instruction had been calculated to be there. But
reading said code was very difficult unless you too were intimately
familiar with the engineering of the memory system.

There were Giants in those days. Also complete wackos.

tschus
pyotr
--
APL is a mistake, carried through to perfection. It is the language of the
future for the programming techniques of the past: it creates a new generation
of coding bums.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

On Sun, 24 Feb 2019 08:51:59 -0500, "Mayayana"
wrote:

"J. P. Gilliver (John)" wrote

| Like all programming languages, it is possible to write something that's
| indescribably elegant, and pleasing to the eye - but, as another has
| said, virtually impossible to understand how it works when you come back
| to it after a while.

That's a pet peeve of mine. People who think it's
clever to shrink multiple steps into one. They sacrifice
readability based on a misconception -- the notion
that terse code is efficient code.

Or the notion that the code will never change.

I usually deliberately write code to be be maintainable. If it
is a bit slower, it usually does not matter (to me or mine). However,
it could change, maybe years later, and I may have to change it
quickly.

With the overoptimised one-liners, I usually have to unblock the
code to be able to implement the change. A waste of time.

Sincerely,

Gene Wirchenko

"J. P. Gilliver (John)" on Sun, 24 Feb 2019
11:22:20 +0000 typed in alt.windows7.general the following:

Advice (and manuals, and sometimes even company procedures) often
recommend)s( a ratio of comment to code; whatever ratio is recommended,
of course, few of us follow that, and _usually_ without problem. It
_can_ be argued that well-written code is its own comment, and that can
_sometimes_ be the case - though efficient C does lend itself to
impenetrability. Also, the arguments about whether the compiler can
match the coder for efficiency will go on for ever, too. (Certainly I
used to think I could do better than any compiler, but that was decades
ago - though what I've seen recently of automatically-generated HTML has
certainly not impressed me.)

There used to be code optimizers, but now I think were seeing the
use of more code pessimizers.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?