Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Non scrivetemi on 5 Jun 2010 19:17 > COBOL maybe! However, here in Canada, I'm aware that a lot of financial > institutions were set up to use Mumps (now M Technology) and they're still > using it. I believe the same is true in the U.S.A. Mumps is _still_ big in > the Health Care sector. Yes, only in H/C. No American bank uses MUMPS.
From: Yannick Duchêne (Hibou57) on 5 Jun 2010 23:46 Le Sat, 05 Jun 2010 21:59:58 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > BTW, this is my concern about software certification procedures. It fact, > they act quite as you suggested. They certify programmers, they don't the > software. What is this named âsoftware certificationâ then ? Are you sure you are not talking about some non-glorious example only ? Or is it really common ? -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Yannick Duchêne (Hibou57) on 6 Jun 2010 00:08 Le Sat, 05 Jun 2010 18:02:36 +0200, Nasser M. Abbasi <nma(a)12000.org> a écrit: > I meant complex type in ada is not an elementary type. as in So this was indeed about to have Complex beside Integer and others. To keep it simple : it is not elementary, because it can be built using more elementary things, so this is not really elementary. If something can be created using something else, it is not so much elementary. May be the matter is efficiency so ? But as there is no low-level support for Complex in any architecture I know (I have never heard about a CPU with a Complex number instructions set), there is no way to formally assert it is less efficient as a composite type. And if ever a CPU support it, an implementation may always be able to get benefit from any dedicated CPU instructions in its implementation of Complex. Note: I heard to say FORTRAN specifications of Real numbers is more relaxed than Ada ones and have less requirements. If there is ever an efficiency gap between FORTRAN and Ada, perhaps this can simply be explained by their different requirement with Real numbers ? -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Jacob Sparre Andersen on 6 Jun 2010 02:36 Dmitry A. Kazakov wrote: > On Sat, 05 Jun 2010 11:05:16 +0200, Yannick Duch�ne (Hibou57) wrote: >> So this is chaotic (and there is a science which can talk about it >> too). > Do you mean chaos theory here? I don't think "chaos theory" as such is the right answer, but some of the tools developed to analyse and model complex systems may be able to help us put some numbers on the risks involved in changing software. As far as I know, nobody has done this yet, but it is definitely interesting. > In that context reliability must be redefined. Well, I doubt that > chaos theory could efficiently handle that. Although most of programs > as well as software developing processes are indeed > cyclic/iterative. One could try to apply the theory there. I don't think it is development process as much as it is the interconnectedness of the produced software which is interesting. > Boarding a plane would you be glad to hear that the software > developing process used for its flight system wasn't random? It was > CHAOTIC! (:-)) :-) Jacob -- "It ain't rocket science!"
From: Dmitry A. Kazakov on 6 Jun 2010 03:46
On Sun, 06 Jun 2010 09:38:21 +0200, Yannick Duchêne (Hibou57) wrote: > Le Sun, 06 Jun 2010 09:25:59 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a écrit: >>> I've never understood the objection to "all this instantiating every >>> where". >>> How much effort is a line or three of boilerplate code? >> >> Geometrically exploding... > As this is about genericity, I would like to understand: what kind of > curve is one “Geometrically exploding” ? = exponentially http://en.wikipedia.org/wiki/Geometric_progression > I remember in the past (past year I think), we talked around generics > hierarchy and generic packages as formal parameters. You had warned about > possible complexity explosion in this area: is this about the same ? Yep. Once generic always generic. Two generics make four instantiations. And the mill starts milling... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |