2 Sep
2016
2 Sep
'16
1:10 p.m.
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.