OT: Programming languages (was Re: Open Source Quality)

From: Edward Cherlin <edward_dot_cherlin_at_etssg_dot_com>
Date: Tue May 11 2004 - 02:35:06 CDT

On Monday 10 May 2004 18:33, Douglas W. Jones wrote:
> On May 10, 2004, at 5:19 PM, Edward Cherlin wrote:
Quoting myself in full here, because Doug left out this bit
On Sunday 09 May 2004 11:58, Douglas W. Jones wrote:
> On May 9, 2004, at 12:49 PM, David Mertz wrote:
> >> The presence of these errors argues (minimally) for
> >> garbage-collected languages and fulltime array bounds
> >> checking to help a sloppy programmer detect these problems.
> >
> > I.e. Python is the *right* language to write OVC's reference
> > in.
> Well, the same could be said for Java, LISP, Simula 67 and a
> number of other languages. This merely demonstrates that
> Python is a member of a class of relatively safer languages.
> > APL, also.

I said only that APL is relatively safe. It is garbage-collected
and type-safe. That doesn't make it the ideal language for OVC,
any more than Java, LISP, Simula 67 or the others in this class.

> I would argue that our criteria are not strong enough
> if we claim that APL is an adequate language for this
> job.
> APL turns out to be a spectacularly useful language for
> "throw away programming", where, once written, programs
> are used once and discarded.

APL turns out to be a spectacularly useful language for financial
analysis, actuarial work, statistics, engineering, robot
control, writing computer descriptions, verification of
correctness of software, and a lot more.

> APL programs are notoriously hard to follow by those
> who didn't write them, or by those who did, but more than
> an hour ago.

I find APL much easier to read than C++, since the APL syntax is
vastly simpler, and also because I was trained as a
mathematician, so I understand what APL's powerful functions do.
Other languages require far more effort to understand far less
powerful facilities.

But this is not the place for an r-war. You can come over to
comp.lang.apl if you like and we'll give you an education.

> There may be disciplined programming models for APL, but
> like disciplined programming models for other languages,
> experienced programmers tend to bend the model, until
> only the original author can understand the code.

Mere rumor. The cleanest code I have ever seen is Roger Hui's
published C implementation of J, Iverson's latest version of
APL. Hui used the C preprocessor to allow him to write APL-style
code in C.

Programmers who don't understand algorithms, data structures, or
problem factoring write garbage code in any language.

> In sum, I believe we should not encourage the use of
> any language where valid programs strongly resemble
> line noise or compressed files viewed as text.
> > Another issue is choosing a language that is simple enough
> > so that the implementation can be verified. FORTH is the
> > leader by this measure, though of course it fails on bounds
> > checking and garbage collection.
> Perhaps, but again, FORTH programs have a habit of looking
> like line noise.
> Doug Jones
> jones@cs.uiowa.edu

So does mathematics, especially mathematical logic and set
theory, to the uninitiated. A good notation has enormous power
to aid thought, but only for those willing to learn it. Please
don't pontificate on subjects where you have no direct
knowledge. (I have a degree in mathematics, and have been paid
to program in APL, BASIC, FORTH, and C, and to document APL, C,
C++ and Java. In addition I have studied implementation
techniques for LISP, APL, FORTH, and compiled languages, and the
use of programming languages in hardware description.)

The appearance of readability of most languages is an illusion,
since few even among professional programmers in most languages
understand the complete syntax correctly. The only exceptions to
this that I have experience of are in FORTH, LISP, and APL, all
of which have trivial syntax compared with the usual languages,
and a far more unified model of computing.

The inventors of each of the three were driven to build the most
powerful systems they could on the simplest possible bases, in
ways appropriate to three seemingly quite different problem
domains. The code of the masters in each of these languages is
incredibly direct and easy to comprehend, and you would do well
to seek it out, and to ignore those who treat every tool like a
hammer, and complain that nailguns don't have the right balance
for pounding with.

Edward Cherlin, Simputer Evangelist
Encore Technologies (S) Pte. Ltd.
New voices in the global conversation
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon May 31 23:17:33 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:16 CDT