Survival of a Programming Language
Posted: April 13, 2007 Filed under: Brian Farn, Easy of use, RPG 3 Comments »As I awoke this morning, I cast my gaze onto a set of pleated curtains and came to realize that I was looking at an array of pleats. As an array is a programming concept, I started pondering why our children are not given lessons about stacks, queues, lists, and hierarchical trees, how to recognize them in the world that surrounds them, and how to use them to organize their lives. Are these not as important as the different types of simple machines, such as levers, wheels, axles, and pulleys? And if our children are aware of these concepts, wouldn’t they expect to find them in a programming language?
Sometime in our future, humanity may acquire the knowledge and capability to interact with our computers directly with our brains. Until then, we are relegated to inventing and using devices, as well as computer software in order for us to tell our computers what we want them to do. We define programming languages and concepts so that we may exchange data and instructions. As with everything else these days, efficiency and usability are key drivers of acceptance. We want to be able to do the smallest amount of work in the smallest amount of time in order to satisfy a programming goal, and also be able to have others understand our work so that it can be reused, extended and maintained. The longevity of a programming language, like pop stars, will be determined by its retention and growth of its admirers and supporters. To achieve this state, programming languages need to continually adapt to modern technologies and devices. Otherwise, they will be left behind and abandoned.
To be easy and natural to use, a programming language needs to have inherent support for concepts that mirror what we see and use in our everyday lives. Collections of things such as sorted lists, maps, stacks, tables and queues are currently supported rather sporadically. Object oriented languages such as Java has libraries of objects that are available to all Java programmers. Non object oriented languages such as C and RPG who have functions and procedures need to standardize on libraries that are shipped with the language compiler.
The functions that these libraries have must be both usable and complete. For instance, RPG has built in opcodes to trim the empty space from the left end or right end of strings while Java has only a single method to trim the empty space from both ends of a string. When basic function such as these are missing, all programmers that use the language are required to allocate time to write their own implementation of the function.
Successful programming languages also need to have a deprecation policy in order to banish notions that are a leftover of past hardware limitations. For example, older programming languages have facilities for manually allocating memory, managing pointers, and defining fixed field lengths. This is due to the limited capability of early input and output devices. A green screen has only a single fixed pitch font which restricts the number of characters that can be displayed on each row. A printed report has the limitation of its physical size. Newer devices and concepts have since been invented that remove the need for explicit memory allocation. For instance, in Java, there is no equivalent of the malloc function that exists in ‘C / C++’. The Java virtual machine automatically handles the allocation and freeing of computer memory. Scrolling text fields now allow for varying field lengths to be the norm, rather than the exception. Databases are now able to handle data in XML format which does not have fixed data lengths. As electronic books become more prevalent, the technology will continue to advance with the advent of scrollable electronic paper.
Fixed format languages are a result of the 80 column punch card. We no longer use punch cards, so any new graduate programmers would certainly balk at using any programming language that does not allow them to specify all of their code in their own free format style.
Surviving programming languages need to be designed with functional extensibility in mind. This allows for the growth of its ecosystem to be driven by its users. As such, a successful language will need to have a complete set of primitives, or built-in function. Elegance and simplicity of the core is crucial. Otherwise, a programmer who discovers a documented anomaly, may conclude that the programming language has been assembled like a spoken language where exceptions are being added to by special interest groups, resulting in a language with many irregularities, and therefore too unwieldy to learn.
As the state of programming languages progresses, I foresee that the successful ones will be those that are more natural to use, because of their inclusion of everyday concepts, those that have architectures with built-in facilities specifically designed to adapt to newer technologies, and those that are able to leave behind any obsolete, historical baggage. All programming languages, whether older ones, or newer ones based on concepts such as intent based programming, or modeling, will always contend with growing pains as their ecosystems expand. The ability to quickly adapt to the present, and be attractive because of their simplicity, elegance and efficient usability, will differentiate themselves from those doomed to obsolescence.
And don’t be surprised if one day, you encounter a child who is amazed as to how adults are able to survive without the ability to see the structure in all things.
Hi Brian,
Great post. The following sentences caught my eye:
“To be easy and natural to use, a programming language needs to have inherent support for concepts that mirror what we see and use in our everyday lives. Collections of things such as sorted lists, maps, stacks, tables and queues are currently supported rather sporadically.”
At first they seem contradictory. Lists, maps, stacks and queues are often things beginning computer science students struggle with, even though they appear in our everyday lives.
Perhaps something is missing in the abstractions? Without a CS background, would you look at your curtains and think “array”? It seems we should be thinking the other way around. We write programs and think “curtains” :)
- Don
I think you’ve made a good point. When I was learning to program in C it was really hard to wrap your head around fixed lengths for strings and integers… I kept asking myself why?
Currently I’ve moved on to web programming languages. They seem to be way lax in how they treat variables and casting and are really growing in popularity. Perhaps their strength lies in their ability to be so flexible and have decent foundations of pre-built functionality and objects.
I am looking for the APL (IBM based) interpreter.
Can anyone give me where can I find it in order to downloading it to my IBM PC ?.
Thanks.
luiscosgaya@yahoo.com.mx