Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.com>]

kevin.cline@gmail.com (Kevin Cline) writes:

> jayessay wrote
> > "Richard  Riehle" <adaworks@earthlink.net> writes:
> > 
> > Also, logic errors (what most
> > people would consider significantly more negative) are far rarer.
> > 
> > There turn out to be various reasons for this, but two worth
> > mentioning are the sort of bottom up style of programming as described
> > by Paul Graham (a kind of agile/extreme programming) and the ability
> > to move Lisp to the expressive level of the application domain.
> > 
> > In any application/system of any significance these two go hand in
> > hand.  The second is achieved by crafting a constrained narrowly
> > focused domain specific language _within_ Lisp, which allows the
> > programmer to then work at the level of the domain, _both_
> > syntactically as well as semantically.  This is why Lisp macros
> > (please don't confuse with any other kind of macro you've come across
> > before) are such a big deal.
> > 
> > Now, admittedly, creating these is not something your typical code
> > monkey is going to grok.  This is one of the big reasons why Lisp will
> > never be as "popular" as something like Java.  But then your typical
> > code monkey isn't going to be building your core internal application
> > api either.  Once you've built this though, even a code monkey will be
> > a lot more productive and produce much more clean and robust code.
> > 
> > > For example, a Common Lisp programmer rarely agnonizes over such
> > > silliness as constructors, copy constructors, overloading assignment
> > > operators, friends, and all the hideous little details that
> > > characterize so much of C++ programming.
> 
> I'm skeptical.  In any language, data structures will require
> initialization to reach the empty state.

Just to be clear, I didn't say that last bit, Richard Riehle did.  But
you've mixed it in with my comments so it is unclear of what you are
skeptical - everything quoted above or just the R.R. bit.

It's also worth noting that if you substituted "Ada" for "C++" there
would not be a substantive change to the bit.

Anyway, other than "constructors" none of the stuff in R.R.'s quote is
remotely the concern of a developer using Common Lisp.


> You still have to write the code, it just has a different name.
> Instead of MyThing(int mobys, ...) you have (defun
> make-my-thing(mobys ...).

Strictly speaking, this is usually simply not true.  The normal case
by far is one where this code is generated for you from a
specification and it is sufficient.  There are cases where this will
need to be overridden or otherwise enhanced, but those are "outlying"
cases.


>  Instead of a copy constructor, you have (defun
> clone-my-thing(thing) ...).

This sort of thing is _extremely_ rare, because you don't use or need
"copy" semantics.  You just do _not_ make copies of things unless
there is some _domain_ level reason for it.  [Aside: fyi, in such
cases where this makes sense it is _much_ more likely that you'd be
using defmethod for this sort of thing].


> And if you open files or lock mutexes or consume any other limited
> resource, you are going to have to ensure they are released by
> writing the equivalent of a destructor.

Macros eliminate this sort of "boiler plate" code.  These are nothing
at all like a destructor.  Most other uses of "destructors" typically
revolve around "memory management" which obviously is pretty
irrelevant in Common Lisp.


A typical example here would be with-open-file.  You simply do not
need to be concerned with the maintenance of the file/os resource,
etc.  It is handled for you and guranteed to be cleaned up when
leaving scope whether by normal or exceptional flow.

Same with locks:

;;; Serialize access, lock for update, guarantee unlock on exception,
;;; and unlock/commit on success
;;;
(with-protected-resource (get-database :medline-journals)
  (foo it)
  (bar it))



> When done well, C++ programming does not get mired in hideous little
> details.  But like most programming, it is rarely done well.  And the
> more popular a language, the lower the performance of the average
> practitioner.  Lots of people learned C++ and Java because that's what
> the market demanded.  So there is lots of horrible C++ code and Java
> code.

Mostly agree with this (though C++ does force you to deal with a lot
of extraneous grime).


> People learn LISP because they love programming.  Not all LISP
> programmers are geniuses, but almost all are well above the mean.

I think you are basically correct in this also.  BTW, "LISP" is
basically never used anymore except by some as a shorthand for "a
Lisp" or "Lisp like language", i.e., as a term for a certain class of
languages.


> ...
> > 1. Which from experience would typically be in the range of 250K-500K
> > lines of equivalent Ada/C++/Eiffel/etc.  An order of magnitude is not
> > hyperbole here even though most uninitiated developers will raise
> > their eyebrows or roll their eyes. 
> 
> This I know to be true, although again it's not fair to compare the
> C++ code from an average programmer to the LISP code from an expert.
> An expert C++ programmer can reduce the line count of typical code
> by 60% or more.  

I'm instantiating "LISP" here with Common Lisp.  I'm not talking about
code monkey C++/Ada/Eiffel vs Guru Lisp.  The mentioned one to two
orders of magnitude of typical gain holds for expert code vs expert
code.


> In either language, experts will refactor until a new
> domain-specific language appears.

I agree that experts will refactor no matter what.  However, there is
no way to create a domain specific _language_ _within_
C++/Ada/Eiffel/etc.

I'm talking about where the the syntax as well as the semantics is
just as transparently and cleanly integrated in the language as any
core aspect.  Where there is no bolt on interpreter needed, no hacking
away trying to kludge up something with yacc/lex types of tools.  And
where the result supports the expression of the application code
naturally and cleanly in the terms and processes of the target domain.

You just can't do this with things like C++/Ada/Eiffel/etc.  You can't
even do this with stuff like Smalltalk, Python, or even Dylan.

The key to this was succinctly captured by John Foderaro: "Lisp is a
programmable programming language".


/Jon

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