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:
: 
:> : 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")
:> 
:> with Alice;
:> procedure test is
:> begin
:>    Alice.read_unanswered_log("../alice-unanswered.log");
:> end test;
: 
: This doesn't do you any good because the procedure does not return a
: value much less print it out in a form showing the internal structure
: of the result.  Plus you still need to compile, link, and then execute
: (though emacs will help you a lot with that).

Ah, wait, I was just showing what I would do in Ada provided I had your
alice:-stuff. As someone has already been mention in another posting,
how am I supposed to know that alice:read-unanswered-log is
a function that returns a value different from the empty list?
It could return a truth value as the comment above it reads as a question,
"Does ...". 
How do you know that read_unanswered_log in my package Alice doesn't
print out a dump? All this is beside the point as it talks about
libraries.


:> If I have a big Ada library, I expect to use it as an Ada
:> library.
: 
: Sure, but you don't get this sort of extremely interactive incremental
: development with the integrated results always available.

What's the measure for "extremely interactive"? 
Sure, writing tests is more work than typing testing expressions
into a REPL. Hopefully the testing exppressions are saved and
documented as regression test?
I'd be courious about a comparison using empirical data for a
program of at least a year of programming done by three or more
persons and a few years of operation.

:> If I want
:> to do incremental try-out programming, I know where to get it.
:> (Lisps, Smalltalk, ...)
: 
: That's the point - you can't get this with static languages, so the
: idea is indeed a non starter there.

I can get something sufficiently similar for the purpose of writing
a number of programs. And I know that in many cases the compiler
has saved me time and reduced anger, and has been helpful in finding
errors.


 
:> Here, someone has provided a set of identifiers implicitly setting
:> up a couple of task and some such I guess.
: 
: No that is what the with-protected-resource is providing along with
: the incremental results that you have been accumulating in your
: sandbox.

Right, incrementing takes time and testing, doesn't it?
 
 
: The point is there is no time needed to set this up for this test as
: it is already there in your sandbox as the previous bit to which you
: are incrementally adding.

There is no sandbox without someone having developed the things
needed to build sandboxes. This takes time /= 0.

:> Why should static type checking be in the way of every dynamic
:> thing?
: 
: It just is - what difference does the "why" part make?
 
"It just is" is not a convincing answer. As a SNOBOL4 fan, I know that
typed values and the ability to look at everything and to have the
compiler at hand in a running program can work miracles, also
miracles of program complexity a.k.a. cleverness.
But saying that static type checks are in the way of every dynamic
thing sounds like denying any kind of dynamics in a language like Ada
(in a Humpty Dumpty style?).  You cannot change executable pieces at
runtime in a typical Ada implementation AFAIK. But with O-O classes
of types operations are chosen at runtime. Is this not dynamic?

 
:> : Second, testing many cases is irrelevant.  Testing
:> : _outside_ the expected envelope is key.
:> 
:> A type defines an envelope, known to both the compiler at 
:> compile time and the program at run time, or test time.
: 
: The "both" here is typically not true in static languages.

Forgive me to think in terms of Ada. All Ada types do carry some type
information, even if limited. Not the same type information that you get
in CL, of course. But, with types and with variables
- you get bounds,
- you get ranges,
- You can ask whether a value belongs to the set of values that
  a type has declared.
- you can ask whether some type parameter is a definite type or not.
- ...

I agree this is not the same as type-of(value). But IIUC you are
typically asked, in Ada, to provide functionality for a set of differently
typed values not by type inspection and conditionals, but by using
interfaces and being explicit about what you do at the outer level.
It is still possible though, in particular with O-O types, to look
at what subtype we have and base decisions on the result deeply
inside some conditional.


:> And the use of types removes some of the need to test a function
:> with arguments that cannot be passed to the function because the
:> compiler has checked.
: 
: I agree that is the "theory", but in practice with a dynamic system
: and interactive incremental development it doesn't actually matter as
: the types are checked anyway at the time you are checking logic.

When I have a

   type Direction is (North, East, South, West);

and then a COND somewhere,

   case d is
      when North => bow;
      when South => spread_arms;
      when East => awake;
      when West => relax;
   end case;

There is no need, in theory and  practice, to test case coverage,
because it is guaranteed by the language rules that the compiler obeys.
Likewise, I cannot just add cases for Up and Down somewhere.

What would I have to do to have the compiler tell me in CL?

If this isn't possible, is there a way to predict the number of test
expressions together with the average time each takes to find missing
cases in all affected parts of the program?

If it is possible, don't you think that it saves lots of time
during code checking and in code restructuring as well?

When I have

   type Foo is array (Direction) of Color;

and then I create a value

   (North => Black, South => Yellow, East => Orange, West => Grey)

I know this value will have been completely initialised with
component values that are allowed for types Foo, Direction, and Color.
Again less testing.

If Direction is to be changed to include Up and Down as values,
both the case distinction and the tuple won't be valid any longer and
the compiler will let me know, as it checkes Foo-dependent
things in the transitive closure of all units depending on
the unit where Foo is defined.

I find this rather practical, for example because it can
guide the "refactoring" process without a need to run the tests
mentioned above.
 The mechanism isn't fool proof, for example when `others`
is used, but it saves time because a computer program (the compiler)
points to code that will or might have to be changed when Foo
changes.
 I think you will recognise this in ML pattern matching, too.


-- Georg