From: Alex R. Mosteo on 9 Jul 2010 05:18 usenet(a)scriptoriumdesigns.com wrote: > Serious question: What do you consider the N best things / strong > points / biggest benefits of using Ada? I'm asking as part of my case- > building for using Ada at work. Of course I have my own list, but I > don't have anywhere near the Ada experience of most of you folks. Out of my head -- 1. Separation of spec/impl. 2. Easy tasking/data sharing with monitors. 3. If it compiles, bugs are almost always of logic nature and not silly time-wasters (although there's the rare occurrence when I get too smart ;). 4. Unconstrained types that minimize dynamic allocation needs. 4.1 I guess the use of 'Class is a particular instance of this. 5. Rep. clauses, custom numeric types. 6. Easy interfacing to C.
From: John McCormick on 9 Jul 2010 07:52 On Jul 8, 7:52 pm, use...(a)scriptoriumdesigns.com wrote: > Serious question: What do you consider the N best things / strong > points / biggest benefits of using Ada? I'm asking as part of my case- > building for using Ada at work. Of course I have my own list, but I > don't have anywhere near the Ada experience of most of you folks. > > Thanks. The ability to model scalars. This is the primary reason why my Ada students succeed and my C students fail in my Real-Time Systems class. One of the principles of object-oriented programming is the development of classes that accurately model the objects in the problem. We can apply this same approach to the design of our scalar types. By using scalar types that more accurately reflect the nature of the data in a problem we are solving, we can write better programs. One research study by Eisenstadt and analyzed by me in 1997 on the nature of costly software faults indicates that poor models of scalar quantities were responsible for nearly 90% of the errors in the cases studied. Ada allows programmers to define their own scalar data types that accurately model the scalar values in the problem domain. Eisenstadt, M, My hariest bug war stories, Commun ACM, 1997, vol 40, #4 30-37 McCormick, J., Forum letter, Commun ACM, 1997, vol 40, #8, 30
From: (see below) on 9 Jul 2010 13:27 On 09/07/2010 12:52, in article bff0da99-cd58-4612-a720-4c94ace50804(a)s9g2000yqd.googlegroups.com, "John McCormick" <mccormick(a)cs.uni.edu> wrote: > On Jul 8, 7:52�pm, use...(a)scriptoriumdesigns.com wrote: >> Serious question: �What do you consider the N best things / strong >> points / biggest benefits of using Ada? �I'm asking as part of my case- >> building for using Ada at work. �Of course I have my own list, but I >> don't have anywhere near the Ada experience of most of you folks. >> >> Thanks. > > The ability to model scalars. > > > This is the primary reason why my Ada students succeed and my C > students fail in my Real-Time Systems class. My own teaching experience is completely in agreement with this. I would just add that the mindset induced by being very careful about scalar types then carries over to other aspects of the job. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: anon on 10 Jul 2010 01:14 In <1122ac0c-8f74-47f9-ade4-fe6348bff6d7(a)i28g2000yqa.googlegroups.com>, tonyg <tonythegair(a)googlemail.com> writes: >On Jul 9, 4:08=A0am, a...(a)att.net wrote: >> In <97691fd2-7411-4ccc-bc7b-290aca633...(a)z30g2000prg.googlegroups.com>, u= >se...(a)scriptoriumdesigns.com writes: >> >> >Serious question: =A0What do you consider the N best things / strong >> >points / biggest benefits of using Ada? =A0I'm asking as part of my case= >- >> >building for using Ada at work. =A0Of course I have my own list, but I >> >don't have anywhere near the Ada experience of most of you folks. >> >> >Thanks. >> >> 1. RM defines the language. >> >> 2. Muti-Core programs are easy. Just modify/create few run-time packages = >to >> switch the real-time concurrent system to a real-time mutiple-core system= >.. >> >> 3. Readablity, Reliability, Maintainability, and Efficiency. >> >> 4. Portable without conditionals statement. Update the OS or change >> processor only requires a simple recomping of the source code without >> changes. >> >> 5. from Section 1 of the RM 95: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 1: Gen= >eral >> >> 1 =A0 Ada is a programming language designed to support the construction = >of >> long-lived, highly reliable software systems. =A0The language includes >> facilities to define packages of related types, objects, and operations. = >=A0The >> packages may be parameterized and the types may be extended to support th= >e >> construction of libraries of reusable, adaptable software components. =A0= >The >> operations may be implemented as subprograms using conventional sequentia= >l >> control structures, or as entries that include synchronization of concurr= >ent >> threads of control as part of their invocation. =A0The language treats >> modularity in the physical sense as well, with a facility to support sepa= >rate >> compilation. >> >> 2 =A0 The language includes a complete facility for the support of real-t= >ime, >> concurrent programming. =A0Errors can be signaled as exceptions and handl= >ed >> explicitly. =A0The language also covers systems programming; this require= >s >> precise control over the representation of data and access to >> system-dependent properties. =A0Finally, a predefined environment of stan= >dard >> packages is provided, including facilities for, among others, input-outpu= >t, >> string manipulation, numeric elementary functions, and random number >> generation. > >A few years at a eminent european institution which uses Ada, C++ and >linux I was hired as part of a 5 man team to conduct a migration of a >monumental system from a 32 bit environment to a 64 bit environment. >There were two C++ guys, one hardware guy and I was the ada guy, and >the boss flew in, / worked remtoely a lot. Two days after the start >the Boss Guy took me aside to tell me that there appeared to be no >work for me because the Ada was all going to work. The rest required >all sorts of changes. (Luckily I was useful elsewhere). > Well that the up and downside of a Ada programmer. We create the partition and after finding and repairing those foolish bugs, we like to move on, because there no money in upgrading Ada program. That's because it a few hours recompiling to the new system, then a few more hours to adjusting the documentation and your done. On to the next job.
From: Shark8 on 12 Jul 2010 10:05
People have mentioned packages, non-textual-substitution generics, and such. But one thing that could come in handy is the named parameters, and it is something I like; one of those "little things." "Circle( Radius => 23, X => 28, Y => 14 );" will always be more readable than "Circle( 23, 28, 14 );" plus, there's the added benefit that 1) changes in parameter-ordering will not impact calls of this sort, & 2) the users of the functions/procedures can place the more pertinent parameters [to their task] more prominently [e.g. first]. |