| ??? 07/20/09 16:27 Read: times |
#167615 - That may be one of the reasons we disagree ... Responding to: ???'s previous message |
Per Westermark said:
You are correct in that it isn't a language problem.
But I don't think it is a result of any PC mentality. In my view it is more a question of learning by mistakes. Everyone has made noob mistakes. It's just a question of learning from them. It is often quite easy to "repair" a program that has tried floating point on a processor with math emulation. A big problem when people start to code in any language, is that it takes hard work to get somewhere. So they treat their existing code as magic and unique and very valuable. If they find out that they have made a bad design choice, they don't want to correct their design because that would mean throwing a way a number of their very valuable lines. Yes, that's a beginner issue. Once they have something that "works" they think it's precious. That may not be true to anyone else, but it certainly is, to them. Having worked with programming for a great many years, you learn that coding is just writing text. You can quickly create - or recreate - 100 lines of code. A big time is needed to figure out beforehand a good design. If your current design isn't good, you will have to spend time figuring out a better design, but then it will be quite quick to rewrite the code based on the design changes. The next thing that takes a lot of time is to document the code and to figure out how to test it. But much of that work would happen after you have made sure your design is working, so you don't have to redo so much documentation and testing if you need to redesign.
Well, programs aren't just "text." They're a specification. It's not a matter of creativity, as in writing a short-story, but, rather it's a matter of rigor, ordering things exactly as they should be, and not just doing what's "kewl". It also demands the discipline to omit what's unnecessary for the case at hand, and, instead, ensure that everything that is required, is included. That's why some people (often foolishly) consider the process "software engineering", which is considered an oxymoron by some, in view of the fact that engineering principles are seldom applied to software/firmware. It means attention to detail at the lowest level, and that's where the process often breaks down. The reason I repeat, time and again, that one who can't program a task in ASM can't program it, is that ASM forces the programmer to concern him/herself with the lowest-level details. One who's learned to do it in ASM recognizes those low-level details and ensures that they're properly dealt-with before considering his work complete. It's easy to overlook lowest-level details when the language allows you to do that. RE |
