Re: language design for handling library-complexity/learnability

[Paul Graham <address@hidden>]

One way to avoid a huge list of names is to have higher
order functions.  Instead of both member-if and 
member-if-not, remove-if and remove-if-not, have just
whatever-if and complement.

In Arc we may make let people express operations on 
functions implicitly by doing things to their names.  For
example, we may make foobar work as a way of expressing
(fn (a . args) (apply foo (bar a) args))), so e.g. 
(eqcar x 5) would be a legal way to say (eq (car x) 5).  
We'll see how it works.

--pg

--- Henning von Rosen <henning@ikso.net> wrote:
> this quote is from the former Caltech "Parallel Computing Works"
> http://www.npac.syr.edu/copywrite/pcw/node405.html
> 
> "Our claim is that the good ``in large'' computer language design
> should
> contain a nontrivial ``common English'' part, useful by itself for a
> broad
> set of generic tasks, and it should offer a graded, multiscale
> extensibility model towards specialized expert dialects. Indeed, we
> program
> by building reusable associations between software entities and
> names. Each
> ``in large'' programming model unavoidably contains a large number of
> names.
> The disciplined and structured process of naming software entities is
> crucial for successful complexity control. In languages such as C or
> Fortran, the ``common English'' part is reduced to arithmetic and
> simple
> control structures such as if, for, switch, and so on. All other
> names are
> simply mapped on a huge and ever-growing linear chain of library
> functions.
> The original language syntax, based on mathematics notation,
> degenerates
> towards a poorly organized functional programming style. ``In large''
> programming in such languages becomes very complex. "
> 
> The text is a decade old. Questions:
> 
> How relevant is the problem description to you?
> 
> What languages by your opinion meets the demands presented in the
> quote
> best?
> 
> If you are a language designer; how did you design in order to avoid
> the
> "All other names are simply mapped on a huge and ever-growing linear
> chain
> of library functions"-problem from above?
> 
> thanks for any comments!
> 
> amike via Henning
> 
> 


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/