This has been a short discussion of some of the problems that I see that are preventing the widespread use of a very powerful programming language. There are some more problems that I am aware of (something has to hang over for the next column) and I am sure that there are many more that I am not aware of Please send in your concerns about the use of the language for application development to Susan Ennis, Amoco Production Company, P. O. Box 3385, Tulsa, Oklahoma 74102.

Speed is a concern for commercial applications. If a job cannot be started before someFixedTime because the input data are not available and the output of the job is needed at anotherFixedTime, then a beautiful, user-friendly, fully documented, etc., etc., system that takes longer than (=    anotherFixedTime  someFixedTime) cannot be used. This problem will be overcome only by the existence and widespread knowledge of viable commercial systems. Lack of Portability The final problem that I want to address in this column is the problem of portability. It is all well and good for universities to use programming languages that are experimental and to write software in those

languages that may have to be completely re-written in a few years because the base language no longer exists. One of the reasons that universities can live in this manner is that they have the largest pool of good inexpensive programming talent in the world - students. In the industrial world, these conditions do not exist. Programs have to work, they have to work for many years, and they will be ported to different hardwares. The problem of different hardwares is an increasing problem as the rate of advances increases. It is accepted that there will be some changes because of hardware dependencies, but there needs to be a way to isolate hardware dependent code so that conversions can proceed smoothly and with acceptable costs.

Prev Article               Start of This Article               Next Article From C. A. R. Hoare, Hints on Programming Language Design, Symposium on Principles of Programming Languages, 1973. Conclusion A final hint: listen carefully to what language users say they want, until you have an understanding of what they really want. Then find some way of achieving the latter at a small fraction of the cost of the former. This is the test of success in language design, and of progress in programming methodology. Perhaps these two are the same subject anyway. Page Left          x Page Right Vol. I, No. 1 Table of Contents          Copyright © 2009, Mary S. Van Deusen