Posted: Mon Mar 24, 2003 12:18 pm
Restored from previous forum. Originally posted by geoff.
We all want a bug free language and we all have a personal wish list for language changes, additions and improvements. Trouble is, these wishes are somewhat incompatible.
We tend to disagree over priorities. Why? I assume because we have different applications. For the newcomer writing his first game or for someone starting to learn programming what does the odd bug matter? If the language changes, no problem, he can rewrite a few lines to get things working again.
But suppose you have been programming for many years, you have tens of megabytes of source code that you need to work. When a new bug appears or a change is made to the syntax what do you do? Keep using an old version that is no longer supported, or spend days changing your code and then weeks re-testing it?
Suppose you have persuaded your employer that it's a good idea to write a few applications in PureBasic. You've got them working OK, but then a new version of PureBasic arrives, how do you explain that you need to be paid to re-work code that was working perfectly before?
From some of the comments on this Forum it is obvious that some of you have little idea how reliable compilers can be. Let me give an example. Once, when I started a new job I thought I had found a bug in the Solaris C compiler that other, more experienced, programmers were using. Not one of them believed me. They thought this so unlikely they didn't even want to be interrupted to see the problem. This is not surprising, in my entire career I have never seen a mathematical error due to a language bug in a Fortran or C program.
So am I just trying to run down PureBasic? Most certainly not, it's a great language and I admire the way Fred works so hard and patiently puts up with all our comments. I'm just making the case for reliability and stability to be given a higher priority. When it comes to complex APIs and 3D I expect a few problems with the details, but there must come a time when we have cast iron confidence in the fundamentals of the language, the maths operations, expression evaluation, control statements and so on.
We all want a bug free language and we all have a personal wish list for language changes, additions and improvements. Trouble is, these wishes are somewhat incompatible.
We tend to disagree over priorities. Why? I assume because we have different applications. For the newcomer writing his first game or for someone starting to learn programming what does the odd bug matter? If the language changes, no problem, he can rewrite a few lines to get things working again.
But suppose you have been programming for many years, you have tens of megabytes of source code that you need to work. When a new bug appears or a change is made to the syntax what do you do? Keep using an old version that is no longer supported, or spend days changing your code and then weeks re-testing it?
Suppose you have persuaded your employer that it's a good idea to write a few applications in PureBasic. You've got them working OK, but then a new version of PureBasic arrives, how do you explain that you need to be paid to re-work code that was working perfectly before?
From some of the comments on this Forum it is obvious that some of you have little idea how reliable compilers can be. Let me give an example. Once, when I started a new job I thought I had found a bug in the Solaris C compiler that other, more experienced, programmers were using. Not one of them believed me. They thought this so unlikely they didn't even want to be interrupted to see the problem. This is not surprising, in my entire career I have never seen a mathematical error due to a language bug in a Fortran or C program.
So am I just trying to run down PureBasic? Most certainly not, it's a great language and I admire the way Fred works so hard and patiently puts up with all our comments. I'm just making the case for reliability and stability to be given a higher priority. When it comes to complex APIs and 3D I expect a few problems with the details, but there must come a time when we have cast iron confidence in the fundamentals of the language, the maths operations, expression evaluation, control statements and so on.