* Isn't this in favour of Ada?? @ 2005-07-14 11:34 Erlo Haugen 2005-07-14 14:56 ` Mike Silva ` (2 more replies) 0 siblings, 3 replies; 60+ messages in thread From: Erlo Haugen @ 2005-07-14 11:34 UTC (permalink / raw) http://www.gotw.ca/publications/concurrency-ddj.htm I think so. -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 11:34 Isn't this in favour of Ada?? Erlo Haugen @ 2005-07-14 14:56 ` Mike Silva 2005-07-14 16:11 ` Jeffrey Carter 2005-07-15 14:04 ` Florian Weimer 2005-07-21 13:27 ` Maciej Sobczak 2 siblings, 1 reply; 60+ messages in thread From: Mike Silva @ 2005-07-14 14:56 UTC (permalink / raw) I think so too. Of course the article only mentions Java and C++. Big surprise there. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 14:56 ` Mike Silva @ 2005-07-14 16:11 ` Jeffrey Carter 2005-07-14 18:06 ` Marc A. Criley ` (3 more replies) 0 siblings, 4 replies; 60+ messages in thread From: Jeffrey Carter @ 2005-07-14 16:11 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 1574 bytes --] Mike Silva wrote: > I think so too. Of course the article only mentions Java and C++. Big > surprise there. Everything technical about SW development favors the use of well designed languages such as Ada by SW engineers. Everything economic favors the current system where the construction workers (coders) design the bridges (SW) and choose the materials (languages) to build them with. Adding concurrency to the mix won't change that, though it will probably reduce quality even further. Ada is a language for SW engineers; C and its offspring are languages for coders. Since we allow coders to choose languages, it's not surprising that they choose coders' languages. Even when Ada is used for concurrent systems, Ada's concurrency features are often not used. While technical reasons are often given for such decisions, they rarely are true. Generally, the real reasons are the designers' lack of understanding of concurrency, replacing it with something more familiar. Why don't we allow construction workers to design bridges and choose the materials? Because when they fail, we lose enormous lawsuits, and that more than offsets the savings obtained. Because when they fail, people die in ways that attract the attention of regulators. When the same is true of SW, perhaps we will see a distinction between SW engineers and coders, and Ada will become more prevalent. In the meantime, my experience is that only about 2% of developers are SW engineers, so I'm glad Ada isn't popular. If Ada were popular, it would mean it was badly designed. [-- Attachment #2: spam.vcf --] [-- Type: text/x-vcard, Size: 177 bytes --] begin:vcard fn:Jeffrey Carter n:;Jeffrey Carter email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 16:11 ` Jeffrey Carter @ 2005-07-14 18:06 ` Marc A. Criley 2005-07-15 13:05 ` Marin David Condic 2005-07-19 11:40 ` Erlo Haugen ` (2 subsequent siblings) 3 siblings, 1 reply; 60+ messages in thread From: Marc A. Criley @ 2005-07-14 18:06 UTC (permalink / raw) Jeffrey Carter wrote: > Even when Ada is used for concurrent systems, Ada's concurrency features > are often not used. While technical reasons are often given for such > decisions, they rarely are true. Generally, the real reasons are the > designers' lack of understanding of concurrency, replacing it with > something more familiar. 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. -- Marc A. Criley -- www.mckae.com -- DTraq - XPath In Ada - XML EZ Out ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 18:06 ` Marc A. Criley @ 2005-07-15 13:05 ` Marin David Condic 2005-07-19 17:03 ` James Alan Farrell 0 siblings, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-15 13:05 UTC (permalink / raw) 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. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-15 13:05 ` Marin David Condic @ 2005-07-19 17:03 ` James Alan Farrell 2005-07-19 17:31 ` Ed Falis 2005-07-20 11:49 ` Marin David Condic 0 siblings, 2 replies; 60+ messages in thread From: James Alan Farrell @ 2005-07-19 17:03 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 2671 bytes --] 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 [-- Attachment #2: jfarrell.vcf --] [-- Type: text/x-vcard, Size: 88 bytes --] begin:vcard fn:James Alan Farrell n:Farrell;James org:GrammaTech version:2.1 end:vcard ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 17:03 ` James Alan Farrell @ 2005-07-19 17:31 ` Ed Falis 2005-07-20 11:49 ` Marin David Condic 1 sibling, 0 replies; 60+ messages in thread From: Ed Falis @ 2005-07-19 17:31 UTC (permalink / raw) On Tue, 19 Jul 2005 13:03:55 -0400, James Alan Farrell <jfarrell@nospam.com> wrote: > I think the biggest reason for things like this is lack of really good > books that do a good job of > explaining Ada tasking. Burns & Welling "Concurrency in Ada". ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 17:03 ` James Alan Farrell 2005-07-19 17:31 ` Ed Falis @ 2005-07-20 11:49 ` Marin David Condic 1 sibling, 0 replies; 60+ messages in thread From: Marin David Condic @ 2005-07-20 11:49 UTC (permalink / raw) Tasking does tend to suffer in that regard. A good text that not only had step-by-step introduction of tasking but a bunch of practical examples of when to use it (and when not to) would be a good thing. There are web pages that would publish it if it was reasonably well done. MDC James Alan Farrell wrote: > 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 -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 16:11 ` Jeffrey Carter 2005-07-14 18:06 ` Marc A. Criley @ 2005-07-19 11:40 ` Erlo Haugen 2005-07-19 17:10 ` Jeffrey Carter 2005-07-19 15:41 ` Dan McLeran 2005-07-22 7:30 ` Erlo Haugen 3 siblings, 1 reply; 60+ messages in thread From: Erlo Haugen @ 2005-07-19 11:40 UTC (permalink / raw) Jeffrey Carter wrote: > > Why don't we allow construction workers to design bridges and choose the > materials? Because when they fail, we lose enormous lawsuits, and that > more than offsets the savings obtained. Because when they fail, people > die in ways that attract the attention of regulators. When the same is > true of SW, perhaps we will see a distinction between SW engineers and > coders, and Ada will become more prevalent. > Guess your are right here. > In the meantime, my experience is that only about 2% of developers are > SW engineers, so I'm glad Ada isn't popular. If Ada were popular, it > would mean it was badly designed. So, us morons who don't have have university degree shouldn't be allowed to use Ada? Anything popular is badly designed, is that Your view? -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 11:40 ` Erlo Haugen @ 2005-07-19 17:10 ` Jeffrey Carter 0 siblings, 0 replies; 60+ messages in thread From: Jeffrey Carter @ 2005-07-19 17:10 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 630 bytes --] Erlo Haugen wrote: > So, us morons who don't have have university degree shouldn't be allowed > to use Ada? In my experience, education has little to do with it. The qualities that distinguish SW engineers from coders seem to be intrinsic. No amount of education will convince most coders to use Ada, while those who have the makings of SW engineers tend to adopt it once they become aware of it. I certainly don't object to coders using Ada. > Anything popular is badly designed, is that Your view? From the point of view of SW engineering that tends to be true. C may be perfectly designed from a coders' perspective. [-- Attachment #2: spam.vcf --] [-- Type: text/x-vcard, Size: 177 bytes --] begin:vcard fn:Jeffrey Carter n:;Jeffrey Carter email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 16:11 ` Jeffrey Carter 2005-07-14 18:06 ` Marc A. Criley 2005-07-19 11:40 ` Erlo Haugen @ 2005-07-19 15:41 ` Dan McLeran 2005-07-19 17:17 ` Adrien Plisson 2005-07-20 2:22 ` Jeffrey Carter 2005-07-22 7:30 ` Erlo Haugen 3 siblings, 2 replies; 60+ messages in thread From: Dan McLeran @ 2005-07-19 15:41 UTC (permalink / raw) I don't think one can say that SW engineers use Ada and everyone else is a coder. I'm sure we all know of some skilled people who do not promote or use Ada. Having said that, I do believe that Ada is the best tool out there for the creation of software that does what the engineer/coder intended, which makes me wonder why programmers as a whole do not gravitate towards the best tools available. Is syntax that important? I'm starting to wonder what's wrong with SW engineers. There seems to be an almost religious attachment to programming language. I don't perceive the same kind of behaviour out of other engineering disciplines. You'd be hard pressed to find a structural engineer who refuses to use a superior tool/building process/etc. just because he/she is used to doing things a different way. This kind of thought process seemingly doesn't enter their minds. As long as cost is not prohibitive, these engineers will use the best tools/materials for their job because they don't want their bridges and buildings collapsing on us. Do SW engineers not feel the same sense of responsibility for their products? In our (programming) community there seems to be alot of zealotry about the tools we use to build software. Since when does personal preference count for anything when the goal is a quality product that behaves as expected by the customer? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 15:41 ` Dan McLeran @ 2005-07-19 17:17 ` Adrien Plisson 2005-07-20 2:22 ` Jeffrey Carter 1 sibling, 0 replies; 60+ messages in thread From: Adrien Plisson @ 2005-07-19 17:17 UTC (permalink / raw) Dan McLeran wrote: > I don't think one can say that SW engineers use Ada and everyone else > is a coder. I'm sure we all know of some skilled people who do not > promote or use Ada. Having said that, I do believe that Ada is the best > tool out there for the creation of software that does what the > engineer/coder intended, which makes me wonder why programmers as a > whole do not gravitate towards the best tools available. Is syntax that > important? IMHO, it's not only a syntax problem. Ada may be the best tool available for some development task, but unfortunately NOT for ALL develoment tasks. for example, i often use Python: its interpreter allows me to enter an expresion and directly see the result, i can't do that with Ada. every language has its own advantages and weaknesses, which does not make them useful for all tasks. some languages can be used in more contexts, while others are niche languages. the old adage "use the right tool for the right job" applies to software development too. unfortunately, people confuse "the right tool" with "the ultimate tool" and tend to always use the same languages whatever the context, even if the language is clearly not apropriate for their tasks. > I'm starting to wonder what's wrong with SW engineers. you should ask: what's wrong with computing in general ? the computing field is directed by worst quality softwares running on poorly designed platforms inheriting from bad management decisions made 20 years ago. this is not the best house for breeding software engineers. newcomers in the field can't tell the difference between the good and the bad because they have only been in contact with the bad. how many people i know have never touched anything else than a PC under Windows ? they can't even imagine there could be something else ! as for life on earth, diversity is the key: diversity is disappearing, leaving only consanguine degenerates. > [...] > Do SW engineers not feel the same sense of > responsibility for their products? In our (programming) community there > seems to be alot of zealotry about the tools we use to build software. > Since when does personal preference count for anything when the goal is > a quality product that behaves as expected by the customer? not every software engineer has to write safety critical softwares, so people tend to minimize the importance of product quality (generally to maximise profit). if software quality had an impact on engineers life (i mean, revenue), they would take it more seriously. -- rien ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 15:41 ` Dan McLeran 2005-07-19 17:17 ` Adrien Plisson @ 2005-07-20 2:22 ` Jeffrey Carter 2005-07-20 5:13 ` Dan McLeran 1 sibling, 1 reply; 60+ messages in thread From: Jeffrey Carter @ 2005-07-20 2:22 UTC (permalink / raw) Dan McLeran wrote: > I don't think one can say that SW engineers use Ada and everyone else > is a coder. One could say that. It wouldn't be correct, but one could say that. I, however, didn't say that. I said that Ada is unpopular because it's a SW engineering language, and most developers are coders. -- Jeff Carter "To Err is human, to really screw up, you need C++!" St�phane Richard 63 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-20 2:22 ` Jeffrey Carter @ 2005-07-20 5:13 ` Dan McLeran 0 siblings, 0 replies; 60+ messages in thread From: Dan McLeran @ 2005-07-20 5:13 UTC (permalink / raw) You're right, I just said it out loud to myself and it worked! ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 16:11 ` Jeffrey Carter ` (2 preceding siblings ...) 2005-07-19 15:41 ` Dan McLeran @ 2005-07-22 7:30 ` Erlo Haugen 2005-07-22 13:12 ` Marc A. Criley 2005-07-22 15:49 ` Jeffrey Carter 3 siblings, 2 replies; 60+ messages in thread From: Erlo Haugen @ 2005-07-22 7:30 UTC (permalink / raw) Jeffrey Carter wrote: > Ada is a language for SW engineers; C and its offspring are languages > for coders. Since we allow coders to choose languages, it's not > surprising that they choose coders' languages. > But isn't engineering (at its best) supposed to be independent of the language chosen? > > Why don't we allow construction workers to design bridges and choose the > materials? Because when they fail, we lose enormous lawsuits, and that > more than offsets the savings obtained. Because when they fail, people > die in ways that attract the attention of regulators. When the same is > true of SW, perhaps we will see a distinction between SW engineers and > coders, and Ada will become more prevalent. > You have a point, but most software is not like bridges, it's more like garden houses: if something goes wrong, it is inconvenient, but not fatal. I do hope that adequate engineering processes are used for critical software. -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 7:30 ` Erlo Haugen @ 2005-07-22 13:12 ` Marc A. Criley 2005-07-22 13:36 ` Erlo Haugen 2005-07-22 15:49 ` Jeffrey Carter 1 sibling, 1 reply; 60+ messages in thread From: Marc A. Criley @ 2005-07-22 13:12 UTC (permalink / raw) Erlo Haugen wrote: > But isn't engineering (at its best) supposed to be independent of the > language chosen? Nope. Engineering is focused on implementation. A critical component of software engineering therefore is implementation language. I've ceased agreeing with the PC statement that "Good software engineers can write good software in any language." Does Tiger Woods buy his clubs at Wal-Mart? A good golfer... Do Formula One racing teams get their tools from K-Mart? A good mechanic... -- Marc A. Criley -- www.mckae.com -- DTraq - XPath In Ada - XML EZ Out ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 13:12 ` Marc A. Criley @ 2005-07-22 13:36 ` Erlo Haugen 2005-07-22 14:24 ` Dan McLeran ` (2 more replies) 0 siblings, 3 replies; 60+ messages in thread From: Erlo Haugen @ 2005-07-22 13:36 UTC (permalink / raw) Marc A. Criley wrote: > Erlo Haugen wrote: > >> But isn't engineering (at its best) supposed to be independent of the >> language chosen? > > > Nope. Engineering is focused on implementation. A critical component > of software engineering therefore is implementation language. > So, a design dependends on implementation? > I've ceased agreeing with the PC statement that "Good software engineers > can write good software in any language." > > Does Tiger Woods buy his clubs at Wal-Mart? A good golfer... > > Do Formula One racing teams get their tools from K-Mart? A good > mechanic... Those are craftsmen, not designers. Naturally they choose the best possible tool, but the guy that designed the golf ball or car does not need to know if the club is bought at K-Mart or if the wrench is made from steel or titanium. Neither does the designer of the software neccessarily need to know which language is chosen to implement the design. > > -- Marc A. Criley > -- www.mckae.com > -- DTraq - XPath In Ada - XML EZ Out -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 13:36 ` Erlo Haugen @ 2005-07-22 14:24 ` Dan McLeran 2005-07-22 14:29 ` Bob Spooner 2005-07-22 18:01 ` Marc A. Criley 2 siblings, 0 replies; 60+ messages in thread From: Dan McLeran @ 2005-07-22 14:24 UTC (permalink / raw) But does the guy who designs the golf clubs that sell for $40 believe that his product is pro-tour worthy? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 13:36 ` Erlo Haugen 2005-07-22 14:24 ` Dan McLeran @ 2005-07-22 14:29 ` Bob Spooner 2005-07-23 13:02 ` Ludovic Brenta 2005-07-22 18:01 ` Marc A. Criley 2 siblings, 1 reply; 60+ messages in thread From: Bob Spooner @ 2005-07-22 14:29 UTC (permalink / raw) "Erlo Haugen" <"elh whirlpool terma spot com"> wrote in message news:42e0f666$0$54741$edfadb0f@dread12.news.tele.dk... > Marc A. Criley wrote: > > Erlo Haugen wrote: > > > >> But isn't engineering (at its best) supposed to be independent of the > >> language chosen? > > > > > > Nope. Engineering is focused on implementation. A critical component > > of software engineering therefore is implementation language. > > > > So, a design dependends on implementation? > Yes, design does depend on implementation. It is impossible to completely separate design from implementation because the design has to be built. The design is constrained by the components available to realize the design. Bridges are designed to use the structural members available that can economically span the space where the bridge is to be built while supporting the load it needs to carry. Bob ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 14:29 ` Bob Spooner @ 2005-07-23 13:02 ` Ludovic Brenta 0 siblings, 0 replies; 60+ messages in thread From: Ludovic Brenta @ 2005-07-23 13:02 UTC (permalink / raw) "Bob Spooner" <rls19@psu.edu> writes: > "Erlo Haugen" <"elh whirlpool terma spot com"> wrote in message > news:42e0f666$0$54741$edfadb0f@dread12.news.tele.dk... >> Marc A. Criley wrote: >> > Erlo Haugen wrote: >> > >> >> But isn't engineering (at its best) supposed to be independent >> >> of the language chosen? >> > >> > >> > Nope. Engineering is focused on implementation. A critical >> > component of software engineering therefore is implementation >> > language. >> >> So, a design dependends on implementation? > > Yes, design does depend on implementation. It is impossible to > completely separate design from implementation because the design > has to be built. The design is constrained by the components > available to realize the design. Bridges are designed to use the > structural members available that can economically span the space > where the bridge is to be built while supporting the load it needs > to carry. I agree. Architects are physically present at the construction site of buildings they designed. They choose materials, construction method, tools, and, quite often, even the workers who actually do the job. If you want to have a home built, and the architect never shows up at the construction site, does this give you confidence in the architect or the house? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 13:36 ` Erlo Haugen 2005-07-22 14:24 ` Dan McLeran 2005-07-22 14:29 ` Bob Spooner @ 2005-07-22 18:01 ` Marc A. Criley 2 siblings, 0 replies; 60+ messages in thread From: Marc A. Criley @ 2005-07-22 18:01 UTC (permalink / raw) Erlo Haugen wrote: > Marc A. Criley wrote: > >> Nope. Engineering is focused on implementation. A critical component >> of software engineering therefore is implementation language. >> > So, a design dependends on implementation? As noted in other postings, yes, design has to take the implementation environment into account. E.g., does your design exploit concurrency? This can make a difference in your choice of Ada vs Lisp for implementation. >> Does Tiger Woods buy his clubs at Wal-Mart? A good golfer... >> >> Do Formula One racing teams get their tools from K-Mart? A good >> mechanic... > > Those are craftsmen, not designers. Okay, do skyscraper architects use T-squares and pencils? A good architect ... Do commercial aircraft designers use graph paper, a French Curve, and a compass? A good aircraft designer... Remember, we're talking detailed designs sufficient to begin implementation, not Burt Rutan's whiteboard. -- Marc A. Criley -- www.mckae.com -- DTraq - XPath In Ada -- XML EZ Out ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 7:30 ` Erlo Haugen 2005-07-22 13:12 ` Marc A. Criley @ 2005-07-22 15:49 ` Jeffrey Carter 1 sibling, 0 replies; 60+ messages in thread From: Jeffrey Carter @ 2005-07-22 15:49 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 2278 bytes --] Erlo Haugen wrote: >> > But isn't engineering (at its best) supposed to be independent of the > language chosen? Hardly. A bridge is designed to work when constructed of materials with certain characteristics; the design is not independent of the materials. In the SW field, we've been correcting buffer-overflow vulnerabilities in networking code for decades. They're the single most commonly exploited class of error in the code. Yet the people writing networking code in C today are creating new buffer-overflow errors, despite their knowledge of the problem and their desire not to contribute to it. It seems no amount of engineering can overcome the weakness of the material. A SW engineer using C will create better SW than a coder using C, but a SW engineer using Ada will create better SW than a SW engineer using C. There was a posting here just the other day to the effect that no matter how carefully the poster designs his C++ code, he makes errors that he would not have made in Ada. > You have a point, but most software is not like bridges, it's more like > garden houses: if something goes wrong, it is inconvenient, but not > fatal. I do hope that adequate engineering processes are used for > critical software. Unfortunately, I've seen critical SW that is very badly designed, basically taking design techniques that work OK on a student's 300-line program applied to 100s of KLOC of critical code. If there's a ditch, 2 m deep and 2 m wide, on my property between my house and the road, and I want to be able to get my car across it, I can put a couple of beams across and add a roadbed and have a bridge that will serve my purposes. If I need to carry heavy trucks or span the Golden Gate of San Francisco Bay, this design technique is not optimum. You can build such a bridge across the Golden Gate. It involves a lot of piers. It will be much more expensive to build than a better suited design, not meet all desirable objectives (we'll have to give up having large ships moving in and out of the bay), but it will carry traffic across the gap. It will be very difficult and expensive to maintain. What we have in SW are a lot of Golden Gate bridges built using design techniques only suitable for much smaller projects. [-- Attachment #2: spam.vcf --] [-- Type: text/x-vcard, Size: 177 bytes --] begin:vcard fn:Jeffrey Carter n:;Jeffrey Carter email;internet:jeffrey_r_carter-nr [commercial-at] raytheon [period | full stop] com x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 11:34 Isn't this in favour of Ada?? Erlo Haugen 2005-07-14 14:56 ` Mike Silva @ 2005-07-15 14:04 ` Florian Weimer 2005-07-15 21:10 ` Larry Kilgallen 2005-07-21 13:27 ` Maciej Sobczak 2 siblings, 1 reply; 60+ messages in thread From: Florian Weimer @ 2005-07-15 14:04 UTC (permalink / raw) * Erlo Haugen: > http://www.gotw.ca/publications/concurrency-ddj.htm > > I think so. This is hardly new, people have been writing concurrent programs for decades, at least on the server side. I also fail to see Ada's advantages because Ada tasking tends to match poorly to concurrency models supported by operating systems. For example, how can you add a select alternative which waits for activity on a specific file descriptor, without introducing many pointless context switches? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-15 14:04 ` Florian Weimer @ 2005-07-15 21:10 ` Larry Kilgallen 2005-07-18 12:37 ` Marin David Condic 2005-08-04 12:59 ` Florian Weimer 0 siblings, 2 replies; 60+ messages in thread From: Larry Kilgallen @ 2005-07-15 21:10 UTC (permalink / raw) In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: > I also fail to see Ada's advantages because Ada tasking tends to match > poorly to concurrency models supported by operating systems. For > example, how can you add a select alternative which waits for activity > on a specific file descriptor, without introducing many pointless > context switches? I don't know "file descriptor" as an Ada term, but presuming you mean activity on a file, I would use the VMS Lock Manager requesting an AST when there is activity (if I were creating an Ada implementation). ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-15 21:10 ` Larry Kilgallen @ 2005-07-18 12:37 ` Marin David Condic 2005-07-18 12:57 ` Ed Falis 2005-08-04 12:59 ` Florian Weimer 1 sibling, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-18 12:37 UTC (permalink / raw) I think it would be an improvement for Ada if it had a mechanism for defining its own interrupts and/or attaching them to various system signals. (Something like an exception, but where the handler ends up being a task entry or protected type procedure call) The mechanisms currently in place are typically pretty good for bare-board programming & connecting to some hardware interrupt, but I'd like a mechanism for defining my own. One use would be to isolate a hardware interrupt behind an abstraction so that it can be simulated off of the target machine. If a hardware interrupt were translated to some abstraction like an exception (call it a "signal"?) I could write a "signal handler" the way I write a hardware interrupt handler, but then be able to run it on a PC by writing some low-level simulation code that triggered the "signal" rather than having the hardware interrupt trigger it. MDC Larry Kilgallen wrote: > > I don't know "file descriptor" as an Ada term, but presuming you mean > activity on a file, I would use the VMS Lock Manager requesting an AST > when there is activity (if I were creating an Ada implementation). -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-18 12:37 ` Marin David Condic @ 2005-07-18 12:57 ` Ed Falis 2005-07-18 13:18 ` Marin David Condic 0 siblings, 1 reply; 60+ messages in thread From: Ed Falis @ 2005-07-18 12:57 UTC (permalink / raw) On Mon, 18 Jul 2005 08:37:56 -0400, Marin David Condic <nobody@noplace.com> wrote: > I think it would be an improvement for Ada if it had a mechanism for > defining its own interrupts and/or attaching them to various system > signals. (Something like an exception, but where the handler ends up > being a task entry or protected type procedure call) The mechanisms > currently in place are typically pretty good for bare-board programming > & connecting to some hardware interrupt, but I'd like a mechanism for > defining my own. > With GNAT, the RM mechanisms for handling interrupts are used for signals on "native" platforms, so you should be able to do something like what you want now. - Ed ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-18 12:57 ` Ed Falis @ 2005-07-18 13:18 ` Marin David Condic 2005-07-18 14:12 ` Ed Falis 0 siblings, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-18 13:18 UTC (permalink / raw) Yes and No. Yes, you can tie an interrupt handler to a system signal as if it were the same as a hardware interrupt. No, in that I'd like another layer of abstraction. I want to separate the system dependent signal from the system-independent response. Think about it this way: Interfacing to hardware these days typically involves three things: Reading from some special addresses, writing to some special addresses and responding to some hardware interrupts. So I might isolate my hardware beneath a package that looks like this: package HW_Isolator is Some_Interrupt : signal ; -- Not really Ada - but like an exception. procedure Read (blah) ; procedure Write (blah) ; end HW_Isolator ; If I have some way of connecting task entries or protected type procedures to "Sime_Interrupt" and have a language mechanism similar to exception propogation (as in "raise Some_Interrupt ;") then beneath the package HW_Isolator I can either a) connect Some_Interrupt directly to the hardware or b) connect it to a simulation of the hardware running on a PC. My embedded code othewrwise functions identically running on the real processor and running in an off-line simulation. Presumably, having the ability to do something like "raise Some_Interrupt ;" anywhere in your code and have it asynchronously trigger execution of some other logic would be of advantage beyond hardware isolation, but I have not given that much thought. Perhaps it might be viewed as "Dangerous" as well? MDC Ed Falis wrote: > > With GNAT, the RM mechanisms for handling interrupts are used for > signals on "native" platforms, so you should be able to do something > like what you want now. > > - Ed -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-18 13:18 ` Marin David Condic @ 2005-07-18 14:12 ` Ed Falis 2005-07-19 12:51 ` Marin David Condic 0 siblings, 1 reply; 60+ messages in thread From: Ed Falis @ 2005-07-18 14:12 UTC (permalink / raw) It's certainly possible to import the "kill" routine to raise a signal. But of course you would have a different "interrupt" number for native and target, as well as needing explicit code somewhere to call kill. So the code would have to be slightly different. But I can't really think of any magic that could hide that. - Ed ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-18 14:12 ` Ed Falis @ 2005-07-19 12:51 ` Marin David Condic 2005-07-19 18:08 ` Robert A Duff 0 siblings, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-19 12:51 UTC (permalink / raw) Well, if I thought about it long enough, I could probably figure out some way of disconnecting the interrupt from the code it has to trigger using only existing Ada mechanisms. What I fear is that it would introduce either too much inefficiency or not provide for uninterruptability that may be needed by an ISR. I suppose it wouldn't hurt too much if you actually shielded the ISR beneath some hardware abstraction layer & kept it small, providing most of the "Real" work has to happen above it. (Let it grab data and propogate a message of some sort?) But then you're really not making a provision to run all of the software for an embedded system on some workstation platform in an off-line way. It would be better with a language mechanism, but I don't know if it is either too complicated or of too narrow an interest to be worth a language update. MDC Ed Falis wrote: > It's certainly possible to import the "kill" routine to raise a > signal. But of course you would have a different "interrupt" number > for native and target, as well as needing explicit code somewhere to > call kill. So the code would have to be slightly different. But I > can't really think of any magic that could hide that. > > - Ed -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 12:51 ` Marin David Condic @ 2005-07-19 18:08 ` Robert A Duff 2005-07-20 5:12 ` Simon Wright 2005-07-20 12:26 ` Marin David Condic 0 siblings, 2 replies; 60+ messages in thread From: Robert A Duff @ 2005-07-19 18:08 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > Well, if I thought about it long enough, I could probably figure out > some way of disconnecting the interrupt from the code it has to trigger > using only existing Ada mechanisms. What I fear is that it would > introduce either too much inefficiency or not provide for > uninterruptability that may be needed by an ISR. I suppose it wouldn't > hurt too much if you actually shielded the ISR beneath some hardware > abstraction layer & kept it small, providing most of the "Real" work has > to happen above it. (Let it grab data and propogate a message of some > sort?) But then you're really not making a provision to run all of the > software for an embedded system on some workstation platform in an > off-line way. > > It would be better with a language mechanism, but I don't know if it is > either too complicated or of too narrow an interest to be worth a > language update. The problem you're talking about is "How to deal with cases where you need to write different code for different platforms." If the language is well designed, and the compilers aren't too buggy, this will happen fairly rarely. Interrupt handling is inherently platform specific, so this is one case where you'll need platform-specific code. The usual solutions are to use a preprocessor of some sort, or to write different versions of the same source file, and have the build process select among them. So I think no interrupt-specific language mechanism is warranted here. I agree with you that it would be nice to have a way to trigger an interrupt under program control. - Bob ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 18:08 ` Robert A Duff @ 2005-07-20 5:12 ` Simon Wright 2005-07-20 15:37 ` Robert A Duff 2005-07-20 12:26 ` Marin David Condic 1 sibling, 1 reply; 60+ messages in thread From: Simon Wright @ 2005-07-20 5:12 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > I agree with you that it would be nice to have a way to trigger an > interrupt under program control. _If_ you are running VxWorks on a VME-based system, you can call sysBusIntGen(). ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-20 5:12 ` Simon Wright @ 2005-07-20 15:37 ` Robert A Duff 2005-07-21 12:15 ` Marin David Condic 0 siblings, 1 reply; 60+ messages in thread From: Robert A Duff @ 2005-07-20 15:37 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Robert A Duff <bobduff@shell01.TheWorld.com> writes: > > > I agree with you that it would be nice to have a way to trigger an > > interrupt under program control. > > _If_ you are running VxWorks on a VME-based system, you can call > sysBusIntGen(). I meant an Ada feature to trigger an interrupt. Yes, on most systems, there's a way to do it. It would be nice to have a portable Ada name for this procedure. - Bob ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-20 15:37 ` Robert A Duff @ 2005-07-21 12:15 ` Marin David Condic 2005-07-21 15:32 ` Robert A Duff 0 siblings, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-21 12:15 UTC (permalink / raw) Besides, this can only work if you have an operating system. If you *are* the operating system, you'd have to do something to bump the hardware to make an interrupt happen and this may or may not be possible in all cases. This is why I say if Ada had something like a "signal" entity that is typically tied to an interrupt, but (since its an Ada thing) can be triggered by some Ada mechanism, then you've got the problem solved. You could probably "Roll Your Own" - but I'm not sure how to do that and still utilize Ada's normal mechanisms for interrupt processing. MDC Robert A Duff wrote: > > I meant an Ada feature to trigger an interrupt. Yes, on most systems, > there's a way to do it. It would be nice to have a portable Ada name > for this procedure. > > - Bob -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-21 12:15 ` Marin David Condic @ 2005-07-21 15:32 ` Robert A Duff 0 siblings, 0 replies; 60+ messages in thread From: Robert A Duff @ 2005-07-21 15:32 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > Besides, this can only work if you have an operating system. It *can* work without an operating system. >... If you > *are* the operating system, you'd have to do something to bump the > hardware to make an interrupt happen Right. >... and this may or may not be possible > in all cases. It's possible for many interrupts on many systems, with or without an OS. Many machines have a "trigger interrupt" instruction. I wouldn't insist that the "trigger interrupt" Ada routine be completely portable. After all, the names of the interrupts are inherently nonportable. It's still useful to have a standard procedure, for those systems where it can work. I'd define it to raise an exception for interrupts that cannot be triggered.uun >... This is why I say if Ada had something like a "signal" > entity that is typically tied to an interrupt, but (since its an Ada > thing) can be triggered by some Ada mechanism, then you've got the > problem solved. You could probably "Roll Your Own" - but I'm not sure > how to do that and still utilize Ada's normal mechanisms for interrupt > processing. I think such a signal mechanism would add some inefficiency. Perhaps not much, but when you're using interrupts on a bare machine, you want to be as close to the metal as possible, and Ada's current design allows for that. I suspect that rolling your own will give better results, because then the programmer is in charge of the efficiency tradeoffs, and the programmer can take advantage of the particular systems of interest, whereas the language designer has to be portable to pretty much every machine under the Sun. - Bob ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-19 18:08 ` Robert A Duff 2005-07-20 5:12 ` Simon Wright @ 2005-07-20 12:26 ` Marin David Condic 2005-10-27 7:20 ` Robert I. Eachus 1 sibling, 1 reply; 60+ messages in thread From: Marin David Condic @ 2005-07-20 12:26 UTC (permalink / raw) Yes, interrupt handling is platform specific, but since Ada found a way to connect a protected procedure to an interrupt, it would seem that some similar mechanism could be invented to translate a platform specific interrupt into a portable representation. I don't see how this wouldn't be in the general spirit of Ada - especially if I can hide the hardware connection in a package BODY so it can be substituted for different platforms. (Or do I need to raise the whole issue of conditional compilation again? ;-) It doesn't seem like a big leap to have some language defined "signal" abstraction that could be either hardware triggered, OS triggered or software triggered so that the protected procedure could do what it is currently doing to connect to an interrupt (connecting to the "signal" abstraction instead), but you could hide the triggering mechanism under a package body somewhere. I'm not looking to avoid having to do some code substitution between a target machine and a simulation. What I'm looking for is a mechanism that lets you hide the SOURCE of the interrupt in a package BODY so that the embedded executive developer and the workstation simulation developer can both work from a common specification and all we have to do to get off the target and on to the simulation is substitute one package body. With Ada as it stands, I'm not sure I can do that without some significant gyrations. A language defined "signal" would seem to provide a simple mechanism for doing that. MDC Robert A Duff wrote: > > The problem you're talking about is "How to deal with cases where you > need to write different code for different platforms." If the language > is well designed, and the compilers aren't too buggy, this will happen > fairly rarely. Interrupt handling is inherently platform specific, so > this is one case where you'll need platform-specific code. The usual > solutions are to use a preprocessor of some sort, or to write different > versions of the same source file, and have the build process select > among them. > > So I think no interrupt-specific language mechanism is warranted here. > > I agree with you that it would be nice to have a way to trigger an > interrupt under program control. > > - Bob -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "The Christian ideal has not been tried and found wanting. It has been found difficult; and left untried." -- G. K. Chesterton ====================================================================== ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-20 12:26 ` Marin David Condic @ 2005-10-27 7:20 ` Robert I. Eachus 0 siblings, 0 replies; 60+ messages in thread From: Robert I. Eachus @ 2005-10-27 7:20 UTC (permalink / raw) Marin David Condic wrote: > It doesn't seem like a big leap to have some language defined "signal" > abstraction that could be either hardware triggered, OS triggered or > software triggered so that the protected procedure could do what it is > currently doing to connect to an interrupt (connecting to the "signal" > abstraction instead), but you could hide the triggering mechanism under > a package body somewhere. > > I'm not looking to avoid having to do some code substitution between a > target machine and a simulation. What I'm looking for is a mechanism > that lets you hide the SOURCE of the interrupt in a package BODY so that > the embedded executive developer and the workstation simulation > developer can both work from a common specification and all we have to > do to get off the target and on to the simulation is substitute one > package body. With Ada as it stands, I'm not sure I can do that without > some significant gyrations. A language defined "signal" would seem to > provide a simple mechanism for doing that. Hmmm... If I wanted to do this in a platform independent manner, I'd have a package containing an enumeration type that provided the interrupt names. If you prefer, you could have an integer type with deferred constants for some common useful names. Also in the package would be a generic package with two procedures for binding and unbinding the interrupt to a task or protected object entry. The choice of generic formals I leave up to you. I'd go for a formal parameterless procedure for the action to be called. That lets you use a procedure in a protected object. And I would have the package body maintain a stack of bindings that resides in the non-generic enclosing package. However, I would have the unbind routine raise an error if it is not from the generic instance that did the binding. Oh, and the generic body should use finalization to insure that when the scope in which the generic package is instantiated is left, the interrupt is unbound if necessary. At the other end of the spectrum would be an implementation where instantiating the generic did the binding, and the unbinding occurs when the enclosing scope is left. So the generic takes two (generic)parameters an interrupt name or number and the procedure or entry to be called. Not as powerful an abstraction, but easier to use. In practice though, most interrupt bindings will have the same scope as the main program... RIE ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-15 21:10 ` Larry Kilgallen 2005-07-18 12:37 ` Marin David Condic @ 2005-08-04 12:59 ` Florian Weimer 2005-08-05 14:29 ` Larry Kilgallen 1 sibling, 1 reply; 60+ messages in thread From: Florian Weimer @ 2005-08-04 12:59 UTC (permalink / raw) * Larry Kilgallen: > In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: > >> I also fail to see Ada's advantages because Ada tasking tends to match >> poorly to concurrency models supported by operating systems. For >> example, how can you add a select alternative which waits for activity >> on a specific file descriptor, without introducing many pointless >> context switches? > > I don't know "file descriptor" as an Ada term, but presuming you mean > activity on a file, I would use the VMS Lock Manager requesting an AST > when there is activity (if I were creating an Ada implementation). But my point was that this has to be done by the implementor. It is something that is hard to resolve at a library level (unless you are willing to take the costs of a few additional context switches, of course). ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-04 12:59 ` Florian Weimer @ 2005-08-05 14:29 ` Larry Kilgallen 2005-08-05 16:58 ` Florian Weimer 0 siblings, 1 reply; 60+ messages in thread From: Larry Kilgallen @ 2005-08-05 14:29 UTC (permalink / raw) In article <87ll3hyi14.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: > * Larry Kilgallen: > >> In article <8764vcdv2f.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: >> >>> I also fail to see Ada's advantages because Ada tasking tends to match >>> poorly to concurrency models supported by operating systems. For >>> example, how can you add a select alternative which waits for activity >>> on a specific file descriptor, without introducing many pointless >>> context switches? >> >> I don't know "file descriptor" as an Ada term, but presuming you mean >> activity on a file, I would use the VMS Lock Manager requesting an AST >> when there is activity (if I were creating an Ada implementation). > > But my point was that this has to be done by the implementor. It is > something that is hard to resolve at a library level (unless you are > willing to take the costs of a few additional context switches, of > course). By "implementor" I presume you mean the person who builds an Ada compiler and runtime system for a particular operating system. The fact that it is hard to build a compiler is not my problem unless I am trying to build the compiler myself. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-05 14:29 ` Larry Kilgallen @ 2005-08-05 16:58 ` Florian Weimer 2005-08-05 23:15 ` Larry Kilgallen ` (3 more replies) 0 siblings, 4 replies; 60+ messages in thread From: Florian Weimer @ 2005-08-05 16:58 UTC (permalink / raw) * Larry Kilgallen: >>>> I also fail to see Ada's advantages because Ada tasking tends to match >>>> poorly to concurrency models supported by operating systems. For >>>> example, how can you add a select alternative which waits for activity >>>> on a specific file descriptor, without introducing many pointless >>>> context switches? >>> >>> I don't know "file descriptor" as an Ada term, but presuming you mean >>> activity on a file, I would use the VMS Lock Manager requesting an AST >>> when there is activity (if I were creating an Ada implementation). >> >> But my point was that this has to be done by the implementor. It is >> something that is hard to resolve at a library level (unless you are >> willing to take the costs of a few additional context switches, of >> course). > > By "implementor" I presume you mean the person who builds an Ada > compiler and runtime system for a particular operating system. > The fact that it is hard to build a compiler is not my problem > unless I am trying to build the compiler myself. The original claim in this thread was that Ada is particularly suitable to the concurrency challenges ahead of us (I don't believe that there are any fundamentally new challenges, but let's assume that there are). However, in order to create scalable applications, you have to use some features of today's operating systems, for example I/O multiplexing. I am not aware of any Ada implementation which integrates I/O multiplexing with tasks. Therefore, it seems to me that Ada's tasking is a completely useless burden when developing concurrent applications on mainstream operating systems. Usually, you have to figure out how to work around it realiably, so that the run-time library continues to work. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-05 16:58 ` Florian Weimer @ 2005-08-05 23:15 ` Larry Kilgallen 2005-08-06 4:01 ` tmoran ` (2 subsequent siblings) 3 siblings, 0 replies; 60+ messages in thread From: Larry Kilgallen @ 2005-08-05 23:15 UTC (permalink / raw) In article <877jf02ud1.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: > I am not aware of any Ada implementation which integrates I/O > multiplexing with tasks. Therefore, it seems to me that Ada's tasking > is a completely useless burden when developing concurrent applications > on mainstream operating systems. Usually, you have to figure out how > to work around it realiably, so that the run-time library continues to > work. The DEC Ada package Tasking_Services provides a model for those who want to avoid setting up their own AST entries for calling $QIO and similar services. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-05 16:58 ` Florian Weimer 2005-08-05 23:15 ` Larry Kilgallen @ 2005-08-06 4:01 ` tmoran 2005-08-06 10:28 ` Pascal Obry 2005-08-06 11:02 ` Dmitry A. Kazakov 3 siblings, 0 replies; 60+ messages in thread From: tmoran @ 2005-08-06 4:01 UTC (permalink / raw) > I am not aware of any Ada implementation which integrates I/O > multiplexing with tasks. Therefore, it seems to me that Ada's tasking > is a completely useless burden when developing concurrent applications > on mainstream operating systems. Usually, you have to figure out how > to work around it realiably, so that the run-time library continues to > work. There's an OS called Windows which, while you may not like it, cannot be called non-mainstream. It's mostly based on polling, which works just fine with tasks. Claw has been working fine that way for nearly a decade now. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-05 16:58 ` Florian Weimer 2005-08-05 23:15 ` Larry Kilgallen 2005-08-06 4:01 ` tmoran @ 2005-08-06 10:28 ` Pascal Obry 2005-08-06 10:33 ` Pascal Obry 2005-08-06 11:02 ` Dmitry A. Kazakov 3 siblings, 1 reply; 60+ messages in thread From: Pascal Obry @ 2005-08-06 10:28 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> writes: > The original claim in this thread was that Ada is particularly > suitable to the concurrency challenges ahead of us (I don't believe > that there are any fundamentally new challenges, but let's assume that > there are). However, in order to create scalable applications, you > have to use some features of today's operating systems, for example > I/O multiplexing. And ??? Isn't this like saying that C++ is not suitable to the concurrency challenges because it does not support IO multiplexing? Just use the same library with Ada that you use with C++ for the IO. Reading the C++ RM you certainly won't find a single work about IO multiplexing. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-06 10:28 ` Pascal Obry @ 2005-08-06 10:33 ` Pascal Obry 0 siblings, 0 replies; 60+ messages in thread From: Pascal Obry @ 2005-08-06 10:33 UTC (permalink / raw) Pascal Obry <pascal@obry.net> writes: > And ??? Isn't this like saying that C++ is not suitable to the concurrency > challenges because it does not support IO multiplexing? Just use the same > library with Ada that you use with C++ for the IO. Reading the C++ RM you > certainly won't find a single work about IO multiplexing. Rereading your mail I see that it was related to tasking and IO multiplexing is related to threading. So I withdraw my comments. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-08-05 16:58 ` Florian Weimer ` (2 preceding siblings ...) 2005-08-06 10:28 ` Pascal Obry @ 2005-08-06 11:02 ` Dmitry A. Kazakov 3 siblings, 0 replies; 60+ messages in thread From: Dmitry A. Kazakov @ 2005-08-06 11:02 UTC (permalink / raw) On Fri, 05 Aug 2005 18:58:50 +0200, Florian Weimer wrote: > The original claim in this thread was that Ada is particularly > suitable to the concurrency challenges ahead of us (I don't believe > that there are any fundamentally new challenges, but let's assume that > there are). However, in order to create scalable applications, you > have to use some features of today's operating systems, for example > I/O multiplexing. Which is a case of more general waiting for multiple events. The problem is that multiple-wait is a too low level mechanism. It is not very clear how to map it on entry calls and accept. > I am not aware of any Ada implementation which integrates I/O > multiplexing with tasks. Therefore, it seems to me that Ada's tasking > is a completely useless burden when developing concurrent applications > on mainstream operating systems. Usually, you have to figure out how > to work around it realiably, so that the run-time library continues to > work. I disagree. Multitasking is more than just multiplexed I/O. If you look at Windows (sort of mainstream) you find dozens of calls starting a thread. Among them only 1 or 2 are actually usable. The synchronization mechanisms Windows offers are all too low level. So for our C++ project of a middleware (heavily multitasking), we end up with developing a library that mimics Ada's rendezvous. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-14 11:34 Isn't this in favour of Ada?? Erlo Haugen 2005-07-14 14:56 ` Mike Silva 2005-07-15 14:04 ` Florian Weimer @ 2005-07-21 13:27 ` Maciej Sobczak 2005-07-22 7:39 ` Erlo Haugen 2 siblings, 1 reply; 60+ messages in thread From: Maciej Sobczak @ 2005-07-21 13:27 UTC (permalink / raw) Erlo Haugen wrote: > http://www.gotw.ca/publications/concurrency-ddj.htm > > I think so. I don't think so. I mean - the article is neutral with regard to Ada, and not only because it does not mention "Ada" at all. The article is about the fact that future hardware platforms will tend to have more and more parallelism, no matter whether this will be used by software or not. Actually, this happens already, even on popular desktop platforms. The problem that you seem to forget about is that all the factors that are used today for choosing the language (some factors are technical, some not, but that does not matter) will be still in use tomorrow. For example, if some project chooses Java, it does so independent of whether the program will be running on Hyper Threading processor or not - so the increased concurrency capabilities of the target platform has no impact on the language chosen for implementation. In general, programmers will not rush to change their languages just because the multicore CPUs will become prevalent. This article is therefore about raising the awareness of programmers that concurrency is the only way to benefit from new hardware, which is very far from saying that people should move to another language - be it Ada or whatever else. And since the author is involved in the C++ standardization process, I'd rather read this article as a "good-source" prediction that more effort will be put into standardizing the relation between C++ and multithreading (which already happens). The *only* way it could be in favour of Ada is to reuse the experience of the Ada community when defining threading for C++ (I'm not sure whether this will be the case or not), but I don't think that this kind of "favour" is what you really mean. ;) -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-21 13:27 ` Maciej Sobczak @ 2005-07-22 7:39 ` Erlo Haugen 2005-07-22 9:29 ` Maciej Sobczak 0 siblings, 1 reply; 60+ messages in thread From: Erlo Haugen @ 2005-07-22 7:39 UTC (permalink / raw) Maciej Sobczak wrote: > Erlo Haugen wrote: > >> http://www.gotw.ca/publications/concurrency-ddj.htm >> >> I think so. > > > I don't think so. I mean - the article is neutral with regard to Ada, > and not only because it does not mention "Ada" at all. > > The article is about the fact that future hardware platforms will tend > to have more and more parallelism, no matter whether this will be used > by software or not. Actually, this happens already, even on popular > desktop platforms. > The problem that you seem to forget about is that all the factors that > are used today for choosing the language (some factors are technical, > some not, but that does not matter) will be still in use tomorrow. For > example, if some project chooses Java, it does so independent of whether > the program will be running on Hyper Threading processor or not - so the > increased concurrency capabilities of the target platform has no impact > on the language chosen for implementation. In general, programmers will > not rush to change their languages just because the multicore CPUs will > become prevalent. This article is therefore about raising the awareness > of programmers that concurrency is the only way to benefit from new > hardware, which is very far from saying that people should move to > another language - be it Ada or whatever else. And since the author is > involved in the C++ standardization process, I'd rather read this > article as a "good-source" prediction that more effort will be put into > standardizing the relation between C++ and multithreading (which already > happens). > > The *only* way it could be in favour of Ada is to reuse the experience > of the Ada community when defining threading for C++ (I'm not sure > whether this will be the case or not), but I don't think that this kind > of "favour" is what you really mean. ;) > > What i meant to say was that Ada already has the features needed to take advantage of this increasing parallelism, be it hyperthreading og multiple processors, and doing it in a portable way. Threading possibilities are already supplied by most OSes, but by incorporating it as a language standard, it becomes portable. -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 7:39 ` Erlo Haugen @ 2005-07-22 9:29 ` Maciej Sobczak 2005-07-22 10:41 ` Erlo Haugen 0 siblings, 1 reply; 60+ messages in thread From: Maciej Sobczak @ 2005-07-22 9:29 UTC (permalink / raw) Erlo Haugen wrote: > What i meant to say was that Ada already has the features Yes, I understand this. But standardizing threading features in other languages means simply that Ada can lose its competetive edge in this very aspect (portability of concurrent programs). That's why I don't really think that the article in question is "in favour" of Ada. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 9:29 ` Maciej Sobczak @ 2005-07-22 10:41 ` Erlo Haugen 2005-07-22 14:28 ` Alex R. Mosteo 0 siblings, 1 reply; 60+ messages in thread From: Erlo Haugen @ 2005-07-22 10:41 UTC (permalink / raw) Maciej Sobczak wrote: > Erlo Haugen wrote: > >> What i meant to say was that Ada already has the features > > > Yes, I understand this. But standardizing threading features in other > languages means simply that Ada can lose its competetive edge in this > very aspect (portability of concurrent programs). That's why I don't > really think that the article in question is "in favour" of Ada. > > Oh, I see. That might be correct, but for now it seems that Ada is leading the pack. -- Erlo ----- The statements and opinions are mine and does not neccesarily reflect those of my employers ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 10:41 ` Erlo Haugen @ 2005-07-22 14:28 ` Alex R. Mosteo 2005-07-22 15:02 ` Pascal Obry 2005-07-22 15:26 ` Georg Bauhaus 0 siblings, 2 replies; 60+ messages in thread From: Alex R. Mosteo @ 2005-07-22 14:28 UTC (permalink / raw) Erlo Haugen wrote: > Maciej Sobczak wrote: > >> Erlo Haugen wrote: >> >>> What i meant to say was that Ada already has the features >> >> >> >> Yes, I understand this. But standardizing threading features in other >> languages means simply that Ada can lose its competetive edge in this >> very aspect (portability of concurrent programs). That's why I don't >> really think that the article in question is "in favour" of Ada. >> >> > Oh, I see. That might be correct, but for now it seems that Ada is > leading the pack. OpenMP is pushing hard. At least I heard of it a lot, and seems to be pretty standard when it comes to multithreading with C/C++. This edge in Ada may be very well already lost. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 14:28 ` Alex R. Mosteo @ 2005-07-22 15:02 ` Pascal Obry 2005-07-25 9:48 ` Tassilo v. Parseval 2005-07-22 15:26 ` Georg Bauhaus 1 sibling, 1 reply; 60+ messages in thread From: Pascal Obry @ 2005-07-22 15:02 UTC (permalink / raw) "Alex R. Mosteo" <devnull@mailinator.com> writes: > OpenMP is pushing hard. At least I heard of it a lot, and seems to be pretty > standard when it comes to multithreading with C/C++. This edge in Ada may be > very well already lost. Have you looked at an OpenMP C++ enabled application ? OpenMP is a quite intrusive technology (adding lot of directives in comment) this makes the code again less readable. I agree that OpenMP is pushing hard, I'm sure it will gain a very good part of the market... this is just sad when you know the Ada tasking model. We can also talk about MPI compared to the distributed annex :( Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 15:02 ` Pascal Obry @ 2005-07-25 9:48 ` Tassilo v. Parseval 2005-07-25 13:31 ` Adrien Plisson 2005-07-25 16:39 ` Pascal Obry 0 siblings, 2 replies; 60+ messages in thread From: Tassilo v. Parseval @ 2005-07-25 9:48 UTC (permalink / raw) Also sprach Pascal Obry: > "Alex R. Mosteo" <devnull@mailinator.com> writes: > >> OpenMP is pushing hard. At least I heard of it a lot, and seems to be pretty >> standard when it comes to multithreading with C/C++. This edge in Ada may be >> very well already lost. > > Have you looked at an OpenMP C++ enabled application ? OpenMP is a quite > intrusive technology (adding lot of directives in comment) this makes the > code again less readable. I agree that OpenMP is pushing hard, I'm sure it > will gain a very good part of the market... this is just sad when you know the > Ada tasking model. We can also talk about MPI compared to the distributed > annex :( I don't think that Ada tasks and MPI are comparable. MPI is mainly used in the fields of supercomputing. You would certainly not use it as a fork or threads replacement (incidentally, the 1.x standard of MPI did not allow to create processes dynamically) because it would just be too painful. On the other hand it offers things not present in Ada tasks. MPI has its own datatypes that allow you to specify in detail which parts of a data-structure to send to another process, where the appropriate conversions are done by MPI's pack routines. If you have a matrix with rank 100,000 you don't want to share it all and in Ada you'd explicitely have to take precautions against that. Furthermore, MPI allows you to write a program that does a calculation in parallel on your computer and, say, NEC's earth simulator because data-exchange between processors can happen over TCP/IP. So MPI really is a way to distribute one application across a huge distributed system involving workstations that can be anywhere on the internet. Also, there are MPI bindings for Ada which wouldn't be the case if those two had the same niches in mind. Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200); ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 9:48 ` Tassilo v. Parseval @ 2005-07-25 13:31 ` Adrien Plisson 2005-07-25 15:08 ` Jerome Hugues 2005-07-25 16:39 ` Pascal Obry 1 sibling, 1 reply; 60+ messages in thread From: Adrien Plisson @ 2005-07-25 13:31 UTC (permalink / raw) Tassilo v. Parseval wrote: > I don't think that Ada tasks and MPI are comparable. MPI is mainly used > in the fields of supercomputing. You would certainly not use it as a > fork or threads replacement (incidentally, the 1.x standard of MPI did > not allow to create processes dynamically) because it would just be too > painful. the Ada tasking model may be regarded as a form of MPI, when MPI is taken in its broader form of "message passing interface". but MPI taken in its narrower form of "MPI standard <http://www-unix.mcs.anl.gov/mpi/>" is more closely related to Ada Distributed Annex, with which it shares a lot of features, including all those cited below: > On the other hand it offers things not present in Ada tasks. MPI has its > own datatypes that allow you to specify in detail which parts of a > data-structure to send to another process, where the appropriate > conversions are done by MPI's pack routines. If you have a matrix with > rank 100,000 you don't want to share it all and in Ada you'd explicitely > have to take precautions against that. > > Furthermore, MPI allows you to write a program that does a calculation > in parallel on your computer and, say, NEC's earth simulator because > data-exchange between processors can happen over TCP/IP. So MPI really > is a way to distribute one application across a huge distributed system > involving workstations that can be anywhere on the internet. all this should be posible with the Ada distributed annex (annex E of the Ada 95 Reference Manual). a free implementation of this annex for the GNAT compiler is available under the name "Glade" (which is not to be confused with the Gtk+ GUI builder). > Also, there are MPI bindings for Ada which wouldn't be the case if those > two had the same niches in mind. strange enough when one knows about annex E. i think it exists for inter-operability between softwares written using different languages. (Annex E is kinda Ada'ish). (side note: shouldn't PolyORB provide a personality which would allow an Ada Annex E enabled application to inter-operate with a MPI enabled amplication ?) -- rien ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 13:31 ` Adrien Plisson @ 2005-07-25 15:08 ` Jerome Hugues 2005-07-25 15:58 ` Adrien Plisson 0 siblings, 1 reply; 60+ messages in thread From: Jerome Hugues @ 2005-07-25 15:08 UTC (permalink / raw) In article <42e4e8ea$0$3948$ba620e4c@news.skynet.be>, Adrien Plisson wrote: >> Also, there are MPI bindings for Ada which wouldn't be the case if those >> two had the same niches in mind. > > strange enough when one knows about annex E. i think it exists for > inter-operability between softwares written using different languages. > (Annex E is kinda Ada'ish). I'm not sure this was the main goal of annex E, perhaps an Ada "historian" can confirm. Annex B (Interface to Other Languages) seems more relevant for this topic. > (side note: shouldn't PolyORB provide a personality which would allow > an Ada Annex E enabled application to inter-operate with a MPI enabled > amplication ?) PolyORB *c*ould, the "only" point is to provide the corresponding protocol personality (if MPI defines its own protocol), and (I suppose) some way to map Ada calls onto MPI functions (and vice-versa). I'm not an MPI expert. There already exist mappings for CORBA <=> DSA (quite natural in most cases, ses Quinot's paper on CIAO), CORBA/MOM (requires some thinking), so why not for DSA/MPI. *sh*ould is another question .. but we welcome all new contributors onboard ;) -- Jerome ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 15:08 ` Jerome Hugues @ 2005-07-25 15:58 ` Adrien Plisson 2005-07-25 21:03 ` Jerome Hugues 0 siblings, 1 reply; 60+ messages in thread From: Adrien Plisson @ 2005-07-25 15:58 UTC (permalink / raw) Jerome Hugues wrote: > In article <42e4e8ea$0$3948$ba620e4c@news.skynet.be>, Adrien Plisson wrote: > >>strange enough when one knows about annex E. i think it exists for >>inter-operability between softwares written using different languages. >>(Annex E is kinda Ada'ish). > > I'm not sure this was the main goal of annex E, perhaps an Ada > "historian" can confirm. Annex B (Interface to Other Languages) seems > more relevant for this topic. well, technically, you are right: the goal of annex B is interfacing software components written in Ada with other components written in other languages. Annex E has nothing to do with this case. when re-reading my sentence, i see i should have stated it this way: "i think that _MPI bindings for Ada_ exists for inter-operability between woftwares written using different languages". this means making softwares written in different languages, including Ada, communicate through MPI, on a cluster for example. my point was that the Ada Distributed Annex is of no-help when components written in other languages are involved: it is specifically tailored for Ada softwares. which leads us directly to my last point: making ada distributed softwares written using annex E communicate with other distributed softwares written using MPI could be possible through the use of a middleware (like PolyORB) if that middleware is able to translate back and forth between DSA and MPI. >>(side note: shouldn't PolyORB provide a personality which would allow >>an Ada Annex E enabled application to inter-operate with a MPI enabled >>amplication ?) > > PolyORB *c*ould, the "only" point is to provide the corresponding > protocol personality (if MPI defines its own protocol), and (I > suppose) some way to map Ada calls onto MPI functions (and > vice-versa). I'm not an MPI expert. it was just a suggestion thrown here for free. i'm no expert in the field of distributed softwares. i also think it *c*ould be possible, but i don't know if the PolyORB development team ever thought of this. > *sh*ould is another question .. but we welcome all new contributors > onboard ;) it is with deep regret that i have have to announce that, unfortunately, due to the lack of research in time-warping and the impossibility to extend free time (which might not be free as in "free beer"), this new contributor won't be me. -- rien ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 15:58 ` Adrien Plisson @ 2005-07-25 21:03 ` Jerome Hugues 2005-07-26 6:03 ` Tassilo v. Parseval 0 siblings, 1 reply; 60+ messages in thread From: Jerome Hugues @ 2005-07-25 21:03 UTC (permalink / raw) In article <42e50b87$0$30716$ba620e4c@news.skynet.be>, Adrien Plisson wrote: > it was just a suggestion thrown here for free. i'm no expert in the > field of distributed softwares. i also think it *c*ould be possible, > but i don't know if the PolyORB development team ever thought of this. Speaking for myself (as one contributor of the PolyORB project, working on it as part of my PhD), I've already thought about it. But I do not know MPI enough to be sure this is something I want to do, or that would be used by a lot of people. -- Jerome ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 21:03 ` Jerome Hugues @ 2005-07-26 6:03 ` Tassilo v. Parseval 0 siblings, 0 replies; 60+ messages in thread From: Tassilo v. Parseval @ 2005-07-26 6:03 UTC (permalink / raw) Also sprach Jerome Hugues: > In article <42e50b87$0$30716$ba620e4c@news.skynet.be>, Adrien Plisson wrote: > >> it was just a suggestion thrown here for free. i'm no expert in the >> field of distributed softwares. i also think it *c*ould be possible, >> but i don't know if the PolyORB development team ever thought of this. > > Speaking for myself (as one contributor of the PolyORB project, > working on it as part of my PhD), I've already thought about it. > > But I do not know MPI enough to be sure this is something I want to > do, or that would be used by a lot of people. It might be. The Ada folks just have to keep in mind that it could attract the "wrong" people: physicists, mathematicians and the lot. Certainly not people accused of being strong in the fields of software-engineering. ;-) Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200); ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 9:48 ` Tassilo v. Parseval 2005-07-25 13:31 ` Adrien Plisson @ 2005-07-25 16:39 ` Pascal Obry 2005-07-26 5:58 ` Tassilo v. Parseval 1 sibling, 1 reply; 60+ messages in thread From: Pascal Obry @ 2005-07-25 16:39 UTC (permalink / raw) "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes: > I don't think that Ada tasks and MPI are comparable. MPI is mainly used I'm not talking about Ada tasking. I'm talking about Ada distributed annex. > in the fields of supercomputing. You would certainly not use it as a > fork or threads replacement (incidentally, the 1.x standard of MPI did > not allow to create processes dynamically) because it would just be too > painful. Indeed, I'm certainly not saying that one should use Ada tasks + fork in a replacement of MPI :) > Furthermore, MPI allows you to write a program that does a calculation > in parallel on your computer and, say, NEC's earth simulator because > data-exchange between processors can happen over TCP/IP. So MPI really > is a way to distribute one application across a huge distributed system > involving workstations that can be anywhere on the internet. Idem for Ada *distributed* annex. > Also, there are MPI bindings for Ada which wouldn't be the case if those > two had the same niches in mind. That's not a proof! It could mean that somebody wanted to use Ada in a larger project where C++/MPI was used for example. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-25 16:39 ` Pascal Obry @ 2005-07-26 5:58 ` Tassilo v. Parseval 2005-07-26 17:25 ` Pascal Obry 0 siblings, 1 reply; 60+ messages in thread From: Tassilo v. Parseval @ 2005-07-26 5:58 UTC (permalink / raw) Also sprach Pascal Obry: > "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes: > >> I don't think that Ada tasks and MPI are comparable. MPI is mainly used > > I'm not talking about Ada tasking. I'm talking about Ada distributed > annex. My apologies, I must have missed that part. However... >> Furthermore, MPI allows you to write a program that does a calculation >> in parallel on your computer and, say, NEC's earth simulator because >> data-exchange between processors can happen over TCP/IP. So MPI really >> is a way to distribute one application across a huge distributed system >> involving workstations that can be anywhere on the internet. > > Idem for Ada *distributed* annex. Annex E doesn't say much about these things. It's normative in that it says that RPC is to be used (with message passing remaining, at least, an option) and puts some requirements on the three different library units involved. This whole annex is merely a few pages. Compare that with MPI 2.0 which consists of 370 pages. It defines in great depth all the data-types that an MPI conformant systems needs to implement and the whole interface. That makes MPI extremely portable. Whereas Ada's distributed annex leaves almost everything up to the actual implementation. >> Also, there are MPI bindings for Ada which wouldn't be the case if those >> two had the same niches in mind. > > That's not a proof! It could mean that somebody wanted to use Ada in a larger > project where C++/MPI was used for example. Maybe. But the mere fact that you can write a small MPI application in Ada and connect it to an already existing one running elsewhere speaks in favour of MPI. MPI is huge in that in certain fields it is used almost exclusively, owing to the fact that its standard is so comprehensive and non-ambiguous. Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200); ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-26 5:58 ` Tassilo v. Parseval @ 2005-07-26 17:25 ` Pascal Obry 0 siblings, 0 replies; 60+ messages in thread From: Pascal Obry @ 2005-07-26 17:25 UTC (permalink / raw) "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes: > This whole annex is merely a few pages. Compare that with MPI 2.0 which > consists of 370 pages. It defines in great depth all the data-types that > an MPI conformant systems needs to implement and the whole interface. Ada Annex-E says nothing about data type because it supports all the Ada data types described elsewhere. > That makes MPI extremely portable. Agreed. > Maybe. But the mere fact that you can write a small MPI application in > Ada and connect it to an already existing one running elsewhere speaks > in favour of MPI. MPI is huge in that in certain fields it is used > almost exclusively, owing to the fact that its standard is so > comprehensive and non-ambiguous. Agreed too. For interoperability reasons it is certainly good to consider MPI since it is widly used in HPC. But I'm also positive to say that using Ada Distributed Annex is a good alternative to MPI if interoperability is not an issue. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Isn't this in favour of Ada?? 2005-07-22 14:28 ` Alex R. Mosteo 2005-07-22 15:02 ` Pascal Obry @ 2005-07-22 15:26 ` Georg Bauhaus 1 sibling, 0 replies; 60+ messages in thread From: Georg Bauhaus @ 2005-07-22 15:26 UTC (permalink / raw) Alex R. Mosteo wrote: > OpenMP is pushing hard. At least I heard of it a lot, and seems to be > pretty standard when it comes to multithreading with C/C++. This edge in > Ada may be very well already lost. > Except that handling data shared by more than one thread using pragma annotations (OpenMP), and (Ada) a concurrency model built into the type system, scope rules, ... are two very different things IMHO. OpenMP, another kludge to be added to C, C++, and Fortran? If at least they could consider µC++. "A program that consists of an original program, annotated with OpenMP directives." A flexible and powerful solution indeed, you assemble a concurrent program with omp start/end directives around sequences of statements. If my understanding is correct, then OpenMP offers building blocks for parallel programs, to be used via libraries. "throw() must not violate the entry/exit criteria." ... Is OpenMP going to be another instance of what Meyer has described as "debugging an application into existence", only more challenging? ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2005-10-27 7:20 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-14 11:34 Isn't this in favour of Ada?? Erlo Haugen 2005-07-14 14:56 ` Mike Silva 2005-07-14 16:11 ` Jeffrey Carter 2005-07-14 18:06 ` Marc A. Criley 2005-07-15 13:05 ` Marin David Condic 2005-07-19 17:03 ` James Alan Farrell 2005-07-19 17:31 ` Ed Falis 2005-07-20 11:49 ` Marin David Condic 2005-07-19 11:40 ` Erlo Haugen 2005-07-19 17:10 ` Jeffrey Carter 2005-07-19 15:41 ` Dan McLeran 2005-07-19 17:17 ` Adrien Plisson 2005-07-20 2:22 ` Jeffrey Carter 2005-07-20 5:13 ` Dan McLeran 2005-07-22 7:30 ` Erlo Haugen 2005-07-22 13:12 ` Marc A. Criley 2005-07-22 13:36 ` Erlo Haugen 2005-07-22 14:24 ` Dan McLeran 2005-07-22 14:29 ` Bob Spooner 2005-07-23 13:02 ` Ludovic Brenta 2005-07-22 18:01 ` Marc A. Criley 2005-07-22 15:49 ` Jeffrey Carter 2005-07-15 14:04 ` Florian Weimer 2005-07-15 21:10 ` Larry Kilgallen 2005-07-18 12:37 ` Marin David Condic 2005-07-18 12:57 ` Ed Falis 2005-07-18 13:18 ` Marin David Condic 2005-07-18 14:12 ` Ed Falis 2005-07-19 12:51 ` Marin David Condic 2005-07-19 18:08 ` Robert A Duff 2005-07-20 5:12 ` Simon Wright 2005-07-20 15:37 ` Robert A Duff 2005-07-21 12:15 ` Marin David Condic 2005-07-21 15:32 ` Robert A Duff 2005-07-20 12:26 ` Marin David Condic 2005-10-27 7:20 ` Robert I. Eachus 2005-08-04 12:59 ` Florian Weimer 2005-08-05 14:29 ` Larry Kilgallen 2005-08-05 16:58 ` Florian Weimer 2005-08-05 23:15 ` Larry Kilgallen 2005-08-06 4:01 ` tmoran 2005-08-06 10:28 ` Pascal Obry 2005-08-06 10:33 ` Pascal Obry 2005-08-06 11:02 ` Dmitry A. Kazakov 2005-07-21 13:27 ` Maciej Sobczak 2005-07-22 7:39 ` Erlo Haugen 2005-07-22 9:29 ` Maciej Sobczak 2005-07-22 10:41 ` Erlo Haugen 2005-07-22 14:28 ` Alex R. Mosteo 2005-07-22 15:02 ` Pascal Obry 2005-07-25 9:48 ` Tassilo v. Parseval 2005-07-25 13:31 ` Adrien Plisson 2005-07-25 15:08 ` Jerome Hugues 2005-07-25 15:58 ` Adrien Plisson 2005-07-25 21:03 ` Jerome Hugues 2005-07-26 6:03 ` Tassilo v. Parseval 2005-07-25 16:39 ` Pascal Obry 2005-07-26 5:58 ` Tassilo v. Parseval 2005-07-26 17:25 ` Pascal Obry 2005-07-22 15:26 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox