How Lisp's Nested Notation Limits The Language's Utility
Xah Lee, 2007-05-03
There is a common complain by programers about lisp's notation, of
nested parenthesis, being unnatural or difficult to read. Long time
lisp programers, often counter, that it is a matter of conditioning,
and or blaming the use of “inferior” text editors that are not
designed to display nested notations. In the following, i describe how
lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for human to read.
Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.
The first issue, that most programers are not comfortable with nested
notation, is well known. It is not a technical issue. Whether it is
considered a problem of the lisp language is a matter of philosophical
disposition.
The second issue, about nested parenthesis not being natural for human
to read, may be debatable. I do think, that deep nesting is a problem
to the programer. Here's a example of 2 blocks of code that are
syntactically equivalent in the Mathematica language:
vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[····@y === 1, π/2, -π/2],
If[y == 0, If[····@x === 1, 0, π],
If[····@y === 1, ······@x, 2 π - ······@x]
]
]
]
SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[π,Power[2,-1]],
Times[Times[-1,π],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,π],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,π],Times[-1,ArcCos[x]]]]]]]]]
In the latter, it uses a full nested form (called FullForm in
Mathematica). This form is isomorphic to lisp's nested parenthesis
syntax, token for token (i.e. lisp's “(f a b)” is Mathematica's
“f[a,b]”). As you can see, this form, by the sheer number of nested
brackets, is in practice problematic to read and type. In Mathematica,
nobody really program using this syntax. (The FullForm syntax is
there, for the same reason of language design principle shared with
lisp of “consistency and simplicity”, or the commonly touted lisp
advantage of “data is program; program is data”.)
The third issue, about how nested syntax seriously discourages
frequent or advanced use of inline function sequencing on the fly, is
the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering unix's
shell syntax. You all know, how convenient and powerful is the unix's
pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
b c | grep xyz | sort | uniq”.
Now suppose, we get rid of the unix's pipe notation, instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
b c)))), or enrich it with a composition function and a pure function
construct (λ), so this example can be written as: ((compose (lambda
(x) (grep xyz x)) sort uniq) (cat a b c)).
You see, how this change, although syntactically equivalent to the
pipe “|” (or semantically equivalent in the example using function
compositions), but due to the cumbersome nested syntax, will force a
change in the nature of the language by the code programer produces.
Namely, the frequency of inline sequencing of functions on the fly
will probably be reduced, instead, there will be more code that define
functions with temp variables and apply it just once as with
traditonal languages.
A language's syntax or notation system, has major impact on what kind
of code or style or thinking pattern on the language's users. This is
a well-known fact for those acquainted with the history of math
notations.
The sequential notation ··@·@·@x”, or “x//h//g//f”, or unixy “x|h|g|
f”, are far more convenient and easier to decipher, than “(f (g (h
x)))” or “((compose h g f) x)”. In actual code, any of the f, g, h
might be a complex pure function (aka lambda construct, full of
parenthesis themselves).
Lisp, by sticking with almost uniform nested parenthesis notation, it
immediately reduces the pattern of sequencing functions, simply
because the syntax does not readily lend the programer to it as in the
unix's “x|h|g|f”. For programers who are aware of the coding pattern
of sequencing functions, now either need to think in terms of a
separate “composition” construct, and or subject to the much
problematic typing and deciphering of nested parenthesis.
(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
equivalents such as the “quote” construct “ '(a b c) ”, and also “`”,
“#”, “,@” constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming standard the
R6RS ↗, even proposes the introduction of [] and {} and few other
syntax sugars to break the uniformity of nested parenthesis for
legibility. Mathematica's FullForm, is actually a pure nested notation
as can be.)
-------
The above, is part of a 3-part exposition:
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations”,
“Prefix, Infix, Postfix notations in Mathematica”,
“How Lisp's Nested Notation Limits The Language's Utility”,
archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
···@xahlee.org
∑ http://xahlee.org/
On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read.
That is false. The complaint does not frequently occur among all of
the complaints occured by the entire population of complaintive
programmers.
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem.
Since 99% of programmers don't use Lisp, it's not a practical problem.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
Programming language syntax shouldn't be natural for humans to read.
Or, rather, this shouldn't be a requirement which creates technical
compromises.
> (3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions.
That is an artifact of the way in which function composition is
rendered in nested syntax, and not an artifact of that syntax itself.
There exist macros that provide alternate syntax for function
composition, such as a left-to-right pipeline.
> This aspect is the most devastating.
Compared to issues like global warming and problems in the Middle
East, hardly.
> The first issue, that most programers are not comfortable with nested
> notation, is well known.
Many programmers are also not comfortable in social situations. So
what?
> shell syntax. You all know, how convenient and powerful is the unix's
> pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a
> b c | grep xyz | sort | uniq”.
>
> Now suppose, we get rid of the unix's pipe notation, instead, replace
> it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a
> b c)))),
When you think about this more deeply (i.e. at all) you run into nasty
details. These programs pass their output to each other, but they also
have a return value (termination status) which isn't passed through
the pipeline. And they take arguments, but the arguments of a pipeline
element are not derived from the previous pipeline element.
Your call (grep xyz (cat ...)) means to pass the output of cat as the
third argument of grep.
In the POSIX shell, this would be coded using guess what, Lisp-like
syntax:
grep xyz $(cat ...)
Taking it further:
uniq $(sort $(grep xyz $(cat a b c)))
or enrich it with a composition function and a pure function
> construct (λ), so this example can be written as: ((compose (lambda
> (x) (grep xyz x)) sort uniq) (cat a b c)).
I posted a filter macro in comp.lang.lisp which expresses function
chaining into a left-to-right notation. Look for it.
In this notation, you might write:
(filter 3 (expt _ 2) (* 4))
which means, start with 3, raise it to the power of 2 to obtain 9, and
then multiply by 4 to get 36.
The underscore indicates the argument position where the output of the
previous pipeline element is to be inserted when calling the next
pipeline element. The default is to add it as a rightmost argument.
The macro has features for dealing with splitting and recombining
lists, and handling multiple values.
This is still the same ``pure nested'' syntax; it merely expresses
function chaining differently.
What was that about notation limiting language utility?
Kaz Kylheku wrote:
> On May 4, 5:11�pm, Xah Lee <····@xahlee.org> wrote:
>> (1) Some 99% of programers are not used to the nested parenthesis
>> syntax. This is a practical problem.
>
> Since 99% of programmers don't use Lisp, it's not a practical problem.
If you're being pedantic, you may mean "it is an uncommon practical
problem". However, the problem extends beyond Lisp.
Recent discussions have covered the use of pattern matching. In SML, OCaml,
Haskell (I believe) and F# you must write pattern matches over the expr
type in prefix notation. To borrow from Alan's example, the Lisp code:
(destructuring-bind (op1 (op2 n x) y) form
`(* ,n (* ,(simplify x) ,(simplify y)))))
((cons (eql *) *)
(destructuring-bind (op left right) form
(list op
(simplify left)
(simplify right))))
((cons (eql +)
(cons (eql 0)
(cons * null)))
could be written:
| n*x*y -> n*(x*y)
but in ML this must be written as a pattern match over a sum type where the
type constructors must use prefix notation:
| Mul(Mul(n, x), y) -> Mul(n, Mul(x, y))
While this is clearly much better than the Lisp, it would be preferable to
use the mathematical syntax in this case. You can address this in OCaml
using macros and there is a chance that F# will support overloaded
operators in patterns in the future.
Mathematica lets you do:
n x y -> n (x y)
but I don't know of any other languages that do, without forcing you to
reinvent the wheel via macros.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
"Kaz Kylheku" <········@gmail.com> wrote in message
····························@w5g2000hsg.googlegroups.com...
On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
>> How Lisp's Nested Notation Limits The Language's Utility
>> (2) Arguably, the pure nested syntax is not natural for human to read.
>> Long time lispers may disagree on this point.
>
>Programming language syntax shouldn't be natural for humans to read.
>Or, rather, this shouldn't be a requirement which creates technical
>compromises.
>
I couldn't disagree more. Occasionally you do need to use a language with no
technical compromises whatsoever - pure assembly or machine code - but only
rarely. Most of the time we accept some limitations for the sake of making
things easier for the human programmer. That includes run-time efficiency,
but also restrictions in the "power" of the language.
You might be interested in the page 10 Rules of Computer Programming on my
website which deals with psychological issues in programming. Lisp breaks
the rule of three in spades.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"Malcolm McLean" <·········@btinternet.com> writes:
> You might be interested in the page 10 Rules of Computer Programming
> on my website which deals with psychological issues in
> programming. Lisp breaks the rule of three in spades.
Rule three is about indirection, not about nesting. The other rules
suck also. If your "Refutation of Common Atheist Arguments" have a
similar quality, the atheists will have a field day.
Regards -- Markus
Markus E Leypold wrote:
> "Malcolm McLean" <·········@btinternet.com> writes:
>
>
>>You might be interested in the page 10 Rules of Computer Programming
>>on my website which deals with psychological issues in
>>programming. Lisp breaks the rule of three in spades.
>
>
> Rule three is about indirection, not about nesting. The other rules
> suck also. If your "Refutation of Common Atheist Arguments" have a
> similar quality, the atheists will have a field day.
Perhaps it's not a coincidence that these two seemingly unrelated
arguments are offered by the same person. Both religious belief and a
belief in the essential importance of syntactic sugar require abandoning
Occam's Razor.
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message
······················@newssvr11.news.prodigy.net...
> Markus E Leypold wrote:
>> "Malcolm McLean" <·········@btinternet.com> writes:
>>
>>
>>>You might be interested in the page 10 Rules of Computer Programming
>>>on my website which deals with psychological issues in
>>>programming. Lisp breaks the rule of three in spades.
>>
>>
>> Rule three is about indirection, not about nesting. The other rules
>> suck also. If your "Refutation of Common Atheist Arguments" have a
>> similar quality, the atheists will have a field day.
>
> Perhaps it's not a coincidence that these two seemingly unrelated
> arguments are offered by the same person. Both religious belief and a
> belief in the essential importance of syntactic sugar require abandoning
> Occam's Razor.
>
I can't defend 12 Common Atheist Arguments (refuted) here, for obvious
reasons, without irritating a lot of Lispers.
A programming language is inherently a compromise between the needs of the
human programmer and the needs of the computer. That's why the 10 rules of
computer programming are all psychological rules. There are many other
things you need to know to program a computer, but they are documented with
the system. The difference is, if you break a psychological rule then the
program still works, but it is too difficult to maintain.
The rules are also ones which people might be tempted to break - obviously
writing code with no comments and one letter identifiers is a bad idea, but
people don't need to be told that, so it's not a rule.
The rule of three was written before I was familiar with Lisp, and so you
might say that Lisp is a counter-example. I don't think it is, because the
first thing that everyone says about Lisp is "I can't do with all those
parentheses". In fact Lisp programmers use indentation to try to impose
another hierarchy of structure on the program, something they wouldn't need
to do if humans could glance at a long expression and match up parentheses.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
In article <································@bt.com>,
"Malcolm McLean" <·········@btinternet.com> wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message
> ······················@newssvr11.news.prodigy.net...
> > Markus E Leypold wrote:
> >> "Malcolm McLean" <·········@btinternet.com> writes:
> >>
> >>
> >>>You might be interested in the page 10 Rules of Computer Programming
> >>>on my website which deals with psychological issues in
> >>>programming. Lisp breaks the rule of three in spades.
> >>
> >>
> >> Rule three is about indirection, not about nesting. The other rules
> >> suck also. If your "Refutation of Common Atheist Arguments" have a
> >> similar quality, the atheists will have a field day.
> >
> > Perhaps it's not a coincidence that these two seemingly unrelated
> > arguments are offered by the same person. Both religious belief and a
> > belief in the essential importance of syntactic sugar require abandoning
> > Occam's Razor.
> >
> I can't defend 12 Common Atheist Arguments (refuted) here, for obvious
> reasons, without irritating a lot of Lispers.
> A programming language is inherently a compromise between the needs of the
> human programmer and the needs of the computer. That's why the 10 rules of
> computer programming are all psychological rules. There are many other
> things you need to know to program a computer, but they are documented with
> the system. The difference is, if you break a psychological rule then the
> program still works, but it is too difficult to maintain.
> The rules are also ones which people might be tempted to break - obviously
> writing code with no comments and one letter identifiers is a bad idea, but
> people don't need to be told that, so it's not a rule.
>
> The rule of three was written before I was familiar with Lisp, and so you
> might say that Lisp is a counter-example. I don't think it is, because the
> first thing that everyone says about Lisp is "I can't do with all those
> parentheses". In fact Lisp programmers use indentation to try to impose
> another hierarchy of structure on the program, something they wouldn't need
> to do if humans could glance at a long expression and match up parentheses.
The basic problem is that people coming to Lisp have all kinds
of interesting experiences and believes. But Lisp tends to
do things differently. It questions those prior experiences
and believes. But we are unwilling to question what we learned
is true. It is not that the Lisp way is better, but it is
different. Accepting that a different approach to software
development may also make sense seems to be hard.
Once these people get converted, they are the most
active evangelists. ;-)
So the basic first thing when you come to Lisp from other
programming languages and development tools is UNLEARNING.
That's also a reason Lisp was (is?) once popular in computer science
courses. Students are coming to the university full of
prior knowledge (basic, c, ... what ever programming).
Then they have to use Lisp to solve problems. Shock. Horror.
All are suddenly beginners and have to learn something
completely new.
* You work bottom-up talking to a partial ready program?
No batch compiler? No half-hour turn around times with
enough time for a long coffee break?
* No fixed language? No half year waiting time unless
you get a new operator into your language?
Language building built-in?
* S-expressions? Easy manipulation of code by integrated tools?
* Multiple paradigms in one language?
And so on.
About the Lisp syntax has been written quite a lot, I'm
not repeating it. Only a few words.
For me Lisp code is different from Pascal/C++/.. or other code
because it has a completely look & feel. The feel
is also an interesting part.
You see direct manipulative user interfaces quite a lot.
We drag icons around. We get instant visual feedback
from graphical user interfaces. Yet programming
often is far from interactive.
When I press keys and write code, is there a direct connection
from the brain to what I see on the screen and back?
In less than a second?
When I write code for a batch system, I type to an
editor and the objects I work with are characters,
words, sentences. Functions, declarations, etc.
The running application is far away. I have to imagine
what my code will do once it runs. Not so in Lisp.
When I write Lisp code, I talk to an object system via
code on the screen. There is something alive on the other
side. It is a running Lisp image fully loaded with functions, objects,
Lisp code. I type a bit code. Then I give that code to the Lisp
system. Let it compile, execute. I take the literal code and
let it reformat, restructure, walk (macroexpand at all levels).
I talk to a debugger who gives me access to the objects,
functions and the code. So Lisp code has a feel associated to
it. You can manipulate it much more directly and you
can inspect it, reuse it. Pressing enter in an Lisp editor
immediately executes something. This direct interaction
with the program is more extreme on the Lisp machine where
you had the special keyboards tailored for the programmer.
It had a suspend key. When you run a tool in a window
and you press suspend you get a REPL where you can talk
with Lisp directly to the application. This was
for example useful in an editor where you have some
Lisp code, you want to check something, pressing suspend
brings you into an editor typeout window with a REPL,
do a few experiments, press continue. Suddenly the code
is like clay in your hands (some say 'mud'). Code
is no long a bunch of characters. Code suddenly
is data. Data is code.
Another thing adds to that direct manipulative feeling
of Lisp code. Each basic form is enclosed in parentheses.
So you have visual markers for the form. You see where
it begins, where it ends and what is between. If you
want to select a specific form you can click on visual
markers, the parentheses to grab the form. You don't edit
code based on remembering syntax diagrams or operator
precedence. You edit lists of symbols that have a
textual representation and that have a representation
in a running program.
When you work like that, you'll be near the 'flow',
where there is extremely little distance between
your thoughts and an executable form of those thoughts.
Changes and effects are immediate.
But first you have to unlearn batch programming and
hostile syntaxes - both are standing between you and
interactive incremental development with a flexible
language that has direct manipulative qualities.
--
http://lispm.dyndns.org
From: Malcolm McLean
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <OfSdnYLVtYi2eqHbRVnyjwA@bt.com>
"Rainer Joswig" <······@lisp.de> wrote in message
·································@news-europe.giganews.com...
> In article <································@bt.com>,
> "Malcolm McLean" <·········@btinternet.com> wrote:
>
> When I write code for a batch system, I type to an
> editor and the objects I work with are characters,
> words, sentences. Functions, declarations, etc.
> The running application is far away. I have to imagine
> what my code will do once it runs. Not so in Lisp.
>
> When I write Lisp code, I talk to an object system via
> code on the screen. There is something alive on the other
> side. It is a running Lisp image fully loaded with functions, objects,
> Lisp code. I type a bit code. Then I give that code to the Lisp
> system. Let it compile, execute. I take the literal code and
> let it reformat, restructure, walk (macroexpand at all levels).
> I talk to a debugger who gives me access to the objects,
> functions and the code. So Lisp code has a feel associated to
> it. You can manipulate it much more directly and you
> can inspect it, reuse it.
>
This makes a lot of sense. I know that I ought to integrate Lisp with emacs,
but I can't get it to work. So I'm writing it like C - write the script, and
submit it. So it works, but not nicely, and I am always counting parentheses
and thinking that, yes, I can see the computer science logic behind this,
but I don't see how I can write a non-trivial program as a programmer.
In software development tools are everything. When you can do things easily
it doesn't just enhance productivity, it actually means you can do more
things - you can draw a picture with a mouse, but not by setting pixel
values in code.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Malcolm McLean <·········@btinternet.com> wrote:
+---------------
| "Rainer Joswig" <······@lisp.de> wrote in message
| > When I write code for a batch system, I type to an
| > editor and the objects I work with are characters,
| > words, sentences. Functions, declarations, etc.
| > The running application is far away. I have to imagine
| > what my code will do once it runs. Not so in Lisp.
| >
| > When I write Lisp code, I talk to an object system via code
| > on the screen. There is something alive on the other side.
| > It is a running Lisp image fully loaded with functions, objects,
| > Lisp code. I type a bit code. Then I give that code to the Lisp...
| > I talk to a debugger who gives me access to the objects,
| > functions and the code. So Lisp code has a feel associated to it. ...
|
| This makes a lot of sense. I know that I ought to integrate Lisp
| with emacs, but I can't get it to work. So I'm writing it like C -
| write the script, and submit it. So it works, but not nicely, and
| I am always counting parentheses...
+---------------
1. Get an editor -- *ANY* editor, not necessarily Emacs -- which
at the *very* least *balances* [not counts -- nobody counts]
parentheses for you. For example, in most versions of Vi[1]
":set showmatch matchtime=2" will "flash" the cursor back on
the matching open parenthesis for ~200ms whenever you're in
insert mode and type a closing parenthesis. And when sitting
with the cursor on a parenthesis [either flavor], the "%" command
will move you to the matching parenthesis, and when used as
the "motion" command of a any of the commands that take motion
commands to specify their scope, will select the entire s-expr
as the argument. That is, "ady (or "ad%) will copy an s-expr
into Q-register "a (or delete it, respectively); the "ap commmand
will "paste" it back, >% and <% will shift all of the lines
containing the s-expr right or left, respectively. [Note: When
using Vi for Lisp, it helps to ":set shiftwidth=1". Then you
can do >%... to shift some form right four spaces, etc.]
2. You speak of "scripts": {Develop,Choose,Use consistently}
*some* stylized way of writing your scripts that lets you
load them into a running CL image *without* executing them,
so you can debug them at the REPL rather than in "batch" mode
as you seem to be doing [and as Rainer rightfully criticizes].
That lets you *use* the powerful debugging tools that exist
inside most Lisp systems.
For example [not to be blindly copied, but just so you know
that I *do* practice what I preach here], I have the CL that
I most often use [CMUCL] set up so that when I run it with a
REPL, the keyword :REPL ends up on a *SCRIPT-EXIT-HOOKS* list,
but *not* if it's run from a script[2]. So I write all of my
"#!/usr/local/bin/cmucl -script" scripts[3] with a MAIN function
that does all the work, and then at the very bottom of each
script file contains this:
(unless (find :repl *script-exit-hooks*) ; Debugging?
(apply 'main *script-args*))
or this [depending on the needs of the particular script]:
(unless (find :repl *script-exit-hooks*) ; Debugging?
(apply 'main (mapcar #'read-from-string *script-args*)))
[...where *SCRIPT-ARGS* ends up being a list of lightly-massaged
*COMMAND-LINE-STRINGS*.]
The point of this is that if you run the script from the shell,
it "just runs". But if you start up your REPL and LOAD the script,
it just sits there and waits for you to poke at it from the REPL,
e.g., by calling MAIN with a list of manually-constructed command-
line arguments, or by calling some of the internal functions of
your script, etc. If something goes wrong, you drop into the
internal Lisp debugger, where you have access to the entire
environment *and* a full CL implementation at your command,
including the compiler!
3. *Use* the Lisp environment you make your life easier!!
Define as many little personal "conveniece" functions
and/or macros as you find you want or need, and arrange
that they get loaded into your default REPL. Here's just
a small subset of mine:
;;; More shortcuts & conveniences:
(defun ap (string &optional package) ; be more liberal about 2nd arg
(apply #'apropos string (when package (list (find-package package)))))
(defun de (&rest rest) (apply #'describe rest))
(defun dis (&rest rest) (apply #'disassemble rest))
(defun mxp (&rest rest) (pprint (apply #'macroexpand rest)))
(defun mxp0 (&rest rest) (apply #'macroexpand rest)) ; same, but w/o PP
(defun mxp1 (&rest rest) (apply #'macroexpand-1 rest))
(defun mxp* (&rest rest) (apply #'walker:macroexpand-all rest)) ; CMUCL only
;;; For REPL compiles of functions with non-NIL lexical environments,
;;; e.g, (COMPILE* (let ((y 5)) (defun add5 (x) (+ x y)))).
(defmacro compile* (&body body)
`(funcall (compile nil (lambda () ,@body))))
;;; I don't know why I find myself needing this so often, but I do...
(defun hash-table-alist (hash-table &key (test (constantly t)))
(loop for key being each hash-key in hash-table using (hash-value value)
when (funcall test key value)
collect (cons key value)))
4. *Use* the Lisp environment you make your life easier!!
If you can't (or don't want to) use ASDF or MK:DEFSYSTEM
or equiv., at least whip yourself up a little function
that's loaded into your default REPL that lets you reload
and/or recompile all the files you're currently working on --
something short [e.g., "REDO"] that's data-driven [e.g., a
global named *USER-LOAD-LIST*, maybe]. I have one[4] that I
call LOAD*, that does the following:
- Remembers when it was last called.
- If called with args, adds them to the end of *USER-LOAD-LIST*
(suppressing duplicates).
- For each file in the [possibly-just-modified] *USER-LOAD-LIST*,
if the FILE-WRITE-DATE of either the file or [if a compiled
version already exists] the compiled version of it is newer
than the last LOAD* time, re-LOAD that file [recompiling it
first, iff a compiled version already existed].
Then say (DEFUN REDO () (LOAD*) (current-unit-test args...)),
and your "edit/compile/test" cycle becomes:
- Type "Save" in all the editor windows in which you've made changes.
- Type (REDO) to the REPL.
- [Optional:] If what you're working on is a persistent web
applications server, hit your web browser's "Reload" or "Refresh".
That's all the basic "IDE" you need to be *very* productive
in Lisp [CL, Scheme, whatever].
Now that you know all this, time to start coding. *NOW!!*
[Or I'll sic Kenny on you... ;-} ]
-Rob
[1] Some Lispers may consider me a heretic because I don't use Emacs
when writing Lisp. Tough. [I've *tried* to, several times, but
my fingers just don't bend that way. And besides, I've been using
"moded" editors like TECO, Bravo, Ed, & Vi for more than half my
total lifetime.] Frankly, I spend such a *small* percentage of
my programming time on "editor issues" that I simply don't buy
the "I don't have (or can't use) the perfect editor (or IDE)"
obstacle as a legitimate excuse for not simply getting on with
Lisp programming [though as noted in the text above it *does*
help a lot if you have an editor that at least *shows* you the
balancing paren, even better if it can delete/shift an s-expr
as a group -- which almost *all* can, even if not with a single
keystroke].
So if someone says, "I can't use Lisp... no {Emacs,SLIME,IDE}..."
I just say, "FIDO!" [An acronym of supposed military origin;
the last two letters stand for "Drive On"...]
[2] Unless the script explicitly chooses to push it onto the list. ;-}
Which is how I normally run CMUCL -- with a script named "cmu"
that sets up a bunch of stuff, REQUIREs the usual suspects,
pushes :REPL onto *SCRIPT-EXIT-HOOKS*, and falls off the bottom.
This causes "cmucl -script"[3] to start a REPL and *not* silently
exit [which is what a good script should normally do otherwise].
[3] (*sigh*) I've been promising to put my "-script" extension
to CMUCL on the net for entirely too long. Soon, soon...
[Hint for home hobbyists who don't want to wait: It's implemented
by adding a few lines to "/usr/local/lib/cmucl/lib/site-init.lisp"...]
[4] No, I'm not going to clutter this article any more than
it already is with my version of LOAD*. It's simple enough
[mine's only ~40 lines, could be even shorter], and is a
good beginner exercise for one to get used to building
their own personalized "conveniences".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> ;;; I don't know why I find myself needing this so often, but I do...
> (defun hash-table-alist (hash-table &key (test (constantly t)))
> (loop for key being each hash-key in hash-table using (hash-value value)
> when (funcall test key value)
> collect (cons key value)))
Perhaps in your implementation the hash-table are printed opaquely?
In clisp, they dump their contents. I had to write something similar
when I used acl...
> [4] No, I'm not going to clutter this article any more than
> it already is with my version of LOAD*. It's simple enough
> [mine's only ~40 lines, could be even shorter], and is a
> good beginner exercise for one to get used to building
> their own personalized "conveniences".
In some implementations it's also possible to define debugger or
toplevel commands, so you can write some shortcut or specialized
debugging functions for your program.
And if your editor is customizable, you can also add commands in the
editor sending commands to the inferior lisp to automate some stuff,
or add an easy interface to your lisp. For example, I bind function
keys to clisp debugger commands when I use STEP:
(defun clisp-debug-keys ()
"Binds locally some keys to send clisp debugger commands to the inferior-lisp"
(interactive)
(macrolet ((cmd (string)
`(lambda ()
(interactive)
(comint-send-string (inferior-lisp-proc)
,(format "%s\n" string)))))
(local-set-key (kbd "<f5>") (cmd ":s"))
(local-set-key (kbd "<f6>") (cmd ":n"))
(local-set-key (kbd "<f7>") (cmd ":o"))
(local-set-key (kbd "<f8>") (cmd ":c"))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
Pascal Bourguignon <···@informatimago.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
|
| > ;;; I don't know why I find myself needing this so often, but I do...
| > (defun hash-table-alist (hash-table &key (test (constantly t)))
| > (loop for key being each hash-key in hash-table using (hash-value value)
| > when (funcall test key value)
| > collect (cons key value)))
|
| Perhaps in your implementation the hash-table are printed opaquely?
+---------------
Yup. CMUCL: ;-}
cmu> (make-hash-table)
#<EQL hash table, 0 entries {4893DD45}>
cmu> (loop for i in (iota 20) do (setf (gethash i *) (* i i)))
NIL
cmu> **
#<EQL hash table, 20 entries {4893DD45}>
cmu> (hash-table-alist *)
((0 . 0) (1 . 1) (2 . 4) (3 . 9) (4 . 16) (5 . 25) (6 . 36)
(7 . 49) (8 . 64) (9 . 81) (10 . 100) (11 . 121) (12 . 144)
(13 . 169) (14 . 196) (15 . 225) (16 . 256) (17 . 289)
(18 . 324) (19 . 361))
cmu>
+---------------
| > [4] No, I'm not going to clutter this article any more than
| > it already is with my version of LOAD*. It's simple enough
| > [mine's only ~40 lines, could be even shorter], and is a
| > good beginner exercise for one to get used to building
| > their own personalized "conveniences".
|
| In some implementations it's also possible to define debugger or
| toplevel commands, so you can write some shortcut or specialized
| debugging functions for your program.
+---------------
Ah, yezz... :FOO or ,FOO at the top level. It's not in CMUCL
(by default), but I think there's a package mentioned somewhere
on CLiki that will do that, by replacing the top-level reader.
+---------------
| And if your editor is customizable, you can also add commands in the
| editor sending commands to the inferior lisp to automate some stuff,
| or add an easy interface to your lisp.
+---------------
Indeed, though since the OP said "emacs...can't get it to work", I
was trying to show that not having an "inferior lisp" connection at
all shouldn't be considered a deal-breaker obstacle to using Lisp
[and in fact, really isn't an obstacle at all].
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <·······················@bt.com>,
"Malcolm McLean" <·········@btinternet.com> wrote:
> "Rainer Joswig" <······@lisp.de> wrote in message
> ·································@news-europe.giganews.com...
> > In article <································@bt.com>,
> > "Malcolm McLean" <·········@btinternet.com> wrote:
> >
> > When I write code for a batch system, I type to an
> > editor and the objects I work with are characters,
> > words, sentences. Functions, declarations, etc.
> > The running application is far away. I have to imagine
> > what my code will do once it runs. Not so in Lisp.
> >
> > When I write Lisp code, I talk to an object system via
> > code on the screen. There is something alive on the other
> > side. It is a running Lisp image fully loaded with functions, objects,
> > Lisp code. I type a bit code. Then I give that code to the Lisp
> > system. Let it compile, execute. I take the literal code and
> > let it reformat, restructure, walk (macroexpand at all levels).
> > I talk to a debugger who gives me access to the objects,
> > functions and the code. So Lisp code has a feel associated to
> > it. You can manipulate it much more directly and you
> > can inspect it, reuse it.
> >
> This makes a lot of sense. I know that I ought to integrate Lisp with emacs,
> but I can't get it to work. So I'm writing it like C - write the script, and
> submit it. So it works, but not nicely, and I am always counting parentheses
> and thinking that, yes, I can see the computer science logic behind this,
> but I don't see how I can write a non-trivial program as a programmer.
> In software development tools are everything. When you can do things easily
> it doesn't just enhance productivity, it actually means you can do more
> things - you can draw a picture with a mouse, but not by setting pixel
> values in code.
You might want to try out one of the no/low-cost versions
of commercial Lisp systems, which usually come
with interactive environments (Allegro CL on
some platforms, LispWorks, Corman CL, MCL, ...).
--
http://lispm.dyndns.org
From: Miles Bader
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87abwjwhr3.fsf@catnip.gol.com>
"Malcolm McLean" <·········@btinternet.com> writes:
> You might be interested in the page 10 Rules of Computer Programming on
> my website which deals with psychological issues in programming. Lisp
> breaks the rule of three in spades.
That suggests that the "rule of three" is wrong...
-Miles
--
o The existentialist, not having a pillow, goes everywhere with the book by
Sullivan, _I am going to spit on your graves_.
From: Jay Belanger
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <878xbzds6s.fsf@gmail.com>
Miles Bader <·····@gnu.org> writes:
> "Malcolm McLean" <·········@btinternet.com> writes:
>> You might be interested in the page 10 Rules of Computer Programming on
>> my website which deals with psychological issues in programming. Lisp
>> breaks the rule of three in spades.
>
> That suggests that the "rule of three" is wrong...
Multiplication is vexation,
Division is as bad;
The Rule of Three doth puzzle me,
And Practice drives me mad.
From: Arved Sandstrom
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <z4o%h.5219$Vi6.3376@edtnps82>
"Malcolm McLean" <·········@btinternet.com> wrote in message
·····································@bt.com...
>
> "Kaz Kylheku" <········@gmail.com> wrote in message
> ····························@w5g2000hsg.googlegroups.com...
> On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
>>> How Lisp's Nested Notation Limits The Language's Utility
>>> (2) Arguably, the pure nested syntax is not natural for human to read.
>>> Long time lispers may disagree on this point.
>>
>>Programming language syntax shouldn't be natural for humans to read.
>>Or, rather, this shouldn't be a requirement which creates technical
>>compromises.
>>
> I couldn't disagree more. Occasionally you do need to use a language with
> no technical compromises whatsoever - pure assembly or machine code - but
> only rarely. Most of the time we accept some limitations for the sake of
> making things easier for the human programmer. That includes run-time
> efficiency, but also restrictions in the "power" of the language.
[ SNIP ]
You two are not referring to the same thing. Syntax is not related to the
power of a language (or the lack thereof) in the slightest. Plenty of
languages that operate at higher levels than machine code or assembler are
just as terse and non-intelligible to the uninformed. Kaz simply made a
reference to syntax.
AHS
"Arved Sandstrom" <··········@accesswave.ca> wrote in message
························@edtnps82...
> "Malcolm McLean" <·········@btinternet.com> wrote in message
> ·····································@bt.com...
>>
>> "Kaz Kylheku" <········@gmail.com> wrote in message
>> ····························@w5g2000hsg.googlegroups.com...
>> On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
>>>> How Lisp's Nested Notation Limits The Language's Utility
>>>> (2) Arguably, the pure nested syntax is not natural for human to read.
>>>> Long time lispers may disagree on this point.
>>>
>>>Programming language syntax shouldn't be natural for humans to read.
>>>Or, rather, this shouldn't be a requirement which creates technical
>>>compromises.
>>>
>> I couldn't disagree more. Occasionally you do need to use a language with
>> no technical compromises whatsoever - pure assembly or machine code - but
>> only rarely. Most of the time we accept some limitations for the sake of
>> making things easier for the human programmer. That includes run-time
>> efficiency, but also restrictions in the "power" of the language.
> [ SNIP ]
>
> You two are not referring to the same thing. Syntax is not related to the
> power of a language (or the lack thereof) in the slightest. Plenty of
> languages that operate at higher levels than machine code or assembler are
> just as terse and non-intelligible to the uninformed. Kaz simply made a
> reference to syntax.
>
If we use the term "syntax" in the narrow sense then Kaz's statement is
nonsense, because syntax is simply the convention for noting the grammar.
For instance we could use "begin" and "end" instead of '(' and ')' to open
and close lists, without changing anything fundamental about the language,
but it wouldn't be a good idea because it would be totally unreadable. A
change in syntax inherently can't create technical compromises, unless I
suppose you demand a symbol like $ which might not be available on some
machines.
If we use it in the broader sense then we've got something to argue about.
Let's say that we agree that add(1, 2, 3) is easier to read than (add 1 2
3), and we change the underlying representation so that "function calls" are
separate from "lists". Now we've made the language less tidy at the machine
level, but we've also given an advantage to the human programmer. There is
no easy or "right" answer to these questions. My own programming language,
MiniBasic (see website) makes huge technical compromises, such as having
only one numerical type, to make the language easier to learn, because that
is the priority.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
From: Arved Sandstrom
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <_LD0i.25302$au6.432@edtnps90>
"Malcolm McLean" <·········@btinternet.com> wrote in message
·····································@bt.com...
>
> "Arved Sandstrom" <··········@accesswave.ca> wrote in message
> ························@edtnps82...
>> "Malcolm McLean" <·········@btinternet.com> wrote in message
>> ·····································@bt.com...
>>>
>>> "Kaz Kylheku" <········@gmail.com> wrote in message
>>> ····························@w5g2000hsg.googlegroups.com...
>>> On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
>>>>> How Lisp's Nested Notation Limits The Language's Utility
>>>>> (2) Arguably, the pure nested syntax is not natural for human to read.
>>>>> Long time lispers may disagree on this point.
>>>>
>>>>Programming language syntax shouldn't be natural for humans to read.
>>>>Or, rather, this shouldn't be a requirement which creates technical
>>>>compromises.
>>>>
>>> I couldn't disagree more. Occasionally you do need to use a language
>>> with no technical compromises whatsoever - pure assembly or machine
>>> code - but only rarely. Most of the time we accept some limitations for
>>> the sake of making things easier for the human programmer. That includes
>>> run-time efficiency, but also restrictions in the "power" of the
>>> language.
>> [ SNIP ]
>>
>> You two are not referring to the same thing. Syntax is not related to the
>> power of a language (or the lack thereof) in the slightest. Plenty of
>> languages that operate at higher levels than machine code or assembler
>> are just as terse and non-intelligible to the uninformed. Kaz simply made
>> a reference to syntax.
>>
> If we use the term "syntax" in the narrow sense then Kaz's statement is
> nonsense, because syntax is simply the convention for noting the grammar.
> For instance we could use "begin" and "end" instead of '(' and ')' to open
> and close lists, without changing anything fundamental about the language,
> but it wouldn't be a good idea because it would be totally unreadable. A
> change in syntax inherently can't create technical compromises, unless I
> suppose you demand a symbol like $ which might not be available on some
> machines.
I suspect that he was talking about this interpretation of syntax.
> If we use it in the broader sense then we've got something to argue about.
> Let's say that we agree that add(1, 2, 3) is easier to read than (add 1 2
> 3), and we change the underlying representation so that "function calls"
> are separate from "lists". Now we've made the language less tidy at the
> machine level, but we've also given an advantage to the human programmer.
> There is no easy or "right" answer to these questions. My own programming
> language, MiniBasic (see website) makes huge technical compromises, such
> as having only one numerical type, to make the language easier to learn,
> because that is the priority.
In this broad sense you are then talking about grammar, really, because as
you've said, syntax is the notation for the grammar.
Deciding that a variable 'a' can be of any datatype available in the
language, depending on what is assigned to it, is not a syntactical issue -
it's grammatical. Which you know...I'm not trying to tell my grandmother how
to suck eggs.
I think Kaz's point might be best understood by looking at the difference
between J and C and Haskell and Java (or comparable languages). J is pure
line noise - much worse than Perl - but also very powerful. C can be line
noise too (and if you look at Numerical Recipes in C you'll see some
examples), but is much less powerful than J. Perl is C-ish, but has its
forays into line noise, and is intermediate in programming power. Haskell
seems to be very readable (when well written), and is powerful, but some
people just won't like the FP-paradigm...so no Haskell for them. Java -
again when well written - is also very readable, but it's a low to mid-level
language in terms of power...one has to write too much code to get stuff
done in comparison to high-level languages.
Is Prolog easy to read? No. Yet you can do stuff with that which is not
going to happen with a bunch of other languages.
I think that was Kaz' point. Some of the languages I just mentioned make no
particular (or any) attempt to cater to ease of learning, and have syntaxes
that are quite difficult to pick up. Yet they are amongst the most powerful
languages. And the chosen syntax actually promotes the chosen grammar. For
example, people choose J because they want a really concise and powerful
chainsaw, where two lines of J replaces a page of Java...the syntax has to
reflect that. They choose Perl or UNIX shell because they can slap together
a quick and dirty script in 5 minutes, where writing it in C++ would take
hours. Conversely, they may choose C when they want to write an SQL UDF or a
UNIX tool. In the case of Perl, UNIX shell, and C, the ugliness (or
prettiness) of the syntax is roughly comparable - the grammars are highly
different.
AHS
On May 5, 12:50 am, "Malcolm McLean" <·········@btinternet.com> wrote:
> Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1mm
Nutjob.
From: Robert D. Crawford
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87irb8846z.fsf@comcast.net>
Xah Lee <···@xahlee.org> writes:
> How Lisp's Nested Notation Limits The Language's Utility
You know, I am all about keeping one's eyes open so as to see the
limitations of the tools one chooses or is forced to use. If more
people were open to the flaws in their OS, religion, editor, and a
myriad of other things the world would surely be a better and more
peaceful place. However, I have to say that all I ever see from you,
Mr. Lee, is complaints and how you want emacs and lisp to change. For
the love of whatever god you choose to pray to, find a frigging tool
that makes you happy. If it is emacs that makes you happy, then change
the things you don't like and be happy but I fail to see how your
whining diatribes serve any useful purpose. If you don't like lisp then
by all means use something else.
No offense but it does get old after a while.
--
Robert D. Crawford ·····@comcast.net
Marriage is learning about women the hard way.
From: Miles Bader
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <873b2cxbxt.fsf@catnip.gol.com>
"Robert D. Crawford" <·····@comcast.net> writes:
> If it is emacs that makes you happy, then change the things you don't
> like and be happy but I fail to see how your whining diatribes serve
> any useful purpose. If you don't like lisp then by all means use
> something else.
Xahlee likes to complain. That's the main factor here.
-Miles
--
Run away! Run away!
"Miles Bader" <·····@gnu.org> wrote in message
···················@catnip.gol.com...
> "Robert D. Crawford" <·····@comcast.net> writes:
>> If it is emacs that makes you happy, then change the things you don't
>> like and be happy but I fail to see how your whining diatribes serve
>> any useful purpose. If you don't like lisp then by all means use
>> something else.
>
> Xahlee likes to complain. That's the main factor here.
>
There is thought and intelligence in his posts. However they are provocative
in both the good and the bad sense of the term, and rather eccentric.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"Malcolm McLean" <·········@btinternet.com> writes:
> "Miles Bader" <·····@gnu.org> wrote in message
> ···················@catnip.gol.com...
>> "Robert D. Crawford" <·····@comcast.net> writes:
>>> If it is emacs that makes you happy, then change the things you don't
>>> like and be happy but I fail to see how your whining diatribes serve
>>> any useful purpose. If you don't like lisp then by all means use
>>> something else.
>>
>> Xahlee likes to complain. That's the main factor here.
>>
> There is thought and intelligence in his posts. However they are
> provocative in both the good and the bad sense of the term, and rather
Where is the good sense in there? We have (at c.l.f) people
complaining about parenthesis in lisp every 3 months and the arguments
never get any better or new. Rehashing all that once again doesn't
attest to "thought and intelligence" but rather to a trollish streak.
Regards -- Markus
From: Miles Bader
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87irb7whtw.fsf@catnip.gol.com>
Markus E Leypold
<·····································@ANDTHATm-e-leypold.de> writes:
> Where is the good sense in there? We have (at c.l.f) people
> complaining about parenthesis in lisp every 3 months and the arguments
> never get any better or new. Rehashing all that once again doesn't
> attest to "thought and intelligence" but rather to a trollish streak.
Indeed, and people have been saying what Xahlee's saying since the
_1950s_! Lisp still has the parens, and there are good reasons for that.
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
The first time I saw graph-theory notation, I thought it was
gibberish. I still think most mathematical notation is gibberish, but
I deal with it --- I don't turn in proofs written in prose.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
And mathematical notation is not natural for people to read, at least
not anybody who grew up learning a natural language. But people deal
with it. They're remarkably adaptable this way.
> vectorAngle[{a1_, a2_}] := Module[{x, y},
> {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> If[x == 0, If[····@y === 1, π/2, -π/2],
> If[y == 0, If[····@x === 1, 0, π],
> If[····@y === 1, ······@x, 2 π - ······@x]
> ]
> ]
> ]
Speaking of gibberish. I can't believe anybody would hold up
Mathematica as an example of good programming. Next you'll be telling
me that 99% of Matlab code isn't really crap!
> The third issue, about how nested syntax seriously discourages
> frequent or advanced use of inline function sequencing on the fly, is
> the most important and I'll give further explanation below.
I consider this to be a Good Thing (TM). Unix shell commands read like
line noise.
Rayiner Hashem <·······@gmail.com> writes:
>> (1) Some 99% of programers are not used to the nested parenthesis
>> syntax. This is a practical problem. On this aspect along, lisp's
>> syntax can be considered a problem.
>
> The first time I saw graph-theory notation, I thought it was
> gibberish. I still think most mathematical notation is gibberish, but
> I deal with it --- I don't turn in proofs written in prose.
Right.
>
>> (2) Arguably, the pure nested syntax is not natural for human to read.
And BTW, it's not natural for humans to read at all.
:-)
>> Long time lispers may disagree on this point.
>
> And mathematical notation is not natural for people to read, at least
> not anybody who grew up learning a natural language. But people deal
> with it. They're remarkably adaptable this way.
Regards -- Markus
From: Edward
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m2odkzj4ln.fsf@gmail.com>
Xah Lee <···@xahlee.org> writes:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of “inferior” text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
As a practical matter, most LISPers don't even see the parens, but
rather interpret the code according to the indentation.
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
It's certainly different. Whether it is a problem or not depends on
personal or subjective criteria.
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
Harder to read for some things, easier to read for others.
E.G.
1 + 2 + 3 + 4 + 6 - 3 + 32
or
(- (+ 1 2 3 4 6 32) 3)
> (3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions. This aspect is
> the most devastating.
This is one reason LISP has macros. Don't like the syntax? Make your
own. How many languages make this as easy as LISP does?
> The third issue, about how nested syntax seriously discourages
> frequent or advanced use of inline function sequencing on the fly,
> is the most important and I'll give further explanation below.
>
> One practical way to see how this is so, is by considering unix's
> shell syntax. You all know, how convenient and powerful is the
> unix's pipes. Here are some practical example: “ls -al | grep xyz”,
> or “cat a b c | grep xyz | sort | uniq”.
>
> Now suppose, we get rid of the unix's pipe notation, instead,
> replace it with a pure functional notation: e.g. (uniq (sort (grep
> xyz (cat a b c)))), or enrich it with a composition function and a
> pure function construct (λ), so this example can be written as:
> ((compose (lambda (x) (grep xyz x)) sort uniq) (cat a b c)).
(pipe (cat a b c) (grep xyz) (sort) (uniq))
'Nuff said.
UNIX pipe `|' is not just a throw-away syntactic separator, anyone
with LISP experience would see it for what it is: a function that
operates on functions.
> Lisp, by sticking with almost uniform nested parenthesis notation,
> it immediately reduces the pattern of sequencing functions, simply
> because the syntax does not readily...<snip>
I would contend that LISP did not do this. You did.
<snip>
> (Note: Lisp's sexp is actually not that pure. It has ad hoc syntax
> equivalents such as the “quote” construct “ '(a b c) ”, and also
> “`”, “#”, “,@” constructs, precisely for the purpose of reducing
> parenthesis and increasing readability. Scheme's coming standard the
> R6RS ↗, even proposes the introduction of [] and {} and few other
> syntax sugars to break the uniformity of nested parenthesis for
> legibility. Mathematica's FullForm, is actually a pure nested
> notation as can be.)
Some functions are used so often, they have shorthand equivalents.
This is a feature in many languages. But if for some reason one
wanted the sexp to be "pure," nothing's stopping him from using the
fully-parenthesized versions.
> -------
> The above, is part of a 3-part exposition:
> “The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations”,
> “Prefix, Infix, Postfix notations in Mathematica”,
> “How Lisp's Nested Notation Limits The Language's Utility”,
> archived at:
> http://xahlee.org/UnixResource_dir/writ/notations.html
>
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
>
I suggest you start to acquaint yourself with LISP before getting too
far into the exposition:
http://gigamonkeys.com/book/
--
Edward
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <1qS_h.584$QO6.263@newsfe12.lga>
Xah Lee wrote:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of “inferior” text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
>
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
Simply wrong. What would be a problem would be if they tried it and
could not quickly get used to it.
>
> (2) Arguably, the pure nested syntax is not natural for human to read.
> Long time lispers may disagree on this point.
No code is natural to read, and yes, I have written a ton of COBOL.
Neither are legal or scholarly natural language texts natural to read.
>
> (3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions. This aspect is
> the most devastating.
The example you chose was a command line, where conciseness rules and
where one is not likely to encounter refactoring or macros. ie, the
syntax for a command-line has nothing to do with the syntax for serious
programming.
sexpr notation provides a hierarchical lexical grouping that maps
isomorphically onto the functional semantics, and the latter is what I
need to rearrange when refactoring, so it kinda helps that the code I
must edit to achieve said rearrangement maps so directly to the semantics.
I think the biggest argument in favor of parens is all the people that
want them to go away. Bad features just die out (see C++ and Java).
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Xah Lee wrote:
«(1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.»
Ken Tilton wrote:
«Simply wrong. What would be a problem would be if they tried it and
could not quickly get used to it.»
I think what you said is part of what i said. But let me elaborate.
Lisp's nested parenthesis certainly is a problem, if you want to
attract programers to lisp and programers are not attracted by sexp in
the first place.
What you expressed, is to consider the question of whether people can
get used to sexp. If programers cannot adapt sexp and find it
comfortable as a syntax of a programing language, then, you consider
THAT, to be a problem of the lisp syntax. Otherwise no problemo.
I think you vantage point is not so goody. But if we consider the
question itself, i think yes, people can adapt and use sexp reasonable
well for programing. Actually, this has been already done i guess by
lispers for 40+ years right? But if we really focus on this point of
view, namely: whether sexp can be suitable as a syntax for computing
language. Then, that is rather not a interesting question i thinky.
Because, in general, people can adapt to all kind of wierd shits,
really depending how pressing the matter is. If it is life
threatening, or they have no other choice, human animals can adapt.
Imagine, compare, the technology today are far advanced than 40 years
ago. Computers are what? a thousand, ten thousand times faster? And
there's no Perl, Python, Java, Internet 40 years ago. But People went
to the Moon! Imagine, what kind of torturous pain these people have
to go thru in software and hardware or the computation of mathematics
to do this. BASIC with GOTO and FORTRAN? What? no structured
constructs? No code blocks? No libraries? No symbols? No macros? Not
even Eval()? No USB and DVDs but punchcards?
You know about Chinese characters right? To a European, Chinese
characters looks torturous. But in fact it is. Just consider the
number of strokes. But i think Chinese people of 13 billion are
surviving.
Sure. I certainly agree human animals can get used to sexp. Under
some conditions, human animals can get used to a lot of things, and
loving it too.
See:
• “Body and Mind Modification”
http://xahlee.org/Periodic_dosage_dir/20031129_body_mod.html
• “Difficulty Perceptions in Human Feats”
http://xahlee.org/vofli_bolci/juggling.html
The interesting question would be, to what degree of botchedness of
computer language syntax can be, until programers will not be able to
adapt it and code it fruitfully? Suppose, for each paren in lisp, we
double it. So, “(+ 3 4)” will be written as “((+ 3 4))”. And suppose
we force this to be the new syntax for lisp. I will bet you one
hundred bucks, that all lispers will find in exactly as easy to read
as before.
How many level of parens do you think we can add till all lispers
abandon ship?
How many?
----------------------------
Xah Lee wrote:
«(2) Arguably, the pure nested syntax is not natural for human to
read. Long time lispers may disagree on this point.»
Kenny wrote:
«No code is natural to read, and yes, I have written a ton of COBOL.
Neither are legal or scholarly natural language texts natural to
read.»
Huh? surely you agree that there is at least some qualification as to
some written language being more natural or easier to read?
For example, compare language A and B, where A is just lisp's sexp,
and B is sexp with every paren replaced by double parens. Now, which
is more “natural” or easy to read?
So, likewise, compare Perl and Python. Which is easier to read in
general? You can't wax philosophy on this can you?
Imagine a philosophical scenario, where a devil killed off all
pythoners on earth. Therefore perl code is easier to read, because
nobody would understand a fuck when shown a python code. So, the
question of whether Perl or Python code is easier to read, depends.
Also, i mean, it depends on the programer!! Because, if i write Perl
code versus a moron writing in Python, then my Perl code will sure be
easier to read. So, it also depends on me.
What a great tough undecidability!
----------------------------
Xah Wrote:
«(3) Most importantly, a pure nested syntax discourages frequent or
advanced use of function sequencing or compositions. This aspect is
the most devastating.»
Kenny wrote:
«The example you chose was a command line, where conciseness rules and
where one is not likely to encounter refactoring or macros. ie, the
syntax for a command-line has nothing to do with the syntax for
serious programming.»
Yes the example i gave was unix's shell. It is chosen because it is
simple to illustrate and widely known.
I could give Mathematica examples with explanations... but its not
suitable as the simple unix pipe example because then i'll have to
spend great space explaining Mathematica.
(if anyone is interested in Mathematica syntax, i explained some here
http://xahlee.org/UnixResource_dir/writ/notations.html
)
But anyway, here's a few mathematica example from my Plane Tiling
package.
Here's one line that's the most simple to understand:
Reflect2DGraphics[{a1_, a2_}, {n1_, n2_}][gra_] :=
(Translate2DGraphics[{n1, n2}])@
(Reflect2DGraphics[{a1,a2}])@
(Translate2DGraphics[-{n1, n2}][gra]);
Basically, you'll see on the right side are 3 sequence of functions.
The left side is a function applied to a function. i.e.
Reflect2DGraphics takes 2 vectors and “returns” a function that takes
one graphics argument. (it doesn't actually return a function since
it's written as pattern matching... but you can think of it as a
function generator)
Here's the lispy form some lisper believe is easier to read:
CompoundExpression[
SetDelayed[
Reflect2DGraphics[List[Pattern[a1, Blank[]], Pattern[a2,
Blank[]]],
List[Pattern[n1, Blank[]], Pattern[n2, Blank[]]]][
Pattern[gra, Blank[]]],
Translate2DGraphics[List[n1, n2]][
Reflect2DGraphics[List[a1, a2]][
Translate2DGraphics[Times[-1, List[n1, n2]]][gra]]]], Null]
The following are more code. They involve pure functions, function
application, function mapping, function generator applied to
functions... and basically all done with flat sequencing of functions
when possible. (aka function chaining sans nesting). Whenever you see
the ampersand sign &, its a pure function (aka lambda). Some pure
function has pure function as its innards.
These are written in 1997, by yours truely. I would say, if you have
not been coding lisp or Mathematica for, say, 40 hours a week for 4
years, you wouldn't understand these code when explained. (not
considering the math it is doing)
Okie, here's a good one. Lots of sequencing of pure functions on the
fly:
cycledMatrix[{m_Integer, n_Integer}, cycleLists : {_List ..}] :=
Module[{}, (Flatten[({Table[#1, {Quotient[#2, #3]}],
Take[#1, Mod[#2, #3]]} &) @@ ({#, m,
······@#} &)@#] &) ·@
Flatten[(({(Flatten[#, 1] &)@Table[#1, {Quotient[#2, #3]}],
Take[#1, Mod[#2, #3]]} &) @@ ({#, n, ······@#} &)@
cycleLists), 1]];
Btw, the ··@@g” you see is shortcut syntax for “Apply[f,g]”.
Here's the equivalent lispy form, lispers think its easier to read:
CompoundExpression[
SetDelayed[
cycledMatrix[
List[Pattern[m, Blank[Integer]], Pattern[n, Blank[Integer]]],
Pattern[cycleLists, List[Repeated[Blank[List]]]]],
Module[List[],
Map[Function[
Flatten[Apply[
Function[
List[Table[Slot[1], List[Quotient[Slot[2],
Slot[3]]]],
Take[Slot[1], Mod[Slot[2], Slot[3]]]]],
Function[List[Slot[1], m, Length[Slot[1]]]]
[Slot[1]]]]],
Flatten[Apply[
Function[
List[Function[Flatten[Slot[1], 1]][
Table[Slot[1], List[Quotient[Slot[2],
Slot[3]]]]],
Take[Slot[1], Mod[Slot[2], Slot[3]]]]],
Function[List[Slot[1], n, Length[Slot[1]]]]
[cycleLists]], 1]]]],
Null]
----------------------------------------
Okie, another one, wee!
ColoredLatticeNetwork[n:(4 | 3), m_Integer,
colors:{_List..}, s_, a_, {x_, y_}] :=
Module[{lines, gp}, lines = (Map[Line, #1, {2}] & )[
(Partition[#1, 2, 1] & ) ·@
N[Table[{1, 0}*s*i + ({Cos[#1], Sin[#1]} & )[
(2*Pi)/n]*s*j, {j, -m, m}, {i, -m, m}]]];
gp = (Transpose[#1, {3, 1, 2}] & )[
{cycledMatrix[{m*2, m*2 + 1}, (RotateRight[#1, m] & )[
(RotateRight[#1, m] & ) ·@ colors]], lines}];
Translate2DGraphics[{x, y}][
Table[Rotate2DGraphics[{0, 0}, ((2*Pi)*i)/n + a][
gp], {i, 0, n - 1}]]];
Here's the equivalent lispy form lisp morons insist it is easier to
read:
CompoundExpression[
SetDelayed[
ColoredLatticeNetwork[Pattern[n, Alternatives[4, 3]],
Pattern[m, Blank[Integer]],
Pattern[colors, List[Repeated[Blank[List]]]], Pattern[s,
Blank[]],
Pattern[a, Blank[]], List[Pattern[x, Blank[]], Pattern[y,
Blank[]]]],
Module[List[lines, gp],
CompoundExpression[
Set[lines,
Function[Map[Line, Slot[1], List[2]]][
Map[Function[Partition[Slot[1], 2, 1]],
N[Table[
Plus[Times[List[1, 0], s, i],
Times[Function[List[Cos[Slot[1]], Sin[Slot[1]]]]
[
Times[Times[2, Pi], Power[n, -1]]], s, j]],
List[j, Times[-1, m], m], List[i, Times[-1, m],
m]]]]]],
Set[gp, Function[Transpose[Slot[1], List[3, 1, 2]]][
List[cycledMatrix[List[Times[m, 2], Plus[Times[m, 2],
1]],
Function[RotateRight[Slot[1], m]][
Map[Function[RotateRight[Slot[1], m]], colors]]],
lines]]],
Translate2DGraphics[List[x, y]][
Table[Rotate2DGraphics[List[0, 0],
Plus[Times[Times[Times[2, Pi], i], Power[n, -1]], a]]
[gp],
List[i, 0, Plus[n, -1]]]]]]], Null]
--------------------------------
Okie, this one is a simple one.
StarMotif[n_Integer, coords_?MatrixQ, s_, α_, {x_, y_}] :=
·······@(Flatten[#, 1] &)@
·········@
Map[Table[{Cos[t + ····@#], Sin[t + ····@#]}*First[#]*s +
{x,
y}, {t, α, 2*Pi + α - 2*Pi/n/2, 2*Pi/n}] &,
coords];
Now, the easier-to-read lisp form follows:
CompoundExpression[
SetDelayed[
StarMotif[Pattern[n, Blank[Integer]],
PatternTest[Pattern[coords, Blank[]], MatrixQ], Pattern[s,
Blank[]],
Pattern[α, Blank[]],
List[Pattern[x, Blank[]], Pattern[y, Blank[]]]],
Polygon[Function[Flatten[Slot[1], 1]][
Transpose[
Map[Function[
Table[Plus[
Times[List[Cos[Plus[t, Last[Slot[1]]]],
Sin[Plus[t, Last[Slot[1]]]]], First[Slot[1]],
s],
List[x, y]],
List[t, α,
Plus[Times[2, Pi], α,
Times[-1,
Times[2,
Times[Times[Pi, Power[n, -1]], Power[2,
-1]]]]],
Times[2, Times[Pi, Power[n, -1]]]]]], coords]]]]],
Null]
--------------
This one is semantically and geometrically complex!
SlitLine[Line[pts_List /; (······@pts > 2)], cuttingLine : {{_, _},
{_, _}}] :=
Module[{temp},
If[SameQ @@ (temp = PointOnLeftSideQ[#, cuttingLine] & ·@ pts),
······@····@····@pts];
temp = MapThread[
And[#1, #2] &, {(UnsameQ @@ # &) ·@
Partition[temp, 2,
1], (PointOnLeftSideQ[·····@cuttingLine, #] =!=
PointOnLeftSideQ[····@cuttingLine, #] &) ·@
Partition[pts, 2, 1]}];
temp = Append[#, Null] &@
MapThread[
If[#2, ·@LineIntersectionPoint[#1, cuttingLine],
Null] &, {Partition[pts, 2, 1], temp}];
temp = (DeleteCases[#, Null, {1}] &)@Flatten[·········@{pts, temp},
1];
(Line ·@
ReplaceRepeated[
····@temp, {a__, 0[pt_], b__} :> Sequence[{a, pt}, {pt,
b}]])]
Now, the spectacular lisp form:
SetDelayed[
SlitLine[Line[
Condition[Pattern[pts, Blank[List]], Greater[Length[pts],
2]]],
Pattern[cuttingLine,
List[List[Blank[], Blank[]], List[Blank[], Blank[]]]]],
Module[List[temp],
CompoundExpression[
If[Apply[SameQ,
Set[temp,
Map[Function[PointOnLeftSideQ[Slot[1], cuttingLine]],
pts]]],
Return[List[Line[pts]]]],
Set[temp,
MapThread[Function[And[Slot[1], Slot[2]]],
List[Map[Function[Apply[UnsameQ, Slot[1]]],
Partition[temp, 2, 1]],
Map[Function[
UnsameQ[PointOnLeftSideQ[First[cuttingLine],
Slot[1]],
PointOnLeftSideQ[Last[cuttingLine], Slot[1]]]],
Partition[pts, 2, 1]]]]],
Set[temp,
Function[Append[Slot[1], Null]][
MapThread[
Function[
If[Slot[2], 0[LineIntersectionPoint[Slot[1],
cuttingLine]],
Null]], List[Partition[pts, 2, 1], temp]]]],
Set[temp,
Function[DeleteCases[Slot[1], Null, List[1]]][
Flatten[Transpose[List[pts, temp]], 1]]],
Map[Line,
ReplaceRepeated[List[temp],
RuleDelayed[
List[Pattern[a, BlankSequence[]], 0[Pattern[pt,
Blank[]]],
Pattern[b, BlankSequence[]]],
Sequence[List[a, pt], List[pt, b]]]]]]]]
If you want to see more, you can download my package at
http://xahlee.org/MathGraphicsGallery_dir/PlaneTilingPackageDemo_dir/planeTilingPackageDemo.html
Free of charge.
Xah
···@xahlee.org
∑ http://xahlee.org/
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <EM0%h.314$PS7.256@newsfe12.lga>
Xah Lee wrote:
> Xah Lee wrote:
> «(1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.»
>
> Ken Tilton wrote:
> «Simply wrong. What would be a problem would be if they tried it and
> could not quickly get used to it.»
>
> I think what you said is part of what i said. But let me elaborate.
>
> Lisp's nested parenthesis certainly is a problem, if you want to
> attract programers to lisp and programers are not attracted by sexp in
> the first place.
Ah, but now you are talking about marketing, and I happen to believe
that one does not win at marketing by throwing out one of the best
features of the language.
Do things well and people will find you. Why else has Lisp recovered
from the AI Winter? When has a computer language ever made a comeback?
Below you suggest I may be blinded by perspective. My question to you
is, do /you/ appreciate the importance of parens? If not, your
perspective is the problem.
>
> What you expressed, is to consider the question of whether people can
> get used to sexp. ...snip... Then, that is rather not a interesting question i thinky.
> Because, in general, people can adapt to all kind of wierd shits,
I understand how you went wrong, but you have read something into what I
wrote and are now off on a tangent by yourself, complete with
bibliography <g>. Nowhere did I say people would have to struggle to
appreciate parens, what I said was that it is not interesting if people
who have never tried Lisp complain about the parens. The only
interesting repsondent is one who has tried Lisp for some reason, and no
such person has ever had a problem with the parens. You are reacting to
word of mouth from people who have never tried Lisp, and that means
nothing. Give someone a microphone, they will say something.
But this is all Usenet hair-splitting. The bottom line is this: all
Lispers learned parens at some point, and know from experience that it
was easy for them, that it would be easy for anyone, and that parens are
an absolute advantage. If you disagree on any of those points we likely
will not find common ground.
[a bunch more on the mistaken idea that parens are an acquired taste]
> The interesting question would be, to what degree of botchedness of
> computer language syntax can be, until programers will not be able to
> adapt it and code it fruitfully? Suppose, for each paren in lisp, we
> double it. So, “(+ 3 4)” will be written as “((+ 3 4))”. And suppose
> we force this to be the new syntax for lisp. I will bet you one
> hundred bucks, that all lispers will find in exactly as easy to read
> as before.
You seem deeply convinced that parens /are/ a problem? Perhaps the story
here is that they /do/ confuse you. Anyway, the above is thoroughly
wrong. Lispers hate line noise, which is why they love parens and why
they use macros such as my BIF, which changes:
(let ((x (look-up y)))
(when x (print (list x 42))))
to:
(bwhen (x (look-up y))
(print (list x 42)))
Come to think of it, one reason I like loop is that it lets me express
iteration without so many parens. I guess I am making a tradeoff in
which I accept locally a burden to think about syntax in return for
being able to dash off commonly written code (which commonness means the
syntax will be second-nature). And a big point you have missed: I still
get decent auto indentation of my code even with the whacky loop syntax.
Note, btw, that your second set of parens adds nothing. The first
brilliantly captures lexically that the operator along with its operands
forms a meaningful semantic chunk....hang on.... eureka! So do the
arguments, so (+ 2 3) should really be (+ (2 3)). Ah, but then (+ 40 (-
4 2)) becomes (+ (40 (- (4 2)))... well, I guess Lispers /do/ worry
about readability. :)
Meanwhile, you owe me $100. Paul Graham, at ILC '2003 (? In NYC), said
one problem he wanted to fix with Arc was that Lisp had too many
parnetheses. He picked on COND as an example.
>
> How many level of parens do you think we can add till all lispers
> abandon ship?
>
> How many?
>
> ----------------------------
> Xah Lee wrote:
> «(2) Arguably, the pure nested syntax is not natural for human to
> read. Long time lispers may disagree on this point.»
>
> Kenny wrote:
> «No code is natural to read, and yes, I have written a ton of COBOL.
> Neither are legal or scholarly natural language texts natural to
> read.»
>
> Huh? surely you agree that there is at least some qualification as to
> some written language being more natural or easier to read?
>
> For example, compare language A and B, where A is just lisp's sexp,
> and B is sexp with every paren replaced by double parens. Now, which
> is more “natural” or easy to read?
>
> So, likewise, compare Perl and Python. Which is easier to read in
> general? You can't wax philosophy on this can you?
>
> Imagine a philosophical scenario, where a devil killed off all
> pythoners on earth. Therefore perl code is easier to read, because
> nobody would understand a fuck when shown a python code. So, the
> question of whether Perl or Python code is easier to read, depends.
>
> Also, i mean, it depends on the programer!! Because, if i write Perl
> code versus a moron writing in Python, then my Perl code will sure be
> easier to read. So, it also depends on me.
>
> What a great tough undecidability!
But only because you think the only thing that makes a computer language
readable is experience with it. And you are stuck on the idea of
readability being important, another big mistake. We /write/ code, we do
not read it. The important thing is to make the writing easy. The parens
make writing code code (guessing) twice as easy, certainly refactoring.
Another mistake: code ever being as readable as Stephen King. Nope, with
code one /always/ has to slow down to figure out what is going on.
I think you are also missing that the parens also mean there is a ton of
syntax and precedence I do not need to learn or make mistakes on. One
simple rule and I am good to go.
You need to remember, Xah, that any Lisper is master also of other
computer languages, because we likely pay the bills with something else.
You seem to have a mental model of us in which the only thing we know is
Lisp.
>
> ----------------------------
> Xah Wrote:
> «(3) Most importantly, a pure nested syntax discourages frequent or
> advanced use of function sequencing or compositions. This aspect is
> the most devastating.»
>
> Kenny wrote:
>
> «The example you chose was a command line, where conciseness rules and
> where one is not likely to encounter refactoring or macros. ie, the
> syntax for a command-line has nothing to do with the syntax for
> serious programming.»
>
> Yes the example i gave was unix's shell. It is chosen because it is
> simple to illustrate and widely known.
Well, the problem with examples is the problem with analogies: even if
we agree with the proffered case, what does that add to the discussion?
How well does it apply? What does it say? It just opens up a whole new
thread. The second set of parens is different from the first, a
command-line is not a 3gl with pages of text (and to head you off, if I
was writing a ten-line shell script, yes, I would want sexprs).
>
> I could give Mathematica examples with explanations... but its not
> suitable as the simple unix pipe example because then i'll have to
> spend great space explaining Mathematica.
>
> (if anyone is interested in Mathematica syntax, i explained some here
> http://xahlee.org/UnixResource_dir/writ/notations.html
> )
>
> But anyway, here's a few mathematica example from my Plane Tiling
> package.
>
> Here's one line that's the most simple to understand:
>
> Reflect2DGraphics[{a1_, a2_}, {n1_, n2_}][gra_] :=
> (Translate2DGraphics[{n1, n2}])@
> (Reflect2DGraphics[{a1,a2}])@
> (Translate2DGraphics[-{n1, n2}][gra]);
>
> Basically, you'll see on the right side are 3 sequence of functions.
> The left side is a function applied to a function. i.e.
> Reflect2DGraphics takes 2 vectors and “returns” a function that takes
> one graphics argument. (it doesn't actually return a function since
> it's written as pattern matching... but you can think of it as a
> function generator)
>
> Here's the lispy form some lisper believe is easier to read:
>
> CompoundExpression[
> SetDelayed[
> Reflect2DGraphics[List[Pattern[a1, Blank[]], Pattern[a2,
> Blank[]]],
> List[Pattern[n1, Blank[]], Pattern[n2, Blank[]]]][
> Pattern[gra, Blank[]]],
> Translate2DGraphics[List[n1, n2]][
> Reflect2DGraphics[List[a1, a2]][
> Translate2DGraphics[Times[-1, List[n1, n2]]][gra]]]], Null]
>
> The following are more code. They involve pure functions, function
> application, function mapping, function generator applied to
> functions... and basically all done with flat sequencing of functions
> when possible. (aka function chaining sans nesting). Whenever you see
> the ampersand sign &, its a pure function (aka lambda). Some pure
> function has pure function as its innards.
>
> These are written in 1997, by yours truely. I would say, if you have
> not been coding lisp or Mathematica for, say, 40 hours a week for 4
> years, you wouldn't understand these code when explained. (not
> considering the math it is doing)
>
> Okie, here's a good one. Lots of sequencing of pure functions on the
> fly:
>
> cycledMatrix[{m_Integer, n_Integer}, cycleLists : {_List ..}] :=
> Module[{}, (Flatten[({Table[#1, {Quotient[#2, #3]}],
> Take[#1, Mod[#2, #3]]} &) @@ ({#, m,
> ······@#} &)@#] &) ·@
> Flatten[(({(Flatten[#, 1] &)@Table[#1, {Quotient[#2, #3]}],
> Take[#1, Mod[#2, #3]]} &) @@ ({#, n, ······@#} &)@
> cycleLists), 1]];
>
> Btw, the ··@@g” you see is shortcut syntax for “Apply[f,g]”.
>
> Here's the equivalent lispy form, lispers think its easier to read:
>
> CompoundExpression[
> SetDelayed[
> cycledMatrix[
> List[Pattern[m, Blank[Integer]], Pattern[n, Blank[Integer]]],
> Pattern[cycleLists, List[Repeated[Blank[List]]]]],
> Module[List[],
How on Earth is that Lispy??! Bring the operator inside, then lose the
[]s and commas. Puzzled.
kenny
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton <···@theoryyalgebra.com> wrote:
[...]
>
> But only because you think the only thing that makes a computer language
> readable is experience with it. And you are stuck on the idea of
> readability being important, another big mistake. We /write/ code, we do
> not read it. The important thing is to make the writing easy. The parens
> make writing code code (guessing) twice as easy, certainly refactoring.
We write /and/ read code. Sometimes, especially on large multi-team
projects, some of us spend more time reading it than writing it. One of
the things I have to keep pounding into the heads of our programmers is
that you aren't writing code for yourself and you certainly aren't
writing it for the computer -- you're writing it for other programmers.
That's why it's so important to remember rules such as:
1) "Write clearly -- don't be too clever"
2) "Say what you mean, simply and directly"
3) "Parenthesize to avoid ambiguity"
4) "Use the telephone test for readibility"
And so on, from "The Elements of Programming Style" by Kernighan and
Plaugher. [1]
We have engineers who, I kid you not, have used 9 lines of C code where
1 would do. Think that double and triple negatives are a reasonable way
of writing conditionals. Think that liberal use of temporary variables
is an excellent way of expressing onself. And so on.
This, of course, is true of all programming languages, not just Lisp.
So, while experience in the language contributes to readibility, it's
just (if not more important) that the code is written well. Joyce
certainly was experienced in English but I still find "Ulysses" a
dreadful chore.
-----
[1] I'd gladly buy a version of this book targeted to Lisp.
>
> Another mistake: code ever being as readable as Stephen King. Nope, with
> code one /always/ has to slow down to figure out what is going on.
>
> I think you are also missing that the parens also mean there is a ton of
> syntax and precedence I do not need to learn or make mistakes on. One
> simple rule and I am good to go.
>
> You need to remember, Xah, that any Lisper is master also of other
> computer languages, because we likely pay the bills with something else.
> You seem to have a mental model of us in which the only thing we know is
> Lisp.
>
Lee is suffering from the notion that there is a "natural" way of
expressing onself; the "natural" way, of course, being what he's used
to. The only "natual" language is the one spoken by God and I have the
feeling that He's an omniglot. Lisp, with its parenthesis, is no more
unnatural than Greek. And I like Greek. I can say things in it that I
can't say in English. Lee might as well complain that Greek uses an
"unnatural" alphabet, "funny" punctuation (like two kinds of "breathing
marks"), and an incredibly complex system of verb stems.
Lisp is the most elegant computer language I know, because it allows me
to express thoughts that are difficult to express in other languages.
Part of the reason for this is its syntax, just like one of the reasons
I can say things in Greek that I can't say in English are the different
verb tenses.
I also like Lisp because I can express more with less. Our company
decided to try PSP (Personal Software Process) using two teams as guinea
pigs. Lots of fanfare, classes, etc... Of course it turned out to be,
as Scott Adams might say, "a dead woodchuck". But as part of their
training, engineers had to code a set of eight exercises and collect
various metrics about the code. I think everyone used C; I certainly
did because I wanted to compare my time/size/defect metrics with the
other engineers. In order to improve my Lisp-fu, I later re-did the
exercises in Lisp. I was blown away by how much faster I could work.
The first exercise, for example, took 189 lines of C code but 51 lines
of Lisp. And the Lisp code did more; it had a built in test suite that
the C code did not.
Criticising a language based upon one small point of punctuation shows
that the critic doesn't know anything about languages. Best not to pay
any attention to them.
> >
> > ----------------------------
> > Xah Wrote:
> > �(3) Most importantly, a pure nested syntax discourages frequent or
> > advanced use of function sequencing or compositions. This aspect is
> > the most devastating.�
> >
> > Kenny wrote:
> >
> > �The example you chose was a command line, where conciseness rules and
> > where one is not likely to encounter refactoring or macros. ie, the
> > syntax for a command-line has nothing to do with the syntax for
> > serious programming.�
> >
> > Yes the example i gave was unix's shell. It is chosen because it is
> > simple to illustrate and widely known.
>
> Well, the problem with examples is the problem with analogies: even if
> we agree with the proffered case, what does that add to the discussion?
> How well does it apply? What does it say? It just opens up a whole new
> thread. The second set of parens is different from the first, a
> command-line is not a 3gl with pages of text (and to head you off, if I
> was writing a ten-line shell script, yes, I would want sexprs).
>
> >
> > I could give Mathematica examples with explanations... but its not
> > suitable as the simple unix pipe example because then i'll have to
> > spend great space explaining Mathematica.
> >
[...]
So what? Given _any_ language, human or machine, one can find an
example that is easily expressible in one but not in another. That's
one reason why we keep inventing languages. This will never stop unless
we can no longer find new things to express.
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <sp4%h.402$PS7.131@newsfe12.lga>
Bob Felts wrote:
> Ken Tilton <···@theoryyalgebra.com> wrote:
>
> [...]
>
>
>>But only because you think the only thing that makes a computer language
>>readable is experience with it. And you are stuck on the idea of
>>readability being important, another big mistake. We /write/ code, we do
>>not read it. The important thing is to make the writing easy. The parens
>>make writing code code (guessing) twice as easy, certainly refactoring.
>
>
> We write /and/ read code. Sometimes, especially on large multi-team
> projects, some of us spend more time reading it than writing it. One of
> the things I have to keep pounding into the heads of our programmers is
> that you aren't writing code for yourself and you certainly aren't
> writing it for the computer -- you're writing it for other programmers.
> That's why it's so important to remember rules such as:
>
> 1) "Write clearly -- don't be too clever"
> 2) "Say what you mean, simply and directly"
> 3) "Parenthesize to avoid ambiguity"
> 4) "Use the telephone test for readibility"
>
> And so on, from "The Elements of Programming Style" by Kernighan and
> Plaugher. [1]
>
> We have engineers who, I kid you not, have used 9 lines of C code where
> 1 would do. Think that double and triple negatives are a reasonable way
> of writing conditionals. Think that liberal use of temporary variables
> is an excellent way of expressing onself. And so on.
>
> This, of course, is true of all programming languages, not just Lisp.
There ya go. Natural language is wonderfully ambiguous. We can lump a
lot of things into readability, including typeface and justification. In
this thread we of course must narrow it down to things language
specific. You have failed, and Mr. Bradshaw will be around later to pick
you up.
> Criticising a language based upon one small point of punctuation shows
> that the critic doesn't know anything about languages. Best not to pay
> any attention to them.
We need something to drown out the incessant threads about getting free
software to work.
:)
kxo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On 5 May, 19:29, ····@stablecross.com (Bob Felts) wrote:
[...]
> 1) "Write clearly -- don't be too clever"
> 2) "Say what you mean, simply and directly"
> 3) "Parenthesize to avoid ambiguity"
> 4) "Use the tel
> And so on, from "The Elements of Programming Style" by Kernighan and
> Plaugher. [1]
>
[...]
> -----
> [1] I'd gladly buy a version of this book targeted to Lisp.
>
Have you read Norvig & Pitman's guide?
http://www.cc.gatech.edu/computing/classes/cs2360/ghall/style/Good-Lisp-Style.ps
jim burton <··········@gmail.com> wrote:
> On 5 May, 19:29, ····@stablecross.com (Bob Felts) wrote:
> [...]
> > 1) "Write clearly -- don't be too clever"
> > 2) "Say what you mean, simply and directly"
> > 3) "Parenthesize to avoid ambiguity"
> > 4) "Use the tel
> > And so on, from "The Elements of Programming Style" by Kernighan and
> > Plaugher. [1]
> >
> [...]
> > -----
> > [1] I'd gladly buy a version of this book targeted to Lisp.
> >
> Have you read Norvig & Pitman's guide?
>
http://www.cc.gatech.edu/computing/classes/cs2360/ghall/style/Good-Lisp-
Style.ps
Yes, I have. Thanks.
Ken Tilton wrote:
> Do things well and people will find you. Why else has Lisp recovered
> from the AI Winter?
Lisp didn't recover from the "AI Winter", it remains very unpopular.
> Below you suggest I may be blinded by perspective. My question to you
> is, do /you/ appreciate the importance of parens? If not, your
> perspective is the problem.
Most people disagree.
>> Here's the equivalent lispy form, lispers think its easier to read:
>>
>> CompoundExpression[
>> SetDelayed[
>> cycledMatrix[
>> List[Pattern[m, Blank[Integer]], Pattern[n, Blank[Integer]]],
>> Pattern[cycleLists, List[Repeated[Blank[List]]]]],
>> Module[List[],
>
> How on Earth is that Lispy??! Bring the operator inside, then lose the
> []s and commas. Puzzled.
It is "lispy" because it is prefix notation. Mathematica is probably the
best example to these claims that parens are important because it provides
all of the symbolic rewriting (macro) capabilities of Lisp with the brevity
of a decent programming language. Contrary to the claims of Lispers,
Mathematica clearly demonstrates that you can combine macros with syntax.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <lZ8%h.460$PS7.134@newsfe12.lga>
Jon Harrop wrote:
> Ken Tilton wrote:
>
>>Do things well and people will find you. Why else has Lisp recovered
>>from the AI Winter?
>
>
> Lisp didn't recover from the "AI Winter", it remains very unpopular.
Microsoft just announced support for dynamic languages.* What part of
the second derivative do you not understand?
kzo
* And they are running scared. In listing the languages they hoped to
support with DLR, they did not mention Lisp. Someone should tell them:
you can run, but you cannot hide. k
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton wrote:
> Jon Harrop wrote:
>> Lisp didn't recover from the "AI Winter", it remains very unpopular.
> What part of the second derivative do you not understand?
Plus the first derivative isn't doing too badly these days either:
* Lisp, along with Haskell, has been getting plenty of attention
from Reddit, which seems to be gaining ground on Digg and Slashdot
in the geek world. Much to my disappointment, OCaml hasn't been
getting as much attention recently.
* c.l.l is obviously very active.
* Lisp, again like Haskell, has an active IRC channel.
* There are regular job postings on lispjobs.wordpress.com.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Ken Tilton wrote:
>> Jon Harrop wrote:
>>> Lisp didn't recover from the "AI Winter", it remains very unpopular.
>> What part of the second derivative do you not understand?
>
> Plus the first derivative isn't doing too badly these days either:
> * Lisp, along with Haskell, has been getting plenty of attention
> from Reddit, which seems to be gaining ground on Digg and Slashdot
> in the geek world.
I've noticed Haskell growing very rapidly, the same as OCaml, but I haven't
heard of anything exciting that is Lisp related, except maybe Qi.
> Much to my disappointment, OCaml hasn't been
> getting as much attention recently.
Our OCaml-related sales have quadrupled over the past year. Then there's F#.
I think F# will overtake most other FPLs in the next year. It just overtook
Common Lisp according to Google trends:
http://www.google.com/trends?q=common+lisp,+ocaml
+f%23&date=all&geo=all&ctab=0&sa=N
There is certainly work to be done if any FPL is to catch up with the likes
of Mathematica:
http://www.google.com/trends?q=mathematica%2C+haskell%2C+ocaml&ctab=0&geo=all&date=all
Their latest release will give them a well-earned boost in the rankings.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Ken Tilton <···@theoryyalgebra.com> writes:
> Xah Lee wrote:
>> Xah Lee wrote:
>
,snip]
> Below you suggest I may be blinded by perspective. My question to you is, do
> /you/ appreciate the importance of parens? If not, your perspective is the
> problem.
>
Ah, the resounding sound of a nail being firmly hit on the head!
[snip]
>
> I think you are also missing that the parens also mean there is a ton of syntax
> and precedence I do not need to learn or make mistakes on. One simple rule and
> I am good to go.
>
> You need to remember, Xah, that any Lisper is master also of other computer
> languages, because we likely pay the bills with something else. You seem to
> have a mental model of us in which the only thing we know is Lisp.
>
I think this is an important point too often overlooked. Lisp was /the/ easiest
language I ever learnt because the syntax was trivial compared to other
languages. It is going to take me a long time to master the language, but I was
up and coding almost immediately and actually get the results I expected. Other
languages involved a lot more time and had a lot more surprises due to not
knowing/understanding all the operator precedence rules.
I grinned when reading Xah's post and his reference to lisp programmers having
to use indentation because the parens were so hard to read. What other high
level languages /don't/ use indentation to assist in expressing
meaning/structure?
anyone who has done C programming would be familiar with seeing fairly simple
expressions wrapped in aprens because the original author wasn't 100% confident
about operator precedence or pointer arithmetic which can require lots of
parens to get the desired affect (lets not even raise how readable some of that
can be).
Consider Perl and its 'or' versus '||', 'and' versus '&&'. How many times have
perl programmers discovered bugs because the author forgot that these operators
have different precedence and will behave differently in some contexts.
Then, when we move past this fairly trivial issue of parens, we begin to see
what we actually get from them. The straight-forward syntax that allows code to
be treated as data and the power that can bring. The ability to use macros to
make code more readable, reduce the code you type (and the associated parens),
the ability to create a domain specific language that still follows the same
syntax rules and is pretty much indistinguishable from the rest of the
language, etc.
bottom line - if someone can demonstrate an alternative syntax that doesn't
sacrifice the power we get with sexps, which is just as readable or easier and
can be written with the same or less keystrokes and doesn't create a syntax
full of exceptions and odd/inconsistent evaluation rules, then I'd be interested in
considering it. Given that the common easy target for non-lisp programmers has
been the parens and that this has gone on for years, yet it seems nobody has
come up with an alternative that doesn't sacrifice some aspect of the language,
I don't expect to see anything until we have some other paradigm shift with
respect to our basic interface to the computer. Until then, I'm happy with the
parens if it means I don't need to also have an operator precedence chart on
the wall and a <language X> pocket reference sitting on the desk.
tim
P.S. I'm also sick of all those languages with the () and {} and [] and ;
everywhere. I keep missing one or mismatching the () {} and [] or accidently
using : when it should have been ; because my fingers moved too quickly and I
still had the shift key down! Even more frustrating, I didn't realise I had done it
until the compiler barfed after the first 5 minutes of my long build cycle. Now
I've got to fix that silly error and start the build again and I've already had
20 cups of coffee today. I guess another cigarette while I wait for the build
to complete will fill the time. Still, its such a shame software takes so long
to develop.
--
tcross (at) rapttech dot com dot au
On 2007-05-05 08:30:56 +0100, Xah Lee <···@xahlee.org> said:
> Xah Lee wrote:
[...]
> programers are not attracted by sexp in the first place.
No sex-p ?
Why wonder then why so many women see us geeks as wussies ... :(
Xah Lee wrote:
> How Lisp's Nested Notation Limits The Language's Utility
I didn't read your thesis, but the general premise is correct.
Caution: late-night ramblings follow. Proceed with caution.
The solution is simple: do something in Lisp that is nearly impossible
in other languages.
Do something that is anathema to the programmer machismo.
Write an interactive, point-and-click interface that lets users edit
Lisp code as block diagrams, seamlessly transforming back and forth
between s-expressions and widgets.
In another project, write macros that convert Basic code into idiomatic
Lisp.
Provide the user with "UI/syntax macros" that can present code in any
number of forms.
With such frameworks in place, the truth will be exposed: All languages
are "preprocessed Lisp"; their only essential difference is the
preferred syntax and the libraries provided.
Definition: Turing-complete, n., an expression of Lisp.
(I should really get some sleep now.)
Seriously, though. The lisp environment is overwhelming to the new
user. Everything is foreign; they should offer a course in the history
department just so people can understand all the thoughts that resulted
in what we have today.
I "learned programming" by typing hex codes from magazines into a VIC20;
when these didn't work, I finally entered the BASIC checksum program to
help identify where things went wrong. This was foreign, but Commodore
basic provided a simple interface for the types of interactive
programming that Lisp excels at. I learned "for loops" by bouncing *'s
across the screen... I can only imagine what it would happen if I were
at that age trying the same experiments today... construct a widget, add
a text panel, oops can't position text, try a blank panel, figure out
which command draws text... 2 years later?
What will future generations learn to program on? The abomination known
as Visual Basic? Perl, Python, and other "scripting languages"? Almost
certainly not Lisp. Dr.Scheme (or whatever had the simple built-in
Windows IDE) was my first introduction to Lisp, and I must say that
Commodore and GRA (? AtariST) basic were much easier to grasp -- largely
due to the linguistic nature of their commands.
Lisp has a full suite of macros for morphing code; but the main efforts
to fix the syntax always seem to result in new compilers being written
(Dylan anyone?). Why can't we have syntax macros?
We need something that new coders can grasp easily. If it runs on a
thin layer over Lisp, then they will learn to see through the facade --
and hopefully avoid the brain damage encoded in restrictive programming
paradigms enforced by inferior language systems. Plus code written in
the "simple" syntax will be translated by these syntax macros into
idiomatic Lisp code, thus providing an interactive lesson in Lisp.
Treat Lisp as the bytecode of a universal "virtual machine".
I've cobbled together a simple framework inspired by Terence Parr's
Antlr and StringTemplate libraries. These (Mr. Parr's libraries) are
excellent libraries that implement a fairly , ignoring their linguistic
implementation. Something like this in Lisp should be just the key to
providing a standardized syntax macro framework...
/end transmission
On May 4, 10:17 pm, D Herring <········@at.tentpost.dot.com> wrote:
> Definition: Turing-complete, n., an expression of Lisp.
> (I should really get some sleep now.)
Why? The full name is Church-Turing thesis, of course... <wink-wink>
Paul B.
D Herring wrote:
> The solution is simple: do something in Lisp that is nearly impossible
> in other languages.
Lisp no longer offers anything new and what it does offer it rather out of
date. So I don't think that is possible.
When I first looked at Lisp, I found that it had two features that set it
apart from the crowd: EVAL and macros. Run-time code generation is done
better in languages like MetaOCaml and F#. Macros are done better in
languages like Mathematica. Neither are particularly useful. EVAL can be
used in regexp engines (bundling with all decent languages) or compiler
writing (a tiny niche). Macros are only worthwhile when you're dealing with
a DSL with complex syntax, like mathematics, so another tiny niche.
My advice is always to point people at Scheme rather than Lisp because it is
a sanitary version of the same thing. There's basically no point in trying
to write real code in Lisp, other languages provide more and do it better.
Lisp is more like an ill-thoughout husk of a language, with painful funcall
problems and without things like bundled pattern matching. I'm amazed that
anyone is still using it but the main reason seems to be that students are
forced to use it precisely because it is a weird curiosity.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 5, 9:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Lisp no longer offers anything new and what it does offer it rather out of
> date. So I don't think that is possible.
> [...]
> My advice is always to point people at Scheme rather than Lisp because it is
> a sanitary version of the same thing. There's basically no point in trying
> to write real code in Lisp, other languages provide more and do it better.
> Lisp is more like an ill-thoughout husk of a language, with painful funcall
> problems and without things like bundled pattern matching. I'm amazed that
> anyone is still using it but the main reason seems to be that students are
> forced to use it precisely because it is a weird curiosity.
>
Remind me why you post here again? If you're hoping it's because
we'll dispatch the helicopters for you then you're out of luck: mine
have been all fully occupied spoiling ballot papers and need
maintenance (bloody chinooks, really expensive to run). Tilton may
have some available.
On May 5, 10:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> D Herring wrote:
> > The solution is simple: do something in Lisp that is nearly impossible
> > in other languages.
>
> Lisp no longer offers anything new and what it does offer it rather out of
> date. So I don't think that is possible.
>
> When I first looked at Lisp, I found that it had two features that set it
> apart from the crowd: EVAL and macros. Run-time code generation is done
> better in languages like MetaOCaml and F#. Macros are done better in
> languages like Mathematica. Neither are particularly useful. EVAL can be
> used in regexp engines (bundling with all decent languages) or compiler
> writing (a tiny niche). Macros are only worthwhile when you're dealing with
> a DSL with complex syntax, like mathematics, so another tiny niche.
>
> My advice is always to point people at Scheme rather than Lisp because it is
> a sanitary version of the same thing. There's basically no point in trying
> to write real code in Lisp, other languages provide more and do it better.
> Lisp is more like an ill-thoughout husk of a language, with painful funcall
> problems and without things like bundled pattern matching. I'm amazed that
> anyone is still using it but the main reason seems to be that students are
> forced to use it precisely because it is a weird curiosity.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
The real question is how much is Microsoft paying you to write your
nonsense? I've just finished a product with your former savior to poor
programmers souls C# and i'm glad it's over. It was far easier to
write it first with Lisp and recode it in C# than streight coding
in C#, something we tried and get stuck. Oh we're probably too stupid
for such a brilliant technological marble like C#, so we're forced to
stick with Lisp. F# , No thanks. I don't need MS propaganda anymore ,
try some managers ,they might be interested in your latest buzzword.
On May 5, 4:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> D Herring wrote:
> > The solution is simple: do something in Lisp that is nearly impossible
> > in other languages.
>
> Lisp no longer offers anything new and what it does offer it rather out of> date. So I don't think that is possible.
>
> When I first looked at Lisp, I found that it had two features that set it
> apart from the crowd: EVAL and macros. Run-time code generation is done
> better in languages like MetaOCaml and F#. Macros are done better in
> languages like Mathematica. Neither are particularly useful. EVAL can be
> used in regexp engines (bundling with all decent languages) or compiler
> writing (a tiny niche). Macros are only worthwhile when you're dealing with
> a DSL with complex syntax, like mathematics, so another tiny niche.
>
> My advice is always to point people at Scheme rather than Lisp because it is
> a sanitary version of the same thing. There's basically no point in trying
> to write real code in Lisp, other languages provide more and do it better.
> Lisp is more like an ill-thoughout husk of a language, with painful funcall
> problems and without things like bundled pattern matching. I'm amazed that
> anyone is still using it but the main reason seems to be that students are
> forced to use it precisely because it is a weird curiosity.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Scheme's continuation support has much to recommend it, say for web
programming. But sanitizing a language can lead to inefficiencies.
Hackers
like flexible typing; defining a type theory hackers would
enthusiastically embrace
seems to be elusive.
Here is a somewhat tongue-in-cheek classification: I call a
programming language that implements Boolean operations on integer
types Knuthian. Common Lisp and C are Knuthian; Scheme is not.
For example, in C, to kill off the least significant bit of the
positive integer n, one can write
n &= n-1;
In Common Lisp, one can write
(LOGAND n (- n 1))
(this is not the only way). In Scheme there is no operator
corresponding to LOGAND, so to compute the MSB function below in
Scheme, we need to divide repeatedly.
(define (MSB0 n i)
(cond ((zero? n) 0)
((= n 1) i))
(else (MSB0 (quotient n 2) (+ i i)))))
(define (MSB n) (MSB0 n 1)
Scheme seems to encourage programming according to a pedagogical
aesthetic, enforced by expresive constraints.
However, the penalty for disallowing logical operations on integer
types can be significant. Consider the grey permutation g:N-->N of
the natural numbers, defined by Knuth in The Art of Computer
Programming, Volume 4 Fascicle 2, Generating All Tuples and
Permutations (2005). Knuth defines g recursively by
g(0) = 0; and,
g(k) = 2^n + g(2^n -1 - r) for k = 2^n + r with 0≤r<2^n .
Knuth points out that a consequence of the relation
a_j = b_j(+)b_j+1 (where a_j is the j-th binary bit of g(k), and b_j
is the j-th bit of k)
is that the permutation g has a simple description in terms of
exclusive or and integer division:
g(k) = k (+) [k/2]. [Writing (+) for exclusive or.]
A LISP function for this is
(DEFUN GREY (N) (LOGXOR N (FLOOR N 2)))
What would this look like in F#?
This is clearly better than the recursions of Scheme, not to mention
previously mentioned functions in common lisp
(DEFUN MSB (n)
(LET (( x (LOGAND (- n 1 ) n)))
(COND
((EQUAL x 0) n)
(T (MSB x)))))
(DEFUN GREY (n)
(COND (EQUAL (n 0) 0)
(T (LET (( x (MSB n)))
(+ x (GREY (- (- x 1) (- n x))))))))
As for Mathematica, I have to check which of Richard Fateman's
criicisms of the Mathematica programming language from an old review
( http://www.cs.berkeley.edu/~fateman/papers/mma.review.pdf )
are still valid for my copy of Mathematica 6.
It's too bad that mathematics is considered a tiny niche: one is
still often
reduced to pseudo-Latex and ASCII-isms to express mathematics on he
web
FL
·······@gmail.com wrote:
> (DEFUN GREY (N) (LOGXOR N (FLOOR N 2)))
>
> What would this look like in F#?
let grey n = n ^^^ n/2
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 10:33 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ·······@gmail.com wrote:
> > (DEFUN GREY (N) (LOGXOR N (FLOOR N 2)))
>
> > What would this look like in F#?
>
> let grey n = n ^^^ n/2
>
>Dr Jon D Harrop, Flying Frog Consultancy
[shameless advertisement removed]
And don't forgeth that F# is windows only ? (Yes I've heard about
mono)
On May 10, 4:33 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ·······@gmail.com wrote:
> > (DEFUN GREY (N) (LOGXOR N (FLOOR N 2)))
>
> > What would this look like in F#?
>
> let grey n = n ^^^ n/2
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Thanks for this. I looked further and found http://srfi.schemers.org/srfi-60/
the Integers as Bits SRFI, which will do what I want.
Xah Lee wrote:
> vectorAngle[{a1_, a2_}] := Module[{x, y},
> {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> If[x == 0, If[····@y === 1, ?/2, -?/2],
> If[y == 0, If[····@x === 1, 0, ?],
> If[····@y === 1, ······@x, 2 ? - ······@x]
> ]
> ]
> ]
>
> SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> Module[List[x,y],
> CompoundExpression[
> Set[List[x,y],
> N[Times[List[a1,a2],
> Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> If[Equal[x,0],
> If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
> Times[Times[-1,?],Power[2,-1]]],
> If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> If[SameQ[Sign[y],1],ArcCos[x],
> Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
Yes. The Mathematica language really brings home the fact that non-trivial
syntax is good. In particular, it does an excellent job of mimicking
conventional mathematical notation. Arguing in favor of Lisp syntax is like
advocating the use of cave painting...
Also, note that Mathematica provides strictly more in the way of macros.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 4, 8:37 pm, Jon Harrop <····@ffconsultancy.com> wrote:
[...]
> Yes. The Mathematica language really brings home the fact that non-trivial
> syntax is good. In particular, it does an excellent job of mimicking
> conventional mathematical notation.
If I wanted to exhibit the benefits of syntax, Mathematica would be
pretty low on my list of languages to do it with. The combination of C-
ish abreviations (i++, et c.), tricky rules for implicit
multiplication, and a maze of twisty little infix operators make it
very confusing. It's not Perl, but I'd still pick Lisp's syntax any
day of the week and twice on Sundays.
Cheers,
Pillsy
In article <························@o5g2000hsb.googlegroups.com>,
fireblade <·················@gmail.com> wrote:
> On May 5, 2:37 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > Xah Lee wrote:
> > > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > > If[x == 0, If[····@y === 1, ?/2, -?/2],
> > > If[y == 0, If[····@x === 1, 0, ?],
> > > If[····@y === 1, ······@x, 2 ? - ······@x]
> > > ]
> > > ]
> > > ]
> >
> > > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > > Module[List[x,y],
> > > CompoundExpression[
> > > Set[List[x,y],
> > > N[Times[List[a1,a2],
> > > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > > If[Equal[x,0],
> > > If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
> > > Times[Times[-1,?],Power[2,-1]]],
> > > If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> > > If[SameQ[Sign[y],1],ArcCos[x],
> > > Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
> >
> > Yes. The Mathematica language really brings home the fact that non-trivial
> > syntax is good. In particular, it does an excellent job of mimicking
> > conventional mathematical notation. Arguing in favor of Lisp syntax is like
> > advocating the use of cave painting...
> >
> > Also, note that Mathematica provides strictly more in the way of macros.
> >
> > --
> > Dr Jon D Harrop, Flying Frog Consultancy
> > The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet- Hide quoted text -
> >
> > - Show quoted text -
>
> ___________________________
> /| /| | |
> ||__|| | Please don't |
> / O O\__ feed |
> / \ the trolls |
> / \ \ |
> / _ \ \ ----------------------
> / |\____\ \ ||
> / | | | |\____/ ||
> / \|_|_|/ | __||
> / / \ |____| ||
> / | | /| | --|
> | | |// |____ --|
> * _ | |_|_|_| | \-/
> *-- _--\ _ \ // |
> / _ \\ _ // | /
> * / \_ /- | - | |
> * ___ c_c_c_C/ \C_c_c_c____________
>
>
> Sorry for double posting but I'm getting sick of Xah Lee and Jon
> Harrop.
> We all get their message :COMMON LISP SUCKS so please let us leave in
> our misery
> while you make all the great programms in F#, Mathematica or
> whatever ...
> >From now on I'll ignore both of them for good .
>
> cheers
> bobi
I fully agree. Neither of them as any (!) clue about Lisp and programming in Lisp.
Neither of them has written any significant or even non-significant Lisp program.
Their postings are full of (wrong) assumptions and are mostly based on
no experience and no knowledge of Lisp programming. Both are only trolling
in comp.lang.lisp. Best to post a warning sign and other to ignore them...
--
http://lispm.dyndns.org
On May 5, 10:26 am, Rainer Joswig <······@lisp.de> wrote:
> In article <························@o5g2000hsb.googlegroups.com>,
>
>
>
>
>
> fireblade <·················@gmail.com> wrote:
> > On May 5, 2:37 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > > Xah Lee wrote:
> > > > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > > > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > > > If[x == 0, If[····@y === 1, ?/2, -?/2],
> > > > If[y == 0, If[····@x === 1, 0, ?],
> > > > If[····@y === 1, ······@x, 2 ? - ······@x]
> > > > ]
> > > > ]
> > > > ]
>
> > > > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > > > Module[List[x,y],
> > > > CompoundExpression[
> > > > Set[List[x,y],
> > > > N[Times[List[a1,a2],
> > > > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > > > If[Equal[x,0],
> > > > If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
> > > > Times[Times[-1,?],Power[2,-1]]],
> > > > If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> > > > If[SameQ[Sign[y],1],ArcCos[x],
> > > > Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
>
> > > Yes. The Mathematica language really brings home the fact that non-trivial
> > > syntax is good. In particular, it does an excellent job of mimicking
> > > conventional mathematical notation. Arguing in favor of Lisp syntax is like
> > > advocating the use of cave painting...
>
> > > Also, note that Mathematica provides strictly more in the way of macros.
>
> > > --
> > > Dr Jon D Harrop, Flying Frog Consultancy
> > > The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet-Hide quoted text -
>
> > > - Show quoted text -
>
> > ___________________________
> > /| /| | |
> > ||__|| | Please don't |
> > / O O\__ feed |
> > / \ the trolls |
> > / \ \ |
> > / _ \ \ ----------------------
> > / |\____\ \ ||
> > / | | | |\____/ ||
> > / \|_|_|/ | __||
> > / / \ |____| ||
> > / | | /| | --|
> > | | |// |____ --|
> > * _ | |_|_|_| | \-/
> > *-- _--\ _ \ // |
> > / _ \\ _ // | /
> > * / \_ /- | - | |
> > * ___ c_c_c_C/ \C_c_c_c____________
>
> > Sorry for double posting but I'm getting sick of Xah Lee and Jon
> > Harrop.
> > We all get their message :COMMON LISP SUCKS so please let us leave in
> > our misery
> > while you make all the great programms in F#, Mathematica or
> > whatever ...
> > >From now on I'll ignore both of them for good .
>
> > cheers
> > bobi
>
> I fully agree. Neither of them as any (!) clue about Lisp and programming in Lisp.
> Neither of them has written any significant or even non-significant Lisp program.
> Their postings are full of (wrong) assumptions and are mostly based on
> no experience and no knowledge of Lisp programming. Both are only trolling
> in comp.lang.lisp. Best to post a warning sign and other to ignore them...
>
> --http://lispm.dyndns.org- Hide quoted text -
>
> - Show quoted text -
Seems that I was wrong about Xah Lee. He's no troll, but a completely
new flame warrior. Something that could be better described as
crossing of Tireless Rebutter ,Issues & Furious Typer . I will report
him to Mike Reed ·····@hutman.net from http://redwing.hutman.net/~mreed/
. I just don't know how to name it.
http://redwing.hutman.net/%7Emreed/warriorshtm/tirelessrebutter.htm
http://redwing.hutman.net/%7Emreed/warriorshtm/issues.htm
http://redwing.hutman.net/%7Emreed/warriorshtm/furioustyper.htm
On May 7, 11:15 am, fireblade <·················@gmail.com> wrote:
> On May 5, 10:26 am, Rainer Joswig <······@lisp.de> wrote:
>
>
>
>
>
> > In article <························@o5g2000hsb.googlegroups.com>,
>
> > fireblade <·················@gmail.com> wrote:
> > > On May 5, 2:37 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > > > Xah Lee wrote:
> > > > > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > > > > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > > > > If[x == 0, If[····@y === 1, ?/2, -?/2],
> > > > > If[y == 0, If[····@x === 1, 0, ?],
> > > > > If[····@y === 1, ······@x, 2 ? - ······@x]
> > > > > ]
> > > > > ]
> > > > > ]
>
> > > > > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > > > > Module[List[x,y],
> > > > > CompoundExpression[
> > > > > Set[List[x,y],
> > > > > N[Times[List[a1,a2],
> > > > > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > > > > If[Equal[x,0],
> > > > > If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
> > > > > Times[Times[-1,?],Power[2,-1]]],
> > > > > If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> > > > > If[SameQ[Sign[y],1],ArcCos[x],
> > > > > Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
>
> > > > Yes. The Mathematica language really brings home the fact that non-trivial
> > > > syntax is good. In particular, it does an excellent job of mimicking
> > > > conventional mathematical notation. Arguing in favor of Lisp syntax is like
> > > > advocating the use of cave painting...
>
> > > > Also, note that Mathematica provides strictly more in the way of macros.
>
> > > > --
> > > > Dr Jon D Harrop, Flying Frog Consultancy
> > > > The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet-Hidequoted text -
>
> > > > - Show quoted text -
>
> > > ___________________________
> > > /| /| | |
> > > ||__|| | Please don't |
> > > / O O\__ feed |
> > > / \ the trolls |
> > > / \ \ |
> > > / _ \ \ ----------------------
> > > / |\____\ \ ||
> > > / | | | |\____/ ||
> > > / \|_|_|/ | __||
> > > / / \ |____| ||
> > > / | | /| | --|
> > > | | |// |____ --|
> > > * _ | |_|_|_| | \-/
> > > *-- _--\ _ \ // |
> > > / _ \\ _ // | /
> > > * / \_ /- | - | |
> > > * ___ c_c_c_C/ \C_c_c_c____________
>
> > > Sorry for double posting but I'm getting sick of Xah Lee and Jon
> > > Harrop.
> > > We all get their message :COMMON LISP SUCKS so please let us leave in
> > > our misery
> > > while you make all the great programms in F#, Mathematica or
> > > whatever ...
> > > >From now on I'll ignore both of them for good .
>
> > > cheers
> > > bobi
>
> > I fully agree. Neither of them as any (!) clue about Lisp and programming in Lisp.
> > Neither of them has written any significant or even non-significant Lisp program.
> > Their postings are full of (wrong) assumptions and are mostly based on
> > no experience and no knowledge of Lisp programming. Both are only trolling
> > in comp.lang.lisp. Best to post a warning sign and other to ignore them...
>
> > --http://lispm.dyndns.org-Hide quoted text -
>
> > - Show quoted text -
>
> Seems that I was wrong about Xah Lee. He's no troll, but a completely
> new flame warrior. Something that could be better described as
> crossing of Tireless Rebutter ,Issues & Furious Typer . I will report
> him to Mike Reed ····@hutman.net fromhttp://redwing.hutman.net/~mreed/
> . I just don't know how to name it.
>
> http://redwing.hutman.net/%7Emreed/warriorshtm/tirelessrebutter.htmhttp://redwing.hutman.net/%7Emreed/warriorshtm/issues.htmhttp://redwing.hutman.net/%7Emreed/warriorshtm/furioustyper.htm- Hide quoted text -
>
> - Show quoted text -
Ok after few thoughts I had a name read carefully and advise before
I send this to Mr Mike Reed.
Brainy a.k.a Lecturing Smurf
Brainy Smurf fancies himself as the all-around-brain of the village. .
In fact he could be considered as the class swot or know-all. Brainy
Smurf is an avid reader and keeps a lot of books in his house (mostly
his quotations). He is quite arrogant and often lectures smurfs who
don't behave. Loquacious, he often uses big words that he himself
either made up or doesn't know what they really mean. A lot of the
other smurfs dislike him, and when he enters into a long lecturing,
some frustrated smurf often angrily smashes him on the head with a big
wooden mallet. Frequently, in the cartoon, after his blathering or
posturing have gone too far, he is thrown a long distance (typically
by Hefty Smurf), and always lands square on his head, usually outside
of the village. He is the best friend to Clumsy Smurf.
On May 8, 1:38 pm, fireblade <·················@gmail.com> wrote:
> Ok after few thoughts I had a name read carefully and advise before
> I send this to Mr Mike Reed.
>
> Brainy a.k.a Lecturing Smurf
>
> Brainy Smurf fancies himself as the all-around-brain of the village.
Checked
> In fact he could be considered as the class swot or know-all.
Checked
>Brainy Smurf is an avid reader and keeps a lot of books in his house (mostly
> his quotations).
Checked (just look at his site)
>He is quite arrogant and often lectures smurfs who
> don't behave.
Checked( + calling them names)
> Loquacious, he often uses big words that he himself
> either made up or doesn't know what they really mean.
Checked (criticizing something he doesn't know a thing about)
>A lot of the other smurfs dislike him,
Checked (A lot of the other smurfs dislike him, the rest hate him )
> and when he enters into a long lecturing,
> some frustrated smurf often angrily smashes him on the head with a big
> wooden mallet. Frequently, in the cartoon, after his blathering or
> posturing have gone too far, he is thrown a long distance (typically
> by Hefty Smurf), and always lands square on his head, usually outside
> of the village.
Cyberspace protects him else.. Hm
>He is the best friend to Clumsy Smurf.
Rather annoying smurf ( Jon Harrop )
Send it.
JT
On May 8, 1:57 pm, ·············@gmail.com wrote:
> On May 8, 1:38 pm, fireblade <·················@gmail.com> wrote:
>
> > Ok after few thoughts I had a name read carefully and advise before
> > I send this to Mr Mike Reed.
>
> > Brainy a.k.a Lecturing Smurf
>
> > Brainy Smurf fancies himself as the all-around-brain of the village.
> Checked
> > In fact he could be considered as the class swot or know-all.
> Checked
> >Brainy Smurf is an avid reader and keeps a lot of books in his house (mostly
> > his quotations).
>
> Checked (just look at his site)>He is quite arrogant and often lectures smurfs who
> > don't behave.
>
> Checked( + calling them names)> Loquacious, he often uses big words that he himself
> > either made up or doesn't know what they really mean.
>
> Checked (criticizing something he doesn't know a thing about)>A lot of the other smurfs dislike him,
>
> Checked (A lot of the other smurfs dislike him, the rest hate him )> and when he enters into a long lecturing,
> > some frustrated smurf often angrily smashes him on the head with a big
> > wooden mallet. Frequently, in the cartoon, after his blathering or
> > posturing have gone too far, he is thrown a long distance (typically
> > by Hefty Smurf), and always lands square on his head, usually outside
> > of the village.
>
> Cyberspace protects him else.. Hm>He is the best friend to Clumsy Smurf.
>
> Rather annoying smurf ( Jon Harrop )
Nausea perhaps ? It might be more descriptive....
On May 8, 1:38 pm, fireblade <·················@gmail.com> wrote:
> On May 7, 11:15 am, fireblade <·················@gmail.com> wrote:
>
>
>
>
>
> > On May 5, 10:26 am, Rainer Joswig <······@lisp.de> wrote:
>
> > > In article <························@o5g2000hsb.googlegroups.com>,
>
> > > fireblade <·················@gmail.com> wrote:
> > > > On May 5, 2:37 am, Jon Harrop <····@ffconsultancy.com> wrote:
> > > > > Xah Lee wrote:
> > > > > > vectorAngle[{a1_, a2_}] := Module[{x, y},
> > > > > > {x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
> > > > > > If[x == 0, If[····@y === 1, ?/2, -?/2],
> > > > > > If[y == 0, If[····@x === 1, 0, ?],
> > > > > > If[····@y === 1, ······@x, 2 ? - ······@x]
> > > > > > ]
> > > > > > ]
> > > > > > ]
>
> > > > > > SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
> > > > > > Module[List[x,y],
> > > > > > CompoundExpression[
> > > > > > Set[List[x,y],
> > > > > > N[Times[List[a1,a2],
> > > > > > Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
> > > > > > If[Equal[x,0],
> > > > > > If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
> > > > > > Times[Times[-1,?],Power[2,-1]]],
> > > > > > If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
> > > > > > If[SameQ[Sign[y],1],ArcCos[x],
> > > > > > Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
>
> > > > > Yes. The Mathematica language really brings home the fact that non-trivial
> > > > > syntax is good. In particular, it does an excellent job of mimicking
> > > > > conventional mathematical notation. Arguing in favor of Lisp syntax is like
> > > > > advocating the use of cave painting...
>
> > > > > Also, note that Mathematica provides strictly more in the way of macros.
>
> > > > > --
> > > > > Dr Jon D Harrop, Flying Frog Consultancy
> > > > > The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet-Hidequotedtext -
>
> > > > > - Show quoted text -
>
> > > > ___________________________
> > > > /| /| | |
> > > > ||__|| | Please don't |
> > > > / O O\__ feed |
> > > > / \ the trolls |
> > > > / \ \ |
> > > > / _ \ \ ----------------------
> > > > / |\____\ \ ||
> > > > / | | | |\____/ ||
> > > > / \|_|_|/ | __||
> > > > / / \ |____| ||
> > > > / | | /| | --|
> > > > | | |// |____ --|
> > > > * _ | |_|_|_| | \-/
> > > > *-- _--\ _ \ // |
> > > > / _ \\ _ // | /
> > > > * / \_ /- | - | |
> > > > * ___ c_c_c_C/ \C_c_c_c____________
>
> > > > Sorry for double posting but I'm getting sick of Xah Lee and Jon
> > > > Harrop.
> > > > We all get their message :COMMON LISP SUCKS so please let us leave in
> > > > our misery
> > > > while you make all the great programms in F#, Mathematica or
> > > > whatever ...
> > > > >From now on I'll ignore both of them for good .
>
> > > > cheers
> > > > bobi
>
> > > I fully agree. Neither of them as any (!) clue about Lisp and programming in Lisp.
> > > Neither of them has written any significant or even non-significant Lisp program.
> > > Their postings are full of (wrong) assumptions and are mostly based on
> > > no experience and no knowledge of Lisp programming. Both are only trolling
> > > in comp.lang.lisp. Best to post a warning sign and other to ignore them...
>
> > > --http://lispm.dyndns.org-Hidequoted text -
>
> > > - Show quoted text -
>
> > Seems that I was wrong about Xah Lee. He's no troll, but a completely
> > new flame warrior. Something that could be better described as
> > crossing of Tireless Rebutter ,Issues & Furious Typer . I will report
> > him to Mike Reed ····@hutman.net fromhttp://redwing.hutman.net/~mreed/
> > . I just don't know how to name it.
>
> >http://redwing.hutman.net/%7Emreed/warriorshtm/tirelessrebutter.htmht...Hide quoted text -
>
> > - Show quoted text -
>
> Ok after few thoughts I had a name read carefully and advise before
> I send this to Mr Mike Reed.
>
> Brainy a.k.a Lecturing Smurf
>
> Brainy Smurf fancies himself as the all-around-brain of the village. .
> In fact he could be considered as the class swot or know-all. Brainy
> Smurf is an avid reader and keeps a lot of books in his house (mostly
> his quotations). He is quite arrogant and often lectures smurfs who
> don't behave. Loquacious, he often uses big words that he himself
> either made up or doesn't know what they really mean. A lot of the
> other smurfs dislike him, and when he enters into a long lecturing,
> some frustrated smurf often angrily smashes him on the head with a big
> wooden mallet. Frequently, in the cartoon, after his blathering or
> posturing have gone too far, he is thrown a long distance (typically
> by Hefty Smurf), and always lands square on his head, usually outside
> of the village. He is the best friend to Clumsy Smurf.- Hide quoted text -
>
> - Show quoted text -
Brainy a.k.a Lecturing Smurf is fine about Xah Lee , though he's a bit
more agressive, or that's just becuse he knows nobody could spank
him .Send it It's fine for me.
On May 7, 10:15 am, fireblade <·················@gmail.com> wrote:
> Seems that I was wrong about Xah Lee. He's no troll, but a completely
> new flame warrior.
He's certainly an interesting character. I don't have much time for
psychoanalysis of whatever flavour, but given the way he almost
immediately responds to anyone who disagrees with him with obscenity
and boasting about the size of his penis you really have to wonder.
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <7500i.2159$V01.1504@newsfe12.lga>
Tim Bradshaw wrote:
> On May 7, 10:15 am, fireblade <·················@gmail.com> wrote:
>
>
>>Seems that I was wrong about Xah Lee. He's no troll, but a completely
>>new flame warrior.
>
>
> He's certainly an interesting character. I don't have much time for
> psychoanalysis of whatever flavour, but given the way he almost
> immediately responds to anyone who disagrees with him with obscenity
> and boasting about the size of his penis you really have to wonder.
>
Why wonder? Xah openly shares the mental challenges he lives with on his
Web site. I always adjust the gain on my attenna to the source at which
it is aimed. When Xah calls me "fuckhead Kenny", I gather he disagrees
with what I said. When Duane says "I disagree", I check for helicopters.
kenny
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 5, 1:11 am, Xah Lee <····@xahlee.org> wrote:
> How Lisp's Nested Notation Limits The Language's Utility
Very good. Now, off you go and design and implement an alternative
syntax. It's easy, it's been done hundreds of times. I think I have
two or three limited examples on my web site and several more I never
bothered publishing. There must, as I say, be hundreds of examples
around and probably thousands when you count all the non-published
ones. So pick the best and use them, or, since you're by far the
smartest person here, why not come up with your own? Jon Harrop can
probably help you.
Tim Bradshaw <··········@tfeb.org> writes:
> On May 5, 1:11 am, Xah Lee <····@xahlee.org> wrote:
>> How Lisp's Nested Notation Limits The Language's Utility
>
> Very good. Now, off you go and design and implement an alternative
> syntax. It's easy, it's been done hundreds of times. I think I have
> two or three limited examples on my web site and several more I never
> bothered publishing. There must, as I say, be hundreds of examples
> around and probably thousands when you count all the non-published
> ones. So pick the best and use them, or, since you're by far the
> smartest person here, why not come up with your own? Jon Harrop can
> probably help you.
>
Actually, I think this is a very good idea for Xah. Many have been very
critical of what he posts (including myself), but I suspect a large percentage
of people totally dismiss what he writes because he doesn't provide any
constructive alternatives. He regularly posts about what is wrong with emacs,
lisp, unix, perl etc. but rarely do I see any proposed solutions or
constructive ideas that might actually improve the situation.
come on Xah, you have made frequent references to your superior IQ, your
ability to write and express ideas. Its easy to moan about whats wrong with the
world, time to put your money where your mouth is. Take some of that boundless
IQ and your superior skills in communication and post some ideas on how things
could be improved.
Tim
--
tcross (at) rapttech dot com dot au
On May 6, 5:54 am, Tim X <····@nospam.dev.null> wrote:
> Take some of that boundless
> IQ and your superior skills in communication and post some ideas on how things
> could be improved.
Don't post ideas, post implementations. It really is very easy to
implement new syntaxes for Lisp.
Tim Bradshaw wrote:
> On May 6, 5:54 am, Tim X <····@nospam.dev.null> wrote:
>> Take some of that boundless
>> IQ and your superior skills in communication and post some ideas on how
>> things could be improved.
>
> Don't post ideas, post implementations. It really is very easy to
> implement new syntaxes for Lisp.
The problem isn't creating a syntax (all decent PLs have good syntax). The
problem is that CL doesn't bundle a decent syntax (or pattern matching,
or ...). So there's no point in Xah implementing anything.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On 2007-05-06 17:29:52 +0100, Jon Harrop <···@ffconsultancy.com> said:
> The problem isn't creating a syntax (all decent PLs have good syntax). The
> problem is that CL doesn't bundle a decent syntax (or pattern matching,
> or ...). So there's no point in Xah implementing anything.
As I mentioned in another article, I really think you do need to learn
about this internet thing. One of the nice features it offers is
something called "downloading" - people can write code which you can
then "download" onto your own computer and run there. It's just
amazingly better than the whole shipping magtapes around thing.
Tim Bradshaw <···@tfeb.org> wrote:
> As I mentioned in another article, I really think you do need to learn
> about this internet thing. One of the nice features it offers is
> something called "downloading" - people can write code which you can
> then "download" onto your own computer and run there. It's just
> amazingly better than the whole shipping magtapes around thing.
i wonder how the traditional "kid on a bicycle with a tape" back of the
envelope calculation holds up these days.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
On 2007-05-09 19:25:39 +0100, Garry Hodgson <·····@sage.att.com> said:
> i wonder how the traditional "kid on a bicycle with a tape" back of the
> envelope calculation holds up these days.
Still the same - tape or disk can achieve fantastic bandwidth.
Dreadful latency though.
Jon Harrop <···@ffconsultancy.com> wrote:
> The problem isn't creating a syntax (all decent PLs have good syntax). The
> problem is that CL doesn't bundle a decent syntax (or pattern matching,
> or ...). So there's no point in Xah implementing anything.
it might distract him from diatribing for a while.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <cWm%h.234$9D1.162@newsfe12.lga>
Tim X wrote:
> Tim Bradshaw <··········@tfeb.org> writes:
>
>
>>On May 5, 1:11 am, Xah Lee <····@xahlee.org> wrote:
>>
>>>How Lisp's Nested Notation Limits The Language's Utility
>>
>>Very good. Now, off you go and design and implement an alternative
>>syntax. It's easy, it's been done hundreds of times. I think I have
>>two or three limited examples on my web site and several more I never
>>bothered publishing. There must, as I say, be hundreds of examples
>>around and probably thousands when you count all the non-published
>>ones. So pick the best and use them, or, since you're by far the
>>smartest person here, why not come up with your own? Jon Harrop can
>>probably help you.
>>
>
>
> Actually, I think this is a very good idea for Xah. Many have been very
> critical of what he posts (including myself), but I suspect a large percentage
> of people totally dismiss what he writes because he doesn't provide any
> constructive alternatives. He regularly posts about what is wrong with emacs,
> lisp, unix, perl etc. but rarely do I see any proposed solutions or
> constructive ideas that might actually improve the situation.
>
> come on Xah, you have made frequent references to your superior IQ, your
> ability to write and express ideas. Its easy to moan about whats wrong with the
> world, time to put your money where your mouth is. Take some of that boundless
> IQ and your superior skills in communication and post some ideas on how things
> could be improved.
Close, but no cigar. Xah's problem is anger. That is why he is always
attacking things -- they make him angry. A clearer proof of his anger
would be this thread. Xah, like any, is a good person with a
hair-trigger anger. It has gotten that way because it has run unchecked,
in turn because the upper cortex always makes sense out of what is
happening. When anger strikes, it never seems as if anger Just Happened,
it always seems as if the thing making one angry was Just Horrible. Xah
needs to use his intellect to see how anger has enslaved him to begin
objectifying it, distancing his true self from his anger, eventually to
break anger's control over him.
hth,ken
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Dear Tim X,
i don't know who you are. But i vaguely recall, you are one of the
moronic respondents to one of my criticisms on how Emacs needs to be
modernized. (and i hated you very much)
(See
Modernization Emacs
http://xahlee.org/emacs/modernization.html
)
One of the criticism of my numerous criticism in the computing
industry, is that i am not “constructive” in some way. This is fuzzy
and silly.
For example, poeple don't respond to professional critics, by
retorting “What have you done?”
(
See
Criticism versus Constructive Criticism
UnixResource_dir/writ/criticism.html
)
A good criticism, in itself, is a contribution to the community.
Philosophers, for example, are examplary in this regard.
But as to what i have actually done for the computing communities of
which i've criticized besides criticism, i think there's a few.
Mostly, i have several tutorials on my website:
Perl and Python tutorial (~80 HTML pages)
• http://xahlee.org/perl-python/python.html
Emacs and Emacs Lisp tutorial (~80 HTML pages)
• http://xahlee.org/emacs/emacs.html
A complete, mirror of the official HTML documentation of Emacs Lisp,
with HTML code modified (corrected) so that they are W3C valid HTML
document, and CSS added for easier reading. (~850 HTML pages)
• http://xahlee.org/elisp/index.html
A Java tutorial
• http://xahlee.org/java-a-day/java.html (~40 HTML pages)
A Javascript and HTML and CSS tutorial (~70 HTML pages)
• http://xahlee.org/js/js.html
These are informal tutorials. Sure, they are not as rigorous as
published books in print. Sure, perhaps 20% of the content of my
tutorials are filled with technical criticisms.
You, as a tech geeker, may argue that my writings or teachings are in
bad quality or taste in your eyes. But they are there, and unarguably
took years to create. In all fairness, i think society would judge
them, to be positive, or “constructive” contributions. (and i do
receive regular emails from professional programers, educators,
professors, mathematicians (including a Nobel Prize laureate, to thank
me on my articles in diverse areas)
There was a Python fuckhead, who's name is Steve Holden ( http://www.holdenweb.com/
), in 2005-04-12, in response to criticisms i made of the
motherfucking garbage of the Python documentation, challenged me to
rewrite it, with the offer of $100 USD.
I responded, and the result is a full-rewrite of the Python's RE doc.
(
Pyhton Regex Documentation: String Pattern Matching
http://xahlee.org/perl-python/python_re-write/lib/module-re.html
)
He, reneged his promise to pay, citing that i missed the deadline
(that he missed my announcement), and that i failed the qualifications
of which he made the $100 offer.
Regardless of the situation, my rewrite of the entire Python
documentation of its RE module, is a contribution.
So, yeah, i made contributions, and arguably, quite a lot in the
computing industry. By my mere criticism, and by actual tutorials and
codes. (not counting, areas in Math, or Mathematica programing)
But really, the newsgroup fuckheads, their accusation of my “negative”
criticism, or my “lack of contribution”, really are due to their lack
of general education in the area of humanities (in particular: their
lack of understanding of the role of criticism), and as a execuse to
attack me in the political struggle, and or simply careless farts to
posts they don't like in newsgroups.
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
« How Lisp's Nested Notation Limits The Language's Utility
http://xahlee.org/UnixResource_dir/writ/notations.html
»
Tim Bradshaw wrote:
« Very good. Now, off you go and design and implement an alternative
syntax. It's easy, it's been done hundreds of times. I think I have
two or three limited examples on my web site and several more I never
bothered publishing. There must, as I say, be hundreds of examples
around and probably thousands when you count all the non-published
ones. So pick the best and use them, or, since you're by far the
smartest person here, why not come up with your own? Jon Harrop can
probably help you. »
Tim X wrote:
«
Actually, I think this is a very good idea forXah. Many have been very
critical of what he posts (including myself), but I suspect a large
percentage of people totally dismiss what he writes because he doesn't
provide any constructive alternatives. He regularly posts about what
is wrong with emacs, lisp, unix, perl etc. but rarely do I see any
proposed solutions or constructive ideas that might actually improve
the situation.
come onXah, you have made frequent references to your superior IQ,
your ability to write and express ideas. Its easy to moan about whats
wrong with the world, time to put your money where your mouth is. Take
some of that boundless IQ and your superior skills in communication
and post some ideas on how things could be improved.
»
Xah Lee <···@xahlee.org> writes:
> Dear Tim X,
>
> i don't know who you are. But i vaguely recall, you are one of the
> moronic respondents to one of my criticisms on how Emacs needs to be
> modernized. (and i hated you very much)
> (See
> Modernization Emacs
> http://xahlee.org/emacs/modernization.html
> )
Your right. I did respond to one of your posts criticising emacs. In fact, I
responded to one of the very first ones. I think it was possibly the
first time I responded to one of your posts. At the time, I thought you were
genuine and I responded with genuine suggestions and opinion on what you wrote.
I don't think you responded.
Its unfortunate you feel you hate me for it. Not because I care, but because
you obviously have an emotional investment in my opinion of you, which is a bit
pointless given the medium being used. I have no emotional investment in what
you think or believe. I'm willing to enter into intellectual debate because I
think such debate is a good way to clarify my thoughts and if its a good
debate, I often learn new things or new ways of thinking about something.
Unfortunately, you don't seem to be so inclined. What follows is my response
and some of my opinions and thoughts on your actions, which you will almost
certainly disagree with. In fact, you may not even be interested or may not be
able to read them without getting emotional, in which case, I'd stop reading
and just delete the message. Other readers shouldn't bother unless you have
nothing better to do!
Although your posts sometimes have some valid points, I have not yet seen an
original criticism from you. Every post I've bothered reading has just been a
regurgitation of well known or previously published ideas. In short, despite
your volume of material, I have yet to see anything new. Many of your points
show a very shallow understanding or little experience with the topic being
raised.
>
> One of the criticism of my numerous criticism in the computing
> industry, is that i am not “constructive” in some way. This is fuzzy
> and silly.
>
> For example, poeple don't respond to professional critics, by
> retorting “What have you done?”
>
Actually, it is often what people say. However, its a big stretch for you to
consider yourself in the same league as a professional critic. One of the
reasons that few people take you seriously is that you totally lack any
credibility. I think KT summed it up well when he referred to you as an
amusement. Your very much like the court jester. Now and again, you may say
something with a grain of truth in it, but really, we just read what you write
for a laugh. In some cases, there is the glimmer of something new - a diamond
in the rough. However, instead of taking on the criticisms and refining your
arguement, you typically just attack the poster at a personal level and fail to
use what they have said as a way of making your argument strong and possibly
more convincing.
> A good criticism, in itself, is a contribution to the community.
> Philosophers, for example, are examplary in this regard.
>
True, but the key word there is 'good'. Your criticisms are rarely good or well
thought out. Philosophers try to add to our knowledge and
understanding of the world by thinking, debating, proposing new paradigms and
generally working towards increasing our knowledge and understanding of things.
You simply repeat old ideas and opinions, often with inconsistency and always
at a very shallow level.
While I agree some people simply respond and write you off as an idiot or some
loony, it is interesting to note that these are the posts you tend to respond
to. You rarely respond to those who post genuine arguements against your
opinion and when you do, you generally make it a personal attack and totally
ignore the points they raise. You add words like fuckhead as if that will
somehow make what you say more powerful or maybe you think it will cause a more
emotional reaction. The irony is that you do it so often, we all expect it now
and such words have totally lost any impact - they are now just line noise.
I find it amusing you have condemned so many in this group for being religious
fanatics and having closed minds, yet you have failed to address many of the
valid points raised to counter your claims. For me, religious fanatics are
those annoying people who insist on coming to your door, trying to tell you
about their god and what you need to be saved. These are the same ones that
refuse to listen to reason or science or anything else that challenges their
beliefs and will resort to personal and emotional attacks when presented with
arguements they cannot counter. Does this remind you of anyone? Possibly
someone who indiscriminately posts rants on what they believe is wrong to the
world to newsgroups and then attack anyone who doesn't agree with them? Does
this sound at all familiar? I'm sure with your huge IQ I'm not being too subtle
for you. Look at your history of posts. How many of them have you seen develop
into a real intellectual debate? How many of them have actually added anything
to the general body of knowledge? I may have missed them, but I've never seen a
single one and nor could I find any searching the archives.
> But as to what i have actually done for the computing communities of
> which i've criticized besides criticism, i think there's a few.
> Mostly, i have several tutorials on my website:
>
Well, I have to admit, I did check out your website some time ago. There
certainly did seem to be quite a volume of material. However, the brief stuff I
read was, well, pretty average at best. I found that your discussion of many
topics was largely superficial and showed a very poor depth of understanding.
The one exception was some stuff on geometry (I could be wrong, it was a while
ago). This did seem to have some deeper understanding and potential for truely
original thinking, but was lacking in rigor and any disaplin of thought.
My honest opinion is that you are someone who has a very broad superficial
knowledge of a lot of different topics, but there is little evidence of any
really deep understanding. Much of your writing has the feel of being done by
someone who has spent a few weeks looking at a particular topic and then
written up their findings. There is no evidence of real world application or
any indication that the topic has been covered in any more depth than wold be
expected from someone having completed a semester course on the topic. You
attempt to sell yourself as an expert, yet there is no evidence of any real
expertise or experience.
You obviously enjoy writing. It is unfortunate you appear to be unable to
accept criticism in an unemotional way as this would likely improve your style
and make you a better communicator. Despite your belief in yourself, your IQ
and your huge cock, your expression and general communication skills are pretty
poor.
As I mentioned, it has been a while since I looked at your site and maybe
things have improved. I will look at some of your tutorials and see if they
actually add anything or are simply more unoriginal regurgitation of existing
knowledge, which on the whole, was originally expressed with greater eloquence than you
have exhibited.
>
> You, as a tech geeker, may argue that my writings or teachings are in
> bad quality or taste in your eyes. But they are there, and unarguably
> took years to create. In all fairness, i think society would judge
> them, to be positive, or “constructive” contributions. (and i do
> receive regular emails from professional programers, educators,
> professors, mathematicians (including a Nobel Prize laureate, to thank
> me on my articles in diverse areas)
I wouldn't argue they are in bad taste, but I would question what contribution
they actually make. Quantity is no substitution for quality. Your work on the
emacs web pages is probably something that was worthwhile as it (according to
you) has fixed errors and problems with the originals. In this case, it is
unfortunate your behavior and general attitude has undermined your credibility
as this work would probably be valued more otherwise. In an ideal world, you
could argue this shouldn't matter, but unfortunately we don't live in an ideal
world.
I have to admit to being surprised you have received so much praise by
professional programmers and even a Nobel Prize laureate. (I wonder if the
e-mail from the latter was in relation to the math stuff I mentioned earlier.
as I said, it did show originality and a rare bit of deep insight). I actually
have no doubt you are intelligent and unlike your bosts of cock size, actually
believe you probably did get a high IQ score (but then again, psychologists are
still arguing about what IQs really measure or if they relate to intelligence
anyway. In fact, they cannot agree on precisely what intelligence is). My issue
isn't that I think your stupid or can't understand complex things, but rather
that you appear to be intellectually lazy. By this, I mean you don't appear to
apply any real rigor to your analysis or thinking on topics - your all over the
shop, chopping and changing and avoiding any real debate.
some posters have said that your claims of huge intelligence and a high cock
are really expressions of your own feelings of inadequacy. As I don't know you,
I can't say for sure, but I would agree that such claims usually are indicators
of someone who feels inadequate. Maybe it is this desire to appear smart that
makes you jump around too so many different topics and not spend the time to
develop true understanding. If this is the case, it is a waste. If you are
really as intelligent as you would like to believe, then do something that will
actually improve things. Pick an area and really work at becoming an expert.
then, you can possibly contribute something of real substance. Anything else is
just a waste and as truely gifted people are rare, such a waste is truely a
shame.
> There was a Python fuckhead, who's name is Steve Holden ( http://www.holdenweb.com/
> ), in 2005-04-12, in response to criticisms i made of the
> motherfucking garbage of the Python documentation, challenged me to
> rewrite it, with the offer of $100 USD.
>
> I responded, and the result is a full-rewrite of the Python's RE doc.
> (
> Pyhton Regex Documentation: String Pattern Matching
> http://xahlee.org/perl-python/python_re-write/lib/module-re.html
> )
> He, reneged his promise to pay, citing that i missed the deadline
> (that he missed my announcement), and that i failed the qualifications
> of which he made the $100 offer.
>
As I don't know the facts and only have your side of the story, I can't really
comment other than to say that some people are honorable and some are not.
Sometimes we get sucked in, but there is no point dwelling on the issue and
creating stress and anger. Such things tend to cause physical and mental
ailments and allowing that to happen is effectively allowing them to win. If
you feel you did the right an honorable thing and made a positive contribution,
then move on and forget about lesser individuals. In the end, none of this
really matters. We will all be dead in 100 years and 100 years after that
nobody will remember us anyway.
> Regardless of the situation, my rewrite of the entire Python
> documentation of its RE module, is a contribution.
>
> So, yeah, i made contributions, and arguably, quite a lot in the
> computing industry. By my mere criticism, and by actual tutorials and
> codes. (not counting, areas in Math, or Mathematica programing)
>
Yes, but what contributions do your posts on whats wrong with emacs, lisp,
python or perl really contribute? You don't raise any points that haven't
already been raised by others, you don't enter into debate on the points you
raise and you don't pose any possible avenues for ways to address/improve the
problems you have identified. This is total intellectual lazyness, especially
if your as intelligent as you claim. As everyone knows, its easy to sit back
and criticise - first year comp. sci. students can do as much. The really
intelligent people are the ones that identify the problems and actually attempt
to find ways of solving them. To a large extent, your credibility has been shot
to pieces because people now just see you as a moaner who constantly complains
about whats wrong with things. Gain some credibility and you may actually be
able to improve things (unless of course you just want to moan because your in
love with your own voice, which I guess is valid, but ultimately boring and
irelavent).
> But really, the newsgroup fuckheads, their accusation of my “negative”
> criticism, or my “lack of contribution”, really are due to their lack
> of general education in the area of humanities (in particular: their
> lack of understanding of the role of criticism), and as a execuse to
> attack me in the political struggle, and or simply careless farts to
> posts they don't like in newsgroups.
>
Now your just trying to rationalise and make excuses. If your really genuine
about what you write, then back it up with real debate on the topic, stop
making personal attacks and stop this pointless scatter gun approach to
posting. Target your audiance and be prepared to debate your views. don't just
post as if you were doing a drive by shooting, firing and then running away
before anyone can shoot back.
I have given you the benefit of the doubt in this post, which actually goes
against my instincts. I actually think that what really gives you pleasure is
to start a thread and see it grow - somehow making you feel you have a twisted
sense of power or influence. Your tendency to respond with personal attacks
filled with abusive language does make me think you really get off on trying to
get an emotional response. I hope this isn't the case because this would
indicate a deeply unhappy and emotionally stunted existance that is missing out
on some of the better things in life.
Tim
--
tcross (at) rapttech dot com dot au
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5a33bdF2ng0i9U1@mid.individual.net>
Xah Lee wrote:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of “inferior” text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
>
> (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.
Lisp doesn't have a problem here. Lisp is a programming language, an
inanimate, dispassionate, virtual concept which doesn't (cannot!) "care"
whether it is used at all.
Only people can have problems with something. For example, programmers
who want some of the cool features of Lisp but don't want to put up with
its syntax.
However, for decades, there have been programmers who have learned to
prefer Lisp's syntax over anything else. As long as they continue to
exist, Lisp dialects will continue to exist. Those people don't have a
problem - to the contrary.
Leave them alone - they are happy with their choice.
If you don't like Lisp, there are numerous attempts to copy its features
using other surface syntaxes. Just pick one.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Dear Pascal moron,
Xah Lee wrote:
« (1) Some 99% of programers are not used to the nested parenthesis
syntax. This is a practical problem. On this aspect along, lisp's
syntax can be considered a problem.»
Pascal Costanza wrote:
«Lisp doesn't have a problem here. Lisp is a programming language, an
inanimate, dispassionate, virtual concept which doesn't (cannot!)
"care" whether it is used at all. Only people can have problems with
something. For example, programmers who want some of the cool features
of Lisp but don't want to put up with its syntax. »
You are actually wrong here, because, people can't have a problem.
People are animals, made of meat. They can have a problem when, they
get sick, and their body will disfunction or function abnormally. So,
for example, even sexp has all the problems, lisp morons are still
fine.
Pascal fuckhead wrote:
«However, for decades, there have been programmers who have learned to
prefer Lisp's syntax over anything else. As long as they continue to
exist, Lisp dialects will continue to exist. Those people don't have a
problem - to the contrary.»
existence?
my god... you are quite desperate.
In this thread, a few people already started to post completely off
topic, brainless, pure personal attacks. I think you are still good.
Sometimes i have a problem telling, of those who post brainless things
to my articles, whether they are joking with wanton carelessness, or
if their critical thinking abilities is really that low.
For example, your reply is a good example. I wasn't sure, if you are
just fucking with me, or really, really meant your writing as a valid
argument to my thesis. In this thread, Ken Tilton, also wrote
something that's incredibly stupid. In fact, more or less repeating
what i said, just with antagonism and explicit denial. I take it, that
he acted that way probably because my essay is so cogent and powerful
that it hit a nerve and paralyzed his reasoning faculties and numbed
his nonchalant quip Muse.
There are some others in this thread, which are so hateful, fucking
full of the ugliness of humanity. The replies from Markus E Leypold is
a prime example. I wonder, outside of newsgroups, if he is just a
sophomoron at college.
Other posts in this thread, some sincere ones, are full utterly
fucking stupid drivels. (or i shall put the polite version: logical
fallacies) The level is so low that i'm really ashamed that they
really came out from the mouthes of a class of people in society who's
jobs are to program computers.
(in this regard, see:
The Condition of Industrial Programers
http://xahlee.org/UnixResource_dir/writ/it_programers.html
)
For example, there's this gem: «Programming language syntax shouldn't
be natural for humans to read. Or, rather, this shouldn't be a
requirement which creates technical compromises.»
I think this quote or the concept of it has been around for a while.
If you take it seriously, it's full of MOTHERFUCKING nonsensical,
meaningless, shit. It amounts to a sound bite. Behind it, it wants to
make programers, in particular the elite programers like the lisp
fuckers, to think something along the line: “my syntax is so bizarre
because i'm superior”.
I guess it's lisper's version of “The three chief virtues of a
programmer are: Laziness, Impatience and Hubris”.
Pascal Costanza moron wrote:
«Leave them alone - they are happy with their choice. »
«If you don't like Lisp, there are numerous attempts to copy its
features
using other surface syntaxes. Just pick one. »
Try, perhaps, learn to calm down yourself. You are not under attack.
Lisp the language, is not under attack by my essay. My article,
although cogently detailed why lisp syntax is a serious problem at
several levels, it does not mean that, it is “no good” in some
absolute way. Also, it is far better, then essentially all imperative
language's syntaxes. Even, one can logically agree with my article,
and remain positive, because although lisp perhaps reduce the use of
function sequencing, but that by itself is not necessarily a very bad
thing. Because, function sequencing (aka chaining), although a very
important paradigm, is not necessarily the only way to program, nor
the only way for functional programing. Consider, even today in the
light of OOP. And Common Lisp, in particular, isn't all that much
concerned about purity of functional programing anyway. So logically,
from this perspective or argument, my essay isn't a damning
certificate.
I'm really sorry i have to say the above paragraph, as if like a pat
on the back to some crying pussies. But the juvenility, sensitivity,
ignorance, and stupidity, as shown in the responses in this thread,
made me.
I was hoping, perhaps due to my clear exposition of the sexp problem
for perhaps the first time, that we could move on to other fruitful
discussions, not necessarily agree that it is a problem. For example,
LOGO, DyLan, Arc all abandoned the nested fuck. I mean, lispers may
disagree, but the people behind these LISP languages are not brainless
fuckheads, are they? Alternatively, i was hoping, perhaps there will
be fruitful discussions in the direction of technical issues of
transforming syntax. i.e. of Mathematica's f[a,b] and lisp's (f a b).
Or, perhaps some technically knowledgable people here (there are many)
can by ways of chat, impart some insight about some technical
connections between syntaxes and semantic (apart from myself). For
example, DyLan i believe once was believed to have have sexp
underneath. If so, that would be interesting because it gives us a
actual, existing, example of a lang with sexp underneath alternative
to Mathematica's ways. But also, lisp can actually relatively easily,
create a layer of syntax on top of sexp...
Really, you people need to learn. Be calm. Keep your mind open. I'm
not attacking you or attacking lisp. If there's any attacking, it is
your immature and unhealthy nerve.
PS By the way, i also responded a article recently about why Perl and
Python programers today should learn lisp.
(
“Why learn lisp when there are python and perl?”, Xah Lee, 2007-05-03.
http://xahlee.org/UnixResource_dir/writ/wl_lisp.html
)
Can a lisper write a open letter thanking me for that please?
Xah
···@xahlee.org
∑ http://xahlee.org/
Ouch.
I am just a Lisp newbie, quietly lurking in this newsgroup,
occasionally asking questions. Some of these questions are
elementary, doubtless asked a zillion times before (even though I
always search the archives), but kind people in this newsgroup always
give me a lot of helpful answers and hints.
Even though I cannot prevent it, I hate to see them being called names
by a disgruntled teenager (or someone with an equivalent level of
social skills).
So far, I have been using Google Groups, but that has no filtering.
Could somebody please recommend a reliable and cheap (or a convex
combination of the two ;-) news server? I have seen them mentioned in
the past before, but could not find them. Then I could use mutt or
something else to read news, and filter certain messages.
Thanks,
Tamas
PS: Sorry for the OT post, but this thread finally made it clear that
Google Groups (a great free service) is not the perfect solution for
increasing the signal/noise ratio.
On May 5, 11:52 am, Xah Lee <····@xahlee.org> wrote:
> Dear Pascal moron,
>
[snip]
Tamas wrote:
> Ouch.
>
> I am just a Lisp newbie, quietly lurking in this newsgroup,
> occasionally asking questions. Some of these questions are
> elementary, doubtless asked a zillion times before (even though I
> always search the archives), but kind people in this newsgroup always
> give me a lot of helpful answers and hints.
>
> Even though I cannot prevent it, I hate to see them being called names
> by a disgruntled teenager (or someone with an equivalent level of
> social skills).
>
> So far, I have been using Google Groups, but that has no filtering.
> Could somebody please recommend a reliable and cheap (or a convex
> combination of the two ;-) news server? I have seen them mentioned in
> the past before, but could not find them. Then I could use mutt or
> something else to read news, and filter certain messages.
I use http://teranews.com/. $3.95 for a lifetime account with a 50mb
daily limit, which is more then enough for the comp.lang.* reading i do.
Cheers,
drewc
>
> Thanks,
>
> Tamas
>
> PS: Sorry for the OT post, but this thread finally made it clear that
> Google Groups (a great free service) is not the perfect solution for
> increasing the signal/noise ratio.
>
> On May 5, 11:52 am, Xah Lee <····@xahlee.org> wrote:
>> Dear Pascal moron,
>>
> [snip]
>
--
Posted via a free Usenet account from http://www.teranews.com
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <CT3%h.397$PS7.122@newsfe12.lga>
Tamas wrote:
> Ouch.
>
> I am just a Lisp newbie, quietly lurking in this newsgroup,
> occasionally asking questions. Some of these questions are
> elementary, doubtless asked a zillion times before (even though I
> always search the archives), but kind people in this newsgroup always
> give me a lot of helpful answers and hints.
>
> Even though I cannot prevent it, I hate to see them being called names
> by a disgruntled teenager (or someone with an equivalent level of
> social skills).
We don't need your stinking concern. <kidding!>
Don't worry, Xah is OK. Google applications agreed are not. I use
Mozilla Thunderbird on win32 for mail and news (I have the mail from my
google account forwarded to my ISP mail address so I still get the
portable address and junk filtering).
kenneth
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5a3tlgF2mrt6kU1@mid.individual.net>
Tamas wrote:
> Could somebody please recommend a reliable and cheap (or a convex
> combination of the two ;-) news server? I have seen them mentioned in
> the past before, but could not find them.
I use http://news.individual.net/ and am pretty happy with their service.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
“Tamas” wrote:
«So far, I have been using Google Groups, but that has no
filtering. ... I could use mutt or something else to read news, and
filter certain messages.»
Dear Damas,
What you want to do, is not a good thing in the long run. In fact, it
just plagued newsgroups worse in your sense of how you want it to be.
Please see:
Killfile Considered Harmful
http://xahlee.org/UnixResource_dir/writ/kill_file_harmful.html
Your gentle, wholly off-topic message, instigated 3 more wholly off-
topic gentle messages. (not counting my own here) So, you, are
actually contributing to the so-perceived “worsening” of newsgroup
quality.
You purport to not want off-topic or drivels in newsgroups, but the
fact judged by your behavior is, you love it. And, you are not the
only one. Thousands before you, all like you, did the same,
intentional or not. So, besides huffy-puffy spittle among tech-geeking
language factions, there is another class of soldier, like yourself,
who perennially install themselves into the awareness of the public,
about how benign and good-hearted they are.
Can you post your valid complaint and criticism to
alt.netiquette.discuss or alt.software.google ?
It would be ON-TOPIC there.
Follow up set!
------------------------
Further readings:
Tech Geekers versus Spammers
http://xahlee.org/UnixResource_dir/writ/tech_geekers_vs_spammers.html
Xah
···@xahlee.org
∑ http://xahlee.org/
I think *you* need to cool down Xah Lee. I agree it can be annoying
if you make a critical analysis of Lisp and people attack *you*. This
is called an ad hominem argument, and, sadly, they are all too common
on usenet. But calling people names like 'moron' is not the right
way to win hearts and minds. You say some interesting things but you
play into the hands of your critics by launching personal attacks.
Now you will probably get a load more posts attacking your bad manners
and so your original points are lost in the scrum and people write you
off as a troll.
Be cool and if you do think someone is using ad hominem arguments;
tersely point it out and return to the main points. Don't get
abusive.
Mark
On 5 May, 16:52, Xah Lee <····@xahlee.org> wrote:
> Dear Pascal moron,
>
> Xah Lee wrote:
>
> « (1) Some 99% of programers are not used to the nested parenthesis
> syntax. This is a practical problem. On this aspect along, lisp's
> syntax can be considered a problem.»
>
> Pascal Costanza wrote:
>
> «Lisp doesn't have a problem here. Lisp is a programming language, an
> inanimate, dispassionate, virtual concept which doesn't (cannot!)
> "care" whether it is used at all. Only people can have problems with
> something. For example, programmers who want some of the cool features
> of Lisp but don't want to put up with its syntax. »
>
> You are actually wrong here, because, people can't have a problem.
> People are animals, made of meat. They can have a problem when, they
> get sick, and their body will disfunction or function abnormally. So,
> for example, even sexp has all the problems, lisp morons are still
> fine.
>
> Pascal fuckhead wrote:
>
> «However, for decades, there have been programmers who have learned to
> prefer Lisp's syntax over anything else. As long as they continue to
> exist, Lisp dialects will continue to exist. Those people don't have a
> problem - to the contrary.»
>
> existence?
>
> my god... you are quite desperate.
>
> In this thread, a few people already started to post completely off
> topic, brainless, pure personal attacks. I think you are still good.
>
> Sometimes i have a problem telling, of those who post brainless things
> to my articles, whether they are joking with wanton carelessness, or
> if their critical thinking abilities is really that low.
>
> For example, your reply is a good example. I wasn't sure, if you are
> just fucking with me, or really, really meant your writing as a valid
> argument to my thesis. In this thread, Ken Tilton, also wrote
> something that's incredibly stupid. In fact, more or less repeating
> what i said, just with antagonism and explicit denial. I take it, that
> he acted that way probably because my essay is so cogent and powerful
> that it hit a nerve and paralyzed his reasoning faculties and numbed
> his nonchalant quip Muse.
>
> There are some others in this thread, which are so hateful, fucking
> full of the ugliness of humanity. The replies from Markus E Leypold is
> a prime example. I wonder, outside of newsgroups, if he is just a
> sophomoron at college.
>
> Other posts in this thread, some sincere ones, are full utterly
> fucking stupid drivels. (or i shall put the polite version: logical
> fallacies) The level is so low that i'm really ashamed that they
> really came out from the mouthes of a class of people in society who's
> jobs are to program computers.
>
> (in this regard, see:
> The Condition of Industrial Programershttp://xahlee.org/UnixResource_dir/writ/it_programers.html
> )
>
> For example, there's this gem: «Programming language syntax shouldn't
> be natural for humans to read. Or, rather, this shouldn't be a
> requirement which creates technical compromises.»
>
> I think this quote or the concept of it has been around for a while.
> If you take it seriously, it's full of MOTHERFUCKING nonsensical,
> meaningless, shit. It amounts to a sound bite. Behind it, it wants to
> make programers, in particular the elite programers like the lisp
> fuckers, to think something along the line: “my syntax is so bizarre
> because i'm superior”.
>
> I guess it's lisper's version of “The three chief virtues of a
> programmer are: Laziness, Impatience and Hubris”.
>
> Pascal Costanza moron wrote:
>
> «Leave them alone - they are happy with their choice. »
>
> «If you don't like Lisp, there are numerous attempts to copy its
> features
> using other surface syntaxes. Just pick one. »
>
> Try, perhaps, learn to calm down yourself. You are not under attack.
> Lisp the language, is not under attack by my essay. My article,
> although cogently detailed why lisp syntax is a serious problem at
> several levels, it does not mean that, it is “no good” in some
> absolute way. Also, it is far better, then essentially all imperative
> language's syntaxes. Even, one can logically agree with my article,
> and remain positive, because although lisp perhaps reduce the use of
> function sequencing, but that by itself is not necessarily a very bad
> thing. Because, function sequencing (aka chaining), although a very
> important paradigm, is not necessarily the only way to program, nor
> the only way for functional programing. Consider, even today in the
> light of OOP. And Common Lisp, in particular, isn't all that much
> concerned about purity of functional programing anyway. So logically,
> from this perspective or argument, my essay isn't a damning
> certificate.
>
> I'm really sorry i have to say the above paragraph, as if like a pat
> on the back to some crying pussies. But the juvenility, sensitivity,
> ignorance, and stupidity, as shown in the responses in this thread,
> made me.
>
> I was hoping, perhaps due to my clear exposition of the sexp problem
> for perhaps the first time, that we could move on to other fruitful
> discussions, not necessarily agree that it is a problem. For example,
> LOGO, DyLan, Arc all abandoned the nested fuck. I mean, lispers may
> disagree, but the people behind these LISP languages are not brainless
> fuckheads, are they? Alternatively, i was hoping, perhaps there will
> be fruitful discussions in the direction of technical issues of
> transforming syntax. i.e. of Mathematica's f[a,b] and lisp's (f a b).
> Or, perhaps some technically knowledgable people here (there are many)
> can by ways of chat, impart some insight about some technical
> connections between syntaxes and semantic (apart from myself). For
> example, DyLan i believe once was believed to have have sexp
> underneath. If so, that would be interesting because it gives us a
> actual, existing, example of a lang with sexp underneath alternative
> to Mathematica's ways. But also, lisp can actually relatively easily,
> create a layer of syntax on top of sexp...
>
> Really, you people need to learn. Be calm. Keep your mind open. I'm
> not attacking you or attacking lisp. If there's any attacking, it is
> your immature and unhealthy nerve.
>
> PS By the way, i also responded a article recently about why Perl and
> Python programers today should learn lisp.
> (
> “Why learn lisp when there are python and perl?”, Xah Lee, 2007-05-03.
> http://xahlee.org/UnixResource_dir/writ/wl_lisp.html
> )
>
> Can a lisper write a open letter thanking me for that please?
>
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
Mark Tarver wrote:
«I think *you* need to cool down Xah Lee. I agree it can be annoying
if you make a critical analysis of Lisp and people attack *you*. This
is called an ad hominem argument, and, sadly, they are all too common
on usenet. ...»
«But calling people names like 'moron' is not the right way to win
hearts and minds....»
Exactly. I've been using online forums since 1990. I've been using
newsgroups since maybe 1994. If i wanted to play politics, given my IQ
and my knowledge of computing, and great skill of composition, i might
be a fucknig George Bush by now, with a massive army of morons at my
commands, not like, the likes of some computing industry leaders.
Understand, politness, is a intrinsic element of politics. (and
politics, means power-struggle) Politness arose from the existance of
hostility and aggression. Without aggression, there is no politness.
One easy way to see this, is notice how the behavior of politeness is
inversly proportional to how close are the parties involved. There
will be little politness, between your sisters, wives, or parents.
There will be a huge politeness, when big stakes are involved between
unbound human animals.
The computing newsgroups, made of males, have been brawling just about
when it begin. Your few words on politness and lecturing, is one
additional off-topic drivel in its history. (though, i appreciate your
kindness and your knowledge)
In this thread, i did not start four-letter words before NUMEROUS
fuckheads began sprouting purely unreasonable, totally off-topic,
personal attacks on me in a way more serious than name calling.
(because, it smacks of witch-hunting) (they naturally did this,
because they perceived that i “attacked” their computer language. This
is because, the computing language newsgroup tech geekers are utterly
ignorant of sociology, and combined with male power struggling
instict, have habored the thought about “trolling”, and some ethical
ideas about what one can or cannot say about other's computer
languages. Utterly bizarre.)
This doesn't happen to just me. It just a normal day in newsgroups.
Whoever, may it be professor, or eminent mathematician, professinoal
senior programers (as many are here), as long as he is a long time
newsgroup user, may have involved in verbal abuses given or taken.
(and each party are fully aware the other's social standings, but it
does'n matter. (e.g. in this very thread, a few started to gang up on
Jon Harrop, who is a author of a few functional language books)) It
is, the culture of newsgroups, so to speak. In a way, it is how people
WANT newsgroups to be the way it is. You knew it, i knew it, and we
should not deny it. If you are concerned about this state of affairs
of newsgroups, you need to rethink about it. Not the same old
instinctive good intentions. George motherfucking Bush has good
intentions and 50k to 300k Islamic civilians are dead. I'm sure you
are a kind man. Thousands of kind men existed in newsgroups before
you. They all have, at one time or another or more, given kind
advices, and contributed to what newsgroup is today.
I recommend a few articles. These articles, if tech geekrs all read
it, will help improve the state of affairs of newsgroups.
• What Desires are Politically Important? by Bertrand Russell
http://xahlee.org/Periodic_dosage_dir/_p2/russell-lecture.html
• Demonic Males. Apes and the Origins of Human Violence.
By Richard Wrangham and Dale Peterson
http://xahlee.org/p/demonic_males.html
Nice meeting you.
Xah
···@xahlee.org
∑ http://xahlee.org/
From: thorne
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m3tzukxlmg.fsf@timbral.net>
Xah Lee <···@xahlee.org> writes:
> Exactly. I've been using online forums since 1990. I've been using
> newsgroups since maybe 1994. If i wanted to play politics, given my IQ
> and my knowledge of computing, and great skill of composition, i might
> be a fucknig George Bush by now, with a massive army of morons at my
> commands, not like, the likes of some computing industry leaders.
This is one of the funniest things i've ever read on Usenet.
--
þ theron tlåx þ
(compose-mail (concat ·······@" (rot13 "gvzoeny") ".net"))
From: David Kastrup
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <85y7k3rnz1.fsf@lola.goethe.zz>
Mark Tarver <··········@ukonline.co.uk> writes:
> I think *you* need to cool down Xah Lee. I agree it can be annoying
> if you make a critical analysis of Lisp and people attack *you*.
> This is called an ad hominem argument, and, sadly, they are all too
> common on usenet. But calling people names like 'moron' is not the
> right way to win hearts and minds. You say some interesting things
> but you play into the hands of your critics by launching personal
> attacks.
"play" is actually not the four-letter word I would have used here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
> Other posts in this thread, some sincere ones, are full utterly
> fucking stupid drivels. (or i shall put the polite version: logical
> fallacies) The level is so low that i'm really ashamed that they
> really came out from the mouthes of a class of people in society who's
> jobs are to program computers.
>
> (in this regard, see:
> The Condition of Industrial Programershttp://xahlee.org/UnixResource_dir/writ/it_programers.html
> )
>
When Xah Lee cites to his website, it reminds me of Ignatius J. Reilly
citing his own work in Toole's "A Confederacy of Dunces:"
--- excerpt ---
The humble and pious peasant, Piers Plowman, went to town to sell his
children to the lords of the New Order for purposes that we may call
questionable at best. (See Reilly, Ignatius J., _Blood on Their
Hands: The Crime of It All, A study of some selected abuses in
sixteenth-century Europe_, a Monograph, 2 pages, 1950, Rare Book Room,
Left Corridor, Third Floor, Howard-Tilton Memorial Library, Tulane
University, New Orleans 18, Louisiana. Note: I mailed this singular
monograph to the library as a gift; however, I am not really certain
that it was ever accepted. It may well have been thrown out because
it was only written in pencil on tablet paper.)
--- end excerpt --
Ken, are you related to the Tilton who founded the library
mentioned?
Interestingly enough, Ignatius J. Reilly clearly was not put off by
parentheses, as he nests them throughout his writings. This is one
reason I recommend "A Confederacy of Dunces" to people learning Lisp,
though I still feel Practical Common Lisp is the best for total
newbies.
OK, sorry to distract from the main line here.
Best,
Andrew
"Xah Lee" <···@xahlee.org> wrote in message
·····························@l77g2000hsb.googlegroups.com...
>For example, there's this gem: «Programming language syntax shouldn't
>be natural for humans to read. Or, rather, this shouldn't be a
>requirement which creates technical compromises.»
>I think this quote or the concept of it has been around for a while.
>If you take it seriously, it's full of --------- nonsensical,
>meaningless, ----. It amounts to a sound bite. Behind it, it wants to
>make programers, in particular the elite programers like the lisp
>-----, to think something along the line: “my syntax is so bizarre
>because i'm superior”.
>
Now I also disagreed with Kaz on that one. Compare my post with yours. and
consider why I had to delete some many words in quoting you. Who do you
think is more likely to convince Mr Kylheku that he is in error?
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5a9o30F2ngouqU1@mid.individual.net>
Xah Lee wrote:
> But also, lisp can actually relatively easily,
> create a layer of syntax on top of sexp...
It was hard to find out that there is actually a question somewhere deep
down in your posting.
Here is one possible answer:
(defmacro pipe (&body forms)
(let ((var (gensym)))
`(macrolet ((=> (&body forms)
`(let ((,',var (funcall #',(car forms) ,',var)))
,(if (cdr forms) (cdr forms) ',var))))
(let ((,var ,(car forms)))
,(if (cdr forms) (cdr forms) var)))))
> (defun square (x) (* x x))
SQUARE
> (pipe 5 => 1+ => square => print)
36
This is just a sketch. A full version would probably require some more
work. But there you go...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Xah Lee wrote:
>> But also, lisp can actually relatively easily,
>> create a layer of syntax on top of sexp...
> Here is one possible answer:
> > (pipe 5 => 1+ => square => print)
Just to make this slightly shorter, most nonLispers
seem to like concise syntax, so they might prefer
5 => 1+ => square => print
which in Lisp can (and sort of has to) be written even
more concisely as
(=> 5 1+ square print)
(defmacro => (&rest forms)
(let ((expr (car forms)))
(dolist (func (cdr forms) expr)
(setf expr `(funcall #',func ,expr)))))
(defun echo-sqrt ()
(write-string "Enter number to be sqrt'd: ")
(finish-output)
(=> (read-line)
parse-integer
sqrt
write-to-string
write-line))
> Enter number to be sqrt'd: 34
> 5.8309517
--
Dan
www.prairienet.org/~dsb/
On May 8, 3:44 am, Dan Bensen <··········@cyberspace.net> wrote:
>
> (defmacro => (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(funcall #',func ,expr)))))
Just to be clear, this is precisely *not* what a pipe operator should
do, and it's not what it does in scsh. This is just a notation for
function composition, and that' s not what pipes are (or it's not what
they are without significant changes to what function call means).
The reason this isn't what pipes are is this (in sh)
(while wget http://some/site/blah; do sleep 30; done) | awk '...'
for instance. This perfectly reasonable fragment may fail to
terminate, yet it does (or may) result in a stream of output which
output may be useful. And that's the thing about pipelines: they
operate on potentially infinite streams. Function call in CL is not
like that.
I think you can *make* function call like that with languages which do
lazy evaluation, but CL is not natively such a language. Neither is
scsh as far as I know, and pipes etc are different things than
function calls in it.
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5abb1rF2obpsbU1@mid.individual.net>
Tim Bradshaw wrote:
> On May 8, 3:44 am, Dan Bensen <··········@cyberspace.net> wrote:
>
>> (defmacro => (&rest forms)
>> (let ((expr (car forms)))
>> (dolist (func (cdr forms) expr)
>> (setf expr `(funcall #',func ,expr)))))
>
> Just to be clear, this is precisely *not* what a pipe operator should
> do, and it's not what it does in scsh. This is just a notation for
> function composition, and that' s not what pipes are (or it's not what
> they are without significant changes to what function call means).
>
> The reason this isn't what pipes are is this (in sh)
>
> (while wget http://some/site/blah; do sleep 30; done) | awk '...'
>
> for instance. This perfectly reasonable fragment may fail to
> terminate, yet it does (or may) result in a stream of output which
> output may be useful. And that's the thing about pipelines: they
> operate on potentially infinite streams. Function call in CL is not
> like that.
>
> I think you can *make* function call like that with languages which do
> lazy evaluation, but CL is not natively such a language. Neither is
> scsh as far as I know, and pipes etc are different things than
> function calls in it.
OK, but Xah's complaint was about syntax, not about semantics.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On May 8, 2:08 pm, Pascal Costanza <····@p-cos.net> wrote:
>
> OK, but Xah's complaint was about syntax, not about semantics.
Agreed. I was just trying to add somethign substantive since I think
we both agree his complaing is without merit :-)
Dan Bensen <··········@cyberspace.net> writes:
> Just to make this slightly shorter, most nonLispers
> seem to like concise syntax, so they might prefer
> 5 => 1+ => square => print
> which in Lisp can (and sort of has to) be written even
> more concisely as
> (=> 5 1+ square print)
>
> (defmacro => (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(funcall #',func ,expr)))))
>
> (defun echo-sqrt ()
> (write-string "Enter number to be sqrt'd: ")
> (finish-output)
> (=> (read-line)
> parse-integer
> sqrt
> write-to-string
> write-line))
I am still learning macros, so I wanted to make sure I understand this
one. I have a question: could one write it as
(defmacro my-=> (&rest forms)
(let ((expr (car forms)))
(dolist (func (cdr forms) expr)
(setf expr `(,func ,expr)))))
ie without the funcall? I tried and it seems to work, eg
(=> 5 1+ (lambda (x) (* 2 x)))
(my-=> 5 1+ (lambda (x) (* 2 x)))
both give 12. But I am wondering if there is a difference I haven't
noticed, or if it is simply a matter of style.
Thanks,
Tamas
--
Posted via a free Usenet account from http://www.teranews.com
Tamas Papp wrote:
> Dan Bensen <··········@cyberspace.net> writes:
>> (defmacro => (&rest forms)
>> (let ((expr (car forms)))
>> (dolist (func (cdr forms) expr)
>> (setf expr `(funcall #',func ,expr)))))
> I have a question: could one write it as
> (defmacro my-=> (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(,func ,expr)))))
> ie without the funcall? I tried and it seems to work
Oops.
> I am wondering if there is a difference I haven't
> noticed, or if it is simply a matter of style.
No, I just had other things on my mind at the time.
For one thing, I was surprised that the macro didn't
need any gensyms, and also, I was having trouble with
another example that wasn't working right. Thanks for
pointing that out.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen <··········@cyberspace.net> writes:
> Tamas Papp wrote:
>> Dan Bensen <··········@cyberspace.net> writes:
>>> (defmacro => (&rest forms)
>>> (let ((expr (car forms)))
>>> (dolist (func (cdr forms) expr)
>>> (setf expr `(funcall #',func ,expr)))))
>
>> I have a question: could one write it as
>> (defmacro my-=> (&rest forms)
>> (let ((expr (car forms)))
>> (dolist (func (cdr forms) expr)
>> (setf expr `(,func ,expr)))))
>> ie without the funcall? I tried and it seems to work
>
> Oops.
>
>> I am wondering if there is a difference I haven't
>> noticed, or if it is simply a matter of style.
>
> No, I just had other things on my mind at the time.
> For one thing, I was surprised that the macro didn't
> need any gensyms, and also, I was having trouble with
> another example that wasn't working right. Thanks for
> pointing that out.
>
> --
> Dan
> www.prairienet.org/~dsb/
Dear Pascal and Dan,
Thank you for your answers -- I wasn't trying to split hairs, I just
try to understand people's code so that I can improve mine.
Tamas
--
Posted via a free Usenet account from http://www.teranews.com
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5ac6g6F2o20hdU2@mid.individual.net>
Tamas Papp wrote:
> Dan Bensen <··········@cyberspace.net> writes:
>
>> Just to make this slightly shorter, most nonLispers
>> seem to like concise syntax, so they might prefer
>> 5 => 1+ => square => print
>> which in Lisp can (and sort of has to) be written even
>> more concisely as
>> (=> 5 1+ square print)
>>
>> (defmacro => (&rest forms)
>> (let ((expr (car forms)))
>> (dolist (func (cdr forms) expr)
>> (setf expr `(funcall #',func ,expr)))))
>>
>> (defun echo-sqrt ()
>> (write-string "Enter number to be sqrt'd: ")
>> (finish-output)
>> (=> (read-line)
>> parse-integer
>> sqrt
>> write-to-string
>> write-line))
>
> I am still learning macros, so I wanted to make sure I understand this
> one. I have a question: could one write it as
>
> (defmacro my-=> (&rest forms)
> (let ((expr (car forms)))
> (dolist (func (cdr forms) expr)
> (setf expr `(,func ,expr)))))
>
> ie without the funcall? I tried and it seems to work, eg
>
> (=> 5 1+ (lambda (x) (* 2 x)))
> (my-=> 5 1+ (lambda (x) (* 2 x)))
>
> both give 12. But I am wondering if there is a difference I haven't
> noticed, or if it is simply a matter of style.
Dan modified my code, so I am to blame for the original one. The code
was a first throw at adding infix notation for pipes to Lisp, I haven't
iterated carefully over the code. Yes, the funcall is superfluous here.
Good catch.
I wouldn't be surprised if there weren't other issues with the code. Tim
hinted at a valid semantic issue, for example.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Xah Lee <···@xahlee.org> writes:
> There are some others in this thread, which are so hateful, fucking
> full of the ugliness of humanity. The replies from Markus E Leypold is
> a prime example. I wonder, outside of newsgroups, if he is just a
> sophomoron at college.
Ohoh! Look -- I just found that embedded in so much rubbish that I
actually missed it the first time. Actually thank you for the
feedback, Xah: I must really hurt you some to earn a personal
mentioning, and that, admittedly was the purpose, albeit only an
intermediate one. The primary purpose was to achieve a change in you
incontinent posting behaviour (more a disorder), but that has
failed. Animals learn from pain, you're resistant. I wonder ...
Regards -- Markus
Pascal Costanza wrote:
> Leave them alone - they are happy with their choice.
No. No, they aren't. The Lisp community are actually more interested in
other languages than almost all other programming language communities.
This is why I continue to post in c.l.l, because it garners a lot of
interest in my work from the many Lisp users who are still looking for
something better.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 5, 9:35 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Pascal Costanza wrote:
> > Leave them alone - they are happy with their choice.
>
> No. No, they aren't. The Lispcommunity are actually more interested in
> other languages than almost all other programming language communities.
>
> This is why I continue to post in c.l.l, because it garners a lot of
> interest in my work from the many Lispusers who are still looking for
> something better.
You are abusing your postings here for your commercial purposes.
Commercial
purposes which are off-topic in comp.lang.lisp.
I'm also interested in software engineering issues (including
programming language). If I would be interested in your F# offerings
I can read about them in other mailing lists or usenet groups which
may be more
suitable (actually I'm not interested in your offerings, thanks).
Most readers of comp.lang.lisp who are interested in other
programming languages are reading
those other newsgroups and mailing lists too. They don't get their
C/Haskell/... knowledge from comp.lang.lisp.
Face it, your postings about F# and your F#-related business are
completely off-topic
in comp.lang.lisp.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Dear Rainer Joswig,
You wrote to Jon: «... You are abusing your postings here for your
commercial purposes. Commercial purposes which are off-topic in
comp.lang.lisp ...Face it, your postings about F# and your F#-related
business are completely off-topic in comp.lang.lisp.»
I'm a lisp programer, and I've been reading comp.lang.lisp since 1998.
I love lisp. I don't know Jon, but recent reading of his numberous
posts, i find it every interesting and helpful. In particular, his
knowledge about other functional languages, even though i am not
familiar with them and probably will not study them in the near
future. I see no commercialism what-so-ever. I find your accusations
close to libel.
I respect knowledge, and love.
You, Rainer Joswig, your post is off topic and persecuting. This
annoys me greatly. I have seen you had fights with other
comp.lang.lisp dwellers here exchanging vitriol. So, don't fucking
posing like a saint about expressions you don't agree with.
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> I'm a lisp programer, and I've been reading comp.lang.lisp since 1998.
> I love lisp. I don't know Jon, but recent reading of his numberous
> posts, i find it every interesting and helpful. In particular, his
> knowledge about other functional languages, even though i am not
> familiar with them and probably will not study them in the near
> future.
Thank you. I think you are in the majority here.
I was discussing the reason for this recently. Essentially, people's choice
of programming language or platform is very similar to a choice of
religion. I find the ensuing hatred fascinating. Stating that Lisp's
parentheses are a good thing is like posting "christians kill more people
than muslims in the name of God" on alt.religion.
When I make a statement like "this trivial symbolic rewriter is difficult,
tedious, error-prone and slow when implemented in Lisp", it doesn't matter
to everyone that I can back it up with overwhelming evidence. There are
always a few people who reply with progressively more ridiculous comments
simply to try to fight the Lisp corner. Generally this descends into a
plague of ad-hoc, informally specified and error-prone macros
reimplementing half of ML.
I think it is interesting that c.l.lisp is notorious for this kind of
behaviour but is simultaneously filled with the more fickle programmers
wanting to try more modern languages than any other newsgroup. Perhaps
the "bible bashing" Lispers drive them away?
Either way, the makeup of c.l.lisp is very unusual.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 6, 12:02 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Xah Lee wrote:
> > I'm a lisp programer, and I've been reading comp.lang.lisp since 1998.
> > I love lisp. I don't know Jon, but recent reading of his numberous
> > posts, i find it every interesting and helpful. In particular, his
> > knowledge about other functional languages, even though i am not
> > familiar with them and probably will not study them in the near
> > future.
>
> Thank you. I think you are in the majority here.
I find you're idea of majority quite interesthing. It seems that
onlyone who finds you interesthing and helpful is Xah Lee (Did i
missed somebody else?) the rest of the people here disagree, or think
that you're idot or that someone (Microsoft) is paying you to speak BS
(like I do) .
In article <························@n59g2000hsh.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
> Dear Rainer Joswig,
>
> You wrote to Jon: «... You are abusing your postings here for your
> commercial purposes. Commercial purposes which are off-topic in
> comp.lang.lisp ...Face it, your postings about F# and your F#-related
> business are completely off-topic in comp.lang.lisp.»
>
> I'm a lisp programer, and I've been reading comp.lang.lisp since 1998.
You are what? A Lisp programmer? You are joking, right?
Reading comp.lang.lisp does not make you a Lisp programmer.
Writing Lisp programs would do.
> I love lisp. I don't know Jon, but recent reading of his numberous
> posts, i find it every interesting and helpful. In particular, his
> knowledge about other functional languages, even though i am not
> familiar with them and probably will not study them in the near
> future. I see no commercialism what-so-ever. I find your accusations
> close to libel.
Just recently he was advertising his F# business.
See for example this message:
<························@ptn-nntp-reader02.plus.net>
from Tue, 17 Apr 2007 13:36:42 +0100.
>
> I respect knowledge, and love.
>
> You, Rainer Joswig, your post is off topic and persecuting. This
> annoys me greatly. I have seen you had fights with other
> comp.lang.lisp dwellers here exchanging vitriol. So, don't fucking
> posing like a saint about expressions you don't agree with.
No surprise. Your own cross-postings are mostly off-topic to
comp.lang.lisp. It's not that I'm not reading them
sometimes, but they are, so, off-topic...
Unfortunately, if your postings here are on-topic,
they are also mostly full of misunderstandings and a total
lack of imagination (just a hint, check out pipes
in SCSH). You can't be a LIsp programmer... no way.
>
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
--
http://lispm.dyndns.org
On May 5, 9:35 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Pascal Costanza wrote:
> > Leave them alone - they are happy with their choice.
>
> No. No, they aren't. The Lisp community are actually more interested in
> other languages than almost all other programming language communities.
>
> This is why I continue to post in c.l.l, because it garners a lot of
> interest in my work from the many Lisp users who are still looking for
> something better.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
As a Lisper I'm very happy with Common Lisp. It's not perfect but
it's THE BEST language I've have a chance to work with. I'm not
learning new languages because of unhappiness with Lisp but because I
want to taste how it feels to do something with another language.
>From my own experience with : GWBasic, QBasic,Pascal,C/C++, C#,
SQL,OCaml, PHP,Delphi & Scheme I find Common Lisp closest to my
natural way of thinking. Currently I'm learning Erlang and later I'm
planning to give a try to Forth. And I certainly don't need you Dr Jon
Harrop to preach what is good for me. You and Xah Lee are just
polluting this group, wasting everybody's time with your rubbish and
insulting a lot of good people. So f*ch off both of you.
cheers
bobi
PS.
I hope this isn't a double post , my former reply didn't show up in
google groups.
On May 4, 5:11 pm, Xah Lee <····@xahlee.org> wrote:
> How Lisp's Nested Notation Limits The Language's Utility
>
> Xah Lee, 2007-05-03
>
> There is a common complain by programers about lisp's notation, of
> nested parenthesis, being unnatural or difficult to read. Long time
> lisp programers, often counter, that it is a matter of conditioning,
> and or blaming the use of "inferior" text editors that are not
> designed to display nested notations. In the following, i describe how
> lisp notation is actually a problem, in several levels.
I think you're wrong, Xah. If the syntax is a problem, why haven't
any alternative syntaxes taken over for s-expressions? I point to
these examples:
M-Expressions (c. 1962)
maplist[x;fn]=[null[x]->NIL;
T->cons [fn[x];maplist [cdr [x];fn]]]
CGOL (c. 1977)
define "CGMAP"(x, inon, disp, typ);
if atom car x or caar x not isin !'(quote function)
or if atom cadar x then typ ne "mapcar" else caadar x ne "LAMBDA"
then (princ typ; let lbd=0, rbd=0; cglist(x, ", ", 0, 0))
else if atom cadar x and typ = "mapcar" then
(cgolprin2(cadar x, lbd, rbd, depth);
princ "["; let lbd=-1, rbd=0;
cglist(cdr x, ", ", 0, 0);
princ "]")
else (printeol;
princ "for ";
for vars on cadr cadar x, argts on cdr x do
(lcprinc car vars;
princ inon;
cgolprin2(car argts, 2, 0, depth+1);
if cdr vars then princ ", ");
princ disp;
let depth = depth+1; printeol;
cglist(cddr cadar x, "; ", 1, 0)) $
Dylan (c. 1990)
define function find-position-and-velocity
(rock :: <rock>, time :: <float>)
=> (position :: <float>, velocity :: <float>)
values(-4.9 * time * time
+ rock.initial-velocity * time
+ rock.initial-position,
-9.8 * time
+ rock.initial-velocity);
end function;
Curl (late 1990s)
{method public {set-size layout:LayoutContext, rect:GRect}:void
{super.set-size layout, rect}
|| match pixmap size with display
let width:int = ((rect.lextent + rect.rextent) / pixel-length) asa
int
let height:int = ((rect.ascent + rect.descent) / pixel-length) asa
int
set self.current-pixmap = {Pixmap width, height, ignore-alpha?
=true}
{self.on-resample}
}
Every year someone comes on comp.lang.lisp and informs us
that it is the parenthesis that are the problem. But in more than
forty years no one has come up with a better alternative, and
it hasn't been for want of trying or lack of imagination.
Joe Marshall wrote:
> I think you're wrong, Xah. If the syntax is a problem, why haven't
> any alternative syntaxes taken over for s-expressions?
They have.
Mathematica uses more conventional syntax to handle expressions:
map[{}, _] := {}
map[{h_, t___}, f_] := Prepend[map[{t}, f], f[h]]
or using the built-in map:
f ·@ x
For example, squaring the terms of a sum:
In:= #^2& ·@ (1 + 3 x + x y)
Out= 1 + 9 x^2 + x^2 y^2
As Xah explained, Mathematica gives you the choice between prefix format
(same properties as Lisp's s-exprs) or more sophisticated syntax. The
latter is far more popular.
OCaml allows you to define infix operators and these can be used to compose
expressions. From the symbolic simplifier example I gave:
let rec ( +: ) f g = match f, g with
| `Q n, `Q m -> `Q (n +/ m)
| `Q (Int 0), e | e, `Q (Int 0) -> e
| f, `Add(g, h) -> f +: g +: h
| f, g -> `Add(f, g)
let rec ( *: ) f g = match f, g with
| `Q n, `Q m -> `Q (n */ m)
| `Q (Int 0), e | e, `Q (Int 0) -> `Q (Int 0)
| `Q (Int 1), e | e, `Q (Int 1) -> e
| f, `Mul(g, h) -> f *: g *: h
| f, g -> `Mul(f, g)
Note that I chose to use infix operators +: and *: to compose expressions. I
could have used prefix syntax but conventional syntax is clearer.
One of the advances made by the F# language (derived from OCaml) is that it
allows operator overloading, so you can use + rather than +: to compose
expressions.
OCaml, MetaOCaml and F# provide quotations, allowing you to generate
expressions from quoted source code.
However, you cannot decompose expressions using a nice syntax:
let rec d f x = match f with
| f + g -> d f x + d g x
| f * g -> f * d g x + g * d f x
| ...
so you must write a macro to extend the pattern matcher in OCaml.
In the future, F# may support overloading infix active patterns (views)
which will provide this functionality from the language itself.
So I think it is fair to say that s-exprs in Lisp have been superceded by
more efficient representations of expressions in most modern FPLs.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 6, 11:45 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> So I think it is fair to say that s-exprs in Lisp have been superceded by
> more efficient representations of expressions in most modern FPLs.
have you noticed this web thing? It's quite fashionable I believe.
Obviously not as widely used as Ocaml or F#, yet. They use this
tagged bracket notation which they claim is quite useful and
universal. It isn't sexprs, quite.
Forgive me for continuing this argument even though it isn't
particularly relevant to Xah's original post.
> Joe Marshall wrote:
> > If the syntax is a problem, why haven't
> > any alternative syntaxes taken over for s-expressions?
On May 6, 3:45 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> They have.
They have? Then where's the argument?
I've been programming in lisp quite recently and I don't recall
an algorithmic syntax. Did I miss something?
> Mathematica uses more conventional syntax to handle expressions:
What does this have to do with lisp?
>
> OCaml allows you to define infix operators and these can be used to compose
> expressions.
What does this have to do with lisp?
>
> So I think it is fair to say that s-exprs in Lisp have been superceded by
> more efficient representations of expressions in most modern FPLs.
This makes no sense. I ask why alternative lisp syntaxes never took
off,
and you tell me about the syntax of unrelated languages.
Joe Marshall wrote:
>> Joe Marshall wrote:
>> > If the syntax is a problem, why haven't any alternative syntaxes taken
>> > over for s-expressions?
>
> I ask why alternative lisp syntaxes never took off,
You asked why "alternative syntaxes never took off". Nothing Lisp specific
so I cited several non-Lisp examples.
If you want a Lisp specific example then I'd say why did closures not take
off in BASIC? I think the answer is that BASIC programmers who wanted
something more learned a better tool...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 7, 3:34 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> >> Joe Marshall wrote:
> >> > If the syntax is a problem, why haven't any alternative syntaxes taken
> >> > over for s-expressions?
>
> > I ask why alternative lisp syntaxes never took off,
>
> You asked why "alternative syntaxes never took off". Nothing Lisp specific
> so I cited several non-Lisp examples.
The thread is about lisp syntax. Marshall even wrote "taken over for
s-expressions", which restricts the domain to languages which had s-
expressions to be taken over for.
Of course, Harrop can't be bothered. He's got a language to flog.
> If you want a Lisp specific example then I'd say why did closures not take
> off in BASIC?
In other words, Harrop isn't even trying to honestly participate.
(BASIC features, or lack thereof, are not Lisp-specific.)
Does Harrop really think that his participation in cll makes folks
more friendly toward F#/OCaml or anything else that he apparently
values?
On May 8, 1:58 am, Andy Freeman <······@earthlink.net> wrote:
> On May 7, 3:34 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Joe Marshall wrote:
> > >> Joe Marshall wrote:
> > >> > If the syntax is a problem, why haven't any alternative syntaxes taken
> > >> > over for s-expressions?
>
> > > I ask why alternative lisp syntaxes never took off,
>
> > You asked why "alternative syntaxes never took off". Nothing Lisp specific
> > so I cited several non-Lisp examples.
>
> The thread is about lisp syntax. Marshall even wrote "taken over for
> s-expressions", which restricts the domain to languages which had s-
> expressions to be taken over for.
>
> Of course, Harrop can't be bothered. He's got a language to flog.
>
> > If you want a Lisp specific example then I'd say why did closures not take
> > off in BASIC?
>
> In other words, Harrop isn't even trying to honestly participate.
> (BASIC features, or lack thereof, are not Lisp-specific.)
>
> Does Harrop really think that his participation in cll makes folks
> more friendly toward F#/OCaml or anything else that he apparently
> values?
OCaml is pretty good language to work with . If I tried OCaml before
Lisp I would probably stayed longer with it . But Lisp makes you feel
rush of adrenaline in your veins that enables you to build complex
things, though you are a lone programmer and you are far from from
a programming guru . Just that warm feeling that you could compete
with big guys , that you're able to learn complex systems in
notime, and you're not just some drop in the ocean is worth learning
lisp. No other language could give you that. Give me something
complex build in any other language and i'll shit my pants. While in
lisp I'll just do it. Like Nike motto : just do it.
cheers
bobi
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <TA%%h.2149$V01.1074@newsfe12.lga>
fireblade wrote:
> OCaml is pretty good language to work with . If I tried OCaml before
> Lisp I would probably stayed longer with it . But Lisp makes you feel
> rush of adrenaline in your veins that enables you to build complex
> things, though you are a lone programmer and you are far from from
> a programming guru . Just that warm feeling that you could compete
> with big guys , that you're able to learn complex systems in
> notime, and you're not just some drop in the ocean is worth learning
> lisp. No other language could give you that. Give me something
> complex build in any other language and i'll shit my pants. While in
> lisp I'll just do it. Like Nike motto : just do it.
Nice rant, but I think you get a little more oomph by hooking your wagon
to the Zen mystique. Nothing against sneakers, mind you, but image is
everything.*
hth, kenny
* Bishop Berkeley, not Andre Agassi
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 8, 4:14 pm, Ken Tilton <····@theoryyalgebra.com> wrote:
> fireblade wrote:
> > OCaml is pretty good language to work with . If I tried OCaml before
> > Lisp I would probably stayed longer with it . But Lisp makes you feel
> > rush of adrenaline in your veins that enables you to build complex
> > things, though you are a lone programmer and you are far from from
> > a programming guru . Just that warm feeling that you could compete
> > with big guys , that you're able to learn complex systems in
> > notime, and you're not just some drop in the ocean is worth learning
> > lisp. No other language could give you that. Give me something
> > complex build in any other language and i'll shit my pants. While in
> > lisp I'll just do it. Like Nike motto : just do it.
>
> Nice rant, but I think you get a little more oomph by hooking your wagon
> to the Zen mystique. Nothing against sneakers, mind you, but image is
> everything.*
>
> hth, kenny
Too much Delphi today I guess .Contrasted with yesterday evening
spent going through Sonya Keene Object Oriented programming in Common
Lisp and after that I watched Abelson & Sussman lecture . The same one
where I stopped going through SICP textbook the Painter .Seeing them
talking make continue .
Beside I never weared Nike , Converse & Lotto are my favourites brands
(yeah Nike bought Converse too )
cheers
bobi
Andy Freeman wrote:
>> If you want a Lisp specific example then I'd say why did closures not
>> take off in BASIC?
>
> BASIC features, or lack thereof, are not Lisp-specific.
Syntax is not Lisp specific.
> Does Harrop really think that his participation in cll makes folks
> more friendly toward F#/OCaml or anything else that he apparently
> values?
We got our last order from a Lisper 2.5hrs ago. So yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 8, 2:00 am, Jon Harrop <····@ffconsultancy.com> wrote:
> We got our last order from a Lisper 2.5hrs ago. So yes.
Wow, that's frightening if it's true. I'm an ex lisp person (to a
large extent: I guess I might program in CL again sometime, but
probably not that soon given time constraints). I might be in the
market for other languages. I spend significant money on software and
tend to work places where I'm responsible for the spending of a good
deal more. But after seeing your behaviour in cll you can be assured
that I will never, ever consider any functional programming language.
I can just do without languages that attract that kind of behaviour.
--tim (and yes, before you respond, that is one reason I don't use CL
so much any more as well.)
On May 8, 2:18 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> On May 8, 2:00 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > We got our last order from a Lisper 2.5hrs ago. So yes.
>
> Wow, that's frightening if it's true. I'm an ex lisp person (to a
> large extent: I guess I might program in CL again sometime, but
> probably not that soon given time constraints). I might be in the
> market for other languages. I spend significant money on software and
> tend to work places where I'm responsible for the spending of a good
> deal more. But after seeing your behaviour in cll you can be assured
> that I will never, ever consider any functional programming language.
> I can just do without languages that attract that kind of behaviour.
>
> --tim (and yes, before you respond, that is one reason I don't use CL
> so much any more as well.)
Don't be so hursh with Dr Harrop, he sold his sould a long time ago.
He's going to hell there's no return for him. Now he want to drag us
all with him so he won't be alone in 9th circle. Read details in
http://www.av1611.org/hell.html
On May 8, 2:18 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> Wow, that's frightening if it's true. I'm an ex lisp person (to a
> large extent: I guess I might program in CL again sometime, but
> probably not that soon given time constraints).
> [...]
> But after seeing your behaviour in cll you can be assured that I
> will never, ever consider any functional programming language. I
> can just do without languages that attract that kind of behaviour.
>
> --tim (and yes, before you respond, that is one reason I don't use CL
> so much any more as well.)
Out of curiosity, what are those reasons? (Or did you list them
before?)
My personal observations are that post-AI Lisp programmers are pretty
friendly. The earlier ones are a mixed bag of nuts. ;)
I've worked closely with a couple companies which use Lisp heavily.
* One billed itself as an AI company, but it was in many important
respects the most incompetent and antisocial company I've had
the pleasure to work with. When I demoed their product to
friends, they literally found it ridiculous.
Nevertheless, the product may possibly work in a couple limited
domains, for the same reason that people seem to make money off
poorly reimplemented examples from the Java Cookbook.
I terminated my relationship with them once I realized they were
having me use a pirated edition of LispWorks, losing their
ability to compensate me nicely, and the things they asked me to
do with Lisp were less interesting. Had they been decent human
beings, I no doubt would have helped them regardless of
compensation.
(I eventually found out they previously used the services of
another Lisp programmer... and he was far less polite about
their problems than I was. They actually believe he subscribed
them to spam lists after they parted ways, though they can't
prove it.)
* The other one seems to be about as reasonable and competent as
any other company I've dealt with. Maybe I have not yet detected
their dark side, but they seem like good people. Competent too.
Certainly not an AI company, though people there have read
Norvig's PAIP and so forth.
Tayssir
On May 8, 2:35 pm, Tayssir John Gabbour <············@googlemail.com>
wrote:
> > --tim (and yes, before you respond, that is one reason I don't use CL
> > so much any more as well.)
>
> Out of curiosity, what are those reasons? (Or did you list them
> before?)
Well, what I meant was something like this:
I'm considering using tool x (not particularly Lisp, let's say, as a
neutral-in-context example a particular MTA). Just to repeat: this is
a *neutral* example, I am *not* talking about Lisp people below
(though of course some of these cases do apply to F#).
So I do some technical evaluation and look at the cost and whether it
does what we want. All fine.
I'm anticipating needing advice and so on about it, so I go and have a
look at the uathor's website and any newsgroups/mailing lists.
And lo, I discover one or more of:
* The person I will likely be contacting for support is some kind of
fractious academic with chips on all his shoulders who spends half his
time being rude about the competition
* The person I will likely be contacting for support spends his time
trolling in newsgroups, possibly trying to attract sales.
* The person I will likely be contacting for support spends his time
being deliberately and needlessly offensive to people in newsgroups.
* The person I will likely be contacting for support clearly does not
know what he is talking about.
Any of these things are sufficient to put me off (and I imagine most
potential users).
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <6m00i.2165$V01.1663@newsfe12.lga>
Tim Bradshaw wrote:
> On May 8, 2:00 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
>
>>We got our last order from a Lisper 2.5hrs ago. So yes.
>
>
> Wow, that's frightening if it's true. I'm an ex lisp person (to a
> large extent: I guess I might program in CL again sometime, but
> probably not that soon given time constraints). I might be in the
> market for other languages. I spend significant money on software and
> tend to work places where I'm responsible for the spending of a good
> deal more. But after seeing your behaviour in cll you can be assured
> that I will never, ever consider any functional programming language.
> I can just do without languages that attract that kind of behaviour.
>
> --tim (and yes, before you respond, that is one reason I don't use CL
> so much any more as well.)
>
Abandoning something wonderful because of who else uses it makes perfect
sense. Why did I give up sex? One word: Joey Buttafucco.
hth,kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 8, 4:06 pm, Ken Tilton <····@theoryyalgebra.com> wrote:
> Abandoning something wonderful because of who else uses it makes perfect
> sense. Why did I give up sex? One word: Joey Buttafucco.
Not who else uses it: who *I might plausibly have to interact with as
a result of using it*. I will refrain from giving the appropriate
variant of your example.
--tim
On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Andy Freeman wrote:
> >> If you want a Lisp specific example then I'd say why did closures not
> >> take off in BASIC?
>
> > BASIC features, or lack thereof, are not Lisp-specific.
>
> Syntax is not Lisp specific.
Wowsers.
It's a thread about *Lisp* syntax, emphasis added. When asked why his
examples don't have anything to do with lisp, Harrop says that his
lisp specific example would be BASIC features, or lack thereof. When
told that BASIC also isn't lisp, he retreats to a non sequitor.
Yup, that's just the sort of attention to detail that I'd want in a
vendor.
Andy Freeman wrote:
> On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Syntax is not Lisp specific.
>
> Wowsers.
>
> It's a thread about *Lisp* syntax, emphasis added.
Apparently Lisp's syntax can only stand up to comparison against Lisp syntax
and not anything else, e.g. the better syntaxes I cited.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 8, 10:53 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Andy Freeman wrote:
> > On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> Syntax is not Lisp specific.
>
> > Wowsers.
>
> > It's a thread about *Lisp* syntax, emphasis added.
>
> Apparently Lisp's syntax can only stand up to comparison against Lisp syntax
> and not anything else, e.g. the better syntaxes I cited.
The question was why no language with s-expressions has abandoned them
for supposedly superior alternatives. Harrop's examples didn't have s-
expressions.
At least he's not defending the absence of closures in BASIC as being
a substantive comment on Lisp, yet.
Andy Freeman wrote:
> At least he's not defending the absence of closures in BASIC as being
> a substantive comment on Lisp, yet.
In a parallel universe, there are people arguing on comp.lang.basic that the
fact that closures were never backported and widely adopted by BASICers is
overwhelming evidence that closures are a ridiculous waste of time, totally
ill suited to programming in the "real world".
The BASICers peel themselves away from quoting Greenspun to a 6502 assembler
programmer to kindly explain that the reason no-closures was not widely
adopted elsewhere is that few people have enlightened knowledge of the
BASIC programming language and the amazing benefits that not having decent
closures provides. Anyway, there is nothing wrong with not having anything
at all because you can always create an ad-hoc, informally specified and
bug-ridden implementation of half of anything else yourself in BASIC.
Indeed, this is recommended practice for the dwindling number of people who
are forced to program in BASIC by incestuous academics.
When someone is outrageous enough to suggest that maybe the vast majority of
non-BASIC programmers do actually know BASIC (after all, everyone is taught
BASIC at uni, in the "history" course) but choose not to use it because it
blows chunks like the kid of the exorcist, before pointing out that
closures are now the defacto standard (even found in C# and Java!), that
person is ritualistically beaten with words (well, a mix of hillbilly and
valley girl) and told that they can only compare BASIC's closures to
BASIC's closures.
Meanwhile, a deranged student mumbles something about Microsoft's spies that
reminds him of a old documentary factoid:
http://www.adequacy.org/public/stories/2001.12.2.42056.2147.html
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5adbibF2o2288U1@mid.individual.net>
Jon Harrop wrote:
> Andy Freeman wrote:
>> On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>> Syntax is not Lisp specific.
>> Wowsers.
>>
>> It's a thread about *Lisp* syntax, emphasis added.
>
> Apparently Lisp's syntax can only stand up to comparison against Lisp syntax
> and not anything else, e.g. the better syntaxes I cited.
...but that is an old hat.
To cite from John McCarthy's "History of Lisp" from 1979 [1]:
"The unexpected appearance of an interpreter tended to freeze the form
of the language, and some of the decisions made rather lightheartedly
for the ``Recursive functions ...'' paper later proved unfortunate.
These included the COND notation for conditional expressions which leads
to an unnecessary depth of parentheses, and the use of the number zero
to denote the empty list NIL and the truth value false. Besides
encouraging pornographic programming, giving a special interpretation to
the address 0 has caused difficulties in all subsequent implementations.
"Another reason for the initial acceptance of awkwardnesses in the
internal form of LISP is that we still expected to switch to writing
programs as M-expressions. The project of defining M-expressions
precisely and compiling them or at least translating them into
S-expressions was neither finalized nor explicitly abandoned. It just
receded into the indefinite future, and a new generation of programmers
appeared who preferred internal notation to any FORTRAN-like or
ALGOL-like notation that could be devised."
This refers to events around the end of the 1950's / beginning of the
1960's.
The project that I am aware of that is closest to bringing the same
level of syntactic flexibility as Lisp with a more "traditional" syntax
is the Intentional Programming approach devised by Microsoft, but they
don't seem to be getting anywhere (except to outer space, that is. ;)
Pascal
[1] http://www-formal.stanford.edu/jmc/history/lisp/lisp.html
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
+---------------
| Jon Harrop wrote:
| To cite from John McCarthy's "History of Lisp" from 1979 [1]:
|
| "The unexpected appearance of an interpreter tended to freeze the form
| of the language, and some of the decisions made rather lightheartedly
| for the ``Recursive functions ...'' paper later proved unfortunate.
| These included the COND notation for conditional expressions which leads
| to an unnecessary depth of parentheses, and the use of the number zero
| to denote the empty list NIL and the truth value false. Besides
| encouraging pornographic programming, giving a special interpretation to
| the address 0 has caused difficulties in all subsequent implementations.
+---------------
Note that equating of 0 with NIL is *not* necessary in current
implementations. For example, in CMUCL-19c under either FreeBSD or
Linux, the pointer representation of NIL happens to be 0x28f0000b(!):
cmu> (kernel:get-lisp-obj-address nil)
671088651
cmu> (format nil "0x~x" *)
"0x2800000B"
cmu> (logand ** 7)
3
cmu> (list x86:list-pointer-type x86:other-pointer-type)
(3 7)
cmu>
Though, since CL requires that NIL be *both* a LIST and a SYMBOL,
there still *is* a bit of magic going on here: that 0x28f0000b
descriptor value can be interpreted as both a cons cell and a
symbol struct. The "magic" is that while the "lowtag" (low three bits)
of the NIL pointer denotes that it is a cons -- which means that if
you subtract X86:LIST-POINTER-TYPE (3) from it you get the address
of a pair of NILs [car & cdr at 0x28f00008 & 0x28f0000c, resp.] --
it is *also* true that if you subtract X86:OTHER-POINTER-TYPE (7)
from it [symbols are "other-pointers"] you get the address of the
*symbol* NIL [which has that above-mentioned pseudo-cons buried in it
in the "value" and "hash" cells of the symbol]. [And, yes, that means
that the NIL list/symbol heap object *must* be placed at a specific
location in CMUCL's virtual memory. (Some of us consider that a bug.)]
But since you need to check for NIL explicitly *anyway* pretty much
everywhere you might have a LIST or a SYMBOL, another equally-simple
method one might choose would be to simply assign some small constant
"immediate" pointer-value to NIL ["immediates" being Lisp objects for
which the entire object is specified in the bit pattern of its "pointer",
sometimes used for chars, unbound-markers, EOF, etc.]. Since x86_64
has 32-bit immediate compares, that representation would be fairly
cheap on that architecture.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Jon Harrop <···@ffconsultancy.com> writes:
> Andy Freeman wrote:
>> On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>> Syntax is not Lisp specific.
>>
>> Wowsers.
>>
>> It's a thread about *Lisp* syntax, emphasis added.
>
> Apparently Lisp's syntax can only stand up to comparison against Lisp syntax
> and not anything else, e.g. the better syntaxes I cited.
I wonder how many experienced Lisp programmers have switched to a
different language, citing Lisp syntax as the main reason for the
switch?
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <PKn0i.8$9C4.2@newsfe12.lga>
Rob St. Amant wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>
>
>>Andy Freeman wrote:
>>
>>>On May 7, 6:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>>
>>>>Syntax is not Lisp specific.
>>>
>>>Wowsers.
>>>
>>>It's a thread about *Lisp* syntax, emphasis added.
>>
>>Apparently Lisp's syntax can only stand up to comparison against Lisp syntax
>>and not anything else, e.g. the better syntaxes I cited.
>
>
> I wonder how many experienced Lisp programmers have switched to a
> different language, citing Lisp syntax as the main reason for the
> switch?
I wonder how many Lisp noobs gave up on it because they just could not
get the hang of that damn syntax.
:)
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 7, 3:34 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> >> Joe Marshall wrote:
> >> > If the syntax is a problem, why haven't any alternative syntaxes taken
> >> > over for s-expressions?
>
> > I ask why alternative lisp syntaxes never took off,
>
> You asked why "alternative syntaxes never took off". Nothing Lisp specific
> so I cited several non-Lisp examples.
Huh? This thread is called ``How Lisp's Nested Notation Limits The
Language's Utility Options''. I embedded a paragraph from Xah which
starts ``There is a common complain by programers about lisp's
notation, of nested parenthesis, being unnatural or difficult to
read.'' I then mentioned M-expressions (the original Lisp syntax),
CGOL (an alternative Lisp syntax), Dylan (a language with a strong
lisp heritage that abandoned the s-expression syntax), and Curl (a
language with a strong lisp heritage that replaced parens by curly
braces). Most people know I'm a lisp hacker, too.
What on earth did you think I was talking about?!
> If you want a Lisp specific example then I'd say why did closures not take
> off in BASIC? I think the answer is that BASIC programmers who wanted
> something more learned a better tool...
Am I missing something here? What does BASIC have to do with Lisp?
What are you smoking, dude?
Joe Marshall wrote:
> What on earth did you think I was talking about?!
Syntax popularity.
> What does BASIC have to do with Lisp?
It also sucks?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <dLT%h.1052$AI5.468@newsfe12.lga>
Jon Harrop wrote:
> Joe Marshall wrote:
>
...
>
>
>>What does BASIC have to do with Lisp?
>
>
> It also sucks?
>
Well, so much for the marketing push into the fertile land of Lisp
users. Don't feel bad, I could not even sell these yobbos on a /Lisp/
library. And don't forget how warmly they embraced Dylan.
I understand the concept (Lisp is close enough that you might pull
people over) but that also means it is a great language you are trying
to drag them from, so... yer gonna need a bigger tractor.
You might try looking in the other direction for subscribers, people
using something useless and horrible and utterly unlike F#.
hth,kxo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 8, 7:19 am, Ken Tilton <····@theoryyalgebra.com> wrote:
> Jon Harrop wrote:
> > Joe Marshall wrote:
>
> ...
>
> >>What does BASIC have to do with Lisp?
>
> > It also sucks?
>
> Well, so much for the marketing push into the fertile land of Lisp
> users. Don't feel bad, I could not even sell these yobbos on a /Lisp/
> library.
You don't have to sell anything good, if you have a quality product
just make it available and people will look for it by themself. Nobody
pushed me to use Celtk, Hunchentoot,CLSQL or CL-WHO I found their
quality myslef ( with some pointers, Pointers not propaganda). Now
I'm interested in Cells & cl-opengl. Good staff will stand the test of
time.
Cells is little bit ahead of it's time .For my modest needs I could go
on with pure common -lisp , but it's good to have a quality tool in
your toolbox.
jt
On 2007-05-08 06:19:04 +0100, Ken Tilton <···@theoryyalgebra.com> said:
> I understand the concept (Lisp is close enough that you might pull
> people over) but that also means it is a great language you are trying
> to drag them from, so... yer gonna need a bigger tractor.
For those old enough to remember, this was pretty much the Dylan
approach: pick another minority language (Lisp again) and try
vigourously to attract users from it, while annoying other users.
Ignore the real target audience (C++ then, Java now). Later, die.
--tim
In article <·····················@news.demon.co.uk>,
Tim Bradshaw <···@tfeb.org> wrote:
> On 2007-05-08 06:19:04 +0100, Ken Tilton <···@theoryyalgebra.com> said:
>
> > I understand the concept (Lisp is close enough that you might pull
> > people over) but that also means it is a great language you are trying
> > to drag them from, so... yer gonna need a bigger tractor.
>
> For those old enough to remember, this was pretty much the Dylan
> approach: pick another minority language (Lisp again) and try
> vigourously to attract users from it,
even worse: implementors.
> while annoying other users.
> Ignore the real target audience (C++ then, Java now). Later, die.
Though the initial thing was way cool. If it had been
released, a few things would be different. I'm thinking of
the then new Lisp operating system that was written
at Apple called 'Bauhaus'. The language was 'Ralph',
later changed to 'Dylan'. Ralph was Scheme + CLOS.
Checkout some memories from Mikel Evins:
http://lispm.dyndns.org/lisp/mikel-evins-on-newton.text
Sigh...
>
> --tim
--
http://lispm.dyndns.org
On May 8, 1:02 pm, Rainer Joswig <······@lisp.de> wrote:
> The language was 'Ralph', later changed to 'Dylan'. Ralph was Scheme + CLOS.
`Barf' and `Hurl' were taken?
On 2007-05-08 21:02:18 +0100, Rainer Joswig <······@lisp.de> said:
> Though the initial thing was way cool. If it had been
> released, a few things would be different.
Yes, I have nothing against even the Dylan that did make it out as a
language. I just think the worst possible battleground and the worst
possible opponents, causing maximal damage to both languages and
achieving nothing.
(Harlequin's extraordinary delay in shipping anything at all can not
have helped.)
Jon Harrop <···@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > What on earth did you think I was talking about?!
>
> Syntax popularity.
>
So what? Popularity is not a measure of goodness.
2007-05-06
«I think you're wrong, Xah. If the syntax is a problem, why haven't
any alternative syntaxes taken over for s-expressions? I point to
these examples:»
Do you know how fanatics are blind?
For example, there are Christians, and there are Islamics. Doesn't
matter what you say, what logic, what rationality, what patience, what
evidence, for vast majority of these people, God of their variety will
exist, and will be the only type.
Fanatics are fanatics because they lost their rationality on the
subject. They simply have the need to believe. (other examples in the
computing industry include: Mac fanatics, unix fuckheads (and now
Linux), OpenSource fuckheads.)
My article, is not titled “The stupidity of Lisp Syntax”. Nor “Lisp's
got syntax problems”. Nor, “The moronicity of Common Lisp fuckheads”.
The title is “How Lisp's Nested Notation Limits The Language's
Utility”.
Note that it says “How”, meaning, the article is a exposition. Then,
it says “Nested Notation”. And, it “limits”. Limit what? “Limits the
language's utility”.
In the article, 3 itemized issues are mentioned. I don't think i
should hold each lisper's hand to go thru the article sentence by
sentence. You can eye the article with built-in Common Lisp prejudice
and come off not reading anything, like basically all lispers who
cried in pain here. These lispers, basically, saw the article, skimmed
it, felt the wound, panics, reactionarily thinking to themselves “O!
Another Imperative Moron who can't get used to parens!”, and then like
a gaggle of ducks, all quack about how sexp is just fine and i'm a
“troll”.
Joe, i know you are seasoned lisper, and you love lisp. Me too. (But
i'm getting stronger sense everyday that Common Lispers, at least as
so exhibited in comp.lang.lisp are all motherfuckers, the saboteurs of
the lisp's health.)
In the article, i gave 3 issues. I do not think any lisper can
honestly disagree with any one of them. Note that, let me emphasize
and repeat again here, the conclusion is not: “lisp's syntax is fucked
and needs change”.
(see also my reply to Pascal Costanza, i quote here:
(Try, perhaps, learn to calm down yourself. You are not under attack.
Lisp the language, is not under attack by my essay. My article,
although cogently detailed why lisp syntax is a serious problem at
several levels, it does not mean that, it is “no good” in some
absolute way. Also, it is far better, then essentially all imperative
language's syntaxes. Even, one can logically agree with my article,
and remain positive, because although lisp perhaps reduce the use of
function sequencing, but that by itself is not necessarily a very bad
thing. Because, function sequencing (aka chaining), although a very
important paradigm, is not necessarily the only way to program, nor
the only way for functional programing. Consider, even today in the
light of OOP. And Common Lisp, in particular, isn't all that much
concerned about purity of functional programing anyway. So logically,
from this perspective or argument, my essay isn't a damning
certificate.)
(I'm really sorry i have to say the above paragraph, as if like a pat
on the back to some crying pussies. But the juvenility, sensitivity,
ignorance, and stupidity, as shown in the responses in this thread,
made me. ) )
Joe wrote:
«Every year someone comes on comp.lang.lisp and informs us that it is
the parenthesis that are the problem.»
Huh? What you wrote above, has nothing to do with my essay. It has to
do with Common Lisping fuckhead's nagging toothache.
«But in more than forty years no one has come up with a better
alternative, and it hasn't been for want of trying or lack of
imagination. »
What about Logo? Dylan? Arc? Mathematica? And the Scheme Lisp's coming
standard, the R6RS, introducing [] {} and other syntaxes that breaks
the nested paren. (note: this is mentioned in the article)
Also, in the article, i mentioned, that lisp syntax itself, contains
several _ad hoc_ syntax sugars for the purpose of reducing nested
parenthesis. This, for anyone not prejudiced, who put thought into
reading the article, might suggest a argument that too many nested
parens is considered a problem by the grand daddies of lisp founder
themselves. When you code lisp tonight, why don't you aways use
“(quote ...)” instead of “'”, hum?
As to why, Common Lisp, didn't change its syntax away from parens...
well... with all the Common Lisp fuckheads in hostile denial as
exhibited in this thread, and the stale air hold by these old lispers
new fanatical recruits, how's any change, if necessary, ever gonna
begin?
A prosperous society needs open mind and open discussion. The lisper
fuckheads, as exhibited in this thread, have been unreasonable and
persecuting to criticism. I believe, many lisp's problems,
(specifically, problems of Common Lisp today), its stagnation, is due
to these fuckheads.
Xah
···@xahlee.org
∑ http://xahlee.org/
On May 7, 2:21 pm, Xah Lee <····@xahlee.org> wrote:
> 2007-05-06
>
>
> «But in more than forty years no one has come up with a better
> alternative, and it hasn't been for want of trying or lack of
> imagination. »
>
> What about Logo? Dylan? Arc? Mathematica? And the Scheme Lisp's coming
> standard, the R6RS, introducing [] {} and other syntaxes that breaks
> the nested paren. (note: this is mentioned in the article)
They all failed or vapourware.
>
> As to why, Common Lisp, didn't change its syntax away from parens...
> well... with all the Common Lisp fuckheads in hostile denial as
> exhibited in this thread, and the stale air hold by these old lispers
> new fanatical recruits, how's any change, if necessary, ever gonna
> begin?
I'm new lisper but too old programmer to be called someones recruit. I
've heard about lisp , try it & like it. Offer some good alternative
and people will come to you without torturing them with your long
threads.The languages you offer are known to everybody but this people
still prefer Common Lisp.
>
> A prosperous society needs open mind and open discussion. The lisper
> fuckheads, as exhibited in this thread, have been unreasonable and
> persecuting to criticism. I believe, many lisp's problems,
> (specifically, problems of Common Lisp today), its stagnation, is due
> to these fuckheads.
>
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
What do you want to achieve Xah Lee ? People at Common Lisp like
this kind syntax ,I find it little bit odd at first but now halfway
through On Lisp I understand why it has to be like that and I just get
use to it. If you don't find natural just move on pal there's a plenty
of other languages over there , or create your own. Reiterating the
same thing all over and insulting those who are sick of your threads
won't do any good. Why bother with f*ckheads ?
Pet
On May 7, 2:21 pm, Xah Lee <····@xahlee.org> wrote:
> 2007-05-06
>
>
> A prosperous society needs open mind and open discussion. The lisper
> fuckheads, as exhibited in this thread, have been unreasonable and
> persecuting to criticism. I believe, many lisp's problems,
> (specifically, problems of Common Lisp today), its stagnation, is due
> to these fuckheads.
>
> Xah
> ····@xahlee.org
> ∑http://xahlee.org/
A prosperous society needs open mind and open discussion , not an
insults and miles of empty words from people who don't know anything
about the subject. Learn some Lisp before posting more thrash for
something you don't know anything about.
JT
Lisp rules Xah Lee and Jon Harrop suck
·············@gmail.com writes:
> A prosperous society needs open mind and open discussion , not an
> insults and miles of empty words from people who don't know anything
> about the subject. Learn some Lisp before posting more thrash for
> something you don't know anything about.
>
> JT
> Lisp rules Xah Lee and Jon Harrop suck
Imagine someone, who hasn't played a musical instrument and is
apparently tone-deaf, rushing in to a practice session of the NY
Philharmonic and screaming "Morons! You are holding those violins
WRONG!". Later on, he will give them an "Edu Corner" presentation on
why they should be holding the bow with their toes.
Use a news reader, and discover the magic of scoring (L a in gnus).
HTH,
Tamas
--
Posted via a free Usenet account from http://www.teranews.com
On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
> 2007-05-06
>
> jrm wrote:
> «I think you're wrong, Xah. If the syntax is a problem, why haven't
> any alternative syntaxes taken over for s-expressions? I point to
> these examples:»
>
>
> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>
> The title is "How Lisp's Nested Notation Limits The Language's
> Utility".
Point taken. I got distracted.
Joe Marshall <··········@gmail.com> writes:
> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>> 2007-05-06
>>
>> jrm wrote:
>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>> any alternative syntaxes taken over for s-expressions? I point to
>> these examples:�
>>
>>
>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>
>> The title is "How Lisp's Nested Notation Limits The Language's
>> Utility".
>
> Point taken. I got distracted.
Bah! How's utility defined anyway? And if "limitation of utility" (by
syntax) is not a problem (in the syntax) for a language, I don't
know. No, no -- I think xou got that right: Xah is riding on the old(1)
crank train "Lisp has too many parenthesis" and the answer "this has
never been a problem as evidenced by the non-success of alternative
syntaxes" is exactly the right one.
Regards -- Markus
(1) 50 years. Imagine.
"Markus E Leypold"
<·····································@ANDTHATm-e-leypold.de> wrote in
message ···················@hod.lan.m-e-leypold.de...
>
> Joe Marshall <··········@gmail.com> writes:
>
>> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>>> 2007-05-06
>>>
>>> jrm wrote:
>>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>>> any alternative syntaxes taken over for s-expressions? I point to
>>> these examples:�
>>>
>>>
>>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>>
>>> The title is "How Lisp's Nested Notation Limits The Language's
>>> Utility".
>>
>> Point taken. I got distracted.
>
>
> Bah! How's utility defined anyway? And if "limitation of utility" (by
> syntax) is not a problem (in the syntax) for a language, I don't
> know. No, no -- I think xou got that right: Xah is riding on the old(1)
> crank train "Lisp has too many parenthesis" and the answer "this has
> never been a problem as evidenced by the non-success of alternative
> syntaxes" is exactly the right one.
>
Or rather it is problem but no one has been able to find the right answer
yet.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"Malcolm McLean" <·········@btinternet.com> writes:
> "Markus E Leypold"
> <·····································@ANDTHATm-e-leypold.de> wrote in
> message ···················@hod.lan.m-e-leypold.de...
>>
>> Joe Marshall <··········@gmail.com> writes:
>>
>>> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>>>> 2007-05-06
>>>>
>>>> jrm wrote:
>>>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>>>> any alternative syntaxes taken over for s-expressions? I point to
>>>> these examples:�
>>>>
>>>>
>>>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>>>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>>>
>>>> The title is "How Lisp's Nested Notation Limits The Language's
>>>> Utility".
>>>
>>> Point taken. I got distracted.
>>
>>
>> Bah! How's utility defined anyway? And if "limitation of utility" (by
>> syntax) is not a problem (in the syntax) for a language, I don't
>> know. No, no -- I think xou got that right: Xah is riding on the old(1)
>> crank train "Lisp has too many parenthesis" and the answer "this has
>> never been a problem as evidenced by the non-success of alternative
>> syntaxes" is exactly the right one.
>>
> Or rather it is problem but no one has been able to find the right
> answer yet.
There are many problems in "IT" and CS. The parenthises in Lisp aren't
among them. I also wonder that there are regularly more people
complaining about Lisp syntax than about Perl syntax. Shows to me that
syntax must be an acquired taste anyway.
Regards -- Markus
From: Malcolm McLean
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <N4SdnfRem7b6XN_bRVnyvQA@bt.com>
"Markus E Leypold"
<·····································@ANDTHATm-e-leypold.de> wrote in
message ···················@hod.lan.m-e-leypold.de...
>
> "Malcolm McLean" <·········@btinternet.com> writes:
>
>> "Markus E Leypold"
>> <·····································@ANDTHATm-e-leypold.de> wrote in
>> message ···················@hod.lan.m-e-leypold.de...
>>>
>>> Joe Marshall <··········@gmail.com> writes:
>>>
>>>> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>>>>> 2007-05-06
>>>>>
>>>>> jrm wrote:
>>>>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>>>>> any alternative syntaxes taken over for s-expressions? I point to
>>>>> these examples:�
>>>>>
>>>>>
>>>>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>>>>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>>>>
>>>>> The title is "How Lisp's Nested Notation Limits The Language's
>>>>> Utility".
>>>>
>>>> Point taken. I got distracted.
>>>
>>>
>>> Bah! How's utility defined anyway? And if "limitation of utility" (by
>>> syntax) is not a problem (in the syntax) for a language, I don't
>>> know. No, no -- I think xou got that right: Xah is riding on the old(1)
>>> crank train "Lisp has too many parenthesis" and the answer "this has
>>> never been a problem as evidenced by the non-success of alternative
>>> syntaxes" is exactly the right one.
>>>
>> Or rather it is problem but no one has been able to find the right
>> answer yet.
>
> There are many problems in "IT" and CS. The parenthises in Lisp aren't
> among them. I also wonder that there are regularly more people
> complaining about Lisp syntax than about Perl syntax. Shows to me that
> syntax must be an acquired taste anyway.
>
The problem is that parenthesis syntax breaks the rule of three (see
website, 10 rules). If we used a graphical editor to display lists as trees
we have the rule of five, and thus a better visual fix on the grammar, but
many lists would still be too big.
The solution of putting some extra structure using lines and indents seems
to be workable
Here's the first non-trivial bit of code I found rooting at random in recent
posts
(defgeneric to-string (item)
(:documentation "Returns item as a string.")
(:method ((item string))
item)
(:method ((item character))
(string item))
(:method ((item symbol))
(string item))
(:method ((item number))
(write-to-string item))
(:method ((item sequence))
(if (every #'characterp item)
(coerce item 'string)
(error "Sequence item contains non-characters."))))
You see that the author is in fact imposing a rule of three, except in the
last inevitable closing cascade. However it is maybe untypical - he's only
got one condition.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"Malcolm McLean" <·········@btinternet.com> writes:
> "Markus E Leypold"
> <·····································@ANDTHATm-e-leypold.de> wrote in
> message ···················@hod.lan.m-e-leypold.de...
>>
>> "Malcolm McLean" <·········@btinternet.com> writes:
>>
>>> "Markus E Leypold"
>>> <·····································@ANDTHATm-e-leypold.de> wrote in
>>> message ···················@hod.lan.m-e-leypold.de...
>>>>
>>>> Joe Marshall <··········@gmail.com> writes:
>>>>
>>>>> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>>>>>> 2007-05-06
>>>>>>
>>>>>> jrm wrote:
>>>>>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>>>>>> any alternative syntaxes taken over for s-expressions? I point to
>>>>>> these examples:�
>>>>>>
>>>>>>
>>>>>> My article, is not titled "The stupidity of Lisp Syntax". Nor "Lisp's
>>>>>> got syntax problems". Nor, "The moronicity of Common Lisp fuckheads".
>>>>>>
>>>>>> The title is "How Lisp's Nested Notation Limits The Language's
>>>>>> Utility".
>>>>>
>>>>> Point taken. I got distracted.
>>>>
>>>>
>>>> Bah! How's utility defined anyway? And if "limitation of utility" (by
>>>> syntax) is not a problem (in the syntax) for a language, I don't
>>>> know. No, no -- I think xou got that right: Xah is riding on the old(1)
>>>> crank train "Lisp has too many parenthesis" and the answer "this has
>>>> never been a problem as evidenced by the non-success of alternative
>>>> syntaxes" is exactly the right one.
>>>>
>>> Or rather it is problem but no one has been able to find the right
>>> answer yet.
>>
>> There are many problems in "IT" and CS. The parenthises in Lisp aren't
>> among them. I also wonder that there are regularly more people
>> complaining about Lisp syntax than about Perl syntax. Shows to me that
>> syntax must be an acquired taste anyway.
>>
> The problem is that parenthesis syntax breaks the rule of three (see
> website, 10 rules).
Rule(s) of ten: Never make up ten rules, esp. if badly conceived. Thou
shalt not have nine rules besides me for the obvious reason.
I don't know how to break it to you gently: Your rules are more
pretentious than wise or insightful. They are hardly an authority to
which you can refer for argument. And your rule 3 is not about
parenthesis, but about indirection and a pair of parenthesis has in
Lisp has nothing to do with indirection.
Regards -- Markus
"Markus E Leypold"
<·····································@ANDTHATm-e-leypold.de> wrote in
message ···················@hod.lan.m-e-leypold.de...
>
> "Malcolm McLean" <·········@btinternet.com> writes:
>
>> "Markus E Leypold"
>> <·····································@ANDTHATm-e-leypold.de> wrote in
>> message ···················@hod.lan.m-e-leypold.de...
>>>
>>> "Malcolm McLean" <·········@btinternet.com> writes:
>>>
>>>> "Markus E Leypold"
>>>> <·····································@ANDTHATm-e-leypold.de> wrote in
>>>> message ···················@hod.lan.m-e-leypold.de...
>>>>>
>>>>> Joe Marshall <··········@gmail.com> writes:
>>>>>
>>>>>> On May 7, 5:21 am, Xah Lee <····@xahlee.org> wrote:
>>>>>>> 2007-05-06
>>>>>>>
>>>>>>> jrm wrote:
>>>>>>> �I think you're wrong, Xah. If the syntax is a problem, why haven't
>>>>>>> any alternative syntaxes taken over for s-expressions? I point to
>>>>>>> these examples:�
>>>>>>>
>>>>>>>
>>>>>>> My article, is not titled "The stupidity of Lisp Syntax". Nor
>>>>>>> "Lisp's
>>>>>>> got syntax problems". Nor, "The moronicity of Common Lisp
>>>>>>> fuckheads".
>>>>>>>
>>>>>>> The title is "How Lisp's Nested Notation Limits The Language's
>>>>>>> Utility".
>>>>>>
>>>>>> Point taken. I got distracted.
>>>>>
>>>>>
>>>>> Bah! How's utility defined anyway? And if "limitation of utility" (by
>>>>> syntax) is not a problem (in the syntax) for a language, I don't
>>>>> know. No, no -- I think xou got that right: Xah is riding on the
>>>>> old(1)
>>>>> crank train "Lisp has too many parenthesis" and the answer "this has
>>>>> never been a problem as evidenced by the non-success of alternative
>>>>> syntaxes" is exactly the right one.
>>>>>
>>>> Or rather it is problem but no one has been able to find the right
>>>> answer yet.
>>>
>>> There are many problems in "IT" and CS. The parenthises in Lisp aren't
>>> among them. I also wonder that there are regularly more people
>>> complaining about Lisp syntax than about Perl syntax. Shows to me that
>>> syntax must be an acquired taste anyway.
>>>
>> The problem is that parenthesis syntax breaks the rule of three (see
>> website, 10 rules).
>
> Rule(s) of ten: Never make up ten rules, esp. if badly conceived. Thou
> shalt not have nine rules besides me for the obvious reason.
>
> I don't know how to break it to you gently: Your rules are more
> pretentious than wise or insightful. They are hardly an authority to
> which you can refer for argument. And your rule 3 is not about
> parenthesis, but about indirection and a pair of parenthesis has in
> Lisp has nothing to do with indirection.
>
If you think the rules are pretentious then you are not taking them in the
spirit in which they were intended.
Parentheses have everything to do with indirection. Think about how you
would implement a generic list structure.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
From: David Kastrup
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <85lkfwidb2.fsf@lola.goethe.zz>
"Malcolm McLean" <·········@btinternet.com> writes:
> If you think the rules are pretentious then you are not taking them
> in the spirit in which they were intended. Parentheses have
> everything to do with indirection. Think about how you would
> implement a generic list structure.
Thank McCarthy Lisp allows us to write
(+ (* 3 4 5) 6 7)
and does not require us to write
(+ . ((* . (3 . (4 . (5 . nil)))) . (6 . (7 . nil))))
which actually is the same, and properly reflects the underlying
generic list structure.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
> If you think the rules are pretentious then you are not taking them in
> the spirit in which they were intended.
And that would be? I'm not talking them serious, if you mean that, but
I also can't laugh about them. Aaaand they break my ruke of ten! So.
> Parentheses have everything to do with indirection.
Not.
> Think about how you would implement a generic list structure.
What do I care about _Implementation_? I thought we were talking about
syntax.
Regards -- Markus
From: Malcolm McLean
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <sNudncRl6q48R9nbRVnyugA@bt.com>
"Markus E Leypold"
<·····································@ANDTHATm-e-leypold.de> wrote in
message ···················@hod.lan.m-e-leypold.de...
>
>> If you think the rules are pretentious then you are not taking them in
>> the spirit in which they were intended.
>
> And that would be? I'm not talking them serious, if you mean that, but
> I also can't laugh about them. Aaaand they break my ruke of ten! So.
>
Pretentious is a criticism usually applied to artistic works which have the
outward form of great profundity, but are in fact mediocre and derivative. I
am not quite sure what it mean to mean in relation to programming style
rules.
The ten rules are a few psychological observations given a ten rule format,
where the index of each rule also represents the critical value, in order to
make them a bit more interesting and easy to remember.
In fact the rules aren't very tight. For instance the number of items a
person can recognise without counting is about seven. However depending on
conditions and subject you can also obtain other numbers.
They are meant to be little things to remember whilst programming. The
central point is that there are limits to the busy-ness of a good script.
That's all.
>
>> Parentheses have everything to do with indirection.
>
> Not.
>
>> Think about how you would implement a generic list structure.
>
> What do I care about _Implementation_? I thought we were talking about
> syntax.
>
You need to think about this a bit more. What does it mean to indirect, and
what does it mean to have a list of lists or an array of arrays?
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
"Malcolm McLean" <·········@btinternet.com> writes:
> "Markus E Leypold"
> <·····································@ANDTHATm-e-leypold.de> wrote in
> message ···················@hod.lan.m-e-leypold.de...
>>
>>> If you think the rules are pretentious then you are not taking them in
>>> the spirit in which they were intended.
>>
>> And that would be? I'm not talking them serious, if you mean that, but
>> I also can't laugh about them. Aaaand they break my ruke of ten! So.
>>
> Pretentious is a criticism usually applied to artistic works which have the
> outward form of great profundity, but are in fact mediocre and derivative. I
You know, that IS exactly what I intended to express. Since I'm not a
native speaker, I'm glad to hear that i succeeded in getting the
message across.
Regards -- Markus
"Markus E Leypold"
<·····································@ANDTHATm-e-leypold.de> wrote in
message ···················@hod.lan.m-e-leypold.de...
>
> "Malcolm McLean" <·········@btinternet.com> writes:
>
>> "Markus E Leypold"
>> <·····································@ANDTHATm-e-leypold.de> wrote in
>> message ···················@hod.lan.m-e-leypold.de...
>>>
>>>> If you think the rules are pretentious then you are not taking them in
>>>> the spirit in which they were intended.
>>>
>>> And that would be? I'm not talking them serious, if you mean that, but
>>> I also can't laugh about them. Aaaand they break my ruke of ten! So.
>>>
>> Pretentious is a criticism usually applied to artistic works which have
>> the
>> outward form of great profundity, but are in fact mediocre and
>> derivative. I
>
> You know, that IS exactly what I intended to express. Since I'm not a
> native speaker, I'm glad to hear that i succeeded in getting the
> message across.
>
Ah. That explains it. Britian and also America are very chilled countries.
Places like France are not. I wouldn't like to say about Germany.
A Frenchman would set down his rules very seriously and proudly, as a
pattern for all his students to follow. An Englishman would just see that he
has got two rules with numbers attached, and make up other ones to fill out
the list. Then put it on his website for everyone to see.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
In article <························@n59g2000hsh.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
> 2007-05-06
>
> «I think you're wrong, Xah. If the syntax is a problem, why haven't
> any alternative syntaxes taken over for s-expressions? I point to
> these examples:»
>
> Do you know how fanatics are blind?
>
> For example, there are Christians, and there are Islamics. Doesn't
> matter what you say, what logic, what rationality, what patience, what
> evidence, for vast majority of these people, God of their variety will
> exist, and will be the only type.
>
> Fanatics are fanatics because they lost their rationality on the
> subject. They simply have the need to believe. (other examples in the
> computing industry include: Mac fanatics, unix fuckheads (and now
> Linux), OpenSource fuckheads.)
The fanatic is you.
>
> My article, is not titled “The stupidity of Lisp Syntax”. Nor “Lisp's
> got syntax problems”. Nor, “The moronicity of Common Lisp fuckheads”.
>
> The title is “How Lisp's Nested Notation Limits The Language's
> Utility”.
Sure. And it is full of false assumptions written by somebody
who never has written a single line of Common Lisp code.
Why should anyone listen to your false assumptions?
>
> Note that it says “How”, meaning, the article is a exposition. Then,
> it says “Nested Notation”. And, it “limits”. Limit what? “Limits the
> language's utility”.
>
> In the article, 3 itemized issues are mentioned.
And these are wrong.
> I don't think i
> should hold each lisper's hand to go thru the article sentence by
> sentence. You can eye the article with built-in Common Lisp prejudice
> and come off not reading anything, like basically all lispers who
> cried in pain here. These lispers, basically, saw the article, skimmed
> it, felt the wound, panics, reactionarily thinking to themselves “O!
> Another Imperative Moron who can't get used to parens!”, and then like
> a gaggle of ducks, all quack about how sexp is just fine and i'm a
> “troll”.
No, I read it. Example: I saw you pipe example. I saw that you
don't understand what you are talking about.
a|b|c
okay, what is it in Lisp?
First, your ideas are wrong anyway. On first glance.
(c (b (a))) would not achieve the same effect.
Evaluation is inside out and not in parallel.
In Lisp you would write:
(| a b c)
Now | is taken for symbols already. And usually in Lisp
you won't introduce characters, but identifiers it would be:
(pipe a b c)
If there were arguments, you would write:
(pipe (ls)
(grep ".lisp")
(sort))
PIPE would be a macro that transforms this stuff into
the machinery for pipes.
That's so obvious for anybody who has written some Lisp.
Actually SCSH has exactly such a pipe syntax. If you
want to see who you do the usual scripting stuff
in Lisp notation, check out SCSH.
Now comes the interesting part as a task:
write the pipe macro in Common Lisp and report back.
>
> Joe, i know you are seasoned lisper, and you love lisp. Me too. (But
> i'm getting stronger sense everyday that Common Lispers, at least as
> so exhibited in comp.lang.lisp are all motherfuckers, the saboteurs of
> the lisp's health.)
>
> In the article, i gave 3 issues. I do not think any lisper can
> honestly disagree with any one of them. Note that, let me emphasize
> and repeat again here, the conclusion is not: “lisp's syntax is fucked
> and needs change”.
But your idea that it limits the utility is plain wrong.
See the pipe example.
>
> (see also my reply to Pascal Costanza, i quote here:
>
> (Try, perhaps, learn to calm down yourself. You are not under attack.
> Lisp the language, is not under attack by my essay. My article,
> although cogently detailed why lisp syntax is a serious problem at
> several levels, it does not mean that, it is “no good” in some
> absolute way. Also, it is far better, then essentially all imperative
> language's syntaxes. Even, one can logically agree with my article,
> and remain positive, because although lisp perhaps reduce the use of
> function sequencing, but that by itself is not necessarily a very bad
> thing. Because, function sequencing (aka chaining), although a very
> important paradigm, is not necessarily the only way to program, nor
> the only way for functional programing. Consider, even today in the
> light of OOP. And Common Lisp, in particular, isn't all that much
> concerned about purity of functional programing anyway. So logically,
> from this perspective or argument, my essay isn't a damning
> certificate.)
>
> (I'm really sorry i have to say the above paragraph, as if like a pat
> on the back to some crying pussies. But the juvenility, sensitivity,
> ignorance, and stupidity, as shown in the responses in this thread,
> made me. ) )
>
>
> Joe wrote:
> «Every year someone comes on comp.lang.lisp and informs us that it is
> the parenthesis that are the problem.»
>
> Huh? What you wrote above, has nothing to do with my essay. It has to
> do with Common Lisping fuckhead's nagging toothache.
>
> «But in more than forty years no one has come up with a better
> alternative, and it hasn't been for want of trying or lack of
> imagination. »
>
> What about Logo?
Mostly Dead.
> Dylan?
Mostly Dead.
> Arc?
Where?
> Mathematica?
No Lisp.
> And the Scheme Lisp's coming
> standard, the R6RS, introducing [] {} and other syntaxes that breaks
> the nested paren.
[] and {} are just parentheses and optional.
In Common Lisp those characters are available to
the user. You can set them to anything you
like. If you want them to be another set of parentheses?
Easy. Change the readtable for these characters.
Examples where this is already used:
[] for embedded SQL in LispWorks
{} for Xappings in Connection Machine Lisp
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node192.html
Common Lisp has a programmable reader.
You want new parentheses? Five lines.
(defun |[-reader| (stream char)
(declare (ignore char))
(read-delimited-list #\] stream t))
(set-macro-character #\[ #'|[-reader|)
(set-macro-character #\] (get-macro-character #\) nil))
Now you have new parentheses:
CL-USER 11 > [let [[a 1] [b 2]] (+ (sin a) (sin b))]
1.7507684
> (note: this is mentioned in the article)
>
> Also, in the article, i mentioned, that lisp syntax itself, contains
> several _ad hoc_ syntax sugars for the purpose of reducing nested
> parenthesis. This, for anyone not prejudiced, who put thought into
> reading the article, might suggest a argument that too many nested
> parens is considered a problem by the grand daddies of lisp founder
> themselves. When you code lisp tonight, why don't you aways use
> “(quote ...)” instead of “'”, hum?
It is a shorthand notation with very little visual impact.
Common Lisp is not about parentheses for everything.
Common Lisp is about a minimal syntax and a
programmable and extensible reader. It is usual for Common
Lisp programs to add new syntaxes. Common Lisp
tries to get out of the way for those applications and
embedded programming languages as much as possible.
It comes with some defined reader syntax:
" " : strings
#(a b c) : vectors
#c(1 2) : complex numbers
|Foo| : symbols
#| documentation |# : comments
(a b c) : lists
#'foo : (function foo)
'foo : (quote foo)
#*10001 : bit vectors
#xFFAA : hex numbers
`(foo ,bar) : Quasi quotes
and so on...
> As to why, Common Lisp, didn't change its syntax away from parens...
> well... with all the Common Lisp fuckheads in hostile denial as
> exhibited in this thread, and the stale air hold by these old lispers
> new fanatical recruits, how's any change, if necessary, ever gonna
> begin?
You listed yourself the attempts that never went off.
Lisp syntax as it is is simple extremely practical.
>
> A prosperous society needs open mind and open discussion. The lisper
> fuckheads, as exhibited in this thread, have been unreasonable and
> persecuting to criticism. I believe, many lisp's problems,
> (specifically, problems of Common Lisp today), its stagnation, is due
> to these fuckheads.
Write a line of Lisp first.
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
--
http://lispm.dyndns.org
Dear Rainer Joswig fuckface,
Xah Lee wrote:
«How Lisp's Nested Notation Limits The Language's Utility
http://xahlee.org/UnixResource_dir/writ/notations.html
»
A Common Lisp fuckface, Rainer, wrote:
«Sure. And it is full of false assumptions written by somebody who
never has written a single line of Common Lisp code. Why should
anyone listen to your false assumptions?»
The context of my article, is lisp. More specifically, the nested
notation used by lisp. You should not hijack it to mean Common Lisp.
Lisp, as you know, is a family of languages. Broadly, it can include
Logo, Dylan, or even Mathematica. Narrowly, it includes Common Lisp,
Emacs Lisp, and Scheme. The latter group, all employ a somewhat
uniform nested syntax.
Rainer —a Common Lisp fuckface— wrote:
«... Why should anyone listen to your false assumptions?»
Rainer, When did you stop beating your wife?
As to my qualitifications, I think you know well that i'm not some
student or lisp newbie. So, from my point of view, you are simply
fucking with me, and sputtering unreasonable garbage typical of a
newsgroup brawl.
When responding to a article, it is reasonable to know the author's
qualifications. My qualifications in particular for my article, is
openly and easily viewable on my public website http://XahLee.org/ .
However, to quetsion the author's qualitifications in the context of a
newsgroup discussion, like the Rainer fuckface has done, is
unreasonable. Online forum discussions (such as newsgroups), by its
nature, are often anonymous and informal. You can't just arbitrarily
demand authorship and qualifacitons in any argument in the posts. For
example, let me ask you then, what qualifications do you have, in
responding to my criticism?
If you want to press the issue, i can show you my IQ score, my jobs
held, the software i've written, and the measurement of my cock size.
I don't think you can touch me.
What are the gaggle of troll-cryer's qualifications, when they called
me a troll? Do they, say, have a sociology degree or psychiatric
certificate?
Rainer fuckhead wrote:
«No, I read it. Example: I saw you pipe example. I saw that you don't
understand what you are talking about.»
What if i tell you, honestly, you are a fucking moron in relative to
me?
Dear Rainer, yes i mean it. I truely, honestly, in no humor or joking
sense, believe, that when you, in comparison to me, of the abilities,
knowledge, or skill, in the areas of Lisp (not Common Lisp), computing
languages, programing ability, mathematics, critical thinking, fields,
you are a like moron.
Now, perhaps, maybe, you believe the same way about me? How can we
resolve it then? Usually, there are many ways. For example, we can
both take IQ tests. We can also, have a competition in any of the
areas. There are plenty, well-accepted, qualified, ways in judging
skills and knowledge. Alternatively, we can also, have qualified
experts, assess our abilities in particular areas. For example, in the
areas of Math, we could have say, have 10 mathematicians selected at
random, and grill us for an hour... etc. Similarly, we could have
expert, accomplished, computer language designers, assess our
comparative abilities or merits in questions abot languages... and so
on.
In the context of newsgroup discussion, it might be a bit difficult.
Since, we are limited to just what we write. And, there's not gonna be
the energy, or resource, to actually carry out any of the above tests.
Though, it is still possible, to realize to fairly good conclusions,
of whether party A or party B is more qualified or expert in
particular area, in newsgroups. For example, perhaps, we can start to
get serious, and continue our argument. So, your technical arguments
will be countered by mine, and mine by yours. And, eventually, when
this is done for a while, i think it would show, fairly accurately,
whether one party actually know what he is talking about, while the
other party, may lack lustre. (this might be unfair to you, since your
writing ability may be far below me)
The problem now is, that the parties don't necessarily want to
participate in this process. First of all, comparing cock sizes in a
show down is not exactly the purpose of newsgroups. Also, in practice,
each of us has other slackings to do. Further, a party, such as you,
may fear the eventual failure, and as a man, will feel defeated and
ashamed. So, as a stradgy in a power struggle, one might befuddle
one's real intention in participanting in a serious, final show down,
of the participant's qualifications and relative merits.
Are you, as a Common Lisp fuckhead, willing to have a tech show down
with me? I don't have nothing to do all day. For other Common Lisping
fuckheads who has said fucking shits in this thread, i entertain the
possibility of accepting their challenges too.
> In Lisp you would write:
>
> (| a b c)
Dear Rainer, the context is syntax, not semantics. What your Pipe code
shown above, is semantically Composition as i have written in my
article... (i sense some Common Lisp moron will jump my bone here...
any minute now)
I also replied to Kenny using examples from Mathematica, not unix
pipes. Did you read that?
Rainer wrote:
> > What about Logo?
>
> Mostly Dead.
>
> > Dylan?
>
> Mostly Dead.
>
> > Arc?
>
> Where?
>
> > Mathematica?
>
> No Lisp.
>
> > And the Scheme Lisp's coming
> > standard, the R6RS, introducing [] {} and other syntaxes that breaks
> > the nested paren.
>
> [] and {} are just parentheses and optional.
> ...
Rainer... i get tired of responding to your silly arguments. So, what
about tech show down with me?
Before i expend energy, to seriously answer your posts, i need to
know, if you are serious, not just fucking around and picking typos
here and there.
You know, people usually are not serious where there's no stake. In
job interviews, you would be very serious. In cutting a pizza, you
would be serious. When shopping for a prostitute with money, you would
be serious. But in newsgroup discussions, anyone can say shit as they
please. There is no price to pay.
So, i want to be able to acertain some seriouness before we proceed to
a shown down.
What are ways that can assure us this? Maybe we can both pitch in to
paypal some agreed amount of money? I mean, c'mon friend, make some
suggestions that we can get this over with. I'm willing, to, say, put
money in paypal account to domenstrate that I, have the sincerity to
participate. Sure, this is getting a bit weird in newsgroups, but if
serious argumentation is what you really want, we could take this
approach. Yes?
O, any of the Common Lisping fuckheads who participated in this
thread, please suggest ways. You can open a paypal account, and i will
drop in money. I don't run Paypal, and of course this is not the only
way. We could, perhaps hire some respected computer scientist to be
our arbitraror, or something. And we each sign affidavits.
Xah
···@xahlee.org
∑ http://xahlee.org/
Hallo,
On May 7, 3:29 pm, Xah Lee <····@xahlee.org> wrote:
> Dear Rainer Joswig fuckface,
>
>
> Are you, as a Common Lisp fuckhead, willing to have a tech show down
> with me? I don't have nothing to do all day. For other Common Lisping
> fuckheads who has said fucking shits in this thread, i entertain the
> possibility of accepting their challenges too.
>
How long has this troll been here? Judging by the other posts, it
seems that for ages. How do you guys manage it? It's amazing. When you
think you've known enough types of people...
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <clM%h.43$AI5.9@newsfe12.lga>
········@gmail.com wrote:
> Hallo,
>
> On May 7, 3:29 pm, Xah Lee <····@xahlee.org> wrote:
>
>>Dear Rainer Joswig fuckface,
>>
>>
>>Are you, as a Common Lisp fuckhead, willing to have a tech show down
>>with me? I don't have nothing to do all day. For other Common Lisping
>>fuckheads who has said fucking shits in this thread, i entertain the
>>possibility of accepting their challenges too.
>>
>
>
> How long has this troll been here? Judging by the other posts, it
> seems that for ages. How do you guys manage it?
It is springtime, everyone is busting out. My damn corn plant even
flowered. Xah is normally not so, um, sociable.
hth,kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On 2007-05-07 19:48:10 +0100, ·········@gmail.com" <········@gmail.com> said:
> How long has this troll been here? Judging by the other posts, it
> seems that for ages. How do you guys manage it? It's amazing. When you
> think you've known enough types of people...
He's been around since at least 2002. He's OK so long as you treat him
as an amusement.
On 2007-05-07 19:29:07 +0100, Xah Lee <···@xahlee.org> said:
> Dear Rainer, the context is syntax, not semantics. What your Pipe code
> shown above, is semantically Composition as i have written in my
> article...
That's curious, because, as you'd know if you'd used scsh, what it does
is exactly what a Unix shell pipeline does.
In article <························@l77g2000hsb.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
I'm not quoting lots of stuff from your posting, stuff I'm not
interested in responding to.
> The context of my article, is lisp. More specifically, the nested
> notation used by lisp. You should not hijack it to mean Common Lisp.
> Lisp, as you know, is a family of languages. Broadly, it can include
> Logo, Dylan, or even Mathematica.
Logo is a derived language from way back. My last usage
of Logo is long ago and I can't really say if
it is stilly connected to Lisp nowadays.
There were a few Logo implementations in Lisp,
that shared some features with Lisp.
I haven't seen anybody mentioning Logo in connection
to Lisp in the past decade. But that is just my
impression.
Dylan is not really a Lisp dialect any more.
The first Dylan was a Lisp.
It had Lisp syntax and was 'dynamic'. It was way cool.
The later Dylan is more like a derived language. It
is a bit tragic, Dylan stood for Dynamic Language.
Later Dylan was mostly (as in its definition) a
static language. So Stalan would be a fine name
for Dylan now - for the language definition.
The implementations had some dynamic features, though.
Mathematica is no Lisp at all. Mathematica
has a different computing model (term rewriting). I has some features
of Lisp (and others Lisp does not have).
If you know Mathematica it will help
with Lisp, no doubt. But in essence it does not belong to
the Lisp family. This is nothing negative. It is just
so. I wouldn't even call it a derived language.
It is more derived from some applications that
happen to be written in Lisp (SMP, Macsyma, ...).
I'd say Mathematica is related to Lisp like Prolog
is related to Lisp.
> Narrowly, it includes Common Lisp,
> Emacs Lisp, and Scheme. The latter group, all employ a somewhat
> uniform nested syntax.
Wow, that's atleast correct.
They not only have a similar syntax, but they have
also lots of other things in 'common'.
Though Scheme is the odd one when it comes to syntax.
Scheme has a formal syntax
(http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.1).
We can add EuLisp, ISLisp, InterLisp, XLisp, AutoLisp, Goo and
Lisp Machine Lisp.
> As to my qualitifications, I think you know well that i'm not some
> student or lisp newbie.
No student, okay. But Lisp expert?
I can believe that you have lots of knowhow about
programming languages. But Lisp? I mean what
is your experience in Lisp? You did some Emacs
customization, okay? But Lisp programming?
I mean really real Lisp programming? Give me
a hint. I honestly have no idea, because I saw
nothing so far but bullshitting.
> When responding to a article, it is reasonable to know the author's
> qualifications. My qualifications in particular for my article, is
> openly and easily viewable on my public website http://XahLee.org/ .
Xah, I'm looking. I see lots of Mathematica. I see
some Emacs customization. Lots of interesting stuff.
But I fail to see any hint of a Lisp program.
Maybe I cannot find it. Give me a hint.
Emacs is fine, but it's Lisp is ancient and limited.
There are larger Emacs modes written in Lisp.
Maybe that's what I'm missing?
> > In Lisp you would write:
> >
> > (| a b c)
>
> Dear Rainer, the context is syntax, not semantics. What your Pipe code
> shown above, is semantically Composition as i have written in my
> article...
How can you know what it semantically is? You
just see a syntactic form. It can be anything in Lisp
(-> Macros). You claimed that the Lisp syntax
limits Lisp. But that's not the case. Lisp has
extensibility built in (macros, readmacros, ...).
> (i sense some Common Lisp moron will jump my bone here...
> any minute now)
>
> I also replied to Kenny using examples from Mathematica, not unix
> pipes. Did you read that?
Yes, but Mathematica is no Lisp. Lisp looks and feels
different. That you had to resort to Mathematica to argue
shows.
> Before i expend energy, to seriously answer your posts, i need to
> know, if you are serious, not just fucking around and picking typos
> here and there.
There is no need to take the time and write more. Use
the time to do some Lisp programming. If you have problems
representing things in Lisp, comp.lang.lisp may have
some ideas and may help. Theoretical debates of what
could hinder us to write code is useless. I've
seen dedicated guys who wrote and maintained large
amounts of Lisp code. That's more important to me
than discussing what "could" hinder us. There have been
Lisp systems written from a few hundred to more than a million
lines of code. Your problem is just a joke.
On the Internet you can find lots of larger bodies
of Lisp code, which you can study and see if they
are limited by Lisp syntax and what they are doing
to get around this, if necessary.
Have fun.
--
http://lispm.dyndns.org
From: Malcolm McLean
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <abOdnfCDF7dQQqPbRVnyvAA@bt.com>
"Joe Marshall" <··········@gmail.com> wrote in message
>
> Every year someone comes on comp.lang.lisp and informs us
> that it is the parenthesis that are the problem. But in more than
> forty years no one has come up with a better alternative, and
> it hasn't been for want of trying or lack of imagination.
>
It's a completely natural first reaction. I am used to languages in which
parentheses are a minor matter used to disambiguate short expressions. So
the first thing you say on seeing a Lisp program is "eek".
The second thing I said was "why not write a graphical editor for this, to
show the lists as trees?".
However I haven't written enough Lisp to comment on how best to work with
it.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Hi Xah Lee,
Interesting debate.
I cannot hold myself up as anything other than someone
developing my skills - learning.
I've read most of the posts on this topic and, with respect,
perhaps your views might be a tad out of touch with the
human / IT interface. A person ultimately has to code. I
know some products roll out cookie code but behind these,
someone still had to do the work.
I program in Delphi and can all but make coffee with SQL but
they, like all languages it have their quirks. Now that I'm
learning Scheme I'm horrified to discover how precious
little I understood and how badly crafted my code was ...
ouch. But that's a very very good thing (from my
perspective). I did not know what I didn't know - and could
not ask if I didn't know what to ask. I made things 'work'
so it had to be ok. Moved past that thanks to the help of
the parentheses in Scheme. It adds order and imposes
structure: all good to a newbie.
Taking your argument (as far as I am able to understand it -
not a criticism of you BTW) on face value, all programs that
are not machine code are problematic. And I don't fancy
doing any machine code in this lifetime.
Each language builds on several interacting and to a large
part, symbiotic issues. Technology changes. People are
generally becoming more educated. What is considered
laborious today will be mundane in 20 years time just as it
is now in comparison to 20 years ago.
Scheme (parentheses or not) is from a learning perspective
ideal because it is well structured and it is very easy to
read. Unless a person is able to understand what is
happening in the code (read: any code someone else writes)
then they can't tell if it is doing what it claims to do -
further, they can't tell if there is anything wrong or
anything they might do to improve it. At least, not without
an exorcist.
Isn't is more practical to choose the right tool for the
right task to be used in the right context by the right
person?
And don't you think that the advantages of being able to
easily understand what a program is doing makes it a lot
easier to attract talent to the field and to develop better
tools.
Performance is king - or perhaps not so much. With each
iteration of increase in processor performance, the drive
towards code stability (predictability) and maintainability
outweigh yet to be proved advantages of arcane cryptic code?
If maths is a universal language, then so too is programming
(various languages) by extension?
I'm uncertain if there is merit in returning to a period
where social power was exercised by only those people who
could read. It just sounds like a revisionist form of
techno-mage (the magic lies in the ability to read / write
things that few can read and even less, understand.
Like I said, interesting discussion.
Kindest regards,
Mike
"Xah Lee" <···@xahlee.org> wrote in message
····························@o5g2000hsb.googlegroups.com...
How Lisp's Nested Notation Limits The Language's Utility
Xah Lee, 2007-05-03
There is a common complain by programers about lisp's
notation, of
nested parenthesis, being unnatural or difficult to read.
Long time
lisp programers, often counter, that it is a matter of
conditioning,
and or blaming the use of "inferior" text editors that are
not
designed to display nested notations. In the following, i
describe how
lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested
parenthesis
syntax. This is a practical problem. On this aspect along,
lisp's
syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for
human to read.
Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages
frequent or
advanced use of function sequencing or compositions. This
aspect is
the most devastating.
The first issue, that most programers are not comfortable
with nested
notation, is well known. It is not a technical issue.
Whether it is
considered a problem of the lisp language is a matter of
philosophical
disposition.
The second issue, about nested parenthesis not being natural
for human
to read, may be debatable. I do think, that deep nesting is
a problem
to the programer. Here's a example of 2 blocks of code that
are
syntactically equivalent in the Mathematica language:
vectorAngle[{a1_, a2_}] := Module[{x, y},
{x, y} = {a1, a2}/Sqrt[a1^2 + a2^2] // N;
If[x == 0, If[····@y === 1, ?/2, -?/2],
If[y == 0, If[····@x === 1, 0, ?],
If[····@y === 1, ······@x, 2 ? - ······@x]
]
]
]
SetDelayed[vectorAngle[List[Pattern[a1,Blank[]],Pattern[a2,Blank[]]]],
Module[List[x,y],
CompoundExpression[
Set[List[x,y],
N[Times[List[a1,a2],
Power[Sqrt[Plus[Power[a1,2],Power[a2,2]]],-1]]]],
If[Equal[x,0],
If[SameQ[Sign[y],1],Times[?,Power[2,-1]],
Times[Times[-1,?],Power[2,-1]]],
If[Equal[y,0],If[SameQ[Sign[x],1],0,?],
If[SameQ[Sign[y],1],ArcCos[x],
Plus[Times[2,?],Times[-1,ArcCos[x]]]]]]]]]
In the latter, it uses a full nested form (called FullForm
in
Mathematica). This form is isomorphic to lisp's nested
parenthesis
syntax, token for token (i.e. lisp's "(f a b)" is
Mathematica's
"f[a,b]"). As you can see, this form, by the sheer number of
nested
brackets, is in practice problematic to read and type. In
Mathematica,
nobody really program using this syntax. (The FullForm
syntax is
there, for the same reason of language design principle
shared with
lisp of "consistency and simplicity", or the commonly touted
lisp
advantage of "data is program; program is data".)
The third issue, about how nested syntax seriously
discourages
frequent or advanced use of inline function sequencing on
the fly, is
the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering
unix's
shell syntax. You all know, how convenient and powerful is
the unix's
pipes. Here are some practical example: "ls -al | grep xyz",
or "cat a
b c | grep xyz | sort | uniq".
Now suppose, we get rid of the unix's pipe notation,
instead, replace
it with a pure functional notation: e.g. (uniq (sort (grep
xyz (cat a
b c)))), or enrich it with a composition function and a pure
function
construct (?), so this example can be written as: ((compose
(lambda
(x) (grep xyz x)) sort uniq) (cat a b c)).
You see, how this change, although syntactically equivalent
to the
pipe "|" (or semantically equivalent in the example using
function
compositions), but due to the cumbersome nested syntax, will
force a
change in the nature of the language by the code programer
produces.
Namely, the frequency of inline sequencing of functions on
the fly
will probably be reduced, instead, there will be more code
that define
functions with temp variables and apply it just once as with
traditonal languages.
A language's syntax or notation system, has major impact on
what kind
of code or style or thinking pattern on the language's
users. This is
a well-known fact for those acquainted with the history of
math
notations.
The sequential notation ··@·@·@x", or "x//h//g//f", or unixy
"x|h|g|
f", are far more convenient and easier to decipher, than "(f
(g (h
x)))" or "((compose h g f) x)". In actual code, any of the
f, g, h
might be a complex pure function (aka lambda construct, full
of
parenthesis themselves).
Lisp, by sticking with almost uniform nested parenthesis
notation, it
immediately reduces the pattern of sequencing functions,
simply
because the syntax does not readily lend the programer to it
as in the
unix's "x|h|g|f". For programers who are aware of the coding
pattern
of sequencing functions, now either need to think in terms
of a
separate "composition" construct, and or subject to the much
problematic typing and deciphering of nested parenthesis.
(Note: Lisp's sexp is actually not that pure. It has ad hoc
syntax
equivalents such as the "quote" construct " '(a b c) ", and
also "`",
"#", ",@" constructs, precisely for the purpose of reducing
parenthesis and increasing readability. Scheme's coming
standard the
R6RS ?, even proposes the introduction of [] and {} and few
other
syntax sugars to break the uniformity of nested parenthesis
for
legibility. Mathematica's FullForm, is actually a pure
nested notation
as can be.)
-------
The above, is part of a 3-part exposition:
"The Concepts and Confusions of Prefix, Infix, Postfix and
Fully
Functional Notations",
"Prefix, Infix, Postfix notations in Mathematica",
"How Lisp's Nested Notation Limits The Language's Utility",
archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
···@xahlee.org
? http://xahlee.org/
Mike wrote:
> Taking your argument (as far as I am able to understand it -
> not a criticism of you BTW) on face value, all programs that
> are not machine code are problematic. And I don't fancy
> doing any machine code in this lifetime.
I don't think Xah's comments were specific to machine code in any way.
Essentially he is saying: is it not better to be able to write code like:
o + # d &
easily, rather than:
(lambda (x) `(+ ,o (* ,x ,d)))
> Each language builds on several interacting and to a large
> part, symbiotic issues. Technology changes. People are
> generally becoming more educated. What is considered
> laborious today will be mundane in 20 years time just as it
> is now in comparison to 20 years ago.
Ironically, half of this discussion has been about the relative benefits of
approaches that are all decades old. There is nothing new here.
> Scheme (parentheses or not) is from a learning perspective
> ideal because it is well structured and it is very easy to
> read. Unless a person is able to understand what is
> happening in the code (read: any code someone else writes)
> then they can't tell if it is doing what it claims to do -
> further, they can't tell if there is anything wrong or
> anything they might do to improve it. At least, not without
> an exorcist.
This is one of the arguments in favor of static verification: you can have
machine-verified documentation generated by the compiler provided the
language is carefully designed.
> Isn't is more practical to choose the right tool for the
> right task to be used in the right context by the right
> person?
Absolutely. The question is then: what is Lisp syntax good for? I think the
answer is "not a lot", which is why the vast majority of programmers moved
on to something better over the past 50 years.
> And don't you think that the advantages of being able to
> easily understand what a program is doing makes it a lot
> easier to attract talent to the field and to develop better
> tools.
Absolutely. But don't you think most people will find it easier to
understand:
a + b*c
rather than:
(+ a (* b c))
?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 9, 8:14 am, Jon Harrop <····@ffconsultancy.com> wrote:
(Drivel removed)
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journal http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Ah, the F#.NET Journal.
With a ?usenet attached. So you can see how many people are clicking
on your ads in
comp.lang.lisp. I think your postings here a best seen as pure
advertisements plus random drivel
against Lisp to attract attention. It is not that I find Functional
Programming Languages
and related topics uninteresting, but your postings to Usenet makes
your offerings
extremely, hmm, uninteresting. Somehow I don't find your self-
marketing to be that
effective.
MS Vista: 'Cancel or allow?'
Cancel.
On May 9, 7:14 am, Jon Harrop <····@ffconsultancy.com> wrote:
> the vast majority of programmers moved
> on to something better over the past 50 years.
Yeah. Like XML. Oh, better, oops. Of course, no one uses XML.
On May 9, 2:14 am, Jon Harrop <····@ffconsultancy.com> wrote:
[...]
> I don't think Xah's comments were specific to machine code in any way.
> Essentially he is saying: is it not better to be able to write code like:
> o + # d &
> easily, rather than:
> (lambda (x) `(+ ,o (* ,x ,d)))
If you really enjoy using that sort of syntax, it's not hard to whip
up a macro that allows you to use it in CL. Some people do exactly
that, but most people don't. I played around with it for a while
before deciding that it actually wasn't worth the trouble.
[...]
> > And don't you think that the advantages of being able to
> > easily understand what a program is doing makes it a lot
> > easier to attract talent to the field and to develop better
> > tools.
> Absolutely. But don't you think most people will find it easier to
> understand:
> a + b*c
> rather than:
> (+ a (* b c))
> ?
I don't really care what most people will find easier to understand. I
care what I find easier to understand. I find that with infix
notations in computer languages, the choices I have are either
spending a great deal of time puzzling out precedence, or
parenthesizing everything. This is not a tremendous advantage over
Lisp.
Cheers,
Pillsy
On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> The question is then: what is Lisp syntax good for? I think the
> answer is "not a lot", which is why the vast majority of programmers moved
> on to something better over the past 50 years.
This is an unfounded assertion.
In order to `move on' you are strongly implying that this vast
majority started with (or at least did substantial work with) Lisp
syntax, found it wanting in some way, and then abandoned this syntax
in favor of `something better'. There is ample evidence that this is
false.
Is English your first language?
Joe Marshall wrote:
> On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> The question is then: what is Lisp syntax good for? I think the
>> answer is "not a lot", which is why the vast majority of programmers
>> moved on to something better over the past 50 years.
>
> This is an unfounded assertion.
I already founded it and you replied with something like "Lisp syntax can
only be compared to Lisp syntax".
> In order to `move on' you are strongly implying that this vast
> majority started with (or at least did substantial work with) Lisp
> syntax, found it wanting in some way, and then abandoned this syntax
> in favor of `something better'. There is ample evidence that this is
> false.
Lisp is a language lab. It was used by the original MLers. They were some of
the many people who said "why the hell are we writing this intermediate
language by hand?" and ditched it. I already cited lots of other people and
Xah made an excellent point in his original post about Mathematica users
have the choice and choosing anything but prefix notation.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 9, 1:45 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> The question is then: what is Lisp syntax good for? I think the
> >> answer is "not a lot", which is why the vast majority of programmers
> >> moved on to something better over the past 50 years.
>
> > This is an unfounded assertion.
>
> I already founded it and you replied with something like "Lisp syntax can
> only be compared to Lisp syntax".
Mirriam Webster gives this definition for `unfounded':
Function: adjective
: lacking a sound basis : GROUNDLESS, UNWARRANTED <an unfounded
accusation>
You have mentioned some languages that have been developed after Lisp
that do not have s-expression syntax (a fact that no one disputes).
You have shown no evidence whatsoever that a `vast majority' of
programmers have even *tried* Lisp, let alone `moved on' to anything.
I don't believe I ever said that Lisp syntax can only be compared to
Lisp syntax. If I did, would you please refer me to the message id?
If I did not, would you be so kind as to not put words in my mouth?
> > In order to `move on' you are strongly implying that this vast
> > majority started with (or at least did substantial work with) Lisp
> > syntax, found it wanting in some way, and then abandoned this syntax
> > in favor of `something better'. There is ample evidence that this is
> > false.
>
> Lisp is a language lab. It was used by the original MLers. They were some of
> the many people who said "why the hell are we writing this intermediate
> language by hand?" and ditched it.
Uhuh... You have a reference for this?
Since Milner was interested in proving theorems about Polymorphic
Predicate Lambda Calculus, I suspect that the choice of an ISWIM-like
syntax was made because the semantics of the meta-language was based
on ISWIM. I have no reference that demonstrates the rationale for the
choice of syntax, but it is more plausible that the syntax is derived
from a desire to be similar to the syntax of the prior languages
(ISWIM, POP2, PAL, and Gedanken) than from a desire to be different
from Lisp.
Regardless of the reason, a handful of researchers does not a vast
majority create. ML and its descendants have *fewer* adherents than
Common Lisp.
> I already cited lots of other people and
> Xah made an excellent point in his original post about Mathematica users
> have the choice and choosing anything but prefix notation.
I'll be generous. Programmers of ML and its descendants *and* the
Mathematica programmers *and* all the F# programmers (count them)
*combined* are outnumbered by the Lisp programmers. (Source: TIOBE.
Lisp is at 0.698%, ML at 0.145%, OCaml at 0.103%, Mathematica at a
whopping 0.090%, and F# less than that).
Now it is one thing to assert that Lisp is less popular than Java, C, C
++, etc. because of the syntax. It is *possible* that a large number
of these people saw Lisp at some point and thought `that's weird'.
However, the `vast majority' of programmers have had little to no
exposure to Lisp beyond a cursory overview and have hardly made an
informed decision about syntax. It is patently absurd (read that
`wrong') to assert that the `vast majority' of informed, experienced
Lisp hackers have abandoned the language over syntax. It is simply
incorrect to assert that ML or OCaml or Mathematica has superseded
Lisp in any catagory save obscurity.
On May 10, 12:45 am, Joe Marshall <··········@gmail.com> wrote:
> On May 9, 1:45 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Joe Marshall wrote:
> > > On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> > >> The question is then: what is Lisp syntax good for? I think the
> > >> answer is "not a lot", which is why the vast majority of programmers
> > >> moved on to something better over the past 50 years.
>
> > > This is an unfounded assertion.
>
> > I already founded it and you replied with something like "Lisp syntax can
> > only be compared to Lisp syntax".
>
> Mirriam Webster gives this definition for `unfounded':
> Function: adjective
> : lacking a sound basis : GROUNDLESS, UNWARRANTED <an unfounded
> accusation>
>
> You have mentioned some languages that have been developed after Lisp
> that do not have s-expression syntax (a fact that no one disputes).
> You have shown no evidence whatsoever that a `vast majority' of
> programmers have even *tried* Lisp, let alone `moved on' to anything.
>
> I don't believe I ever said that Lisp syntax can only be compared to
> Lisp syntax. If I did, would you please refer me to the message id?
> If I did not, would you be so kind as to not put words in my mouth?
>
> > > In order to `move on' you are strongly implying that this vast
> > > majority started with (or at least did substantial work with) Lisp
> > > syntax, found it wanting in some way, and then abandoned this syntax
> > > in favor of `something better'. There is ample evidence that this is
> > > false.
>
> > Lisp is a language lab. It was used by the original MLers. They were some of
> > the many people who said "why the hell are we writing this intermediate
> > language by hand?" and ditched it.
>
> Uhuh... You have a reference for this?
>
> Since Milner was interested in proving theorems about Polymorphic
> Predicate Lambda Calculus, I suspect that the choice of an ISWIM-like
> syntax was made because the semantics of the meta-language was based
> on ISWIM. I have no reference that demonstrates the rationale for the
> choice of syntax, but it is more plausible that the syntax is derived
> from a desire to be similar to the syntax of the prior languages
> (ISWIM, POP2, PAL, and Gedanken) than from a desire to be different
> from Lisp.
>
> Regardless of the reason, a handful of researchers does not a vast
> majority create. ML and its descendants have *fewer* adherents than
> Common Lisp.
>
> > I already cited lots of other people and
> > Xah made an excellent point in his original post about Mathematica users
> > have the choice and choosing anything but prefix notation.
>
> I'll be generous. Programmers of ML and its descendants *and* the
> Mathematica programmers *and* all the F# programmers (count them)
> *combined* are outnumbered by the Lisp programmers. (Source: TIOBE.
> Lisp is at 0.698%, ML at 0.145%, OCaml at 0.103%, Mathematica at a
> whopping 0.090%, and F# less than that).
>
> Now it is one thing to assert that Lisp is less popular than Java, C, C
> ++, etc. because of the syntax. It is *possible* that a large number
> of these people saw Lisp at some point and thought `that's weird'.
> However, the `vast majority' of programmers have had little to no
> exposure to Lisp beyond a cursory overview and have hardly made an
> informed decision about syntax.
It's even worse than that, in my country students either are not
learning learn lisp at all or programming some scheme only on pen &
paper. No wonder that everybody I have a chance to speak with
personally, hates lisp and everything about it, they're practically
terrified, comparing useless lisp with Visual Studio 2005 and don't
see any sense learning lisp. Hey Lisp that's artefact from the 50s
(yeah they learn history of lisp in their ai class but not programming
in lisp). I give one guy a quick demonstration of what can be done in
an hour with lisp ,hunchentoot and cl-who and got blamed that I'm a
guru ( which I'm not ) . So I pass him a Gentle Introduction book and
a modern Lisp IDE and make him try some lisp for himself. After an
hour the impression was : If I had this book a year ago I'll score 10
( maximum ) in my AI class. People are just terrified of what they
know , lispers are almost always skilled in other popular languages
but guys from the popular languages don't know anything about lisp or
worse do some scheme on pen & paper in that damn hard AI class.
cheers
bobi
From: Robert Uhl
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m3bqgsk8k9.fsf@latakia.dyndns.org>
Joe Marshall <··········@gmail.com> writes:
>
> Now it is one thing to assert that Lisp is less popular than Java, C, C
> ++, etc. because of the syntax. It is *possible* that a large number
> of these people saw Lisp at some point and thought `that's weird'.
> However, the `vast majority' of programmers have had little to no
> exposure to Lisp beyond a cursory overview and have hardly made an
> informed decision about syntax.
That was certainly true in my case. In college we briefly looked at
Lisp while studying AI; I quickly decided that it was silly (oh, the
follies of youth!). After graduation, I periodically took a look at
Guile Scheme--I never was able to figure out why folks were so excited
by it. I tried looking at Common Lisp, but the online resources were
pretty much nonexistent; CMUCL was weird; CLISP was interpreted; Allegro
and LispWorks were proprietary; GCL seemed buggy beyond belief. So I
stuck with Perl and later Python, with C when I wanted some speed.
It wasn't until Practical Common Lisp came out that I a) figured out why
CL was so cool and b) found SBCL. Now when I'm writing in Python for
work I keep on wishing that I had CL to use instead. Of course, writing
my current project in CL would be a right royal pain for lack of
libraries (yes, I'm just a glue coder; I make no pretence of particular
skill), but that's life for the moment.
At home I'm playing with a CL clone of Django, which is the web
framework I like most so far.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I would rather have a German division in front of me than a French one
behind me. --General George S. Patton
Joe Marshall wrote:
> You have mentioned some languages that have been developed after Lisp
> that do not have s-expression syntax (a fact that no one disputes).
> You have shown no evidence whatsoever that a `vast majority' of
> programmers have even *tried* Lisp, let alone `moved on' to anything.
Lisp is taught at university. Most computer science students used it to
learn the academic curiosity that is the metacircular evaluator.
Google indexes over 1 million pages than mention Common Lisp. Were they
written by people who had never tried Lisp?
> I don't believe I ever said that Lisp syntax can only be compared to
> Lisp syntax. If I did, would you please refer me to the message id?
·······················@e51g2000hsg.googlegroups.com
> Regardless of the reason, a handful of researchers does not a vast
> majority create. ML and its descendants have *fewer* adherents than
> Common Lisp.
A Google trend search indicates that Common Lisp is now less common than any
of OCaml, Haskell or Mathematica and that the trend is worsening for Lisp:
http://www.google.com/trends?q=common+lisp%2C+ocaml%2C+haskell%2C+mathematica&ctab=0&geo=all&date=all
Best case you'll argue that Haskell and Mathematica are homonyms. But OCaml
isn't...
> I'll be generous. Programmers of ML and its descendants *and* the
> Mathematica programmers *and* all the F# programmers (count them)
> *combined* are outnumbered by the Lisp programmers. (Source: TIOBE.
> Lisp is at 0.698%, ML at 0.145%, OCaml at 0.103%, Mathematica at a
> whopping 0.090%, and F# less than that).
TIOBE's method is biased by Lisp's longer history.
Google code search is newer and says otherwise:
Standard ML: 79
Haskell: 101
OCaml: 125
Lisp: 172
Just adding two ML dialects (OCaml and SML), they outnumber all Lisp
dialects (primarily emacs).
Debian source package popularity says otherwise:
http://popcon.debian.org/source/by_inst
MLton: 55
SMLNJ: 268
CMUCL: 358
SBCL: 637
CLisp: 705
GHC6: 1312
OCaml: 7261
OCaml is more than ten times as popular as the most popular Common Lisp
compiler.
Google search hits with years in them:
+"common lisp" +2001: 281,000
+ocaml +2001: 400,000
+haskell +2001: 1,290,000
+"common lisp" +2006: 698,000
+ocaml +2006: 1,260,000
+haskell +2006: 1,510,000
OCaml is more popular and the gap is widening.
Does it suck:
http://www.sucks-rocks.com/rate/common lisp/ocaml/haskell/mathematica
Common Lisp: 0.7
Lisp: 5.4
OCaml: 6.9
Mathematica: 6.9
Haskell: 7.3
> Now it is one thing to assert that Lisp is less popular than Java, C, C
> ++, etc. because of the syntax. It is *possible* that a large number
> of these people saw Lisp at some point and thought `that's weird'.
> However, the `vast majority' of programmers have had little to no
> exposure to Lisp beyond a cursory overview and have hardly made an
> informed decision about syntax. It is patently absurd (read that
> `wrong') to assert that the `vast majority' of informed, experienced
> Lisp hackers have abandoned the language over syntax.
Best case you can claim that the large numbers of people aware of Lisp are
not enlightented Lispers because they were just forced to learn Lisp at
uni. If so, you've just eaten further into your dwindling popularity curve.
> It is simply
> incorrect to assert that ML or OCaml or Mathematica has superseded
> Lisp in any catagory save obscurity.
Given the above, this is at best debateable.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 11:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > You have mentioned some languages that have been developed after Lisp
> > that do not have s-expression syntax (a fact that no one disputes).
> > You have shown no evidence whatsoever that a `vast majority' of
> > programmers have even *tried* Lisp, let alone `moved on' to anything.
>
> Lisp is taught at university. Most computer science students used it to
> learn the academic curiosity that is the metacircular evaluator.
>
> Google indexes over 1 million pages than mention Common Lisp. Were they
> written by people who had never tried Lisp?
>
> > I don't believe I ever said that Lisp syntax can only be compared to
> > Lisp syntax. If I did, would you please refer me to the message id?
>
> ·······················@e51g2000hsg.googlegroups.com
>
> > Regardless of the reason, a handful of researchers does not a vast
> > majority create. ML and its descendants have *fewer* adherents than
> > Common Lisp.
>
> A Google trend search indicates that Common Lisp is now less common than any
> of OCaml, Haskell or Mathematica and that the trend is worsening for Lisp:
>
> http://www.google.com/trends?q=common+lisp%2C+ocaml%2C+haskell%2C+mat...
>
> Best case you'll argue that Haskell and Mathematica are homonyms. But OCaml
> isn't...
>
> > I'll be generous. Programmers of ML and its descendants *and* the
> > Mathematica programmers *and* all the F# programmers (count them)
> > *combined* are outnumbered by the Lisp programmers. (Source: TIOBE.
> > Lisp is at 0.698%, ML at 0.145%, OCaml at 0.103%, Mathematica at a
> > whopping 0.090%, and F# less than that).
>
> TIOBE's method is biased by Lisp's longer history.
>
> Google code search is newer and says otherwise:
>
> Standard ML: 79
> Haskell: 101
> OCaml: 125
> Lisp: 172
>
> Just adding two ML dialects (OCaml and SML), they outnumber all Lisp
> dialects (primarily emacs).
>
> Debian source package popularity says otherwise:
>
> http://popcon.debian.org/source/by_inst
>
> MLton: 55
> SMLNJ: 268
> CMUCL: 358
> SBCL: 637
> CLisp: 705
> GHC6: 1312
> OCaml: 7261
>
> OCaml is more than ten times as popular as the most popular Common Lisp
> compiler.
>
> Google search hits with years in them:
>
> +"common lisp" +2001: 281,000
> +ocaml +2001: 400,000
> +haskell +2001: 1,290,000
>
> +"common lisp" +2006: 698,000
> +ocaml +2006: 1,260,000
> +haskell +2006: 1,510,000
>
> OCaml is more popular and the gap is widening.
>
> Does it suck:
>
> http://www.sucks-rocks.com/rate/commonlisp/ocaml/haskell/mathematica
>
> Common Lisp: 0.7
> Lisp: 5.4
> OCaml: 6.9
> Mathematica: 6.9
> Haskell: 7.3
>
> > Now it is one thing to assert that Lisp is less popular than Java, C, C
> > ++, etc. because of the syntax. It is *possible* that a large number
> > of these people saw Lisp at some point and thought `that's weird'.
> > However, the `vast majority' of programmers have had little to no
> > exposure to Lisp beyond a cursory overview and have hardly made an
> > informed decision about syntax. It is patently absurd (read that
> > `wrong') to assert that the `vast majority' of informed, experienced
> > Lisp hackers have abandoned the language over syntax.
>
> Best case you can claim that the large numbers of people aware of Lisp are
> not enlightented Lispers because they were just forced to learn Lisp at
> uni. If so, you've just eaten further into your dwindling popularity curve.
>
> > It is simply
> > incorrect to assert that ML or OCaml or Mathematica has superseded
> > Lisp in any catagory save obscurity.
>
> Given the above, this is at best debateable.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
BS you could always find statistics who could support your claim ,
beside OCaml line seems streight.
On May 10, 10:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Does it suck:
>
> http://www.sucks-rocks.com/rate/commonlisp/ocaml/haskell/mathematica
>
> Common Lisp: 0.7
> Lisp: 5.4
> OCaml: 6.9
> Mathematica: 6.9
> Haskell: 7.3
http://www.sucks-rocks.com/rate/ocaml/haskell/mathematica/%22common+lisp%22
"common lisp" 9.5
You get points for trying though.
On 2007-05-10 10:30:23 -0400, Chris Russell
<·····················@gmail.com> said:
> http://www.sucks-rocks.com/rate/ocaml/haskell/mathematica/%22common+lisp%22
>
> "common lisp" 9.5
This is fun!
Here then is the "definitive" ranking of languages:
<http://www.sucks-rocks.com/rate/%22Common+Lisp%22/F%23/SML/C%2B%2B/Ruby/ML/Python/erlang/C%23/Smalltalk/lua/Haskell/Scheme/OCaml/%22Objective-C%22/Perl/Java>
Notice
how F# comes up just a bit short. No doubt Harrop will soon remedy this
by means of continuous spam-marketing.
"Common Lisp" 9.5
F# 9.2
SML 9.1
C++ 8.8
Ruby 8.8
ML 8.8
Python 8.4
erlang 8.3
C# 8.0
Smalltalk 8.0
lua 7.7
Haskell 7.3
Scheme 7.0
OCaml 6.9
"Objective-C" 6.2
Perl 5.7
Java 4.9 (ouch!)
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2007-05-10 10:30:23 -0400, Chris Russell
> <·····················@gmail.com> said:
>
> > http://www.sucks-rocks.com/rate/ocaml/haskell/mathematica/%22common+lisp%22
> >
> > "common lisp" 9.5
>
> This is fun!
>
> Here then is the "definitive" ranking of languages:
>
> <http://www.sucks-rocks.com/rate/%22Common+Lisp%22/F%23/SML/C%2B%2B/Ruby/ML/Python/erlang/C%23/Smalltalk/lua/Haskell/Scheme/OCaml/%22Objective-C%22/Perl/Java>
>
>
> Notice
>
> how F# comes up just a bit short. No doubt Harrop will soon remedy this
> by means of continuous spam-marketing.
>
>
> "Common Lisp" 9.5
>
> F# 9.2
>
> SML 9.1
>
> C++ 8.8
>
> Ruby 8.8
>
> ML 8.8
>
> Python 8.4
>
> erlang 8.3
>
> C# 8.0
>
> Smalltalk 8.0
>
> lua 7.7
>
> Haskell 7.3
>
> Scheme 7.0
>
> OCaml 6.9
>
> "Objective-C" 6.2
>
> Perl 5.7
>
> Java 4.9 (ouch!)
Symbolics 10.0
Genera 9.8
;-)
--
http://lispm.dyndns.org
From: Espen Vestre
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m14pml2dt2.fsf@gazonk.netfonds.no>
Jon Harrop <···@ffconsultancy.com> writes:
> Does it suck:
You suck. Go away.
--
(espen)
From: Espen Vestre
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m1zm4d0xtx.fsf@gazonk.netfonds.no>
Espen Vestre <·····@vestre.net> writes:
> Jon Harrop <···@ffconsultancy.com> writes:
>
>> Does it suck:
>
> You suck. Go away.
Hmm. On second thought, I apologize for my rudeness.
I'd rather put it this way:
If you're so convinced that lisp is irrelevant, useless and uncool,
then please don't waste your time disturbing us here at c.l.l. If you
think we're a bunch of religious fanatics, then please don't disturb
us during our ceremonies. Thank you.
--
(espen)
On May 10, 12:36 pm, Espen Vestre <····@vestre.net> wrote:
> Espen Vestre <····@vestre.net> writes:
> > Jon Harrop <····@ffconsultancy.com> writes:
>
> >> Does it suck:
>
> > You suck. Go away.
>
> Hmm. On second thought, I apologize for my rudeness.
>
> I'd rather put it this way:
>
> If you're so convinced that lisp is irrelevant, useless and uncool,
> then please don't waste your time disturbing us here at c.l.l. If you
> think we're a bunch of religious fanatics, then please don't disturb
> us during our ceremonies. Thank you.
> --
> (espen)
Bravo .
BTW I don't know what sounds better :
1. Use lisp or I'll bomb you infidel.
2. Oh mighty lisp , have mercy of those heretics who never understood
your true power, falsely accusode you
On May 10, 12:36 pm, Espen Vestre <····@vestre.net> wrote:
> Espen Vestre <····@vestre.net> writes:
> > Jon Harrop <····@ffconsultancy.com> writes:
>
> >> Does it suck:
>
> > You suck. Go away.
>
> Hmm. On second thought, I apologize for my rudeness.
>
> I'd rather put it this way:
>
> If you're so convinced that lisp is irrelevant, useless and uncool,
> then please don't waste your time disturbing us here at c.l.l. If you
> think we're a bunch of religious fanatics, then please don't disturb
> us during our ceremonies. Thank you.
> --
> (espen)
He won't do that , has a language to promote .
From: Espen Vestre
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m1k5vh0wi8.fsf@gazonk.netfonds.no>
fireblade <·················@gmail.com> writes:
> He won't do that , has a language to promote .
Advertisers and dog are not allowed into the shrine.
;-)
--
(espen)
In article <··············@gazonk.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Espen Vestre <·····@vestre.net> writes:
>
> > Jon Harrop <···@ffconsultancy.com> writes:
> >
> >> Does it suck:
> >
> > You suck. Go away.
>
> Hmm. On second thought, I apologize for my rudeness.
>
> I'd rather put it this way:
>
> If you're so convinced that lisp is irrelevant, useless and uncool,
> then please don't waste your time disturbing us here at c.l.l. If you
> think we're a bunch of religious fanatics, then please don't disturb
> us during our ceremonies. Thank you.
comp.lang.lisp has simply much more traffic than
other newsgroups with some functional programming
background.
Google Groups gives:
High Activity
* comp.lang.perl
* comp.lang.ruby
* comp.lang.python
* comp.lang.lisp
Medium Activity
* comp.lang.functional
* comp.lang.scheme
Low Activity
* comp.lang.smalltalk
* comp.lang.apl
* comp.lang.logo
* comp.lang.ml
* comp.lang.dylan
* fa.caml
* fa.haskell
* comp.lang.haskell
Somehow Mr. Harrop thinks that he can generate
business from posting to comp.lang.lisp. So much,
that he now posts mostly to comp.lang.lisp.
Since F# is so superior, Lisp is so
backwards, Lisp users must be easy to convert.
Or so. Unfortunately his style is so rude that
I would buy anything from him. Maybe he is
trying some stupid marketing tricks, like where
people are told that their hair is ugly, but
with the new shampoo there might be some
help.
--
http://lispm.dyndns.org
On May 10, 2:13 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <··············@gazonk.netfonds.no>,
> Espen Vestre <····@vestre.net> wrote:
>
>
>
>
>
> > Espen Vestre <····@vestre.net> writes:
>
> > > Jon Harrop <····@ffconsultancy.com> writes:
>
> > >> Does it suck:
>
> > > You suck. Go away.
>
> > Hmm. On second thought, I apologize for my rudeness.
>
> > I'd rather put it this way:
>
> > If you're so convinced that lisp is irrelevant, useless and uncool,
> > then please don't waste your time disturbing us here at c.l.l. If you
> > think we're a bunch of religious fanatics, then please don't disturb
> > us during our ceremonies. Thank you.
>
> comp.lang.lisp has simply much more traffic than
> other newsgroups with some functional programming
> background.
>
> Google Groups gives:
>
> High Activity
> * comp.lang.perl
> * comp.lang.ruby
> * comp.lang.python
> * comp.lang.lisp
>
> Medium Activity
> * comp.lang.functional
> * comp.lang.scheme
>
> Low Activity
> * comp.lang.smalltalk
> * comp.lang.apl
> * comp.lang.logo
> * comp.lang.ml
> * comp.lang.dylan
> * fa.caml
> * fa.haskell
> * comp.lang.haskell
>
> Somehow Mr. Harrop thinks that he can generate
> business from posting to comp.lang.lisp. So much,
> that he now posts mostly to comp.lang.lisp.
If lisp needed popularity we would be gratefull to Harrop and Xah Lee
for generating high activity . But If ALL we need is being popular we
could just go to java.
cheers
bobi
Computer Language Popularity Trend
Xah Lee, 2006-09
This page gives a visual report of computer languages's popularity, as
indicated by their traffic level in newsgroups. This is not a
comprehensive or fair survey, but does give some indications of
popularity trends.
[The full version, with statistical charts is archived at
“Computer Language Popularity Trend”
http://xahlee.org/lang_traf/index.html
]
Language Class Overview
above: A graph showing the newsgroup traffic for comp.lang.lisp,
comp.lang.c, comp.lang.perl.misc, comp.lang.javascript.
The figure above gives a general overview of high level languages such
as lisp, medium level languages such as perl and javascript, and low
level languages such as c.
High Level “Scripting” Languages
above: A graph showing newsgroup traffic of representative high-level
languages that are so-called scripting languages. The newsgroups
plotted are: comp.lang.perl.misc, comp.lang.javascript,
comp.lang.python, comp.lang.ruby, comp.lang.php.
>From this graph, we can see that Perl rose and fell with the dot com
era. Python rose and surpassed Perl about 2002. Ruby is a new kid on
the block, and Pretty-Home-Page also has some presence.
Among these languages, Perl is a sys admin staple that started as a
unix scripting hack around 1988 and gained a widespread popularity due
to the rise of the internet, with CGI and dot com boom (~1995-2000).
At the time, it was the only practical language for server-side web
programing. Also, Perl at the time held another unique position in
unix scripting, in that it is more general and flexible than the
inconsistent unix tool bags of shell, find, grep, awk.
Javascript is invented by Netscape during the same time Perl became
widely popular. Javascript holds the unique position where it is the
only industrial language for client-side web scripting (mostly dealing
with HTML in web browsers), and is still so today and not likely to
change in the near future.
PHP, or Pretty-Home-Page, started as as a CGI script written in Perl.
Gradually, it became a language itself, dedicated to server-side
programing. It essentially is a outgrowth of a hack in the unix
tradition. (e.g. c/tcsh, sh/bash, sed/awk/perl) Today, PHP's
popularity surpasses that of Perl in the web application industry. PHP
as a language is rather dry and business-like. It has a lot online
forums but isn't very lively in newsgroups, where chatty college
students and language enthus dwell.
Python started in the early 1990s, several years later than Perl, and
with much less fanfare. It is fit for the same type of applications
Perl is good for. Its popularity rose slowly and stably. The primary,
and a very sharp, difference between Perl and Python is that Perl has
lax syntax that makes Perl code most unreadable, while Python has a
syntax that requires even exact indentations, which makes it very
readable.
Ruby is another language in the same class as Perl and Python. It
arose as a betterment over Perl's problematic syntactical and
semantical inconsistencies. From the design point of view, Ruby is
very clean and elegant, but as of today, it is still a toy language
with no industrial foothold. Although its popularity is on the rise,
but whether it will become widely used is not clear, since there are
also old and new languages such as Scheme, Haskell, Perl6 and
Python3000 vying for the future.
Lisp, and Industrial Low Level Languages
above: A graph showing the newsgroup traffic for comp.lang.lisp,
comp.lang.c, comp.lang.c++, comp.lang.java.programmer.
The languages in this graph are all widely used industrial languages.
C and lisp share a commonality in their old age. (LISP ~ 1960 and C
~1970). Lisp is a functional language distinct from the others. C++ is
more or less a compatible superset of C. Java is somewhat a betterment
over C++. The syntax of C, C++, and Java are basically identical.
We can see that lisp is slowly but steadily on the rise, and the
imperative languages rose and fell with the dot com.
C++ is a result of OOP fad in its infancy, and is functionally a OOP
graft over C. Java is invented by Sun Microsystems during the dot com
era, with huge investment towards marketing, to the point that even
non-programers have read about it in common newspapers, with the air
of some technological revolution. (the naming of Javascript by
Netscape, is a intentional ride on Sun Microsystem's Java marketing
propaganda. Javascript the language has no relations, affinity, or
similarity to Java the language.) From the graph we can see, that
Java's popularity went over C++ but fell slightly below C++ after the
dot com bubble burst.
Postscript & Colophon
The data source is google's newsgroup archive. For example, «http://
groups.google.com/group/comp.lang.javascript/about»
A perl script is used to retrieve the data and parse it into a form
readable by Mathematica. The perl script that does this is here:
parse_data.pl
The data is then feed into Mathematica and plotted there. The
Mathematica notebook is here: language_traffic.nb.zip
This report examed all major languages in the “comp.lang.*” hierarchy.
Any “comp.lang.*” newsgroup either has a traffic below the
“comp.lang.lisp” shown on this page, or is already represented here.
For exmaple, there are several perl newsgroups “comp.lang.perl.*”, but
“comp.lang.perl.misc” is the most busy by far. Similarly,
“comp.lang.lisp.*” and “comp.lang.scheme.*” are represented by just
“comp.lang.lisp”. Languages such as Fortran, Pascall, Ada, Modula etc
don't have much traffic, nor languages like APL, Prolog, Logo, ML etc.
Also note, some language don't have a “comp.lang.*” newsgroup
presence, such as Microsoft's C# and F#. And, as noted before, some
languages are widely popular but don't have much newsgroup culture,
such as PHP and “comp.lang.basic.*”.
If you find a newsgroup that has more traffic than any language here,
please let me know.
Google provides search stats for any word. This is another way to
glean language trends. Example search:
* lisp,emacs
* php,javascript,perl
Some language names, such as Python, Java, lisp, can also mean a lot
other things. Pyhon usually means the snake, and also the a so-named
comedy show. Java can mean a type of coffee, or the island in
Indonesia. And, lisssp is a speech impediment, few knew. Therefore,
the google search stat may make spurious impressions.
2007-04, Addendum:
Programming Language Popularity, 2004, by David Welton. This article
survey's popularity by mostly google search.
http://www.dedasys.com/articles/language_popularity.html
Xah
···@xahlee.org
∑ http://xahlee.org/
Rainer Joswig wrote:
«...
Google Groups gives:
High Activity
* comp.lang.perl
* comp.lang.ruby
* comp.lang.python
* comp.lang.lisp
...»
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <IHG0i.8$DI4.6@newsfe12.lga>
Xah Lee wrote:
> Computer Language Popularity Trend
>
> Xah Lee, 2006-09
>
> This page gives a visual report of computer languages's popularity, as
> indicated by their traffic level in newsgroups. This is not a
> comprehensive or fair survey, but does give some indications of
> popularity trends.
>
> [The full version, with statistical charts is archived at
> “Computer Language Popularity Trend”
> http://xahlee.org/lang_traf/index.html
> ]
Nice charts. I see Lisp started to climb just when I announced Cells.
ken
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
In article <·······················@q75g2000hsh.googlegroups.com>,
Xah Lee <···@xahlee.org> wrote:
> Computer Language Popularity Trend
>
> Xah Lee, 2006-09
>
> This page gives a visual report of computer languages's popularity, as
> indicated by their traffic level in newsgroups. This is not a
> comprehensive or fair survey, but does give some indications of
> popularity trends.
>
> [The full version, with statistical charts is archived at
> “Computer Language Popularity Trend”
> http://xahlee.org/lang_traf/index.html
You could plot some trend line for each of the newgroups...
> If you find a newsgroup that has more traffic than any language here,
> please let me know.
http://groups.google.com/groups/dir?hl=en&sel=16823691
Google gives overviews about newgroups:
High Activity:
http://groups.google.com/groups/dir?hl=en&sel=16823691,83986080
Medium Activity:
http://groups.google.com/groups/dir?hl=en&sel=16823691,83986081
Low Activity:
http://groups.google.com/groups/dir?hl=en&sel=16823691,83986082
Newsgroups with
1000+ 'members'
http://groups.google.com/groups/dir?hl=en&sel=16823691,83986082,100763299
100+ 'members'
http://groups.google.com/groups/dir?hl=en&sel=16823691,83986082,100763299
>
> Google provides search stats for any word. This is another way to
> glean language trends. Example search:
>
> * lisp,emacs
> * php,javascript,perl
>
> Some language names, such as Python, Java, lisp, can also mean a lot
> other things. Pyhon usually means the snake, and also the a so-named
> comedy show. Java can mean a type of coffee, or the island in
> Indonesia. And, lisssp is a speech impediment, few knew. Therefore,
> the google search stat may make spurious impressions.
Haskell as a name is used for lots of other things.
>
> 2007-04, Addendum:
>
> Programming Language Popularity, 2004, by David Welton. This article
> survey's popularity by mostly google search.
> http://www.dedasys.com/articles/language_popularity.html
>
>
> Xah
> ···@xahlee.org
> ∑ http://xahlee.org/
>
>
> Rainer Joswig wrote:
> «...
> Google Groups gives:
>
> High Activity
> * comp.lang.perl
> * comp.lang.ruby
> * comp.lang.python
> * comp.lang.lisp
> ...»
--
http://lispm.dyndns.org
Rainer Joswig wrote:
> comp.lang.lisp has simply much more traffic than
> other newsgroups with some functional programming
> background.
That's why I'm here. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 11, 3:23 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Rainer Joswig wrote:
> > comp.lang.lisp has simply much more traffic than
> > other newsgroups with some functional programming
> > background.
>
> That's why I'm here. :-)
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Oh the sheer price of popularity.
On 2007-05-11 16:00:42 +0100, Antoan Jamison <·············@hotmail.com> said:
> Oh the sheer price of popularity.
He's a bit like Al-Qaeda: yes, they could have taken out a tower block
in Liechtenstein, but who'd care about that? Aim for the big
successful guys and make a mess of them if you can.
On May 11, 3:23 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Rainer Joswig wrote:
> > comp.lang.lisp has simply much more traffic than
> > other newsgroups with some functional programming
> > background.
>
> That's why I'm here. :-)
That's why you have such are hard time anyone convincing of your off-
topic commercial offerings.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Rainer Joswig wrote:
> Google Groups gives:
> ...
> Low Activity
> * fa.caml
> * comp.lang.haskell
It says "medium" here:
http://groups.google.com/group/fa.caml/about
http://groups.google.com/group/fa.haskell/about
Sounds like Google isn't being self-consistent, like Joe said... :-(
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
My apologies to the group for being tedious about this point.
Message-Id: <························@ptn-nntp-reader02.plus.net>
> On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> The question is then: what is Lisp syntax good for? I think the
>> answer is "not a lot", which is why the vast majority of programmers
>> moved on to something better over the past 50 years.
Message-ID: <·······················@u30g2000hsc.googlegroups.com>
> Joe Marshall wrote:
> This is an unfounded assertion.
Message-Id: <························@ptn-nntp-reader02.plus.net>
> John Harrop wrote:
> I already founded it and you replied with something like "Lisp syntax can
> only be compared to Lisp syntax".
Message-ID: <························@h2g2000hsg.googlegroups.com>
> Joe Marshall wrote:
> I don't believe I ever said that Lisp syntax can only be compared to
> Lisp syntax. If I did, would you please refer me to the message id?
> If I did not, would you be so kind as to not put words in my mouth?
Message-ID: <························@ptn-nntp-reader02.plus.net>
> John Harrop wrote:
> ·······················@e51g2000hsg.googlegroups.com
Here is that message reproduced in its entirety:
------------
> Forgive me for continuing this argument even though it isn't
> particularly relevant to Xah's original post.
>
> > Joe Marshall wrote:
> > > If the syntax is a problem, why haven't
> > > any alternative syntaxes taken over for s-expressions?
>
> On May 6, 3:45 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > They have.
>
> They have? Then where's the argument?
>
> I've been programming in lisp quite recently and I don't recall
> an algorithmic syntax. Did I miss something?
>
> > Mathematica uses more conventional syntax to handle expressions:
>
> What does this have to do with lisp?
>
> >
> > OCaml allows you to define infix operators and these can be used to compose
> > expressions.
> What does this have to do with lisp?
> >
> > So I think it is fair to say that s-exprs in Lisp have been superceded by
> > more efficient representations of expressions in most modern FPLs.
> This makes no sense. I ask why alternative lisp syntaxes never took
> off, and you tell me about the syntax of unrelated languages.
------------
At no point in this message did I say ``Lisp syntax can only be
compared to Lisp syntax'' or a similar statement.
To reiterate, would you be so kind as to not put words in my mouth?
Once again I apologize to the group for continuing this absurdity.
On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> The question is then: what is Lisp syntax good for? I think the
> answer is "not a lot", which is why the vast majority of programmers moved
> on to something better over the past 50 years.
I objected to this on the grounds that I doubt that the vast majority
of programmers have ever used Lisp (beyond perhaps a cursory look).
This is a natural prerequisite for `moving on'.
On May 10, 2:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> Lisp is taught at university. Most computer science students used it to
> learn the academic curiosity that is the metacircular evaluator.
Lisp is taught at many universities and colleges, but not all. Many
people here are probably aware that I have worked with Sussman and
more recently with Felleisen, so I'm not uninformed about this area.
There are *thousands* of colleges and universities in the United
States alone. Ed Martin of Schemers Inc. lists that 274 colleges/
universities use Scheme in their curricula (174 in the US). Given
that a person has a degree in Computer Science, it is still *unlikely*
that he was exposed to Lisp/Scheme at all during his education. If
you got a good exposure to Lisp or Scheme at univesity, you should
consider yourself lucky.
This is all that is needed to refute the claim that ``the vast
majority of programmers moved on to something better''.
I will address the other absurdities separately.
On 2007-05-10 21:49:44 +0100, Joe Marshall <··········@gmail.com> said:
> I will address the other absurdities separately.
Unless you're amusing yourself (which is what I've been doing in this
thread) I think there is abundant evidence that neither Harrop nor Lee
is actually listening to anything anyone else says.
On May 10, 2:03 pm, Tim Bradshaw <····@tfeb.org> wrote:
> On 2007-05-10 21:49:44 +0100, Joe Marshall <··········@gmail.com> said:
>
> > I will address the other absurdities separately.
>
> Unless you're amusing yourself (which is what I've been doing in this
> thread) I think there is abundant evidence that neither Harrop nor Lee
> is actually listening to anything anyone else says.
I am amusing myself. I also enjoy `Portsmouth Sinfonia' , the Museum
of Bad Art ( http://www.museumofbadart.org/index.html ),
Schadenfreude, the Darwin Awards, etc.
Although Harrop isn't listening, I'm hoping to ensure that anyone
listening *to* him is employing some critical thinking.
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <pKS0i.64$ep4.36@newsfe12.lga>
Tim Bradshaw wrote:
> On 2007-05-10 21:49:44 +0100, Joe Marshall <··········@gmail.com> said:
>
>> I will address the other absurdities separately.
>
>
> Unless you're amusing yourself (which is what I've been doing in this
> thread) I think there is abundant evidence that neither Harrop nor Lee
> is actually listening to anything anyone else says.
>
Well the trick of folks like Harrop is to listen just enough so that one
can respond to a direct hit with multiple non-pointing counterpoints,
each more retarded than the last and each stated in an artfully needling
fashion guaranteed to make the sanest NG denizen continue the thread, as
if the /next/ direct hit will achieve any more than the last.
It's like playing paintball with a guy who keeps running around and
shooting, covered head to toe in paint.
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Joe Marshall <··········@gmail.com> writes:
> Once again I apologize to the group for continuing this absurdity.
>
> On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> The question is then: what is Lisp syntax good for? I think the
>> answer is "not a lot", which is why the vast majority of programmers moved
>> on to something better over the past 50 years.
>
> I objected to this on the grounds that I doubt that the vast majority
> of programmers have ever used Lisp (beyond perhaps a cursory look).
> This is a natural prerequisite for `moving on'.
>
> On May 10, 2:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
>>
>> Lisp is taught at university. Most computer science students used it to
>> learn the academic curiosity that is the metacircular evaluator.
>
> Lisp is taught at many universities and colleges, but not all. Many
> people here are probably aware that I have worked with Sussman and
> more recently with Felleisen, so I'm not uninformed about this area.
> There are *thousands* of colleges and universities in the United
> States alone. Ed Martin of Schemers Inc. lists that 274 colleges/
> universities use Scheme in their curricula (174 in the US). Given
> that a person has a degree in Computer Science, it is still *unlikely*
> that he was exposed to Lisp/Scheme at all during his education. If
> you got a good exposure to Lisp or Scheme at univesity, you should
> consider yourself lucky.
>
> This is all that is needed to refute the claim that ``the vast
> majority of programmers moved on to something better''.
>
> I will address the other absurdities separately.
>
>
As a comp. sci grad, I can state that lisp was not used as the fundamental
language at my University. In fact, Lisp was only covered in a single semester
course on non-procedural languages, along with prolog, scheme and a number of
others. The language used for teaching and introductory courses was Pascal,
then C and now (god help us) I think they use Java.
Hardly any of the programmers I have known or worked with have done anything
more than a couple of weeks lisp and were not taught it at University. Mr
Harrop's claim, I suspect, is either totally misguiaded or based on what may
have been the case in the 70s and part of the 80s. I don't believe its the case
now. I also believe that most of the Universities used scheme for teaching and
not Common Lisp.
In fact, didn't someone post here a while back stating that MIT was dropping
scheme/lisp as the language they use for teaching comp. sci.
It is also curious that if lisp is so often used for teaching comp sci, how
come there seems to be so few introductory books on data structures and basic
algorithms based on those languages? I see lots of books using Pascal, C, C++
etc, but hardly ever find an intriductory text using a lisp and not a single
one I can think of that uses Common Lisp (I'm referring to academic type texts
and not excellent books like Peter's PCL).
The use of lisp to teaching comp sci is actually reasonably rare once you leave
the US. Australia uses Pascal/C at most Universities and Prolog seems far more
common in the UK than lisp (at least in the 80/90s and with respect to AI stuff
mainly).
I certainly have not seen any evidence of people who have really put in some
time learning CL switch to another language because of CLs syntax etc. In fact,
what I tend to see is lots of peple who stick with CL despite the fact there
are other languages out there with much larger or more standardised libraries
etc.
However, all of this is still irrelevant. Popularity is an uninteresting
measure at best. I'm still waiting for someone to actually show how CL's
utility is limited by its nested syntax as claimed by Xah. Sure, some people
don't like the syntax and maybe there is a better syntax, but how does the
current lisp syntax restrict its utility (or is utility being used here to
simply mean popularity?).
Tim
--
tcross (at) rapttech dot com dot au
On 2007-05-11 07:20:37 +0100, Tim X <····@nospam.dev.null> said:
> I certainly have not seen any evidence of people who have really put in some
> time learning CL switch to another language because of CLs syntax etc. In fact,
> what I tend to see is lots of peple who stick with CL despite the fact there
> are other languages out there with much larger or more standardised libraries
> etc.
In fact all the cases I know about have been people moving away from
Lisp because of (perceived) lack of libraries / compatibility etc with
other platforms & languages.
On May 10, 2:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> Google indexes over 1 million pages than mention Common Lisp. Were they
> written by people who had never tried Lisp?
Are you privy to the details of the Google corpus, or are you
estimating this based on the number displayed on the results page?
The number at the top of the results page (where it says Results 1 -
10 of 58,500,000 results (0.17 seconds)) is a *very* rough estimate.
If you look here:
http://www.trendmapper.com/charts/pages/-commonlisp-_id02042005-51.html
You will see the results count plotted for a year and a half. As you
can see, the number of results can vary wildly from week to week.
This is because the result count is estimated based on the density of
result URLs in the shard of the corpus at the data center you got
directed to.
Note, too, that a lot of these sucks/rocks sites work by performing a
Google query and examining the returned results count. It's amusing,
but hardly accurate.
> > Regardless of the reason, a handful of researchers does not a vast
> > majority create. ML and its descendants have *fewer* adherents than
> > Common Lisp.
>
> A Google trend search indicates that Common Lisp is now less common than any
> of OCaml, Haskell or Mathematica and that the trend is worsening for Lisp:
>
> http://www.google.com/trends?q=common+lisp%2C+ocaml%2C+haskell%2C+mat...
Heh heh, Google trends is quite a tricky tool. One difficulty in
using it is that the method of data collection and normalization is
not published. This can lead to odd looking results and
misinterpretation. Look at the note on the bottom of the page
``Google Trends aims to provide insights into broad search patterns.
As a Google Labs product, it is still in the early stages of
development. Also, it is based upon just a portion of our searches,
and several approximations are used when computing your results.
Please keep this in mind when using it.'' Also note that the results
graph on google trends does not have a scale for the Y axis.
But given that, let's take a look. First, let's see the trend for
`programming language'
http://www.google.com/trends?q=programming+language&ctab=0&geo=all&date=all
It appears as if people are becoming less interested in programming
languages over the years. What is actually happening is that as
Google grows into the consumer market, the number of more mundane
queries has grown considerably, making the *proportion* of programming
language queries smaller. The absolute numbers are not given, so we
cannot tell from this graph whether the absolute number of programming
language queries has risen or not. You'll see a general downward
trend for all the well-known languages.
Ok, so lets compare lisp and OCaml.
http://www.google.com/trends?q=lisp%2C+ocaml
Oh well.
I'd tried Haskell, but you can tell from the headlines that are
printed next to it, there are a bunch of Haskell hits that are not
related to the programming language.
Unfortunately, unless you have better access to Google trends, we
cannot fine tune the queries to exclude things like the Island of
Java, linked investment service provider (a financial instrument known
as a LISP), a huge number of math journals (DOCUMENTA MATHEMATICA,
Principia Mathematica, Philosophia Mathematica, etc.), various Schemes
and conspiracies, etc.
> Best case you'll argue that Haskell and Mathematica are homonyms. But OCaml
> isn't...
>
> > I'll be generous. Programmers of ML and its descendants *and* the
> > Mathematica programmers *and* all the F# programmers (count them)
> > *combined* are outnumbered by the Lisp programmers. (Source: TIOBE.
> > Lisp is at 0.698%, ML at 0.145%, OCaml at 0.103%, Mathematica at a
> > whopping 0.090%, and F# less than that).
>
> TIOBE's method is biased by Lisp's longer history.
Can you explain why that would result in a bias?
> Google code search is newer and says otherwise:
>
> Standard ML: 79
> Haskell: 101
> OCaml: 125
> Lisp: 172
Which numbers are these? These numbers appear unbelievably low. Do
you know the methodology for the search?
> Just adding two ML dialects (OCaml and SML), they outnumber all Lisp
> dialects (primarily emacs).
>
> Debian source package popularity says otherwise:
>
> http://popcon.debian.org/source/by_inst
>
> MLton: 55
> SMLNJ: 268
> CMUCL: 358
> SBCL: 637
> CLisp: 705
> GHC6: 1312
> OCaml: 7261
>
> OCaml is more than ten times as popular as the most popular Common Lisp
> compiler.
The popular commercial lisps are not distributed with debian.
> Google search hits with years in them:
I discussed the variability of this above.
>
> Does it suck:
>
> http://www.sucks-rocks.com/rate/commonlisp/ocaml/haskell/mathematica
Since this is based on the result count from Google, it is also of
questionable reliability.
> > Now it is one thing to assert that Lisp is less popular than Java, C, C
> > ++, etc. because of the syntax. It is *possible* that a large number
> > of these people saw Lisp at some point and thought `that's weird'.
> > However, the `vast majority' of programmers have had little to no
> > exposure to Lisp beyond a cursory overview and have hardly made an
> > informed decision about syntax. It is patently absurd (read that
> > `wrong') to assert that the `vast majority' of informed, experienced
> > Lisp hackers have abandoned the language over syntax.
>
> Best case you can claim that the large numbers of people aware of Lisp are
> not enlightented Lispers because they were just forced to learn Lisp at
> uni. If so, you've just eaten further into your dwindling popularity curve.
I claim that there aren't all *that* many people aware of Lisp and
that most of them weren't even forced to use it at uni. I claim that
of the number of people that have used lisp, then switched to ML or
OCaml or whatever, are hardly among the `vast majority' of Lisp
hackers, let alone the `vast majority' of programmers.
> > It is simply
> > incorrect to assert that ML or OCaml or Mathematica has superseded
> > Lisp in any catagory save obscurity.
>
> Given the above, this is at best debateable.
Some people won't engage in a battle of wits unless their opponent is
armed. I have no such scruples.
Joe Marshall wrote:
> On May 10, 2:44 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> Google indexes over 1 million pages than mention Common Lisp. Were they
>> written by people who had never tried Lisp?
>
> Are you privy to the details of the Google corpus, or are you
> estimating this based on the number displayed on the results page?
> The number at the top of the results page (where it says Results 1 -
> 10 of 58,500,000 results (0.17 seconds)) is a *very* rough estimate.
That is over one million.
> ...
> But given that, let's take a look. First, let's see the trend for
> `programming language'
>
http://www.google.com/trends?q=programming+language&ctab=0&geo=all&date=all
>
> It appears as if people are becoming less interested in programming
> languages over the years. What is actually happening is that as
> Google grows into the consumer market, the number of more mundane
> queries has grown considerably, making the *proportion* of programming
> language queries smaller. The absolute numbers are not given, so we
> cannot tell from this graph whether the absolute number of programming
> language queries has risen or not. You'll see a general downward
> trend for all the well-known languages.
You can normalize by whatever you want, the order Common Lisp < OCaml <
Haskell will be preserved.
> Unfortunately, unless you have better access to Google trends, we
> cannot fine tune the queries to exclude things like the Island of
> Java, linked investment service provider (a financial instrument known
> as a LISP), a huge number of math journals (DOCUMENTA MATHEMATICA,
> Principia Mathematica, Philosophia Mathematica, etc.), various Schemes
> and conspiracies, etc.
I already addressed this by not using homonyms as search terms.
>> TIOBE's method is biased by Lisp's longer history.
>
> Can you explain why that would result in a bias?
Counting stagnant web pages does not reflect current popularity. Lisp (like
flared trousers) is losing popularity. It is circling the drain. It is game
over, man. The methodology of the language has been relegated to the
history draws of theoretical classes, a weird curiosity like an albino
nubian.
>> Google code search is newer and says otherwise:
>>
>> Standard ML: 79
>> Haskell: 101
>> OCaml: 125
>> Lisp: 172
>
> Which numbers are these?
Google code search hits for different languages, enumerated by going to the
end of the search.
>> OCaml is more than ten times as popular as the most popular Common Lisp
>> compiler.
>
> The popular commercial lisps are not distributed with debian.
Ok. Allegro CL from Franz starts at $600. If they are selling enough to
impact the usage statistics they would be hugely wealthy, so I doubt
they're selling any more than MMA, for example.
Google fight:
"Allegro CL 8.0": 1,030
"Mathematica 6": 297,000
Oh man, oh, <gush> <gush>, I feel Lisp's life force fading. Wolfram just
ripped out your heart, stuck it in a blender and hit "frappee". Thank God
you're in groundhog day with Bill Murray and John McCarthy so you can wake
up tomorrow to read a post by Xah about Lisp missing the pattern matching
wagon.
>> http://www.sucks-rocks.com/rate/commonlisp/ocaml/haskell/mathematica
>
> Since this is based on the result count from Google, it is also of
> questionable reliability.
That was just a bit of fun. :-)
>> Best case you can claim that the large numbers of people aware of Lisp
>> are not enlightented Lispers because they were just forced to learn Lisp
>> at uni. If so, you've just eaten further into your dwindling popularity
>> curve.
>
> I claim that there aren't all *that* many people aware of Lisp and
> that most of them weren't even forced to use it at uni. I claim that
> of the number of people that have used lisp, then switched to ML or
> OCaml or whatever, are hardly among the `vast majority' of Lisp
> hackers, let alone the `vast majority' of programmers.
You quoted ~300 universities teaching Scheme, which is ~30,000 people per
year. Why do they move onto other (infix) languages? Could this explain why
your teaching of s-exprs leads to the worst employment statistics for
computer science graduates among any technical subject outside of
Uzbekistan?
>> > It is simply
>> > incorrect to assert that ML or OCaml or Mathematica has superseded
>> > Lisp in any catagory save obscurity.
>>
>> Given the above, this is at best debateable.
>
> Some people won't engage in a battle of wits unless their opponent is
> armed. I have no such scruples.
Bring it on, wide boy. I'll just confuse you by writing in colors that your
green-tinted CRT can't handle...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 6:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> You can normalize by whatever you want, the order Common Lisp < OCaml <
> Haskell will be preserved.
I cannot reproduce your results:
http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
Lisp is clearly above the other two.
Joe Marshall wrote:
> I cannot reproduce your results:
> http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
>
> Lisp is clearly above the other two.
Lisp is a homonym, use "common lisp".
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 11, 12:29 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > I cannot reproduce your results:
> >http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
>
> > Lisp is clearly above the other two.
>
> Lisp is a homonym, use "common lisp".
Ha ha, yes... as opposed to haskell you mean. As in "Haskell goes from
serious fall to the Super Bowl" or "Haskell could be all-Jersey
affair", taken from that same trend page. Ought to be a hint i should
think. If only a computer language could be that popular.
/Ties
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr5u2ewnpqzri1@pandora.upc.no>
On Fri, 11 May 2007 13:32:28 +0200, Ties Stuij <·······@gmail.com> wrote:
> On May 11, 12:29 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Joe Marshall wrote:
>> > I cannot reproduce your results:
>> >http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
>>
>> > Lisp is clearly above the other two.
>>
>> Lisp is a homonym, use "common lisp".
>
> Ha ha, yes... as opposed to haskell you mean. As in "Haskell goes from
> serious fall to the Super Bowl" or "Haskell could be all-Jersey
> affair", taken from that same trend page. Ought to be a hint i should
> think. If only a computer language could be that popular.
>
> /Ties
>
Fotball is the most popular language and I just wrote it ;)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 11, 12:29 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > I cannot reproduce your results:
> >http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
>
> > Lisp is clearly above the other two.
>
> Lisp is a homonym, use "common lisp".
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
Common lispers call their language just lisp, schemers use usually
scheme. Considering in modern days lisp family stands for common
lisp , scheme and some remainings , lisp name goes for common lisp in
almost all cases (though I couldn't find correct %). If you see
subscribers while fa.haskell 353 / comp.lang.haskell 154 , ocaml-
developer 102, F# 18
while Scheme 1364 subscribers and comp.lang.lisp 2995 and
counting (unless you're unaware this is a group for common lisp not
lisp family of langauges) . Even lisp (common lisp) is far more
popular than haskell (language) , ocaml & f# togather 1 / 5 .I could
probably go on comparing messages posted in last quartal or semester
in each group but this is getting very boring.
BTWthe games you link at your site looked nice so I wanted to give you
some credit if they were made with any langauge you promote like
Ocaml, Haskell & F#, but preaching that functional programming is the
savior and using other languages feathers (c++) is discusting. That
feels like saying that lisp (oops common lisp) is great for games and
linking Grand Theft Auto.
cheers
bobi
fireblade wrote:
> Common lispers call their language just lisp, schemers use usually
> scheme.
Yes. The problem is that both Lisp and Scheme are homonyms, so there is no
point in searching for them. Haskell is too, but not as common.
> Considering in modern days lisp family stands for common
> lisp , scheme and some remainings , lisp name goes for common lisp in
> almost all cases (though I couldn't find correct %). If you see
> subscribers while fa.haskell 353 / comp.lang.haskell 154 , ocaml-
> developer 102,
fa.caml mainly copies the caml mailing list. If you post there, you're
unlikely to get a response. Apparently there were 1,100 subscribers three
years ago:
http://caml.inria.fr/resources/forums.en.html
That will have increased 3-4x since then.
> F# 18
I didn't even know there was an F# list. Where is it? Apparently the F# Hub
has ~360 subscribers.
> while Scheme 1364 subscribers and comp.lang.lisp 2995
and where do you get these numbers from? Google currently says ~100 recent
authors for all of lisp, caml and haskell.
> Even lisp (common lisp) is far more popular than haskell (language)
Can you cite some references?
> BTWthe games you link at your site looked nice so I wanted to give you
> some credit if they were made with any langauge you promote like
> Ocaml, Haskell & F#, but preaching that functional programming is the
> savior and using other languages feathers (c++) is discusting. That
> feels like saying that lisp (oops common lisp) is great for games and
> linking Grand Theft Auto.
We use lots of languages, not just OCaml/F#. We have products written in C#
and Mathematica, for example. The "fun" page on our site is a filler of
random fun things, nothing to do with our work and nothing to do with
functional programming.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 11, 3:39 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> fireblade wrote:
> > Common lispers call their language just lisp, schemers use usually
> > scheme.
>
> Yes. The problem is that both Lisp and Scheme are homonyms, so there is no
> point in searching for them. Haskell is too, but not as common.
>
> > Considering in modern days lisp family stands for common
> > lisp , scheme and some remainings , lisp name goes for common lisp in
> > almost all cases (though I couldn't find correct %). If you see
> > subscribers while fa.haskell 353 / comp.lang.haskell 154 , ocaml-
> > developer 102,
>
> fa.caml mainly copies the caml mailing list. If you post there, you're
> unlikely to get a response. Apparently there were 1,100 subscribers three
> years ago:
>
> http://caml.inria.fr/resources/forums.en.html
>
> That will have increased 3-4x since then.
That's implementation specific forum, getting data from all lisp
(oops common lisp) mailing lists and forum like ECL, Lispworks HUG,
etc would take too much time.
>
> > F# 18
>
> I didn't even know there was an F# list. Where is it? Apparently the F# Hub
> has ~360 subscribers.
>
Hey hey thrash talking is Ok but no lies please , you posted about
your blog there:
From: "Dr Jon D Harrop" <····@ffconsultancy.com>
Date: Sun, 03 Dec 2006 14:10:52 -0800
Local: Mon, Dec 4 2006 12:10 am
Subject: F# news blog
Reply to author | Forward | Print | Individual message | Show original
| Report this message | Find messages by this author
For anyone who is interested, I started a blog on F# recently:
http://fsharpnews.blogspot.com
which has articles on various F#-related things that interest me.
http://groups.google.com/group/FSharp/browse_thread/thread/6233d2c0dcafd448
> > while Scheme 1364 subscribers and comp.lang.lisp 2995
>
> and where do you get these numbers from? Google currently says ~100 recent
> authors for all of lisp, caml and haskell.
comp.lang.lisp
Discussion about LISP.
Category: Computers > Programming, Language: English
High activity, 2995 subscribers, Usenet
http://groups.google.com/groups/dir?&sel=33583259&expand=1
comp.lang.scheme
The Scheme Programming language.
Category: Computers > Programming, Language: English
Medium activity, 1365 subscribers, Usenet
http://groups.google.com/groups/dir?&sel=33554433,33584255,33583294&usenet_st=1
fa.caml
235 subscribers - Last message: 6 minutes ago
comp.lang.ml
ML languages including Standard ML, CAML, Lazy ML, etc. (Moderated)
354 subscribers - Last message: 2 days ago
http://groups.google.com/groups/search?q=caml&qt_s=Search
fa.haskell
353 subscribers - Last message: 5 minutes ago
comp.lang.haskell
154 subscribers - Last message: 21 hours ago
http://groups.google.com/groups/search?q=haskell&qt_s=Search
>
> > Even lisp (common lisp) is far more popular than haskell (language)
>
> Can you cite some references?
>
See above
cheers
bobi
On May 11, 4:31 pm, fireblade <·················@gmail.com> wrote:
> On May 11, 3:39 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
>
>
>
>
> >firebladewrote:
> > > Common lispers call their language just lisp, schemers use usually
> > > scheme.
>
> > Yes. The problem is that both Lisp and Scheme are homonyms, so there is no
> > point in searching for them. Haskell is too, but not as common.
>
> > > Considering in modern days lisp family stands for common
> > > lisp , scheme and some remainings , lisp name goes for common lisp in
> > > almost all cases (though I couldn't find correct %). If you see
> > > subscribers while fa.haskell 353 / comp.lang.haskell 154 , ocaml-
> > > developer 102,
>
> > fa.caml mainly copies the caml mailing list. If you post there, you're
> > unlikely to get a response. Apparently there were 1,100 subscribers three
> > years ago:
>
> > http://caml.inria.fr/resources/forums.en.html
>
> > That will have increased 3-4x since then.
>
> That's implementation specific forum, getting data from all lisp
> (oops common lisp) mailing lists and forum like ECL, Lispworks HUG,
> etc would take too much time.
>
>
>
> > > F# 18
>
> > I didn't even know there was an F# list. Where is it? Apparently the F# Hub
> > has ~360 subscribers.
>
> Hey hey thrash talking is Ok but no lies please , you posted about
> your blog there:
>
> From: "Dr Jon D Harrop" <····@ffconsultancy.com>
> Date: Sun, 03 Dec 2006 14:10:52 -0800
> Local: Mon, Dec 4 2006 12:10 am
> Subject: F# news blog
> Reply to author | Forward | Print | Individual message | Show original
> | Report this message | Find messages by this author
> For anyone who is interested, I started a blog on F# recently:http://fsharpnews.blogspot.com
> which has articles on various F#-related things that interest me.http://groups.google.com/group/FSharp/browse_thread/thread/6233d2c0dc...
>
> > > while Scheme 1364 subscribers and comp.lang.lisp 2995
>
> > and where do you get these numbers from? Google currently says ~100 recent
> > authors for all of lisp, caml and haskell.
>
> comp.lang.lisp
> Discussion about LISP.
> Category: Computers > Programming, Language: English
> High activity, 2995 subscribers, Usenethttp://groups.google.com/groups/dir?&sel=33583259&expand=1
>
comp.lang.lisp - Show matching messages from this group
Discussion about LISP.
Category: Computers > Programming, Language: English
High activity, 3000 subscribers, Usenet
> comp.lang.scheme
> The Scheme Programming language.
> Category: Computers > Programming, Language: English
> Medium activity, 1365 subscribers, Usenethttp://groups.google.com/groups/dir?&sel=33554433,33584255,33583294&u...
>
comp.lang.scheme
The Scheme Programming language.
1365 subscribers - Last message: 26 hours ago
> fa.caml
> 235 subscribers - Last message: 6 minutes ago
> comp.lang.ml
> ML languages including Standard ML, CAML, Lazy ML, etc. (Moderated)
> 354 subscribers - Last message: 2 days agohttp://groups.google.com/groups/search?q=caml&qt_s=Search
>
fa.caml
235 subscribers - Last message: 39 minutes ago
comp.lang.ml
ML languages including Standard ML, CAML, Lazy ML, etc. (Moderated)
353 subscribers - Last message: 40 hours ago
> fa.haskell
> 353 subscribers - Last message: 5 minutes ago
> comp.lang.haskell
> 154 subscribers - Last message: 21 hours agohttp://groups.google.com/groups/search?q=haskell&qt_s=Search
>
fa.haskell
353 subscribers - Last message: 45 minutes ago
comp.lang.haskell
154 subscribers - Last message: 2 days ago
Maybe Mr Harrop is lisp fan who impersonates a troll and draws
traffic to this group/Whatever he is obviously we should be gratefull
to him. (or maybe not)
cheers
bobi
How the heck do you count the number of subscribers to comp.lang.lisp?
Seems to me a silly notion, if you have any notion at all how nntp works.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
In article <···············@shuttle.math.ntnu.no>,
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> How the heck do you count the number of subscribers to comp.lang.lisp?
> Seems to me a silly notion, if you have any notion at all how nntp works.
They count the subscribers to a newsgroup using Google Groups.
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote:
> Harald Hanche-Olsen <······@math.ntnu.no> wrote:
>
>> How the heck do you count the number of subscribers to comp.lang.lisp?
>> Seems to me a silly notion, if you have any notion at all how nntp works.
>
>They count the subscribers to a newsgroup using Google Groups.
Which implies not having any notion at all on how nntp works.
I receive c.l.l postings from two different usenet providers, neither
one is Google.
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
On May 13, 4:14 pm, Roberto Waltman <······@rwaltman.net> wrote:
> Rainer Joswig <······@lisp.de> wrote:
> > Harald Hanche-Olsen <······@math.ntnu.no> wrote:
>
> >> How the heck do you count the number of subscribers to comp.lang.lisp?
> >> Seems to me a silly notion, if you have any notion at all how nntp works.
>
> >They count the subscribers to a newsgroup using Google Groups.
>
> Which implies not having any notion at all on how nntp works.
> I receive c.l.l postings from two different usenet providers, neither
> one is Google.
>
> Roberto Waltman
>
> [ Please reply to the group,
> return address is invalid ]
It assumes that lisp : scheme : haskell : ocaml users who use Google
as their usenet provider has same proportion as lisp : scheme :
haskell : ocaml users who use all usenet providers . This assumption
might be completely wrong like most of lisp users use google and very
few haskell use google , in that case lisp numbers would be
overstated, or it might be completely the opposite, very few lispers
use google & a lot of haskell folks use google in that case lisp
percentage would be understated . Hell you can't make a perfect test,
but butter some numbers than none at all.
Mark Twain: There are three kinds of lies: lies, damned lies, and
statistics
cheers
bobi
fireblade wrote:
> Hell you can't make a perfect test, but butter some numbers than none at
> all.
Yes. I'm not really happy with any of the measures used. Especially Google
Code Search and Joe's job search as the numbers are far too small.
Can we try another debate? What proportion of all programmers use functional
programming languages? I think that should exclude Excel but include
(maybe) Ruby?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 14, 8:02 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Can we try another debate? What proportion of all programmers use functional
> programming languages? I think that should exclude Excel but include
> (maybe) Ruby?
Be serious. Ruby is no more a functional programming language than
Perl, Java or Lisp.
If you count things that actually are functional programming languages
(rather than whatever is convenient to make some stupid point) the
answer is simple: essentially no one.
On May 14, 9:02 am, Jon Harrop <····@ffconsultancy.com> wrote:
> fireblade wrote:
> > Hell you can't make a perfect test, but butter some numbers than none at
> > all.
>
> Yes. I'm not really happy with any of the measures used. Especially Google
> Code Search and Joe's job search as the numbers are far too small.
>
> Can we try another debate?
No , enaphe debates. There's a programs that won't write itself.
>What proportion of all programmers use functional
> programming languages? I think that should exclude Excel but include
> (maybe) Ruby?
Lispers are usually polyglots. How would you count folks like me,
using more or less actively Delphi, SQL, Common Lisp, C++ & C#. Now
I'm learning Erlang . yesterday started some basic applications with
mnesia and yaws.
I'm (just) starting to understand why are you pointing non stop to
automatic pattern matching, but that's completely not a lisp
style .When/if lisper needs ML like mattern matching they'll implement
it, look at termite for example.I don't have time to find common lisp
example. One thing that I disliked going through Erlang and your Ocaml
examples is that both languages aren't orthogonal . Too many rules, to
many exceptions to many special purpose things. Lisp power is
simplicity you can grasp it's syntax in notime and stay consistent. As
I said don't trust me try lisp for yourself it might change your mind
or confirm your expectations. And be nicer to people it'll brought you
more sales .Your staff is good , I tried your Ocaml tutorials though
I'm not interested anymore in graphics, but your attitude sucks . If
you want to discuss in this group fine but respect people and they
will respect you. Else all you ever get is a negative bias to whatever
you offer.
with best regards
bobi
In article <··································@4ax.com>,
Roberto Waltman <······@rwaltman.net> wrote:
> Rainer Joswig <······@lisp.de> wrote:
> > Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> >
> >> How the heck do you count the number of subscribers to comp.lang.lisp?
> >> Seems to me a silly notion, if you have any notion at all how nntp works.
> >
> >They count the subscribers to a newsgroup using Google Groups.
>
> Which implies not having any notion at all on how nntp works.
> I receive c.l.l postings from two different usenet providers, neither
> one is Google.
I understand that.
Google has an online reader where you can subscribe to an newsgroup
(Usenet and others). All you see are the users of the Google News
Reader software. It is somewhat popular, so you could
assume that the popularity there is some kind of indication.
It is clear to me (and you) that this is only a fraction
of Usenet readers. Users which are using Emacs' GNUS
and some other NNTP service are not measured. ;-)
>
> Roberto Waltman
>
> [ Please reply to the group,
> return address is invalid ]
--
http://lispm.dyndns.org
On 2007-05-13 15:14:50 +0100, Roberto Waltman <······@rwaltman.net> said:
> Which implies not having any notion at all on how nntp works.
> I receive c.l.l postings from two different usenet providers, neither
> one is Google.
I imagine hey understand perfectly well how NNTP works. However they
have a rather obvious incentive to push their own interface, so those
are the subscribers they count. Apart from anything this is the
information of interest to advertisers.
On May 11, 3:39 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> fireblade wrote:
> > Common lispers call their language just lisp, schemers use usually
> > scheme.
>
> Yes. The problem is that both Lisp and Scheme are homonyms, so there is no
> point in searching for them. Haskell is too, but not as common.
>
> > Considering in modern days lisp family stands for common
> > lisp , scheme and some remainings , lisp name goes for common lisp in
> > almost all cases (though I couldn't find correct %). If you see
> > subscribers while fa.haskell 353 / comp.lang.haskell 154 , ocaml-
> > developer 102,
>
> fa.caml mainly copies the caml mailing list. If you post there, you're
> unlikely to get a response.
That's why I don't post there I actually want to get response and
preferably fast, that's beside caml is plain ugly.
Apparently there were 1,100 subscribers three
> years ago:
>
> http://caml.inria.fr/resources/forums.en.html
>
> That will have increased 3-4x since then.
>
The Caml Mailing List had about 800 subscribers in 2004 everything
else is plain fiction
> Dr Jon D Harrop, Flying Frog Consultancy
Shameless advertisement snipped
Antoan
On May 11, 12:29 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > I cannot reproduce your results:
> >http://www.google.com/trends?q=lisp%2C+haskell%2C+ocaml
>
> > Lisp is clearly above the other two.
>
> Lisp is a homonym, use "common lisp".
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
Lispers are common lisp programmers like in this group called
comp.lang.lisp , nobody wants to write common lisp when there's no
specific need.
On Thu, 10 May 2007 15:28:58 -0700, Joe Marshall wrote:
> Ok, so lets compare lisp and OCaml.
> http://www.google.com/trends?q=lisp%2C+ocaml
Throw something of a curve into the question: add fortran and matlab in,
for kicks... (avoiding languages with English-word names)
Cheers,
--
Andrew
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr2yp4rhpqzri1@pandora.upc.no>
On Wed, 09 May 2007 22:45:14 +0200, Jon Harrop <···@ffconsultancy.com>
wrote:
> Xah made an excellent point in his original post about Mathematica users
> have the choice and choosing anything but prefix notation.
>
Except the the infix notation gets converted to prefix notation under the
hood
anyhow. And yes it does greatly simplify the whole program.
Remember that Wolfram started out with macsygma where he was a active
contributor in early 80's.
I throughly disagree that pattern matching is a glorified if.
That is like saying that a PLA is the same as a ROM.
Pattern matching works well on sparse state spaces.
This allows levels of reasoning orders of magnitude larger that with if.
It is kinda like saying that everything a inference engine does can be
achieved with nested if's.
In theory this might be true if you could find a human capable of setting
up the state
matrix and he had infinite time and the computer infinite memory..
(A system capable of algebra can of course also handle boolean algebra)
Building things from the bottom up every time is time consuming and error
prone.
Personally I might like a pattern matcher in Lisp.
Pitman probly has a point about problems with type inference.
(Guess I should just write one and see for myself.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Except the the infix notation gets converted to prefix notation under the
> hood anyhow.
I'm not sure that is true in any meaningful sense. They are both part of the
same grammar and they both parse to the same data structure. A data
structure is neither infix nor prefix.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr3tr309pqzri1@pandora.upc.no>
On Thu, 10 May 2007 10:26:16 +0200, Jon Harrop <···@ffconsultancy.com>
wrote:
>
> I'm not sure that is true in any meaningful sense. They are both part of
> the
> same grammar and they both parse to the same data structure. A data
> structure is neither infix nor prefix.
>
right. The data-structure is that of a tree.
It has nothing to do with the syntax per se.
What I mean is that:
in: 1 + 3
becomes
-> Plus[1, 3]
and then is evaluated to
out: 4
this is quite similar to:
(+ 1 3)
4
There are differences between Mathematica's data-structure and sexpr's for
sure
but there is little doubt he got some ideas from Lisp.
The main difference is the way spesial forms like If[..] are handeled.
In mathemaica it is handeled by atributes to the tree node.
In lisp it is hard coded into the compiler (if (then) (else)) in a number
of special forms.
(Most Lisp compilers seem to reduce 'cond', 'case' etc. to 'if' under the
hood.
The spec dosn't tell you how the build the compiler of course.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> What I mean is that:
>
> in: 1 + 3
> becomes
> -> Plus[1, 3]
I don't think that is true.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Joe Marshall wrote:
>> On May 8, 11:14 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>> The question is then: what is Lisp syntax good for? I think the
>>> answer is "not a lot", which is why the vast majority of programmers
>>> moved on to something better over the past 50 years.
>>
>> This is an unfounded assertion.
>
> I already founded it and you replied with something like "Lisp syntax can
> only be compared to Lisp syntax".
>
>> In order to `move on' you are strongly implying that this vast
>> majority started with (or at least did substantial work with) Lisp
>> syntax, found it wanting in some way, and then abandoned this syntax
>> in favor of `something better'. There is ample evidence that this is
>> false.
>
> Lisp is a language lab. It was used by the original MLers. They were some of
> the many people who said "why the hell are we writing this intermediate
> language by hand?" and ditched it. I already cited lots of other people and
> Xah made an excellent point in his original post about Mathematica users
> have the choice and choosing anything but prefix notation.
>
but that does not provide the slightest proof of his assertion that it limits
the language. Everyone is bouncing back and forward with all these
unsubstantiated claims that s-exp is the reason people don't use lisp. I'm
still waiting to see any proof whatever that the syntax limits the language.
all this other stuff is just religious war in which neither perspective is any
more proven than the other - its turned into an arguement about taste, which
will never reach a conclusion.
--
tcross (at) rapttech dot com dot au
From: Wolfgang Mederle
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <yj9lkfw2uwo.fsf@elvis.mederle.de>
Jon Harrop wrote:
> Absolutely. But don't you think most people will find it easier to
> understand:
>
> a + b*c
>
> rather than:
>
> (+ a (* b c))
How about
a+b * c
?
--
Wolfgang Mederle
<URL:http://www.mederle.de/>
<URL:http://homepage.mac.com/madearl/>
AIM therealmadearl
On May 10, 3:09 pm, Wolfgang Mederle <·······················@gmx.de>
wrote:
> Jon Harrop wrote:
> > Absolutely. But don't you think most people will find it easier to
> > understand:
>
> > a + b*c
>
> > rather than:
>
> > (+ a (* b c))
>
> How about
>
> a+b * c
>
> ?
Oh, that's *easy* to understand. I can think of two ways to
understand it without even trying...
On 2007-05-10 23:09:11 +0100, Wolfgang Mederle
<·······················@gmx.de> said:
> a+b * c
or, to give a more realistic example: a>b? x : y << 2 + c
I have no idea what the value of that is, it might even be what I meant
it to be.
From: Aaron Hsu
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr2n8fkmm4y54h@illuminus>
On Wed, 09 May 2007 08:40:32 -0500, <········@gmail.com> wrote:
> But the power of S-expressions was discovered only some decade ago,
> and only with the help of computers.
> So it would in fact be possible to find a better way to express maths,
> and only computers are able to help us here.
I don't think this is strictly true. S-expressions, to my understanding,
are a simply an extension of Polish Notation (possibly called Cambridge
Polish Notation). [1] I believe Polish Notation was introduced in 1920 and
some of the benefits of prefix based notations were already demonstrated
there when applied to things like Logic and Mathematics. [2] Not to
mention, if we consider only Lisp, I believe the first incantations of
Lisp appeared around 1958, which is a little more than "some decade." [3]
So, in general I believe much of the power of prefix notations, and
subsequently, much of s-expression power was already seeing the light of
day 80 plus years ago.
[1] http://en.wikipedia.org/wiki/S-expression
[2] http://en.wikipedia.org/wiki/Polish_notation
[3] http://en.wikipedia.org/wiki/Lisp_programming_language
--
Aaron Hsu <·········@sacrificumdeo.net>
"No one could make a greater mistake than he who did nothing because he
could do only a little." - Edmund Burke
The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations
Xah Lee, 2006-03-15
In LISP languages, they use a notation like “(+ 1 2)” to mean “1+2”.
Likewise, they write “(if test this that)” to mean “if (test) {this}
else {that}”. LISP codes are all of the form “(a b c ...)”, where the
a b c themselves may also be of that form. There is a wide
misunderstanding that this notation being “prefix notation”. In this
article, i'll give some general overview of the meanings of Algebraic
Notation and prefix, infix, postfix notations, and explain how LISP
notation is a Functional Notation and is not a so-called prefix
notation or algebraic notation.
The math notation we encounter in school, such as “1+2”, is called
Infix Algebraic Notation. Algebraic notations have the concept of
operators, meaning, symbols placed around arguments. In algebraic
infix notation, different symbols have different stickiness levels
defined for them. e.g. “3+2*5>7” means “(3+(2*5))>7”. The stickiness
of operator symbols are normally called “Operator Precedence”. It is
done by giving a order specification for the symbols, or equivalently,
give each symbol a integer index, so that for example if we have
“a⊗b⊙c”, we can unambiguously understand it to mean one of “(a⊗b)⊙c”
or “a⊗(b⊙c)”.
In a algebraic postfix notation known as Polish Notation, there needs
not to have the concept of Operator Precedence. For example, the infix
notation “(3+(2*5))>7” is written as “3 2 5 * + 7 >”, where the
operation simply evaluates from left to right. Similarly, for a prefix
notation syntax, the evaluation goes from right to left, as in “> 7 +
* 5 2 3”.
While functional notations, do not employ the concept of Operators,
because there is no operators. Everything is a syntactically a
“function”, written as f(a,b,c...). For example, the same expression
above is written as “>( +(3, *(2,5)), 7)” or “greaterThan( plus(3,
times(2,5)), 7)”.
For lisps in particular, their fully functional notation is
historically termed sexp (short for S-Expression, where S stands for
Symbolic). It is sometimes known as Fully Parenthesized Notation. For
example, in lisp it would be (f a b c ...). In the above example it
is: “(> (+ 3 (* 2 5)) 7)”.
The common concepts of “prefix, postfix, infix” are notions in
algebraic notations only. Because in Full Functional Notation, there
are no operators, therefore no positioning to talk about. A Function's
arguments are simply explicitly written out inside a pair of enclosing
delimiters.
Another way to see that lisp notation are not “pre” anything, is by
realizing that the “head” f in (f a b c) can be defined to be placed
anywhere. e.g. (a b c f) or even (a f b c), and its syntax analysis
remains the same. In the language Mathematica, f(a b c) would be
written as f[a,b,c] where the argument enclosure symbols is the square
bracket instead of parenthesis, and argument separator is comma
instead of space, and the function symbol (or head) is placed in
outside and in front of the argument enclosure symbols.
The reason for the misconception that lisp notations are “prefix” is
because the head appears before the enclosed arguments. Such use of
the term “prefix” is a confusion engenderer because the significance
of the term lies in algebraic notation systems.
A side note: the terminology “Algebraic” Notation is a misnomer. It
seems to imply that such notations have something to do with the
branch of math called algebra while other notation systems do not. The
reason the name Algebraic Notation is used because when the science of
algebra was young, around 1700s mathematicians are dealing with
equations using symbols like “+ × =” written out similar to the way we
use them today. This is before the activities of systematic
investigation into notation systems as necessitated in the studies of
logic in 1800s or computer languages in 1900s. So, when notation
systems are actually invented, the conventional way of infixing “+ ×
=” became known as algebraic because that's what people think of when
seeing them.
----
This post is archived at:
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
···@xahlee.org
∑ http://xahlee.org/
From: Dan Bensen
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f1tnlf$m6u$1@wildfire.prairienet.org>
Xah Lee wrote:
> The common concepts of “prefix, postfix, infix” are notions in
> algebraic notations only.
The common concepts of computer programming are defined by computer
programmers, not by mathematicians. The term "prefix notation" when
used in the programming world does not indicate "algebraic prefix
notation" as defined by mathematicians. The word "prefix" is a generic
English word meaning roughly that the thing being referred to occurs
before something else. This accurately describes the position of
the operator in a Lisp s-expression.
> Another way to see that lisp notation are not “pre” anything, is by
> realizing that the “head” f in (f a b c) can be defined to be placed
> anywhere. e.g. (a b c f) or even (a f b c), and its syntax analysis
> remains the same.
Is this consistent with the CL spec or any standard Lisp spec?
I've never heard of such a thing.
--
Dan
www.prairienet.org/~dsb/
From: Malcolm McLean
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <maSdnYm_qt4VX9_bnZ2dnUVZ8tChnZ2d@bt.com>
"Dan Bensen" <··········@cyberspace.net> wrote in message
·················@wildfire.prairienet.org...
> Xah Lee wrote:
>> The common concepts of “prefix, postfix, infix” are notions in
>> algebraic notations only.
>
> The common concepts of computer programming are defined by computer
> programmers, not by mathematicians. The term "prefix notation" when
> used in the programming world does not indicate "algebraic prefix
> notation" as defined by mathematicians. The word "prefix" is a generic
> English word meaning roughly that the thing being referred to occurs
> before something else. This accurately describes the position of
> the operator in a Lisp s-expression.
>
>> Another way to see that lisp notation are not “pre” anything, is by
>> realizing that the “head” f in (f a b c) can be defined to be placed
>> anywhere. e.g. (a b c f) or even (a f b c), and its syntax analysis
>> remains the same.
>
> Is this consistent with the CL spec or any standard Lisp spec?
> I've never heard of such a thing.
>
What he is saying is that it is pure convention that the operator comes
first in the list. It could equally well be last, or second.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
On May 10, 7:58 am, "Malcolm McLean" <·········@btinternet.com> wrote:
>
> What he is saying is that it is pure convention that the operator comes
> first in the list. It could equally well be last, or second.
And of course what he's conveniently ignoring is that the position of
the operator is actually what matters. Like a lot of novices he's got
massively hung up on the parens and the other little punctuation
characters which programming languages need in order for the parser to
do a fast predictable job, but which experienced humans ignore.
Once you ignore the parens (or the other punctuation if you're reading
Java, say) you see a sequence of words, generally with line breaks and
indentation indicating what they are doing. And the difference
between languages then comes down largely to word order:
Lisp is verb first, or prefix:
do-this-operation thing other-thing ...
so is C. Natural languages like this would be called VSO in general.
Java is, in many cases, verb-second, or SVO:
thing operation other-thing ...
So is English in many cases.
Forth is verb-last, so is PS etc (possibly SOV).
Of course most programming languages have a mass of special cases for
arithmetic and logical operations. Lisp doesn't (but such a syntax
can easily be added of course). Some small number of languages allow
you to extend this special syntax: I think Prolog does this. Some
others do this horrible thing of not allowing that but allowing you to
overload the fixed set of special operators (not in the Lisp sense)
with other meanings: C++ is a notorious example. Java notably has
avoided this.
Obviously if you don't like Lisp being verb-first, you can make it be
anything else, see for instance http://www.tfeb.org/lisp/toys.html#SLIP.
Lots of syntax loonies get absurdly hung up on the maths stuff,
because that's typically one of the first things you learn in any
language, and since they never get beyond that stage they assume that
programs are mostly maths. Even mathematical monographs are not
mostly maths!
--tim
Tim Bradshaw wrote:
> Some
> others do this horrible thing of not allowing that but allowing you to
> overload the fixed set of special operators (not in the Lisp sense)
> with other meanings: C++ is a notorious example.
F# also lets you do this and I see it as an advantage.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 10:59 am, Jon Harrop <····@ffconsultancy.com> wrote:
> F# also lets you do this and I see it as an advantage.
Good, another reason not to use it then. I've always been a bit
ashamed that I read beyond the bit in the C++ book where they start
overloading the bit-shift operators to do I/O, and didn't give up in
disgust until I got to the incredibly-patronizing-guidance-about-
comments from Stroustrup.
Tim Bradshaw wrote:
> On May 10, 10:59 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> F# also lets you do this and I see it as an advantage.
>
> Good, another reason not to use it then. I've always been a bit
> ashamed that I read beyond the bit in the C++ book where they start
> overloading the bit-shift operators to do I/O, and didn't give up in
> disgust until I got to the incredibly-patronizing-guidance-about-
> comments from Stroustrup.
Ugh. Yes, ok I'd forgotten about that. F# doesn't overload any operators in
really stupid ways but there are a few things that I'm not too fond of
(like + for string concatenation). Part of the reason is legacy to make
C++/C# programmers feel at home.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Garry Hodgson
Subject: Re: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <2007051010291178807364@k2.sage.att.com>
Jon Harrop <···@ffconsultancy.com> wrote:
> Tim Bradshaw wrote:
> > Some
> > others do this horrible thing of not allowing that but allowing you to
> > overload the fixed set of special operators (not in the Lisp sense)
> > with other meanings: C++ is a notorious example.
>
> F# also lets you do this and I see it as an advantage.
my experience during many years of c++ is that operator overloading
is a Really Bad Idea. nice in theory, a mess in practice. you'd be
astonished (i was) at the bizarre notions people come up with for
overloading "+", for example ( apple + streetcar yields kangaroo,
while burning a cd as a side effect ).
yes, that's a made up example, but not far off the mark.
overloading would be fine if only sensible people used it,
but compiler technology is insufficiently advanced to
enforce that.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
On 2007-05-10 10:29:22 -0400, Garry Hodgson <·····@sage.att.com> said:
> you'd be
> astonished (i was) at the bizarre notions people come up with for
> overloading "+", for example ( apple + streetcar yields kangaroo,
> while burning a cd as a side effect ).
In my experience, apple + streetcar yields applesauce, so I think
frying a latke rather than burning a CD is the appropriate side effect
- and before you ask, yes, the kangaroo keeps the latkes warm in her
pouch ;^)
This is where I wish my sig were the quote from Harvey that Kenny uses.
From: John Thingstad
Subject: Re: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <op.tr4exd1wpqzri1@pandora.upc.no>
On Thu, 10 May 2007 16:29:22 +0200, Garry Hodgson <·····@sage.att.com>
wrote:
>
> yes, that's a made up example, but not far off the mark.
> overloading would be fine if only sensible people used it,
> but compiler technology is insufficiently advanced to
> enforce that.
>
Probaly best just to stick with the ones in STDLIB for streams.
Quite a chore to implement to.
It would have been much simpler with methods.
C++ classes needs to many friends ;)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Gian Uberto Lauri
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <87wszfpid1.fsf@mail.eng.it>
>>>>> Long count = 12.19.14.5.9; tzolkin = 7 Muluc; haab = 17 Uo.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "GH" == Garry Hodgson <·····@sage.att.com> writes:
GH> my experience during many years of c++ is that operator
GH> overloading is a Really Bad Idea.
Once upon a long ago I was fascinated by operators overloading.
"Geee, i can sum my RationalNumbers like i sum integers and floats,
wonderful".
Then I began to use a language that doesn't offer operator
overloading, and lived happily with it.
One nice day, I moved my cursor over the + in (+ 1 1) and typed C-h
C-f.
Emacs nicely responded "+ is a built-in function...". And I realized
that operators does not "exist", they are a formalism. What exists,
IMHO (my I.Q. tends to 0 from below), is something that takes one or
more "input parameters" and yelds a result.
And therefore I feel that operator overloading is not really useful,
not much more than doing
#define begin {
#define end ;}
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
to Caesar I woulda have said "mail me to ·····@rat.vg"
P.S.
And no. I feel that Emacs doesn't need to be modernized. It should be
the user that should get smarter... :)
From: Neelakantan Krishnaswami
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <slrnf46lkh.frs.neelk@gs3106.sp.cs.cmu.edu>
In article <························@l77g2000hsb.googlegroups.com>, Tim
Bradshaw wrote:
>
> Some others do this horrible thing of not allowing that but allowing
> you to overload the fixed set of special operators (not in the Lisp
> sense) with other meanings: C++ is a notorious example. Java
> notably has avoided this.
What? Java has dynamic method dispatch for method calls. That's
overloading, pure and simple. It can't matter whether your overloaded
call is written "x.add(y)" or "(+ x y)" or "x + y" -- the same thing
will happen.
I can certainly believe that the culture of the C++ community
encouraged people to do horrible things, but I don't see how it could
possibly be a property of the language itself.
If you think I'm wrong, I'd /genuinely/ like an explanation why,
because I've heard a lot of people I respect say similar things and I
just don't get it.
--
Neel R. Krishnaswami
·····@cs.cmu.edu
From: Tim Bradshaw
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f1vvlu$es6$1$8300dec7@news.demon.co.uk>
On 2007-05-10 18:29:53 +0100, Neelakantan Krishnaswami <·····@cs.cmu.edu> said:
> What? Java has dynamic method dispatch for method calls. That's
> overloading, pure and simple. It can't matter whether your overloaded
> call is written "x.add(y)" or "(+ x y)" or "x + y" -- the same thing
> will happen.
Can you, in Java, make 'x + y' mean, for instance 'add the row y to the
database table x'? I don't think you can. That expression, in Java,
is not a method call. You could however make 'x.add(y)' mean this, and
that would probably be a reasonable thing to do.
>
> I can certainly believe that the culture of the C++ community
> encouraged people to do horrible things, but I don't see how it could
> possibly be a property of the language itself.
It's a property of the language because it a small fixed number of
operators with fixed precedence and very well-known meanings (such as
<<). Either do the job properly (allow new operators with new
precedence rules etc) or don't do it at all.
--tim
From: Paul Rubin
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <7x7irgdp8k.fsf@ruckus.brouhaha.com>
Tim Bradshaw <···@tfeb.org> writes:
> Can you, in Java, make 'x + y' mean, for instance 'add the row y to
> the database table x'? I don't think you can. That expression, in
> Java, is not a method call. You could however make 'x.add(y)' mean
> this, and that would probably be a reasonable thing to do.
Python can certainly make 'x+y' act as you describe, and I don't hear
anyone complaining.
From: Tim Bradshaw
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <f22ims$itn$1$8300dec7@news.demon.co.uk>
On 2007-05-11 04:16:11 +0100, Paul Rubin <·············@NOSPAM.invalid> said:
> Python can certainly make 'x+y' act as you describe, and I don't hear
> anyone complaining.
You'd hear me if I wrote Python any more. Fortunately I don't, so I
won't (also I suspect but am not sure that you can create entirely new
operators in Python which, as I said, I'm fine with). I seem to
remember the article to which you responded was about Java however.
From: Garry Hodgson
Subject: Re: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <2007051120041178928296@k2.sage.att.com>
Paul Rubin <·············@NOSPAM.invalid> wrote:
> Python can certainly make 'x+y' act as you describe, and I don't hear
> anyone complaining.
maybe pythonistas have more sense than to use it. i don't recall ever
seeing it in python code.
----
Garry Hodgson, Senior Software Geek, AT&T CSO
nobody can do everything, but everybody can do something.
do something.
From: Andrew Reilly
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <5ag2hrF2omhc5U1@mid.individual.net>
On Thu, 10 May 2007 07:58:36 +0100, Malcolm McLean wrote:
> What he is saying is that it is pure convention that the operator comes
> first in the list. It could equally well be last, or second.
Well sure, but how was the dialog helped by saying it? It's one of the
conventions that makes lisp lisp. Putting the operator last makes it
forth, (more or less). Putting it in any other fixed location puts a
probably-inconvenient lower bound on function arity. Making the location
dependent on the operator means that you need some other information to
avoid ambiguities, like precedence. So lisp functions go first in the
list. That makes 'em prefixes in my book.
Cheers,
--
Andrew
From: Malcolm McLean
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <27-dnYVRT8ROF97bRVnytQA@bt.com>
"Andrew Reilly" <···············@areilly.bpc-users.org> wrote in message
····················@mid.individual.net...
> On Thu, 10 May 2007 07:58:36 +0100, Malcolm McLean wrote:
>
>> What he is saying is that it is pure convention that the operator comes
>> first in the list. It could equally well be last, or second.
>
> Well sure, but how was the dialog helped by saying it?
>
I've condensed Xah Lee's post into two sentences. I think that is worth
something.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
From: Markus E Leypold
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Date:
Message-ID: <im1whpsi47.fsf@hod.lan.m-e-leypold.de>
In another thread you wrote:
> In this thread, a few people already started to post completely off
> topic, brainless, pure personal attacks. I think you are still good.
The first off topic post in most Xah Lee thread, unfortunately, is the
first thread of the post -- yours.
> I wasn't sure, if you are just fucking with me, or really, really
> meant your writing as a valid argument to my thesis.
Basically these days we're are just trying to fuck with you, though
only in the metaphoric, sense, not really --
http://xahlee.org/PageTwo_dir/Personal_dir/mi_pixra/mi_lunbe_las_vegas_2003-10.jpg
[WARNING TO READERS: adult rated + rather dependend on your taste too]
is rather off putting in this respect.
BTW, this:
> Exactly. I've been using online forums since 1990. I've been using
> newsgroups since maybe 1994. If i wanted to play politics, given my IQ
> and my knowledge of computing, and great skill of composition, i might
> be a fucknig George Bush by now, with a massive army of morons at my
> commands, not like, the likes of some computing industry leaders.
(and the rest of that post) does sound pretty borderline to me. I
suggest that you look for some professional help.
On the other side ...
> Ken Tilton, also wrote something that's incredibly stupid.
you seem to be completely surrounded by morons, as also evidenced by
various entries in your blogs, at your Wikipedia page etc., which have
no understanding for your outstanding genius.
This indicates a real mismatch between your superior intelligence and
the rest of this poor moronic planet.
Perhaps it is time to transcendend now (to divinity) instead of
bombarding the world at large (well, a tiny corner of the usenet)
> comp.lang.lisp,comp.emacs,comp.lang.scheme,comp.lang.functional
with
> The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations
your (offtopic)
> Xah Lee, 2006-03-15
stale essays.
Regards -- Markus
The Merits of the Head of Expression Inside vs Outside the Parenthesis
Xah Lee. 2007-05
Lisp's nested parenthesis syntax is a Functional Notation. It has the
general form of “(f a b ...)” where any of the symbols inside the
matching parenthesis may again be that form. For example, here's a
typical code from Emacs Lisp.
(defun fold (f x li)
"Recursively apply (f x i), where i is the ith element in the list
li.\n
For example, (fold f x '(1 2)) computes (f (f x 1) 2)"
(let ((li2 li) (ele) (x2 x))
(while (setq ele (pop li2))
(setq x2 (funcall f x2 ele))
)
x2
)
)
Vast majority of computer languages, interpret source code in a one-
dimensional, linear nature. Namely, from left to right, line by line,
as in written text. (Examples of computer languages's source code that
are not linear in nature, are spread sheets, cellular automata,
graphical programing languages) For languages that interprets source
code linearly, the logics of their syntax necessarily have a
hierarchical structure (i.e. a tree). The lisp's notation, is the most
effective in visually showing the logics of the syntax. This is
because, a function and its arguments, are simply laid out inside a
parenthesis. The level of nesting corresponds to the “precedence” in
evaluating the expression.
The first element inside the matching parenthesis, is called the
“head” of the expression. For example, in “(f a b)”, the “f” is the
head. The head is a function, and the rest of the symbols inside the
matching parenthesis are its arguments.
The head of lisp's notation needs not to be defined as the first
element inside the parenthesis. For example, we can define the “head”
to be the last element inside the parenthesis. So, we write “(arg1
arg2 ... f)” instead of the usual “(f arg1 arg2 ...)” and its
syntactical analysis remains unchanged. Like wise, you can move the
head outside of the parenthesis.
In Mathematica, the head is placed in front of the parenthesis, and
square brackets are used instead of parenthesis for the enclosing
delimiter. For example, lisp's “(f a b c)” is syntactically equivalent
to Mathematica's “f[a,b,c]”. Other examples: “(sin θ)” vs “Sin[θ]”,
“(map f list)” vs “Map[f,list]”. Placing the head in front of the
matching bracket makes the notation more familiar, because it is a
conventional math notation.
However, there is a disadvantage in moving the head of a expression
from inside the matching bracket to outside. Namely: The nesting of
the matching delimiters, no longer corresponds to the logics of the
syntax, when the head is itself a compound expression.
For example, suppose Reflection(vectorV,pointP) is function that
returns a function f, such that f(graphicsData) will reflect the
graphicsData along a line passing pointP and parallel to vectorV. In
lisp, we would write “((Reflection vectorV pointP) graphicsData)”. In
Mathematica, we would write “Reflection[vectorV,pointP]
[graphicsData]”. In lisp's version, the nesting corresponds to the
logics of the evaluation. In the Mathematica's form, that is no longer
so.
For another example, suppose Deriv is a function that takes a function
f and returns a function g, and we want to apply g to a variable x. In
lisp, we would write “((Deriv f) x)”. In Mathematica, we would write
“Deriv[f][x]”. In lisp's version, the nesting corresponds to the
logics of the evaluation. In the Mathematica's form, the logics of the
evaluation no longer corresponds to the nesting level, because now the
head is outside of the enclosing delimiters, so the head of
expressions no longer nests. The merit of lisp's “(f x)” form versus
Mathematica's “f(x)” form.
------------
This post is excerpted from
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations”, archived at
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
···@xahlee.org
∑ http://xahlee.org/
The Merits of the Head of Expression Inside vs Outside the
Parenthesis
Xah Lee. 2007-05
Lisp's nested parenthesis syntax is a Functional Notation. It has the
general form of “(f a b ...)” where any of the symbols inside the
matching parenthesis may again be that form. For example, here's a
typical code from Emacs Lisp.
(defun fold (f x li)
"Recursively apply (f x i), where i is the ith element in the list
li.\n
For example, (fold f x '(1 2)) computes (f (f x 1) 2)"
(let ((li2 li) (ele) (x2 x))
(while (setq ele (pop li2))
(setq x2 (funcall f x2 ele))
)
x2
)
)
Vast majority of computer languages, interpret source code in a one-
dimensional, linear nature. Namely, from left to right, line by line,
as in written text. (Examples of computer languages's source code
that
are not linear in nature, are spread sheets, cellular automata,
graphical programing languages) For languages that interprets source
code linearly, the logics of their syntax necessarily have a
hierarchical structure (i.e. a tree). The lisp's notation, is the
most
effective in visually showing the logics of the syntax. This is
because, a function and its arguments, are simply laid out inside a
parenthesis. The level of nesting corresponds to the “precedence” in
evaluating the expression.
The first element inside the matching parenthesis, is called the
“head” of the expression. For example, in “(f a b)”, the “f” is the
head. The head is a function, and the rest of the symbols inside the
matching parenthesis are its arguments.
The head of lisp's notation needs not to be defined as the first
element inside the parenthesis. For example, we can define the “head”
to be the last element inside the parenthesis. So, we write “(arg1
arg2 ... f)” instead of the usual “(f arg1 arg2 ...)” and its
syntactical analysis remains unchanged. Like wise, you can move the
head outside of the parenthesis.
In Mathematica, the head is placed in front of the parenthesis, and
square brackets are used instead of parenthesis for the enclosing
delimiter. For example, lisp's “(f a b c)” is syntactically
equivalent
to Mathematica's “f[a,b,c]”. Other examples: “(sin θ)” vs “Sin[θ]”,
“(map f list)” vs “Map[f,list]”. Placing the head in front of the
matching bracket makes the notation more familiar, because it is a
conventional math notation.
However, there is a disadvantage in moving the head of a expression
from inside the matching bracket to outside. Namely: The nesting of
the matching delimiters, no longer corresponds to the logics of the
syntax, when the head is itself a compound expression.
For example, suppose Reflection(vectorV,pointP) is function that
returns a function f, such that f(graphicsData) will reflect the
graphicsData along a line passing pointP and parallel to vectorV. In
lisp, we would write “((Reflection vectorV pointP) graphicsData)”. In
Mathematica, we would write “Reflection[vectorV,pointP]
[graphicsData]”. In lisp's version, the nesting corresponds to the
logics of the evaluation. In the Mathematica's form, that is no
longer
so.
For another example, suppose Deriv is a function that takes a
function
f and returns a function g, and we want to apply g to a variable x.
In
lisp, we would write “((Deriv f) x)”. In Mathematica, we would write
“Deriv[f][x]”. In lisp's version, the nesting corresponds to the
logics of the evaluation. In the Mathematica's form, the logics of
the
evaluation no longer corresponds to the nesting level, because now
the
head is outside of the enclosing delimiters, so the head of
expressions no longer nests. The merit of lisp's “(f x)” form versus
Mathematica's “f(x)” form.
------------
This post is excerpted from
“The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations”, archived at
http://xahlee.org/UnixResource_dir/writ/notations.html
Xah
····@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> For another example, suppose Deriv is a function that takes a
> function
> f and returns a function g, and we want to apply g to a variable x.
> In
> lisp, we would write ?((Deriv f) x)?. In Mathematica, we would write
> ?Deriv[f][x]?.
It is probably worth noting that currying is comparatively uncommon in both
Lisp and Mathematica. The difference between the syntaxes is fairly small:
((f a) b) Lisp
f[a][b] Mathematica
f a b ML
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On 12 Mai, 05:13, Jon Harrop <····@ffconsultancy.com> wrote:
> Xah Lee wrote:
> > For another example, suppose Deriv is a function that takes a
> > function
> > f and returns a function g, and we want to apply g to a variable x.
> > In
> > lisp, we would write ?((Deriv f) x)?. In Mathematica, we would write
> > ?Deriv[f][x]?.
>
> It is probably worth noting that currying is comparatively uncommon in both
> Lisp
How do you know that?
> and Mathematica. The difference between the syntaxes is fairly small:
>
> ((f a) b) Lisp
Did you try it? It does not work. There is no currying in Lisp.
There is no such syntax in Common Lisp, Scheme, ...
You have to write a function for that or use a built-in curry function
(like in Dylan).
> f[a][b] Mathematica
> f a b ML
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
······@corporate-world.lisp.de wrote:
>> ((f a) b) Lisp
>
> ... It does not work ...
True. So you have to insert funcall at random places in Lisp, depending how
you defined your functions:
* (defun f (x) (lambda (y) (+ x y)))
* (funcall (f 1) 2)
3
Although this is a severe irritation, it is not a syntactic issue.
This is is fixed in Scheme, of course:
> (define (f x) (lambda (y) (+ x y)))
> ((f 2) 3)
5
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 12, 8:58 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
> >> ((f a) b) Lisp
>
> > ... It does not work ...
>
> True. So you have to insert funcall at random places in Lisp,
Again this is bullshit. Inserting FUNCALL at random (!!!) places won't
get
you anything.
> depending how
> you defined your functions:
>
> * (defun f (x) (lambda (y) (+ x y)))
>
> * (funcall (f 1) 2)
Aha, so not at random places, but exactly there where you want to call
a function object.
Another option is to write:
(defun f (x y) (+ x y))
(funcall (curry #'f 1) 2)
Given that one has a CURRY function somewhere else defined.
> 3
>
> Although this is a severe irritation, it is not a syntactic issue.
What is syntax then?
It clearly is a syntactic issue. The Lisp syntax does not include
currying. Check the ANSI CL Hyperspec, The Scheme R5RS document or
any other Lisp specification.
What you have shown is that one can do 'currying' by writing
curryied functions oneself. Sure. But that has nothing to do
with syntax for currying.
All you did was writing ((bla bla) bla) and claiming it was Lisp
syntax and
does some random foo. That is just crazy nonsense.
>
> This is is fixed in Scheme, of course:
>
> > (define (f x) (lambda (y) (+ x y)))
> > ((f 2) 3)
Ah, why post about Lisp when you have no idea about it?
Scheme is a Lisp-1, where Common Lisp is a Lisp-2 (or even Lisp-n).
Many users of Common Lisp don't see Lisp-1 as 'better'.
Actually I prefer (funcall (f 1) 2) over Scheme's ((f 1) 2) .
>
> 5
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
Commercial advertising deleted.
······@corporate-world.lisp.de wrote:
> Actually I prefer (funcall (f 1) 2) over Scheme's ((f 1) 2).
Absolutely. That Scheme code is clearly absurd.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Dan Bensen
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <f2404p$qmb$1@wildfire.prairienet.org>
Jon Harrop wrote:
> Although this is a severe irritation, it is not a syntactic issue.
Typing one extra word once in a while is not a "severe" irritation.
It may be "inconvenient" or a "minor" irritation, but it's not "severe"
in any "reasonable" sense of the word. Plus, it's based on a feature
that makes macros more convenient.
Specifically, funcall is required in CL because it has separate function
and variable namespaces. The double namespace was an intentional design
feature that makes macros more convenient. It was discussed twenty
years ago in this paper:
http://www.nhplace.com/kent/Papers/Technical-Issues.html
I believe Arc, and probably also Qi, have gone back to putting functions
and variables in the same namespace, but CL is optimized for DSLs and
exploratory programming, and macros are one of the best tools for that
area. Macros were clearly a higher design priority in CL, so you're
ignoring possibly the most important feature in the language while
complaining about a feature that was considered at least slightly less
important at the time, and may still be less important in experimental
areas like AI.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> I believe Arc, and probably also Qi, have gone back to putting functions
> and variables in the same namespace, but CL is optimized for DSLs and
> exploratory programming, and macros are one of the best tools for that
> area. Macros were clearly a higher design priority in CL, so you're
> ignoring possibly the most important feature in the language while
> complaining about a feature that was considered at least slightly less
> important at the time, and may still be less important in experimental
> areas like AI.
So you think it was a good design decision?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Dan Bensen
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <f24i6b$111$1@wildfire.prairienet.org>
> Dan Bensen wrote:
>> I believe Arc, and probably also Qi, have gone back to putting
>> functions and variables in the same namespace, but CL is optimized
>> for DSLs and exploratory programming, and macros are one of the best
>> tools for that area. Macros were clearly a higher design priority
>> in CL, so you're ignoring possibly the most important feature in
>> the language while complaining about a feature that was considered
>> at least slightly less important at the time, and may still be less
>> important in experimental areas like AI.
Jon Harrop wrote:
> So you think it was a good design decision?
That's one of the great mysteries of life that I've been interested
in lately. It makes intuitive sense to me that a language capable
of literally rewriting itself would be exceedingly expressive.
It seems reasonable that it might even have some sort of "Turing
meta-completeness" that other languages can't achieve without
Greenspunning, in the sense that code could scale as the log of
the number of features instead of linearly or worse.
As for functional programming, I'm impressed that it can do at least
some of the things that Lisp macros can do, and I accept the argument
that acting at a more semantically meaningful level is more reliable.
I'm also willing to entertain the Haskellers' contention that macros
may not be quite as expressive as monads, although even that may still
be more about reliability/debuggability than expressiveness.
But there are several things that I think still work in favor of
Lisp and macros, and by extension, the double namespace:
* Within the context of emphasizing macros, the Technical Issues article
makes it clear that the double namespace was an excellent decision.
The only argument against it was to support functional programming.
* It would be dumb if no-one had ever tried it. Obviously Lisp is
an exceedingly expressive language, mostly because it has the most
powerful macro system ever developed for a commonly used language.
* Macros seem to be ideal for exploratory RAD-type programming.
You just type out a template for what you want the code to look like,
and the macro generates it. Has Haskell or any other FPL caught on
in the AI community? I've never heard anything to that effect.
* DSLs are useful in just about any application. Macros are excellent
for encapsulating resource allocation and anything else that doesn't
fit the functional mold. Even if monads are theoretically more
expressive, they still seem harder to learn. Lisp's main useability
issue for newbies is the surface appearance of its non-syntax.
Monads, on the other hand, are just obtuse.
Criticizing CL's functional features while ignoring its macro system
is like criticizing the M1 Abrams tank because it doesn't do 150mph/
240kph, or criticizing a Mazarati because it gets bogged down in
a jungle or desert and it can't break down brick walls. I think
the Lisp design was a very good decision for what it was intended for.
Even when Lisp was created, anyone wanting faster performance for
relatively straightforward code could always use Fortran.
--
Dan
www.prairienet.org/~dsb/
From: Pascal Costanza
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <5aob32F2kh8irU1@mid.individual.net>
Dan Bensen wrote:
> I'm also willing to entertain the Haskellers' contention that macros
> may not be quite as expressive as monads, although even that may still
> be more about reliability/debuggability than expressiveness.
Monads can express first-class continuations, macros can't. On the other
hand, macros can express syntactic abstractions, while monads can't. So
there is definitely a difference in expressiveness.
The reason is that monads have access to aspects of the computation at
runtime, while macros exclusively operate on syntactic elements at
compile time. [1]
Pascal
[1] Or more correctly, macro-expansion time, but that doesn't matter here.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2007-05-12 15:21:21 +0100, Dan Bensen <··········@cyberspace.net> said:
> As for functional programming, I'm impressed that it can do at least
> some of the things that Lisp macros can do, and I accept the argument
> that acting at a more semantically meaningful level is more reliable.
> I'm also willing to entertain the Haskellers' contention that macros
> may not be quite as expressive as monads, although even that may still
> be more about reliability/debuggability than expressiveness.
[This article sat in an editor window for too long.]
A long time ago, I used to think that Lisp would be a better language
if the syntax contained more information about the semantics of the
language.
Unlike some, I'm not worried about how hard Lisp it to type, and I'm
happy with what the language looks like on the screen or page, and of
course because I'm reasonably competent at finding or writing Lisp I'm
not worried if I want to use it for some domain where there are better
or more well-understood visual representations, such as mathematics:
it's not that hard to define new surface syntax.
However it seemed to me to be a limitation that programs which
manipulate Lisp programs, such as macros, should have to deal with such
a low-level representation of the program they're manipulating.
Wouldn't it be better if they could deal with higher-level objects
rather than having to work out all the time that what things were. Of
course, having a standard, structured, representation of the source of
a program is a significant advantage over what most languages give you,
and makes Lisp-style macros possible in the first place. But sexps
seemed a bit low-level for the 90s.
For instance, if I defined a new surface syntax for Lisp - say
something that looked more like C or Java, then rather than retaining
all the extra information conveyed by, say "{ integer a = 5; ... }" I'd
have to translate it into some awful list "(LET ((A 5)) (DECLARE
(INTEGER A)) ...)" so macros could work on it, and discover, again, the
information which was there in the first place. Wouldn't it be better
to hand them, say, a BINDING-FORM object containing BINDINGs with type
information and a SEQUENCE-OF-FORMS or something which they could then
poke around in in a nice structured, modern way? I think it's obvious
this would be a win.
Except, may be it isn't so obvious. What if the program our program is
manipulating isn't actually Lisp, but is something else? For instance,
perhaps it's a program in a language which looks like Lisp but has the
semantics of Java, say. Suddenly we have to design an ontology for
this new language, which is a lot more work than just saying it's just
sexps. Even if we're not inventing a new language, we might be
creating new kinds of conceptual object in our Lisp source - a "loop
clause" say - which we now have to formalise before we can even talk
about them. Suddenly everything is rather heavyweight: perhaps we just
won't bother with extending the language after all.
Here's a very concrete and common example:
(with-html-output ()
((:ol :class db-class)
(loop for i in (select (name (count score))
:from scores
:where (> score 10)
:group-by score)
do (htm (:li (fmt "~S ~D" (first i) (second i)))))))
There are three sorts of thing in this form, two of them in rather
light disguise: Common Lisp, HTML/XML and SQL. In 8 lines of code.
Something like the above example is probably really rather common:
quite a lot of people want to generate web pages using the results of
database queries.
Providing a notation for structured data which is not too heavyweight
allows almost arbitrary stuff to be embedded in Lisp source code in a
way which can be manipulated by Lisp code. It may seem somewhat
primitive compared to the "right thing" solution, but it's a hell of a
lot quicker.
Sexps turn out to be a really good notation for this: they're simple,
sufficiently expressive, and adequately readable. It is probably not
coincidence that another fairly well-known and popular notation with
much the same aims has a form which is only trivially different than
sexps, although rather less expressive without special hacks (limited
data types, no easy way of expresssing sharing & circularity).
> On 2007-05-12 15:21:21 +0100, Dan Bensen <··········@cyberspace.net> said:
>> As for functional programming, I'm impressed that it can do at least
>> some of the things that Lisp macros can do, and I accept the argument
>> that acting at a more semantically meaningful level is more reliable.
>> I'm also willing to entertain the Haskellers' contention that macros
>> may not be quite as expressive as monads, although even that may still
>> be more about reliability/debuggability than expressiveness.
Tim Bradshaw wrote:
> A long time ago, I used to think that Lisp would be a better language if
> the syntax contained more information about the semantics of the language.
> Unlike some, I'm not worried about how hard Lisp it to type
Sorry if I gave you the wrong impression, but that's not what I was
talking about. One criticism of macros is that they're hard to debug
because their identity doesn't survive in the code once they're
expanded. Monads are just data types that define regular operators,
so they have semantic meaning that can be traced back to them at
runtime. To whatever extent monads and HOFs can do what macros do,
that's an argument in their favor.
I think I agree with everything you said though. Lisp's (non)syntax
reduces the problem of macros writing code to the almost trivial process
of slinging lists. Surface syntax is a minor issue when it buys you
that kind of expressiveness.
--
Dan
www.prairienet.org/~dsb/
On May 16, 2:31 am, Dan Bensen <··········@cyberspace.net> wrote:
> Sorry if I gave you the wrong impression, but that's not what I was
> talking about.
I know, I just needed somewhere to hang my article. I'm a sort of Jon
Harrop antiparticle you see - I'll followup to anything with some off-
topic pro-lisp point. I don't take money on my web site though, so
there's obviously some symmetry breaking here (actually, if I was an
antiparticle should I be giving money away on me website?)
Tim Bradshaw wrote:
> if I was an antiparticle should I be giving money away on me website?)
If you do, I'll annihilate you.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Tim Bradshaw wrote:
> > if I was an antiparticle should I be giving money away on me website?)
> If you do, I'll annihilate you.
Only if you collide.
From: Kent M Pitman
Subject: Re: A syntax of minimal commitment
Date:
Message-ID: <ur6ph8qv6.fsf@nhplace.com>
Tim Bradshaw <···@tfeb.org> writes:
> Sexps turn out to be a really good notation for this: they're simple,
> sufficiently expressive, and adequately readable.
To paraphrase Freud, in a somewhat ironic and out-of-context way,
"sometimes a symbol is just a symbol".
The issue isn't that special-purpose notations and representations
aren't better for a great many purposes. It's that special-purpose
notations and representations aren't better for all purposes. And
so, since Lisp is built for flexibility, it's better to just let
s-expressions be themselves, and to let other things be other things.
Lisp is like a hammer that is not obsoleted by the invention of a nail
gun. A nail gun makes certain specialized tasks easier but are not
very useful for tasks other than those particular tasks.
Lisp is also lot about "times" decisions are made. And the time at
which semantic analysis is done is different than read time. So even
if Lisp had this (and we tried to add it for ANSI CL but it was
untested technology that was no converging so we took it out; see
CLTL2 for a snapshot of the way it was originally heading before we
removed it), it would be offered differently than you're saying here.
But the important difference isn't the what but the when... Just as
we offer readmacros separately from regular macros and compiler
macros, I think the Lisp Way (if such a thing can be said to exist at
all) would have been to offer a notation _in addition to_ rather than
_instead of_ what we already provide. Fortunately, no one is really
precluded from doing that as an outboard library.
But back to the fact that expressions are read initially without
annotation: This is the very essence of symbol processing, and why it
is different than other forms of language processing that other
systems do with targeted syntaxes designed for an application. It's
not that it's about symbols per se, though there is something deep
about them as well. But it's about the notion of manipulating program
elements for which semantics has not yet attached. So it would indeed
be odd to insist that the first-chance access to what someone had
typed was one that had already seen semantic attachment.
Put another way: Other languages use text as their primitive
representation of structure that is not yet processed. Lisp just
likes a richer notion for being able to talk about structure before
semantics is attached. (Clearly this was a good idea or XML would not
have copied it. :)
On 2007-05-16 03:05:49 +0100, Kent M Pitman <······@nhplace.com> said:
> The issue isn't that special-purpose notations and representations
> aren't better for a great many purposes. It's that special-purpose
> notations and representations aren't better for all purposes. And
> so, since Lisp is built for flexibility, it's better to just let
> s-expressions be themselves, and to let other things be other things.
I think I disagree (or for the purposes of this article I disagree): I
think special-purpose notations and representations are always better.
*However* they also impose an enormous cost: any time you want to talk
about a new thing, you need a new special-purpose notation, and you
have to implement essentially an entirely new language, and that means
you never do that because it's so expensive. So actually they're not
better in one crucial sense, which is economics.
> On 2007-05-16 03:05:49 +0100, Kent M Pitman <······@nhplace.com> said:
>> The issue isn't that special-purpose notations and representations
>> aren't better for a great many purposes. It's that special-purpose
>> notations and representations aren't better for all purposes.
Tim Bradshaw wrote:
> I think I disagree ... I think special-purpose notations and represen-
> tations are always better. *However* they also impose an enormous cost
> So actually they're not better in one crucial sense, which is economics.
Which is probably what Kent meant in the first place. ;)
--
Dan
www.prairienet.org/~dsb/
On Wed, 16 May 2007 00:53:53 +0200, Tim Bradshaw <···@tfeb.org> wrote:
>
> Here's a very concrete and common example:
>
> (with-html-output ()
> ((:ol :class db-class)
> (loop for i in (select (name (count score))
> :from scores
> :where (> score 10)
> :group-by score)
> do (htm (:li (fmt "~S ~D" (first i) (second i)))))))
>
There is no provision in the ANSI standard for extending loop, though
many Lisp's have such extensions. (LispWorks CommonSQL interface is
written with custom loop extensions)
If you accept the iterate macro as a replacement for loop then it becomes
easy to make extensions to this as well.
(iter (for (name adress telephone-nr) in-record person)
...)
Just a thought.
(Iterate is avaliable at http://common-lisp.net/project/iterate/)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2007-05-16 04:53:28 +0100, "John Thingstad" <··············@chello.no> said:
> There is no provision in the ANSI standard for extending loop, though
> many Lisp's have such extensions. (LispWorks CommonSQL interface is
> written with custom loop extensions)
I was actually going to use another macro as you suggested, but I
thought that would make it even more silly. (The example doesn't extend
LOOP though)
Tim Bradshaw wrote:
>
> Sexps turn out to be a really good notation for this: they're simple,
> sufficiently expressive, and adequately readable. It is probably not
> coincidence that another fairly well-known and popular notation with
> much the same aims has a form which is only trivially different than
> sexps, although rather less expressive without special hacks (limited
> data types, no easy way of expresssing sharing & circularity).
>
Here is my take on why s-exps are the best overall general syntax choice
even though I have not done any Lisp development :)
The most powerful/general information representation mechanism (or data
structure or concept) is the graph. It allows arbitrary pieces of
information (nodes) to be associated with one or more other arbitrary
pieces of information. If you allow for directed , labeled edges, then
you pretty much can represent any information (including code, census
data or whatever)
( of course I have no idea how to prove this mathematically :) )
Currently two dimensional text is the most widely used mechanism for
transcribing programs.
To date, no one has figured out how to represent an arbitrary graph
using two dimensional text in a way that is convenient enough to input
using our usual text input mechanisms. If someone does, that would be
the most powerful syntax.
So, the next best thing to a graph is a tree (or a list of lists)
(ok, I know a tree is also a graph with no cycles etc.)
Now I don't know what my punch line should be. So here is a lame one:
S-EXP (or XML if you like that) represents a tree, so they are the best
choice we have
-Antony
On 2007-05-16 18:28:58 +0100, Antony Sequeira
<··················@gmail.com> said:
> Now I don't know what my punch line should be. So here is a lame one:
> S-EXP (or XML if you like that) represents a tree, so they are the best
> choice we have
That's a good sounding line of reasoning. Except of course that sexps
can represent general directed graphs, not just trees.
From: Tim Bradshaw
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <f247f3$hls$2$8302bc10@news.demon.co.uk>
On 2007-05-12 10:45:43 +0100, Jon Harrop <···@ffconsultancy.com> said:
> So you think it was a good design decision?
Absolutely.
From: Pascal Costanza
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <5alj66F2pn6jeU2@mid.individual.net>
Jon Harrop wrote:
> Dan Bensen wrote:
>> I believe Arc, and probably also Qi, have gone back to putting functions
>> and variables in the same namespace, but CL is optimized for DSLs and
>> exploratory programming, and macros are one of the best tools for that
>> area. Macros were clearly a higher design priority in CL, so you're
>> ignoring possibly the most important feature in the language while
>> complaining about a feature that was considered at least slightly less
>> important at the time, and may still be less important in experimental
>> areas like AI.
>
> So you think it was a good design decision?
Lisp-2 makes macro programming safer. See
http://www.nhplace.com/kent/Papers/Technical-Issues.html for more details.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza
Subject: Re: The Merits of the Head of Expression Inside vs Outside the Parenthesis
Date:
Message-ID: <5alc5cF2omgu8U1@mid.individual.net>
Jon Harrop wrote:
> ······@corporate-world.lisp.de wrote:
>>> ((f a) b) Lisp
>> ... It does not work ...
>
> True. So you have to insert funcall at random places in Lisp, depending how
> you defined your functions:
>
> * (defun f (x) (lambda (y) (+ x y)))
>
> * (funcall (f 1) 2)
>
> 3
Blablabla.
Inserting funcall in random places in the code is very likely to make
your code not work at all.
Just because currying isn't supported out of the box doesn't mean that
it is not widely used. To the contrary, using lambda to partially
provide some arguments to a function is rather common - most of the
time, I guess, people just don't realize that they are actually currying.
What do you think this is: (lambda (x y) (f 5 x 6 y 7)) ?
Note that this is more general than the kind of currying provided in
"mainstream" functional programming languages because you don't have to
change the order of arguments in function definitions just to make sure
that the common cases of currying work fine.
Addying a currying operator to Lisp is a trivial exercise, if you're
still not convinced. It doesn't matter that it's not standardized. No
programming language can provide all language constructs known to
mankind. That's why it's better to have a programmable programming
language because you then have any language construct you desire, by
definition.
> Although this is a severe irritation, it is not a syntactic issue.
>
> This is is fixed in Scheme, of course:
>
>> (define (f x) (lambda (y) (+ x y)))
>> ((f 2) 3)
> 5
This doesn't have anything to do with "being fixed" or not. Common Lisp
and Scheme made two different design decisions. That's it.
But you're not interested in learning.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Just because currying isn't supported out of the box
Currying is just returning a function from a function call and you can do
that easily enough out of the box in vanilla Common Lisp.
> doesn't mean that it is not widely used.
OCaml is almost entirely curried. Most of the stdlib is written in curried
form, even the primitive arithmetic operators:
# ((+) 1) 2;;
- : int = 3
So currying is certainly more common in OCaml than in Lisp. Standard ML does
not curry by default, although it is syntactically easy.
Are any of Lisp's library functions written in curried form?
> To the contrary, using lambda to partially
> provide some arguments to a function is rather common - most of the
> time, I guess, people just don't realize that they are actually currying.
>
> What do you think this is: (lambda (x y) (f 5 x 6 y 7)) ?
That is not currying.
Currying converts a function with multiple arguments:
(lambda (x y) (+ x y))
into functions that return other functions in order to consume the arguments
one at a time to allow partial application:
(lambda (x) (lambda (y) (+ x y)))
In SML you have:
fn x => fn y => x+y
In OCaml:
fun x y -> x+y
With arguments applied, in Lisp:
* (funcall (funcall (lambda (x) (lambda (y) (+ x y))) 2) 3)
5
In SML:
- (fn x => fn y => x+y) 2 3;
val it = 5 : int
and in OCaml:
# (fun x y -> x+y) 2 3;;
- : int = 5
or just:
# (+) 2 3;;
- : int = 5
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 12, 11:04 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Pascal Costanza wrote:
> > Just because currying isn't supported out of the box
>
> Currying is just returning a function from a function call and you can do
> that easily enough out of the box in vanilla Common Lisp.
Currying is about converting functions with multiple arguments
into functions with one argument. Some programming
languages have a syntax for that and built in transformations.
Common Lisp and Scheme don't.
>
> > doesn't mean that it is not widely used.
>
> OCaml is almost entirely curried. Most of the stdlib is written in curried
> form, even the primitive arithmetic operators:
>
> # ((+) 1) 2;;
> - : int = 3
>
> So currying is certainly more common in OCaml than in Lisp.
How do you know that? Which Lisp source code have you seen?
<...>
> Currying converts a function with multiple arguments:
>
> (lambda (x y) (+ x y))
>
> into functions that return other functions in order to consume the arguments
> one at a time to allow partial application:
>
> (lambda (x) (lambda (y) (+ x y)))
That is correct. That is you did the transformation. Not Lisp. Lisp
does not provide
you with automatic transformation.
>
> In SML you have:
>
> fn x => fn y => x+y
>
> In OCaml:
>
> fun x y -> x+y
>
> With arguments applied, in Lisp:
>
> * (funcall (funcall (lambda (x) (lambda (y) (+ x y))) 2) 3)
>
> 5
>
> In SML:
>
> - (fn x => fn y => x+y) 2 3;
> val it = 5 : int
>
> and in OCaml:
>
> # (fun x y -> x+y) 2 3;;
> - : int = 5
>
> or just:
>
> # (+) 2 3;;
> - : int = 5
Sure, what was your point?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
······@corporate-world.lisp.de wrote:
>> So currying is certainly more common in OCaml than in Lisp.
>
> How do you know that? Which Lisp source code have you seen?
The functions in Lisp's stdlib are not provided in curried form, e.g.
mapcar.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
In article <························@ptn-nntp-reader02.plus.net>,
Jon Harrop <···@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
> >> So currying is certainly more common in OCaml than in Lisp.
> >
> > How do you know that? Which Lisp source code have you seen?
>
> The functions in Lisp's stdlib are not provided in curried form, e.g.
> mapcar.
Right.
And Lisp provides no syntax or built-in transformations.
It even doesn't provide a CURRY function.
Which I think would be fine to have in a standard.
Dylan has 'curry' and 'rcurry'.
Curried functions are sometimes used in Lisp code,
but for some purposes the mechanism of
default arguments is used.
In this example one would use curry to avoid
repeating the stream variable all the time
when calling some output function.
(defun some-procedure-generating-output (stream foo bar)
...)
(defun example (stream)
(let ((f (curry #'some-procedure-generating-output stream)))
...
(funcall f 'foo 'bar)
...))
But often you will find a variation of this style:
(defun some-procedure-generating-output (foo bar &optional (stream *standard-output*))
...)
(defun example (stream)
(let ((*standard-output* stream))
(some-procedure-generating-output 'foo 'bar)
...))
Here we bring in the argument via dynamic binding of *standard-output*
(which is a 'special' variable) and an optional stream argument with default.
--
http://lispm.dyndns.org
Jon Harrop wrote:
>> To the contrary, using lambda to partially
>> provide some arguments to a function is rather common - most of the
>> time, I guess, people just don't realize that they are actually currying.
>>
>> What do you think this is: (lambda (x y) (f 5 x 6 y 7)) ?
>
> That is not currying.
It's a function that calls another function with some parameters already
filled in.
To be more complete:
(lambda (a b c)
(lambda (x y)
(f a x b y c)))
If you call this with the parameters 5, 6 and 7, you get the above
function. Note that the argument positions already filled in are not
necessarily to the left but can be anywhere in between.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> (lambda (a b c)
> (lambda (x y)
> (f a x b y c)))
That is currying.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Pascal Costanza wrote:
>> (lambda (a b c)
>> (lambda (x y)
>> (f a x b y c)))
>
> That is currying.
Good observation.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <························@ptn-nntp-reader02.plus.net>,
Jon Harrop <···@ffconsultancy.com> wrote:
> Pascal Costanza wrote:
> > Just because currying isn't supported out of the box
>
> Currying is just returning a function from a function call and you can do
> that easily enough out of the box in vanilla Common Lisp.
>
> > doesn't mean that it is not widely used.
>
> OCaml is almost entirely curried. Most of the stdlib is written in curried
> form, even the primitive arithmetic operators:
>
> # ((+) 1) 2;;
> - : int = 3
>
> So currying is certainly more common in OCaml than in Lisp. Standard ML does
> not curry by default, although it is syntactically easy.
>
> Are any of Lisp's library functions written in curried form?
>
> > To the contrary, using lambda to partially
> > provide some arguments to a function is rather common - most of the
> > time, I guess, people just don't realize that they are actually currying.
> >
> > What do you think this is: (lambda (x y) (f 5 x 6 y 7)) ?
>
> That is not currying.
>
> Currying converts a function with multiple arguments:
>
> (lambda (x y) (+ x y))
>
> into functions that return other functions in order to consume the arguments
> one at a time to allow partial application:
>
> (lambda (x) (lambda (y) (+ x y)))
>
> In SML you have:
>
> fn x => fn y => x+y
>
> In OCaml:
>
> fun x y -> x+y
>
> With arguments applied, in Lisp:
>
> * (funcall (funcall (lambda (x) (lambda (y) (+ x y))) 2) 3)
>
> 5
If you would do that in Lisp, introducing a function for
currying might be useful:
(defun schoenfinkel (function argument)
(lambda (&rest arguments)
(apply function argument arguments)))
(funcall (schoenfinkel #'+ 2) 3)
>
> In SML:
>
> - (fn x => fn y => x+y) 2 3;
> val it = 5 : int
>
> and in OCaml:
>
> # (fun x y -> x+y) 2 3;;
> - : int = 5
>
> or just:
>
> # (+) 2 3;;
> - : int = 5
--
http://lispm.dyndns.org
On 2007-05-12 10:51:01 +0100, Rainer Joswig <······@lisp.de> said:
> (defun schoenfinkel (function argument)
> (lambda (&rest arguments)
> (apply function argument arguments)))
And just to bring this back to syntax, this could easily be written as, say:
#&(f arg ...)
or
{f arg ...}
if you would prefer that, or
#&f (arg ...)
On Wed, 9 May 2007, ········@gmail.com wrote:
> Jon Harrop wrote:
>> Absolutely. But don't you think most people will find it easier to
>> understand:
>>
>> a + b*c
>>
>> rather than:
>>
>> (+ a (* b c))
>>
>> ?
>
> And why is that? Because we learned that in school. So we recognize it
> instantly.
>
There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
Therefore I think the first one is quicker to grasp. And I don't think so
because I learned "a + b*c" in school, I program lisp every day, and is
more customed to the lisp style.
However, this is a minor issue. There might be good reasons why
s-expressions aren't ideal, but to quicker get the grip of short (because
it only counts for short examples) mathematical expressions is not one of
them.
For larger mathematical expressions, I think s-expressions are much better
because you can use more lines and indentations to make things clearer.
This is of course my own subjective view. :-)
In article <·································@ttleush>,
Kjetil S. Matheussen <··············@notam02.no> wrote:
>On Wed, 9 May 2007, ········@gmail.com wrote:
>> Jon Harrop wrote:
>>> Absolutely. But don't you think most people will find it easier to
>>> understand:
>>> a + b*c
>>> rather than:
>>> (+ a (* b c))
>> And why is that? Because we learned that in school. So we recognize it
>> instantly.
>There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
>Therefore I think the first one is quicker to grasp. And I don't think so
>because I learned "a + b*c" in school, I program lisp every day, and is
>more customed to the lisp style.
...
An S-expression's[*] strength is also its weakness. It uses one
notation for everything, so syntax is uniform and trivial. This
property is very important when you are trying to unify program and
data structure (and blur their distinction). It makes it easy to
create new conceptual structures because you don't have to fit it into
complex syntactic rules.
The weakness is that the syntax gives you no clue as to the semantics:
you have to read and understand each operator in order to know how to
interpret its semantics.
The algebraic notation -- and things like different uses of braces,
parentheses, and other syntactic elements in programming languages --
means that, once learned, you can apply syntactic information to aid
in and speed understanding of the semantic content. This is something
that we do all the time in written (and verbal) language use and so we
find it natural and easy. Losing the syntactic clues makes us have to
go to more effort to understand the semantics. This effect is
especially important if you are doing a cursory overview or just want
to get the gist of something: in many cases, the syntax is the
important thing.
For example, if I'm scanning a journal looking for a particular
article, I might glance at the equations and see a summation. That in
itself may tell me whether the article is the one I'm after.
So, I don't see us switching all languages to use S-expressions. But
that doesn't mean that Lisp should change.
Craig
[*] The same argument applies to RPN, Polish notation, XML, and many
others.
Craig A. Finseth <····@finseth.com> writes:
>
> The weakness is that the syntax gives you no clue as to the semantics:
> you have to read and understand each operator in order to know how to
> interpret its semantics.
It also doesn't mislead you about semantics: It doesn't pretend that a
lambda definition is really something different from any other
expression, from control structures etc. It has been argued that
therefore Scheme is the ideal language for beginners. I don't agree
with that completely, but still: Syntax can also be misleading because
it introduces distinction where there are none.
Regards -- Markus
Craig A. Finseth wrote:
> An S-expression's[*] strength is also its weakness. It uses one
> notation for everything, so syntax is uniform and trivial. This
> property is very important when you are trying to unify program and
> data structure (and blur their distinction). It makes it easy to
> create new conceptual structures because you don't have to fit it into
> complex syntactic rules.
Xah already provided the perfect counterexample: Mathematica.
As a rewrite language it completely removes the distinction between program
and data structure (everything is an expression) whilst simultaneously
adopting a sophisticated syntax and providing fallback to prefix notation.
As Xah said, prefix notation is rare in real Mathematica code.
So the common claim that s-exprs are necessary for rewriting clearly does
not hold water.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 9, 10:01 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Craig A. Finseth wrote:
> > An S-expression's[*] strength is also its weakness. It uses one
> > notation for everything, so syntax is uniform and trivial. This
> > property is very important when you are trying to unify program and
> > data structure (and blur their distinction). It makes it easy to
> > create new conceptual structures because you don't have to fit it into
> > complex syntactic rules.
>
> Xah already provided the perfect counterexample: Mathematica.
>
> As a rewrite language it completely removes the distinction between program
> and data structure (everything is an expression) whilst simultaneously
> adopting a sophisticated syntax and providing fallback to prefix notation.
> As Xah said, prefix notation is rare in real Mathematica code.
You are talking about Mathematica's prefix notation.
We were talking about Lisp's s-expression notation.
That Mathematica is not a Lisp should be clear. That Mathematica
has another user base as a target is also clear. That Mathematica
has a different syntax from Lisp is also obvious. Type (+ 1 2)
to a standard Mathematica top-level and see what happens.
>
> So the common claim that s-exprs are necessary for rewriting clearly does
> not hold water.
This is another of your typical argumentation patterns. Nobody claims
that
S-epressions are necessary for rewriting.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journalhttp://www.ffconsultancy.com/products/fsharp_journal/?usenet
······@corporate-world.lisp.de wrote:
> You are talking about Mathematica's prefix notation.
> We were talking about Lisp's s-expression notation.
Xah started by comparing the two, which is apparently prohibited here.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
In article <························@ptn-nntp-reader02.plus.net>,
Jon Harrop <···@ffconsultancy.com> wrote:
> ······@corporate-world.lisp.de wrote:
> > You are talking about Mathematica's prefix notation.
> > We were talking about Lisp's s-expression notation.
>
> Xah started by comparing the two, which is apparently prohibited here.
You can compare everything, but it does not make things the same.
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr2zs2hlpqzri1@pandora.upc.no>
On Wed, 09 May 2007 23:47:36 +0200, ······@corporate-world.lisp.de
<······@corporate-world.lisp.de> wrote:
>> As Xah said, prefix notation is rare in real Mathematica code.
>
Actually all expressions get reduced to prefix form by the pattern matcher
before processing.
> You are talking about Mathematica's prefix notation.
> We were talking about Lisp's s-expression notation.
>
> That Mathematica is not a Lisp should be clear. That Mathematica
> has another user base as a target is also clear. That Mathematica
> has a different syntax from Lisp is also obvious. Type (+ 1 2)
> to a standard Mathematica top-level and see what happens.
Plus[1, 2]
3
Not s-expr exactly.. but
>
>>
>> So the common claim that s-exprs are necessary for rewriting clearly
>> does
>> not hold water.
Perhaps, but this is certaily a horrible example of this :)
>
> This is another of your typical argumentation patterns. Nobody claims
> that
> S-epressions are necessary for rewriting.
>
No, but it greatly simplifies things.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 9, 1:01 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
> So the common claim that s-exprs are necessary for rewriting clearly does
> not hold water.
I believe you are misinterpreting the claim. Of course general
rewrite systems do not have to be based on s-expressions. Post's
reduction rules predate s-expressions by more than 15 years.
The claim is that languages in the tradition of C and Java, which
require complex parsing technologies (Lex and Yacc) are far less
amenable to macro transformation than Lisp. There *exist* various
macro systems in these languages, but they are extraordinarily
difficult to implement and use, especially when compared to the macros
in Lisp.
Joe Marshall wrote:
> On May 9, 1:01 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> So the common claim that s-exprs are necessary for rewriting clearly does
>> not hold water.
First of all, the only common claim I've seen is that sexprs are
very helpful for full evaluated macros, not that they're necessary
for term rewriting. No language other than Lisp[1], including Dylan,
Mathematica, and camlp4, has fully evaluated macro functions,
and anyone arguing against Lisp syntax should know that.
> There *exist* various macro systems in these languages, but
> they are extraordinarily difficult to implement and use,
> especially when compared to the macros in Lisp.
And they're less expressive as well. If we're going to discuss
sexprs and Lisp syntax, there's no excuse for ignoring their
importance to macro functions. I don't know enough yet to
defend the position, but everything I've read says that's
their primary purpose. We shouldn't waste our time with
other reasons, because they're not nearly as important.
[1] Except maybe Arc and Qi, but they both use sexprs.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> First of all, the only common claim I've seen is that sexprs are
> very helpful for full evaluated macros, not that they're necessary
> for term rewriting. No language other than Lisp[1], including Dylan,
> Mathematica, and camlp4, has fully evaluated macro functions,
> and anyone arguing against Lisp syntax should know that.
Can you elaborate on this because, as far as I know, Lisp is completely run
of the mill in this regard, offering no more than Mathematica, OCaml...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5ag44lF2n21ptU1@mid.individual.net>
Jon Harrop wrote:
> Dan Bensen wrote:
>> First of all, the only common claim I've seen is that sexprs are
>> very helpful for full evaluated macros, not that they're necessary
>> for term rewriting. No language other than Lisp[1], including Dylan,
>> Mathematica, and camlp4, has fully evaluated macro functions,
>> and anyone arguing against Lisp syntax should know that.
>
> Can you elaborate on this because, as far as I know, Lisp is completely run
> of the mill in this regard, offering no more than Mathematica, OCaml...
See point 9 at http://www.paulgraham.com/diff.html
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Jon Harrop wrote:
>> Dan Bensen wrote:
>>> First of all, the only common claim I've seen is that sexprs are
>>> very helpful for full evaluated macros, not that they're necessary
>>> for term rewriting. No language other than Lisp[1], including Dylan,
>>> Mathematica, and camlp4, has fully evaluated macro functions,
>>> and anyone arguing against Lisp syntax should know that.
>>
>> Can you elaborate on this because, as far as I know, Lisp is completely
>> run of the mill in this regard, offering no more than Mathematica,
>> OCaml...
>
> See point 9 at http://www.paulgraham.com/diff.html
Nothing useful there. Can you give an example of something that you believe
Lisp can do with s-exprs that Mathematica cannot do with exprs?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
>>> Dan Bensen wrote:
>>>> First of all, the only common claim I've seen is that sexprs are
>>>> very helpful for full evaluated macros, not that they're necessary
>>>> for term rewriting. No language other than Lisp[1], including
>>>> Dylan, Mathematica, and camlp4, has fully evaluated macro
>>>> functions, and anyone arguing against Lisp syntax should
>>>> know that.
>> Jon Harrop wrote:
>>> Can you elaborate on this because, as far as I know, Lisp is
>>> completely run of the mill in this regard, offering no more
>>> than Mathematica,
Well, your impression seems to differ wildly from almost every other
opinion I've ever seen. Googling lisp macro, the first page alone
contains several testimonials from experienced hackers about the
expressive power of Lisp macros.
> Pascal Costanza wrote:
>> See point 9 at http://www.paulgraham.com/diff.html
>>> 9. The whole language always available.
Jon Harrop wrote:
> Nothing useful there.
You don't find having the expressive power of a full-featured
programming language useful? That's a stunning opinion coming
from someone comparing languages. Lisp macros use the entire
Lisp language to act on a problem that's made much easier by
the syntactic simplicity of s-expressions.
Jon Harrop wrote:
> Can you give an example of something that you believe
> Lisp can do with s-exprs that Mathematica cannot do with exprs?
You might take a look at the source code for LOOP. Also, we're
not talking about what can or can't be done in the theoretical
sense of Turing completeness. The question is how easy the problem
is based on the syntax of the language, which in the case of Lisp
is trivially simple; and how convenient the solution is based on
the expressive power of the macro language, which in the case
of Lisp is one of the most expressive languages in common use,
including good functional features and pre-existing macros.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Lisp macros use the entire Lisp language to act on a problem that's made
> much easier by the syntactic simplicity of s-expressions.
This is exactly the belief that I was talking about. Xah's initial point was
pointing out that Mathematica provides its users with a choice between
using entirely prefix syntax and using more sophisticated syntax, and users
often choose the latter (infix).
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr5ufay5pqzri1@pandora.upc.no>
On Fri, 11 May 2007 12:37:08 +0200, Jon Harrop <···@ffconsultancy.com>
wrote:
> Dan Bensen wrote:
>> Lisp macros use the entire Lisp language to act on a problem that's made
>> much easier by the syntactic simplicity of s-expressions.
>
> This is exactly the belief that I was talking about. Xah's initial point
> was
> pointing out that Mathematica provides its users with a choice between
> using entirely prefix syntax and using more sophisticated syntax, and
> users
> often choose the latter (infix).
>
It is more a case of the complex language being buildt on top of
the simpler prefix syntax. The whole reason for the more complex
syntax is for users to use it. Lisp provide a macro facility which
allows you to build more complex languages on top of it in a similar way.
(This is probably where he borrowed the idea.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> It is more a case of the complex language being buildt on top of
> the simpler prefix syntax. The whole reason for the more complex
> syntax is for users to use it. Lisp provide a macro facility which
> allows you to build more complex languages on top of it in a similar way.
> (This is probably where he borrowed the idea.)
Absolutely. The only debate is whether or not it is worth writing so much
code with minimal syntax.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Pascal Costanza
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <5ak1jtF2mce3lU1@mid.individual.net>
Jon Harrop wrote:
> John Thingstad wrote:
>> It is more a case of the complex language being buildt on top of
>> the simpler prefix syntax. The whole reason for the more complex
>> syntax is for users to use it. Lisp provide a macro facility which
>> allows you to build more complex languages on top of it in a similar way.
>> (This is probably where he borrowed the idea.)
>
> Absolutely. The only debate is whether or not it is worth writing so much
> code with minimal syntax.
What makes you think we write a lot of code?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2007-05-11 11:37:08 +0100, Jon Harrop <···@ffconsultancy.com> said:
> This is exactly the belief that I was talking about. Xah's initial point was
> pointing out that Mathematica provides its users with a choice between
> using entirely prefix syntax and using more sophisticated syntax, and users
> often choose the latter (infix).
And what a surprise that is, since it's a language for maths. It's
probably before your time but that's exactly how the Lisp-based algebra
systems worked (and work I expect).
From: Ken Tilton
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <Ncw1i.25$5U2.18@newsfe12.lga>
Tim Bradshaw wrote:
> On 2007-05-11 11:37:08 +0100, Jon Harrop <···@ffconsultancy.com> said:
>
>> This is exactly the belief that I was talking about. Xah's initial
>> point was
>> pointing out that Mathematica provides its users with a choice between
>> using entirely prefix syntax and using more sophisticated syntax, and
>> users
>> often choose the latter (infix).
>
>
> And what a surprise that is, since it's a language for maths. It's
> probably before your time but that's exactly how the Lisp-based algebra
> systems worked (and work I expect).
>
Users of http://www.theoryyalgebra.com/ never see it, though power users
will if they ever ask for it, but ascii-encoding of Algebra (for
built-in problems) stays as close to possible to math notation:
'4/3'+'7/2'
Math notation is syntax-rich thus extremely efficient, and I already
/think/ in that notation for math, so of course I want to use that for
entering dozens of math problems.
kt
ps. No, I am not actually trying to add value to this thread, i just
wanted to see a blip in the page hits. :) k
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On 2007-05-13 00:10:21 -0400, Ken Tilton <···········@optonline.net> said:
> ps. No, I am not actually trying to add value to this thread, i just
> wanted to see a blip in the page hits. :) k
Yeah, but at least your shameless plug is on topic for c.l.l ;^)
From: Miles Bader
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87tzul5xgx.fsf@catnip.gol.com>
Craig A. Finseth <····@finseth.com> writes:
> The algebraic notation -- and things like different uses of braces,
> parentheses, and other syntactic elements in programming languages --
> means that, once learned, you can apply syntactic information to aid
> in and speed understanding of the semantic content.
However this happens in sexpr based languages too -- people use the
"shape" of code (e.g., notice how quickly you can recognize a "cond" in
lisp) , and things like naming conventions ("with-..." "do...") to
quickly establish the general meaning of a statement. This is exactly
the sort of "vague semantic hint" that you get from braces and other
more exotic syntaxes.
-Miles
--
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."
Miles Bader wrote:
> However this happens in sexpr based languages too -- people use the
> "shape" of code (e.g., notice how quickly you can recognize a "cond" in
> lisp) , and things like naming conventions ("with-..." "do...") to
> quickly establish the general meaning of a statement. This is exactly
> the sort of "vague semantic hint" that you get from braces and other
> more exotic syntaxes.
Exactly. Indentation is the poor man's typesetting.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 10:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Miles Bader wrote:
> > However this happens in sexpr based languages too -- people use the
> > "shape" of code (e.g., notice how quickly you can recognize a "cond" in
> > lisp) , and things like naming conventions ("with-..." "do...") to
> > quickly establish the general meaning of a statement. This is exactly
> > the sort of "vague semantic hint" that you get from braces and other
> > more exotic syntaxes.
>
> Exactly. Indentation is the poor man's typesetting.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
Proper indentation is a must for anybody worth of the name
professional programmer.
On May 10, 10:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Miles Bader wrote:
> > However this happens in sexpr based languages too -- people use the
> > "shape" of code (e.g., notice how quickly you can recognize a "cond" in
> > lisp) , and things like naming conventions ("with-..." "do...") to
> > quickly establish the general meaning of a statement. This is exactly
> > the sort of "vague semantic hint" that you get from braces and other
> > more exotic syntaxes.
>
> Exactly. Indentation is the poor man's typesetting.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
Then why do you use it at your Ocaml tutorial your code is properly
indented :
http://www.ffconsultancy.com/ocaml/mandelbrot/index.html
let display () =
let w, h = !dim in
GlDraw.begins `points;
for a = 0 to w - 1 do
for b = 0 to h - 1 do
let x = 4. *. float a /. float w -. 2. in
let y = 4. *. float b /. float h -. 2. in
let i = mandelbrot 0 {re=x; im=y} zero in
let f i = 0.5 +. 0.5 *. cos(float i *. 0.1) in
GlDraw.color (f i, f(i + 16), f(i + 32));
GlDraw.vertex ~x ~y ()
done;
done;
GlDraw.ends ();
Gl.flush ()
On May 10, 11:49 am, fireblade <·················@gmail.com> wrote:
> On May 10, 10:15 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Miles Bader wrote:
> > > However this happens in sexpr based languages too -- people use the
> > > "shape" of code (e.g., notice how quickly you can recognize a "cond" in
> > > lisp) , and things like naming conventions ("with-..." "do...") to
> > > quickly establish the general meaning of a statement. This is exactly
> > > the sort of "vague semantic hint" that you get from braces and other
> > > more exotic syntaxes.
>
> > Exactly. Indentation is the poor man's typesetting.
>
> > --
> > Dr Jon D Harrop, Flying Frog Consultancy
>
> Then why do you use it at your Ocaml tutorial your code is properly
> indented :http://www.ffconsultancy.com/ocaml/mandelbrot/index.html
>
> let display () =
> let w, h = !dim in
> GlDraw.begins `points;
> for a = 0 to w - 1 do
> for b = 0 to h - 1 do
> let x = 4. *. float a /. float w -. 2. in
> let y = 4. *. float b /. float h -. 2. in
> let i = mandelbrot 0 {re=x; im=y} zero in
> let f i = 0.5 +. 0.5 *. cos(float i *. 0.1) in
> GlDraw.color (f i, f(i + 16), f(i + 32));
> GlDraw.vertex ~x ~y ()
> done;
> done;
> GlDraw.ends ();
> Gl.flush ()
Your site motto is Putting the fun in functional since 2005 , I
downloaded one of the games LinCity-NG linked at
http://www.ffconsultancy.com/fun/index.html and guess what ? It's made
with C++. Where the hell is functional in that?
Excerpt from the Game.cpp file :
>//Copyright (C) 2005 Matthias Braun <·····@braunis.de>
>
>#include <config.h>
>
>#include "Game.hpp"
>
>#include "gui/TextureManager.hpp"
>#include "gui/ComponentLoader.hpp"
>#include "gui/Component.hpp"
>#include "gui/Desktop.hpp"
>#include "gui/Event.hpp"
>#include "gui/Button.hpp"
>#include "gui/callback/Callback.hpp"
>#include "lincity/fileutil.h"
>
>#include "MainLincity.hpp"
>#include <iostream>
>#include <physfs.h>
>#include "Util.hpp"
>#include "lincity/lin-city.h"
>#include "GameView.hpp"
>#include "HelpWindow.hpp"
>#include "ButtonPanel.hpp"
>#include "Dialog.hpp"
>#include "EconomyGraph.hpp"
>
>Game* gameptr = 0;
>
>Game* getGame(){
> return gameptr;
>}
>
>Game::Game()
>{
> gui.reset(loadGUIFile("gui/app.xml"));
> gui->resize(SDL_GetVideoSurface()->w, SDL_GetVideoSurface()->h);
>
> Button* gameMenu = getButton( *gui, "GameMenuButton" );
> gameMenu->clicked.connect( makeCallback(*this, &Game::gameButtonClicked ));
>
> Button* helpButton = getButton( *gui, "HelpButton" );
> helpButton->clicked.connect( makeCallback(*this, &Game::gameButtonClicked ));
>
> Button* statButton = getButton( *gui, "StatButton" );
> statButton->clicked.connect( makeCallback(*this, &Game::gameButtonClicked ));
>
> Desktop* desktop = dynamic_cast<Desktop*> (gui.get());
> if(desktop == 0)
> throw std::runtime_error("Game UI is not a Desktop Component");
> helpWindow.reset(new HelpWindow(desktop));
> gameptr = this;
>}
fireblade wrote:
>> Then why do you use it at your Ocaml tutorial your code is properly
>> indented :http://www.ffconsultancy.com/ocaml/mandelbrot/index.html
>>
>> let display () =
>> let w, h = !dim in
>> GlDraw.begins `points;
>> for a = 0 to w - 1 do
>> for b = 0 to h - 1 do
>> let x = 4. *. float a /. float w -. 2. in
>> let y = 4. *. float b /. float h -. 2. in
>> let i = mandelbrot 0 {re=x; im=y} zero in
>> let f i = 0.5 +. 0.5 *. cos(float i *. 0.1) in
>> GlDraw.color (f i, f(i + 16), f(i + 32));
>> GlDraw.vertex ~x ~y ()
>> done;
>> done;
>> GlDraw.ends ();
>> Gl.flush ()
Because OCaml only supports indenting and not full typesetting.
> Your site motto is Putting the fun in functional since 2005 , I
> downloaded one of the games LinCity-NG linked at
> http://www.ffconsultancy.com/fun/index.html and guess what ? It's made
> with C++. Where the hell is functional in that?
Nothing functional about the Linux games that are linked to from our fun
page.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Miles Bader wrote:
>> However this happens in sexpr based languages too -- people use the
>> "shape" of code (e.g., notice how quickly you can recognize a "cond" in
>> lisp) , and things like naming conventions ("with-..." "do...") to
>> quickly establish the general meaning of a statement. This is exactly
>> the sort of "vague semantic hint" that you get from braces and other
>> more exotic syntaxes.
>
> Exactly. Indentation is the poor man's typesetting.
The Haskell and Python communities don't seem to mind it.
--
Dan
www.prairienet.org/~dsb/
Kjetil S. Matheussen wrote:
> On Wed, 9 May 2007, ········@gmail.com wrote:
>> Jon Harrop wrote:
>>
>>> Absolutely. But don't you think most people will find it easier to
>>> understand:
>>>
>>> a + b*c
>>>
>>> rather than:
>>>
>>> (+ a (* b c))
>>>
>>> ?
>>
>> And why is that? Because we learned that in school. So we recognize it
>> instantly.
>
> There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
... and conciseness is important to the extent that mathematicians actually
write "a + bc", just to make it one symbol shorter.
(I'm not saying that programming languages should go that far; the
interpretation of mathematical notation is context-dependent, and
programming languages shouldn't be.)
--
David Hopwood <·············@industrial-designers.co.uk>
From: David Hansen
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87sla6owql.fsf@localhorst.mine.nu>
On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
> For larger mathematical expressions, I think s-expressions are much
> better because you can use more lines and indentations to make
> things clearer.
Show me one person that uses sexps to scribble large equations by hand.
David
On May 9, 11:14 am, David Hansen <············@gmx.net> wrote:
> On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
> > For larger mathematical expressions, I think s-expressions are much
> > better because you can use more lines and indentations to make
> > things clearer.
> Show me one person that uses sexps to scribble large equations by hand.
Show me one person that uses Fortran-style infix notation to scribble
large equations by hand.
Cheers,
Pillsy
Pillsy wrote:
> Show me one person that uses Fortran-style infix notation to scribble
> large equations by hand.
Many computational scientists. Not that I'd recommend it.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Kent M Pitman
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <ups5at36r.fsf@nhplace.com>
[ comp.lang.lisp only.
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
David Hansen <············@gmx.net> writes:
> On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
>
> > For larger mathematical expressions, I think s-expressions are much
> > better because you can use more lines and indentations to make
> > things clearer.
>
> Show me one person that uses sexps to scribble large equations by hand.
There's a fallacy in your question because it presupposes that large
expressions are constructed by scribbling. They often aren't.
Constructing large expressions by scribbling is error-prone and not
best practice.
It also supposes that the people who do this construction by hand do
the full set of operations on their expressions that we do on ours.
They may do some of that symbolic rearranging in their head, but they
may also just deny themselves options that are not easy to administer.
In this regard, it reminds me of writers who stubbornly resisted word
processors for so long, claiming they preferred fixed pieces of paper
for editing. It seems to me objectively clear that the computer /
word processor is a better device because of its ability to save old
copies, to compare copies, to rearrange large blocks, and in every way
to enable "trying alternatives" to make sure what you have is good.
Those who manipulate symbolic algebra without benefit of a mechanical
tool to assure the integrity and validity of the transforms they do are
really just hampering themselves.
Infix notation is, objectively, a device for compact depiction of a
result, and for people who don't want to type a lot. The compact
display has its purpose, and compact input may have its purpose, but
ultimately, trying to argue that there's no purpose in having other
display forms is like trying to argue that mathematical transforms
have no purpose.
Or, if you prefer a more obscure analogy, infix algebra is like
clinging to non-realtime TECO after WYSIWYG editors came along.
[I'd use the the correct names of the tools here, but it would obscure
my analogy, which is obscure already.]
Another problem problem with infix is that its irregular rules of
presentation obscure structural regularities that would probably
produce great insights, but that are hidden by the non-parallel nature
of the notation [in the English grammar sense of parallel
construction; no allusion to computational parallism here] .
Also, there are lots of people that use parens around algebraic
notation because they don't understand and trust "precedence".
(((a*b)+c)/d)
is not an uncommon style for people to adopt.
And, there are people like me who don't like doing math at all. I
prefer to hand it over to a computer to do it for me. Algebraic
notation is fine when the task I want to farm out is just "compute
this". But it's not when the task is more complicated.
And, also, even when editing things myself, I frequently find that
it's hard to safely and reliably rearrange an expression to understand
it. If you see an algebraic expression that goes on for pages, it's
nearly unintelligible. (I deal with symbolic algebra systems all day
for work and I have this problem every day. I have to stop and indent
the expression Lisp-style in order to make any sense of it, and that's
a complicated and tedious process.)
On Wed, 9 May 2007, David Hansen wrote:
> On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
>
> > For larger mathematical expressions, I think s-expressions are much
> > better because you can use more lines and indentations to make
> > things clearer.
>
> Show me one person that uses sexps to scribble large equations by hand.
>
I don't think this has got anything to do with what I wrote. What are you
trying to say?
On Wed, 9 May 2007, Kjetil Svalastog Matheussen wrote:
> On Wed, 9 May 2007, David Hansen wrote:
>
> > On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
> >
> > > For larger mathematical expressions, I think s-expressions are much
> > > better because you can use more lines and indentations to make
> > > things clearer.
> >
> > Show me one person that uses sexps to scribble large equations by hand.
> >
>
> I don't think this has got anything to do with what I wrote. What are you
> trying to say?
>
Okay, I get it. You didn't read the whole thread? The thread is about
code written on a computer. However, in case you actually knew that; No,
you can't make the comparison of scribbling an equation and writing
an equations that is supposed to be easy to grasp the meaning of.
From: David Hansen
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <87hcqlq2qk.fsf@localhorst.mine.nu>
On Wed, 9 May 2007 18:13:56 +0200 Kjetil Svalastog Matheussen wrote:
> On Wed, 9 May 2007, Kjetil Svalastog Matheussen wrote:
>
>> On Wed, 9 May 2007, David Hansen wrote:
>>
>> > On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
>> >
>> > > For larger mathematical expressions, I think s-expressions are much
>> > > better because you can use more lines and indentations to make
>> > > things clearer.
>> >
>> > Show me one person that uses sexps to scribble large equations by hand.
>> >
>>
>> I don't think this has got anything to do with what I wrote. What are you
>> trying to say?
>>
>
> Okay, I get it. You didn't read the whole thread? The thread is about
> code written on a computer. However, in case you actually knew that; No,
> you can't make the comparison of scribbling an equation and writing
> an equations that is supposed to be easy to grasp the meaning of.
Not the whole thread but enough to understand the context. What i
wanted to say is that especially large equations benefit a lot from
special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
a computer program but are far more easy to parse for a human than
sexps.
David
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr2pjvynpqzri1@pandora.upc.no>
On Wed, 09 May 2007 20:19:15 +0200, David Hansen <············@gmx.net>
wrote:
>>
>> Okay, I get it. You didn't read the whole thread? The thread is about
>> code written on a computer. However, in case you actually knew that; No,
>> you can't make the comparison of scribbling an equation and writing
>> an equations that is supposed to be easy to grasp the meaning of.
>
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
>
> David
Ever considered using a Mathematica kernel and mathlink?
Do the math in mathematica and the lispy stuff in Lisp.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323328-1123613849-1178754438=:27620
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Wed, 9 May 2007, David Hansen wrote:
>>>>
>>>> Show me one person that uses sexps to scribble large equations by hand=
=2E
>>>>
>>>
>>> I don't think this has got anything to do with what I wrote. What are y=
ou
>>> trying to say?
>>>
>>
>> Okay, I get it. You didn't read the whole thread? The thread is about
>> code written on a computer. However, in case you actually knew that; No,
>> you can't make the comparison of scribbling an equation and writing
>> an equations that is supposed to be easy to grasp the meaning of.
>
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (=FF=FF, =FF=FF, =FF=FF, =FF=FF, =FF=FF, =FF=FF). They=
might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
Not really... There is no right or wrong here so you must add something=20
like "I think", "in my opinion", "from my experience based on ...", etc.=20
to make the above statement correct.
--8323328-1123613849-1178754438=:27620--
David Hansen <············@gmx.net> writes:
> Not the whole thread but enough to understand the context. What i
> wanted to say is that especially large equations benefit a lot from
> special notations (∫, ∑, ∇, ∂, □, …). They might be harder to parse by
> a computer program but are far more easy to parse for a human than
> sexps.
All these special notations are prefix.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
From: Kent M Pitman
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <uejlpec5d.fsf@nhplace.com>
[ comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Pascal Bourguignon <···@informatimago.com> writes:
> David Hansen <············@gmx.net> writes:
> > Not the whole thread but enough to understand the context. What i
> > wanted to say is that especially large equations benefit a lot from
> > special notations (��"+, ��", ��", ��", ��%�, �� &). They might be harder to parse by
> > a computer program but are far more easy to parse for a human than
> > sexps.
>
> All these special notations are prefix.
Imaging up in his mind the episode of Star Trek: The Original Series
entitled "Let that be your last battlefield", he suddenly blurts out:
"But... but... are you blind? Their paren is on the RIGHT side!"
From: Kent M Pitman
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <u8xbxebxq.fsf@nhplace.com>
In case that last post of mine didn't come out well for you (it came
out terribly in my newsreader due to some unexpected character encoding
problem), here's a repost with the summation sign and other special
characters edited out...
[ comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Pascal Bourguignon <···@informatimago.com> writes:
> David Hansen <············@gmx.net> writes:
> > Not the whole thread but enough to understand the context. What i
> > wanted to say is that especially large equations benefit a lot from
> > special notations [...summation, etc...]. They might be harder to parse by
> > a computer program but are far more easy to parse for a human than
> > sexps.
>
> All these special notations are prefix.
Imaging up in his mind the episode of Star Trek: The Original Series
entitled "Let that be your last battlefield", he suddenly blurts out:
"But... but... are you blind? Their paren is on the RIGHT side!"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323328-1954974835-1178756333=:27620
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Thu, 10 May 2007, Pascal Bourguignon wrote:
> David Hansen <············@gmx.net> writes:
>> Not the whole thread but enough to understand the context. What i
>> wanted to say is that especially large equations benefit a lot from
>> special notations (=FF=FF, =FF=FF, =FF=FF, =FF=FF, =FF=FF, =FF=FF). The=
y might be harder to parse by
>> a computer program but are far more easy to parse for a human than
>> sexps.
>
> All these special notations are prefix.
>
Oh, I didn't see the special notations. (Pine just shows ( , , , ,).) In=20
that case, then I guess there was less reason to add "I think" etc.,=20
although it definitely wouldn't hurt.
But I still wonder what his point was, as this is unrelated to the=20
discussion. The way he quoted me on his first posting, I got the=20
impression that he disagreed with something I said, but I'm not sure what=
=20
that might have been?
--8323328-1954974835-1178756333=:27620--
"Kjetil S. Matheussen" <··············@notam02.no> writes:
> On Thu, 10 May 2007, Pascal Bourguignon wrote:
>
>> David Hansen <············@gmx.net> writes:
>>> Not the whole thread but enough to understand the context. What i
>>> wanted to say is that especially large equations benefit a lot from
>>> special notations (��, ��, ��, ��, ��, ��). They might be harder to parse by
>>> a computer program but are far more easy to parse for a human than
>>> sexps.
>>
>> All these special notations are prefix.
>>
>
> Oh, I didn't see the special notations. (Pine just shows ( , , , ,).)
> In that case, then I guess there was less reason to add "I think"
> etc., although it definitely wouldn't hurt.
That's why, while we can use Unicode in most lisp implementations, we
usually prefer to "spell out" the symbols in ASCII, and write:
(integral sum nabla delta square etc)
This is something that seems to be bothering lisp detractors, but it's
also a liberating aspect of lisp, that a lot of what is encoded in
characters with special syntactic roles in other programming languages
can be written in lisp as normal symbols.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Pascal Bourguignon wrote:
> David Hansen <············@gmx.net> writes:
>> Not the whole thread but enough to understand the context. What i
>> wanted to say is that especially large equations benefit a lot from
>> special notations (?, ?, ?, ?, ?, ?). They might be harder to parse by
>> a computer program but are far more easy to parse for a human than
>> sexps.
>
> All these special notations are prefix.
No they aren't. The German S and Sigma are typeset, with limits above and
below. Square root symbol is typeset, not prefix. Many syntaxes uses
superscript, subscript, overbar, strikethrough etc.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
David Hansen <············@gmx.net> writes:
> On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
>
>> For larger mathematical expressions, I think s-expressions are much
>> better because you can use more lines and indentations to make
>> things clearer.
>
> Show me one person that uses sexps to scribble large equations by hand.
I have done so from time to time, when I still practiced physics and
mathematics. It has advantages.
Regards -- Markus
In article <··············@localhorst.mine.nu>,
David Hansen <············@gmx.net> wrote:
> On Wed, 9 May 2007 16:24:41 +0200 Kjetil S. Matheussen wrote:
>
> > For larger mathematical expressions, I think s-expressions are much
> > better because you can use more lines and indentations to make
> > things clearer.
>
> Show me one person that uses sexps to scribble large equations by hand.
>
> David
Check out Gerald Jay Sussman:
http://video.google.com/videoplay?docid=5571878527594356342&q=sussman+sicp&hl=en
;-)
--
http://lispm.dyndns.org
On May 9, 4:24 pm, "Kjetil S. Matheussen" <··············@notam02.no>
wrote:
> On Wed, 9 May 2007, ········@gmail.com wrote:
> > Jon Harrop wrote:
> >> Absolutely. But don't you think most people will find it easier to
> >> understand:
>
> >> a + b*c
>
> >> rather than:
>
> >> (+ a (* b c))
>
> >> ?
>
> > And why is that? Because we learned that in school. So we recognize it
> > instantly.
>
> There is another reason, "a + b*c" is shorter than "(+ a (* b c))".
> Therefore I think the first one is quicker to grasp. And I don't think so
> because I learned "a + b*c" in school, I program lisp every day, and is
> more customed to the lisp style.
>
> However, this is a minor issue. There might be good reasons why
> s-expressions aren't ideal, but to quicker get the grip of short (because
> it only counts for short examples) mathematical expressions is not one of
> them.
>
> For larger mathematical expressions, I think s-expressions are much better
> because you can use more lines and indentations to make things clearer.
>
> This is of course my own subjective view. :-)- Hide quoted text -
>
> - Show quoted text -
s-exp gives you orthogonality so you could learn lisp syntax in a half
of hour .How long does it takes to get all the precedence rules? I'm
not saying that s-exp are good thing for inserting complex math
expressions, though in some ways it helps like a + b + c + d + e <=>
(+ a b c d e), but if you prefer inserting math infix use a macro for
it. There's a full thread explaining this => Any macro for inserting
math "normally:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/38c67e7a2511eeb6/dc827f5650e54d49lnk=gst&q=&rnum=15#dc827f5650e54d49
Lisp gives you a power of choice, in other languages you have to live
with whatever language designers thought it's right.
cheers
bobi
fireblade wrote:
> Lisp gives you a power of choice, in other languages you have to live
> with whatever language designers thought it's right.
As Xah pointed out, that is not true. Other languages do give you the
choice, people made the choice and most of them didn't choose s-exprs.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 10:11 am, Jon Harrop <····@ffconsultancy.com> wrote:
> fireblade wrote:
> > Lisp gives you a power of choice, in other languages you have to live
> > with whatever language designers thought it's right.
>
> As Xah pointed out, that is not true. Other languages do give you the
> choice, people made the choice and most of them didn't choose s-exprs.
>
Xah pointed crup, in lisp I could use infix syntax including only a
macro in my code. I hate extended loop (very unlispy) so I use
iterate, I don't like format so I make something else. I want to use
comma (,) for something else than common lisp committee decided (see
my reverse clsql syntax) so I modify the reader or make macro to suit
my needs. In other languages things like this are carved in stone.
> people made the choice and most of them didn't choose s-exprs.
So what? Nobody's pointing a gun in their head saying you must use s-
exps, nor anybody is going to comp.lang.java/c/c++
and saying every fuchen day that their choice sucks and they should
choose prefix , postfix or whatever. It's their job to decide. If
you're happy with your language fine stick with it. If you're
interested to try something else lisp is easy thing to learn try it
for a week and see if it works for you , AND MAKE UP YOUR OWN MIND .
Don't trust me, don't trust your colleagues and certainly don't trust
people who would do anything to sell you their shit like you Jon
Harrop.
cheers
bobi
On May 10, 10:43 am, fireblade <·················@gmail.com> wrote:
> On May 10, 10:11 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > fireblade wrote:
> > people made the choice and most of them didn't choose s-exprs.
>
> So what? Nobody's pointing a gun in their head saying you must use s-
> exps, nor anybody is going to comp.lang.java/c/c++
> and saying every fuchen day that their choice sucks and they should
> choose prefix , postfix or whatever. It's their job to decide. If
> you're happy with your language fine stick with it. If you're
> interested to try something else lisp is easy thing to learn try it
> for a week and see if it works for you , AND MAKE UP YOUR OWN MIND .
> Don't trust me, don't trust your colleagues and certainly don't trust
> people who would do anything to sell you their shit like you Jon
> Harrop.
>
> cheers
> bobi
That's exactly why I'll never try F#, anything that needs such
advertising to bring people on board is crup with probability of
99.99999% . C# is very good example for a bad example, perfectly
suited for a waterfall method. I wonder how to make global function
in C# ? Oh I'm so stupid keep a pointer to a class that keeps a method
for doing what you want or you probably heard about copy-paste
programming , copy the same method in every class that needs it and if
that method needs changes than .. let's worry about those things
later . BTW People are used to buggy software in windows so why should
our software be an exception.
From: John Thingstad
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <op.tr3uxtiwpqzri1@pandora.upc.no>
On Thu, 10 May 2007 10:59:05 +0200, <·············@hotmail.com> wrote:
>
> That's exactly why I'll never try F#, anything that needs such
> advertising to bring people on board is crup with probability of
> 99.99999% .
Seems like a silly attitude. Always see first then judge.
Functional programming is a tough sell. It forces you to rethink
the way you structure code. To many people it just seems 'wrong'.
> C# is very good example for a bad example, perfectly
> suited for a waterfall method. I wonder how to make global function
> in C# ? Oh I'm so stupid keep a pointer to a class that keeps a method
> for doing what you want or you probably heard about copy-paste
> programming , copy the same method in every class that needs it and if
> that method needs changes than .. let's worry about those things
> later . BTW People are used to buggy software in windows so why should
> our software be an exception.
>
I use C# a little bit. I don't like it all that much, but I find it really
is a improvement over Java. It runs faster, it loads faster, it seems less
bloated.
Not important from a design perspective perhaps. But in day for day use
you really
notice the difference.
The method for global declaration is the same as with Java or SmallTalk.
The singleton pattern. (Unneccesary in Lisp)
I hate interfaces which seem like a brain dead idea.
Forces you to repeat youself. And yes, having the IDE
automatically grind repetitious code for you is not the answer.
And I don't really feel that everything is a object or belongs in a class.
Can't say I found C# software to be particularly buggy.
That microsoft is super buggy is more of a myth now.
Most of that changed with Windows 2000 when the system DLL problem was
fixed.
The introduction of Kerberos also adressed the most critical security
issues.
Then there was the deprecation of all dangerous functions in the C libray.
They have actually made significant efforts to improve things there.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 10, 11:50 am, "John Thingstad" <··············@chello.no>
wrote:
> On Thu, 10 May 2007 10:59:05 +0200, <·············@hotmail.com> wrote:
>
> > That's exactly why I'll never try F#, anything that needs such
> > advertising to bring people on board is crup with probability of
> > 99.99999% .
>
> Seems like a silly attitude. Always see first then judge.
There's too much offer in the market to try everything. No time for
all you must pick what to drop. I' rather go for Forth seems more
interesthing than stupid MS research which from my own experience made
me feel negatibve bias. Beside Harrop is just a prick.
> Functional programming is a tough sell. It forces you to rethink
> the way you structure code. To many people it just seems 'wrong'.
I have no problem with functional proramming but language should
rather support more paradigms . C# is only for OO that's crup.
> > C# is very good example for a bad example, perfectly
> > suited for a waterfall method. I wonder how to make global function
> > in C# ? Oh I'm so stupid keep a pointer to a class that keeps a method
> > for doing what you want or you probably heard about copy-paste
> > programming , copy the same method in every class that needs it and if
> > that method needs changes than .. let's worry about those things
> > later . BTW People are used to buggy software in windows so why should
> > our software be an exception.
>
> I use C# a little bit. I don't like it all that much, but I find it really
> is a improvement over Java. It runs faster, it loads faster, it seems less
> bloated.
> Not important from a design perspective perhaps. But in day for day use
> you really
> notice the difference.
You need very strong machine to do java.
> The method for global declaration is the same as with Java or SmallTalk.
> The singleton pattern. (Unneccesary in Lisp)
>
> I hate interfaces which seem like a brain dead idea.
> Forces you to repeat youself. And yes, having the IDE
> automatically grind repetitious code for you is not the answer.
> And I don't really feel that everything is a object or belongs in a class.
>
> Can't say I found C# software to be particularly buggy.
>
> That microsoft is super buggy is more of a myth now.
> Most of that changed with Windows 2000 when the system DLL problem was
> fixed.
> The introduction of Kerberos also adressed the most critical security
> issues.
> Then there was the deprecation of all dangerous functions in the C libray.
> They have actually made significant efforts to improve things there.
>
Ok I just deleted a folder in XP and the icon is still why the folder
is deleted (I hope so) . Yesterday the restore points didn't worked.
Week ago installing oracle xe makes services panel unaccessible , is
that no bug for you ? Try FreeBSD (DesctopBSD) and see the difference
for yourself.
> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/
From: Edward Dodge
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <m2bqgpgolj.fsf@gmail.com>
"Kjetil S. Matheussen" <··············@notam02.no> writes:
<snip>
> For larger mathematical expressions, I think s-expressions are much
> better because you can use more lines and indentations to make
> things clearer.
>
> This is of course my own subjective view. :-)
Think about the more powerful case: automating the building and
manipulation of large mathematical expressions. There's a /reason/
LISP is used to check and generate mathematical proofs.
Can't make a complicated, special-case mathematical expression look
readable in LISP? So what? If readability of one-off equations were
key, you'd be doing it in some other less versatile language anyway.
--
Edward Dodge
From: Daniel C. Wang
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <46475785.5080308@gmail.com>
Edward Dodge wrote:
{stuff deleted}
> Think about the more powerful case: automating the building and
> manipulation of large mathematical expressions. There's a /reason/
> LISP is used to check and generate mathematical proofs.
Most recent theorem proving environments are written in ML, which offers
infix operators. Some MLs provide for infix operators that are even user
definable. The ACL2 are PVS being the two biggest proof systems based on
LISP. PVS has infix operators, and ACL2 offers and infix package. Prolog
syntax which offer infix as well as meta-programming I find more
readable than s-expressions.
Just some facts from which you can draw your own conclusions from.
········@gmail.com wrote:
> The only language which Lisp still is not able to beat is in fact
> assembler...
and most other languages:
http://www.ffconsultancy.com/languages/ray_tracer/index.html
Note that Lisp is both the slowest and the verbose. The latter is thanks to
s-exprs and a bare-bones language.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Frederic Beal
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <slrnf45hpm.3il.beal@clipper.ens.fr>
On 2007-05-10, ········@gmail.com <········@gmail.com> wrote:
> If a problem is so (relatively) trivial that there exist hardware
> implementations of it (ray tracing), it is certainly a very bad
> example for language comparison... (all of your cited examples compare
> very badly to the hardware solution).
>
> So you took a typical problem best solved in hardware, and made a
> software (programming language) comparison out of it:
>
> Was this decision wise?
Yes, because it supports his predetermined conclusion :-)
BTW, if Mr. Harrop reads this, I've been trying to translate his program
into Haskell, but since the ML source code (first version ray.ml) produces
compile-time error (bad typing), I cannot try it...
--
Frederic
Frederic Beal wrote:
> BTW, if Mr. Harrop reads this, I've been trying to translate his program
> into Haskell, but since the ML source code (first version ray.ml) produces
> compile-time error (bad typing), I cannot try it...
Are you using the compile line that is given on the site?
I'd love to see a Haskell version...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Frederic Beal
Subject: Re: How Lisp's Nested Notation Limits The Language's Utility
Date:
Message-ID: <slrnf461h4.5i2.beal@clipper.ens.fr>
On 2007-05-10, Jon Harrop <···@ffconsultancy.com> wrote:
> Are you using the compile line that is given on the site?
Oh, I see you use recursive types. What is the rationale for that ?
--
Frederic Beal
On May 9, 1:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> ········@gmail.com wrote:
> > The only language which Lisp still is not able to beat is in fact
> > assembler...
>
> and most other languages:
>
> http://www.ffconsultancy.com/languages/ray_tracer/index.html
>
> Note that Lisp is both theslowestand the verbose. The latter is thanks to
> s-exprs and a bare-bones language.
It is far more likely that the problem lies in the fact that the
benchmark makes heavy use of floating-point numbers and the overhead
of maintaining a tagged representation is the problem.
Joe Marshall wrote:
> On May 9, 1:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Note that Lisp is both theslowestand the verbose. The latter is thanks to
>> s-exprs and a bare-bones language.
>
> It is far more likely that the problem lies in the fact that the
> benchmark makes heavy use of floating-point numbers and the overhead
> of maintaining a tagged representation is the problem.
Why would that afflict Lisp and not Scheme/OCaml/SML/...?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 10, 5:28 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Joe Marshall wrote:
> > On May 9, 1:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> Note that Lisp is both theslowestand the verbose. The latter is thanks to
> >> s-exprs and a bare-bones language.
>
> > It is far more likely that the problem lies in the fact that the
> > benchmark makes heavy use of floating-point numbers and the overhead
> > of maintaining a tagged representation is the problem.
>
> Why would that afflict Lisp and not Scheme/OCaml/SML/...?
I misunderstood your claim. The tagged representation at runtime has
nothing to do with the verbosity of the source code.
From among one-character operators, two-character parentheses and
four-letter insults ( :-) ) I found the following two interesting
statements:
1. Nested function calls are not appropriate in all situations
2. Lisp's notation for (nested) function calls introduces some more
problems
I think point #1 is very good vand valid. Sometimes (this of course
depends on the situation and the reader) nesting just gets too deep to be
readable.
Nesting is especially inappropriate when the semantics of the code is to
pass data throgh a chain of functions. As many have demonstrated, function
composition (or its special case, pipeline) communicates the serial
semantics much better.
The discussion motivated me to implement function composition in my
ngrease language. The following acceptance test shows it in action:
$:assert:$:equals {
abcd
$:compose {
_:a
$:append-symbols {$:_ b}
$:append-symbols {$:_ c}
$:append-symbols {$:_ d}
}
}
(From
http://ngrease.svn.sourceforge.net/viewvc/ngrease/trunk/ngrease-acceptancetests/src/test/java/net/sf/ngrease/acceptancetests/metaevaluation/compose.ngr?revision=209&view=markup
)
The implementation of the $:compose expression may not be very readable at
this stage where the standard library of ngrease is so limited. Some
general hints for reading: $:with is pretty much the same as lisp's let;
an element is treated as constant unless "animated" by putting it inside a
metaelement, $:
compose(source):
$:with {
$:evaluate:$:child {index:0 of:$:source}
var-symbol:$:symbol-of:$:evaluate:$:child {index:0 of:$:source}
var-declaration:$:evaluate:$:child {index:0 of:$:source}
$:if {
$:> {$:child-count:$:source 1}
$:with {
first-subresult:$:evaluate:$:child {index:1 of:$:source}
$:$:append-children {
to:compose {
$:append-child {$:var-symbol $:first-subresult}
}
from:$:keep-children {
of:$:source
index-symbol:index
if:$:> {$:index 1}
}
}
}
$:child {index:0 of:$:var-declaration}
}
}
(From
http://ngrease.svn.sourceforge.net/viewvc/ngrease/trunk/ngrease-metalanguage/src/main/java/net/sf/ngrease/core/metalanguage/default-context.ngr?revision=208&view=markup
)
The expression is included in the newest release, ngrease 0.1.1 (available
at http://sourceforge.net/projects/ngrease).
----
Point #2 is more debatable, but from my Domain Specific Languages point of
view a partially agree.
"S-expressions are fine, but as a base for domain specific languages they
have one flaw: An s-expression is either a childless singular or an
anonymous list. In natural speech things almost always have explicit,
domain-specific names, and anonymous collections are seldom used. ngrease
doesn't even support anonymous plurals. There can only be explicitly named
singulars, which may or may not contain other singulars."
(An excerpt from
http://ngrease.sourceforge.net/introduction.html#Lispdialects)
ngrease isn't really competing against Lisp. I wouldn't dream of proposing
changes to Lisp; its awesome history is proof enough for its utility. But
for my DSL purposes I (mostly intuitively) prefer the ngrease syntax
(inspired by the Groovy builder syntax), not to mention other features
that IMHO make it more flexible as a metalanguage.
Critique of that last statement is very welcome :)
- Ville Oikarinen
Ville Oikarinen <·····@oikarinen.org> writes:
> From among one-character operators, two-character parentheses and
> four-letter insults ( :-) ) I found the following two interesting
> statements:
>
> 1. Nested function calls are not appropriate in all situations
>
> 2. Lisp's notation for (nested) function calls introduces some more
> problems
>
> I think point #1 is very good vand valid. Sometimes (this of course
> depends on the situation and the reader) nesting just gets too deep to be
> readable.
If you think point #1 is valid, why do you think point #2 is true?
At least, the global balance of the lisp notation, if you think
function call nesting introduces some problem sometimes, is positive,
since at the same time, it's the very lisp notation that allows us to
write a _simple_ solution, in the form of a compose macro. See below.
> Nesting is especially inappropriate when the semantics of the code is to
> pass data throgh a chain of functions. As many have demonstrated, function
> composition (or its special case, pipeline) communicates the serial
> semantics much better.
>
> The discussion motivated me to implement function composition in my
> ngrease language. The following acceptance test shows it in action:
>
> $:assert:$:equals {
> abcd
> $:compose {
> _:a
> $:append-symbols {$:_ b}
> $:append-symbols {$:_ c}
> $:append-symbols {$:_ d}
> }
> }
>
> (From
> http://ngrease.svn.sourceforge.net/viewvc/ngrease/trunk/ngrease-acceptancetests/src/test/java/net/sf/ngrease/acceptancetests/metaevaluation/compose.ngr?revision=209&view=markup
> )
>
> The implementation of the $:compose expression may not be very readable at
> this stage where the standard library of ngrease is so limited. Some
> general hints for reading: $:with is pretty much the same as lisp's let;
> an element is treated as constant unless "animated" by putting it inside a
> metaelement, $:
>
> compose(source):
> $:with {
> $:evaluate:$:child {index:0 of:$:source}
> var-symbol:$:symbol-of:$:evaluate:$:child {index:0 of:$:source}
> var-declaration:$:evaluate:$:child {index:0 of:$:source}
> $:if {
> $:> {$:child-count:$:source 1}
> $:with {
> first-subresult:$:evaluate:$:child {index:1 of:$:source}
> $:$:append-children {
> to:compose {
> $:append-child {$:var-symbol $:first-subresult}
> }
> from:$:keep-children {
> of:$:source
> index-symbol:index
> if:$:> {$:index 1}
> }
> }
> }
> $:child {index:0 of:$:var-declaration}
> }
> }
(defun compose-sexp (functions var)
(if (null functions)
var
(list (car functions) (compose-sexp (cdr functions) var))))
(defmacro compose (&rest functions)
`(lambda (x) ,(compose-sexp functions 'x)))
(funcall (compose / 1+ 1+) 2)
--> 1/4
Note how much more concise the lisp code is compared to your language.
And this is not a question of library, here I use only NULL, LIST,
CAR, CDR and LAMBDA...
It's good that it's possible to write macros in your language; it
would be better if it was as easy as in lisp! ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
> If you think point #1 is valid, why do you think point #2 is true?
>
> At least, the global balance of the lisp notation, if you think
> function call nesting introduces some problem sometimes, is positive,
> since at the same time, it's the very lisp notation that allows us to
> write a _simple_ solution, in the form of a compose macro. See below.
I'm not quite sure what you mean. Anyway, function nesting is a common and
natural structure. Nothing bad there. And yes, like demonstrated many
times, function composition can be implemented using function nesting. The
simple fact is that both nesting and composition have their uses, and it
is good to have them both, one way or another.
Then, about the Lisp's "Head insinde parentheses" convention. Like Xah Lee
demonstrated, generating the function dynamically for a function call is
easier, if the function is inside. I have already experienced that when
writing code with ngrease, which puts the function symbol outside.
This is a very good example of how a language's primary use dictates its
design. Lisp, as a general-purpose language, is designed to make it
maximally easy to create and execute function calls.
That's why the function call is so simple and even _implicit_: it's just
an anonymous list that is _interpreted_ as a function call after a certain
convention.
ngrease, on the other hand, is designed to make it maximally easy to
create mostly constant trees, that communicate some domain-specific
intention. So ngrease can be thought of as a tree template language. IMHO
"symbol outside" fits this goal better, because that way the
(domain-specific) semantic density of the tree isn't diminished by the
fact that almost everything is wrapped inside an anonymous list.
More about this below.
> (defun compose-sexp (functions var)
> (if (null functions)
> var
> (list (car functions) (compose-sexp (cdr functions) var))))
>
> (defmacro compose (&rest functions)
> `(lambda (x) ,(compose-sexp functions 'x)))
>
> (funcall (compose / 1+ 1+) 2)
> --> 1/4
>
>
> Note how much more concise the lisp code is compared to your language.
> And this is not a question of library, here I use only NULL, LIST,
> CAR, CDR and LAMBDA...
>
> It's good that it's possible to write macros in your language; it
> would be better if it was as easy as in lisp! ;-)
I'm very grateful for your comment on my language. It's the first
nontrivial technical comment I've got so far :)
You are right, Lisp code is more concise, and I didn't expect my language
to beat Lisp on its own ground, especially after only two releases :)
However, there are some points I'd like to elaborate:
Like I explained above, it's all about what features of a language are
considered the most important, and it's them that should be optimized,
notation-wise.
Because function call isn't the most commonly anticipated use of ngrease,
it isn't given a minimal notation. So if ngrease is going to implement all
the Lisp's tricks, it must be more explicit.
Conceptually, lisp's ((generate-a-function) param1 param2) is something
like this, in ngr pseudo code:
evaluate {
function:evaluate {
function:generate-a-function
}
parameters {
param1
param2
}
}
In ngrease there is no separation between macros and functions: they are
both just transformers that transform a (function/macro/expression) call
into its value. So each "function" just gets one argument: the call, in
which the root of the tree is the function name and the chilren are the
arguments.
So, if the function name needs to be generated dynamically, so far I have
used something like this:
$:set-symbol {
$:generate-the-call-with-some-wrong-root-symbol
$:generate-the-correct-function-name
}
This is clumsy (and smells of too much nesting!), but when I've had enough
of writing code like that, I'll probably implement something easier,
starging from the pseudo code above.
Another point about the verbosity of my $:compose implementation: (car
list) is implemented in ngrease using the more general-purpose $:child
expression like this: $:child {index:0 of:list}.
Specialized functions make more concise code, but so far I've tried to
find the minimal library and only later (with experience of what is
needed) create convenience features. And when I've extracted enough of
first children with $:child, I'll probably implement car (of course, I
won't name it after an ancient assembler instruction :).
Another reason why my code is more verbose: if I read your code correctly
(I have very little experience on Lisp dialects, especially other than
Scheme), your macro only supports currying style function generation. Mine
is more general, because it makes it possible to refer to the current var
anywhere in the expressions.
- Ville Oikarinen
> $:set-symbol {
> $:generate-the-call-with-some-wrong-root-symbol
> $:generate-the-correct-function-name
> }
A minor fix: The above example just generates the expression. If it also
needs to be evaluated, the following version is correct:
$:$:set-symbol {
$:generate-the-call-with-some-wrong-root-symbol
$:generate-the-correct-function-name
}
- Ville Oikarinen
From: Simon Richard Clarkstone
Subject: Empty function composition (was: Re: How Lisp's Nested Notation Limits The Language's Utility)
Date:
Message-ID: <f2t389$158$1@heffalump.dur.ac.uk>
Ville Oikarinen wrote:
> The discussion motivated me to implement function composition in my
> ngrease language. The following acceptance test shows it in action:
>
> $:assert:$:equals {
> abcd
> $:compose {
> _:a
> $:append-symbols {$:_ b}
> $:append-symbols {$:_ c}
> $:append-symbols {$:_ d}
> }
> }
>
> (From
> http://ngrease.svn.sourceforge.net/viewvc/ngrease/trunk/ngrease-acceptancetests/src/test/java/net/sf/ngrease/acceptancetests/metaevaluation/compose.ngr?revision=209&view=markup
> )
There is a potential bug in your acceptance tests. Normally in
programming and mathematics, an empty composition is not an error but is
the identity function, as the identity function is also the left and
right identity element for function composition. Is there a special
reason that this case is different?
--
Simon Richard Clarkstone:
··············@·····························@hotmail.com
"August 9 - I just made my signature file. Its only 6 pages long.
I will have to work on it some more." -- _Diary of an AOL User_
From: Ville Oikarinen
Subject: Re: Empty function composition (was: Re: How Lisp's Nested Notation Limits The Language's Utility)
Date:
Message-ID: <Pine.LNX.4.56L0.0705220837210.10929@localhost>
On Mon, 21 May 2007, Simon Richard Clarkstone wrote:
> Ville Oikarinen wrote:
> > The discussion motivated me to implement function composition in my
> > ngrease language. The following acceptance test shows it in action:
> >
> > $:assert:$:equals {
> > abcd
> > $:compose {
> > _:a
> > $:append-symbols {$:_ b}
> > $:append-symbols {$:_ c}
> > $:append-symbols {$:_ d}
> > }
> > }
> >
> > (From
> > http://ngrease.svn.sourceforge.net/viewvc/ngrease/trunk/ngrease-acceptancetests/src/test/java/net/sf/ngrease/acceptancetests/metaevaluation/compose.ngr?revision=209&view=markup
> > )
>
> There is a potential bug in your acceptance tests. Normally in
> programming and mathematics, an empty composition is not an error but is
> the identity function, as the identity function is also the left and
> right identity element for function composition. Is there a special
> reason that this case is different?
It's because $:compose is not really a mathematical composition function
that gets a list of functions and returns a composition function.
Instead it uses its first child as the variable declaration that both
defines the initial value and the symbol that can be used to refer the
current var value in the "function" expressions. So it kind of creates the
composition and calls it at the same time.
In ngrease an empty composition is a $:compose expression that has no
other children than the initial value declaration (see the second
acceptance test for an example).
I admit that the expression should probably have some other name than
compose, because it does two things. What would be a good name?
compose-call?
Maybe a function-generating variation of the $:compose expression could
work like this (just an unimplemented sketch that may have typos):
$:assert:$:equals {
abc
$:with {
f:$:quote:$:compose {
_
$:append-symbols {$:_ b}
$:append-symbols {$:_ c}
}
$:f:a
}
}
Here the first child of $:compose just defines the symbol without an
initial value. In this example f will be an expression that, when
evaluated, reads the only child, a, from its invocation and binds it to _
before evaluating the subexpressions in sequence.
- Ville Oikarinen