The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: tfb@tfeb.org (Tim Bradshaw)
Subject: [TUHS] Comments on "C"
Date: Thu, 1 Sep 2016 22:47:15 +0100	[thread overview]
Message-ID: <267C9862-54F7-4A38-B59C-7FC59C7BD0F1@tfeb.org> (raw)
In-Reply-To: <20160901091746.1F3734422E@lignose.oclsc.org>

On 1 Sep 2016, at 10:17, Norman Wilson <norman at 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.


  parent reply	other threads:[~2016-09-01 21:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01  9:17 Norman Wilson
2016-09-01 15:11 ` Clem Cole
2016-09-01 21:47 ` Tim Bradshaw [this message]
2016-09-02  0:11   ` Mary Ann Horton
2016-09-02  7:10     ` Steve Simon
2016-09-02 10:02       ` Steve Nickolas
2016-09-02 14:13       ` Random832
2016-09-02 21:23 ` Dave Horsfall
2016-09-04 17:03   ` scj
2016-09-05 13:07     ` Ron Natalie
2016-09-04 22:24   ` Nemo
  -- strict thread matches above, loose matches on Subject: below --
2016-09-09  2:43 Doug McIlroy
2016-09-08 13:30 Noel Chiappa
2016-09-08 14:22 ` Tony Finch
2016-09-08 19:20   ` Ron Natalie
2016-09-08 22:06     ` Dave Horsfall
2016-09-09  3:02       ` Ronald Natalie
2016-09-09  6:06         ` Diomidis Spinellis
2016-09-09 21:15 ` Mary Ann Horton
2016-09-08 12:35 Doug McIlroy
2016-09-09 17:07 ` scj
2016-08-28 18:21 Dave Horsfall
2016-08-29  0:37 ` Marc Rochkind
2016-08-29  0:42   ` Larry McVoy
2016-08-29  1:54     ` Steve Nickolas
2016-09-08  1:19     ` Blake McBride
2016-08-29  3:16   ` Greg 'groggy' Lehey
2016-08-31 10:02     ` Tim Bradshaw
2016-08-31 12:59       ` John Cowan
2016-08-31 13:32         ` Ron Natalie
2016-08-31 14:37           ` John Cowan
2016-08-31 13:57   ` Brantley Coile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=267C9862-54F7-4A38-B59C-7FC59C7BD0F1@tfeb.org \
    --to=tfb@tfeb.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).