A few notes from a (traditional) programmer to a cerebrum developer.
We understand that most (if not all) the following will be questioned by Cerebrum developers who will most likely (and correctly) observe “its just old assembler programmers being a nuisance”.
However, a little context may assist.
Its becoming increasingly rare for systems to be designed, created, maintained and expanded by the same few people.
It is the maintenance and ongoing expansion/development phases that are the target of the following remarks.
Comments, the odd one does not go astray:
This is a perennial favorite.
Computers execute code, not comments.
So concise and accurate code is the aim, but sometimes code is not quite enough.
Hence a few comments can make the life of a maintainer much easier.
Automatic Variables:
Please be careful how you use “automatic variables”.
We know there are many many script languages that use this approach.
But:
As convenient as they are, to those accustomed to “define before use” it makes the code harder to maintain/follow and the drop downs are frequently less useful.
Until you are familiar with “Cerebrum’s scope rules”, it makes working with the expressions/variables harder.
Finally, its not much effort to manually add the variables after which it makes an excellent error checking procedure.
If you use the XML technique (see earlier), frequently you can spot the (ab)use of automatic variables.
Nested Expressions:
Its highly unlikely the typical Cerebrum developer was alive when BASIC interpreters ruled the world, think TRS80 / IMSAI / MMD1.
So to those people, a little history.
BASIC started out mainly in microprocessors where it was the default language.
As time progressed, BASIC came to the attention of the “programming police” (otherwise known as UNI’s etc).
Examining BASIC, they (programming police) saw little they liked and almost everything they hated, and made such known.
Their diatribe was not limited to nested expressions, but it was certainly a topic that gave them much material to talk about.
The PASCAL vs BASIC vs C wars were quite a fun time……
Back to reality.
We wont reprint the historical silliness from years ago, but they did make some points that are still relevant today.
It was not uncommon to see situations like that illustrated below:
a = Left$(Mid$(Len$(Chr$(Instr$(Ord…….
To the creator of the code it was probably a triumph, and gave them great satisfaction.
Indeed, managing to get it to work and without bugs is impressive.
To a maintainer, its far too time consuming to unpick and verify/debug/modify.
Its preferable to break the expression into more lines of code.
This is one occasion where (under the right circumstances) automatic variables might be ok.
Ex. You are coding a button and need to create a nested expression (say 5 deep).
The use of 3 LOCAL automatic variables (within the button context) would be much easier to follow and maintain.
As expected a few people have contacted us about (some) of the above.
Rather than answer questions we felt it better to provide a few references.
Unfortunately these are well out of print (sorry)….
Title: Algoritms + Data Structures = Programs.
Author: Nicklaus Wirth
Publisher: Prentice Hall
As its wiki (https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs) states, it was heavily used in education and provided some of the ammunition from that side of the debate.
It is an excellent text, but not one of our favorites (annoying pedantic at times).
Title: The Elements of Programming Style
Author: Kernighan and Plaugher
Publisher: McGraw-Hill
(Yes it is the “Kernighan” of Unix and the “K and R Book on C”.
Although dated, its one of our favorites.
Its immensely practical and could be quite humbling when you discovered your code had drifted into areas the book considered “less than professional”. It was a book we would read every few years.
These are only two of the numerous books (in book shops – no internet!) all attempting to shape the still relatively new area of programming at that time.
Did the books and education of the time have a lasting affect…hmmm….