Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.com>]

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

> jayessay <nospam@foo.com> wrote:
> : 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")
> 
> 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).


> : 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.
> 
> Huh?  The fact that you have a big, hopefully tested and checked
> library/system full of convenient things in CL may be a plus if you
> can use it.

Not just that - you create a sandbox where all this stuff is available
for use and testing as you are developing.  In particular this is all
done incrementally.

> 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.


> : The whole idea is a complete non starter.
> 
> Not for me. A can live with some typing on the keyboard.  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.


> : 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.
> 
> 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.


> How much time has it taken to define all this using testing and
> run-time type checking, when you compare to the time needed to do
> the "same" thing with static type checks on?  Seems a more
> interesting question.

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.  So, basically the correct answer here is 0
time.


> : 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.
> 
> Why should static type checking be in the way of every dynamic
> thing?

It just is - what difference does the "why" part make?


> :> 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.
> 
> From what you were saying (sounding like static type checks are
> a waste of time) I thought it wasn't obvious.

If what you have available is static type checking then clearly it
isn't a waste of time.  You basically have the thing backwards: If you
have a dynamic language with "extreme programming" abilities then you
don't miss static typing as what it covers is a _subset_ of what you
get.


> :> 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.
> 
> At run-time only ... Or at try-out time, maybe?

If I take "try-out time" to mean development time, the answer is both.


> : 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.  The reason
should be clear: a type in static typing applies to _variables_ (it is
supposed to define/constrain the kind of value a variable (including
parameters and results) can "hold".  Variables don't actually exist at
runtime.  So, no the program typically has no information about types
at runtime in a static language.  This is what so called RTTI is
intended for in the very limited scope it provides.

In a dynamic language, _values_ have types, variables are just binding
locations, i.e., names which can be used to identify a potential
value.  Hence, full type information is available whenever there are
values - either compile, load, or runtime.


> : 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.
>  
> 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.


/Jon

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