[TUHS] Comments on "C"

[Steve Simon]

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 at 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 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.