Re: ADA Popularity Discussion Request

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

jayessay <nospam@foo.com> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> jayessay <nospam@foo.com> wrote:
:> 
:> : Yes, and they don't happen at runtime if pre and post are checked
:> : during incremental development.  If you don't do this, then you will
:> : likely have problems - just like if you don't get the types right in
:> : static languages.
:> 
:> Is it really much more time efficient, if pre and post checking is done
:> by an incrementing human? If so, how much?
: 
: Generally, yes.  For two general reasons: 1. you are always sure of
: the logic as well as the type consistency

Yes, within the limiting conditions of parameter values of a suitable
type.

: 2. You don't have global
: "system integration" issues as each incremental step subsumes an
: integration aspect.

OK. Similarly.


:> : Your explanation above does not cover the logic error.  I don't see
:> : right off how modular types catch that.
:> 
:> See below, there isn't a logic error, only a typo.
: 
: No, I'm not talking about the typo in the advance function.  I'm
: talking about the logic error in the Hext function itself!

That's your interpretation of the "hext" function as given in
the Lisp example.

:> In the Lisp example there was a "typo context". "next" should have
:> been where "hext" was actually typed in the Lisp example
: 
: That's not the logic error.  The logic error is that Hext is broken
: due to the incorrect expression at the line noted above.

It is broken WRT your interpretation of its undocumented purpose.
It is not a broken Lisp function at all and might reflect a
specification precisely.  It could as well have been

 (defun hext (n) (+ offset  (mod n 16)))

(What has made you think otherwise? :-)

or even

 ;; hext: string -> string
 (defun hext (n) (extract-h-from-oldstyle-german-th-word n))
  ;; make Thor from Tor etc.
 
With the same typo leading to the discovery of the error only
a run time or test time.
 
:> Therefore, an integer number was actually wanted ("next"), not
:> a hex number ("hext").

(In fact at the point of definition of "advance", the programmer
will likely have been aware of the "next" function, but not of
a "hext" function. The test might have revealed the existence of
the "hext" function in the first place. (I do like surprises
sometimes, as they also make you see things that you might have
missed before :-)

Now consider a situation where there are no two similarly named
functions in the environment, with similar results, both producing
values of the same Lisp number type, and both consuming arguments of
the same number types.

I think that a static type system like Ada's, if used, will
likely catch a logic error at compile time, that is when by mistake
one function is used where the other should have been used. This is because
a value of a type being in  1 .. 10  will not be compatible with a value
of another type's  1 .. 10.  The program will not have to be run to
find out, at least there is a chance for this to to be found out
prior to surprises at run time, even if not every case can be handled
by compile time type checking.


; old Rome

(defun 1-to-10 (n)         (random-even 1 10))
; ...
(defun 1-out-of-10 (n)     (test-status  parts-of-town n))

(set-on-fire (1-to-10 3))   ; should have been 1-out-of-10

-- Georg