Re: Definable operators

Our moderator adds commentary to a post of mine:


> [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]


Excellent points.


I've lately been considering that perhaps there are no good
programmers or bad programmers. In a particular instance a person
might be doing good or bad programming, but it is probably not worth
extending that characterization to entire people for substantial
portions of their lives.


My general impression regarding C vs. Fortran, for example, is that C
programmers are considered "good" if they have command of the C
language and related tools, if they've memorized most or all of the
rules of C, if they rarely make mistakes at the level of writing C
code, and so on. It doesn't seem to matter much how well they
understand their problem domain, however -- a C programmer often is
considered "good" if he writes a lot of C code that compiles out of
the box, is portable, runs without crashing, has decent diagnostics,
and so on, even if the word- processing program he wrote is a mediocre
or even terrible example of a well-designed word processor.


Fortran programmers seem to be considered "good" if they have
excellent command of their problem domain, regardless of how clean or
elegant their code ends up being, or how many features of Fortran they
actually make use of. I've seen lots of Fortran code that, even
though not written in 1962, almost might as well have been -- it's
hard to read visually, it doesn't make good use of language features,
it's often not portable (or barely so), no clever programming-level
tricks are used -- but the programmer is considered "good" because the
program does a killer job of solving the _problem_, whether that be
solving linear equations, modeling fluid dynamics, or whatever.


Perhaps the above overstates the issue, but the point is that maybe we
should start thinking hard about designing languages so that people
don't need to be "good programmers" in the C sense of memorizing
obscure linguistic tricks, cleverly using language features, and so
on, so they can instead focus more of their attention on being "good
programmers" in the Fortran sense of actually understanding their
problem domain.


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.


But I've come to realize I'd rather have the people who wrote the code
to control the cockpit instrumentation being used by the pilots of the
plane I'm on be able to focus more of their time and thought on
understanding man/machine interaction, flight, instrumentation,
aerodynamics, and so on, and less of it on obscure formal-language
rules such as whether + means addition in a particular context and
whether maybe it would be neat if they could re-use + to mean
something entirely different under some circumstances, because of the
syntactic convenience such overloading might offer them.


And I've decided that, of all of the clever compiler (and code-
development) tricks we come up with, I'd rather see most of them turn
clean, self-evident code written in a language where it's very hard
(and considered simply "wrong" even if the compiler accepts it) to
write code that looks like it says one thing but, upon detailed
examination (such as parsing and analyzing the entire source file),
turns out to do another...


...instead of using most of those tricks to help people figure out
what the code they're looking out is really saying. (E.g. fancy
editors that visually distinguish C reserved words vs. types vs.
macros, overloaded C++ operators, and so on.)


For example, I'd rather see numerical programming done in a language
without anything like Fortran's EQUIVALENCE, and the development $$
spent on making compilers recognize where and when they can re-use
memory or do faster type conversions or I/O, instead of encouraging
programmers to use EQUIVALENCE and spending that development $$
building editors that help programmers visualize what the code they're
looking at actually means, e.g. such as "no, you don't have to worry
that `A = ...' modifies `B' because they're EQUIVALENCEd, because I've
proved they aren't".


Even what might turn out to be baby steps towards in this direction
are encouraging -- e.g. there are subsets of Fortran 90 (called F and,
I think, ELF90) that each eliminates lots of the "risky" stuff so
programmers can't so easily shoot themselves in the foot. I don't
think compilers for them do a better job of generating optimized code
for them than compilers of full F90 do of the same code, but there do
seem to be fans of these languages. (Perhaps because the
implementations are less expensive than full-F90 ones.) What if
compiler-optimization specialists decided they'd rather spend their
time making code written in well-designed languages faster -- if F
compilers, for example, started beating out equivalent F90 compilers,
especially when the F90 code used the "unsafe" stuff to "run fast" and
the F code didn't (and thus stayed clean) -- could something big start
happening?


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.


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


James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
--

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