CompuServe Thread

#109585From: Ben BlishFeb 17, 1988 3:45 AM

I disagree – I think a language ought to check types when you're messing with pointers – I think it ought to handle casting and conversions of numeric arguments w/o squealing at you, and in a completely predictible (defined, standardized, etc) way. However, if I'm pointing at an 8-bit entity, the compiler does things to the pointer (hopefully) for me like increment, decrement, etc… in the size of the entity; therefore, I wanna know if I point at a 24 bit entity with that pointer; – so…. I think that is a reasonable canidate for casting. Numeric types, no way. BTW – I can think of plenty that's wrong with 'c'… limitations I would rather not have, features I'd like to see removed; but I still think it's by _far_ the best language around that I've messed with at all, barring assembler; Of course, if I had unlimited time, I'd _always_ write in assembler – that, and a totally stable environment, so's I wouldn't be caught flatfooted by revs and so on. but, since I need to get things done NOW, I use 'c' – the next best thing…. another thing 'c' buys you, on this machine, that I _really_ like, is a huge common ground with other amiga people who are writing complex system-level things… M2 and all the rest are just too limited for me to take a serious interest in for programming serious things. And I don't have time or energy to play with multiple languages… however wonderful they may be, which btw M2 isn't. hehehehe. On another subject… I noticed a lot of flack about a compiler's having no way to bounds check an array you allocate at run time – gee….. <musing> doesn't seem all THAT hard… another subject for casting, or an equivalent operation. (If you WANT bound checking, of course – Yech!) –Ben–

#109611From: John DraperFeb 17, 1988 10:03 AM

I think I see… you want the compiler to yell at you when an operation would result in a pointer changing value by an unexpected amount, but not when an operation would change a numeric variable by an unexpected amount. Lots of consistency there all right. As for common ground and M2; C and M2 are not all that far apart when it comes to interfacing with the system. I think that a lot more people would have progressed a lot faster on the learning curve had the machine been documented in a more Pascalish or M2ish way, though I'm sure all the C types will disagree with that. As I said the other night in CO Ben, you really should at least try a language before you say it 'isn't all that wonderful'. Bounds and range checking is just another tool, and is normally put in while you are debugging code, and removed (by changing one line in the source), when you have proven out the program and want to generate the final output. Your distaste for that is amusing, to say the least, showing that you either have no need for debugging or that you think scattering debug statements throughout the code to be a better method.

#109629From: Doug WingerFeb 17, 1988 2:28 PM

I was grabbed by the one phase,"…documented in a more Pascalish or M2ish way" in your missive. I partialy agree with that. For illustrating how to use what's there, psuedo-code is the most flexible method for imparting the necessary basic information. However, a lot of the OS was written in C, and it does seem to be the language of choice for the machine. This does not mean that I endorse Pascal or M2 as the language of to be used when illustrating a point. Strip any of the languages mentioned down to the bones and you have a _lot_ of simularities in grammar and syntax. They all require declaration of variables and are for the most part structured in an almost identical fashion. It seems to me that Pascal and M2 are stricter in their demands on how a programmer goes about doing certain things, while C allows more lattitude. I've always thought of C as being a mid-level language that gives the knowlegable programmer a good idea of what his code is doing at the machine level, while Pascal and son were high-level structured languages. (Wandering a bit, sorry) Since these langages share a great deal in structure, why not use psuedo-code for illustrating algorithms? This lets you write in the language of your choice, without having to translate from a language you have little interest in to the one you use. I'm certain ther have been times you've seen code in C you wanted to port over to M2 and were forced to `dirty your hands' mucking about with it in C. I know I've seen that on my part, only it was Pascal/M2 to C translations that had me reaching for reference books. (Yes, I do know some of the languages, but have not used them enough to certain of some of the more arcane features) Besides, I thought is was the power of the algorithm that makes good programs with all the rest just being bells and whistles, 🙂

#109753From: John DraperFeb 18, 1988 9:50 AM

You are absolutely right about the power of the algorithm being the all important part of programming, and I think it may be worthwhile to clarify one thing. I do think that any language that does the trick for you is the right one to use. I think that perhaps in the heat of the debate, we have forgotten that. My point was not that C is all bad, just that it is more error prone, and not as suitable for large projects involving many modules, perhaps worked on by many programmers, as is a truly modular language like M2.

#109753From: John DraperFeb 18, 1988 9:50 AM

You are absolutely right about the power of the algorithm being the all important part of programming, and I think it may be worthwhile to clarify one thing. I do think that any language that does the trick for you is the right one to use. I think that perhaps in the heat of the debate, we have forgotten that. My point was not that C is all bad, just that it is more error prone, and not as suitable for large projects involving many modules, perhaps worked on by many programmers, as is a truly modular language like M2.

#109629From: Doug WingerFeb 17, 1988 2:28 PM

I was grabbed by the one phase,"…documented in a more Pascalish or M2ish way" in your missive. I partialy agree with that. For illustrating how to use what's there, psuedo-code is the most flexible method for imparting the necessary basic information. However, a lot of the OS was written in C, and it does seem to be the language of choice for the machine. This does not mean that I endorse Pascal or M2 as the language of to be used when illustrating a point. Strip any of the languages mentioned down to the bones and you have a _lot_ of simularities in grammar and syntax. They all require declaration of variables and are for the most part structured in an almost identical fashion. It seems to me that Pascal and M2 are stricter in their demands on how a programmer goes about doing certain things, while C allows more lattitude. I've always thought of C as being a mid-level language that gives the knowlegable programmer a good idea of what his code is doing at the machine level, while Pascal and son were high-level structured languages. (Wandering a bit, sorry) Since these langages share a great deal in structure, why not use psuedo-code for illustrating algorithms? This lets you write in the language of your choice, without having to translate from a language you have little interest in to the one you use. I'm certain ther have been times you've seen code in C you wanted to port over to M2 and were forced to `dirty your hands' mucking about with it in C. I know I've seen that on my part, only it was Pascal/M2 to C translations that had me reaching for reference books. (Yes, I do know some of the languages, but have not used them enough to certain of some of the more arcane features) Besides, I thought is was the power of the algorithm that makes good programs with all the rest just being bells and whistles, 🙂

#109662From: Ben BlishFeb 17, 1988 7:15 PM

I _do_ try to have no need for debugging… and if a program just grabs a guru, I can (so far) find it very quickly, and usually without resort to a printf… that comes from a modular approach, and checking things (data ranges and so on) myself – carefully. I sure don't want the compiler checking me after the fact. If the program is written correctly, you won't go outside a range, period. I have a question for you – what does "changing a numeric variable by an unexpected amount" mean? if I add a signed byte with a value of -3 to a long unsigned int with a value of 27, I expect a result of 24. I _don't_ expect the compiler to harp at me. numbers are numbers; c compilers are supposed to promote all variables to the highest precision of a variable in an operation; then assign the result to the target. <shrug>… If the result doesn't fit, things are supposed to be converted, then truncated. <shrug again> Nothing unexpected – as a matter of fact, that behaivior is basic to handling the language. –Ben–=

#109683From: John DraperFeb 17, 1988 9:21 PM

Add 1 to 127. What are the results when using signed char? unsigned char? You gave a good example yourself. As I mentioned, you seem to think that's OK, but only for numeric values, not for pointers. I find that inconsistent.

#109704From: Ben BlishFeb 17, 1988 10:12 PM

1 to 127 using signed char are zero. Using unsigned char, 128. No problem. Add 1 to a 32 bit float… add 1 to a 32 bit int. you can get totally different results. Great. I like having the flexibility available… I don't want to be nudged alla time about it. Pointers are handling items much more diversified than numbers; a pointer may be pointing to an item that is a unit size of 27 bytes – or 2, or 1. It's a different issue – and since the compiler can take care of making sure that the number gets to it's target whether you'r eusing char, int, or whatever, I odn't need to be bugged about casting. With a pointer, if you are not using the proper pointer, your data may end up quite a ways off from it's target – a different issue entirely, and one that is extrordinarily dangerous in a system w/o an MMU… like the Amiga. I just have no _use_ for numeric casting. Pointer casting, I have a use for. Those are my reasons. <grin> Regards <tounge firmly in cheek> Ben

#109763From: Richard Rae/SYSOPFeb 18, 1988 11:09 AM

[Adding] 1 to 127 using signed character [the results] are zero. Hmm? Are you sure about that, Ben? I haven't tried it, but it seems to me that the result would be -128… I *ASSUME* they use two's complement notation? Even if they use one's complement the result would be -127. I can't see any way to represent 10000000B as zero. Rick

#109776From: Nick Sullivan/TransactorFeb 18, 1988 1:06 PM

Rick, right you are… 127 + 1 = -128 for signed char.

#109776From: Nick Sullivan/TransactorFeb 18, 1988 1:06 PM

Rick, right you are… 127 + 1 = -128 for signed char.

#109763From: Richard Rae/SYSOPFeb 18, 1988 11:09 AM

[Adding] 1 to 127 using signed character [the results] are zero. Hmm? Are you sure about that, Ben? I haven't tried it, but it seems to me that the result would be -128… I *ASSUME* they use two's complement notation? Even if they use one's complement the result would be -127. I can't see any way to represent 10000000B as zero. Rick

#109704From: Ben BlishFeb 17, 1988 10:12 PM

1 to 127 using signed char are zero. Using unsigned char, 128. No problem. Add 1 to a 32 bit float… add 1 to a 32 bit int. you can get totally different results. Great. I like having the flexibility available… I don't want to be nudged alla time about it. Pointers are handling items much more diversified than numbers; a pointer may be pointing to an item that is a unit size of 27 bytes – or 2, or 1. It's a different issue – and since the compiler can take care of making sure that the number gets to it's target whether you'r eusing char, int, or whatever, I odn't need to be bugged about casting. With a pointer, if you are not using the proper pointer, your data may end up quite a ways off from it's target – a different issue entirely, and one that is extrordinarily dangerous in a system w/o an MMU… like the Amiga. I just have no _use_ for numeric casting. Pointer casting, I have a use for. Those are my reasons. <grin> Regards <tounge firmly in cheek> Ben

#109683From: John DraperFeb 17, 1988 9:21 PM

Add 1 to 127. What are the results when using signed char? unsigned char? You gave a good example yourself. As I mentioned, you seem to think that's OK, but only for numeric values, not for pointers. I find that inconsistent.

#109662From: Ben BlishFeb 17, 1988 7:15 PM

I _do_ try to have no need for debugging… and if a program just grabs a guru, I can (so far) find it very quickly, and usually without resort to a printf… that comes from a modular approach, and checking things (data ranges and so on) myself – carefully. I sure don't want the compiler checking me after the fact. If the program is written correctly, you won't go outside a range, period. I have a question for you – what does "changing a numeric variable by an unexpected amount" mean? if I add a signed byte with a value of -3 to a long unsigned int with a value of 27, I expect a result of 24. I _don't_ expect the compiler to harp at me. numbers are numbers; c compilers are supposed to promote all variables to the highest precision of a variable in an operation; then assign the result to the target. <shrug>… If the result doesn't fit, things are supposed to be converted, then truncated. <shrug again> Nothing unexpected – as a matter of fact, that behaivior is basic to handling the language. –Ben–=

#109611From: John DraperFeb 17, 1988 10:03 AM

I think I see… you want the compiler to yell at you when an operation would result in a pointer changing value by an unexpected amount, but not when an operation would change a numeric variable by an unexpected amount. Lots of consistency there all right. As for common ground and M2; C and M2 are not all that far apart when it comes to interfacing with the system. I think that a lot more people would have progressed a lot faster on the learning curve had the machine been documented in a more Pascalish or M2ish way, though I'm sure all the C types will disagree with that. As I said the other night in CO Ben, you really should at least try a language before you say it 'isn't all that wonderful'. Bounds and range checking is just another tool, and is normally put in while you are debugging code, and removed (by changing one line in the source), when you have proven out the program and want to generate the final output. Your distaste for that is amusing, to say the least, showing that you either have no need for debugging or that you think scattering debug statements throughout the code to be a better method.

#109585From: Ben BlishFeb 17, 1988 3:45 AM

I disagree – I think a language ought to check types when you're messing with pointers – I think it ought to handle casting and conversions of numeric arguments w/o squealing at you, and in a completely predictible (defined, standardized, etc) way. However, if I'm pointing at an 8-bit entity, the compiler does things to the pointer (hopefully) for me like increment, decrement, etc… in the size of the entity; therefore, I wanna know if I point at a 24 bit entity with that pointer; – so…. I think that is a reasonable canidate for casting. Numeric types, no way. BTW – I can think of plenty that's wrong with 'c'… limitations I would rather not have, features I'd like to see removed; but I still think it's by _far_ the best language around that I've messed with at all, barring assembler; Of course, if I had unlimited time, I'd _always_ write in assembler – that, and a totally stable environment, so's I wouldn't be caught flatfooted by revs and so on. but, since I need to get things done NOW, I use 'c' – the next best thing…. another thing 'c' buys you, on this machine, that I _really_ like, is a huge common ground with other amiga people who are writing complex system-level things… M2 and all the rest are just too limited for me to take a serious interest in for programming serious things. And I don't have time or energy to play with multiple languages… however wonderful they may be, which btw M2 isn't. hehehehe. On another subject… I noticed a lot of flack about a compiler's having no way to bounds check an array you allocate at run time – gee….. <musing> doesn't seem all THAT hard… another subject for casting, or an equivalent operation. (If you WANT bound checking, of course – Yech!) –Ben–

#109687From: Richard Rae/SYSOPFeb 17, 1988 9:36 PM

"If you honestly disagree with… my contention that a language should either check types all the time or not at all, then tell me the reason for your disagreement." Surely. IT DOESN'T MATTER. If you are letting a language do all your casting for you, then the program is not self-documented at the lowest level; you must look back to the variable declarations to figure out what is being done where. Case in point: FORTRAN does casts automatically. That doesn't stop XYBASE=REAL(COORD)*100.0 from being clearer than XYBASE=COORD*100.0 if COORD is defined as INTEGER. I always cast explicitly in FORTRAN too, just like C. At the other end of the spectrum, if a language doesn't do ANY casting for you, you MUST by definition cast everything. What it comes down to is that, for my outlook and coding style, it doesn't matter whether a language casts fully, partially, or not at all. A piece of code written for understandability and maintainability has everything spelled out. Please note once more that I am not disagreeing with your contention that C is not right FOR YOU. Further, I really can't argue on your grounds, since I've not used Modula or Pascal. I am merely trying to keep you aware of the fact that a lot of what you are labeling as inherent problems with the language are based on your approach TO the language.

#109714From: John DraperFeb 17, 1988 11:11 PM

i wouldn't agree that it is based on my approach to the language, but rather on my feeling for the essential rightness of a programming language in general. In a completely untyped language, you need never concern yourself with types. The type will be whatever you use it for at the time. In this case, casting is unnecessary and probably not even meaningful. In a strongly typed language, one need cast only when a type change is needed. My point is that the mixing of implicit casts with needed casts is dangerous.

#109764From: Richard Rae/SYSOPFeb 18, 1988 11:10 AM

Okay, you view C the way you do because of your feelings relative to the "essential rightness of a programming language". Sounds to me like that's the same thing as "your particular approach to the language", but I'll give you that one. I'm going to endeavour to drop out of this one now. I've reminded you of why we don't agree, and we both know we're both not changing on this one 8), so further discussion between you and I would be a waste of message space. I'll just sit back and watch you and Ben thrash it out. 8D

#109764From: Richard Rae/SYSOPFeb 18, 1988 11:10 AM

Okay, you view C the way you do because of your feelings relative to the "essential rightness of a programming language". Sounds to me like that's the same thing as "your particular approach to the language", but I'll give you that one. I'm going to endeavour to drop out of this one now. I've reminded you of why we don't agree, and we both know we're both not changing on this one 8), so further discussion between you and I would be a waste of message space. I'll just sit back and watch you and Ben thrash it out. 8D

#109714From: John DraperFeb 17, 1988 11:11 PM

i wouldn't agree that it is based on my approach to the language, but rather on my feeling for the essential rightness of a programming language in general. In a completely untyped language, you need never concern yourself with types. The type will be whatever you use it for at the time. In this case, casting is unnecessary and probably not even meaningful. In a strongly typed language, one need cast only when a type change is needed. My point is that the mixing of implicit casts with needed casts is dangerous.

#109687From: Richard Rae/SYSOPFeb 17, 1988 9:36 PM

"If you honestly disagree with… my contention that a language should either check types all the time or not at all, then tell me the reason for your disagreement." Surely. IT DOESN'T MATTER. If you are letting a language do all your casting for you, then the program is not self-documented at the lowest level; you must look back to the variable declarations to figure out what is being done where. Case in point: FORTRAN does casts automatically. That doesn't stop XYBASE=REAL(COORD)*100.0 from being clearer than XYBASE=COORD*100.0 if COORD is defined as INTEGER. I always cast explicitly in FORTRAN too, just like C. At the other end of the spectrum, if a language doesn't do ANY casting for you, you MUST by definition cast everything. What it comes down to is that, for my outlook and coding style, it doesn't matter whether a language casts fully, partially, or not at all. A piece of code written for understandability and maintainability has everything spelled out. Please note once more that I am not disagreeing with your contention that C is not right FOR YOU. Further, I really can't argue on your grounds, since I've not used Modula or Pascal. I am merely trying to keep you aware of the fact that a lot of what you are labeling as inherent problems with the language are based on your approach TO the language.

#What goes where?