From: Non scrivetemi on
> 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
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
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
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
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