On Thursday 18 August 2011 18:15:03 Alan Kay wrote:
> Another more trivial but telling point is that John did not like the use of
> S expressions for programming -- he invented them to have a way to
> represent collections and to serve as an internal form for interpretation.
> But as any decent mathematician would, he wanted to have a more readable
> notation for programming in and reading programs and learning to think in
> this more mathematical style. And he experimented with a number of these
> over the years.
> 
> Cheers,
> 
> Alan

I think that this is an often neglected feature of LISP; the syntax doesn't 
matter. The only complaints I've heard about LISP over the years are the 
'over' use of parentheses (ie. it is hard to distinguish control structures, 
data, etc.) and the prefix notation, but these are incredibly superficial 
syntactic features, especially considering how well-structured (and thus 
easily transformable) LISP s-expressions are.

I know there are a few attempts at generic "frontend" languages for LISP (eg. 
Sugar http://redhog.org/Projects/Programming/Current/Sugar/ ), however I think 
a lot suffer from trying to keep the full metaprogramming capabilities of 
LISP. In other words, they don't stray too far from the nested parentheses 
approach, and strive to support direct 1:1 translation back and forth between 
the notations. This closes off a lot of avenues.

Of course, it is ironic that many subsequent languages have tried to 'beat' 
LISP by having a more 'user friendly' syntax whilst, internally, compiling 
everything to ASTs anyway. If these ASTs were standardised then all of these 
languages would effectively fulfil McCarthy's vision of LISP (as a 'backend' 
language). The AST definitions would essentially be LISP libraries, which 
determine each language's particular semantics.

It's a crying shame that so much attention is focused on a language's syntax, 
whilst the potentially common details of the semantics end up drifting apart 
with each language implementation. For example, compare Perl, PHP, Python, 
Ruby, Smalltalk and Javascript. There are vast semantic differences, but a lot 
of that is simply implementation cruft. The core ideas of each language are 
relatively simple, but rather than being defined by these ideas, instead they 
are defined by an entire bottom-up implementation+standard 
library+compiler/interpreter/VM, etc.

Chris

_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to