Re: Definable operators

>>: John Levine (Our moderator)


>> [I think there actually has been a fair amount of work on these
>> issues, but it's languishing in the journals that discuss human
>> factors and the like. But it's a real trick to design a language that
>> will keep bad programmers from writing bad programs but won't keep
>> good programmers from writing good programs. On the other hand,
>> considering how many bad programmers there are, maybe we should forget
>> about the good programmers for a while. -John]


Oh, no! Not another paranoid design! "Fascist pig with a read-only
mind" is the only comment that your remark inspires.


I seldom agree with him, but Bertrand Meyer rightly said that the good
tool is the one that helps get the good things done, not the one that
prevents the bad things from being done.


Good programmers are a scarce resource enough so that they shouldn't
be prevented from doing their job by braindead restrictions. Bad
programmers well, should either get better or get another job; there
is no need for them at programming, and there are so many useful
things to do outside of programming that they will be more useful
elsewhere.


Of course, even good programmers need foolproofing features in
programming tools. But there's a whole lot of a difference between a
tool that allows you to express correctness and verify it, and a tool
that will restrict expressiveness in a stupid try to enforce
correctness without allowing to specify it.


To evaluate the complete invalidity of your argument, I invite you to
apply it to other things than programming.


Instead of preventing people from doing what they're good at, so that
they can do what they're bad at, you'd better encourage them to stop
doing do what they're bad at, and engage in activities they can be
good at.


Craig Burley <burley@tweedledumb.cygnus.com>
> This is a recently unfolding sentiment for me, personally. As
> recently as 10 years ago, and for most of my life before that, I would
> have probably rejected the notion that programming languages needed to
> be more simple to explain and use. Back then, I tended to think
> programming was for people who were willing to learn all the "rules"
> and apply them dogmatically.


Considering the scarcity of computer resources then, it was a
reasonable position. But computers have evolved, and good programming
has become much rarer than computer power, so that we should relieve
the programmers from the lower-level administratrivia, and let them
concentrate on clean, high-level, design, with languages optimized for
human understanding of the abstract semantics rather than computer
understanding of the operational semantics.


There's been a revolution in the balance of computer resources, and
computer software designers have still not understood it, while
Operating systems are still built on concepts that are completely
invalidated today.


> I think we might be about to witness a sea change, over the next 10
> years or so, that consists of a large-scale changeover from risky,
> program-to-the-bare-metal languages with $$ spent on tools to help
> programmers avoid misunderstanding their code, to safe,
> say-what-you-mean languages with $$ spent on compilers to make the
> resulting code run very fast. Once the big-$$ suits are given a clear
> choice between: a language where dropping or adding a single ";" can
> means $billions lost long after product deployment; versus a language
> where it's very difficult for common typos or thinkos to not be caught
> by the compiler (or even the editor); they might stop funding
> development of the former and fund development of the latter by
> purchasing compilers of languages that basically mandate array
> bounds-checking, interval arithmetic, and include the kinds of
> linguistic improvements I've been going on about.


Indeed. Again, that's the new balance I've been talking about: there
was a time when cycles were more expensive than programmer time. Now,
cycles are cheap, and more and more expensive stuff depends on it,
while the good programmers haven't been multiplied remotely as much.
Hence programming tools must get higher-level.


> After all, if a bit-banging programmer like me sees the writing
> on the wall, surely _something_ has to be going on out there! ;-)


Even if their replacement are not completely ready yet, we can already
count the days of languages like FORTRAN, COBOL, C, ADA, C++, JAVA,
and all that crap.


For more discussion on the subject, see the Tunes project page.
--
== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
--

Return to the comp.compilers page.
Search the comp.compilers archives again.