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

"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

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

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 */

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

In message , Wolf K
writes:
[]
FTR, I took an IBM assembler about 40 years ago. Can still read maybe
20% of an assembler printout, but couldn't code my way out of paper
bag. But by the end of the course, I could write 15-20 lines without a
bug. The instructor said this was pretty good.

About ten years ago, I was startled, speaking to a new graduate with a
computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER.
Thinking about it afterwards, I decided that the computing world is
certainly big enough that he'd have no difficulty in finding employment,
but it did throw me at the time; I'd come up through (7-bit serial then)
8-bit, 6800 and 6502, then in professional life some work in bit-slice
processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we
had to _create_ our assembly tools as we assembled our processors.

Maybe nowadays assembler is _rare_?
--
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 in message
...
In message , Wolf K
writes:
[]
FTR, I took an IBM assembler about 40 years ago. Can still read maybe 20%
of an assembler printout, but couldn't code my way out of paper bag. But
by the end of the course, I could write 15-20 lines without a bug. The
instructor said this was pretty good.

About ten years ago, I was startled, speaking to a new graduate with a
computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER.
Thinking about it afterwards, I decided that the computing world is
certainly big enough that he'd have no difficulty in finding employment,
but it did throw me at the time; I'd come up through (7-bit serial then)
8-bit, 6800 and 6502, then in professional life some work in bit-slice
processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we
had to _create_ our assembly tools as we assembled our processors.

Maybe nowadays assembler is _rare_?

When I was at university, doing electronic engineering, in the early 1980s,
we did a bit of assembler programming, in 6809. Everyone was very frustrated
at the choice of CPU because those who had their own computer had either a
CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a
6809 that they could practice on out of hours. Of course, a few years later,
8086 and its successors (386, 486 etc) would have been fairly universal ;-)
Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors.

I remember as a project we had to write software which allowed serial data
to be written to a tape and to be read from it, and I don't think anyone go
their equipment working: as a project it was a bit too advanced for the
amount of practical time allocated to it.

I *think* the high-level language we were taught was Pascal. Certainly we
didn't learn C because I remember having to learn that from scratch when I
started my first job.

As a little exercise I managed to code a bubble sort in Z80 on my Wren CP/M
3 computer in the mid 80s. I wrote a BASIC program which allowed a user to
enter intergers into an array, then passed the address of that array to a
Z80 sort routine and then returned control to the BASIC program to print it
out. Developing it was fairly thankless because any mistake in the Z80
crashed the computer, requiring it to be rebooted (from floppy). But I got
it working. I forget the actual timings, but I know that the Z80 routine was
several orders of magnitude faster than the same algorithm in interpreted
BASIC and several times faster than a compiled Pascal program with the same
algorithm.

I would imagine that the ability to write assembler for any given CPU is
nowadays fairly specialised and only done for specific routines that need
the absolute maximum speed.

On 25/02/2019 16:19, Wolf K wrote:
On 2019-02-25 09:53, J. P. Gilliver (John) wrote:
In message , Wolf K
writes:
[]
FTR, I took an IBM assembler about 40 years ago. Can still read maybe
20% of an assembler printout, but couldn't code my way out of paper
bag. But by the end of the course, I could write 15-20 lines without
a bug. The instructor said this was pretty good.

About ten years ago, I was startled, speaking to a new graduate with a
computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER.
Thinking about it afterwards, I decided that the computing world is
certainly big enough that he'd have no difficulty in finding
employment, but it did throw me at the time; I'd come up through
(7-bit serial then) 8-bit, 6800 and 6502, then in professional life
some work in bit-slice processors (AMD 2901, 2960, etc., and the IDT
copies thereof), where we had to _create_ our assembly tools as we
assembled our processors.

Maybe nowadays assembler is _rare_?

I think human-created assembler is becoming rare. However, I have the
impression that robotics requires machine-coded assembler, translated
from whatever human-readable language was used to program the machine.
Those neat videos of dog=like robots loping through the building are
misleading. Their abilities are not only severely limited, but those
abilities were programmed on large machines cabled to the robot. The
programs were tweaked and compressed before being copied to the on-board
chips that control the "dog".

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.

I think it is good for programmers to have some experience of assembly,
and to have understanding of it - it helps give a better appreciation of
how things work underneath, and can lead to the programmer writing
better high-level code (especially on smaller systems). But that is
different from actually writing assembly for real work.


Maybe someone from MIT or Boston Dynamics can clarify and correct.

In article , J. P. Gilliver (John)
wrote:

About ten years ago, I was startled, speaking to a new graduate with a
computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER.

why is that surprising?

there's no need to write assembly anymore, with very, very rare
exception, such as writing a compiler.

Thinking about it afterwards, I decided that the computing world is
certainly big enough that he'd have no difficulty in finding employment,
but it did throw me at the time; I'd come up through (7-bit serial then)
8-bit, 6800 and 6502, then in professional life some work in bit-slice
processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we
had to _create_ our assembly tools as we assembled our processors.

things are very, very, very different since then. extremely so.

Maybe nowadays assembler is _rare_?

yes. almost nonexistent. see above for compiler.