1 Sep
2016
1 Sep
'16
9:17 a.m.
Every time someone starts spouting about how unsafe
C is, and how all the world's problems would be solved
if only people would stop using it, I think of Flon's
Axiom, for 35 years my favourite one-liner about
programming and languages:
There does not now, nor will there ever, exist a
programming language in which it is the least bit
hard to write bad programs.
Flon's Axiom comes from a short note On Research
in Structured Programming, published in SIGPLAN
Notices in October 1975. It's just as true today.
Over the years I've seen people misinterpret the
Axiom as an argument against looking for better
programming languages at all, but that's not what
it means. (Read the original note--it's a page
and a half--for full context; it is, alas, behind
ACM's Digital Library paywall.) There are certainly
languages that make certain sorts of mistakes easier
or harder, or are easier or harder to read, but in
the end most of that really is up to the programmer.
Programming well requires a lot of thought and care
and careful rereading, and often throwing half the
code out and re-doing it better, and until we can
have a programming community the majority of whom
are up to those challenges, we will continue to have
crashes and security vulnerabilities and other
embarrassing bugs aplenty, no matter what language
is used.
Norman Wilson
Toronto ON
1 Sep
1 Sep
3:11 p.m.
New subject: Comments on "C"
On Thu, Sep 1, 2016 at 5:17 AM, Norman Wilson <norman(a)oclsc.org> wrote:
Flon's Axiom comes from a short note On Research
in Structured Programming, published in SIGPLAN
Notices in October 1975. It's just as true today.
+1 (a few times) - His axiom is also one of my favorites. Flon was
brilliant and funny.
Page 16 and 17. Scanned from my copy and ocred - fair use declared ;-)
Its interesting... FORTRAN still pays my salary ;-)
It's not banks & insurance company programmers. It's the physicist,
chemists et al running on my supercomputer that still use it.
But as Flon says, I see just as many bad Java, javascript, Python programs.
========== Sigplan Notices October 1975 -- pages 16 and part of 17.
On Research in Structured Programming
Lawrence Flon
Department of Computer Science
Carnegie-Mellon University
Pittsburgh, PA 15213
The August issue of SIGPLAN Notices contained a rather interesting
collection of material. Not suprisingly, I was struck with some humor at
first upon noticing the rather glaring connection between Karp's letter on
the one hand and examples of each of his objections on the other. The issue
presented, in addition, a lampoon of what has become a somewhat limited,
syntax for titles of structured programming articles, followed by yet
another member of that very class. My mirth, unfortunately, did not last
long when I began to wonder about whether the whole thing was at all
funny. There has been a forum going on for quite some time in an effort to
define structured programming. A number of articles have been written in
the style of Dijkstra's original goto letter in an attempt to banish
particular language constructs. Counter-articles have been written
defending these constructs. I would like to present a statement which has
needed presenting for a while. I like to regard it as an axiom because I
firmly believe both in the statement itself and the hopelessness of trying
to prove it.
*Axiom*
*There does not now, nor will there ever, exist a programming language in
which it is the least bit hard to write bad programs. *
Not only is it possible to misuse goto's, global variables, and
conditionals, but the possibilities for misuse of block structure,
procedures, macros, pointers, and everything else are endless. Too many
textually nested blocks can make an ALGOL program hopelessly unreadable, as
can procedures or macros with too many parameters. A set of procedures
whose functions are badly partitioned are not only difficult to understand
but hard to modify. Syntax macros which do not themselves parse to
non-terminal or terminal symbols (e.g. those with unbalanced parentheses or
begin-end pairs) are prone to causing hard-to-find syntax errors.
Unrestricted pointers (as in PL/I) cause a proclivity of disastrous bugs.
These are the seeds for at least four more "considered harmful" papers
which I will not write and hope no one else does.
I would like to see the S.P. forum re-directed towards a less hopeless task
than finding the perfect programming language or formally defining S.P.
itself. If we take the definition to be simply the construction of
efficient, readable, understandable, modifiable, and verifiable programs,
we can then begin to discuss ways to *globally* reach these goals by
*educating* the people who do the programming. Since it follows from the
axiom that no amount of construct-clipping will make the typical graduate
of a "data processing" school even a potentially good programmer, we must
find something that will: What can be said to be the *proper* use of
goto's, conditionals, and global variables (and block structure, pointers,
etc.)? What are the general guidelines to follow with respect to
procedures? How does one go about modularizing a task, anyway?
Answering these questions and so many more is what structured programming
research should be about. What good is debating the if-then-else construct
when half the world is programming in (and will continue to program in)
FORTRAN? Let us see articles on the-way-to-do-it-right in *any* language;
articles which programming managers can show their programmers which will
improve the quality of software where it is most needed - not in
universities and research centers, but in banks and insurance companies.
9:47 p.m.
New subject: Comments on "C"
On 1 Sep 2016, at 10:17, Norman Wilson <norman(a)oclsc.org> wrote:
Flon's
Axiom, for 35 years my favourite one-liner about
programming and languages:
There does not now, nor will there ever, exist a
programming language in which it is the least bit
hard to write bad programs.
I think this is almost trivially true (in the same sense that, say, general relativity is
almost trivially true once you see it): if there are complicated problems to solve, then
programming languages are either powerful enough to represent the solution or they
can't solve the problem. If they are powerful enough then that power can be used to
write horrid programs, if they're not then they die out, at least as general-purpose
languages.
To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps
(really, Scheme) mandate tail-call elimination as part of the language, which is clearly
this lovely pure thing to do which can only make programs better. Well, in a language
with tail-call elimination, some (but, of course, not all) function calls can be treated
as gotos which pass arguments, and isn't goto meant to be bad? So now add full
continuations and any half-educated person like me can write the sort of tiny opaque
horror which it would take someone really deep understanding to write in C, say.
That being said (and note I *like* C, a lot), what proportion of security problems are
undetected buffer overflows? Less than it used to be, I hope.
2 Sep
2 Sep
12:11 a.m.
New subject: Comments on "C"
Of course it's possible to write terrible programs in powerful languages!
How else could we have the wonders of the International Obfuscated C
Code Contest?
On 09/01/2016 02:47 PM, Tim Bradshaw wrote:
On 1 Sep 2016, at 10:17, Norman Wilson
<norman(a)oclsc.org> wrote:
Flon's
Axiom, for 35 years my favourite one-liner about
programming and languages:
There does not now, nor will there ever, exist a
programming language in which it is the least bit
hard to write bad programs.
I think this is almost trivially true (in the same
sense that, say, general relativity is almost trivially true once you see it): if there
are complicated problems to solve, then programming languages are either powerful enough
to represent the solution or they can't solve the problem. If they are powerful
enough then that power can be used to write horrid programs, if they're not then they
die out, at least as general-purpose languages.
To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps
(really, Scheme) mandate tail-call elimination as part of the language, which is clearly
this lovely pure thing to do which can only make programs better. Well, in a language
with tail-call elimination, some (but, of course, not all) function calls can be treated
as gotos which pass arguments, and isn't goto meant to be bad? So now add full
continuations and any half-educated person like me can write the sort of tiny opaque
horror which it would take someone really deep understanding to write in C, say.
That being said (and note I *like* C, a lot), what proportion of security problems are
undetected buffer overflows? Less than it used to be, I hope. 
7:10 a.m.
New subject: Comments on "C"
I find this a very interesting conversation.
my bugbear is languages and tools that help you do the the easy stuff, IDEs that
suggest arguments for the read() function, syntax highlighting that show which text
comments etc.
this is not stuff I find hard, it helps me with the easy stuff! working out what to write
- I.e. reading and digesting chip data sheets and protocol specs, that is what I need help
with and there is no royal road to this.
I have long felt that solving complex problems requires complex code, but a well designed
program can spread a little of this complexity as a thinner layer rather than having a
great clump of it in one place. some languages can encourage this practice - OO is the
obvious example of this, but it is not a requirement. I still remember the versatec
printer driver written in beautiful FORTRAN 4 (yes it can be done).
-Steve
-Steve
On 2 Sep 2016, at 01:11, Mary Ann Horton
<mah(a)mhorton.net> wrote:
Of course it's possible to write terrible programs in powerful languages!
How else could we have the wonders of the International Obfuscated C Code Contest?
> On 09/01/2016 02:47 PM, Tim Bradshaw wrote:
>> On 1 Sep 2016, at 10:17, Norman Wilson <norman(a)oclsc.org> wrote:
>>
>> Flon's
>> Axiom, for 35 years my favourite one-liner about
>> programming and languages:
>>
>> There does not now, nor will there ever, exist a
>> programming language in which it is the least bit
>> hard to write bad programs.
> I think this is almost trivially true (in the same sense that, say, general
relativity is almost trivially true once you see it): if there are complicated problems to
solve, then programming languages are either powerful enough to represent the solution or
they can't solve the problem. If they are powerful enough then that power can be
used to write horrid programs, if they're not then they die out, at least as
general-purpose languages.
>
> To turn my earlier comment around, Lisp is a fantastic example of this: modern Lisps
(really, Scheme) mandate tail-call elimination as part of the language, which is clearly
this lovely pure thing to do which can only make programs better. Well, in a language
with tail-call elimination, some (but, of course, not all) function calls can be treated
as gotos which pass arguments, and isn't goto meant to be bad? So now add full
continuations and any half-educated person like me can write the sort of tiny opaque
horror which it would take someone really deep understanding to write in C, say.
>
> That being said (and note I *like* C, a lot), what proportion of security problems
are undetected buffer overflows? Less than it used to be, I hope.
10:02 a.m.
New subject: Comments on "C"
My language of choice is C, and has been for a decade and a half.
I write some really FUGLY C code when I need to get down and dirty, like
in my emulators - though they're not OO by a longshot, they're written as
sort-of modular, one of them has an emulation of a 6847/6883 which is
implemented in clearly marked functions, but the functions are terribly
coded. Comments are sparse, and usually only mark where I needed to
actually think about what I was doing.
I implemented a couple Unix commands as part of a never-finished project -
I wanted to write a userland for a Unix clone, where the utilities could
also run on MS-DOS.
(...something like "Does DOS have the Unix nature?" "Mu!" comes to
mind...)
-uso.
2:13 p.m.
New subject: Comments on "C"
On Fri, Sep 2, 2016, at 03:10, Steve Simon wrote:
I find this a very interesting conversation.
my bugbear is languages and tools that help you do the the easy stuff,
IDEs that suggest arguments for the read() function, syntax
highlighting that show which text comments etc.
this is not stuff I find hard, it helps me with the easy stuff!
Sure, but help with the easy [and medium - not every function's
signature is as simple as read()] stuff helps you not break your
concentration to go look at documentation if you're not 100% sure you
remember the signature correctly, so you can use your brain more
efficiently for the hard stuff.
I use a Java IDE that will, with a single command, generate a
declaration corresponding to the type of an expression I just assigned
to an undeclared variable. This saves typing [in the easy cases] and it
saves thinking about return types [in the medium cases].
9:23 p.m.
New subject: Comments on "C"
On Thu, 1 Sep 2016, Norman Wilson wrote:
Programming well requires a lot of thought and care
and careful
rereading, and often throwing half the code out and re-doing it better,
and until we can have a programming community the majority of whom are
up to those challenges, we will continue to have crashes and security
vulnerabilities and other embarrassing bugs aplenty, no matter what
language is used.
I think I saw that in CACM: "Prepare to throw out half your code, because
you will anyway".
Then there was the time I saw a Uni student, when, ambling down the
corridor at UNSW Comp Sci, he tripped and spilled the entire deck of
cards; after laughing for a while, I helped him to put them through the
reader-sorter (fortunately, they were sequenced, I think).
When I think back on some of the code I wrote, I still shudder... Mind
you, this was back in the days of the IBM-360 and the PDP-11, and I'd only
just graduated, m'lud.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
4 Sep
4 Sep
5:03 p.m.
New subject: Comments on "C"
Before I headed off to my first summer job, my mother, who was working as
a programmer, gave me some good advice: "before you throw away a deck of
cards, put a rubber band around it...". Saved my butt twice that
summer...
Incidentally, I figured the other day that a Petabyte of data, if punched
onto punched cards, would make a deck that was 6 times higher than the
distance to the moon...
Steve
On Thu, 1 Sep 2016, Norman Wilson wrote:
Programming well requires a lot of thought and
care and careful
rereading, and often throwing half the code out and re-doing it better,
and until we can have a programming community the majority of whom are
up to those challenges, we will continue to have crashes and security
vulnerabilities and other embarrassing bugs aplenty, no matter what
language is used.
I think I saw that in CACM: "Prepare to throw out half your code, because
you will anyway".
Then there was the time I saw a Uni student, when, ambling down the
corridor at UNSW Comp Sci, he tripped and spilled the entire deck of
cards; after laughing for a while, I helped him to put them through the
reader-sorter (fortunately, they were sequenced, I think).
When I think back on some of the code I wrote, I still shudder... Mind
you, this was back in the days of the IBM-360 and the PDP-11, and I'd only
just graduated, m'lud.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
5 Sep
5 Sep
1:07 p.m.
New subject: Comments on "C"
Many of us who got started early learned that the value of nothing was p&P6.
You can write bad (I'm not going to even to begin with sustainable) code in
any language.
C's biggest defect was it dates from an era where people didn't much care.
Type 120 characters into a field expecting 10, well you deserved what you
got.
It was more the issue with C's utility functions than with the language
itself. Most of that has been cleaned up.
One piece of aracane programming did come in handy later on. Our
highschool didn't have any computers. Your choices were to call the
timeshare system across the county using the Bell 103 Dataphones or punch
your cards and send them down to the county seat to run on the 370 mainframe
(me and a friend were writing a computer dating program in COBOL until
someone at the County looked at our printouts and caught what we were up to.
Still we'd joke each other by inserting random JCL commands like //OPTIONS
ASSHOLE into each other's deck. With a two day turnaround time, that was
painful).
What we did have is a bunch of old IBM card processing machines: 401
accounting machine, 514 reproducing punch, 085 colator, 082 sorter. On
the shelf in that room was a bunch of self-paced training manuals on how to
program these units via large punchboards full of wires. Being a geek, I
went through these (the 402/514 was an interesting combination, it had the
ability via a big 12x80 pin plug to punch the output of calculations on
cards).
Anyway, years later I was sitting around a university computer center and
these guys came in with a problem. They had a whole deck of IBM cards
that had patent information on them. What was neat about these cards is
that in addition to the punched information, there was a window in the card
with a small piece of microfilm with some imagers on it. The problem is
that all the card readers they tried to read this deck in would spaz when
the optical sensor hit the microfilm part. No problem. Give me the
columns you're interested in and I set about programming the 402 to print
out what they were interested in knowing. I believe it was the only
useful thing I ever did with that machine.
4 Sep
4 Sep
10:24 p.m.
New subject: Comments on "C"
On 2 September 2016 at 17:23, Dave Horsfall <dave(a)horsfall.org> wrote:
[...]
I think I saw that in CACM: "Prepare to throw out
half your code, because
you will anyway".
There is Brook's law: Plan to throw one away, you will anyways [MMM
Chapt. 11]. (There is also Writh's advice not to be afraid of tossing
it and starting again) but I do'nt recall the 50% rule.
2789
days inactive
2793
days old
10 comments
11 participants
participants (11)
-
Clem Cole -
Dave Horsfall -
Mary Ann Horton -
Nemo -
norman＠oclsc.org -
Random832 -
Ron Natalie -
scj＠yaccman.com -
Steve Nickolas -
Steve Simon -
Tim Bradshaw