by Tdarcos » Fri Oct 07, 2011 6:56 pm
Ice Cream Jonsey wrote:You didn't even read what I wrote, did you?
Oh, we read it alright.
No, clearly you did not.
Ice Cream Jonsey wrote:You make not like the conclusions, but we read it.
I was talking about a function of the program generating the wrong results by putting a property value on the same line as the property declaration. You were talking about the requirement to split a line by using a \ at the end. That's entirely different and has absolutely no relevance to the question I posted, so clearly you did not read what I wrote and proceeded to say whatever you wanted, the fact it had absolutely zero relevance to the question I posted notwithstanding.
Ice Cream Jonsey wrote:Expressing the text on two lines works perfectly (without the use of the backslash) but expressing the text on one line fails without error. This is the exact opposite of what you are referring to.
Paul. PAUL. The compiler, engine and language will let you do a w_to "Some_Object". If you don't have that object defined, that's on you.
In a language requiring declaration of items in order to use them, failure to declare is an error of the program writer, and is an obvious bug which the compiler should catch. Since use of an uninitialized object or nonexistent object would cause serious errors this is a bug in the compiler for not catching it.
And actually, you're wrong:
Code: Select all
room W_Past_warehouse "Approaching East of Warehouse area"
{
S_to Noplace
E_to W_of_warehouse
W_to
"Not available"
long_desc
"The path running east leads toward a warehouse."
}
The Hugo compiler will throw a flag if "Noplace" is not defined. It will not allow you to reference a nonexistent object.
Ice Cream Jonsey wrote: You could rename "Blah" to "Some_Object" later and it would be fine.
Use of uninitialized or undeclared objects is not a valid purpose and serves no purpose (there is no way to use this as a feature that would allow the program to work), and for the compiler to fail to notice this is an error. There is no conceivable legitimate reason to reference a non-existent object and doing so is an error that even the simplest compiler should catch.
I've seen some applications - Firefox might be one, but Netscape Navigator definitely is one - that when the program referenced a pure virtual function (the template) of a class, instead of an overriding function to handle the particular action needed, the runtime library terminated the application. This is an example where the system protects the programmer from himself by catching obvious and glaring errors.
Ice Cream Jonsey wrote:I mean, why on earth you want to send your player character into a string I have no idea, but that's not something the compiler should or will stop you from doing.
Wrong. A compiler should catch errors that are obvious. A string is not an object, does not work as an object, and can't be used as one, so using one where an object should be present is an error the compiler should catch.
Ice Cream Jonsey wrote:I am pointing out where a construct causes the run-time library to fail without detecting the error. If the construct is valid the application should not fail; if the construct is invalid the compiler should flag it as erroneous.
You are going to find yourself very frustrated in life if you believe that all languages are buggy if they don't catch real-time exceptions.
I'm not frustrated, I simply know when something is a real compiler or when it's a toy not worthy of serious consideration. And I doubt that you would use a weak toy to design a serious piece of fiction like CryptoZookeeper or the other ones you've used Hugo for. If it was as bad as this implies, people would have discarded Hugo as being worthless and would not have used it.
Error trapping of the obvious is trivial, it improves the code generated because really bad constructs don't go through, and because it makes the writer more careful because a bad construct won't be tolerated.
Older C compilers won't catch this type of error, but good ones will generally throw a flag (which can be overridden by a compiler argument if you need it) if you use the construct
instead of
in fact, good coders will do their comparisons backward such as
in case they forget to use == and use = by mistake so the compiler will catch the attempt to assign something to a constant.
Ice Cream Jonsey wrote:Commander, the reason why I said it's going to be you and not the language is because that is how it is EVERY SINGLE TIME a programmer learns a new language.
Where this will all go next is that you'll find something the language doesn't have and call it a bug.
That's got to be the weakest and most stupidly presented example of a strawman argument I've ever seen.
OK, but for the record, when you thought that Hugo couldn't print numbers that were strings, you called it a bug.
Because I knew that it could do so because the status line does so.
Ice Cream Jonsey wrote: What if Hugo simply didn't have the ability to print numbers? You would have called it a bug. That's the only reason I said that. If that's not accurate, consider it..... redacted!!!
Okay, it wouldn't have been a bug. It would have been a design failure so bad and a class of flawed application so horrendous as to make the program a toy not worth considering.
Even the smallest Basic interpreters written in 4K thirty years ago could print numbers. An application development system - a compiler, an interpreter, a spreadsheet - which is designed to allow user applications to make the development system perform actions, and has no capacity to print numbers is not merely defective, it is out and out a toy of absolutely no value and worse than useless.
Ice Cream Jonsey wrote: It is neither an error nor a bug in Fortran, Basic or Java to fail to have pointers.... I understand your analogy except that no Basic written in about the last 20 years has required line numbers. I have FreeBasic installed
So when I say, "BASIC has line numbers" and you say, "FreeBasic doesn't require line numbers" ... I'm not so sure I said something incorrect there.
I used FreeBasic as an example. But find one. I will reiterate my statement: no commercially released Basic interpreter or compiler in the last 20 years has required line numbers, and where labels are required for branching, the labels can be words. And there is no serious open-source basic that has been released in the last 20 years that required line numbers to be used. Visual Basic, the Basic that is used in Excel or Word, the basic now used in OpenOffice.Org, none of these require line numbers.
But go ahead, prove me wrong, find any serious Basic which has been recently released - meaning one created since 1991 that has a regular following beyond the author and that those who follow the system are using it to create programs they actually use - that requires line numbers on each line and I'll apologize.
Ice Cream Jonsey wrote:Yeah, but programmers can do all sorts of wild and crazy things to lock up their applications, that gets by the compiler. In this case, the Hugo engine is trusting the programmer that he or she has a reason for doing that. That's all.
Ronald Reagan gave one of the greatest statments ever, "Trust, but verify." People make mistakes all of the time; the more things the compiler presumes the programmer can do wrong and catches, the better the code is.
One of the most powerful features of programming languages, that has seriously increased programmer efficiency, is the automation of memory management and garbage collection. This, more than anything else is why so many people moved to Java over C++ because Java does GC and memory management automatically. C++ programmers still have to do their own memory management and garbage collection, and they have commensurately higher error rates.
Ice Cream Jonsey wrote:I have been programming for decades; that gives me an advantage in that I might push the envelope more than someone else.
I do not deny this! This is why I wanted you to test CZK.
I'll admit I wish I could have done better on it, the thing is that one of the things that bores me too easily are difficult problems I can't reasonably solve, and the second are games that kill me off fairly quickly (or, as related to the above, that I can't figure out how to keep from being killed in a hurry.)
Ice Cream Jonsey wrote:The next big game I write I will approach you again and I'll see if we can make this work.... financially. (And I'll give you a walkthrough to consult so you can find bugs and move on.)
Well, that's nice of you. The real problem is I do try to solve a problem and I'll attack it from a number of angles, but after a while I'll get frustrated because sometimes it seems like the problem can't be solved, or that the person who designed it thinks in such an unusual way that I don't see it from their angle and thus can't figure out what they were thinking.
Ice Cream Jonsey wrote:In his defense, it was Pascal.
With the development of Turbo Pascal, and later Delphi, it made Pascal an excellent environment for the development of serious applications. Pascal is a very good learning tool, and with the addition of object orientation it gave it capacities on par with C++ but with less danger of getting oneself in trouble by use of bad constructs. Pascal's usual one-pass requirement, predeclaration of identifiers, and strict typing force better habits in the development of applications and reduce attack vectors.
Since you have to declare an array or a dynamic structure in advance, you allocate it from a memory area, and going outside the memory you allocated causes the program to fault, this makes buffer overflow attacks - very common in C/C++ applications - impossible in ones written in Pascal. Access unallocated or unauthorized memory, and you don't create an execution vector for an attacker, your program crashes instead.
Ice Cream Jonsey wrote:
Who's judging? This is a judging-free zone. A judge-free zone, Commander!
I must respectfully disagree, Your Honor.
[quote="Ice Cream Jonsey"][quote]You didn't even read what I wrote, did you? [/quote]Oh, we read it alright.[/quote]
No, clearly you did not.
[quote="Ice Cream Jonsey"]You make not like the conclusions, but we read it. [/quote]
I was talking about a function of the program generating the wrong results by putting a property value on the same line as the property declaration. You were talking about the requirement to split a line by using a \ at the end. That's entirely different and has absolutely no relevance to the question I posted, so clearly you did not read what I wrote and proceeded to say whatever you wanted, the fact it had absolutely zero relevance to the question I posted notwithstanding.
[quote="Ice Cream Jonsey"][quote]Expressing the text on two lines works perfectly (without the use of the backslash) but expressing the text on one line fails without error. This is the exact opposite of what you are referring to. [/quote]
Paul. PAUL. The compiler, engine and language will let you do a w_to "Some_Object". If you don't have that object defined, that's on you.[/quote] In a language requiring declaration of items in order to use them, failure to declare is an error of the program writer, and is an obvious bug which the compiler should catch. Since use of an uninitialized object or nonexistent object would cause serious errors this is a bug in the compiler for not catching it.
And actually, you're wrong:
[code]
room W_Past_warehouse "Approaching East of Warehouse area"
{
S_to Noplace
E_to W_of_warehouse
W_to
"Not available"
long_desc
"The path running east leads toward a warehouse."
}
[/code]
The Hugo compiler will throw a flag if "Noplace" is not defined. It will not allow you to reference a nonexistent object.
[quote="Ice Cream Jonsey"] You could rename "Blah" to "Some_Object" later and it would be fine.[/quote]
Use of uninitialized or undeclared objects is not a valid purpose and serves no purpose (there is no way to use this as a feature that would allow the program to work), and for the compiler to fail to notice this is an error. There is no conceivable legitimate reason to reference a non-existent object and doing so is an error that even the simplest compiler should catch.
I've seen some applications - Firefox might be one, but Netscape Navigator definitely is one - that when the program referenced a pure virtual function (the template) of a class, instead of an overriding function to handle the particular action needed, the runtime library terminated the application. This is an example where the system protects the programmer from himself by catching obvious and glaring errors.
[quote="Ice Cream Jonsey"]I mean, why on earth you want to send your player character into a string I have no idea, but that's not something the compiler should or will stop you from doing.[/quote]
Wrong. A compiler should catch errors that are obvious. A string is not an object, does not work as an object, and can't be used as one, so using one where an object should be present is an error the compiler should catch.
[quote="Ice Cream Jonsey"][quote]I am pointing out where a construct causes the run-time library to fail without detecting the error. If the construct is valid the application should not fail; if the construct is invalid the compiler should flag it as erroneous. [/quote]
You are going to find yourself very frustrated in life if you believe that all languages are buggy if they don't catch real-time exceptions.[/quote]
I'm not frustrated, I simply know when something is a real compiler or when it's a toy not worthy of serious consideration. And I doubt that you would use a weak toy to design a serious piece of fiction like CryptoZookeeper or the other ones you've used Hugo for. If it was as bad as this implies, people would have discarded Hugo as being worthless and would not have used it.
Error trapping of the obvious is trivial, it improves the code generated because really bad constructs don't go through, and because it makes the writer more careful because a bad construct won't be tolerated.
Older C compilers won't catch this type of error, but good ones will generally throw a flag (which can be overridden by a compiler argument if you need it) if you use the construct
[code]if ( a=4 ) { [/code] instead of [code]if (a==4) {[/code] in fact, good coders will do their comparisons backward such as [code]if (4==a) {[/code] in case they forget to use == and use = by mistake so the compiler will catch the attempt to assign something to a constant.
[quote][quote="Ice Cream Jonsey"]Commander, the reason why I said it's going to be you and not the language is because that is how it is EVERY SINGLE TIME a programmer learns a new language.
Where this will all go next is that you'll find something the language doesn't have and call it a bug.[/quote]
[quote]That's got to be the weakest and most stupidly presented example of a strawman argument I've ever seen.[/quote]
OK, but for the record, when you thought that Hugo couldn't print numbers that were strings, you called it a bug.[/quote]
Because I knew that it could do so because the status line does so.
[quote="Ice Cream Jonsey"] What if Hugo simply didn't have the ability to print numbers? You would have called it a bug. That's the only reason I said that. If that's not accurate, consider it..... [i]redacted!!![/i] [/quote]
Okay, it wouldn't have been a bug. It would have been a design failure so bad and a class of flawed application so horrendous as to make the program a toy not worth considering.
Even the smallest Basic interpreters written in 4K thirty years ago could print numbers. An application development system - a compiler, an interpreter, a spreadsheet - which is designed to allow user applications to make the development system perform actions, and has no capacity to print numbers is not merely defective, it is out and out a toy of absolutely no value and worse than useless.
[quote="Ice Cream Jonsey"][quote] It is neither an error nor a bug in Fortran, Basic or Java to fail to have pointers.... I understand your analogy except that no Basic written in about the last 20 years has required line numbers. I have FreeBasic installed[/quote]
So when I say, "BASIC has line numbers" and you say, "FreeBasic doesn't require line numbers" ... I'm not so sure I said something incorrect there. [/quote]
I used FreeBasic as an example. But find one. I will reiterate my statement: no commercially released Basic interpreter or compiler in the last 20 years has required line numbers, and where labels are required for branching, the labels can be words. And there is no serious open-source basic that has been released in the last 20 years that required line numbers to be used. Visual Basic, the Basic that is used in Excel or Word, the basic now used in OpenOffice.Org, none of these require line numbers.
But go ahead, prove me wrong, find any serious Basic which has been recently released - meaning one created since 1991 that has a regular following beyond the author and that those who follow the system are using it to create programs they actually use - that requires line numbers on each line and I'll apologize.
[quote="Ice Cream Jonsey"]Yeah, but programmers can do all sorts of wild and crazy things to lock up their applications, that gets by the compiler. In this case, the Hugo engine is trusting the programmer that he or she has a reason for doing that. That's all. [/quote]
Ronald Reagan gave one of the greatest statments ever, "Trust, but verify." People make mistakes all of the time; the more things the compiler presumes the programmer can do wrong and catches, the better the code is.
One of the most powerful features of programming languages, that has seriously increased programmer efficiency, is the automation of memory management and garbage collection. This, more than anything else is why so many people moved to Java over C++ because Java does GC and memory management automatically. C++ programmers still have to do their own memory management and garbage collection, and they have commensurately higher error rates.
[quote="Ice Cream Jonsey"][quote]I have been programming for decades; that gives me an advantage in that I might push the envelope more than someone else.[/quote]I do not deny this! This is why I wanted you to test CZK. [quote]
I'll admit I wish I could have done better on it, the thing is that one of the things that bores me too easily are difficult problems I can't reasonably solve, and the second are games that kill me off fairly quickly (or, as related to the above, that I can't figure out how to keep from being killed in a hurry.)
[quote="Ice Cream Jonsey"]The next big game I write I will approach you again and I'll see if we can make this work.... financially. (And I'll give you a walkthrough to consult so you can find bugs and move on.) [/quote]
Well, that's nice of you. The real problem is I do try to solve a problem and I'll attack it from a number of angles, but after a while I'll get frustrated because sometimes it seems like the problem can't be solved, or that the person who designed it thinks in such an unusual way that I don't see it from their angle and thus can't figure out what they were thinking.
[quote="Ice Cream Jonsey"]In his defense, it was Pascal. [/quote]
With the development of Turbo Pascal, and later Delphi, it made Pascal an excellent environment for the development of serious applications. Pascal is a very good learning tool, and with the addition of object orientation it gave it capacities on par with C++ but with less danger of getting oneself in trouble by use of bad constructs. Pascal's usual one-pass requirement, predeclaration of identifiers, and strict typing force better habits in the development of applications and reduce attack vectors.
Since you have to declare an array or a dynamic structure in advance, you allocate it from a memory area, and going outside the memory you allocated causes the program to fault, this makes buffer overflow attacks - very common in C/C++ applications - impossible in ones written in Pascal. Access unallocated or unauthorized memory, and you don't create an execution vector for an attacker, your program crashes instead.
[quote="Ice Cream Jonsey"]
Who's judging? This is a judging-free zone. A judge-free zone, Commander![/quote]
I must respectfully disagree, Your Honor.