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

[Fabrizio Diodati]

Dear David,

I fully agree with you!!!
If you need any support from me please don't hesitate to ask for it I'm ready to do anything to support you point of view.

Friendly
Fabrizio

[James Murray]

I will continue to use all caps for keywords. It is the only technique available to make scripts more readable for humans. GS won't do anything to make scripting easier, but here's something we can do voluntarily to make it harder. No way.

DNC wrote:
Frankly this seems to be a case of something that ain't broke and doesnt need fixing.

Pointless form over function. As for making GDL more like C, I would think that would be much more development intensive than colored text, but be my guest. In the meantime it will continue to look like BASIC because it is like BASIC.

[LiHigh]

David, you'll have my full support!
GS, we want colour texts PLEASE.......

[Anonymous]

David,

Count me in too.

Case, indents and comments are the only tools we have to make scripts readable. I see no reason to promote a standard which abandons one of these features.

Regarding colored text; I've been wishing for this in GDL ever since I first encountered it in 4th Dimension thirteen (or more?) years ago. It was even a part of AlphaText, a shareware text editor I used back in 1997.

4th Dimension has also included automatic indenting in conditional statements and loops since I started using it back in 1988. It even provides a column on the left with lines which show the nesting of the IFs, FOR/NEXTs, REPEAT/UNTILs and WHILEs.

[Vitruvius]

This seems to be a completely unecessary application of a "standard" for some arcane reason. In fact, I'd like them to make it easier to peruse through the application of coloured text, bold text, etc.

I fully support the retention of CAPs for keywords - we're a community of designers grappling with programming, we're not C programmers!

Cheers, Cameron

[David Collins]

I would also strongly recommend the use of caps as David sets forth in the Cookbook. All anyone has to do to understand the importance of this is to open an old Graphisoft library part and try to understand what's happening.

I also think the extra discipline required results in more carefully constructed and controlled scripts, meaning less typographical problems to my way of thinking, due to greater attention to what's going down.

And yes I'd love to see color-coded GDL. Give us that and you can take away the caps.

[Anonymous]

I fully agree with DNC

Please GS, don't change the rules in the middle of the game.
(notice that GS standards are not respected in their own libraries)

My disapointment is great. This is absolutely not what i am waiting from GS, about GDL.
I would like first a line counter and color system font. After this, i can consider this minor suggestion.

I have not yet finished the update from 7 to 8.1. Some GDL points are still mysterious.
Difficult for me (specially on Mac) to know what is new feature, and what is perhaps a bug.

I had to wait several months to discover the new "^" flag for STR command,
not documented anywhere, and if i did not asked, i should still be waiting.

I am waiting for a better communication, better feedback, and more examples.
Please, don't misunderstand me, i am critical because i like GDL.

[TomWaltz]

Vitruvius wrote:
we're a community of designers grappling with programming, we're not C programmers!

All the more reason for color-coded code, with keywords one color, variables another, and comments yet another. It makes it MUCH easier to tell what a certain word might be, and helps you notice typos more easily.

[Anonymous]

I completely agree -- all lower-case would be terrible.

Also, GS needs to display keywords in one color, variables in another color, strings in yet another color, etc., for added clarity. But I would still prefer to use mixed case even in a colored-editor scenario. In fact, the editor ought to be smart enough to capitalize the keywords while leaving variables and strings alone.