Karl wrote:
I 'know' you well enough from your posts here, Leo, to know that you know that this is not the problem.
Thank you, Karl, for the compliment. I realy know that some individuals try writing robust GDL code and can be a rather success in this way. Thank you, Thomas, for your nice example. I'll try to check it out, as you suggested. But, as saying goes, the exception proves the rule.
I have a lot to say on the theme, but I'll try to limit myself for avoid flooding. I am going to make just several remarks.
Unfortunately or fortunately, professional commercial development can't rely on individuals. A company hires one/one gives up/one is ill; a department has got a good budget/ a company cuts our budget; managers try to reach timeline by enlarging a developer group. It's life. Programmers and architects, there are no differences.
Karl, you've compared GDL and assembler
. Sorry for my irony, it's a good choice, isn't it? But have you ever seen new version of a serious assembly-written system coming every year? What about a lot of robust variation in its code (market specific, for example) ? Did you remember what documentation for that systems looked like? Was it like a "talking-around" speach (with a background idea - try to investigate any additional details by yourself)?
Are you sure most errors come from bad parameters? May be from mistyping of names of variables too? Or from copying GOTO statements without changing lables? Or from wrong assumptions about a global parameter meaning or behaviour in various contexts? Or from using a lot of global variables in rather a large piece of code? In most of these cases an object crashes with an error like "Division by zero", especially in geometry-processing code.
GDL is a language for processing geometry entities. We code objects with a lot of parameters. Usually, a GDL program creates rather a lot of parameter-rich geometric primitives, which correspond with each other. So, regular GDL object has lots of variables and branching. What does GDL offer us to deal with this complexity? Nothing. Absolutely nothing.
But GUI programming brings object-oriented concept into our usual practice mainly up to these reasons!
From my point of view, there are the main weaknesses of GDL, which affect reliability of GDL objects:
1. Lack of strict variable declaration rule.
2. Lack of normal subroutines with local variables. We can use CALL statements, but do you seriosly isolate every subroutine in an individual object? How do you review the whole code of your object? I guess, this approach is possible, but doubt about its usefulness.
3. No internal error-state handling features. They haven't implement even usual Basic instruction ON ERROR GOTO, so we can't isolate and handle error conditions. But, besides this, they must have implemented some regular way for informative and logic handling of error-like situations.
4. What have we got for debugging? We can't use "PRINT" in PARAMETERS Script, so what can they offer? Nothing. They have a report window, but we can't write to the window! I keep silence about tracing.
5. What about informative error-related messages? As Steve reported above, he got an error message without any library object identification!
These all are about robustness, from my point of view. Once again, some of us can write rather robust GDL objects, but we are talking about a commercial product. It's a result of a lot of modifications and each particular modification is done by a human. Who has an essential quality - he is making mistakes. Sometimes, even you and I make mistakes, as we are humans too
. But GDL developers know nothing about this. Possibly, they haven't read any classical programming books.
Sorry for a so long message, but I really need to blow off steam.
Cheers,
Leo.