On 8/18/2011 11:08 AM, Chris Warburton wrote:
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.
yes, but in many ways, form beats function.
it is often of more benefit to have a pretty language than a powerful one.
for example, it seems possible that many more people might have used
Objective-C had it agreed more with peoples' aesthetic sensibilities.
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.
yep.
after I implemented my Scheme VM, but before I implemented what would
become BGBScript, I had been experimenting with designs like this.
I sort of got "halfway tolerable" with a syntax sort of resembling a mix
of S-Expressions and a Python-style syntax, but this was reasonably
short-lived (offered no strong advantages, and a few larger drawbacks).
a little later, I also developed a language that was intended for
procedural geometry, but ended up mostly used by me as a graphing
calculator. its syntax was primarily designed to be readily typed
interactively (minimization of characters and hand-movements), but had
the drawback of being difficult to make sense of or remember (when not
even the original programmer can remember the syntax much of the time
absent a cheat-sheet, there may be a problem...).
in both cases, there was a more-or-less 1:1 mapping with S-Expressions.
later on, I have mostly just used C-family syntax designs for HLL's,
personally finding it, in general, to provide the best overall tradeoffs
(terseness vs flexibility vs readability vs familiarity). granted,
syntactic similarity doesn't necessarily imply semantic similarity.
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.
yep.
it is funny that, in many ways, my AST format is essentially a Lisp variant.
bit, it has drifted a bit from its original form for semantics reasons
and similar.
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.
yep, but it is problematic to try to create a single VM or IL which can
effectively represent more than a narrow range of languages.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
