Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.com>]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>
writes:

> >>>>> "j" == jayessay  <nospam@foo.com> writes:
> 
>     j> In any application/system of any significance these two go hand in
>     j> hand.  The second is achieved by crafting a constrained narrowly
>     j> focused domain specific language _within_ Lisp, which allows the
>     j> programmer to then work at the level of the domain, _both_
>     j> syntactically as well as semantically.  This is why Lisp macros
>     j> (please don't confuse with any other kind of macro you've come across
>     j> before) are such a big deal.
> 
>     j> Now, admittedly, creating these is not something your typical code
>     j> monkey is going to grok.  This is one of the big reasons why Lisp will
>     j> never be as "popular" as something like Java.  But then your typical
>     j> code monkey isn't going to be building your core internal application
>     j> api either.  Once you've built this though, even a code monkey will be
>     j> a lot more productive and produce much more clean and robust code.
> 
> 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.  In this sort of
development you are typically _extensively testing even partial
expressions or single clauses_ (well below the level of a function)
and at each increment of accretion testing that until you have a
function at which point it is tested.  The upshot is you have a
stunning level of code path coverage - not just for type checks, but
logic checks as well.

Since you are not saddled with the typical
write-try-to-compile-rewrite-compile-try-to-link-rewrite-... finally
try to test something cycle this can be done _extremely_ efficiently
and timely.  You will catch errors _much faster_ than compile time
checking - you are checking the correctness of code paths through most
every singl path possible.  You don't wait to build tests at the
higher levels with input cases which you "hope/believe" will exercise
"most" of these paths.  This is also why _logic_ errors are also far
rarer.


> But for the last years I have been mainly working with soft real time,
> multi-threaded systems. I am aware of the existence of real-time
> garbage collectors, but what about multi-threading? Common Lisp used
> to be pretty weak in this respect, has this changed?

Multi-threading has actually always been available.  All the
implementations provide an MP facility modeled on the Lisp Machine's -
they are not 100% the same as this is a "industry standard" and not
yet in the ANSI standard, but they are very very close.  So moving
code from one to another is actually very easy.

I have used multi-threading in basically all my work for years now and
don't even think much of it anymore.  In many ways, multi-threading is
far simpler and more robust in Common Lisp than most anything else for
a variety of reasons.  Two big ones: 1) you can build your own tasking
model and _embed it within the language_ for the type of tasking you
will be using.  So your code will be succinct, clean and _natural_.
2) Dynamic variables are simply amazing for reducing the much of the
programming complexity of multi-threaded applications to nearly that
of single-threaded.

As for real-time GC, it depends on what you mean by "soft real time".
If this really just means something like "it should run fast" or "I
can't have any pauses" or some such, then any good modern generational
GC will be more than sufficient.  I've only had to tune the GC in a
couple of really _huge_ application cases.  Generally, such modern GCs
will never use up more than a fraction of a _one_ percent of the
runtime and will typically out perform manual heap management by quite
a bit.

If you really mean guaranteed response and runtimes, you may well need
to roll your own, use a form of manual management, or maybe this case
just isn't a good fit for Common Lisp.  There are some bare metal
Schemes out there that might work.


/Jon


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