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

 
: 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. If I have a big Ada library, I expect to use it as an
Ada library. Ada is explicit and verbose. You get something in return.


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


: 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. 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 
possibility to do amazing things in Lisp is beside the point I
think.

: 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? True, sometimes being explicit about everything using types
can be combersome plus Lisp has EVAL and macros, adding power...


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


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

: 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.
So you have at least told your readers where outside is.

Testing inside is important as well, because unless proven
you don't know for sure which values are inside and outside, resp..
As someone said somewhere else in this thread, test the
unexpected unexpected :-)

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



-- Georg