Marin David Condic wrote:
> I've seen similar things. ;-)
> 
> But ultimately, you're not going to get much better understanding of how 
> to use Ada unless Ada gets used more generally. People who get dumped 
> onto a project done in Ada and then return back to other activities 
> (because Ada is not used extensively, making it a possible career) don't 
> spend enough time there to get good at it & really understand the 
> language. They don't necessarily operate in an environment where there 
> is long-term institutional knowledge built up around what is the best 
> way to do things.
> 
> If Ada got out of its position as being a niche-language and got, say, 
> 20% of the software development market? - there would be a lot more 
> widespread knowledge of "Best Practices" and you wouldn't see as much 
> incorrect featrue usage.
> 
> But that means Ada has to show up in product development and that means 
> that people who think Ada is a good thing have to apply it in developing 
> new & successful products. That takes entrepeneurs. More of us have to 
> do that.
> 
> MDC
> 
> 
> Marc A. Criley wrote:
> 
>>
>> Unfortunately I've found this to be all too true :-(  I've been 
>> involved with fixing up more than one system (long after the original 
>> designers have moved on) that had horrendous misuse of tasking.
>>
>> One had tasks handling the buffering of data in and out of sockets.  A 
>> reasonable application of tasking, yes?
>>
>> Except all the interaction between the tasks and the application 
>> occurred _within_ the 'accept' blocks.  Meaning a message would come 
>> on the socket and into the socket-monitoring task, rendezvous and 
>> block on the buffering task, which would rendezvous and block on the 
>> message processing task, which would generate output that would 
>> rendezvous and block on the output buffering task, which would 
>> rendezvous and block on the output socket transmission task, which 
>> then write out the message, followed by unblock, unblock, unblock, 
>> etc.  I am not making this up.
>>
>> I characterized this as the world's most expensive procedure call chain.
>>
> 
I think the biggest reason for things like this is lack of really good 
books that do a good job of explaining Ada tasking.  We have five or six 
different books lying around the office with names like "Object Oriented 
  Programming in Ada" (which gives a good overview of the basic features 
of Ada, with a few notes on object oriented programming added as an 
after thought), "Ada as a second language", etc.  None do a good job of 
covering advanced features of Ada, such as tasking, or Ada's object 
oriented programming.

JAF