XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Mon, 20 Feb 2006 15:20:22 +0300, Maxim S. Shatskih wrote:   
      
   [ unfortunately this ended up in a language war. I have to apologize to the   
   readers of comp.ai.fuzzy ]   
      
   >     About Ada. The "widespread" of Ada in real-world software business proves   
   > my position and not yours :-)   
      
   The most widespread languages are definitely COBOL and most probably VB.   
   I'm dying to see an OS written in COBOL! As for VB, I have a strong   
   suspicion that everybody saw one! (:-))   
      
   [ Popularity proves nothing, but bad taste. ]   
      
   >> Safety. You need a helper object to ensure freeing the resource [in the   
   >> destructor.] Though this still wouldn't prevent deadlocks. Because just two   
   >> mutexes can create a deadlock.   
   >   
   > So what? Just don't do the stupid errors :)   
      
   Well, flying Airbus or Boeing I wouldn't rely on programmers not making   
   stupid errors. Fortunately, their software is written in Ada, not in K&R C.   
      
   >> Mutex is too low-level. Problems are: deadlocks and priority inversion.   
   >   
   > Once again - don't do stupid things. Priority inversion (and starvations   
   > similar to it) is a real-world problem which immediately arises when 2   
   threads   
   > of different priority use the same mutex.   
      
   Google it for "static analysis", "Ravenscar", "SPARK Ada".   
      
   > The developer must know this.   
      
   And what should know the passenger?   
      
   >>In   
   >> general, mutexes aren't composable. That means: put together two safe,   
   >> tested pieces of code, and you won't be able to say anything useful about   
   >> the combination.   
   >   
   > Most inter-module calls are done with no mutexes held. This is a must. This   
   is   
   > a default - you must not do any, say, API calls with mutexes held. You must   
   not   
   > do callbacks to upper layers while you have any mutexes held. If the things   
   are   
   > otherwise and this is allowed - then this must be documented.   
      
   = not composable. That's the whole point.   
      
   [ When discipline is claimed to be a solution, that implies the tool is   
   wrong. ]   
      
   >> The problem isn't to be able to write something, after all, almost every   
   >> language is Turing-complete. The problem is to manage complexity.   
   >   
   > Language-embedded features are the poor way to manage complexity. They   
   provide   
   > only the illusion of "management", while in reality the complexity is just   
   > pushed somewhere down, and will manifest itself is some very unconvinient way   
   > sooner or later, the way which can be solved on low-level and cannot be   
   solved   
   > on higher levels like the language constructs.   
      
   If that were true, we would still have been programming in hexadecimal   
   codes.   
      
   >> C++ is a bad language, especially because of its types system.   
   >   
   > Very strong type system. Is this bad?   
      
   Strong manifested typing is good, when properly implemented. C++ violates   
   type contracts in several places. For example, when methods re-dispatch.   
   This is a safety breach, because a derived type may override methods you   
   call from your specific [and tested] implementation. C++ has chosen this   
   path, because it does not separate types and classes, so all methods are   
   both dispatching and class-wide.   
      
   [ It is not so that Bjarne did it intentionally, I suppose that the   
   technique I describe was unknown that time. As I said before, there was and   
   still are many problems with theoretical foundations of types system. ]   
      
   >> The core   
   >> problem that there is no distinction between types and classes. As the   
   >> result:   
   >>   
   >> 1. Small value objects cannot have classes (int)   
   >   
   > Why is this bad?   
      
   Any language irregularity adds complexity. OS badly needs small efficient   
   polymorphic objects. Consider all sorts of smart-pointers, arena-pointers,   
   GC-pointers, handles [pointers enforcing accessibility rules] etc.   
      
   > C++ classes are _structure types only_. If you need int as a   
   > class (for what?) - write your own "class Int", it's trivial.   
      
   As a class it will have vtab pointer. As a plain type it will have no   
   dispatching methods [virtual functions.] There is no way to handle it.   
      
   >> 2. Multiple dispatch cannot be implemented   
   >   
   > What is "multiple dispatch" and what real-world, practical advantages will it   
   > provide?   
      
   Write (Where : in out Device; What : Thing);   
      -- Dispatches on both Device and Thing.   
      
   >> 3. Multiple inheritance requires lots of vtab pointers   
   >   
   > Can you imagine the better (in this term of memory load by auxuliary   
   > structures) implementation of multiple inheritance then in C++?   
      
   Yes. The C++ types system design flaw (no separation of types and classes =   
   closures of types sets) enforces specific [of the type] and polymorphic [of   
   the class rooted in the type] objects to have exactly same representation.   
   The rest follows.   
      
   >> 4. Construction model is unsound (no dispatch in c/dtors)   
   >   
   > C++ suggests all dtors to be virtual for all classes which have at least 1   
   > virtual method. So, the problem is solved.   
      
   Please, refer to the C++ standard. You cannot dispatch from a c/dtors. At   
   the same time, all methods are re-dispatching, which is a contract   
   violation and inefficient.   
      
   >>> Linux is safe, distributed, portable, scalable, real-time (with extensions)   
   >>> system,   
   >>   
   >> Where is a smiley? That's a joke, wasn't it?   
   >   
   > No, this is a real-world truth. The major OSes and platforms used everywhere   
   > are written in C or sometimes (and some parts) C++.   
      
   Yes, and because these OSes are notably bad, I conclude that probably it   
   was unwise to write them in C...   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)