XPost: alt.os.development   
   From: Ekrem.Saban@utanet.at   
      
   >> The project manager was responsible for the main fraim of the software,   
   >> from   
   >> where all the parts were called. And he had a lot of time to spend to   
   >> find   
   >> the errors (mostly memory errors) of the programmers.   
   >   
   > Poor quality personnel is always a bad thing.   
   >   
   Oh, come on, Maxim! Do not judge the personnel, but see the real-world! This   
   is what you get in large projects. You cannot have a C/C++ expert at each   
   position. What you need are a few experts who *really know* how to make a   
   WORKING environment. It must be robust and not weak, i.e. allowing alot to   
   do, and a lot of wrong-doing also... ;))   
      
   An unrealistic way would be to throw away all the "coders" & employ   
   specialists. Then, the program would be well, even if it is programmed in C,   
   even if you use machine language! But then either   
   (a) nobody will buy it either, as it is too expensive, or   
   (b) a few happy customers will buy it, but the company will go bankrupt, as   
   the price for the software does not cover the expenses.   
      
   Nobody will accept that a plain programmer must be an expert. I would not   
   accept to communicate with YOU, if I would need a physiologist that knows   
   about YOUR exceptions and specialities in your body. That will be too   
   expensive for me. I prefer to communicate with humans over a high-level   
   protocol. I do not care about the carriage return at the end of my string.   
   You do not have to know HOW you do process my words. It would be a terrible   
   chore to communicate with others knowing ALL about their thinking process,   
   the electro-chemical reactions in his nervous system, in his brain...   
      
   Maxim, if you want to, you can see the problem from this way: stop to think   
   that you can CHANGE the way people are thinking! YOU have to find the proper   
   language for the people. Otherwise, what you get with large complexity is   
   clearly A MESS.   
      
   That's what I saw in my 15 years of HW/SW experience. And after five years   
   HW design, it was like a plunch into cold water to go over SW design. The   
   way they approach the problem can be described with one word the best:   
   CHAOS.   
      
   :)))))   
      
   It is not true for ALL of the SW designers, but it is unfortunately true for   
   MOST of them...   
      
   > This does not say that C is evil. With more complex and high-level   
   > language,   
   > these kinds of developers will just get lost in the language features,   
   > being   
   > unable to comprehend them properly, and will use them in wrong ways, which   
   > will   
   > create the same kind of problems.   
   >   
   Oh no! You will get NO memory problems with a real language, like JAVA, say.   
   There is a good memory management. No memory is given away, dangling in the   
   virtual memory space without a connection... The garbage collector, if not   
   called too often, will do it! And I speak here not from theory, I made the   
   experience.   
      
   The high level language will encompass a lot of problems - the better it   
   will do it, the better it reflects human thinking. The poorer it is in this   
   context, it will be good for simple problems. If you have a code of millions   
   of lines, written in a low- or intermediate-level language, you have   
   something "too good to throw away, but not good enough to be used properly"!   
   This is worse than having a solution that do not apply at all. Because in   
   such a case, you find someone else who will rewrite the whole again.   
   Otherwise, it will and remain an unstable system.   
      
   >> principles. All the classes were accessible from outside. The classes had   
   >> optional subclasses that were pointed to by POINTERS instead of making it   
   >> with a constructer & accessing it by references.   
   >   
   > C++ references are evil. Their only real-world purpose is implementing the   
   > lvalue-based operators like "operator []", which should return lvalue, and   
   > "operator++", which should accept the lvalue as a parameter and update it.   
   > For   
   > these functions, passing the parameters and return values by reference is   
   > necessary, thus the references in the language.   
   >   
   > In most other places, C++ references are evil. The proof: they do not   
   > contain   
   > the visual reminder of deref at the place of their use. Compare:   
   >   
   They are not so evil as pointers, as to my knowledge - please correct me if   
   I am wrong -, references never refer to NOWHERE.   
   >    void Func(MyClass& c);   
   >    // 1000 lines below   
   >    Func(c);   
   >   
   > and   
   >   
   >    void Func(MyClass* c);   
   >    // 1000 lines below   
   >    Func(&c);   
   >   
   > At the machine code level, they are the same. But note this good little   
   > "&" in   
   > the second call, which explicitly emphasises that the parameter is passed   
   > by   
   > reference and can be updated in Func(). In the first sample, this is not   
   > obvious, and the code is lesser comprehendable.   
   >   
   >> If one mixes up C & C++ code, the overall performance and stability will   
   >> be   
   >> far of satisfactory. But before I forget the point, let me state it: NO,   
   >> IT   
   >> WASN'T THE PROBLEM OF *THIS* PROJECT MANAGER. It is the problem   
   >>of the whole   
   >> software industry.   
   >   
   > Correct, poor quality personnel is a really a problem of the whole   
   > software   
   > industry.   
   >   
   So what is the realistic answer to THIS problem?? Quitting the SW industry?   
   Well, I think about that. But if you have a better answer that IS   
   cost-efficient, then tell it to us! OK, getting personnel from China at a   
   cost for 1/10th. OK, that will work for a few decades. :)) But that is not   
   solving the problem of doing things with the WRONG paradigm, i.e. trying to   
   CHANGE the very, very complex HUMAN THINKING. You will never succeed in   
   that. So, why not use the so much increased and now levelled CPU power to   
   define high-level languages?   
      
   For this discussion that has nothing to do with FLOS anymore, stick to the   
   example of OOD and the much simpler example of memory "leakage".   
      
   By the way: do you ever used PURIFY under UNIX to see the memory leaks? You   
   can get the dumped core after the so-often seen   
      
   *** Memory error - core dumped   
      
   message & analyse from the crash point backwards to see what happened.   
      
   Please, do not misunderstand me! I do not say that low-/intermediate-level   
   languages are rubbish! They are good, but good for experts! So, they should   
   not be used by a large programmer community. If you have a group of experts   
   that want to program a more efficient library, say, you are wrong if you   
   take a high-level language, as "high-level" means not only restrictions on   
   functionality, but reduction in speed. Just see how they have done it in the   
   Rogue Wave! You will never do that with the high-level there; what you need   
   is a language that lets you manipulate virtually everything, to get out of   
   the system as much as possible! Packed into a library, you have the expert   
   knowledge somehow encapsulated. Your code will rely on well-tested code &   
   the testing costs will fall.   
      
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)