Talk on what a systems programming language needs to replace C

[Russel Winder]

On Thu, 2019-09-05 at 14:29 -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Sep 05, 2019 at 01:50:03PM -0700, Walter Bright via Digitalmars-d
> wrote:
> > On 9/5/2019 3:06 AM, Russel Winder wrote:
> [...]
> > > The lesson from Groovy was to actively avoid doing stupid things and
> > > to trust programmers not to f### things up. Which they didn't.
> 
> Sorry to say, having worked in the industry for a few decades, I have
> exactly the opposite sentiment.  Perhaps things aren't that way where
> you are, and that's good for you.  Where I am, the worst possible code
> gets written because the language allowed it, and it falls upon my
> shoulders to fix the inscrutable problems therein long after the
> original author has moved on to greener pastures.  "Trust the
> programmer" is an attitude I used to subscribe to, but these days it
> leaves a bitter taste in my mouth.

I too have worked in the industry for decades, perhaps I just employed good
programmers as opposed to crap ones. There is clearly a distribution of
ability (a truly complicated concept I agree) as programmers amongst
programmers and to be honest most people below the median are really not very
good at all. Many can and do get better, far too many just take the money and
ignore any notion of personal or organisational betterment.

For the best programmers programming language features are enabling. For the
worst programmers the constraints and dictats of programming languages rarely
stop them creating truly crap code.

If you cannot trust your programmers then change the programmers or close the
organisation.

> 
> > All programmers agree with this sentiment, and create a hellish mess
> > anyway.
> [...]
> 
> Yep.  Especially when there's a deadline and the customer is being
> unreasonable, and your job is on the line, then anything goes.
> Unreadable hacks using C macros?  Sure, if it gets the job done before
> you're fired.  Operator overload abuse? Sure, if it gets the job done
> before you're fired.  Inscrutable pointer casting hacks?  Oh yes, if it
> gets the product shipped by the deadline.  Making things easier for the
> poor sod who'll be maintaining your code a decade later?  That's not
> even a consideration when the deadline is looming, the customer is
> demanding, and the project manager is angry.

Isn't this really a description of a crap organisation using crap programmers?

If this is the way software industry is always going to behave maybe the whole
thing should be culled and restarted.

> Some things should not be allowed by the language, or at least should be
> harder to do compared to the "right" way. The incentives need to be
> right. Free-for-all usually means lowest common denominator, and believe
> me, when it comes to average code quality in your typical "enterprise"
> code, that denominator is low indeed.

Clearly the building of abstractions inherently means some restriction on what
can be done with the machine. Programming language enshrine this, along with
the prejudices of the language developer. The question is all to often are the
prejudices of the language designer copeable with by programmers or will they
choose another language. Lack of operator overloading in D as is present in
C++ and Python still irritates me (it constrains making nice abstraction,
which are internal DSLs) but clearly the operator creation of Algol68 and
Scala clearly leads to incomprehensible babble very quickly given the way the
official examples suggest using it. 

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190907/18390fbc/attachment.sig>