This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
Moved comments here from main text. Reorganized into threads.--buzco
The descrition of the Ariane 5 Failure should not be on a side describing a programming language a link to a different side should be enough. Ariane 5 Failure
I agree with that. it seems to me that this topic has nothing to do in an article describing a programming language all the more since it is rather a human error than a weakness of the language.
--Tarroux 07:28, 24 February 2007 (UTC)
The statement that this incident caused the Ada runtime error checking to be questioned (I have been working with Ada for 20 years and have never heard this). This statement has no citation; the full report on the incident does not cite the Ada language as a contributing cause of the accident only the specification and design of the software. I believe this statement should be supported by a citation or removed. Richard A Brown 18:05, 9 March 2007 (UTC)
In any case, a human-error "let's just import the program directly" example isn't a criticism. "It's unweildy and unpopular" would be criticisms... and before anyone jumps down my throat, I don't know the first thing about Ada, so those were just vague examples. I'd love to see a criticism section like the one in C++ or COBOL#Criticism, but until then, I'm just going to axe it and request an expansion. --The Centipede 20:00, 15 August 2007 (UTC)
Really only used anymore in US Department of Defense stuff. Oh yeah, and Ada95, the most popular Ada compiler actually translates your code to C, then compiles the C. I love that.
--- Sorry, but that's a rather pointless and not only invalid but also uninformed statement, in fact you may be surprised that software compilation regularly involves translating high level code into ASSEMBLY language, which -surprise- usually happens to be even less-(strongly) typed than any conceivable high level language, so the point really isn't the target language/representation that a high level language is translated to, but rather how (strictly) this is done and how it is enforced that the corresponding rules are enforced.
Thus, only because a compiler for a very strongly typed language (such as Ada) may -in fact, routinely- translate source code to a less-strongly or even virtually untyped target/intermediate representation (like C or directly assembly), this doesn't necessarily imply that the strongly-typed nature and goals of the original language is automatically affected and may thus be questioned: once compilation has taken place and succeeded, it doesn't matter for an Ada program whether its target language is C, Java, Pascal, Python or assembly, simply because until then numerous rules have been applied to the original code, ensuring to a very high degree that the underlying source code can in fact be properly transformed to (a subset of) the target representation. The real potential pitfall in such a scenario would in fact lie in 3rd party software that may translate the produced -valid- output to another target language possibly not applying similarly rigorous rules, however this issue is routinely addressed by settling for a well-defined and very limited subset of the target language which can be easily verified and validated using a corresponding test suite.
This approach is for example also taken by the SPARK language (a dialect/subset of Ada): Being basically a subset, SPARK programs are necessarily valid Ada, however they're being written with lots of meta information about expected and desired runtime behavior, this very meta information is provided in the form of comments in the source code, so it would not really affect an Ada compiler, a SPARK compiler however will happily process and honor such comments to parse, validate and augment the source code to come up with an accordingly enriched Ada program. So, this is again an example for a scenario where a comparatively strongly typed source language (SPARK) is translated to a less-strongly typed language (ADA) without necessarily compromising the safety margins provided by the source language and its specification.
See http://www1.acm.org/sigs/sigada/education/pages/myths.html for some answers to similar questions.--Parallelized (talk) 23:02, 1 February 2008 (UTC)
And: http://www.mil-embedded.com/articles/authors/gicca/ --Parallelized (talk) 23:12, 1 February 2008 (UTC)
Ada is used in a few compiler theory books because of its comprehensiveness and elegance.
Related websites:
Should there be a section on primary users of a language like ada and how their requirements affected the language?
Ada is today still routinely being used for efforts where safety-critical software systems need to be developed, this is for example the case for aviation and space technology (think ATC, avionics, engine control etc) but also lots of other government software (think traffic surveillance, control and management), whenever lives or great financial resources are at stake, crucial software components are still being developed in Ada or even more rigorous subsets of it (i.e. SPARK). Likewise, for many such safety-critical software projects there are very high safety requirements to be met, which are often easier to satisfy by using Ada (critical software in railway control systems or even nuclear power plants, must have a well-defined and easily verifiable runtime behavior).
Also, Ada is also frequently the first choice when it comes to guaranteeing a high degree of maintainability for long-term software projects.
For additional in-depth resources, see the Ada wikibook and its discussion/talk page which features a "resource" section about Ada, its primary uses and benefits. —Preceding unsigned comment added by 82.83.66.83 (talk) 13:23, 21 January 2008 (UTC)
See this website for an overview of Ada users and application areas. Someone might want to incorporate some of this into the actual article. --Parallelized (talk) 22:42, 1 February 2008 (UTC)
Ada has some tastes of Pascal still but not one of the bad ones. --Janet Davis
Well both Ada and Pascal are based syntactically on ALGOL 60, so that's not much of a surprise. Ada certainly took some ideas from Pascal, but fixed it's problems. —Preceding unsigned comment added by 68.222.42.172 (talk) 21:12, 18 January 2009 (UTC)
(list of possible topics moved from main page) What about
I think the Steelman language requirements page would be better as part of this entry, or maybe a subpage, as it isn't really of interest except in the context of Ada. Anyone agree/disagree? --Matthew Woodcraft
Development History: If possible a table summarizing the roughly 17-18 received, all but one Pascal-based designs, with names or references preceding the four finalist colors would be good. Any distinct features might be noted before their developers fade to dust. 143.232.210.150 (talk) 17:44, 14 May 2008 (UTC)
I don't think the note re the Ariane 5 disaster is quite correct. As I understand it, the fault was the re-use of a part and its software, which had worked properly on the Ariane 4. However, the more powerful engines on the Ariane 5 gave a thrust/velocity/displacement that was out of the part's design range, and the part detected that fact -- correctly, according to its original design. But since it thought it had a number that failed the sanity check it went into debug mode -- again according to design -- and started dumping debug data onto the rocket's control bus. So unless my understanding of the problem is wrong, the problem was a simple failure to review a part's specifications, and nothing at all to do with the programming language or compilation switches. -- B.Bryant
I'm excising this whole paragraph. I've never heard it called the "language of the future", after reading a lot about Ada. For every language, you can find someone hyping it that looks silly in retrospect. Usage may be important, but it needs a lot more than just "never been used that much". "The variable name conventions ... are difficult to type, look ugly, and don't provide any information, unlike variable name conventions for just about every other language do" is a bit absurd; Ada has the same freeform variable names that most modern languages do, and the names I've seen in C code look much like the ones in Ada. To say that other language name conventions aren't difficult to type and don't look ugly is a very arguable case to make; BASIC and FORTRAN's short variable names, FORTRAN's type-name relations and Perl's type-name relations can be considered ugly and difficult.
I'd like to see some valid criticisms on Ada, but these are just silly. --Prosfilaes 02:19, 1 Jul 2004 (UTC)
In May of 1979, the Green proposal, designed by Jean Ichbiah at Cii Honeywell Bull, was chosen and given the name Ada
the above is chronologically the first mention of the name 'Ada' being associated with the Ada programming language. I'm quite certain that when I worked for the US Navy, and at sometime definitely prior to 1976 June 13, that I heard mention of 'the Ada Project' more than once. Do we have any info available from nonclassified source about this beingcalled the Ada Project, prior to 1979?
There was nothing awful, but nothing great. Ada83 is one version of Ada, not another name for; "statically typed" is more unambigious than "strongly typed"; it was created to stop the proliferation of languages in the DoD, and improving on other languages (and not just C and C++) was a side-goal; what it was designed to do is important; and tasking is just one feature out of many.
I replaced "Ada was named after Ada, Lady Lovelace, the first computer programmer" with "Ada was named after Ada, Lady Lovelace", because the statement that she was a computer programmer directly contradicts the linked Wikipedia article (as well as other sources). My edit was reverted by UtherSRG with no explanation. I'm not trying to denigrate Ada Lovelace or the Ada language; I'm just trying to correct a factual error in a Wikipedia article. There is no historical evidence to support the common belief that she wrote programs for the Analytical Engine. -- BenRG 00:23, 12 Oct 2004 (UTC)
I propose to change the capitalization of the identifier 'Text_Io' in the Hello World! example. In my opinion the correct letter case is 'Text_IO' and not 'Text_Io', as it's found in the Ada Reference Manual and also in the GNAT source code. Although Ada is not case sensitive this doesn't mean that capitalization isn't important. The Ada 95 Quality and Style Guide recommends to 'Use uppercase for abbreviations and acronyms', e.g. Text_IO (for Input/Output). Moreover, GNAT has an option to check attribute casing and reject any identifier that doesn't mach with its definition casing. Both forms are syntactically correct, but Text_IO is more correct and follows the language's guidelines of quality and style. Thanks -- suruena 14:13, 2004 Nov 30 (UTC)
--Krischik 14:51, 30 Nov 2004 (UTC)
I've moved JGNAT back to the compilers subsection and added MGNAT (Ada .NET compiler). I've also removind the reference to A# to the related programming languages subsection (that was put there by myself). I'm not sure whether A# is only the name of the project, or there are any extension to the Ada language (other than 'limited with', a feature that will be part of Ada 2005). Are the languages accepted by JGNAT and MGNAT a subset of Ada? (Can someone confirm this?) In that case, maybe it would be necesary to add a section called Ada dialects.
NOTE: I do not consider SPARK as an Ada dialect because it greatly changes the language with data & information flow analysis (adding formal annotations), therefore becoming another language. But if A# makes any chages (I suppose those are minor changes), I will consider it a dialect.
-- suruena 23:38, 2004 Dec 6 (UTC)
I would consider JGNAT and MGNAT more a superset. In order to support the virtual mashines additional featuers are added: Garbage Collector - a must, interface inheritance, limited with, Object.Operation.
Yes, some of which will be part of Ada 2005 - but not all with the same syntax. And on top ObjectAda did the Java extension differently. The hope is that with Ada 2005 all both will fall in line again.
As for A# - Tricky to say since MGNAT is the only A# implementation - so mayby there are just two words for the same thing.
SPARC and "Dialect" - I see the word itself broader then you - The are german dialects which I can't understand - but I can understand SPARC programms.
But if you are a native english speaker you may find a more appropiate word.
Anyway, I think the current wording is OK for far and I would leave it as it is.
--Krischik 08:43, 7 Dec 2004 (UTC)
I removed the Embedded systems cat (a language alone isn't a system) and got a note regarding Ada's intended use within that context. While I wouldn't suggest re-adding the category, I would suggest that someone incorporate that fact in the article itself to better clarify that fact.--Hooperbloob 06:46, 14 Feb 2005 (UTC)
As a software engineer involved in the development of Ada, I would like to see included in here a comparison with C and C++. Ada is one of the few programming languages certified by the DoD because we produce much more reliable programs, more resistant to hacking than other high order languages, e.g., C++. However, where speed is concerned, you really want to use either Assembly Language or C, an intermediate language. Ada still requires a lot of memory and has a high overhead. There are some compilers that allow an optimized, bare-bones Ada but they need to be carefully checked. I suggest having two compilers and compiling the source code on both. You'll find different bugs each way.