Re: proposal: state machine syntax also usable for continue / nested break

[Everett L Williams II <rett@...>]

Javier Guerra Giraldez wrote:

On Sat, Jan 29, 2011 at 6:23 AM, Everett L Williams II
<rett@classicnet.net> wrote:
  

largely write-only language
    

i'm surprised by that, as i find Lua the most readable language I
know; far more than Python and _javascript_, which (others) often
mention that as their advantages.

can you share which languages you find most readable? Maybe COBOL or
AppleScript? (both of which I find 'read-only')

  

Javier,

Over the years, I have largely classified languages as read-only, write only, read/write, and none of the above, with some caveats here and there. I can certainly sympathize with the wish to classify COBOL as a read-only language, but really it is not. I wrote a reasonably complicated CLIST program in the TSO editor to allow me to take care of the Data Division with speed and accuracy. When the ANSI 74 version of the language became available, I used the formatting option in the language to regularize the form of the language so that it was even more readable. That and the power of the ISPF editor allowed me to kick out COBOL faster than any language that I have used since, even with modern IDEs. And, debugging COBOL was so very easy that you really could not spend too much time doing it. On top of that, we had an early structuralizer system for COBOL. And, all of that was before we got to the VM/CMS editor and the REXX language, which were orders of magnitude more powerful than TSO-CLIST/ISPF.

At the other end of the gamut is FORTH, which seldom has anything that resembles a FORTH primitive visible anywhere. If you didn't write it or have the author's dictionary and notes, reading it was out of the question.

Several of the early 4th generation and scripting languages are quite readable and writable, such as Eztrieve, CLIST, and REXX. As strong typing came into vogue, the languages became readable, but clumsy and almost unwritable. Pascal and it's follow-ons became less and less read or write friendly, as what seemed the simplest of functions often required major side trips. Privacy and protection in methods set up huge barriers to straightforward programming. With object oriented programming, if you don't name your methods carefully, the greatest genius on Earth could not read the resultant code. Then you get to functional languages, and there, the train runs right off the track. The attraction is the enormous power offered by the constructs available in such languages. The problem with great power is that it normally engenders subtle syntax, making readable by only a very limited set of readers. That is where lua resides. Tables and metatables and skipping back and forth between C and lua would give a headache to the guy who tied the Gordian knot.

You will no doubt not that I have entirely skipped over the C and Cpp group of languages, and there is a reason for that. That's because C is very difficult to manage and Cpp just beyond the pale. Put in a few templates and Cpp just rises up into the stratosphere. That's why we have to have APIs for everything written in those languages. The idea that anyone could with reasonable effort, figure out how to interface with C or Cpp programs that they did not write is not just logically ridiculous, but palpably exemplified by the massive systems of code that are out there at the heart of so much of our current programming world. And, give me a dime for every time the API written by the person who wrote the program is just plain wrong, and I would be a rich man.

Of the languages that have stuck around and that are still in use that are most readable and writable, I find that REXX and Eiffel are right at the top, though they accomplish their ends by totally different means. That does not mean that I would not suggest the use of other languages in particular circumstances, but I would suggest to you that the first and necessary job of the first real AI will be to go out and untangle and replace the enormous and humanly undigewtible lump of C, Cpp, and assembler programs that is out there at the heart of our computing world. Now, there are quite a few small and very readable and writable languages out there, but they just do not have the base and many times the capabilities required to cover much of the territory. I have worked with many of them, hoping that they would find a way to take off, and some of them have gotten close, but they all stumble when they have to be interfaced with that massive legacy of C and Cpp code. lua does some of that, but is too dependent to solve the problem.

Everett L.(Rett) Williams II