(Original creator: HenkVanDerVeer)
Since Neil Armstrong landed on the moon, stating āThatās one small step for (a) manā¦ā the moonās surface hasnāt changed much. At least, to my knowledge. Maybe a few rocks have been moved, but to me the moon by night still looks the same as back then in 1969.
The difference with the changes in development land could hardly be bigger. The older programming languages arenāt extinct yet, but many new have appeared on the set, including complete frameworks implemented in one or more languages, each with their own API. Back then, say 20 years ago, life was simple. You learned one language, at school or in your own spare time, and reached a varying degree of expertise in that single language. Maybe you touched a second language at the surface, to make sure you could at least read the statements. But programming in a second language was, well, letās say a challenge.
It may sound like a memory from past life, but I do remember an annual company kick off meeting by ā back then ā Uniface Corporation in the US, probably around 1992 or 1993. All sales reps and tech reps came to Alameda, CA for a few days and one of the items on the agenda was a āpub quizā for the techies. A questionnaire with a dozen or so questions about our infamous Proc Language constructs. Of course, we were all cocky, as a tech support guy (or girl) you wouldnāt see the light of day if you didnāt know the Proc Language manual by heart. It was easier then: we knew one language and we knew it very well, it was still limited in functionality and in syntax.
Today, developers hardly ever work with one single development language. They often find themselves in the middle a Software Development Ecosystem, a virtual working space consisting of a variety of tools: development tools, build tools, test tools, etc. But even merely developing a modern application user interface already involves frequent switching between languages: Uniface, JavaScript, HTML/CSS, maybe even Javaā¦
And then, the modern languages are functionally much richer too. Meaning: more functions, more command statements. But also meaning: sometimes small but sometimes big differences between languages for the same type of constructions. For most humans itās near to impossible to memorize the exact syntax in each language. Already within a single language the syntax may not be strict, often due to later developments and new insights when enhancing the language.
For example, compare the following two Uniface language constructions that sort of serve the same purpose:
Target = $item(Id, Source)
getitem/id Target, Source, Id
Each time I use one of these statements, I find myself invoking the online Help, simply because I forgot. With or without parentheses? And whatās the order of the parameters again?
Comes the IDE to the rescue⦠Ideally the language editor in the IDE of your choice provides hints, or even better: a degree of intelligent code completion. It takes away the mental load of memorizing and the nuisance of separately looking it up in the reference documentation. So, where is Unifaceās IDE in that respect? Well, we canāt revert the past: it was never there except the keyword coloring and keyword completion (using Tab and Shift Tab to scroll through a list statements or functions one by one).
Uniface release 10.00b, released internally last week for the purpose of showing at User Group conferences these days, makes the first small step:
Yeah! Just what I needed: I can see which parameters are expected. I can see their types, their order. I can see where I am in the construction, i.e. which parameter Iām at. Admittedly, a first small step. But remember how Armstrong started. Many more steps to make, one at a time.
And while weāre at it, you actually see a glimpse of the new Script Editor, with new features like line numbering and code folding:
More about that and all sorts of other new stuff in 10.00b in the next blog.
Henk van der Veer
PS: I mentioned Java once, but I think I got away with it all right ā¦

