XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
   > > Poor quality personnel is always a bad thing.   
   > >   
   > Oh, come on, Maxim! Do not judge the personnel, but see the real-world   
      
   You have described the bad developers. So what? Yes, I have no doubts this is a   
   real world, such things do occur.   
      
   > is what you get in large projects. You cannot have a C/C++ expert   
      
   I think that having good knowledge and practical skills of tool use is a very   
   major requirement.   
      
   > An unrealistic way would be to throw away all the "coders" & employ   
   > specialists.   
      
   Realistic. In some projects, the coder's stupidity is tolerable to some degree.   
   In some - it is _not_ so at all, so even the coders must be specialists. An OS   
   and embedded software is second thing, the website is first one (it is   
   developed using the tools which are very forgiving in terms of the coder's   
   stupidity, C is not).   
      
   >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   
      
   Then how Microsoft, Oracle, Symantec, Google and others do live? If Siemens's   
   software department could not become one of these names - then this is   
   definitely a management issue in Siemens (possibly they are unwilling to pay   
   proper salaries and want to make good things using cheap labour - then sorry,   
   this can easily fail in some scopes of activity).   
      
   > Nobody will accept that a plain programmer must be an expert.   
      
   He must not be sub-qualified for his exact task, this is the rule. For some   
   tasks, experts are needed. For some, they are not. Coding embedded systems in C   
   is nearly and expert task, a task for a guy which will be qualified enough to   
   understand pointers well, and not forgetting to call free() after malloc().   
      
   You cannot do complex tasks using cheap labour, period. And no Ada or other   
   similar complex languages will help. The cheap labour force will just   
   misunderstand them :-)   
      
   > expensive for me. I prefer to communicate with humans over a high-level   
   > protocol.   
      
   Me too :-) especially at work.   
      
   > 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!   
      
   What I see from your description is sub-qualified (for this task) developers   
   making constant errors in their C (or C++-near-to-C) code, errors related to   
   pointer use. Sorry, but how Ada or Eiffel can help them? Such guys will just   
   not be able to comprehend these languages properly.   
      
   >YOU have to find the proper language for the people.   
      
   ...or proper people, if we are about work.   
      
   > 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...   
      
   Maybe. This is one of the cause the software professionals are well-paid - the   
   company usually can hardly afford the personnel flow.   
      
   > Oh no! You will get NO memory problems with a real language, like JAVA, say.   
      
   You will get another problems, like "this framework-provided class throws this   
   stupid exception sometimes, why is it?".   
      
   But for many tasks Java and .NET are fine and better then C, this is for sure.   
      
   > 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.   
      
   Depends on whether the code is comprehendable or not so. Sometimes it is really   
   easier to re-implement something instead of comprehending the existing   
   implementation.   
      
   And now - the paradox - C++ code is often lesser comprehendable then C. For   
   instance, the "a = b" for objects is lesser comprehendable then "Copy(&a, &b)".   
   The reason is that with C++ "a = b" you have no copy constructor code at hand,   
   and will need "grep" to find it somewhere in the header files, possibly of some   
   base class.   
      
   > They are not so evil as pointers, as to my knowledge - please correct me if   
   > I am wrong -, references never refer to NOWHERE.   
      
   So what? The issue with deref of the NULL pointer is very, very rare, it is not   
   an issue in real world.   
      
   > So what is the realistic answer to THIS problem?? Quitting the SW industry?   
      
   For individual - educating yourself. At least you must comprehend your tool   
   very well, also you must comprehend your platform very well. You can have bad   
   comprehension of some feature group of your tool, but then - sorry - do not use   
   them in your code at all, or take an effort and study them. First - comprehend.   
   Then - design or code. This must be the law.   
      
   For a company - proper hiring policy.   
      
   > cost-efficient, then tell it to us! OK, getting personnel from China at a   
   > cost for 1/10th.   
      
   They are usually very poor specialists. Indians are often better, but a good   
   Indian guy will cost the same as good Austrian guy (well, at least the same as   
   good Slovenian guy).   
      
   > that. So, why not use the so much increased and now levelled CPU power to   
   > define high-level languages?   
      
   They are more complex, and will require the good brains just to comprehend   
   them. Otherwise, people will do some other stupid errors, just due to mis-using   
   the complex language features.   
      
   > By the way: do you ever used PURIFY under UNIX to see the memory leaks?   
      
   I use PREfast on Windows, the static code analyzer for C provided by MS. The   
   memory leak detector is embedded into Windows kernel, just must be activated by   
   a registry flag.   
      
   > Please, do not misunderstand me! I do not say that low-/intermediate-level   
   > languages are rubbish! They are good, but good for experts!   
      
   Correct. For many other tasks, PHP, Java and C# are adequate - due to them   
   being _forgiving_, more forgiving then C. Again no room for, say, Ada.   
      
   Note: you say about "please be more forgiving to bad developers". Then Dmitry,   
   who holds your side in this argument, is speaking about deep theoretical things   
   like the "multiple dispatch" which even average-to-good developer will not   
   understand, and looks like comprehension of such things are necessary to study,   
   say, Eiffel. A paradox.   
      
   > This is the reality, Maxim! It is not an issue that can be marked down and   
   > named and forgotten. It is the real problem we have in the software world   
   > today.   
      
   The problem is due to the idea that you can have good results from poor quality   
   labour force, the idea (yes, the beloved mistake of many PMs) that the 9 women   
   will deliver a child in 1 month, and so on.   
      
   > Microsoft is efficient? Really?? What about comparisons between MS and   
   >other   
   > operating systems? Have you read any?   
      
   Unbiased comparisons treat Windows (modern) as a good quality OS.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)