??? 10/25/08 12:22 Read: times |
#159345 - blame users, not tools Responding to: ???'s previous message |
Steve M. Taylor said:
I HAVE seen too many slick 'C' programs that confuse obfuscation with efficiency, [...] Correct. I have too. And in other programming languages. Just as in several natural languages. Any language can degenerate into foolish constructs if the involved user can't use it. The danger with C is clearly formulated in "A minute to learn, a lifetime to master." Too many people spend a couple of weeks with C and then think they know the language. [...] who take a perverse delight in making things hard to understand. I don't think they do. I think they are just not good developers, and their code reflects back on them. Life don't get better since many users gets their first contact with C at the same moment as their get their first contact with computer programming, or with embedded development. The end result of starting to use a new computer language without any value ground to build upon is never pleasant. In the real world, you may start car racing by driving go-kart before switching to Formula Ford, etc until possibly striving for Formula 1. With programming, people almost always jumps into the deep end, and then ends up blaming the tools. I haven't found anything I can't do in Pascal that I could do in 'C' - in 25 years of working on the platform. You have to notice a very important thing. The Pascal language, as invented by Wirth, is a very limited language. The only input/output capability (often requiring that you create your file streams before starting the program) are read/write of text streams or files of records. This results in big troubles with anything that doesn't fit the file metaphor. And the joy if you need a file that should contain records of more than one type... It did also lack suitable constructs for creating a runtime library. I have done that on on several occasions, successfully, and without invoking pointer types. Did you read "real data" as in real-world data types, or as in the "real" floating-point type? I was thinking about the code to take care of floating point data and modify it in a way that it was binary transmittable for reception by another program who was expecting IEEE floating poing point values. If the receiving end expencts binary data, you can't just dump it as text. Besides, text dumping introduces loss of precision. Turbo Pascal got modules in version 4. You had to wait until Delhi to get dynamic arrays. More general string support was also late. The improvements to a large part added by Borland in their Turbo Pascal is more or less required, to make it a general-purpose language. It did add the @ operator, module support and later objects. The included changes introduced basically represents a new programming langauge, just as Objective-C and C++ are new languages based on C. Have you tried programming in Pascal, as in comparison to Turbo Pascal-compatible incarnations? In your 25 years of Pascal programming - what did you do before you got support for zero-terminated strings? Especially if you needed to work with strings larger than 255 characters? (Yes, I know that there have been some implementations that have supported 65525 (or if it was 65534) character long Pascal strings too, but to my knowledge that has been quite uncommon. And how many of your 25 years did you have to wait for the ability to pass varying-size arrays as parameters? That is unless you used @ to loose the type and then create a new typed array of maximum size "above" the passed array. Yes, I know my Pascal skills are old - I still have a couple of programs that have been used commercially for more than 20 years, but I stopped creating new programs about 1990-1992 after having written maybe 500k lines of code. The reason for the switch of language was that I felt more productive in C or C++, without noticing any loss of reliability. And the better availabilty of C/C++ compilers could not be ignored. And I ultimately needed access to OS and library API defined in C. Thinking hard about writing code is a very good idea in any language. As I have already noted in this and earlier posts: Thinking hard about writing code^H^H^H^Hanything is always a very good idea in any language. |