Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 12:34:05PM +0000, Guillaume Boucher via Digitalmars-d wrote:
[...]
> In modern C and with GLib (which makes use of a gcc/clang extension) you can
> write this as:
> 
> gboolean myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
>         /* Cleanup everything automatically at the end */
>         g_autoptr(GResource) resource1 = NULL, resource2 = NULL, resource3 =
> NULL;
>         gboolean ok;
> 
>         /* Vet arguments */
>         g_return_if_fail(blah != NULL, FALSE);
>         g_return_if_fail(bleh != NULL, FALSE);
>         g_return_if_fail(bluh != NULL, FALSE);
> 
> 	/* Acquire resources */
> 	ok = acquire_resource(resource1, blah->blah);
> 	g_return_if_fail(ok, FALSE);
> 
>         ok = acquire_resource(resource2, bleh->bleh);
> 	g_return_if_fail(ok, FALSE);
> 
> 	ok = acquire_resource(resource3, bluh->bluh);
> 	g_return_if_fail(ok, FALSE);
> 
>         /* Do actual work */
> 	ok = do_step1(blah, resource1);
> 	g_return_if_fail(ok, FALSE);
> 
> 	ok = do_step2(blah, resource1);
> 	g_return_if_fail(ok, FALSE);
> 
> 	return do_step3(blah, resource1);
> }
[...]

Yes, this would address the problem somewhat, but the problem is again,
this is programming by convention.  The language doesn't enforce that
you have to write code this way, and because it's not enforced,
*somebody* will ignore it and write things the Bad Ole Way.  You're
essentially writing in what amounts to a subdialect of C using Glib
idioms, and that's not a bad thing in and of itself. But the larger
language that includes all the old unsafe ways of writing code is still
readily accessible.  By Murphy's Law, somebody will eventually write
something that breaks the idiom and causes problems.

Also, because this way of writing code is not part of the language, the
compiler cannot verify that you're using the macros correctly.  And it
cannot verify that you didn't write goto labels or other things that
might conflict with the way the macros are implemented. Lack of hygiene
in C macros does not help in this respect.

I don't dispute that there are ways of writing correct (or mostly
correct) C code.  But the problem is that these ways of writing correct
C code are (1) non-obvious to someone not already in the know, and so
you will always have people who either don't know about them or aren't
sufficiently well-versed in them to use them effectively; and (2) not
statically enforceable because they are not a part of the language.
Lack of enforcement, in the long run, can only end in disaster, because
programming by convention does not work.  It works as long as the
convention is kept, but humans are fallible, and we all know how well
humans are at keeping conventions over a sustained period of time (or
even just short periods of time).

Not even D is perfect in this regard, but it has taken significant steps
in the right directions.  Correct-by-default (well, for the most part
anyway, barring compiler bugs / spec issues) and static guarantees
(verified by the compiler -- again barring compiler bugs) are major
steps forward.  Ultimately, I'm unsure how far a language can go at
static guarantees: I think somewhere along the line human error will
still be unpreventable because you start running into the halting
problem when verifying certain things. But I certainly think there's
still a LOT that can be done by the language between here and there,
much more than what we have today.


T

-- 
Mediocrity has been pushed to extremes.