Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.com>]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> jayessay <nospam@foo.com> wrote:
> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com>
...
> :> 
> :> I do not consider myself a Lisp programmer, but I have programmed
> :> enough Lisp to conclude that you probably are correct that the ability
> :> to create a constrained narrowly focused domain specific language
> :> within Lisp could very well outweigh the advantages of static typing.
> : 
> : If you've been there, you know this.  Actually, the incremental bottom
> : up development with _continual_ testing of almost every code snippet
> : is a significant advance above static typing.
> 
> I do these little steps all the time, _with_ static type checks,
> documenting my expectations in lots of small test-programs.

You can't.  Because the sort of snippets I'm discussing are not even
legal programs in things like C++/Ada/Eiffel/etc.

How do you do stuff like this:

;; Does the log reader return the correct forms for a log file
(alice:read-unanswered-log "../alice-unanswered.log")

You can simply ask Lisp to try this and see the results

;; Is the format properly formed for output to a client bin widget
(with-open-bin (:bin-id 1440691622 :session-number 12)
  (put-bin (alice:read-unanswered-log "./alice-unanswered.log")))

Same here - but this will also go over to a connected client and you
can see if all that protocol is correctly working.

(set-of-names (the-objects-in-bin 1440691622))

Just get a pretty printed output of the internal structure of the
client widget content.

Doing this in Ada/C++/Eiffel would require setting up a fairly big
procedure/function with all sorts of withs or imports and
instantiations, etc just to get to the one line out of hundred or so
that you want to test.  The whole idea is a complete non starter.

Or how about:

(with-protected-resource *main-database*
  (let ((broken-bits (ensure-consistent-state it)))
    (when broken-bits
      (pprint-db-items broken-bits))))


Here, you'd need to set up a couple of tasks and probably a protected
object plus more boiler plate.

You simply cannot do this sort of thing in stactic languages.  You
shouldn't be bothered by this because you are claiming static type
checks are worth the price of losing this sort of thing.


> But why do you assume that static typing replaces the need to test
> every corner of the software?

I don't.  Obviously it doesn't.  No one believes that it does.  You
are hacking at a strawman.


> But the "incremental testing fans" do not assume that testing many
> cases will give them type coverage?

There is no assumption.  First dynamic typing is as strong (robust) as
static typing.  Second, testing many cases is irrelevant.  Testing
_outside_ the expected envelope is key.  Once you have accounted for
this you are set to go.  As you evolve the functionality input
producing erroneous results (type or logic) is caught futher and
further up the chain.  At each point you account for this and
continue.


> Likewise, I guess they know that the set of paths tested and the set
> of paths taken at runtime may have little overlap in unwelcome cases
> (given some types are large)?

See above.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com