Typographical discipline in GDL - new guidelines

[david nicholson-cole]

Dear GDL Friends,

I have been asked for my opinion about a proposed change in Graphisoft's guidelines for GDL. For many years, the GS guidelines and the system promoted in the GDL Cookbooks and Object Making books have been Upper case for keywords (BLOCK, SQR(), TAN(), TUBE etc) and lower case for parameters and strings and comments.

The proposal from GS is that ALL script should be in lower case - keywords, commands, parameters etc. The justification appears to be that this is how things are in java, C etc. and its good to shake off the heritage from BASIC.

This is something I fundamentally disagree with.

But if you agree with me, then I need some supporting emails from the GDL developer community. Ed Brown of the GDL team at GS would like to know how the developer community think.

My arguments are:

The machine may not mind what case the script is in, but the human brain cannot read pages of script easily if there is no system of distinguishing keywords from parameter names and strings.

Since Graphisoft have not seen fit to provide smart colourtext (as in Dreamweaver etc and Visual GDL of 1995-6, and Codewarrior) whereby colour is used to distinguish keywords, comments, parameters, strings, the poor human working with the script needs some way of distinguishing words in the script. Good java and C++ editors like Codewarrior used coloured text.

The tendency for parameter names to get longer and longer means that it is more important than it ever was to use a system of Typography to distinguish keywords from parameters and strings. In java, C, pascal etc, there is also a very disciplined system of progressive indenting, to highlight blocks of code and help the brain pick out the blocks - I also promote this in my recent books.

In the old days of AC 4 and 4.5, we used single letter variables, and if these were upper case, there could be an argument for making the keywords in lower. But even then, the GDL book from GS recommended the system proposed in the Cookbook. And since AC5, parameter names could be longer.

The new languages on the block like HTML and XML can use Upper case for keywords (FONT, STYLE etc) and lower case for strings etc, and this is a perfectly good precedent for arguing that GDL should stay with a mixture of upper and lower case. (they also use coloured text in Dreamweaver and Golive editing. Dreamweaver 4 uses lower case, but as its coloured, I dont have a problem with that.).

The need for modularity and maintainability and upgradability is essential for GDL libraries, and vast masses of text all in one case and colour inhibits maintenance.

GS Manuals, Autoscripts and DXF / XML import translators etc all work to the Cookbook/old GS guidelines, so why should Human GDL writers be disadvantaged?

----------------------------
Please can you write to me directly or on here so I can assemble a case. Ed Brown at Graphisoft has very kindly offered to consider the opinions of GDL developers and compile them for consideration by the GDL development team - but I dont think he wants to be deluged! so put them here or send copies of them to me privately at davidnc@gdlcookbook.com .

Remember, these are only guidelines, this discussion is not about changing GDL - so it is not life changing. But i will certainly NOT plough back through 200 pages of GDL Cookbook 4 and change everything to lower case!! And it does mean that future objects in GS libraries will be even more impenetrable to editing or maintenance.

Frankly this seems to be a case of something that ain't broke and doesnt need fixing. There are many other improvements in GDL that we can all think of and that we would prefer the team to be thinking about - like smart coloured GDL script.

>>>david

[DGSketcher]

100%. Maybe a new thread would be more likely to get this noticed Karl, although I assume it should already be on the Wishlist. There would have been a better return if the Param-O resources had been used for this.

[Karl Ottenstein]

@DGSketcher I agree a new thread might be noticed more... sort of.. other than in the past 20 years, I think there are a few dozen threads on this very issue now.  I just happened to see this 17 year old one and thought that re-activating it would drive home how nothing has changed in 17 years and that it is long past time for improvements in this area.   It seems that in this forum, posting here has bumped this old thread.  We'll see 🙂