Fundamental Problems of Lisp
Perm url:
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
plain text version follows.
----------------------------------------------
...
Since i'm writing... n i wrote a lot in the past on diverse issues
scattered
in various essays... i'll sum some fundamental problems of lisp.
• Lisp relies on a regular nested syntax. However, the lisp syntax has
several
irregularities, that reduces such syntax's power and confuses the
language
semantics. (i.e. those «' # ; ` ,» chars.) (and whenever i tried to
get some
technical answer about this to clarify at least my own understanding,
the lisp
fuckheads muck and obfuscate the truth)
• Lisp's irregular syntax those «' # ; ` ,» things, are practically
confusing
and made the lang less powerful. i.e. in elisp, there's no form of
comments in
matching delimiters (and consequently no nested comment). The reliance
on EOL
chars as part of the syntax semantics is one of the major fuckup to
the power
of pure nested syntax.
• Lisp relies on a regular nested syntax. Because of such regularity
of the
syntax, it has very powerful consequences, at least theoretically.
(and
practically, lispers realized just one: the lisp macros) For example,
since
the syntax is regular, one could easily have alternative, easier to
read
syntaxes as a layer. (the concept is somewhat known in early lisp as
M-expression) Mathematica took this advantage (probably independent of
lisp's
influence), so that you really have easy to read syntax, yet fully
retain the
regular form advantages. Lisp, on the other hand, such alternative
syntax has
been done and tried here and there in various forms or langs, but
never caught
on due to largely social reasons. Part of these reasons are political.
(thanks
to, in part, the Lisp old hats that suppresses it.)
• One of the advantage of pure fully functional syntax is that a
programer
should never, ever need to format his source code (i.e. pressing tabs,
returns) in coding, and save the hundreds hours of labor, guides,
tutorials,
advices, publications, editor tools, on what's known as “coding style
convention”, because the editor can trivially reformat the source code
on the
fly based on a simple lexical scan. This is done in Mathematica
version 3
(~1996). In coding elisp, i'm pained to no ends by the manual process
of
formatting lisp code. The lisp community, established a particular way
of
formatting lisp code as exhibited in emacs's lisp modes and written
guides in
conventions. The recognization of such convention further erode any
possibility and awareness of automatic, uniform, formatting.
• Lisp relies on a regular nested syntax. One of the power of such
pure syntax
is that you could build up layers on top of it, so that the source
code can
function as markup of conventional mathematical notations (i.e. LaTeX)
and or
as a word-processing-like file that can contain structures, images,
yet lose
practical nothing. This is done in Mathematica in ~1996 with release
of
Mathematica version 3.
Further readings:
* The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional
Notations
* The Harm of Hard-wrapping Lines
* A Text Editor Feature: Syntax Tree Walk
* A Simple Lisp Code Formatter
The above are some of the damages lispers has done to themselfs, with
respect
to its nested functional syntax. The other major one is the cons
business.
• Lisp at core is based on functional programing on lists. This is
very
powerful. However, for historical reasons, lisp's list is based on the
hardware concept of “cons” cell. This fundamentally handicapped the
advantages
of power of list processing.
Lisp being historically based the cons for like 2 or 3 decades. The
cons (and
cdr, car, caadar etc) are fundamentally rooted in the lisp langs, is
thus not
something that can be easily fixed. Quite unfortunate. However, this
situation
could be improved. But, whenever i discuss this, you can see that the
lisper
slaves here, their mentality, prevents any possible improvement. (in
general,
this is because, lispers usually do not have serious experience or
investment
in other functional langs, such as Mathematica, Haskell, etc.)
One of the myth that are quickly embedded into budding lispers, is
that cons
are powerful. Powerful my ass. It is powerful in the sense any
assembly lang
is powerful. Lisp's cons is perhaps the greatest fuck up in the
history of
computer languages.
Further readings:
* Lisp's List Problem
* My First Encounter And Impression Of Lisp
* The Jargon “Lisp1” vs “Lisp2”
Will Lisp ever be Popular?
Mathematica today sells for over 2 thousands dollars. Its sales
record,
throughout its history, is probably more than ALL commercial lisps
combined.
Such a illuminating social fact, in not known in lisp communities.
These
fuckheads thinks that lisp is more popular.
10 years ago, in the dot come days (~1998), where Java, Javascript,
Perl are
screaming the rounds. It was my opinion, that lisp will inevitably
become
popular in the future, simply due to its inherent superior design,
simplicity,
flexibility, power, whatever its existing problems may be. Now i don't
think
that'll ever happen as is. Because, due to the tremendous
technological
advances, in particular in communication (i.e. the internet and its
consequences, e.g. Wikipedia, youtube, youporn, social networks sites,
Instant
chat, etc) computer languages are proliferating like never before.
(i.e.
because the abundance of tools, libraries, parsers, existance of
infrastructure) New langs, basically will have all the advantages of
lisps or
lisp's fundamental concepts or principles. I see that, perhaps in the
next
decade, as communication technologies further hurl us forward, the
proliferation of langs will reduce to a trend of consolidation (e.g.
fueled by
virtual machines such as Microsoft's .NET. (and, btw, the breaking of
social
taboo of cross communication led by Xah Lee)).
There is one slight hope for Lisp the lang as we understood it, and
that is
emacs lisp. Due to, it being deeply rooted in the industry as a
powerful text
editor, and the embedded lisp have major practical impact in getting
people to
know lisp and also actually use it for practical need. (this
satisfying
prospect is however mar'd by the tech geekers. e.g. the Common
Lispers, and
Scheme Lispers, perennially inject snide and sneer at emacs lisp that
harms
its progress, while the fucking emacs priests, want to coffin emacs
perpetually in its 1980s UI and terminologies.)
Xah
∑ http://xahlee.org/
☄
On Jul 13, 10:53 am, ·······@gmail.com" <······@gmail.com> wrote:
> Fundamental Problems of Lisp
>
> Perm url:http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> plain text version follows.
>
> Will Lisp ever be Popular?
>
> Mathematica today sells for over 2 thousands dollars. Its sales
> record,
> throughout its history, is probably more than ALL commercial lisps
> combined.
You infer that Mathematica is popular due to its syntax as a
programming language and ignore that it was the first user-friendly
symbolic math system and gained its user base on that strength. Much
of that base is people who are far more interested in the math than
the programming language aspect. I'm neither a Lisp nor a Mathematica
zealot. But I've used both. Mathematica has its own warts, and a
long list of them at that, thought its good enough for what it does.
As a general purpose programming language, it would be a failure.
······@gmail.com breaking news:
> Fundamental Problems of Lisp
Xah, I love you, we should become friends!
There seems to be no real contents in your postings, only some pseudo
scientific Lisp bashing.
Exactly the same art I'm specialized in.
Congrats, keep up your good work! Together we will win them all!
Jon Harrop
Xah Lee wrote:
«
Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
»
Jon Harrop wrote:
> Xah, I love you, we should become friends!
>
> There seems to be no real contents in your postings, only some pseudo
> scientific Lisp bashing.
> Exactly the same art I'm specialized in.
>
> Congrats, keep up your good work! Together we will win them all!
I must say, sometimes i lookup to your courage in frequent cross
posting, even though i consider your posts are proper with respect to
the various forum's explicit or implicit charters. (though, i do see
your tendency to peddle your website, and freely inject your little
personal gripes about Mathematica or whatever)
When i cross post, and if my subject or opinion is controversial, and
or my writting demeanor is to be non-conformal, i limit myself to
maybe 1 post per week or month, as a matter of self-imposed discipline
and respect for the larger community. I've been following this more or
less since about 2004.
And, when i post controversial or non-conformal ways, i made sure i
spend great time on it. (1 or 2 hours is typical. 6 hours composition,
broken into multiple days, is not unusual) I almost never, do a post
that's trivial like just few lines. (i've been gradually relaxing this
rule in recent years, however.)
For example, some of these philosophies i've written publically before
(often with the result of being ostracized from the community).
• Philosophies of Netiquette
http://xahlee.org/UnixResource_dir/writ/phil_netiquette.html
• “Old School Netiquette (The traffic of Well-written vs One-liner
posts)”
http://xahlee.org/UnixResource_dir/writ/os_netiquette.html
My own dilemma in recent years, is whether i shall keep aloof with
some sense of immaculateness in limiting sensitive posts to a few, yet
persistent possibly until i die. Or, should i just “relax”, mix-in,
adapt more of a every-body-is-a-friend writing style, and post
profusely, like multiple posts per day, with just one or two line per
post (like “thanks, but i don't agree.”), like them.
The litanies of nagging has its powers.
For example, in recent years i have spent great energy in emacs lisp.
I spent several months out of my decade long keyboarding experience to
have deviced a ergonomic shortcut for emacs (or any text editing tasks
on computer keyboard). (been thinking of patent it) By my usual
practice, i would put it on my web page (so it's public), make a
announcement in appropriate forums once, and never speak of it again.
The basic philosophy is that I, don't do peddling. If it is good, let
people come to it. Marketing is a necessity, but its not something I,
shall deign to do. Like, if Einstein invented relativity, and nobody
belived it, that's their problem. History, will possibly eventually
recognize good things, possibly a while after the inventor is dead.
(long list of examples here... e.g. Dvorak keymap in our context.
(btw, Richard Stallman, is somewhat aloof like this, however, he
invented the the Gnu General Public (viral) License, Free Software
Foundation, full-fledged with laws and lawers, which in the end made
him and his ideas successful, as opposed to the huge number of free-
spirited software such as BSDs etc. (Richard Stalman, also, freely
abused English words such as “hacker”, “freedom”, to sell his
ideas.)))
But, i have second thoughts. Fame, power, leadership, seduces me. For
example, instead of my aloof behavior, i could just be like a “normal”
human animal. When i see people asking about difficult emacs
keybindings in emacs forums, which happens frequently maybe at least
once a month, i could just say, “hey, by chance i did this keymap. Try
it out, maybe it'll help!”. And whenever i did minor update to my page
about it, or have some minor thoughts about my keymap design, i'll
just post: “hi guys, thanks a lot for previous feedback. Recently i've
been thinking xyz design, what do you think?” Usually, the more
trivial the question, the more numerous the reply. People, especially
in modern society, in particular the tech geekers, are a very lonely
bunch. They are EAGER to help, contribute their opinions. We NEED the
emontional touch. (every book on friendship, leadership or politics,
will tell you about the importance of establishing supporters) Also,
avoid making a post that's more than, say, 2 short paragraphs long, or
construct very logical sentences, or use big words. That makes you
less approachable.
I'm not sure Socrates or Plato would approve such relationship style.
But by Allah, didn't Goddess Fortuna put Socrates to death by poison
drinking?
Ok, 2.5 hours went into this post. I shall make a stop and post what i
have now, lest i become unapproachable.
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> Like, if Einstein invented relativity, and nobody
> belived it, that's their problem.
You're not Einstein, even though you probably believe you are.
On Sun, 13 Jul 2008 07:53:38 -0700 (PDT), ·······@gmail.com" <······@gmail.com> said:
| ...
| i.e. in elisp, there's no form of comments in matching delimiters
| (and consequently no nested comment).
That is not entirely true. XEmacs, at least, implements the `#+'
syntax, which can be used to comment out well-formed S-expressions
without relying on newlines, and such constructs do nest: if we
start with
(foo)
(bar)
(baz)
(quux)
then in
(foo)
#+(or) (
(bar)
(baz)
)
(quux)
(FOO) and (BAR) are effectively commented out, and then in
#+(or) (
(foo)
#+(or) (
(bar)
(baz)
)
(quux)
)
the whole thing is commented out.
| ...
| since the syntax is regular, one could easily have alternative,
| easier to read syntaxes as a layer. (the concept is somewhat known
| in early lisp as M-expression)
M-expressions are not an "alternative syntax as a layer". Rather,
they are an (abstract) algorithmic language, which can be translated
into S-expressions as forms in the Lisp programming language.
M-expressions make an extensive appearance in John Allen's
_Anatomy of LISP_ (recommended reading whether or not the reader is
interested in M-expressions). I don't have a good pointer to an
Internet source (as of this writing, the Wikipedia article is not
much to go by).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> wrote:
+---------------
| That is not entirely true. XEmacs, at least, implements the `#+'
| syntax, which can be used to comment out well-formed S-expressions...
...
| #+(or) (
| (bar)
| (baz)
| )
| (FOO) and (BAR) are effectively commented out...
+---------------
Ever since a long-ago thread [in which Erik Naggum was an active
participant, so that tells you how long ago it was!!] in which
this style was presented as a better alternative to #+NIL [which
can break if :NIL ever got onto *FEATURES*], I've found it rather
distasteful -- *not* because there's anything technically "wrong"
with it [there's not], but because of the cognitive dissonance of
the "+" implying the exact *opposite* of what you're trying to do!!
Ditto "#-(or)" to un-comment something -- flat-out backwards! So
ever since then I've been using Erik's suggestion from that thread:
#+(and) to *enable* an S-expression.
#-(and) to "comment out" an S-expression.
Now the "+"/enable and "-"/disable semantics line up:
#-(and) ( ;turn off (BAR) & (BAZ)
(bar)
(baz)
)
Yes, using AND is one character longer than using OR, but
reading it [by humans!] is simply more reliable.
-Rob
p.s. O.k., confession time: Even more recently I've started getting
a bit lazy and using "#-+" to enable and "#+-" to comment out.
My mnemonic is that "#-+" represents a "rising edge", that is,
goes "from off to on" (enables), while the "falling edge" "#+-"
goes "from on to off" (*dis*ables). Yes, it depends upon
(INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
really, *really* unlikely to be violated.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Sun, 13 Jul 2008 20:36:01 -0500, ····@rpw3.org (Rob Warnock) said:
| ...
| the cognitive dissonance of
| the "+" implying the exact *opposite* of what you're trying to do!!
| Ditto "#-(or)" to un-comment something -- flat-out backwards! So
| ever since then I've been using Erik's suggestion from that thread:
| #+(and) to *enable* an S-expression.
| #-(and) to "comment out" an S-expression.
| Now the "+"/enable and "-"/disable semantics line up:
| #-(and) ( ;turn off (BAR) & (BAZ)
| (bar)
| (baz)
| )
| Yes, using AND is one character longer than using OR, but
| reading it [by humans!] is simply more reliable.
You may well be right that `#-(AND)' is cognitively safer; myself,
not only had I forgotten that particular part about preferring
`#-(AND)' to `#+(OR)', but I didn't perceive the plus sign as one
for "adding" anything in this context, either, but applied the
(private) mnemonic that the latter is like "'hash-sign' and 'or'",
i.e. `#|'.
(Until one starts perceiving this idiomatically, working out #-(AND)
involves working out a double negation, of which I am not a
particularly big fan, but that probably matters little. In other
words, I'd prefer ``(WHEN false ...)'' (`#+(OR)') to ``(UNLESS true ...)''
(`#-(AND)').)
---Vassil.
P.S. Sadly, Erik Naggum will not be explaining how wrong I am (and I
am not being sarcastic here).
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> writes:
> On Sun, 13 Jul 2008 20:36:01 -0500, ····@rpw3.org (Rob Warnock) said:
> | ...
> | the cognitive dissonance of
> | the "+" implying the exact *opposite* of what you're trying to do!!
> | Ditto "#-(or)" to un-comment something -- flat-out backwards! So
> | ever since then I've been using Erik's suggestion from that thread:
>
> | #+(and) to *enable* an S-expression.
>
> | #-(and) to "comment out" an S-expression.
>
> | Now the "+"/enable and "-"/disable semantics line up:
>
> | #-(and) ( ;turn off (BAR) & (BAZ)
> | (bar)
> | (baz)
> | )
>
> | Yes, using AND is one character longer than using OR, but
> | reading it [by humans!] is simply more reliable.
>
> You may well be right that `#-(AND)' is cognitively safer; myself,
> not only had I forgotten that particular part about preferring
> `#-(AND)' to `#+(OR)', but I didn't perceive the plus sign as one
> for "adding" anything in this context, either, but applied the
> (private) mnemonic that the latter is like "'hash-sign' and 'or'",
> i.e. `#|'.
>
> (Until one starts perceiving this idiomatically, working out #-(AND)
> involves working out a double negation, of which I am not a
> particularly big fan, but that probably matters little. In other
> words, I'd prefer ``(WHEN false ...)'' (`#+(OR)') to ``(UNLESS true ...)''
You could also use:
'(
#+(and) x
#+(not (and)) y
)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
From: http://public.xdi.org/=pf
Subject: Re: some corrections Re: The Fundamental Problems of Lisp
Date:
Message-ID: <m2fxqcinft.fsf@mycroft.actrix.gen.nz>
On Sun, 13 Jul 2008 20:36:01 -0500, Rob Warnock wrote:
> Vassil Nikolov <···············@pobox.com> wrote:
> +---------------
> | That is not entirely true. XEmacs, at least, implements the `#+'
> | syntax, which can be used to comment out well-formed S-expressions...
> ...
> | #+(or) (
> | (bar)
> | (baz)
> | )
> | (FOO) and (BAR) are effectively commented out...
> +---------------
> Ever since a long-ago thread [in which Erik Naggum was an active
> participant, so that tells you how long ago it was!!] in which
> this style was presented as a better alternative to #+NIL [which
> can break if :NIL ever got onto *FEATURES*], I've found it rather
> distasteful -- *not* because there's anything technically "wrong"
> with it [there's not], but because of the cognitive dissonance of
> the "+" implying the exact *opposite* of what you're trying to do!!
But it's not; #+(or) is like (when nil ...), which is exactly what I
would write if I ever wanted to write that sort of thing; also, #+xxx
is normally "special" (i.e., likely-to-be-disabled) case, so if you
start using #-(and) and #+(and) you're suddenly reversing the normal
sense of #+ and #- ... that's not good.
> Yes, using AND is one character longer than using OR, but
> reading it [by humans!] is simply more reliable.
Not by this human!
> p.s. O.k., confession time: Even more recently I've started getting
> a bit lazy and using "#-+" to enable and "#+-" to comment out.
At least it uses #+ the right way around
--
Tact is the ability to tell a man he has an open mind when he has a
hole in his head.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
·······@gmail.com" <······@gmail.com> writes:
Lisp relies on a regular nested syntax. However, the
lisp syntax has several irregularities, that reduces
such syntax's power and confuses the language
semantics. (i.e. those «' # ; ` ,» chars.)
I am not a lisp expert. My understanding is that the
standard quote, as in 'foo is syntactic sugar for (quote
foo), and that the correspondence is one-to-one. So you
could, if you liked, simply write all your code without it.
You could, of course, also write all your code without
comments, as well. You might like using a more "pure" (so
to speak) dialect of lisp than Common Lisp or even Emacs
Lisp. I wish there was a port of Lisp 1 or Lisp 1.5
available for common modern systems (is there?) to play
with, but I do believe there a few lisps available based on
such a model. Or perhaps you could write one.
[...] in elisp, there's no form of comments in matching
delimiters (and consequently no nested comment). The
reliance on EOL chars as part of the syntax semantics is
one of the major fuckup to the power of pure nested
syntax.
I don't know how the built-in documentation mechanism works,
but I gather that it has to do with the fact that a defun
only returns its last value. Maybe that concept could be
extended to work with other embedded strings, as in:
(defun foo (slaz)
"This function grovels the slaz. Then returns t"
(grovel slaz) "This is a comment"
"This functions like a comment too."
t)
Of course this adds the comments to your lisp image, but
then maybe it would allow for "literate programming" style
practices. Maybe some of the most common operators could be
programed to take an optional throw-away argument where you
could plug in comments.
But really, unless your purpose is to make those comments
available in your image, what difference does it make? The
comments are there for humans reading the code, so what
difference does it make if EOL is made the comment end syntax?
since the syntax is regular, one could easily have
alternative, easier to read syntaxes as a layer. (the
concept is somewhat known in early lisp as M-expression)
It's debatable whether M syntax is easier to read than S
syntax. But it is interesting that, that having been the
initial intent of McCarthy et al, there was never enough
motivation to actually implement it. Certainly I prefer
lisp syntax to that of any other language I have dabbled
with. And then I believe that a number of macro-based
alternate syntaxa /have/ been implemented in lisp. (What is
the plural of syntax, anyway?)
One of the advantage of pure fully functional syntax is
that a programer should never, ever need to format his
source code (i.e. pressing tabs, returns) [\ldots]
That sounds nice. I believe it is the CADR lisp machine
(not sure) that I once played with (under QEMU, I believe)
that had a nice feature that once you typed a final end
parenthesis for a form, the form was evaluated without you
having to hit enter. I implemented that for myself with
slime a while back for fun. But that is really a REPL
feature, not a language feature per se. Where your
interface to the language interpreter is through an editor,
as is obviously the case with Emacs lisp, it is arguable
that code grinding or formatting or whatever it is called is
an editor feature, not a language feature. Granted, the
syntax of the language can make implementing that more or
less difficult. Using EOL for comment ends makes having the
editor parse it and reformat it more difficult, but I
wouldn't think impossible.
I guess my point is that it is not really possible (as I
understand it) or convenient to build a programming language
that is absolutely nothing but lambda calculus. You still
need some things like an eval function, and a means of
telling it when to evaluate code or not, and a way to embed
comments in code, and so on. In order to be useful, the
language has to solve some problems of a purely practical
nature that aren't really part of the core concept of the
language. I'm no language designer, so I readily admit I
may not know what I'm talking about here. But having said
that, there are automatic code formatters out there for
languages like C; I would be surprised there are not for
lisp, precisely because it /does/ have such a generally
regular syntax.
Lisp relies on a regular nested syntax. One of the power
of such pure syntax is that you could build up layers on
top of it, so that the source code can function as
markup of conventional mathematical notations
(i.e. LaTeX) and or as a word-processing-like file that
can contain structures, images, yet lose practical
nothing.
I may not understand what you are saying here, but available
for at least Common Lisp are packages that turn
s-expressions into xml/html/sgml, etc, and into some kind of
(La)TeX I believe.
Lisp being historically based the cons for like 2 or 3
decades. The cons (and cdr, car, caadar etc) are
fundamentally rooted in the lisp langs, is thus not
something that can be easily fixed. Quite
unfortunate.
It is not immediately obvious to me why cons is a bad
thing. It's also not immediately obvious to my why it's a
good thing, either, so I would be interested in exactly what
it is that is bad about it.
Addendum:
in lisp communities, it is widely recognized that lisp's regular
syntax has the property that “code is data; data is code”. However,
there was never, clear, explanation what this means exactly.
Here's what it means exactly, in one concise paragarph.
A regular nested syntax, makes it easy (possible) to do source code
transformations with a lexical scan. (think of XML. See
http://en.wikipedia.org/wiki/XML_transformation_language )
The consequence of the ability to do such source code transformation,
are many as i discussed in previous article. (see
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html (Among
which, is lisp's so-called “macros”, pattern matching or term
rewriting (lisp's so-called “macros” is simple form of so-called term-
rewriting).))
among lispers, often when people ask what it means about lisp's “code
is data; datais code”, usually they are unable to explain it exactly,
because they don't possess mathematician's analytic abilities. Here
i'll repeat, and please remember it.
A regular nested syntax, makes it possible to do systimatic and
generalized source code transformations and trivial to implement.
There are important consequences. Some of the examples are: lisp's
macros, general pattern matching, term rewriting, source code dual
functioning as markup lang for presentation (i.e. word-processor,
notebook), mathematical markup (MathML;LaTeX), in general all benefits
of XML, on-the-fly source code “formatting” for a automatic, uniform,
universal, source code display (aka “coding style convention”).
(Note the phrase “automatic, uniform, universal, source code display”.
The “uniform” and “universal” aspect is a well-known propery of Python
lang's source code. The reason Python's source code has such uniform
and universal display formatting is because it is worked into the
language's sematics. i.e. the semantics of the code depends on the
formatting (i.e. where you press tabs and returns). But also note,
Python's source code is not and cannot be automatically formatted,
precisely because the semantics and formatting is tied together, with
a inprecise relation. A strictly regular nested syntax, such as
Mathematica's, can, and is done, since 1996. Lisp, despite its bunch
of irregularities such as thos «` ' # ; ,» chars, i think it still can
have a automatic formatting at least to a large, practical, extent.
(one of my future elisp project would be this) Once lisp has automatic
on-the-fly formatting (think of emacs's fill-sexp, auto-fill-sexp),
then lisp code will achieve uniform and universal source code
formatting display. By “uniform”, it is meant that there is one human-
readible cannonical way to display the source code. By “universal” is
meant that all programers, will recognize and habituated with this one
cannonical way, as a standard. (they can of course set their editor to
display it in other ways) The advantage of having a automatic,
uniform, universal, source code display for a language is that, by
having such properties, it will actually have a impact on how
programer codes in the language. i.e. what kind of idioms they choose
to use, where type of comments they make. This, further influences the
evolution of the language, i.e. what kind of functions or features are
added to the lang.
for some detail on this aspect, see:
“The Harm of Manual Code Formating”
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
)
------------------------------
The other point in my previous article discussed lisp's cons problems.
Here's what it means in a concise, mathematical perspective:
From a mathematical point of view, what this means is that lisp's
lists is limited to a max of 2 elements. If you want a longer list,
you must nest it and interpret it in a special way. (i.e. effectively
creating a mini-protocol of nesting lists, known as proper lists.) The
cons fundamentally crippled the development of list processing.
------------------------------
The cons issue bugged me for 10 years, since i first tried to learn
scheme in ~1999. I've never worked with lisp (other than academic
reading) until in recent years with emacs lisp since 2005. Several
times i tried to explain to lispers this problem, but usually with
paragraphs and paragraphs of descriptions, analogies, examples,
frustrated by how hard it is to convey such a simple flaw (aided by
their blind, deep-seated, lisp fanaticsm). Yesterday it hit on me. The
above mathematical aspect of lisp's cons is the first time i
formulated the cons problem concisely. (my previous verbose
explanation here: http://xahlee.org/emacs/lisp_list_problem.html
)
Also, about lisp's regular syntax being “data is code; code is
data”... it was also my first time seeing it clearly. (in my 10 years
of comp.lang.lisp reading, you read confusions.)
Xah
∑ http://xahlee.org/
☄
On 15 juil, 22:32, ·······@gmail.com" <······@gmail.com> wrote:
> Addendum:
>
> in lisp communities, it is widely recognized that lisp's regular
> syntax has the property that “code is data; data is code”. However,
> there was never, clear, explanation what this means exactly.
>
> Here's what it means exactly, in one concise paragarph.
>
> A regular nested syntax, makes it easy (possible) to do source code
> transformations with a lexical scan. (think of XML. Seehttp://en.wikipedia.org/wiki/XML_transformation_language)
>
> The consequence of the ability to do such source code transformation,
> are many as i discussed in previous article. (seehttp://xahlee.org/UnixResource_dir/writ/lisp_problems.html(Among
> which, is lisp's so-called “macros”, pattern matching or term
> rewriting (lisp's so-called “macros” is simple form of so-called term-
> rewriting).))
>
> among lispers, often when people ask what it means about lisp's “code
> is data; datais code”, usually they are unable to explain it exactly,
> because they don't possess mathematician's analytic abilities. Here
> i'll repeat, and please remember it.
>
> A regular nested syntax, makes it possible to do systimatic and
> generalized source code transformations and trivial to implement.
> There are important consequences. Some of the examples are: lisp's
> macros, general pattern matching, term rewriting, source code dual
> functioning as markup lang for presentation (i.e. word-processor,
> notebook), mathematical markup (MathML;LaTeX), in general all benefits
> of XML, on-the-fly source code “formatting” for a automatic, uniform,
> universal, source code display (aka “coding style convention”).
>
> (Note the phrase “automatic, uniform, universal, source code display”.
> The “uniform” and “universal” aspect is a well-known propery of Python
> lang's source code. The reason Python's source code has such uniform
> and universal display formatting is because it is worked into the
> language's sematics. i.e. the semantics of the code depends on the
> formatting (i.e. where you press tabs and returns). But also note,
> Python's source code is not and cannot be automatically formatted,
> precisely because the semantics and formatting is tied together, with
> a inprecise relation. A strictly regular nested syntax, such as
> Mathematica's, can, and is done, since 1996. Lisp, despite its bunch
> of irregularities such as thos «` ' # ; ,» chars, i think it still can
> have a automatic formatting at least to a large, practical, extent.
> (one of my future elisp project would be this) Once lisp has automatic
> on-the-fly formatting (think of emacs's fill-sexp, auto-fill-sexp),
> then lisp code will achieve uniform and universal source code
> formatting display. By “uniform”, it is meant that there is one human-
> readible cannonical way to display the source code. By “universal” is
> meant that all programers, will recognize and habituated with this one
> cannonical way, as a standard. (they can of course set their editor to
> display it in other ways) The advantage of having a automatic,
> uniform, universal, source code display for a language is that, by
> having such properties, it will actually have a impact on how
> programer codes in the language. i.e. what kind of idioms they choose
> to use, where type of comments they make. This, further influences the
> evolution of the language, i.e. what kind of functions or features are
> added to the lang.
>
> for some detail on this aspect, see:
> “The Harm of Manual Code Formating”http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
> )
>
> ------------------------------
>
> The other point in my previous article discussed lisp's cons problems.
> Here's what it means in a concise, mathematical perspective:
>
> From a mathematical point of view, what this means is that lisp's
> lists is limited to a max of 2 elements. If you want a longer list,
> you must nest it and interpret it in a special way. (i.e. effectively
> creating a mini-protocol of nesting lists, known as proper lists.) The
> cons fundamentally crippled the development of list processing.
>
> ------------------------------
>
> The cons issue bugged me for 10 years, since i first tried to learn
> scheme in ~1999. I've never worked with lisp (other than academic
> reading) until in recent years with emacs lisp since 2005. Several
> times i tried to explain to lispers this problem, but usually with
> paragraphs and paragraphs of descriptions, analogies, examples,
> frustrated by how hard it is to convey such a simple flaw (aided by
> their blind, deep-seated, lisp fanaticsm). Yesterday it hit on me. The
> above mathematical aspect of lisp's cons is the first time i
> formulated the cons problem concisely. (my previous verbose
> explanation here:http://xahlee.org/emacs/lisp_list_problem.html
> )
>
> Also, about lisp's regular syntax being “data is code; code is
> data”... it was also my first time seeing it clearly. (in my 10 years
> of comp.lang.lisp reading, you read confusions.)
>
> Xah
> ∑http://xahlee.org/
>
> ☄
They are no problem with cons, Community publish a lot of articles to
explain how avoid it. Read this before.
On 15 Jul., 22:32, ·······@gmail.com" <······@gmail.com> wrote:
> Addendum:
>
> in lisp communities, it is widely recognized that lisp's regular
> syntax has the property that “code is data; data is code”. However,
> there was never, clear, explanation what this means exactly.
>
> Here's what it means exactly, in one concise paragarph.
You are still totally confused.
Code is data and data is code:
Lisp uses the same external s-expression representation of Lisp
data for Lisp code.
Lisp programs can read, print and manipulate Lisp code like any
other Lisp data.
> Mathematica's, can, and is done, since 1996. Lisp, despite its bunch
> of irregularities such as thos «` ' # ; ,» chars, i think it still can
> have a automatic formatting at least to a large, practical, extent.
Sure it can. Many years before Mathematica it could already.
> (one of my future elisp project would be this)
Would be? So it isn't?
> Once lisp has automatic
> on-the-fly formatting (think of emacs's fill-sexp, auto-fill-sexp),
> then lisp code will achieve uniform and universal source code
> formatting display. By “uniform”, it is meant that there is one human-
> readible cannonical way to display the source code. By “universal” is
> meant that all programers, will recognize and habituated with this one
> cannonical way, as a standard. (they can of course set their editor to
> display it in other ways) The advantage of having a automatic,
> uniform, universal, source code display for a language is that, by
> having such properties, it will actually have a impact on how
> programer codes in the language. i.e. what kind of idioms they choose
> to use, where type of comments they make. This, further influences the
> evolution of the language, i.e. what kind of functions or features are
> added to the lang.
This has been done already several times. But it hasn't found much
following in the last years.
See chapter 16 of http://www.bitsavers.org/pdf/xerox/interlisp/3101273_InterlispD_2_Oct85.pdf
for the most prominent attempt.
Structure editors made sure that every source manipulation would
result in a valid s-expression.
Editors like Emacs allow us to write invalid or partially valid s-
expressions:
(defun foo a b + a b is not a valid s-expression. We can make it
valid:
(defun foo a b + a b) this is a valid s-exypression, but not valid
Lisp code. We can make it valid:
(defun foo (a b) (+ a b)) this is both a valid s-expression and
valid Lisp code.
A structure editor usually would allow only to create valid s-
expressions. Otherwise it would need to know how to deal
with invalid s-expressions (input, formatting, ...).
So, the most primitive approach would be to type free form in Emacs,
read the code using some command and then
use pretty printing to display the result in the buffer.
That's relatively easy to implement.
> ------------------------------
>
> The other point in my previous article discussed lisp's cons problems.
> Here's what it means in a concise, mathematical perspective:
>
> From a mathematical point of view, what this means is that lisp's
> lists is limited to a max of 2 elements. If you want a longer list,
> you must nest it and interpret it in a special way. (i.e. effectively
> creating a mini-protocol of nesting lists, known as proper lists.) The
> cons fundamentally crippled the development of list processing.
Hmm, sounds completely confused.
Why struggle with this? Write some code and be happy. Maybe use
Mathematica instead?
Dear Rainer Joswig,
Rainer wrote:
> Code is data and data is code:
>
> Lisp uses the same external s-expression representation of Lisp
> data for Lisp code.
> Lisp programs can read, print and manipulate Lisp code like any
> other Lisp data.
Yeah, and?
I wrote: «A regular nested syntax, makes it possible to do systematic
source code transformation in a way that's also trivial to implement.
There are important consequences. Some of the examples are: lisp's
macros, structural pattern matching, term rewriting, source code dual
functioning as markup lang for presentation (e.g. word-processor,
Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
general all benefits of XML, on-the-fly source code “formatting” for a
automatic, uniform, universal, source code display (aka “coding style
convention”).»
Did you disagree with this? Further, your statement is basically
equivalent with mine, and, if i may argue, mine is more general and
clear, stated in a way understandable to any programer, and applicable
to any langs, as opposed to the lisp's in-world view with its fucking
readers and printers and motherfucking “objects”. Are you saying my
statement is wrong?
I dont' care about politness in newsgroup, but in discussion, you need
to acknowledge points you recognize as valid or worthy to make
progress, ok?
About automatic formatting of code, you wrote:
«Sure it [common lisp] can. Many years before Mathematica it could
already.»
We discussed this in a thread about ~3 months ago. (and at least once
before that too) What is your problem?
In that thread, if i may summarize: some experienced common lisp coder
posted his first version of code to do the reformatting of lisp code,
you, and other Common Lisp morons, sprang to feet and chocked him out
of breath. The final outcome of the thread is that, Common Lisp can
reformat the code, but will lose comments (and few other problems
(such as dealing with macros or something)), which is not usable for
the purpose of automatically formatting source code for editing. If i
recall correctly, i made the last post in that thread summarize the
situation.
I don't want to spend 5 min to google up that thread, because it is no
use to you and other common lisp fuckheads. (for those interested, go
to groups.google.com, view comp.lang.lisp group, then search for “Xah,
Rainer” (or joswig) in that group, then arrange by date. It should be
on the first few pages.)
The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
vigil to smother any seed of progress that may be out of CL tradition,
is currently probably you.
Also, you (and quite a handful of other CL morons) have a nasty habit,
which i also stated in the past half year. Namely, you patently ignore
any pertinent point about other langs that has been brought up, but
always drive the discussion into CL technicalities. This is done to a
degree that you and your cohorts seem even unwilling or unable to show
code in emacs lisp. Do you have any expertise or familiarity in any
other high level lang at all?
Jon Harrop commented once (within the past half year), that a problem
with Common Lisp old hats is that you morons (MY term. Yay!) don't
really know any modern functional langs.
Did you one day got relevation from Zeus, and he told you Common Lisp
is the greatest lang on earth?
This is likely my last post in this thread. Drivel is starting to flow
in. I've had enough writing excursion this week.
PS I'm posting this reply back to all the groups that started this
thread in: comp.lang.lisp, comp.emacs, comp.lang.scheme,
comp.lang.functional . The rational is that, so you Common Lispers (or
any single lang fanatics), dont get into a cartel of patting each
other's back.
Xah
∑ http://xahlee.org/
☄
······@gmail.com a écrit :
> Dear Rainer Joswig,
>
> Rainer wrote:
> > Code is data and data is code:
> >
> > Lisp uses the same external s-expression representation of Lisp
> > data for Lisp code.
> > Lisp programs can read, print and manipulate Lisp code like any
> > other Lisp data.
>
> Yeah, and?
>
> I wrote: «A regular nested syntax, makes it possible to do systematic
> source code transformation in a way that's also trivial to implement.
> There are important consequences. Some of the examples are: lisp's
> macros, structural pattern matching, term rewriting, source code dual
> functioning as markup lang for presentation (e.g. word-processor,
> Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
> general all benefits of XML, on-the-fly source code “formatting” for a
> automatic, uniform, universal, source code display (aka “coding style
> convention”).»
>
> Did you disagree with this? Further, your statement is basically
> equivalent with mine, and, if i may argue, mine is more general and
> clear, stated in a way understandable to any programer, and applicable
> to any langs, as opposed to the lisp's in-world view with its fucking
> readers and printers and motherfucking “objects”. Are you saying my
> statement is wrong?
>
> I dont' care about politness in newsgroup, but in discussion, you need
> to acknowledge points you recognize as valid or worthy to make
> progress, ok?
>
> About automatic formatting of code, you wrote:
> «Sure it [common lisp] can. Many years before Mathematica it could
> already.»
>
> We discussed this in a thread about ~3 months ago. (and at least once
> before that too) What is your problem?
>
> In that thread, if i may summarize: some experienced common lisp coder
> posted his first version of code to do the reformatting of lisp code,
> you, and other Common Lisp morons, sprang to feet and chocked him out
> of breath. The final outcome of the thread is that, Common Lisp can
> reformat the code, but will lose comments (and few other problems
> (such as dealing with macros or something)), which is not usable for
> the purpose of automatically formatting source code for editing. If i
> recall correctly, i made the last post in that thread summarize the
> situation.
>
> I don't want to spend 5 min to google up that thread, because it is no
> use to you and other common lisp fuckheads. (for those interested, go
> to groups.google.com, view comp.lang.lisp group, then search for “Xah,
> Rainer” (or joswig) in that group, then arrange by date. It should be
> on the first few pages.)
>
> The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> vigil to smother any seed of progress that may be out of CL tradition,
> is currently probably you.
>
> Also, you (and quite a handful of other CL morons) have a nasty habit,
> which i also stated in the past half year. Namely, you patently ignore
> any pertinent point about other langs that has been brought up, but
> always drive the discussion into CL technicalities. This is done to a
> degree that you and your cohorts seem even unwilling or unable to show
> code in emacs lisp. Do you have any expertise or familiarity in any
> other high level lang at all?
>
> Jon Harrop commented once (within the past half year), that a problem
> with Common Lisp old hats is that you morons (MY term. Yay!) don't
> really know any modern functional langs.
>
> Did you one day got relevation from Zeus, and he told you Common Lisp
> is the greatest lang on earth?
>
> This is likely my last post in this thread. Drivel is starting to flow
> in. I've had enough writing excursion this week.
>
> PS I'm posting this reply back to all the groups that started this
> thread in: comp.lang.lisp, comp.emacs, comp.lang.scheme,
> comp.lang.functional . The rational is that, so you Common Lispers (or
> any single lang fanatics), dont get into a cartel of patting each
> other's back.
>
> Xah
> ∑ http://xahlee.org/
>
> ☄
We found the Harrop Ningen Copy.
Just a question, what is the interest of this topic ?
Best Regards,
Christophe
On 16 Jul., 07:33, ·······@gmail.com" <······@gmail.com> wrote:
> Dear Rainer Joswig,
Dear Xah!
>
> Rainer wrote:
> > Code is data and data is code:
>
> > Lisp uses the same external s-expression representation of Lisp
> > data for Lisp code.
> > Lisp programs can read, print and manipulate Lisp code like any
> > other Lisp data.
>
> Yeah, and?
>
> I wrote: «A regular nested syntax, makes it possible to do systematic
>
> source code transformation in a way that's also trivial to implement.
> There are important consequences. Some of the examples are: lisp's
> macros, structural pattern matching, term rewriting, source code dual
> functioning as markup lang for presentation (e.g. word-processor,
> Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
> general all benefits of XML, on-the-fly source code “formatting” for a
> automatic, uniform, universal, source code display (aka “coding style
> convention”).»
>
> Did you disagree with this? Further, your statement is basically
> equivalent with mine, and, if i may argue, mine is more general and
> clear, stated in a way understandable to any programer, and applicable
> to any langs, as opposed to the lisp's in-world view with its fucking
> readers and printers and motherfucking “objects”. Are you saying my
> statement is wrong?
It's missing the core of the issue. code as data is not about syntax.
It's a question
a simple representation of code and a function from external source to
code as data (-> READ)
and code as data to external source (-> PRINT). There are other syntax
variants (say, like
XML) that can be used for that. s-expressions are relatively primitive
and easy to implement/use. That's one of the features of Lisp, that
this mechanism is relatively simple (compare that to the spec of XML
which includes additional things like Schemas, but no computation).
The transformations in Lisp are not done on textual source. They are
done
on source as data. At that point s-expression syntax is gone (because
it is READ already) and we are talking about syntax over structural
data:
special forms, macros, functions, ...
Lisp dialects usually (the Scheme standard is an exception) see
parsing
of s-expressions as a dynamic feature of the reader. This is both good
and
bad. Good: you get the flexibility to manipulate the reader to do
a lot of interesting things. Bad: there is no fixed syntax.
Just like in Emacs where keystrokes call Lisp functions, reading
characters
will call Lisp functions that decided what to do. The function
for the character ( reads the rest of a list, for-example.
There is no fixed syntax and a fixed programmed scanner/parser for
that syntax in Lisp
(exception: as I mentioned Scheme has a fixed syntax, though Scheme
implementations
will often provide a typical 'read' mechanism as an extension).
That's just the way it is and it offers interesting possibilities,
but also makes it impossible to parse for example arbitrary Common
Lisp
code without a full Common Lisp reader.
> I dont' care about politness in newsgroup, but in discussion, you need
> to acknowledge points you recognize as valid or worthy to make
> progress, ok?
Ok, my point was that you were missing the core of the issue when
insisting on syntax. It's just easy in Lisp, because it is so
'primitive'.
> In that thread, if i may summarize: some experienced common lisp coder
> posted his first version of code to do the reformatting of lisp code,
> you, and other Common Lisp morons, sprang to feet and chocked him out
> of breath. The final outcome of the thread is that, Common Lisp can
> reformat the code, but will lose comments (and few other problems
> (such as dealing with macros or something)), which is not usable for
> the purpose of automatically formatting source code for editing. If i
> recall correctly, i made the last post in that thread summarize the
> situation.
I remember that thread, right.
That's not just a problem of Common Lisp, that's a problem of Lisp in
general.
It's true for a certain class of comments. Mainly comments
for ; and #| ... |#. You can program the reader to get those
comments read, but I haven't seen this done for a long time.
You need to use comments that are part of the s-expressions.
Common Lisp allows documentation strings in certain places.
CL-USER 15 > (defun foo (a) "this is a documentation string" a)
FOO
CL-USER 16 > (documentation 'foo 'function)
"this is a documentation string"
The other thing is to define some comment form that is part of the
source, but
does nothing.
(defun foo (a)
(sin a) (comment 1 "computes the sin of a")
)
(defun comment (level text) (declare (ignore level text)))
What you need to do with the code-as-data approach, is to make
comments to be data and part of the code, too. Check the Interlisp
pointer I gave you, it deals with comments in code.
That's one of the reasons structure editors for Lisp code are
not more popular - most programmers insist on putting
their comments where they want. Take away that facility
and reading, formatting of code gets easier.
I'm not saying that this shouldn't be tried and that it is
not interesting to do that. All I say is that it has been
tried and has some drawbacks. In the XML world structure
editing is common (see XMLspy). In the Lisp world the
discussion on structure vs. text editing was seeing
a heated discussion. Richard Stallman argued against it.
Try to get a copy of the old book 'Interactive Programming
Environments'
(ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
you find lots of discussions about these issues. You will find a
letter
of Stallman on page 75 where he argues against structure editing.
Stallman (page 76):
"Here are the advantages of editing text rather than list structure.
1. The user can specify any style of indentation and the system will
never
override it. The editor supplies standard indentation as a
default.
2. Comments are easily stored and formatted as the user likes them.
3. The user can create unbalanced parenthese while editing a
function.
This causes no trouble as as the function is not redefined from
the
text at such times. The user can also move, delele, copy blocks
of syntactically unbalanced text. In a list-structure
editor,these operations
are impossible or require peculiar and unintuitive commands.
4. The editor can provide commands to move over balanced objects ...
5. A text editor can support extended syntax. ...
6. A text editor can be used for languages other than Lisp with no
change. ...
..."
So, Stallman was no fan of structure editing and probably also
not of automatic code formatting (indentation is fine, as long as it
can
be overridden.). Automatic code formatting is part of most
structure editors.
Again, I'm not saying that it (automatic code formatting) should not
be done.
As I mentioned earlier the Symbolics Lisp machine has commands for
that.
Just try to implement it for Emacs, I'll bet it would find some users.
See also:
http://portal.acm.org/citation.cfm?doid=356744.356754
Surveyor's Forum: Structured Editing with a Lisp - Richard Stallman
(unfortunately I don't have a better reference for that).
> The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> vigil to smother any seed of progress that may be out of CL tradition,
> is currently probably you.
Too much honor.
> Also, you (and quite a handful of other CL morons) have a nasty habit,
> which i also stated in the past half year. Namely, you patently ignore
> any pertinent point about other langs that has been brought up, but
> always drive the discussion into CL technicalities. This is done to a
> degree that you and your cohorts seem even unwilling or unable to show
> code in emacs lisp.
You were talking about Lisp and you were posting to comp.lang.lisp .
Emacs Lisp
is mainly just a subset of Common Lisp (no closures, no CLOS, ...)
anyway.
I don't know why you are so excited about Emacs Lisp. It's a very
small domain specific Lisp variant that was designed to implement
editor
extensions. That's all. For that it does relatively well.
Everybody who understands Common Lisp can learn Emacs Lisp in a day
and
then struggle with the large Emacs library. ;-) The concepts
of Emacs Lisp are all very old and most predate Common Lisp, Scheme
and
other Lisp dialects. Many of the things that the basic Emacs does have
been implemented in Editors written in Scheme or Common Lisp also.
<Drivel deleted>
On Jul 16, 7:43 am, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On 16 Jul., 07:33, ·······@gmail.com" <······@gmail.com> wrote:
>
> Try to get a copy of the old book 'Interactive Programming
> Environments'
> (ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
> you find lots of discussions about these issues. You will find a
> letter
> of Stallman on page 75 where he argues against structure editing.
>
OK, I'll make a note to add this one to my bookshelf!
> > The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> > vigil to smother any seed of progress that may be out of CL tradition,
> > is currently probably you.
>
> Too much honor.
I must say Rainer that you are, indeed, gracious to reply in such
informative detail to someone who has repeatedly dubbed you a "moron";
this time with no less honour than the "Number One Common Lisp
Moron" .
Still limited in English, Xah misinterprets Stallman's use of "hacker"
and "freedom" as abuse. Perhaps he believes the word "moron" is
complimentary?
> > Also, you (and quite a handful of other CL morons) have a nasty habit,
> > which i also stated in the past half year. Namely, you patently ignore
> > any pertinent point about other langs that has been brought up, but
> > always drive the discussion into CL technicalities. This is done to a
> > degree that you and your cohorts seem even unwilling or unable to show
> > code in emacs lisp.
>
> I don't know why you are so excited about Emacs Lisp.
I think the problem is that Xah craves recognition for his technical
abilities. He, like many of us, is still struggling to master Common
Lisp. Xah tries to compensate by parlaying his knowledge of Emacs
Lisp. But to expect members of this group to reply in kind with Elisp
code, would be asking us to pander.
As Xah himself said:
Regarding your patronizing concern and officious
advice of learning Common Lisp, you might want
to be acquainted with the fact i have no interest
in learning Common Lisp whatsoever.
http://groups.google.com/group/comp.lang.lisp/msg/6809921006d8ca28?hl=en
So I think the latter is Xah's own admission, himself, that he might
be more at home in a group that discusses Emacs Lisp. As you noted,
comp.lang.lisp is for discussions about Common Lisp - i.e. "CL
technicalities".
--agt
In article
<····································@s50g2000hsb.googlegroups.com>,
viper-2 <········@mail.infochan.com> wrote:
> On Jul 16, 7:43 am, ·······@corporate-world.lisp.de" <······@corporate-
> world.lisp.de> wrote:
> > On 16 Jul., 07:33, ·······@gmail.com" <······@gmail.com> wrote:
> >
>
> > Try to get a copy of the old book 'Interactive Programming
> > Environments'
> > (ISBN 0-07-003885-6) by Barstow, Shrobe and Sandewall - 1984. There
> > you find lots of discussions about these issues. You will find a
> > letter
> > of Stallman on page 75 where he argues against structure editing.
> >
>
> OK, I'll make a note to add this one to my bookshelf!
I think it's a real classic.
> > > The number one Common Lisp moron slaving in comp.lang.lisp, keeping a
> > > vigil to smother any seed of progress that may be out of CL tradition,
> > > is currently probably you.
> >
> > Too much honor.
>
> I must say Rainer that you are, indeed, gracious to reply in such
> informative detail to someone who has repeatedly dubbed you a "moron";
> this time with no less honour than the "Number One Common Lisp
> Moron" .
He is a moron, too. ;-) He posts to the wrong newsgroups most
of the time, insults a lot of people, writes stuff that
insults whole group of people, etc. But I'll give him
a bonus sometimes, since he tries to learn some of that stuff, writes
things down and thinks whether it is useful or not. He then
posts it again to the wrong newgroups. Okay. But it is quite
useful to think for example about usability and even though
Emacs is quite some achievement, stuff like the keyboard mappings
are a real pain. So, thinking about it and how to improve that
is very useful, IMHO. With other stuff he is on the wrong track.
But it might interest him to know that some people disagree and why.
When things get too ugly I stop responding...
> > I don't know why you are so excited about Emacs Lisp.
>
> I think the problem is that Xah craves recognition for his technical
> abilities. He, like many of us, is still struggling to master Common
> Lisp.
He is struggling to master Emacs Lisp, I'd say. Though I'm surprised
a bit - Emacs Lisp is not that difficult. Sometimes it is
a hurdle and after getting over some hurdle it suddenly gets much
easier. Typical hurdles for Lisp are understanding closures,
for Scheme it would be continuations, for Haskell it would be monads.
But Emacs Lisp doesn't have that stuff.
If he posts some Lisp code and wants feedback (even better if it were
in the correct newsgroup), fine by me. I think newsgroups
like comp.lang.lisp are a great way to get feedback from
very different people. I'm learning from that, too. One
just has to learn to live with all the different opinions.
One problem with posting Emacs Lisp code or questions is
that one gets Common Lisp answers back - quite often. It's
the preferred language on comp.lang.lisp - IMHO.
But often the answers can be adapted to some other dialects.
One thing that interests me is to understand what helps people
over the initial hurdles to start doing useful things with Lisp.
I had last month some communication with a student, who
was learning some Lisp and he and his tutor asked me to give him some
tasks. I was positively surprised to see that the student was
able to do some useful coding (in Common Lisp using the
LispWorks Personal Edition) after a relatively short
period of time. There was one point where he was struggling
with a CAPI callback. I explained the use of closures for that
and he got it and understood why that is a useful thing.
That was a good sign for me.
Btw., the frog seller has no interest in Lisp at all and just
spams here - so there is no point to respond to that guy.
That other troll that we see here just posts simple questions
and has no idea what to do with the answers.
> Xah tries to compensate by parlaying his knowledge of Emacs
> Lisp. But to expect members of this group to reply in kind with Elisp
> code, would be asking us to pander.
>
> As Xah himself said:
>
> Regarding your patronizing concern and officious
> advice of learning Common Lisp, you might want
> to be acquainted with the fact i have no interest
> in learning Common Lisp whatsoever.
>
> http://groups.google.com/group/comp.lang.lisp/msg/6809921006d8ca28?hl=en
>
> So I think the latter is Xah's own admission, himself, that he might
> be more at home in a group that discusses Emacs Lisp. As you noted,
> comp.lang.lisp is for discussions about Common Lisp - i.e. "CL
> technicalities".
I don't think comp.lang.lisp is for exclusive discussions of
Common Lisp. It is just that many here use Common Lisp or are interested
in it. The newsgroup is equally there for discussing other Lisp
dialects. Though the usual rule would be to use the most
specific newsgroup. Common Lisp has no other specific newsgroup,
so it's discussed here. Scheme has comp.lang.scheme, Emacs Lisp
has some Emacs related newsgroup. Most Emacs-Lisp-specific postings
belong there. Many other Lisps and implementations are discussed
on specific mailing lists. See here:
http://dir.gmane.org/index.php?prefix=gmane.lisp
>
> --agt
--
http://lispm.dyndns.org/
On Jul 16, 10:59 am, Rainer Joswig <······@lisp.de> wrote:
>
> I don't think comp.lang.lisp is for exclusive discussions of
> Common Lisp. It is just that many here use Common Lisp or are interested
> in it. The newsgroup is equally there for discussing other Lisp
> dialects.
Your tolerance is commendable, for how else would people like Xah
learn? It seems you would make an excellent professor, unlike me. I
have neither the patience nor the interest.
I do recognize that cll is not exclusively for discussions in Common
Lisp. In fact, comparisons with other dialects, here, might invite
plurality and debate leading to more profound understanding of CL
itself.
I think the point I was trying to make is that Xah seems to consider
responses in terms of "CL technicalities" (from a newsgroup primarily
concerned with CL) to be "moronic".
I'm coding in law temporarily, not Lisp (unfortunately); got to
compile - and run! ;-)
--agt
Dear Rainer,
You wrote: «It's missing the core of the issue. code as data is not
about syntax. ... Lisp dialects usually (the Scheme standard is an
exception) see parsing of s-expressions as a dynamic feature of the
reader. This is both good and bad. ... »
When a language, such as Lisp or Mathematica, that deals with symbols,
the 2 formulation about “code⇔data” is equivalent, ok?
Sure you can bury your head into Common Lisp technicalities, by
starting to bitch about how Scheme Lisp is breaking the “code⇔data”
property.
Also, you may or may not be aware, that people are making XML into a
general purpose language. i.e. a language with XML as syntax. (e.g.
O:XML ( http://www.o-xml.org/ ), and to a lesser degree MathML and XML
transformation language ( http://en.wikipedia.org/wiki/XML_transformation_language
))
About a tool that autoformat lisp code, you wrote: «That's not just a
problem of Common Lisp, that's a problem of Lisp in general. ...
There is no fixed syntax and a fixed programmed scanner/parser for
that syntax in Lisp (exception: as I mentioned Scheme has a fixed
syntax, though Scheme implementations ... It's true for a certain
class of comments. Mainly comments for ; and #| ... |#. You can
program the reader to get those comments read, but I haven't seen this
done for a long time. You need to use comments that are part of the s-
expressions. Common Lisp allows documentation strings in certain
places. ... »
So, you are implicitly admitting, one of my ciritism of lisp
( http://xahlee.org/UnixResource_dir/writ/lisp_problems.html ), that
the irregularities of lisp syntax (e.g. “; ”) is a problem?
Further, practically speaking, today there's no tool to autoformat
lisp code as i described in my criticism (see the link above for
detail ). This is a practical need. You kept meddeling with this
negative fact, yet kept talking about how Common Lisp can and have in
the past done great using CL's read/print notions that have just
“minor” issues, adding belittering remarks about how i could
contribute by creating such a tool. What is your problem? Can you not
see, your CL fanaticism is doing harm to lisp in general and CL as
well?
(The thread about creating a lisp re-indenting tool is here:
Newsgroups: comp.lang.lisp
From: Jeremy Smith
Date: Sat, 26 Jan 2008 19:16:47 GMT
Subject: Lisp indenting tool
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e95564e3550bbcfd?tvc=2
)
People, lisp's lack of automatic formatting tool, is a problem. I
described in the above article several paragraphs of details about it.
You may or may not agree the degree of the problem or degree of
benefit, or my views about how this problem occurred. However, having
a automatic formatting tool for lisp would still a great benefit.
Please spread this fact whenever you can. Common Lisp fuckheads, you
need to stop befuddle criticisms.
it looks like the monikor moron for some Common Lispers here, ceases
to appear a hyperbole or playful. (this becomes apparent in another
thread last month or so about Closure. (
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/634ae034c6a71c66?tvc=2
))
----------------
Postscript:
A post in this thread related to netiquette, is now perm archived
here:
“(Knowledge + Love) / Disrespectfulness”
http://xahlee.org/Netiquette_dir/disrespectfulness.html
Also, this post is posted to: comp.lang.lisp, comp.emacs,
comp.lang.scheme, comp.lang.functional . The post that this post
replies to, is by Rainer only in comp.lang.lisp, can be view here:
http://groups.google.com/group/comp.lang.lisp/msg/65797f4df62df54f?
Xah
∑ http://xahlee.org/
☄
On 17 Jul., 00:46, ·······@gmail.com" <······@gmail.com> wrote:
> Dear Rainer,
>
> You wrote: <<It's missing the core of the issue. code as data is not
>
> about syntax. ... Lisp dialects usually (the Scheme standard is an
> exception) see parsing of s-expressions as a dynamic feature of the
> reader. This is both good and bad. ... >>
>
> When a language, such as Lisp or Mathematica, that deals with symbols,
> the 2 formulation about "code$B"N(Bdata" is equivalent, ok?
Don't know. I would agree that Mathematica (and a bunch of other
languages)
also support the 'code is data' idea.
<drivel>
> Also, you may or may not be aware, that people are making XML into a
> general purpose language. i.e. a language with XML as syntax. (e.g.
> O:XML (http://www.o-xml.org/), and to a lesser degree MathML and XML
> transformation language (http://en.wikipedia.org/wiki/XML_transformation_language
> ))
Sure, I heard of XML. There are plenty attempts in XML to do that.
> About a tool that autoformat lisp code, you wrote: <<That's not just a
> problem of Common Lisp, that's a problem of Lisp in general. ...
> There is no fixed syntax and a fixed programmed scanner/parser for
> that syntax in Lisp (exception: as I mentioned Scheme has a fixed
> syntax, though Scheme implementations ... It's true for a certain
> class of comments. Mainly comments for ; and #| ... |#. You can
> program the reader to get those comments read, but I haven't seen this
> done for a long time. You need to use comments that are part of the s-
> expressions. Common Lisp allows documentation strings in certain
> places. ... >>
>
> So, you are implicitly admitting, one of my ciritism of lisp
> (http://xahlee.org/UnixResource_dir/writ/lisp_problems.html), that
> the irregularities of lisp syntax (e.g. "; ") is a problem?
What 'problem'? It sounds dramatic as only Lisp has such a 'problem'.
The 'problem' just is that the reader by default
is throwing away comments introduced by semicolon and #| |# and that
the
pretty-printer also does not know about those comments.
As Lisp systems are currently used this and automatic formatting of
textual
code is mostly not needed.
It's a design choice. Other features (like a programmable reader)
were more important than 'comments as data'. Most Lisp systems
ignore comments and don't read it. As I mentioned Common Lisp
has several places where comments and documentation can be
used in the source as data. Those will not be lost after
reading or pretty-printing code.
Still I would agree that it is interesting to have one and to get
more practical experience if it is useful or not.
As I said, either solve the problem by
a) ignore the comment problem (why not?) and just write a code
formatter.
Could be a start.
b) implement the fully general solution by modifying the reader
to also return comments and their position
c) implement a different lexical analysis tool within Emacs which
parses a version of Lisp syntax that is fixed and deals with
comments.
Probably not that easy, but possible.
Anyway, a real good code formatting tool is not that easy to write.
> Further, practically speaking, today there's no tool to autoformat
> lisp code as i described in my criticism (see the link above for
> detail ). This is a practical need.
Not for me. I'm usually fine with semi-automatic indenting or with a
real structure editor.
Anyway, I have a Lisp system which already has code formatting (minus
the
problem with comments). I wasn't using the formatter much.
It looks like this - a fucked up formatting of some function:
(defun test-function
(arg1 arg2
arg3
argument-with-longer-name)
"this function is just a test"
(setf argument-with-longer-name (* arg1 ; use this
first
arg2 (sin arg3)))
(* argument-with-longer-name argument-with-longer-name argument-with-
longer-name argument-with-lo\
nger-name))
Now the command 'M-x format code' and 'M-x lowercase in region'
produces the following formatting:
(defun test-function (arg1 arg2 arg3 argument-with-longer-name)
"this function is just a test"
(setf argument-with-longer-name (* arg1 arg2 (sin arg3)))
(* argument-with-longer-name
argument-with-longer-name
argument-with-longer-name
argument-with-longer-name))
You can see that the 'comment as data' documentation string still is
there,
but the semicolon comment has been lost.
<your drivel deleted>
Hi everybody,
I've been spending some time thinking about this code formatting
issue. Although the task of writing a good formatter is quite
demanding by itself, I think the real problem is whether or not we are
willing to drop macros with "special formatting" in order to get a
canonical format. E.g., you might want to have different indentation
levels for the parameter list and the body of a function, as
(defun myfun
(long-parameter-list-argument-1 ..)
("heureka"))
looks quite weird. Or maybe you like
(if x
"true"
"false")
which at least one editor I tried gives.
But if this special indentation rules are important, there should be
some way to give a hint when defining a macro about how to indent it
correctly, as a user-macro should have the same rights as defmacro =)
At least this is what I would do if I had to reinvent Lisp from
scratch - which in fact I might be doing ;-)
Regards,
Benjamin
From: Joost Diepenmaat
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <87prpcrnn0.fsf@zeekat.nl>
Benjamin Teuber <······@web.de> writes:
> Hi everybody,
[ ... ]
> But if this special indentation rules are important, there should be
> some way to give a hint when defining a macro about how to indent it
> correctly, as a user-macro should have the same rights as defmacro =)
> At least this is what I would do if I had to reinvent Lisp from
> scratch - which in fact I might be doing ;-)
Isn't that why &body is for?
Also: why did you not start a new thread for this?
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
> Benjamin Teuber <······@web.de> writes:
>
>> Hi everybody,
That's just the kind of attitude we do not need around here.
>> At least this is what I would do if I had to reinvent Lisp from
>> scratch - which in fact I might be doing ;-)
Well that certainly sets you off from all the other people who discover
Lisp on day zero and on day one decide to write their own. So they can
be programming in C all day.
The one thing you know about someone who reacts to being handed a
Formula I race car by heading to the machine shop to make a wheel is
that they have no interest in driving.
WTF am I still doing in this walking dead NG???
:)
kt
On 18 Jul., 08:13, Kenny <·········@gmail.com> wrote:
> > Benjamin Teuber <······@web.de> writes:
>
> >> Hi everybody,
>
> That's just the kind of attitude we do not need around here.
Like ... greeting?
>
> >> At least this is what I would do if I had to reinvent Lisp from
> >> scratch - which in fact I might be doing ;-)
>
> Well that certainly sets you off from all the other people who discover
> Lisp on day zero and on day one decide to write their own. So they can
> be programming in C all day.
I feel honored at least not be put put into the very worst category =)
> The one thing you know about someone who reacts to being handed a
> Formula I race car by heading to the machine shop to make a wheel is
> that they have no interest in driving.
Well, "reinvent from scratch" was an exeggeration - my plan would
rather be building a tuning kit people can use to make their say
japanese car behave more like a race car. But nevermind, I should not
start the spamming before having something in my hands, so I'd better
shut up now..
On 18 Jul., 03:23, Joost Diepenmaat <·····@zeekat.nl> wrote:
> Isn't that why &body is for?
Right, but I'm not sure whether this is enough - maybe there happens
to be a macro with two bodies or some other reason for different
indentation. Question to the experienced guys: Did you ever stumble
across a macro where &body alone wasn't enough to specify a good
indentation?
> Also: why did you not start a new thread for this?
Well, because it's a discussion of the one point I more or less liked
about Xah's post - but if you prefer, we can move to another thread.
Benjamin Teuber <······@web.de> writes:
> On 18 Jul., 03:23, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
>> Isn't that why &body is for?
>
> Right, but I'm not sure whether this is enough - maybe there happens
> to be a macro with two bodies or some other reason for different
> indentation. Question to the experienced guys: Did you ever stumble
> across a macro where &body alone wasn't enough to specify a good
> indentation?
Of course, it happens.
That's where the lisp-indent-function property of emacs symbols comes
into play. See C-h f lisp-indent-function RET
(defun mymacro (a b c d e f &body g) ...)
#+emacs (put 'mymacro 'lisp-indent-function '3)
(mymacro a b
c
d e
f
g)
>> Also: why did you not start a new thread for this?
>
> Well, because it's a discussion of the one point I more or less liked
> about Xah's post - but if you prefer, we can move to another thread.
It would be better yes. A lot of people killfile Xah.
--
__Pascal Bourguignon__
Benjamin Teuber <······@web.de> writes:
> On 18 Jul., 03:23, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
> > Isn't that why &body is for?
>
> Right, but I'm not sure whether this is enough - maybe there happens
> to be a macro with two bodies or some other reason for different
> indentation. Question to the experienced guys: Did you ever stumble
> across a macro where &body alone wasn't enough to specify a good
> indentation?
It's extremely rare and usually not an issue, not because it can't be
wanted but because Lisp syntax doesn't really allow for it.
The problem comes that if you wanted multiple bodies, there would be
no obvious cue about how to divide them. So usually what you do is
like what COND does where you do:
(defmacro my-cond (&body clauses)
...
(dolist (clause clauses)
... (destructuring-bind (test &body forms) clause ...) ...)
...)
Or else you just take one as a form and make the user use progn, as in:
(defmacro my-multiple-value-bind (bindings value-form &body forms) ...)
where in practice one often occasionally wishes for
(defmacro my-multiple-value-bind (bindings &body value-forms
&more-body other-forms)
...)
The fact is that &body is not the source of any problem, it just reminds you
that there are inherent limitations with positionally supplied semantics.
That problem is a problem of the universe, not even of Lisp. e.g., it comes
up with regular expressions, for example, when you try to juxtapose to *
wildcards and either combinatoric answers come up or the string doesn't
compile, depending on the tool. It's also the reason that if you're wanting
something scanf-like, as in (setf (format nil "~D" x) "3"), you can't
allow cases like (setf (format nil "~D~D" x y) "357") to set multiple values
because you can't know what the partitioning is. &body is just another case
of this broad class of issues.
Kent M Pitman <······@nhplace.com> writes:
> Benjamin Teuber <······@web.de> writes:
>
> > Right, but I'm not sure whether this is enough - maybe there happens
> > to be a macro with two bodies or some other reason for different
> > indentation. Question to the experienced guys: Did you ever stumble
> > across a macro where &body alone wasn't enough to specify a good
> > indentation?
>
> It's extremely rare and usually not an issue, not because it can't be
> wanted but because Lisp syntax doesn't really allow for it.
I sometimes wish for an equivalent to &BODY for functions:
(defun call-with-foo (context &thunk fn)
...)
Such that
(call-with-foo (current-context)
#'(lambda (foo) ...))
instead of
(call-with-foo (current-context)
#'(lambda (foo) ...))
-T.
"Tobias C. Rittweiler" <···@freebits.de> writes:
> I sometimes wish for an equivalent to &BODY for functions:
>
> (defun call-with-foo (context &thunk fn)
> ...)
> Such that
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))
>
> instead of
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))
Heh. This is nature's way of telling you that you wanted to write a
WITH-FOO macro that has &BODY. :)
In fact, although I don't think you'd find any historical record
showing this to be true in fact, I think the reason you see &body in
macros but not functions is that this particular situation is in fact
the most common and is amenable to macros. The only other case where
I have ever wanted it was in a long list of keywords, as with certain
calls to OPEN or many of the functions in CLIM.
There's also a practical matter that there are usually other ways
involving variables that long function calls can be phrased differently
so that some of those issues can be rearranged.
And, finally, I think the real flaw here is not in CL but in the community
not having a way of declaring indentation portably. This is an easily
layerable thing, and the real thing is not that CL was trying to add the
only way to do it in DEFMACRO, but rather CL was saying "we can't tell you
how this is done on a per-implementation basis, but it's possible to sneak
in for macros so we'll hide it on a limited basis." With functions the
issues are more complicated, not just because of APPLY, but also because
functions can come and go dynamically at runtime.
In that regard, this is a little like the LispM's "e, which was like
a fexpr and is happily gone. The idea is appealing at some level.
((LAMBDA ("E X) X) A) => A
but the problem is that this is really a property of the name of the function,
not of the value of the function. So when the value is picked up and moved
to other names or used with APPLY, the question is whether those dynamic uses
must recognize the usage. (APPLY #'(LAMBDA ("E X) X) '(A)) => A
which is a little bizarre since so (APPLY #'(LAMBDA (X) X) '(A)) => A
and it shows the "E is really riding around in the wrong place.
I think the same would be true of &body. What would (apply #'call-with-foo ..)
do with the information? I'm not saying these things don't have answers,
only that the answers are not as neat and pretty as the answers were with
the macro case.
And, finally, I have not looked at this stuff recently but I'm fairly sure
I was actually the one who first put data-driven body-style indentation
into TECO-based Emacs years ago. Before that, I think the indentation style
was generally the old-style MACLISP indent-under-arg-1 thing, possibly with
just a few special cases. I remember it bugged me a lot and I did some major
overhaul on it anyway. And while it made it possible to do this on functions
as well as definitions, the critical point was that you were supposed to
globally declare your intent, which you usually did in a Local Modes at the
end of a file full of code (for Emacs). e.g., one might write:
; -*- Mode: LISP; -*-
(defun blah ()
(foo
x))
^L
; Local Modes:
; Lisp FOO Indent: -1
; End:
I tried this just now on an ITS emulator and I'm amazed I still
mremembered how to write this syntax first try after
that many years... It's weird what the brain keeps around. The documentation
on the mode stuff is in the file EMACS1;INDENT > for anyone with such an
emulator wanting to look. I was looking at version 238, which offered this
doc:
!^R Indent for LISP:! !^R Indent this line for a Lisp-like language.
With arg, moves over and indents that many lines.
The variable Lisp Indent Language (default "Lisp") controls the dialect.
Handlers may be defined per-dialect to make this function win for other
Lisp-like languages. With a pre-comma arg, return indentation level instead
of changing anything and don't treat ;;; comments specially.!
!* Indentation is first computed by a long-standing indentation algorithm.
Relevant variables:
Lisp Indent Offset (default 0), if nonzero indent this many columns
past the most recent hanging "(" rather than worrying about indentation
relative to arguments.
Lisp Indentation Hook (default m.m& Standard Lisp Indentation Hook$) is
macroed to get extra refinement. The default has hairy options as
described below. It can return two values.
The second one, if nonzero, is the hpos to indent to.
If it is zero, the indentation of point (as point is left
by the hook) is used.
The first value, if nonzero, means that succeeding sexps
at the same level of nesting will not necessarily be
indented the same way. The value should be the char address
of the ( which starts the containing form.
According to the default behavior:
If a variable name Lisp ... Indent (where the ... is replaced by
the name of the operator at the head of the list -- eg, CAR looks
for Lisp CAR Indent exists, it will be interpreted as follows:
if a string, then macro it.
if a number, then
if -4 or less, undefined.
if -3, don't indent specially unless Lisp Indent DEFanything says to
if -2, don't indent specially.
if -1, indent as a defform.
if 0 or pos, indent as a specform.
If Lisp Indent DEFanything (default 1) if nonzero says that any operator
name beginning with DEF should be treated as a defform.
The amount of indentation used by the variables is special indentation
values -1 and up is given by Lisp Special Indent Offset (default 2)
and is an offset from the open paren of the enclosing form!
e.g., for a PROG (replacing control characters with printables), there was
actually a macro handler living in the q-register named q$Lisp PROG Indent$,
because it was too complicated to do this by a simple integer variable value:
!& Alternate Lisp PROG Hook:! !& Hook indents PROGs with tags left justified!
Z-qZj 0l @f^B_^]^Q $l !* Jump to head of line being indented !
0,1a*5+1:g..D-^^A"e ^X+1j ' !* Indent tags one way !
"# ^X+5j @f^B_^]^Q $l !* Else indent to normal place !
0,1af^B^M;$:"l ^X+1j'' !* being careful of bvl not on line 1 !
^X,0^\
Ah, TECO. Why ever did we leave you behind? *sniffle*
On the LispM, there was a more general mechanism that had a list of,
if I recall correctly, expression position and indent points, so that you
could tell multiple-value-bind that its value expression was to indent 4
and then its body only 2, so it permitted multiple indent points:
(multiple-value-bind (foo bar)
(returns-two-values)
(user-of foo bar))
But to get this right you were out of scope of anything &body could have
done [unless you had special rules for indentation of pre-&body expressions].
Probably modern packages have ways to customize this that are similar.
Heh, looking at my own emacs init, I see things like:
(put 'block 'lisp-indent-hook 1)
which look like transliterations of the teco
So, back to your original point, I agree with you there's a gap there,
and the gap may even have a subconscious political bent to it. But in
practice I think the main issue is that once you're outside of the
simple issue &body in defmacro solves, the number of subtleties is
sparse and distributed in multiple directions. Trying to patch it by
just extending the feeble &body hack to functions really misses the
big picture that there are a lot of issues in indentation, just as
with any typography, and getting them right involves a full-fledged
declarational facility.
Kent M Pitman <······@nhplace.com> writes:
> On the LispM, there was a more general mechanism that had a list of,
> if I recall correctly, expression position and indent points, ...
I'd like to take the opportunity to point to my editor-hints project at
http://common-lisp.net/project/editor-hints/, as such an indentation
declaration facility is one of its goals. Among many other things. See
the TODO file referenced on that page. I'll continue working on it
during upcomming breaks.
And thanks for your posting. I especially enjoyed the original TECO
snippet! :-)
-T.
On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" <···@freebits.de> said:
| ...
| I sometimes wish for an equivalent to &BODY for functions:
| (defun call-with-foo (context &thunk fn)
| ...)
| Such that
| (call-with-foo (current-context)
| #'(lambda (foo) ...))
| instead of
| (call-with-foo (current-context)
| #'(lambda (foo) ...))
In my opinion, the reason why there is relatively little demand for
this in Common Lisp (and hence why such a facility isn't (widely)
used) is that in most of the cases of this kind, one would use
macros, rather than higher-order programming. Again, this is just a
thesis; it would be interesting to hear the opposite point made.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> writes:
> On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" said:
>
> | ...
> | I sometimes wish for an equivalent to &BODY for functions:
> |
> | (defun call-with-foo (context &thunk fn)
> | ...)
> | Such that
> |
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
> |
> | instead of
> |
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
>
> In my opinion, the reason why there is relatively little demand for
> this in Common Lisp (and hence why such a facility isn't (widely)
> used) is that in most of the cases of this kind, one would use
> macros, rather than higher-order programming. Again, this is just a
> thesis; it would be interesting to hear the opposite point made.
CALL-WITH-FOO is nice if the continuation is a named function:
(call-with-foo (current-context) #'frob-foo)
vs.
(with-foo foo (current-context)
(frob-foo foo))
Now as names get longer, I'd prefer
(call-with-zurped-foobar (get-zurped-context)
#'frobnicate-a-zurped-foobar)
to
(call-with-zurped-foobar (get-zurped-context)
#'frobnicate-a-zurped-foobar)
Or
(call-with-zurped-foobar (get-zurped-context)
(make-foobar-frobnicator :zurp t))
There are other times where I'd have like an indentation like above,
for instance:
(frob-quux (some-context)
(make-some-data-structure :foo-slot (compute-foo)
:bar-slot (compute-bar)))
As a real-world example take
(defun maybecall (bool fn &rest args)
"Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
(if bool (apply fn args) (values-list args)))
I'd like it be indented like
(maybecall (tasty-p food)
#'grab-and-eat food :smacking nil)
It doesn't come up all that often, of course. HTH,
-T.
"Tobias C. Rittweiler" <···@freebits.de.invalid> writes:
> As a real-world example take
>
> (defun maybecall (bool fn &rest args)
> "Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
> (if bool (apply fn args) (values-list args)))
>
> I'd like it be indented like
>
> (maybecall (tasty-p food)
> #'grab-and-eat food :smacking nil)
Stupid example, as you'd use WHEN here anyway. MAYBECALL can be useful
because it behaves like identity if the condition is not true, making it
practical for normalization of arguments.
-T.
On Sat, 19 Jul 2008 18:04:31 +0200, "Tobias C. Rittweiler" <···@freebits.de.invalid> said:
|| As a real-world example take
||
|| (defun maybecall (bool fn &rest args)
|| "Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
|| (if bool (apply fn args) (values-list args)))
|| ...
| MAYBECALL can be useful
| because it behaves like identity if the condition is not true, making it
| practical for normalization of arguments.
Hmmm... Wouldn't it be more true to the variable-free programming
style mentioned earlier in the thread if we have
(defun condapply (test fn &rest args)
"Apply FN to ARGS if they satisfy TEST, otherwise just return ARGS."
(apply (if (apply test args) fn #'values-list) args))
instead, e.g.
(condapply #'atom #'list (get-designators ...))
for
((lambda (d) (maybecall (atom d) #'list d)) (get-designators ...))
(to return to the subject of the thread, I don't know if I would
want special indenting for calls to CONDAPPLY, though).
---Vassil.
P.S. Imagine a Lisp-1 in which (F . X) means (APPLY F X); would
((IF (TEST . ARGS) FN VALUES-LIST) . ARGS) be considered readable?
--
Peius melius est. ---Ricardus Gabriel.
In article <··············@freebits.de>,
"Tobias C. Rittweiler" <···@freebits.de.invalid> wrote:
> Vassil Nikolov <···············@pobox.com> writes:
>
> > On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" said:
> >
> > | ...
> > | I sometimes wish for an equivalent to &BODY for functions:
> > |
> > | (defun call-with-foo (context &thunk fn)
> > | ...)
> > | Such that
> > |
> > | (call-with-foo (current-context)
> > | #'(lambda (foo) ...))
> > |
> > | instead of
> > |
> > | (call-with-foo (current-context)
> > | #'(lambda (foo) ...))
> >
> > In my opinion, the reason why there is relatively little demand for
> > this in Common Lisp (and hence why such a facility isn't (widely)
> > used) is that in most of the cases of this kind, one would use
> > macros, rather than higher-order programming. Again, this is just a
> > thesis; it would be interesting to hear the opposite point made.
>
...
> As a real-world example take
>
> (defun maybecall (bool fn &rest args)
> "Call FN with ARGS if BOOL is T. Otherwise return ARGS as multiple values."
> (if bool (apply fn args) (values-list args)))
>
> I'd like it be indented like
>
> (maybecall (tasty-p food)
> #'grab-and-eat food :smacking nil)
>
>
> It doesn't come up all that often, of course. HTH,
>
> -T.
Your favorite Lisp editor may have a way to customize indentation.
LispWorks for example:
http://www.lispworks.com/documentation/lw51/EDUG-U/html/eduser-u-132.htm
--
http://lispm.dyndns.org/
Vassil Nikolov wrote:
> On Sat, 19 Jul 2008 13:44:25 +0200, "Tobias C. Rittweiler" <···@freebits.de> said:
>
> | ...
> | I sometimes wish for an equivalent to &BODY for functions:
>
> | (defun call-with-foo (context &thunk fn)
> | ...)
> | Such that
>
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
>
> | instead of
>
> | (call-with-foo (current-context)
> | #'(lambda (foo) ...))
>
> In my opinion, the reason why there is relatively little demand for
> this in Common Lisp (and hence why such a facility isn't (widely)
> used) is that in most of the cases of this kind, one would use
> macros, rather than higher-order programming. Again, this is just a
> thesis; it would be interesting to hear the opposite point made.
I know two cases where the indentation sucks a bit:
(make-instance 'some-class
:slot1 value1
:slot2 value2)
I would prefer:
(make-instance 'some-class
:slot1 value1
:slot2 value2)
Also:
(apply #'make-instance 'some-class
:slot1 value1
:slot2 value2
more-slots)
It would be nice like this:
(apply #'make-instance 'some-class
:slot1 value1
:slot2 value2
more-slots)
...although this case is not as bad as the first one. Nevertheless,
apply and funcall could be a bit more 'forgiving' with regard to
indentation.
There is also an inconsistency between defmethod forms with and without
qualifiers:
(defmethod some-method
((obj some-class) ...)
...)
vs.
(defmethod some-method :before
((obj some-class) ...)
...)
...but maybe that's implementation-specific - I don't see why it
couldn't be handled more consistently.
What I also find annoying quite often is this:
(defun some-function (arg0 &key arg1
arg2
arg3)
...)
vs.
(defun some-function (&key arg1
arg2
arg3)
...)
I have no idea whether that would be easy to solve or not.
Lisp-1 seems to have an advantage here, because the indentation can be
more easily made consistent everywhere, I think. At least, it's my
impression that Scheme code is easier to indent, and my gut tells me it
has something to do with it being a Lisp-1. Maybe not, not sure here...
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 <··@p-cos.net> wrote something approximately like:
> I know two cases where the indentation sucks [...]
> (make-instance 'some-class
> ...)
> (apply #'make-instance 'some-class ...)
> ...)
APPLY will always be a special case. What about
(apply #'make-instance 'some-class '(
:foo 3))
or
(apply #'make-instance 'some-class
'(:foo 3
:bar 4))
There are lots of special cases here. Implementations can choose how
to handle them, but this was my point that the standard doesn't attempt
to do a full job.
> There is also an inconsistency between defmethod forms with and
> without qualifiers:
> (defmethod some-method
> ((obj some-class) ...)
> ...)
> vs.
> (defmethod some-method :before
> ((obj some-class) ...)
> ...)
> ...but maybe that's implementation-specific - I don't see why it
> couldn't be handled more consistently.
Indeed that just seems like an implementation bug. This is not required
by the standard. None of this is, I think. So send some vendor bug
reports.
> What I also find annoying quite often is this:
> (defun some-function (arg0 &key arg1
> arg2
> arg3)
> ...)
> vs.
> (defun some-function (&key arg1
> arg2
> arg3)
> ...)
> I have no idea whether that would be easy to solve or not.
These may be widespread problems but are not problems in the language They're
editor issues.
> Lisp-1 seems to have an advantage here, because the indentation can be
> more easily made consistent everywhere, I think.
I seriously doubt you can make a convincing case of this. It seems unlikely
to me that this would be so, unless you're generalizing Lisp1 to mean the
entire mindset of not allowing things like keywords (which is part and parcel
of the design philosophy that brought on Lisp1), in which case many of these
examples just don't come up.
If you're meaning the baroque macro language that the Lisp1 folks have to have
in order to keep from tripping over namespace issues semantically, we can
optionally have that, too. So you can write a macro definition language of
your own and you'll have the parser data you need to do the indentation you
want. Nothing about LispN holds you back. What holds you back is the absence
of a declaration facility that cooperates with the editor to say where you
want indentation.
> At least, it's my impression that Scheme code is easier to indent,
> and my gut tells me it has something to do with it being a Lisp-1.
> Maybe not, not sure here...
I'm doubting this. The same shapes can potentially occur. The only
difference between Lisp1 and LispN is where the function name is stored,
which can't affect indentation and the slight difference in using APPLY in
a few situations in Lisp2 where it wouldn't be in Lisp1 (the compensating
situation in Lisp1 uses longer or different names than in Lisp1, which is
not a shape changer). So I agree APPLY is a minor issue, but I think is
rarely the crux of any problem you're describing.
And I would rush to emphasize that the origin of the Lisp1/Lisp2
distinction was to solve a problem in conversational structure, almost
etiquette, in the namespace separation debate. Gabriel and I were
co-writing a paper analyzing the differences between Lisp and Scheme,
in which he was effectively advocating Scheme-style and I was
advocating Lisp-style. I felt he was gaining an unfair advantage
debate-wise by saying "like Scheme" or "like Lisp", which caused
people to think about other things than namespaces, and to have warm
fuzzies for things that had no relevance to this debate. So I invented
the notion of a Lisp1 which was otherwise like Common Lisp and of a
Lisp2 that was otherwise like Scheme, and I wanted the terms Lisp1 and
Lisp2 to help people remember that the namespace choice didn't get them
the other features of the language. These artificial dialectal names were
chosen to insulate me from other features of the language.
But in this case you're doing the opposite. You're liking some other
feature of Scheme than just the namespace, I'm pretty sure. I'm not
faulting you for that, but I'm probably prepared to defend CL
syntactically, at least for debate purposes, on whatever feature you
might be liking, since I personally like most of the CL decisions in
this space and personally prefer them. (Obviously, the matter is
subjective and I'm not saying you can't disagree. But I am saying
that the rationales for some of these choices are often ill-understood
by people and/or spun in various religious ways rather than analyzed
as complicated design choices that are made in spaces where there are
no canonically right answers and are merely local optima to be sought.)
So here I'd allege it's debate-wise more fair for you to say
Scheme-like or Lisp-like rather than Lisp1-like and Lisp2-like unless
you can show that the feature, if you renamed all the names to random
names and ignored all the semantics still would somehow depend on where
you stored values and functions. I just don't see it.
I think you're really thinking you like that overly complex
declarative macro thing and/or the absence of keywords and/or the
absence of &optional, for that matter, since the presence of the
consing dot in an arglist as one's only variation in argument notation
makes a lot of syntax easier (at the expense of making it hard to
write complicated function calls). Some people may indeed like that
but I think most will appreciate that &optional and &rest and &key did
not arise for no reason and are part of a design split that is not on
the Lisp1/Lisp2 line, but is part of a more general "people would be
happier if they didn't have many options"/"people would be happier if
they had a lot more options" line. It's like a debate over whether
more or fewer axioms in a logical system makes the system better.
It's just different. And it's hard to debate logically without some
groundrules about how to value things. And people mostly like to hold
their personal values close to themselves and not offer them up as fixed
constants to be over-reasoned-about by logicians.
So I don't know if I got to where I'd meant to say in what I actually
said here, but I'll leave it to stand. My two points were these: I don't
think it's a Lisp1/Lisp2 divide you're pointing to, and I think if you
tried harder to be explicit about what you like, you would see that. I don't
see that any of your cited examples is specific to Lisp1/Lisp2. Those issues
can all come up in both pseudo-dialects.
"Tobias C. Rittweiler" <···@freebits.de> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
>> Benjamin Teuber <······@web.de> writes:
>>
>> > Right, but I'm not sure whether this is enough - maybe there happens
>> > to be a macro with two bodies or some other reason for different
>> > indentation. Question to the experienced guys: Did you ever stumble
>> > across a macro where &body alone wasn't enough to specify a good
>> > indentation?
>>
>> It's extremely rare and usually not an issue, not because it can't be
>> wanted but because Lisp syntax doesn't really allow for it.
>
> I sometimes wish for an equivalent to &BODY for functions:
>
> (defun call-with-foo (context &thunk fn)
> ...)
> Such that
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))
>
> instead of
>
> (call-with-foo (current-context)
> #'(lambda (foo) ...))
>
#+emacs
(put 'call-with-foo 'lisp-indent-function 1)
and then it will indent it as:
(call-with-foo (current-context)
#'(lambda (foo) ...))
There are two practical ways to do that automatically:
1- use emacs local variables. Put at the end of the source:
;;; Local Variables:
;;; eval: (put 'call-with-foo 'lisp-indent-function 1)
;;; End:
so when you open this file, emacs will evaluate the expression, and
will know how to indent your operators.
However, recent versions of emacs thankfully ask you whether the
expression is safe to evaluate. This is nice to avoid viruses (if
only Microsoft could take a hint), but this is irritating having to
answer to a set of questions when loading a file. Also, the same
operator may appear in various files so this may lead to code
duplication and maintenance headache. Therefore:
2- nowadays, what I do, is to put these instructions in separate
lisp.indentations files, spread at various levels of my source
directory hierarchy, and I have an emacs command to load them with
M-x load-lisp-indentations RET
(require 'cl) ; of course
(defun cl-indent (symbol num-forms)
"
Put on the SYMBOL and its lower case and upper case variants
a 'lisp-indent-function property set to NUM-FORMS.
"
(dolist (property '(lisp-indent-function common-lisp-indent-function))
(put symbol property num-forms)
(put (intern (string-downcase (symbol-name symbol))) property num-forms)
(put (intern (string-upcase (symbol-name symbol))) property num-forms)))
(defun* read* (stream &optional (eof-error-p t) eof-value ignored)
(handler-case (read stream)
(end-of-file (err) (if eof-error-p
(error err)
eof-value))))
(defun %batch-cl-indent (&rest indent-symbols-list)
(dolist (item indent-symbols-list)
(let ((indent (car item)))
(dolist (sym (cdr item))
(cl-indent sym indent)
(let ((p (position (character ":") (symbol-name sym))))
(when p
(cl-indent (intern (subseq (symbol-name sym) (1+ p)))
indent)))))))
(defmacro* do-directories-up ((var dir-path &optional result) &body body)
"
DO: Evaluates body with var bound to dir-path, then dir-path's parent,
and so on up to the root directory.
RETURN: The evaluation of the result form.
"
`(do ((,var ,dir-path
(if (string-match "^\\(.*/\\)[^/]+/$" ,var)
(match-string 1 ,var)
"")))
((string-equal "" ,var) ,result)
,@body))
(defun load-lisp-indentations ()
"Processes a lisp.indentations file,
in the current directory, or in a parent."
(interactive)
(do-directories-up (dir default-directory)
(let ((file (concat dir "lisp.indentations")))
;; (message "file = %S" file)
(when (file-exists-p file)
(save-excursion
(let ((count (length (buffer-list)))) ; is there a better way?
(find-file file)
(goto-char (point-min))
(let ((killp (/= count (length (buffer-list)))))
(unwind-protect
(loop
for clause = (read* (current-buffer) nil (current-buffer))
until (eql clause (current-buffer))
do (message "(%%batch-cl-indent '%S)" clause)
do (%batch-cl-indent clause))
(when killp (kill-buffer (current-buffer)))))))))))
Here is an extract of my ~/lisp.indentations file:
;;-------------
;; COMMON-LISP
;;-------------
(defun lambda macrolet)
(((&whole 4 &rest (&whole 1 &lambda &body)) &body)
flet labels)
(((&whole 6 1 1 1 1 1 1) (&whole 4 1 1 1 1 1 1) &body)
destructuring-bind)
(0 progn)
;; (put 'progn 'lisp-indent-function 0), say, causes progn to be indented
;; like defun if the first form is placed on the next line, otherwise
;; it is indented like any other form (i.e. forms line up under first).
(1 block case catch ccase concatenate
do-all-symbols do-external-symbols do-symbols
dolist dotimes ecase eval-when
format
handler-case
if let let*
logical-pathname-translations make-instance
print-unreadable-object
typecase ctypecase etypecase
prog1 rename-package run-program struct unless
unwind-protect when while with-accessors
with-compilation-unit with-condition-restarts
with-gensyms with-hash-table-iterator with-input-from-string
with-open-file with-open-stream with-output-to-string
with-package-iterator with-simple-restart
with-standard-io-syntax with-temp-file without-package-lock)
(2 condition-case destructuring-bind do do* multiple-value-bind
multiple-value-setq prog2 with-slots set-dispatch-macro-character
cl:defmacro)
;;-------------
;; CLISP
;;-------------
(1 ffi:with-foreign-strings ffi:with-foreign-object
ffi:def-c-type ffi:def-c-struct
ffi:def-c-call-out ffi:def-c-call-int
ffi:with-c-var
ext:run-program ext:without-package-lock
ext:letf
screen:with-window)
;;-------------
;; ALEGRO
;;-------------
;; Franz Allegro net.html.generator
(1 net.html.generator:html-stream html-stream)
;; Franz AllegroCache
(1 db.ac:doclass db.ac:doclass*)
(1 if* db.ac:doclass db.ac:doclass* doclass doclass*
)
(defun top-level:alias tpl:alias)
;;-------------
;; Libraries
;;-------------
;; parenscript
(1 doeach)
;; CFFI
(1 defbinding)
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Benjamin Teuber <······@web.de> writes:
> Hi everybody,
>
> I've been spending some time thinking about this code formatting
> issue. Although the task of writing a good formatter is quite
> demanding by itself, I think the real problem is whether or not we are
> willing to drop macros with "special formatting" in order to get a
> canonical format. E.g., you might want to have different indentation
> levels for the parameter list and the body of a function, as
>
> (defun myfun
> (long-parameter-list-argument-1 ..)
> ("heureka"))
>
> looks quite weird.
Yes.
emacs indents it like this both in emacs-lisp-mode and in common-lisp-mode:
(defun myfun
(long-parameter-list-argument-1 ..)
("heureka"))
> Or maybe you like
>
> (if x
> "true"
> "false")
>
> which at least one editor I tried gives.
Because it is not indenting Common Lisp code, but some older lisp,
like emacs lisp.
(if test
(single form evaluated when test is true)
(in emacs lisp)
(we can have)
(several forms with)
(an implicit progn)
(in the else branch))
> But if this special indentation rules are important, there should be
> some way to give a hint when defining a macro about how to indent it
> correctly, as a user-macro should have the same rights as defmacro =)
> At least this is what I would do if I had to reinvent Lisp from
> scratch - which in fact I might be doing ;-)
Have fun!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
On 18 Jul., 07:32, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Benjamin Teuber <······@web.de> writes:
> > Or maybe you like
>
> > (if x
> > "true"
> > "false")
>
> > which at least one editor I tried gives.
>
> Because it is not indenting Common Lisp code, but some older lisp,
> like emacs lisp.
Thanks for clarifying that.
In comp.lang.scheme ······@gmail.com <······@gmail.com> wrote:
[snip]
Really, does it matter?
LISP is just another Turing complete language like any other where some
semantic idioms are nice to express and others difficult. I hear some
people like it and other people don't. What's the difference? Every single
language is like that. Every. Single. One.
If you seriously are upset about what you think are deficiencies in
the language, the world would be better serviced by you writing code,
or contributing to a compiler, or making an IDE, or writing papers to
prove why your way is better than the current way, or any other number of
things except writing volumes of crap that from my point of view mostly
exists to cause strife in the newsgroups.
I'm not avoinding your criticisms either. I'm saying that you aren't
doing anything about your criticisms other than kicking up dust so
others can't see. And that seems to be a waste of time....
-pete
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g5quor$ft8$1@aioe.org>
Peter Keller wrote:
> In comp.lang.scheme ······@gmail.com <······@gmail.com> wrote:
> [snip]
>
> Really, does it matter?
>
> LISP is just another Turing complete language like any other where some
> semantic idioms are nice to express and others difficult. I hear some
> people like it and other people don't. What's the difference? Every single
> language is like that. Every. Single. One.
The difference is productivity. Modern software obviously benefits
enormously from the use of recently adopted technologies like garbage
collection and closures. If you want to compete, you must understand what
the options are and what trade-offs they make.
> If you seriously are upset about what you think are deficiencies in
> the language, the world would be better serviced by you writing code,
> or contributing to a compiler, or making an IDE, or writing papers to
> prove why your way is better than the current way, or any other number of
> things except writing volumes of crap that from my point of view mostly
> exists to cause strife in the newsgroups.
If you want to design and implement a new language then you should survey
what already exists and study the trade-offs exhaustively.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 18 Lug, 22:34, Jon Harrop <····@ffconsultancy.com> wrote:
> Peter Keller wrote:
> > In comp.lang.scheme ······@gmail.com <······@gmail.com> wrote:
> > [snip]
>
> > Really, does it matter?
>
> > LISP is just another Turing complete language like any other where some
> > semantic idioms are nice to express and others difficult. I hear some
> > people like it and other people don't. What's the difference? Every single
> > language is like that. Every. Single. One.
>
> The difference is productivity. Modern software obviously benefits
> enormously from the use of recently adopted technologies like garbage
> collection and closures.
Recently adopted?
Lisp has garbage collection since 1960 and closures since 1970.
Most languages, even the old ones, have garbage collection.
These are recent adoptions in langages derived from C.
<snip>
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g623as$fc3$1@aioe.org>
Vend wrote:
> On 18 Lug, 22:34, Jon Harrop <····@ffconsultancy.com> wrote:
>> The difference is productivity. Modern software obviously benefits
>> enormously from the use of recently adopted technologies like garbage
>> collection and closures.
>
> Recently adopted?
I was referring to the mainstream. Garbage collection and closures have long
since been available in esoteric languages like Lisp, as you say, but they
were not widely adopted until relatively recently (very recently for
closures).
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 21 Lug, 15:35, Jon Harrop <····@ffconsultancy.com> wrote:
> Vend wrote:
> > On 18 Lug, 22:34, Jon Harrop <····@ffconsultancy.com> wrote:
> >> The difference is productivity. Modern software obviously benefits
> >> enormously from the use of recently adopted technologies like garbage
> >> collection and closures.
>
> > Recently adopted?
>
> I was referring to the mainstream. Garbage collection and closures have long
> since been available in esoteric languages like Lisp, as you say, but they
> were not widely adopted until relatively recently (very recently for
> closures).
I don't think that Lisp can be considered an esoteric language. It was
quite mainstream in the academic world during the 70s.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g62c78$gv3$1@aioe.org>
Vend wrote:
> I don't think that Lisp can be considered an esoteric language. It was
> quite mainstream in the academic world during the 70s.
That is not even remotely close to being true. The vast majority of academic
programmers are natural scientists and engineers and they have always been
almost entirely unaware of Lisp, including during the 70s. Indeed, the only
subset of the population commonly familiar with Lisp is probably academic
computer scientists from the USA during the 70s. That is not mainstream by
any stretch of the imagination.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 21 Lug, 18:06, Jon Harrop <····@ffconsultancy.com> wrote:
> Vend wrote:
> > I don't think that Lisp can be considered an esoteric language. It was
> > quite mainstream in the academic world during the 70s.
>
> That is not even remotely close to being true. The vast majority of academic
> programmers are natural scientists and engineers and they have always been
> almost entirely unaware of Lisp, including during the 70s. Indeed, the only
> subset of the population commonly familiar with Lisp is probably academic
> computer scientists from the USA during the 70s. That is not mainstream by
> any stretch of the imagination.
The non-computer scientists mainly used (and use) Fortran. Computer
scientists both in the USA and elsewhere used Lisp a lot, although
Prolog was also quite popular outside the USA, particularly in Japan
due to the government funded "Fifth Generation Computer Systems
project".
On 21 Lug, 21:57, Vend <······@virgilio.it> wrote:
> On 21 Lug, 18:06, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Vend wrote:
> > > I don't think that Lisp can be considered an esoteric language. It was
> > > quite mainstream in the academic world during the 70s.
>
> > That is not even remotely close to being true. The vast majority of academic
> > programmers are natural scientists and engineers and they have always been
> > almost entirely unaware of Lisp, including during the 70s. Indeed, the only
> > subset of the population commonly familiar with Lisp is probably academic
> > computer scientists from the USA during the 70s. That is not mainstream by
> > any stretch of the imagination.
>
> The non-computer scientists mainly used (and use) Fortran. Computer
> scientists both in the USA and elsewhere used Lisp a lot, although
> Prolog was also quite popular outside the USA, particularly in Japan
> due to the government funded "Fifth Generation Computer Systems
> project".
Actually the "Fifth Generation Computer Systems project" was in the
80s. Sorry for the mistake.
On Mon, 21 Jul 2008 14:35:01 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>Vend wrote:
>> On 18 Lug, 22:34, Jon Harrop <····@ffconsultancy.com> wrote:
>>> The difference is productivity. Modern software obviously benefits
>>> enormously from the use of recently adopted technologies like garbage
>>> collection and closures.
>>
>> Recently adopted?
>
>I was referring to the mainstream. Garbage collection and closures have long
>since been available in esoteric languages like Lisp, as you say, but they
>were not widely adopted until relatively recently (very recently for
>closures).
IMO, the term "mainstream" also includes the Pascal family. Modern
derivatives of Pascal - Ada, Modula2+, Modula 3, Oberon, etc. - have
had GC since the 1980's. Ada and Oberon have language supported
threads and Ada has co-routines so effectively it has continuations.
None of these languages are "esoteric" - they require only minor
adjustments from C/C++ programmers.
Ada has quite a large following in the U.S., Europe and Japan where it
is used for a lot of safety critical industrial applications and for
embedded programming, and it is still the preferred language for all
U.S. Pentagon contracts (although it is not required). Ada is
required for most aerospace applications in the U.S. and Europe.
Oberon is still taught in some European schools and has a fair sized
user community there and in the Middle East. Modula 3 is largely
academic now, but it was originally developed for industrial use and
still sports a small number of commercial developers. Both Modula 3
and Oberon have large research communities.
George
--
for email reply remove "/" from address
George Neuner <·········@/comcast.net> writes:
Oberon is still taught in some European schools and has
a fair sized user community there and in the Middle
East. Modula 3 is largely academic now, but it was
originally developed for industrial use and still sports
a small number of commercial developers. Both Modula 3
and Oberon have large research communities.
<flamebait>
Oberon has its own operating system--Bluebottle. I got it
to install on my machine recently just out of curiosity
with no problem.
So how's that Lisp operating system thing coming along?
</flaimbait>
On Mon, 21 Jul 2008 16:53:00 -0600, Evans Winner <······@timbral.net>
wrote:
>George Neuner <·········@/comcast.net> writes:
>
> Oberon is still taught in some European schools and has
> a fair sized user community there and in the Middle
> East. Modula 3 is largely academic now, but it was
> originally developed for industrial use and still sports
> a small number of commercial developers. Both Modula 3
> and Oberon have large research communities.
>
><flamebait>
>
> Oberon has its own operating system--Bluebottle. I got it
> to install on my machine recently just out of curiosity
> with no problem.
Modula 3 has its own OS too - called SPIN, developed by the University
of Washington.
>
> So how's that Lisp operating system thing coming along?
>
></flaimbait>
http://cbbrowne.com/info/lisposes.html
You're not hurting my feelings ... I like Lisp intellectually but I
haven't drunk the KoolAid - I have my own ideas on what makes the
perfect development language. My dream language borrows concepts from
Lisp but is quite far removed from the programming minutia.
George
--
for email reply remove "/" from address
The entity, AKA Evans Winner <······@timbral.net> wrote :
(selectively-snipped-or-not-P)
> <flamebait>
>
> So how's that Lisp operating system thing coming along?
>
> </flaimbait>
Nah, Emacs allready exists ;-)
Cor
--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
Ik ontwerp schpellvauden, ergo innoveer taal
In article <··············@timbral.net>,
Evans Winner <······@timbral.net> wrote:
> George Neuner <·········@/comcast.net> writes:
>
> Oberon is still taught in some European schools and has
> a fair sized user community there and in the Middle
> East. Modula 3 is largely academic now, but it was
> originally developed for industrial use and still sports
> a small number of commercial developers. Both Modula 3
> and Oberon have large research communities.
>
> <flamebait>
>
> Oberon has its own operating system--Bluebottle. I got it
> to install on my machine recently just out of curiosity
> with no problem.
>
> So how's that Lisp operating system thing coming along?
>
> </flaimbait>
So you want to contribute to the Movitz project, right?
http://common-lisp.net/project/movitz/
--
http://lispm.dyndns.org/
P� Tue, 22 Jul 2008 00:53:00 +0200, skrev Evans Winner
<······@timbral.net>:
> George Neuner <·········@/comcast.net> writes:
> Oberon is still taught in some European schools and has
> a fair sized user community there and in the Middle
> East. Modula 3 is largely academic now, but it was
> originally developed for industrial use and still sports
> a small number of commercial developers. Both Modula 3
> and Oberon have large research communities.
> <flamebait>
>
> Oberon has its own operating system--Bluebottle. I got it
> to install on my machine recently just out of curiosity
> with no problem.
>
> So how's that Lisp operating system thing coming along?
>
> </flaimbait>
Come and gone. The Symbolics Lisp Machine OS was called Genera.
Open Genera might still be around.
--------------
John Thingstad
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g64g4m$n8d$1@aioe.org>
George Neuner wrote:
> On Mon, 21 Jul 2008 14:35:01 +0100, Jon Harrop <···@ffconsultancy.com>
> wrote:
>>I was referring to the mainstream. Garbage collection and closures have
>>long since been available in esoteric languages like Lisp, as you say, but
>>they were not widely adopted until relatively recently (very recently for
>>closures).
>
> IMO, the term "mainstream" also includes the Pascal family. Modern
> derivatives of Pascal - Ada, Modula2+, Modula 3, Oberon, etc. - have
> had GC since the 1980's.
Ada was by far the most successful of those and it does not require garbage
collection and it does not provide closures.
Modula-2 also lacks garbage collection.
> None of these languages are "esoteric" - they require only minor
> adjustments from C/C++ programmers.
Sure.
> Ada has quite a large following in the U.S., Europe and Japan where it
> is used for a lot of safety critical industrial applications and for
> embedded programming, and it is still the preferred language for all
> U.S. Pentagon contracts (although it is not required). Ada is
> required for most aerospace applications in the U.S. and Europe.
>
> Oberon is still taught in some European schools and has a fair sized
> user community there and in the Middle East. Modula 3 is largely
> academic now, but it was originally developed for industrial use and
> still sports a small number of commercial developers. Both Modula 3
> and Oberon have large research communities.
None of those examples are remotely close to mainstream.
In reality, garbage collection became mainstream with Java and closures are
becoming mainstream with C# 3.0.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 22 Lug, 13:26, Jon Harrop <····@ffconsultancy.com> wrote:
> George Neuner wrote:
> > On Mon, 21 Jul 2008 14:35:01 +0100, Jon Harrop <····@ffconsultancy.com>
> > wrote:
> >>I was referring to the mainstream. Garbage collection and closures have
> >>long since been available in esoteric languages like Lisp, as you say, but
> >>they were not widely adopted until relatively recently (very recently for
> >>closures).
>
> > IMO, the term "mainstream" also includes the Pascal family. Modern
> > derivatives of Pascal - Ada, Modula2+, Modula 3, Oberon, etc. - have
> > had GC since the 1980's.
>
> Ada was by far the most successful of those and it does not require garbage
> collection and it does not provide closures.
>
> Modula-2 also lacks garbage collection.
>
> > None of these languages are "esoteric" - they require only minor
> > adjustments from C/C++ programmers.
>
> Sure.
>
> > Ada has quite a large following in the U.S., Europe and Japan where it
> > is used for a lot of safety critical industrial applications and for
> > embedded programming, and it is still the preferred language for all
> > U.S. Pentagon contracts (although it is not required). Ada is
> > required for most aerospace applications in the U.S. and Europe.
>
> > Oberon is still taught in some European schools and has a fair sized
> > user community there and in the Middle East. Modula 3 is largely
> > academic now, but it was originally developed for industrial use and
> > still sports a small number of commercial developers. Both Modula 3
> > and Oberon have large research communities.
>
> None of those examples are remotely close to mainstream.
>
> In reality, garbage collection became mainstream with Java and closures are
> becoming mainstream with C# 3.0.
Basic, particularly in its Visual Basic incarnation, was quite
mainstream in the 90s and early 2000s. Before Delphi was relased,
Visual Basic was practically the only way to program MsDos and Windows
without having to deal with C/C++.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g64v73$aun$1@aioe.org>
Vend wrote:
>> In reality, garbage collection became mainstream with Java and closures
>> are becoming mainstream with C# 3.0.
>
> Basic, particularly in its Visual Basic incarnation, was quite
> mainstream in the 90s and early 2000s. Before Delphi was relased,
> Visual Basic was practically the only way to program MsDos and Windows
> without having to deal with C/C++.
True but, again, most BASICs including VBs 1-6 did not have accurate garbage
collection. VB only got accurate GC 6 years after Java.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 22 Lug, 17:43, Jon Harrop <····@ffconsultancy.com> wrote:
> Vend wrote:
> >> In reality, garbage collection became mainstream with Java and closures
> >> are becoming mainstream with C# 3.0.
>
> > Basic, particularly in its Visual Basic incarnation, was quite
> > mainstream in the 90s and early 2000s. Before Delphi was relased,
> > Visual Basic was practically the only way to program MsDos and Windows
> > without having to deal with C/C++.
>
> True but, again, most BASICs including VBs 1-6 did not have accurate garbage
> collection. VB only got accurate GC 6 years after Java.
I've always thought that all BASICs include garbage collection.
The ones I've seen (C64 basic, gwbasic, qbasic and visual basic) IIRC
all support dynamic allocation but not explicit deallocation.
On Tue, 22 Jul 2008 13:38:23 -0700 (PDT), Vend <······@virgilio.it>
wrote:
>On 22 Lug, 17:43, Jon Harrop <····@ffconsultancy.com> wrote:
>
>> Vend wrote:
>>
>> >> In reality, garbage collection became mainstream with Java and closures
>> >> are becoming mainstream with C# 3.0.
>>
>> > Basic, particularly in its Visual Basic incarnation, was quite
>> > mainstream in the 90s and early 2000s. Before Delphi was relased,
>> > Visual Basic was practically the only way to program MsDos and Windows
>> > without having to deal with C/C++.
>>
>> True but, again, most BASICs including VBs 1-6 did not have accurate garbage
>> collection. VB only got accurate GC 6 years after Java.
>
>I've always thought that all BASICs include garbage collection.
>
>The ones I've seen (C64 basic, gwbasic, qbasic and visual basic) IIRC
>all support dynamic allocation but not explicit deallocation.
Not GC exactly, but certainly automatic memory management. Many early
BASICs used object indirection tables and a combination of reference
counting and sliding heap compaction. AFAIK, VB prior to .NET used
only reference counting but I don't know it handled cycles.
But Jon doesn't consider BASIC a "mainstream" language.
George
--
for email reply remove "/" from address
On 23 Lug, 04:51, George Neuner <·········@/comcast.net> wrote:
> On Tue, 22 Jul 2008 13:38:23 -0700 (PDT), Vend <······@virgilio.it>
> wrote:
>
>
>
> >On 22 Lug, 17:43, Jon Harrop <····@ffconsultancy.com> wrote:
>
> >> Vend wrote:
>
> >> >> In reality, garbage collection became mainstream with Java and closures
> >> >> are becoming mainstream with C# 3.0.
>
> >> > Basic, particularly in its Visual Basic incarnation, was quite
> >> > mainstream in the 90s and early 2000s. Before Delphi was relased,
> >> > Visual Basic was practically the only way to program MsDos and Windows
> >> > without having to deal with C/C++.
>
> >> True but, again, most BASICs including VBs 1-6 did not have accurate garbage
> >> collection. VB only got accurate GC 6 years after Java.
>
> >I've always thought that all BASICs include garbage collection.
>
> >The ones I've seen (C64 basic, gwbasic, qbasic and visual basic) IIRC
> >all support dynamic allocation but not explicit deallocation.
>
> Not GC exactly, but certainly automatic memory management. Many early
> BASICs used object indirection tables and a combination of reference
> counting and sliding heap compaction. AFAIK, VB prior to .NET used
> only reference counting but I don't know it handled cycles.
What is sliding heap compaction?
> But Jon doesn't consider BASIC a "mainstream" language.
>
On Wed, 23 Jul 2008 02:19:07 -0700 (PDT), Vend <······@virgilio.it>
wrote:
>
>What is sliding heap compaction?
>
It's a simple method of eliminating fragmentation in the heap. Live
objects are relocated while preserving their relative order by sliding
(copying) them to one end of the heap.
See: http://www.memorymanagement.org/glossary/h.html#handle
for a visual aid of the table indirection model that was common in the
old BASICs. As the text mentions, it also was the memory model for
the old (pre-Unix) Mac OS.
Also Google for Mark-Compact(ing) GC. I tried briefly to find visual
aids for this algorithm but I didn't see anything simple - really odd
because both JVM and .NET use MC ... you'd think the web would be full
of pages trying to explain it. Anyway, maybe you can find a good
paper - the only good MC visuals I know of are offline in Jones & Lins
GC book.
George
--
for email reply remove "/" from address
On 24 Lug, 03:52, George Neuner <·········@/comcast.net> wrote:
> On Wed, 23 Jul 2008 02:19:07 -0700 (PDT), Vend <······@virgilio.it>
> wrote:
>
>
>
> >What is sliding heap compaction?
>
> It's a simple method of eliminating fragmentation in the heap. Live
> objects are relocated while preserving their relative order by sliding
> (copying) them to one end of the heap.
>
> See:http://www.memorymanagement.org/glossary/h.html#handle
> for a visual aid of the table indirection model that was common in the
> old BASICs. As the text mentions, it also was the memory model for
> the old (pre-Unix) Mac OS.
>
> Also Google for Mark-Compact(ing) GC. I tried briefly to find visual
> aids for this algorithm but I didn't see anything simple - really odd
> because both JVM and .NET use MC ... you'd think the web would be full
> of pages trying to explain it. Anyway, maybe you can find a good
> paper - the only good MC visuals I know of are offline in Jones & Lins
> GC book.
Ok, thanks.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6dlo0$u14$1@aioe.org>
Vend wrote:
> The ones I've seen (C64 basic, gwbasic, qbasic and visual basic) IIRC
> all support dynamic allocation but not explicit deallocation.
Early versions of BBC BASIC simply leaked. Later versions provided manual
memory management.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>George Neuner wrote:
>> On Mon, 21 Jul 2008 14:35:01 +0100, Jon Harrop <···@ffconsultancy.com>
>> wrote:
>>>I was referring to the mainstream. Garbage collection and closures have
>>>long since been available in esoteric languages like Lisp, as you say, but
>>>they were not widely adopted until relatively recently (very recently for
>>>closures).
>>
>> IMO, the term "mainstream" also includes the Pascal family. Modern
>> derivatives of Pascal - Ada, Modula2+, Modula 3, Oberon, etc. - have
>> had GC since the 1980's.
>
>Ada was by far the most successful of those and it does not require garbage
>collection and it does not provide closures.
Ada does not *require* GC, but the Boehm collector is available as
well as another Ada-specific tracing collector whose name I can't
remember just now. Ada allows overriding the default functions just
as in C++.
Also note that Ada does not allow explicit deallocation of a heap
object unless you use the optional Unchecked_Deallocation package ...
so Ada has to do it for you. By default, Ada provides a mark-release
type region based memory management. You can also roll your own
object based heap management as in C++.
It's also true that Ada does not provide automatic closures for
arbitrary nested functions. It does, however, provide both objects
with private state and concurrent tasks with private environments.
Therefore the functional equivalent of a closure is available, as in
any OO language and additionally as in a coroutine (Ada tasks can have
multiple entry points and can trivially emulate coroutines).
However Modula2+, Modula-3 and Oberon all *require* GC while
permitting explicit memory management as an advanced option.
>Modula-2 also lacks garbage collection.
Nobody said Modula-2 had GC ... Modula2+ is a different language.
Incidentally, there is also a Boehm collector for Modula-2.
>> None of these languages are "esoteric" - they require only minor
>> adjustments from C/C++ programmers.
>
>Sure.
>
>> Ada has quite a large following in the U.S., Europe and Japan where it
>> is used for a lot of safety critical industrial applications and for
>> embedded programming, and it is still the preferred language for all
>> U.S. Pentagon contracts (although it is not required). Ada is
>> required for most aerospace applications in the U.S. and Europe.
>>
>> Oberon is still taught in some European schools and has a fair sized
>> user community there and in the Middle East. Modula 3 is largely
>> academic now, but it was originally developed for industrial use and
>> still sports a small number of commercial developers. Both Modula 3
>> and Oberon have large research communities.
>
>None of those examples are remotely close to mainstream.
>
>In reality, garbage collection became mainstream with Java and closures are
>becoming mainstream with C# 3.0.
I see. You define "mainstream" as whatever wins you the argument.
Before Java and Python came along, Ada was the 5th most popular
general purpose language by number of users. It still has more users
than all the ML variants combined.
George
--
for email reply remove "/" from address
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6dmg2$18o$1@aioe.org>
George Neuner wrote:
> On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <···@ffconsultancy.com>
> wrote:
>>Ada was by far the most successful of those and it does not require
>>garbage collection and it does not provide closures.
>
> Ada does not *require* GC, but the Boehm collector is available as
> well as another Ada-specific tracing collector whose name I can't
> remember just now. Ada allows overriding the default functions just
> as in C++.
>
> Also note that Ada does not allow explicit deallocation of a heap
> object unless you use the optional Unchecked_Deallocation package ...
> so Ada has to do it for you. By default, Ada provides a mark-release
> type region based memory management. You can also roll your own
> object based heap management as in C++.
By that definition, C is also garbage collected.
> It's also true that Ada does not provide automatic closures for
> arbitrary nested functions. It does, however, provide both objects
> with private state and concurrent tasks with private environments.
> Therefore the functional equivalent of a closure is available, as in
> any OO language and additionally as in a coroutine (Ada tasks can have
> multiple entry points and can trivially emulate coroutines).
Ada has never had closures.
> However Modula2+, Modula-3 and Oberon all *require* GC while
> permitting explicit memory management as an advanced option.
None of those languages have ever been mainstream.
>>In reality, garbage collection became mainstream with Java and closures
>>are becoming mainstream with C# 3.0.
>
> I see. You define "mainstream" as whatever wins you the argument.
You think Java and C# 3.0 are not mainstream?
> Before Java and Python came along, Ada was the 5th most popular
> general purpose language by number of users.
What gave you that impression?
> It still has more users than all the ML variants combined.
What gave you that impression?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Sat, 26 Jul 2008 00:10:04 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>George Neuner wrote:
>> On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <···@ffconsultancy.com>
>> wrote:
>>>Ada was by far the most successful of those and it does not require
>>>garbage collection and it does not provide closures.
>>
>> Ada does not *require* GC, but the Boehm collector is available as
>> well as another Ada-specific tracing collector whose name I can't
>> remember just now. Ada allows overriding the default functions just
>> as in C++.
>>
>> Also note that Ada does not allow explicit deallocation of a heap
>> object unless you use the optional Unchecked_Deallocation package ...
>> so Ada has to do it for you. By default, Ada provides a mark-release
>> type region based memory management. You can also roll your own
>> object based heap management as in C++.
>
>By that definition, C is also garbage collected.
No. Ada forbids manual deallocation unless the programmer explicitly
marks the code "unchecked" - which results in usage warnings to any
checked code that calls it. It is not a step taken lightly.
C leaks memory if you do not call free(). Ada does not leak memory
when you do not call Deallocate() - Ada compilers use multiple heaps
with region allocation to provide low cost automatic recycling. It is
more conservative than GC, but it is a form of automatic memory
management.
>> It's also true that Ada does not provide automatic closures for
>> arbitrary nested functions. It does, however, provide both objects
>> with private state and concurrent tasks with private environments.
>> Therefore the functional equivalent of a closure is available, as in
>> any OO language and additionally as in a coroutine (Ada tasks can have
>> multiple entry points and can trivially emulate coroutines).
>
>Ada has never had closures.
Did you even bother to read what I said?
>> However Modula2+, Modula-3 and Oberon all *require* GC while
>> permitting explicit memory management as an advanced option.
>
>None of those languages have ever been mainstream.
They are all more mainstream than any ML variant.
>>>In reality, garbage collection became mainstream with Java and closures
>>>are becoming mainstream with C# 3.0.
>>
>> I see. You define "mainstream" as whatever wins you the argument.
>
>You think Java and C# 3.0 are not mainstream?
I think you are ignoring evidence of other languages also being
mainstream. And re: C#, yes, I think it is not mainstream. C# has
more propaganda than users.
>> Before Java and Python came along, Ada was the 5th most popular
>> general purpose language by number of users.
>
>What gave you that impression?
It's not an impression - it's a fact backed by surveys and commercial
vendor license figures. Prior to Java's general release in 1995, the
top 10 general purpose programming languages from 1990..1994 according
to Byte magazine and Doctor Dobbs Journal were:
C/C++
Visual Basic
Object Pascal
COBOL
Ada
C
Fortran
Lisp
Prolog
Smalltalk
Visual Basic actually sold more licenses than all the commercial C++
compilers combined, but the free availability of GCC kept C++ on top.
The Object Pascal dialect was sold as Turbo Pascal and as Macintosh
Pascal. By 1994, most Mac programmers had transitioned to C++, but
some 25% still used Macintosh Pascal.
COBOL - what the hell can I say. Companies still use it and according
to some surveys, there are as many COBOL programs as there are
programs in C++. COBOL just won't die.
In 1994, Ada was required for programming any DOD application and was
the preferred language for US government programming contracts - a
guaranteed large user base. It was then, and still is now, the second
most widely used language for embedded programming (after C)
accounting for 1/3 of all projects. Ada is still required for most
aerospace applications and is still the preferred language for
industrial robotic control and safety critical applications such as
chemical and nuclear plant operations.
The top 10 list is different now. Java, Python and C# have come onto
it - Fortran, Prolog and Smalltalk have fallen off. But oddly enough,
Objective Pascal (aka Delphi), COBOL and Ada are still on it and ML
still isn't.
>> It still has more users than all the ML variants combined.
>
>What gave you that impression?
The number of programmers employed in application areas that prefer
Ada to other languages.
What gives you your impressions? Google fights?
George
--
for email reply remove "/" from address
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6fbj6$g2t$1@aioe.org>
George Neuner wrote:
> On Sat, 26 Jul 2008 00:10:04 +0100, Jon Harrop <···@ffconsultancy.com>
> wrote:
>>George Neuner wrote:
>>> On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <···@ffconsultancy.com>
>>> wrote:
>>>>Ada was by far the most successful of those and it does not require
>>>>garbage collection and it does not provide closures.
>>>
>>> Ada does not *require* GC, but the Boehm collector is available as
>>> well as another Ada-specific tracing collector whose name I can't
>>> remember just now. Ada allows overriding the default functions just
>>> as in C++.
>>>
>>> Also note that Ada does not allow explicit deallocation of a heap
>>> object unless you use the optional Unchecked_Deallocation package ...
>>> so Ada has to do it for you. By default, Ada provides a mark-release
>>> type region based memory management. You can also roll your own
>>> object based heap management as in C++.
>>
>> By that definition, C is also garbage collected.
>
> No. Ada forbids manual deallocation unless the programmer explicitly
> marks the code "unchecked" - which results in usage warnings to any
> checked code that calls it. It is not a step taken lightly.
So Ada allows manual deallocation, just like C.
> C leaks memory if you do not call free(). Ada does not leak memory
> when you do not call Deallocate() - Ada compilers use multiple heaps
> with region allocation to provide low cost automatic recycling. It is
> more conservative than GC, but it is a form of automatic memory
> management.
So Ada does not require garbage collection, just like C.
>>> It's also true that Ada does not provide automatic closures for
>>> arbitrary nested functions. It does, however, provide both objects
>>> with private state and concurrent tasks with private environments.
>>> Therefore the functional equivalent of a closure is available, as in
>>> any OO language and additionally as in a coroutine (Ada tasks can have
>>> multiple entry points and can trivially emulate coroutines).
>>
>> Ada has never had closures.
>
> Did you even bother to read what I said?
You listed irrelevant features to detract from the fact that Ada has never
had closures.
>>> However Modula2+, Modula-3 and Oberon all *require* GC while
>>> permitting explicit memory management as an advanced option.
>>
>> None of those languages have ever been mainstream.
>
> They are all more mainstream than any ML variant.
ROTFL.
>>>>In reality, garbage collection became mainstream with Java and closures
>>>>are becoming mainstream with C# 3.0.
>>>
>>> I see. You define "mainstream" as whatever wins you the argument.
>>
>> You think Java and C# 3.0 are not mainstream?
>
> I think you are ignoring evidence of other languages also being
> mainstream. And re: C#, yes, I think it is not mainstream. C# has
> more propaganda than users.
You really think Ada is mainstream but C# is not? That's pretty funny...
>>> Before Java and Python came along, Ada was the 5th most popular
>>> general purpose language by number of users.
>>
>> What gave you that impression?
>
> It's not an impression - it's a fact backed by surveys and commercial
> vendor license figures. Prior to Java's general release in 1995, the
> top 10 general purpose programming languages from 1990..1994 according
> to Byte magazine and Doctor Dobbs Journal were:
>
> C/C++
> Visual Basic
> Object Pascal
> COBOL
> Ada
> C
> Fortran
> Lisp
> Prolog
> Smalltalk
What are the original sources and why is C listed twice in the top 10?
> Visual Basic actually sold more licenses than all the commercial C++
> compilers combined, but the free availability of GCC kept C++ on top.
> The Object Pascal dialect was sold as Turbo Pascal and as Macintosh
> Pascal. By 1994, most Mac programmers had transitioned to C++, but
> some 25% still used Macintosh Pascal.
Can you cite any original sources substantiating any of these conjectures?
> COBOL - what the hell can I say. Companies still use it and according
> to some surveys, there are as many COBOL programs as there are
> programs in C++. COBOL just won't die.
The number of COBOL programmers is tiny.
> In 1994, Ada was required for programming any DOD application and was
> the preferred language for US government programming contracts - a
> guaranteed large user base.
Large? That is a tiny user base.
> It was then, and still is now, the second most widely used language for
> embedded programming (after C) accounting for 1/3 of all projects.
What gave you that impression?
> Ada is still required for most aerospace applications and is still the
> preferred language for industrial robotic control and safety critical
> applications such as chemical and nuclear plant operations.
All of which are tiny user bases.
> The top 10 list is different now. Java, Python and C# have come onto
> it - Fortran, Prolog and Smalltalk have fallen off. But oddly enough,
> Objective Pascal (aka Delphi), COBOL and Ada are still on it and ML
> still isn't.
You really think Ada is in the top 10 most popular languages by the number
of users?
According to Tim O'Reilly's book sale statistics, Ada is in the bottom 10
next to Squeak and Rexx:
http://radar.oreilly.com/2007/05/state-of-the-computer-book-mar-15.html
1 Java
2 C#
3 C++
4 VB
5 Ruby
6 VBA
7 Perl
8 Python
9 VBScript
10 Basic
11 Powershell
12 Groovy
13 Objective C
14 Assembler
15 Lisp
16 Lua
17 Tcl
18 Scheme
19 Haskell
20 COBOL
21 C
22 Alice
23 Delphi
24 OCaml
25 JCL
26 RealBASIC
27 Ada
29 Squeak
31 Rexx
32 Fortran
Specifically, Ada's market share declined to <0.005% compared to, say, 12%
for C#. Note that Modula-2, Modula-3 and Oberon are not even on the list.
OCaml was already ahead of Ada. With the publication of three books on F#,
ML variants are now a long long way ahead of Ada.
>>> It still has more users than all the ML variants combined.
>>
>> What gave you that impression?
>
> The number of programmers employed in application areas that prefer
> Ada to other languages.
Oh look, more unfounded speculation.
> What gives you your impressions?
I personally sold more copies of OCaml for Scientists in 2007 than all book
sellers sold Ada books combined.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> You really think Ada is in the top 10 most popular languages by the number
> of users?
> According to Tim O'Reilly's book sale statistics, Ada is in the bottom 10
> next to Squeak and Rexx:
Book sale statistics are seriously misleading, since the latest hype is
always a ploughed field for those bazillion "XYZ for the complete idiot"
authors who put out quantity rather than quality. Furthermore, if one
has bought K&R2 or Steele 10 years ago, he isn't going to buy another
one every year even though he probably still uses C on a daily basis.
Same for other established languages.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6kpvs$8vs$1@aioe.org>
Matthias Buelow wrote:
> Jon Harrop wrote:
>> You really think Ada is in the top 10 most popular languages by the
>> number of users?
>> According to Tim O'Reilly's book sale statistics, Ada is in the bottom 10
>> next to Squeak and Rexx:
>
> Book sale statistics are seriously misleading, since the latest hype is
> always a ploughed field for those bazillion "XYZ for the complete idiot"
> authors who put out quantity rather than quality.
So O'Reilly say that Ada has <0.005% market share of books, over three
orders of magnitude less than mainstream languages (e.g. 12% for C#).
ITJobsWatch says Ada has 0.07% of the UK job market, over two orders of
magnitude less than mainstream languages (e.g. 13% for C#).
Just to humour George, I also searched for Ada jobs in the US (where, I
believe, Ada's popularity is concentrated) but dice.com lists only one job
for "Ada developer" compared to 794 for "C# developer". So, again, Ada is
several orders of magnitude below mainstream languages.
This raises two obvious questions:
. How many such results will it take before we conclude that George's
assertion that Ada is still mainstream and still in the top 10 programming
languages is about as far from correct as you can get?
. Can we find any metric that paints a different picture of Ada's
popularity?
To be honest, I am absolutely stunned that anyone could be so far off the
money. I think even George now realises just how stupid his assertion was.
Hence he started trying to discuss ML's popularity instead and eventually
gave up even on that.
> Same for other established languages. Furthermore, if one has bought K&R2
> or Steele 10 years ago, he isn't going to buy another one every year even
> though he probably still uses C on a daily basis.
I have always bought books on languages that I use. I used to buy books on C
when I was using C but I now make virtually no use of C. So I do not
believe that book sales do not correlate with language popularity and,
indeed, have just shown that book sales do correlate well with other
measures of language popularity like the job market.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
> Just to humour George, I also searched for Ada jobs in the US (where, I
> believe, Ada's popularity is concentrated) but dice.com lists only one job
> for "Ada developer" compared to 794 for "C# developer". So, again, Ada is
> several orders of magnitude below mainstream languages.
And why should that bother you at all?
On 26 juil, 16:16, Jon Harrop <····@ffconsultancy.com> wrote:
> George Neuner wrote:
> > On Sat, 26 Jul 2008 00:10:04 +0100, Jon Harrop <····@ffconsultancy.com>
> > wrote:
> >>George Neuner wrote:
> >>> On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <····@ffconsultancy.com>
> >>> wrote:
> >>>>Ada was by far the most successful of those and it does not require
> >>>>garbage collection and it does not provide closures.
>
> >>> Ada does not *require* GC, but the Boehm collector is available as
> >>> well as another Ada-specific tracing collector whose name I can't
> >>> remember just now. Ada allows overriding the default functions just
> >>> as in C++.
>
> >>> Also note that Ada does not allow explicit deallocation of a heap
> >>> object unless you use the optional Unchecked_Deallocation package ...
> >>> so Ada has to do it for you. By default, Ada provides a mark-release
> >>> type region based memory management. You can also roll your own
> >>> object based heap management as in C++.
>
> >> By that definition, C is also garbage collected.
>
> > No. Ada forbids manual deallocation unless the programmer explicitly
> > marks the code "unchecked" - which results in usage warnings to any
> > checked code that calls it. It is not a step taken lightly.
>
> So Ada allows manual deallocation, just like C.
>
> > C leaks memory if you do not call free(). Ada does not leak memory
> > when you do not call Deallocate() - Ada compilers use multiple heaps
> > with region allocation to provide low cost automatic recycling. It is
> > more conservative than GC, but it is a form of automatic memory
> > management.
>
> So Ada does not require garbage collection, just like C.
>
> >>> It's also true that Ada does not provide automatic closures for
> >>> arbitrary nested functions. It does, however, provide both objects
> >>> with private state and concurrent tasks with private environments.
> >>> Therefore the functional equivalent of a closure is available, as in
> >>> any OO language and additionally as in a coroutine (Ada tasks can have
> >>> multiple entry points and can trivially emulate coroutines).
>
> >> Ada has never had closures.
>
> > Did you even bother to read what I said?
>
> You listed irrelevant features to detract from the fact that Ada has never
> had closures.
>
> >>> However Modula2+, Modula-3 and Oberon all *require* GC while
> >>> permitting explicit memory management as an advanced option.
>
> >> None of those languages have ever been mainstream.
>
> > They are all more mainstream than any ML variant.
>
> ROTFL.
>
> >>>>In reality, garbage collection became mainstream with Java and closures
> >>>>are becoming mainstream with C# 3.0.
>
> >>> I see. You define "mainstream" as whatever wins you the argument.
>
> >> You think Java and C# 3.0 are not mainstream?
>
> > I think you are ignoring evidence of other languages also being
> > mainstream. And re: C#, yes, I think it is not mainstream. C# has
> > more propaganda than users.
>
> You really think Ada is mainstream but C# is not? That's pretty funny...
>
>
>
>
>
> >>> Before Java and Python came along, Ada was the 5th most popular
> >>> general purpose language by number of users.
>
> >> What gave you that impression?
>
> > It's not an impression - it's a fact backed by surveys and commercial
> > vendor license figures. Prior to Java's general release in 1995, the
> > top 10 general purpose programming languages from 1990..1994 according
> > to Byte magazine and Doctor Dobbs Journal were:
>
> > C/C++
> > Visual Basic
> > Object Pascal
> > COBOL
> > Ada
> > C
> > Fortran
> > Lisp
> > Prolog
> > Smalltalk
>
> What are the original sources and why is C listed twice in the top 10?
>
> > Visual Basic actually sold more licenses than all the commercial C++
> > compilers combined, but the free availability of GCC kept C++ on top.
> > The Object Pascal dialect was sold as Turbo Pascal and as Macintosh
> > Pascal. By 1994, most Mac programmers had transitioned to C++, but
> > some 25% still used Macintosh Pascal.
>
> Can you cite any original sources substantiating any of these conjectures?
>
> > COBOL - what the hell can I say. Companies still use it and according
> > to some surveys, there are as many COBOL programs as there are
> > programs in C++. COBOL just won't die.
>
> The number of COBOL programmers is tiny.
>
> > In 1994, Ada was required for programming any DOD application and was
> > the preferred language for US government programming contracts - a
> > guaranteed large user base.
>
> Large? That is a tiny user base.
>
> > It was then, and still is now, the second most widely used language for
> > embedded programming (after C) accounting for 1/3 of all projects.
>
> What gave you that impression?
>
> > Ada is still required for most aerospace applications and is still the
> > preferred language for industrial robotic control and safety critical
> > applications such as chemical and nuclear plant operations.
>
> All of which are tiny user bases.
>
> > The top 10 list is different now. Java, Python and C# have come onto
> > it - Fortran, Prolog and Smalltalk have fallen off. But oddly enough,
> > Objective Pascal (aka Delphi), COBOL and Ada are still on it and ML
> > still isn't.
>
> You really think Ada is in the top 10 most popular languages by the number
> of users?
>
> According to Tim O'Reilly's book sale statistics, Ada is in the bottom 10
> next to Squeak and Rexx:
>
> http://radar.oreilly.com/2007/05/state-of-the-computer-book-mar-15.html
>
> 1 Java
> 2 C#
> 3 C++
> 4 VB
> 5 Ruby
> 6 VBA
> 7 Perl
> 8 Python
> 9 VBScript
> 10 Basic
> 11 Powershell
> 12 Groovy
> 13 Objective C
> 14 Assembler
> 15 Lisp
> 16 Lua
> 17 Tcl
> 18 Scheme
> 19 Haskell
> 20 COBOL
> 21 C
> 22 Alice
> 23 Delphi
> 24 OCaml
> 25 JCL
> 26 RealBASIC
> 27 Ada
> 29 Squeak
> 31 Rexx
> 32 Fortran
>
> Specifically, Ada's market share declined to <0.005% compared to, say, 12%
> for C#. Note that Modula-2, Modula-3 and Oberon are not even on the list.
>
> OCaml was already ahead of Ada. With the publication of three books on F#,
> ML variants are now a long long way ahead of Ada.
>
> >>> It still has more users than all the ML variants combined.
>
> >> What gave you that impression?
>
> > The number of programmers employed in application areas that prefer
> > Ada to other languages.
>
> Oh look, more unfounded speculation.
>
> > What gives you your impressions?
>
> I personally sold more copies of OCaml for Scientists in 2007 than all book
> sellers sold Ada books combined.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
Hello,
Seriously, I make a simple exercice, find free book about Lisp ...
It's really easy.
It's not necessary to pay for that.
In contrary, I prefer buy a real tool, not download a .zip in the
INRIA WebSite, with the hope to obtain the Graal :)
Best Regards,
Christophe
On 31 jul, 09:40, Christophe <····················@birdtechnology.net>
wrote:
> On 26 juil, 16:16, Jon Harrop <····@ffconsultancy.com> wrote:
>
>
>
> > George Neuner wrote:
> > > On Sat, 26 Jul 2008 00:10:04 +0100, Jon Harrop <····@ffconsultancy.com>
> > > wrote:
> > >>George Neuner wrote:
> > >>> On Tue, 22 Jul 2008 12:26:02 +0100, Jon Harrop <····@ffconsultancy.com>
> > >>> wrote:
> > >>>>Ada was by far the most successful of those and it does not require
> > >>>>garbage collection and it does not provide closures.
>
> > >>> Ada does not *require* GC, but the Boehm collector is available as
> > >>> well as another Ada-specific tracing collector whose name I can't
> > >>> remember just now. Ada allows overriding the default functions just
> > >>> as in C++.
>
> > >>> Also note that Ada does not allow explicit deallocation of a heap
> > >>> object unless you use the optional Unchecked_Deallocation package ...
> > >>> so Ada has to do it for you. By default, Ada provides a mark-release
> > >>> type region based memory management. You can also roll your own
> > >>> object based heap management as in C++.
>
> > >> By that definition, C is also garbage collected.
>
> > > No. Ada forbids manual deallocation unless the programmer explicitly
> > > marks the code "unchecked" - which results in usage warnings to any
> > > checked code that calls it. It is not a step taken lightly.
>
> > So Ada allows manual deallocation, just like C.
>
> > > C leaks memory if you do not call free(). Ada does not leak memory
> > > when you do not call Deallocate() - Ada compilers use multiple heaps
> > > with region allocation to provide low cost automatic recycling. It is
> > > more conservative than GC, but it is a form of automatic memory
> > > management.
>
> > So Ada does not require garbage collection, just like C.
>
> > >>> It's also true that Ada does not provide automatic closures for
> > >>> arbitrary nested functions. It does, however, provide both objects
> > >>> with private state and concurrent tasks with private environments.
> > >>> Therefore the functional equivalent of a closure is available, as in
> > >>> any OO language and additionally as in a coroutine (Ada tasks can have
> > >>> multiple entry points and can trivially emulate coroutines).
>
> > >> Ada has never had closures.
>
> > > Did you even bother to read what I said?
>
> > You listed irrelevant features to detract from the fact that Ada has never
> > had closures.
>
> > >>> However Modula2+, Modula-3 and Oberon all *require* GC while
> > >>> permitting explicit memory management as an advanced option.
>
> > >> None of those languages have ever been mainstream.
>
> > > They are all more mainstream than any ML variant.
>
> > ROTFL.
>
> > >>>>In reality, garbage collection became mainstream with Java and closures
> > >>>>are becoming mainstream with C# 3.0.
>
> > >>> I see. You define "mainstream" as whatever wins you the argument.
>
> > >> You think Java and C# 3.0 are not mainstream?
>
> > > I think you are ignoring evidence of other languages also being
> > > mainstream. And re: C#, yes, I think it is not mainstream. C# has
> > > more propaganda than users.
>
> > You really think Ada is mainstream but C# is not? That's pretty funny...
>
> > >>> Before Java and Python came along, Ada was the 5th most popular
> > >>> general purpose language by number of users.
>
> > >> What gave you that impression?
>
> > > It's not an impression - it's a fact backed by surveys and commercial
> > > vendor license figures. Prior to Java's general release in 1995, the
> > > top 10 general purpose programming languages from 1990..1994 according
> > > to Byte magazine and Doctor Dobbs Journal were:
>
> > > C/C++
> > > Visual Basic
> > > Object Pascal
> > > COBOL
> > > Ada
> > > C
> > > Fortran
> > > Lisp
> > > Prolog
> > > Smalltalk
>
> > What are the original sources and why is C listed twice in the top 10?
>
> > > Visual Basic actually sold more licenses than all the commercial C++
> > > compilers combined, but the free availability of GCC kept C++ on top.
> > > The Object Pascal dialect was sold as Turbo Pascal and as Macintosh
> > > Pascal. By 1994, most Mac programmers had transitioned to C++, but
> > > some 25% still used Macintosh Pascal.
>
> > Can you cite any original sources substantiating any of these conjectures?
>
> > > COBOL - what the hell can I say. Companies still use it and according
> > > to some surveys, there are as many COBOL programs as there are
> > > programs in C++. COBOL just won't die.
>
> > The number of COBOL programmers is tiny.
>
> > > In 1994, Ada was required for programming any DOD application and was
> > > the preferred language for US government programming contracts - a
> > > guaranteed large user base.
>
> > Large? That is a tiny user base.
>
> > > It was then, and still is now, the second most widely used language for
> > > embedded programming (after C) accounting for 1/3 of all projects.
>
> > What gave you that impression?
>
> > > Ada is still required for most aerospace applications and is still the
> > > preferred language for industrial robotic control and safety critical
> > > applications such as chemical and nuclear plant operations.
>
> > All of which are tiny user bases.
>
> > > The top 10 list is different now. Java, Python and C# have come onto
> > > it - Fortran, Prolog and Smalltalk have fallen off. But oddly enough,
> > > Objective Pascal (aka Delphi), COBOL and Ada are still on it and ML
> > > still isn't.
>
> > You really think Ada is in the top 10 most popular languages by the number
> > of users?
>
> > According to Tim O'Reilly's book sale statistics, Ada is in the bottom 10
> > next to Squeak and Rexx:
>
> >http://radar.oreilly.com/2007/05/state-of-the-computer-book-mar-15.html
>
> > 1 Java
> > 2 C#
> > 3 C++
> > 4 VB
> > 5 Ruby
> > 6 VBA
> > 7 Perl
> > 8 Python
> > 9 VBScript
> > 10 Basic
> > 11 Powershell
> > 12 Groovy
> > 13 Objective C
> > 14 Assembler
> > 15 Lisp
> > 16 Lua
> > 17 Tcl
> > 18 Scheme
> > 19 Haskell
> > 20 COBOL
> > 21 C
> > 22 Alice
> > 23 Delphi
> > 24 OCaml
> > 25 JCL
> > 26 RealBASIC
> > 27 Ada
> > 29 Squeak
> > 31 Rexx
> > 32 Fortran
>
> > Specifically, Ada's market share declined to <0.005% compared to, say, 12%
> > for C#. Note that Modula-2, Modula-3 and Oberon are not even on the list.
>
> > OCaml was already ahead of Ada. With the publication of three books on F#,
> > ML variants are now a long long way ahead of Ada.
>
> > >>> It still has more users than all the ML variants combined.
>
> > >> What gave you that impression?
>
> > > The number of programmers employed in application areas that prefer
> > > Ada to other languages.
>
> > Oh look, more unfounded speculation.
>
> > > What gives you your impressions?
>
> > I personally sold more copies of OCaml for Scientists in 2007 than all book
> > sellers sold Ada books combined.
>
> > --
> > Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u-Masquer le texte des messages précédents -
>
> > - Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
>
> > - Afficher le texte des messages précédents -
>
> Hello,
>
> Seriously, I make a simple exercice, find free book about Lisp ...
> It's really easy.
>
> It's not necessary to pay for that.
>
> In contrary, I prefer buy a real tool, not download a .zip in the
> INRIA WebSite, with the hope to obtain the Graal :)
>
> Best Regards,
>
> Christophe
I don't know what's worse: an OCaml spammer or the Lisp snob of lore.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6t8g5$bj0$1@aioe.org>
Christophe wrote:
> Hello,
>
> Seriously, I make a simple exercice, find free book about Lisp ...
> It's really easy.
>
> It's not necessary to pay for that.
>
> In contrary, I prefer buy a real tool, not download a .zip in the
> INRIA WebSite, with the hope to obtain the Graal :)
So you prefer free books and expensive compilers?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 31 juil, 22:49, Jon Harrop <····@ffconsultancy.com> wrote:
> Christophe wrote:
> > Hello,
>
> > Seriously, I make a simple exercice, find free book about Lisp ...
> > It's really easy.
>
> > It's not necessary to pay for that.
>
> > In contrary, I prefer buy a real tool, not download a .zip in the
> > INRIA WebSite, with the hope to obtain the Graal :)
>
> So you prefer free books and expensive compilers?
It's not the subject, you take example of recent book to evaluate
language success.
Of course, with the great number of excellent book speak about Lisp in
free edition, the recent publications are rare.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
comp.lang.ml
ML languages including Standard ML, CAML, Lazy ML, etc. (Moderated)
Langue : Anglais
400 abonnés, Messages per month: 6, Usenet
comp.lang.haskell
416 abonnés, Messages per month: 157, Usenet
comp.lang.lisp
Discussion about LISP.
Langue : Anglais
3856 abonnés, Messages per month: 1608, Usenet
- 0.001% of JH Spam ...
comp.lang.scheme
The Scheme Programming language.
Langue : Anglais
1785 abonnés, Messages per month: 235, Usenet
Best Regards,
Christophe
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6uo40$mlt$1@aioe.org>
Christophe wrote:
> comp.lang.ml
> ML languages including Standard ML, CAML, Lazy ML, etc. (Moderated)
> Langue : Anglais
> 400 abonn�s, Messages per month: 6, Usenet
The highest volume usenet group about OCaml is fa.caml.
> comp.lang.haskell
> 416 abonn�s, Messages per month: 157, Usenet
The highest volume usenet group about Haskell is fa.haskell.
> comp.lang.lisp
> Discussion about LISP.
> Langue : Anglais
> 3856 abonn�s, Messages per month: 1608, Usenet
> - 0.001% of JH Spam ...
>
> comp.lang.scheme
> The Scheme Programming language.
> Langue : Anglais
> 1785 abonn�s, Messages per month: 235, Usenet
Number of recent contributors according to Google Groups:
comp.lang.lisp: 93
fa.caml: 94
fa.haskell: 105
comp.lang.scheme: 107
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Christophe <····················@birdtechnology.net> writes:
> [statistics]
C/USER[26]> (flet ((message/subscriber (g) (/ (getf g :m/m) (getf g :subscribers))))
(map nil (lambda (g)
(format t "~20A ~5D ~6,3F~%" (getf g :group) (getf g :subscribers)
(/ (getf g :m/m) (getf g :subscribers))))
(sort (copy-list '((:group comp.lang.ml :subscribers 400 :m/m 6)
(:group comp.lang.haskell :subscribers 416 :m/m 157)
(:group comp.lang.lisp :subscribers 3856 :m/m 1608)
(:group comp.lang.scheme :subscribers 1785 :m/m 235)))
(function <)
:key (function message/subscriber))))
COMP.LANG.ML 400 0.015
COMP.LANG.SCHEME 1785 0.132
COMP.LANG.HASKELL 416 0.377
COMP.LANG.LISP 3856 0.417
NIL
C/USER[27]>
or we could say that ML is so simple that no ML user has any question
to ask, while Common Lisp is so hard one programmer of two has to ask
a question. Haskell's as hard as lisp. Scheme's simplier than CL.
--
__Pascal Bourguignon__
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6viba$uuj$1@aioe.org>
Pascal J. Bourguignon wrote:
> COMP.LANG.ML 400 0.015
> COMP.LANG.SCHEME 1785 0.132
> COMP.LANG.HASKELL 416 0.377
> COMP.LANG.LISP 3856 0.417
> NIL
> C/USER[27]>
>
> or we could say that ML is so simple that no ML user has any question
> to ask, while Common Lisp is so hard one programmer of two has to ask
> a question. Haskell's as hard as lisp. Scheme's simplier than CL.
Except that the main media for ML are:
. OCaml's mailing lists (the main one is copied to fa.caml on usenet): which
(double counting) have ~4,000 subscribers in total.
. The F# Hub web forum: currently with 5,790 subscribers.
So ML has at ~10,000 subscribers to those media alone, far more than the
numbers you cite. However, many more people will also read comp.lang.lisp
without benefit of Google Groups (as I do) and, consequently, the number of
subscribers recognised by Google is not representative of anything
interesting.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 1 août, 19:50, Jon Harrop <····@ffconsultancy.com> wrote:
> Pascal J. Bourguignon wrote:
> > COMP.LANG.ML 400 0.015
> > COMP.LANG.SCHEME 1785 0.132
> > COMP.LANG.HASKELL 416 0.377
> > COMP.LANG.LISP 3856 0.417
> > NIL
> > C/USER[27]>
>
> > or we could say that ML is so simple that no ML user has any question
> > to ask, while Common Lisp is so hard one programmer of two has to ask
> > a question. Haskell's as hard as lisp. Scheme's simplier than CL.
>
> Except that the main media for ML are:
>
> . OCaml's mailing lists (the main one is copied to fa.caml on usenet): which
> (double counting) have ~4,000 subscribers in total.
>
> . The F# Hub web forum: currently with 5,790 subscribers.
>
> So ML has at ~10,000 subscribers to those media alone, far more than the
> numbers you cite. However, many more people will also read comp.lang.lisp
> without benefit of Google Groups (as I do) and, consequently, the number of
> subscribers recognised by Google is not representative of anything
> interesting.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
Just for information and to close this sterile debate.
Mar 2008 (100d) Feb 2007 (100d) Feb 2006 (100d) Mar 2005 (185d)
Dec 2003 (160 d) Feb 2003 (133 d) Jan 2000 (365d) Jul 1997 (14d?)
posts language posts language posts language posts language
posts language posts language posts language posts language
1 15724 java 18624 c++ 23622 java 39240 java
46418 java 59814 java 229034 java 7294 java
2 14815 c 16974 java 19346 c++ 36763 c++
36633 c++ 44242 c++ 114769 basic 5116 pascal
3 13344 python 15612 c 17502 python 31491 python
28469 python 27054 c 113001 perl 4650 basic
4 12895 c++ 14073 python 15486 c 22787 c
26673 c 24438 python 102261 c++ 2673 c++
5 12577 ruby 14043 ruby 14788 ruby 22115 ruby
21106 perl 23590 perl 79139 javascript 2509 c
6 7945 php 8022 javascript 10569 javascript 20733 perl
15889 clipper 18993 javascript 70135 c 2299 perl
7 7815 javascript 7194 perl 9374 perl 15874 javascript
15245 javascript 17271 clipper 63637 pascal 1732 javascript
8 7266 lisp 6527 php 8505 lisp 14157 lisp
13752 lisp 17131 basic 33567 clipper 968 clarion
9 5121 perl 6483 lisp 7963 php 13786 php
12930 basic 14921 ruby 30925 tcl 955 clipper
10 4789 tcl 6276 labview 6093 labview 12591 clipper
12852 ruby 13174 php 26377 python 792 asm
11 4674 labview 4756 tcl 5488 tcl 11150 basic
12243 clarion 12383 clarion 26374 clarion 760 tcl
12 4159 cobol 3825 fortran 5014 basic 8099 tcl
10468 pascal 12219 lisp 20523 cobol 491 smalltalk
13 3202 fortran 3517 clipper 4696 clipper 7782
cobol 9472 labview 11312 tcl 19784 smalltalk 485
cobol
14 2480 forth 3013 forth 4039 fortran 7225
fortran 9312 tcl 8823 pascal 13761 asm 476
ada
15 2211 clipper 2624 basic 3621 cobol 6714
pascal 6479 ada 7430 labview 13160 lisp 421
fortran
16 2188 idl-pvwave 2029 ada 2768 scheme 6574
labview 6064 cobol 7428 smalltalk 13079 fortran 404
python
17 1781 xharbour 1424 cobol 2180 smalltalk 6062
forth 5618 fortran 5872 fortran 11716 ada 334
eiffel
18 1469 ada 1418 functional 1717 pascal 5798
ada 5593 functional 5189 ada 10581 forth 292
lisp
19 1462 functional 1349 idl-pvwave 1634 forth 4245
smalltalk 3976 scheme 4718 forth 7876 eiffel 286
forth
20 1251 basic 1212 vhdl 1419 vhdl 3035
scheme 3864 smalltalk 4348 cobol 7262 postscript 284
postscript
21 1187 vhdl 1178 smalltalk 1354 ada 2349
vhdl 3823 forth 3416 scheme 6483 functional 260
vrml
22 1145 scheme 1145 scheme 1347 idl-pvwave 2301
asm 3072 asm 3103 asm 6294 vrml 218
scheme
23 861 pascal 1104 pascal 1005 asm 2217 idl-
pvwave 2236 vhdl 2423 vhdl 6035 vhdl 206
apl
24 825 asm 936 verilog 900 pl1 1785
rexx 1764 postscript 2207 functional 4484 idl-pvwave 171
mumps
25 638 awk 828 asm 796 postscript 1725
awk 1703 objective-c 1947 idl-pvwave 4092 scheme 155
vhdl
I don't see ocaml.
And to finish, I will be very surprised the day when I see an editor
lives of ocaml sells :)
Best Regards
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6l5r7$t0a$1@aioe.org>
George Neuner wrote:
> On Sat, 26 Jul 2008 00:10:04 +0100, Jon Harrop <···@ffconsultancy.com>
> wrote:
>> George Neuner wrote:
>>> However Modula2+, Modula-3 and Oberon all *require* GC while
>>> permitting explicit memory management as an advanced option.
>>
>> None of those languages have ever been mainstream.
>
> They are all more mainstream than any ML variant.
I thought this claim of yours might at least turn out to be debatable but,
in fact, those languages are long since extinct. All of those Pascal
derivatives combined are the subject of far less discussion, offer far
fewer jobs with far lower salaries, fewer web pages, no new book titles and
far fewer book sales than any of the main ML variants today. Moreover, it
appears that they have never been remotely close to mainstream. They are
just evolutionary dead ends that are long since extinct.
Consider usenet postings and contributors:
Modula-2
144 usenet posts this year, 31 recent authors
http://groups.google.com/group/comp.lang.modula2/about
Modula-3
6 usenet posts this year, 3 recent authors
http://groups.google.com/group/comp.lang.modula3/about
Oberon
56 usenet posts this year, 41 recent authors
http://groups.google.com/group/comp.lang.oberon/about
Compare to:
OCaml
2,664 usenet posts this year, 94 recent authors
http://groups.google.com/group/fa.caml/about
Haskell
8,334 usenet posts this year, 105 recent authors
http://groups.google.com/group/fa.haskell/about
So ML variants are far more actively discussed than those Pascal
derivatives.
According to Google Trends, nobody has been searching for Modula-2, Modula-3
or Oberon in this context for several years but OCaml, Haskell and F# are
all very active.
According to job sites, there are fewer Modula-2, Modula-3 and Oberon jobs
than OCaml, Haskell and F# jobs. Dice lists zero US jobs for any of
Modula-2, Modula-3 and Oberon. ITJobWatch lists a single job for Modula-2
in the UK and none for Modula-3 and Oberon. Compare to one F# job, three
OCaml jobs and six Haskell jobs listed on those sites.
Moreover, according to ITJobsWatch, the average salary of an OCaml
programmer is over twice that of a Modula-2 programmer and demand for OCaml
programmers in the UK is 4x higher than that of all of the languages you
listed combined:
http://www.itjobswatch.co.uk/jobs/uk/ocaml.do
http://www.itjobswatch.co.uk/jobs/uk/modula-2.do
According to Google, there are many more web pages about OCaml, Haskell and
even F# programming than all of Modula-2, Modula-3 and Oberon combined,
even though they are much older.
So even your statement that "Modula-2, Modula-3 and Oberon are all more
mainstream than any ML variant" is not correct. Given this, your claim that
such languages are more mainstream than C# is clearly absurd.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
P� Mon, 28 Jul 2008 21:15:15 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
>
> Modula-2
> 144 usenet posts this year, 31 recent authors
> http://groups.google.com/group/comp.lang.modula2/about
>
> Modula-3
> 6 usenet posts this year, 3 recent authors
> http://groups.google.com/group/comp.lang.modula3/about
>
> Oberon
> 56 usenet posts this year, 41 recent authors
> http://groups.google.com/group/comp.lang.oberon/about
>
> Compare to:
>
> OCaml
> 2,664 usenet posts this year, 94 recent authors
> http://groups.google.com/group/fa.caml/about
>
> Haskell
> 8,334 usenet posts this year, 105 recent authors
> http://groups.google.com/group/fa.haskell/about
>
All you have proven is that they use groups less.
In the numbers of actual users they are far supperior.
--------------
John Thingstad
On 28 Lug, 22:47, "John Thingstad" <·······@online.no> wrote:
> På Mon, 28 Jul 2008 21:15:15 +0200, skrev Jon Harrop
> <····@ffconsultancy.com>:
>
>
>
>
>
> > Modula-2
> > 144 usenet posts this year, 31 recent authors
> > http://groups.google.com/group/comp.lang.modula2/about
>
> > Modula-3
> > 6 usenet posts this year, 3 recent authors
> > http://groups.google.com/group/comp.lang.modula3/about
>
> > Oberon
> > 56 usenet posts this year, 41 recent authors
> > http://groups.google.com/group/comp.lang.oberon/about
>
> > Compare to:
>
> > OCaml
> > 2,664 usenet posts this year, 94 recent authors
> > http://groups.google.com/group/fa.caml/about
>
> > Haskell
> > 8,334 usenet posts this year, 105 recent authors
> > http://groups.google.com/group/fa.haskell/about
>
> All you have proven is that they use groups less.
> In the numbers of actual users they are far supperior.
Do you think that there is no correlation?
And anyway why did you snip the part about job positions?
I understand that you people don't like him, but I think he has a
point here.
In article
<····································@m45g2000hsb.googlegroups.com>,
Vend <······@virgilio.it> wrote:
> On 28 Lug, 22:47, "John Thingstad" <·······@online.no> wrote:
> > P� Mon, 28 Jul 2008 21:15:15 +0200, skrev Jon Harrop
> > <····@ffconsultancy.com>:
> >
> >
> >
> >
> >
> > > Modula-2
> > > 144 usenet posts this year, 31 recent authors
> > > http://groups.google.com/group/comp.lang.modula2/about
> >
> > > Modula-3
> > > 6 usenet posts this year, 3 recent authors
> > > http://groups.google.com/group/comp.lang.modula3/about
> >
> > > Oberon
> > > 56 usenet posts this year, 41 recent authors
> > > http://groups.google.com/group/comp.lang.oberon/about
> >
> > > Compare to:
> >
> > > OCaml
> > > 2,664 usenet posts this year, 94 recent authors
> > > http://groups.google.com/group/fa.caml/about
> >
> > > Haskell
> > > 8,334 usenet posts this year, 105 recent authors
> > > http://groups.google.com/group/fa.haskell/about
> >
> > All you have proven is that they use groups less.
> > In the numbers of actual users they are far supperior.
>
> Do you think that there is no correlation?
> And anyway why did you snip the part about job positions?
>
> I understand that you people don't like him, but I think he has a
> point here.
The point is that it is totally irrelevant for comp.lang.lisp readers
how many people use groups/mailing lists for OCaml or Oberon.
You guys may want to move this discussion to comp.lang.misc or
alt.timewasters .
Please take Mr. Frog with you, who now posts most of his drivel
to comp.lang.lisp - still without any relevant content.
--
http://lispm.dyndns.org/
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6llun$73n$1@aioe.org>
Vend wrote:
> On 28 Lug, 22:47, "John Thingstad" <·······@online.no> wrote:
>> All you have proven is that they use groups less.
>> In the numbers of actual users they are far supperior.
>
> Do you think that there is no correlation?
> And anyway why did you snip the part about job positions?
... and search terms, book titles, book sales and web pages.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
> According to job sites, there are fewer Modula-2, Modula-3 and Oberon jobs
> than OCaml, Haskell and F# jobs. Dice lists zero US jobs for any of
> Modula-2, Modula-3 and Oberon. ITJobWatch lists a single job for Modula-2
> in the UK and none for Modula-3 and Oberon. Compare to one F# job, three
> OCaml jobs and six Haskell jobs listed on those sites.
>
Ouch, looks like none of us functional types are doing so well here.
You should really include a Lisp metric since after all this is
comp.lang.lisp. I also think it is funny after reading many posts of
yours with quotes such as: "OCaml certainly has vastly more industrial
users than Haskell.", that by your own metric there are more paying
Haskell jobs out there than OCaml and F# combined.
Oh and yes I agree with you that C# is mainstream.
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6pskp$mku$1@aioe.org>
parnell wrote:
>> According to job sites, there are fewer Modula-2, Modula-3 and Oberon
>> jobs than OCaml, Haskell and F# jobs. Dice lists zero US jobs for any of
>> Modula-2, Modula-3 and Oberon. ITJobWatch lists a single job for Modula-2
>> in the UK and none for Modula-3 and Oberon. Compare to one F# job, three
>> OCaml jobs and six Haskell jobs listed on those sites.
>>
> Ouch, looks like none of us functional types are doing so well here.
> You should really include a Lisp metric since after all this is
> comp.lang.lisp.
Demand for Lisp programmers is not increasing and salaries are lower
(�44-53k):
http://www.itjobswatch.co.uk/jobs/uk/lisp.do
> I also think it is funny after reading many posts of
> yours with quotes such as: "OCaml certainly has vastly more industrial
> users than Haskell.", that by your own metric there are more paying
> Haskell jobs out there than OCaml and F# combined.
Yes. Digging a little deeper it seems that industrial projects using Haskell
rarely come to fruition. For example, Red Nucleus advertised Haskell jobs
last year and then went bankrupt.
In contrast, Jane St. Capital, XenSource, Microsoft, Plectix, Asocom, Wink,
Intellifactory and SkyDeck all advertised OCaml or F# jobs over the past
year and all are continuing to expand their efforts.
> Oh and yes I agree with you that C# is mainstream.
Good. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 30 juil, 16:09, Jon Harrop <····@ffconsultancy.com> wrote:
> parnell wrote:
> >> According to job sites, there are fewer Modula-2, Modula-3 and Oberon
> >> jobs than OCaml, Haskell and F# jobs. Dice lists zero US jobs for any of
> >> Modula-2, Modula-3 and Oberon. ITJobWatch lists a single job for Modula-2
> >> in the UK and none for Modula-3 and Oberon. Compare to one F# job, three
> >> OCaml jobs and six Haskell jobs listed on those sites.
>
> > Ouch, looks like none of us functional types are doing so well here.
> > You should really include a Lisp metric since after all this is
> > comp.lang.lisp.
>
> Demand for Lisp programmers is not increasing and salaries are lower
> (£44-53k):
>
> http://www.itjobswatch.co.uk/jobs/uk/lisp.do
>
> > I also think it is funny after reading many posts of
> > yours with quotes such as: "OCaml certainly has vastly more industrial
> > users than Haskell.", that by your own metric there are more paying
> > Haskell jobs out there than OCaml and F# combined.
>
> Yes. Digging a little deeper it seems that industrial projects using Haskell
> rarely come to fruition. For example, Red Nucleus advertised Haskell jobs
> last year and then went bankrupt.
>
> In contrast, Jane St. Capital, XenSource, Microsoft, Plectix, Asocom, Wink,
> Intellifactory and SkyDeck all advertised OCaml or F# jobs over the past
> year and all are continuing to expand their efforts.
>
> > Oh and yes I agree with you that C# is mainstream.
>
> Good. :-)
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
Hello,
What is the price of oCaml ... 0£ 0$ O€
Ha ... !!! Ok ...
The technology whose value is null is certainly adopted easily but I
prefer real tools as Allegro or LispWorks.
And I am not alone.
Of course, you don't know how are used Allegro for example, It's no in
public area.
But as Allegro customer, I can say your ocaml is just a gadget,
perhaps cool, but is't that's all.
I will be surprised to see the ocaml success, if this cost 8000$ per
licence ??? :)
Best Regards,
Christophe
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6t899$b5u$1@aioe.org>
Christophe wrote:
> Hello,
>
> What is the price of oCaml
A commercial license for OCaml costs around ?1,500 and OCaml programmers
cost around ?75-100k p.a.
> Of course, you don't know how are used Allegro for example, It's no in
> public area.
Indeed, Franz' Allegro CL appears to be unsuccessful in all areas. Hence
they migrated to Java in order to turn a profit and keep the business
afloat.
The LispWorks is probably your next example. Their product has a tale of
bankruptcy having changed hands four times in 14 years and is now sold by a
company that is growing old in an academic incubation unit (the St. John's
Innovation Centre in Cambridge).
I am not surprised by these absent success stories though. Keeping a company
afloat by selling a platform of your own invention is hard enough but
becoming a success with no value add over an antique language is
impossible.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jon Harrop <···@ffconsultancy.com> writes:
> Christophe wrote:
>
>> Of course, you don't know how are used Allegro for example, It's no in
>> public area.
>
> Indeed, Franz' Allegro CL appears to be unsuccessful in all areas.
As with most everything else you've said on this forum, you are
spouting off clueless guesses.
> Hence
> they migrated to Java in order to turn a profit and keep the business
> afloat.
Allegro CL has been talking to C and Fortran since its inception in
the late 1980s. Does that mean we've migrated to C or Fortran? Of
course not. It only means that we know the value of having our Common
Lisp based products communicating with other important languages.
Nowadays, languages to communicate with include XML, Prolog, and yes,
even Java, among others. Interestingly, this list does not include ML
or Ocaml. Perhaps that's why you simply don't run across our
products.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Hence
>> they migrated to Java in order to turn a profit and keep the business
>> afloat.
>
> Allegro CL has been talking to C and Fortran since its inception in
> the late 1980s. Does that mean we've migrated to C or Fortran? Of
> course not.
What? I just spent an hour adding the steaming coffee cup logo to the
splash screen for my AllegroCL Inside(tm) Algebra software!
Damn you, Jon Harrop! Damn you!
kenny
On 1 ago, 04:17, Duane Rettig <·····@franz.com> wrote:
> Allegro CL has been talking to C and Fortran since its inception in
> the late 1980s. Does that mean we've migrated to C or Fortran? Of
> course not. It only means that we know the value of having our Common
> Lisp based products communicating with other important languages.
> Nowadays, languages to communicate with include XML, Prolog, and yes,
> even Java, among others. Interestingly, this list does not include ML
> or Ocaml. Perhaps that's why you simply don't run across our
> products.
Pure finesse. :)
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g6unjn$jkf$1@aioe.org>
Duane Rettig wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Hence they migrated to Java in order to turn a profit and keep the
>> business afloat.
>
> Allegro CL has been talking to C and Fortran since its inception in
> the late 1980s. Does that mean we've migrated to C or Fortran? Of
> course not. It only means that we know the value of having our Common
> Lisp based products communicating with other important languages.
> Nowadays, languages to communicate with include XML, Prolog, and yes,
> even Java, among others.
What proportion of your code base is written in Java?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 1 ago, 07:13, Jon Harrop <····@ffconsultancy.com> wrote:
> What proportion of your code base is written in Java?
Hey, this is Java we're talking about! Even interfacing to it
probably demands a lot of glue code...
Jon Harrop <···@ffconsultancy.com> writes:
> Duane Rettig wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> Hence they migrated to Java in order to turn a profit and keep the
>>> business afloat.
>>
>> Allegro CL has been talking to C and Fortran since its inception in
>> the late 1980s. Does that mean we've migrated to C or Fortran? Of
>> course not. It only means that we know the value of having our Common
>> Lisp based products communicating with other important languages.
>> Nowadays, languages to communicate with include XML, Prolog, and yes,
>> even Java, among others.
>
> What proportion of your code base is written in Java?
In AllegroGraph, we provide a server, written entirely in Lisp, and
various clients; a lisp client (obviously written in lisp), a Python
client, an http client, and a Java client.
1. Total Java code in server: 0%.
2. Total Java code in server + clients: about 2%.
We also have other products that talk to Java, including some Java
code, mostly glue. Most of the rest of our code is Lisp. You like
frogs, I like turtles: lisp turtles, all the way down.
3. Total Java code in Franz's code base: less than 1%.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 1 août, 12:13, Jon Harrop <····@ffconsultancy.com> wrote:
> Duane Rettig wrote:
> > Jon Harrop <····@ffconsultancy.com> writes:
> >> Hence they migrated to Java in order to turn a profit and keep the
> >> business afloat.
>
> > Allegro CL has been talking to C and Fortran since its inception in
> > the late 1980s. Does that mean we've migrated to C or Fortran? Of
> > course not. It only means that we know the value of having our Common
> > Lisp based products communicating with other important languages.
> > Nowadays, languages to communicate with include XML, Prolog, and yes,
> > even Java, among others.
>
> What proportion of your code base is written in Java?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
Hello,
Who is the equivalent of JLinker for ocaml ?
Best Regards,
Christophe
From: Jon Harrop
Subject: Re: The Fundamental Confusion of Xah
Date:
Message-ID: <g70pv3$bj3$1@aioe.org>
Christophe wrote:
> Hello,
>
> Who is the equivalent of JLinker for ocaml ?
CamlJava, I believe.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 2 août, 07:06, Jon Harrop <····@ffconsultancy.com> wrote:
> Christophe wrote:
> > Hello,
>
> > Who is the equivalent of JLinker for ocaml ?
>
> CamlJava, I believe.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
Hello,
Actual version of CamlJava : 0.3 ...
Best Regards,
Christophe
On Aug 1, 12:13 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Duane Rettig wrote:
> > Jon Harrop <····@ffconsultancy.com> writes:
> >> Hence they migrated to Java in order to turn a profit and keep the
> >> business afloat.
>
> > Allegro CL has been talking to C and Fortran since its inception in
> > the late 1980s. Does that mean we've migrated to C or Fortran? Of
> > course not. It only means that we know the value of having our Common
> > Lisp based products communicating with other important languages.
> > Nowadays, languages to communicate with include XML, Prolog, and yes,
> > even Java, among others.
>
> What proportion of your code base is written in Java?
OMG! Froggy's turning into gavino!
On 31 juil, 22:46, Jon Harrop <····@ffconsultancy.com> wrote:
> Christophe wrote:
> > Hello,
>
> > What is the price of oCaml
>
> A commercial license for OCaml costs around ?1,500 and OCaml programmers
> cost around ?75-100k p.a.
>
> > Of course, you don't know how are used Allegro for example, It's no in
> > public area.
>
> Indeed, Franz' Allegro CL appears to be unsuccessful in all areas. Hence
> they migrated to Java in order to turn a profit and keep the business
> afloat.
>
It's wrong, and the global offer of Franz with Allegro is significaly
superior at ocaml.
Franz offers in prime an awesome support, it's not the case with
ocaml. And, when I see the attitude of ocaml fan, I don't have any
interested to work with.
> The LispWorks is probably your next example. Their product has a tale of
> bankruptcy having changed hands four times in 14 years and is now sold by a
> company that is growing old in an academic incubation unit (the St. John's
> Innovation Centre in Cambridge).
>
Lispworks is a very good product, and I know a lot of customers that
are very happy with it.
> I am not surprised by these absent success stories though. Keeping a company
> afloat by selling a platform of your own invention is hard enough but
> becoming a success with no value add over an antique language is
> impossible.
>
It's totally wrong, but I can say that recent success stories of
Allegro are a great help for us to improve our capacity to present new
technologies.
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
Just for information : "Les compilateurs Caml développés à l'INRIA
sont des logiciels libres (« Open Source »). Ils sont disponibles
gratuitement. "
Gratuitement = free of charge.
Best Regards,
Christophe
P� Thu, 31 Jul 2008 22:46:13 +0200, skrev Jon Harrop
<···@ffconsultancy.com>:
> Christophe wrote:
>> Hello,
>>
>> What is the price of oCaml
>
> A commercial license for OCaml costs around ?1,500 and OCaml programmers
> cost around ?75-100k p.a.
>
>> Of course, you don't know how are used Allegro for example, It's no in
>> public area.
>
> Indeed, Franz' Allegro CL appears to be unsuccessful in all areas. Hence
> they migrated to Java in order to turn a profit and keep the business
> afloat.
>
> The LispWorks is probably your next example. Their product has a tale of
> bankruptcy having changed hands four times in 14 years and is now sold
> by a
> company that is growing old in an academic incubation unit (the St.
> John's
> Innovation Centre in Cambridge).
>
> I am not surprised by these absent success stories though. Keeping a
> company
> afloat by selling a platform of your own invention is hard enough but
> becoming a success with no value add over an antique language is
> impossible.
>
I take it you haven't heard of their next product A# ? ;)
(I heard you got a F..)
--------------
John Thingstad
Jon Harrop wrote:
> Christophe wrote:
>> Hello,
>>
>> What is the price of oCaml
>
> A commercial license for OCaml costs around ?1,500 and OCaml programmers
> cost around ?75-100k p.a.
>
>> Of course, you don't know how are used Allegro for example, It's no in
>> public area.
>
> Indeed, Franz' Allegro CL appears to be unsuccessful in all areas. Hence
> they migrated to Java in order to turn a profit and keep the business
> afloat.
>
> The LispWorks is probably your next example. Their product has a tale of
> bankruptcy having changed hands four times in 14 years and is now sold by a
> company that is growing old in an academic incubation unit (the St. John's
> Innovation Centre in Cambridge).
>
> I am not surprised by these absent success stories though. Keeping a company
> afloat by selling a platform of your own invention is hard enough but
> becoming a success with no value add over an antique language is
> impossible.
LOLROTFLBTC
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
> Indeed, Franz' Allegro CL appears to be unsuccessful in all areas. Hence
> they migrated to Java in order to turn a profit and keep the business
> afloat.
Please, when in doubt, be simply assumptotic, as you always do!
And stop making sense, enough with it!
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> On 16 Jul., 07:33, ·······@gmail.com" <······@gmail.com> wrote:
>
>
>> Dear Rainer Joswig,
>
> Dear Xah!
>
>>
>> Rainer wrote:
>> > Code is data and data is code:
>>
>> > Lisp uses the same external s-expression representation of Lisp
>> > data for Lisp code.
>> > Lisp programs can read, print and manipulate Lisp code like any
>> > other Lisp data.
>>
>> Yeah, and?
>>
>> I wrote: «A regular nested syntax, makes it possible to do systematic
>>
>> source code transformation in a way that's also trivial to implement.
>> There are important consequences. Some of the examples are: lisp's
>> macros, structural pattern matching, term rewriting, source code dual
>> functioning as markup lang for presentation (e.g. word-processor,
>> Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
>> general all benefits of XML, on-the-fly source code “formatting” for a
>> automatic, uniform, universal, source code display (aka “coding style
>> convention”).»
>>
>> Did you disagree with this? Further, your statement is basically
>> equivalent with mine, and, if i may argue, mine is more general and
>> clear, stated in a way understandable to any programer, and applicable
>> to any langs, as opposed to the lisp's in-world view with its fucking
>> readers and printers and motherfucking “objects”. Are you saying my
>> statement is wrong?
>
> It's missing the core of the issue. code as data is not about
> syntax. It's a question a simple representation of code and a
> function from external source to code as data (-> READ) and code as
> data to external source (-> PRINT). There are other syntax variants
> (say, like XML) that can be used for that. s-expressions are
> relatively primitive and easy to implement/use. That's one of the
> features of Lisp, that this mechanism is relatively simple (compare
> that to the spec of XML which includes additional things like
> Schemas, but no computation).
C has a syntax for data:
Something s={{1,2,"abc",{3,4}},42};
Assuming the right header, and/or the right language extension, in C
we could write programs as data:
Form form={"if",{"a","==",42},
{"printf",{"\"got it\\n\""}},
"else",
{"printf",{"\"a=%d\\n\"","a"}}};
void example(){
eval(form);
}
Do you still think syntax doesn't matter for the usability of
program <=> data <=> program?
Notice how when we write programs (in any programming language), the
separator of terms in the sentences (statements, expressions) is the
space:
if a=b then writeln('Hello');
(if (= a b) (writeln "Hello"))
vs.
{if,{a,=,b},{writeln,{"Hello"}}}
Notice also how the first iteration of LISP used commas to separate
elements in list. We could have spaces in symbol names:
(WITH OPEN FILE,(MY FILE,SRC.TXT),(READ,MY FILE))
happily, quickly enough the inventors of lisp realized it was better
(for pgm<=>data) to use the space rather than the comma.
> Ok, my point was that you were missing the core of the issue when
> insisting on syntax. It's just easy in Lisp, because it is so
> 'primitive'.
Well, it's not because lisp syntax is easy and primitive that it is
not a determinant factor in the quality of the language.
> You were talking about Lisp and you were posting to comp.lang.lisp .
> Emacs Lisp is mainly just a subset of Common Lisp (no closures, no
> CLOS, ...) anyway.
It is not a subset of Common Lisp in the legal sense. The problem
being that (declare (special var)) is not mandatory. But there is a
subset of emacs lisp that is a subset of Common Lisp indeed.
http://www.lispworks.com/documentation/HyperSpec/Body/01_g.htm
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
>
> > On 16 Jul., 07:33, ·······@gmail.com" <······@gmail.com> wrote:
> >
> >
> >> Dear Rainer Joswig,
> >
> > Dear Xah!
> >
> >>
> >> Rainer wrote:
> >> > Code is data and data is code:
> >>
> >> > Lisp uses the same external s-expression representation of Lisp
> >> > data for Lisp code.
> >> > Lisp programs can read, print and manipulate Lisp code like any
> >> > other Lisp data.
> >>
> >> Yeah, and?
> >>
> >> I wrote: «A regular nested syntax, makes it possible to do systematic
> >>
> >> source code transformation in a way that's also trivial to implement.
> >> There are important consequences. Some of the examples are: lisp's
> >> macros, structural pattern matching, term rewriting, source code dual
> >> functioning as markup lang for presentation (e.g. word-processor,
> >> Mathematica's “Notebook”), mathematical markup (e.g. MathML), in
> >> general all benefits of XML, on-the-fly source code “formatting” for a
> >> automatic, uniform, universal, source code display (aka “coding style
> >> convention”).»
> >>
> >> Did you disagree with this? Further, your statement is basically
> >> equivalent with mine, and, if i may argue, mine is more general and
> >> clear, stated in a way understandable to any programer, and applicable
> >> to any langs, as opposed to the lisp's in-world view with its fucking
> >> readers and printers and motherfucking “objects”. Are you saying my
> >> statement is wrong?
> >
> > It's missing the core of the issue. code as data is not about
> > syntax. It's a question a simple representation of code and a
> > function from external source to code as data (-> READ) and code as
> > data to external source (-> PRINT). There are other syntax variants
> > (say, like XML) that can be used for that. s-expressions are
> > relatively primitive and easy to implement/use. That's one of the
> > features of Lisp, that this mechanism is relatively simple (compare
> > that to the spec of XML which includes additional things like
> > Schemas, but no computation).
>
>
> C has a syntax for data:
I know. Lot's of programming languages have syntax for data.
>
> Something s={{1,2,"abc",{3,4}},42};
>
> Assuming the right header, and/or the right language extension, in C
> we could write programs as data:
>
> Form form={"if",{"a","==",42},
> {"printf",{"\"got it\\n\""}},
> "else",
> {"printf",{"\"a=%d\\n\"","a"}}};
>
> void example(){
> eval(form);
> }
>
>
>
> Do you still think syntax doesn't matter for the usability of
> program <=> data <=> program?
Do I think that? Of course it matters for usability.
Would I rather write
(a b c)
or
<s-expression>
<atom>a</atom>
<atom>b</atom>
<atom>c</atom>
</s-expression>
and use the whole XML machinery?
> Notice how when we write programs (in any programming language), the
> separator of terms in the sentences (statements, expressions) is the
> space:
>
> if a=b then writeln('Hello');
>
> (if (= a b) (writeln "Hello"))
> vs.
> {if,{a,=,b},{writeln,{"Hello"}}}
>
>
> Notice also how the first iteration of LISP used commas to separate
> elements in list. We could have spaces in symbol names:
>
> (WITH OPEN FILE,(MY FILE,SRC.TXT),(READ,MY FILE))
>
> happily, quickly enough the inventors of lisp realized it was better
> (for pgm<=>data) to use the space rather than the comma.
Depends on the use case. Now you write:
(|Albert Einstein| |Max Planck| |Marie Curie|)
Instead of
(Albert Einstein, Max Planck, Marie Curie)
> > Ok, my point was that you were missing the core of the issue when
> > insisting on syntax. It's just easy in Lisp, because it is so
> > 'primitive'.
>
> Well, it's not because lisp syntax is easy and primitive that it is
> not a determinant factor in the quality of the language.
>
>
>
> > You were talking about Lisp and you were posting to comp.lang.lisp .
> > Emacs Lisp is mainly just a subset of Common Lisp (no closures, no
> > CLOS, ...) anyway.
>
> It is not a subset of Common Lisp in the legal sense. The problem
> being that (declare (special var)) is not mandatory. But there is a
> subset of emacs lisp that is a subset of Common Lisp indeed.
> http://www.lispworks.com/documentation/HyperSpec/Body/01_g.htm
I'm not talking about the legal sense. There is no way to get
a legal label for a language to be a subset of CL.
Emacs Lisp is a subset 'conceptually' - minus some 'minor'
differences. Many Emacs Lisp programs can be translated to Common Lisp
(minus the Emacs Lisp library) without much change. There
is some mismatch with some data structures.
There are other related languages which are more like
'subsets' of Common Lisp: SubL, CL0, ...
--
http://lispm.dyndns.org/
On Jul 16, 11:29 am, Rainer Joswig <······@lisp.de> wrote:
>
>
> Depends on the use case. Now you write:
>
> (|Albert Einstein| |Max Planck| |Marie Curie|)
>
> Instead of
>
> (Albert Einstein, Max Planck, Marie Curie)
Show a disposition towards balance, harmony, Yin-Yang - innate
features of a true hacker, I'd say!
;-)
--agt
On 13 juil, 16:53, ·······@gmail.com" <······@gmail.com> wrote:
> Fundamental Problems of Lisp
>
> Perm url:http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> plain text version follows.
>
> ----------------------------------------------
> ...
>
> Since i'm writing... n i wrote a lot in the past on diverse issues
> scattered
> in various essays... i'll sum some fundamental problems of lisp.
>
> • Lisp relies on a regular nested syntax. However, the lisp syntax has
> several
> irregularities, that reduces such syntax's power and confuses the
> language
> semantics. (i.e. those «' # ; ` ,» chars.) (and whenever i tried to
> get some
> technical answer about this to clarify at least my own understanding,
> the lisp
> fuckheads muck and obfuscate the truth)
>
> • Lisp's irregular syntax those «' # ; ` ,» things, are practically
> confusing
> and made the lang less powerful. i.e. in elisp, there's no form of
> comments in
> matching delimiters (and consequently no nested comment). The reliance
> on EOL
> chars as part of the syntax semantics is one of the major fuckup to
> the power
> of pure nested syntax.
>
> • Lisp relies on a regular nested syntax. Because of such regularity
> of the
> syntax, it has very powerful consequences, at least theoretically.
> (and
> practically, lispers realized just one: the lisp macros) For example,
> since
> the syntax is regular, one could easily have alternative, easier to
> read
> syntaxes as a layer. (the concept is somewhat known in early lisp as
> M-expression) Mathematica took this advantage (probably independent of
> lisp's
> influence), so that you really have easy to read syntax, yet fully
> retain the
> regular form advantages. Lisp, on the other hand, such alternative
> syntax has
> been done and tried here and there in various forms or langs, but
> never caught
> on due to largely social reasons. Part of these reasons are political.
> (thanks
> to, in part, the Lisp old hats that suppresses it.)
>
> • One of the advantage of pure fully functional syntax is that a
> programer
> should never, ever need to format his source code (i.e. pressing tabs,
> returns) in coding, and save the hundreds hours of labor, guides,
> tutorials,
> advices, publications, editor tools, on what's known as “coding style
> convention”, because the editor can trivially reformat the source code
> on the
> fly based on a simple lexical scan. This is done in Mathematica
> version 3
> (~1996). In coding elisp, i'm pained to no ends by the manual process
> of
> formatting lisp code. The lisp community, established a particular way
> of
> formatting lisp code as exhibited in emacs's lisp modes and written
> guides in
> conventions. The recognization of such convention further erode any
> possibility and awareness of automatic, uniform, formatting.
>
> • Lisp relies on a regular nested syntax. One of the power of such
> pure syntax
> is that you could build up layers on top of it, so that the source
> code can
> function as markup of conventional mathematical notations (i.e. LaTeX)
> and or
> as a word-processing-like file that can contain structures, images,
> yet lose
> practical nothing. This is done in Mathematica in ~1996 with release
> of
> Mathematica version 3.
>
> Further readings:
>
> * The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional
> Notations
> * The Harm of Hard-wrapping Lines
> * A Text Editor Feature: Syntax Tree Walk
> * A Simple Lisp Code Formatter
>
> The above are some of the damages lispers has done to themselfs, with
> respect
> to its nested functional syntax. The other major one is the cons
> business.
>
> • Lisp at core is based on functional programing on lists. This is
> very
> powerful. However, for historical reasons, lisp's list is based on the
> hardware concept of “cons” cell. This fundamentally handicapped the
> advantages
> of power of list processing.
>
> Lisp being historically based the cons for like 2 or 3 decades. The
> cons (and
> cdr, car, caadar etc) are fundamentally rooted in the lisp langs, is
> thus not
> something that can be easily fixed. Quite unfortunate. However, this
> situation
> could be improved. But, whenever i discuss this, you can see that the
> lisper
> slaves here, their mentality, prevents any possible improvement. (in
> general,
> this is because, lispers usually do not have serious experience or
> investment
> in other functional langs, such as Mathematica, Haskell, etc.)
>
> One of the myth that are quickly embedded into budding lispers, is
> that cons
> are powerful. Powerful my ass. It is powerful in the sense any
> assembly lang
> is powerful. Lisp's cons is perhaps the greatest fuck up in the
> history of
> computer languages.
>
> Further readings:
>
> * Lisp's List Problem
> * My First Encounter And Impression Of Lisp
> * The Jargon “Lisp1” vs “Lisp2”
>
> Will Lisp ever be Popular?
>
> Mathematica today sells for over 2 thousands dollars. Its sales
> record,
> throughout its history, is probably more than ALL commercial lisps
> combined.
> Such a illuminating social fact, in not known in lisp communities.
> These
> fuckheads thinks that lisp is more popular.
>
> 10 years ago, in the dot come days (~1998), where Java, Javascript,
> Perl are
> screaming the rounds. It was my opinion, that lisp will inevitably
> become
> popular in the future, simply due to its inherent superior design,
> simplicity,
> flexibility, power, whatever its existing problems may be. Now i don't
> think
> that'll ever happen as is. Because, due to the tremendous
> technological
> advances, in particular in communication (i.e. the internet and its
> consequences, e.g. Wikipedia, youtube, youporn, social networks sites,
> Instant
> chat, etc) computer languages are proliferating like never before.
> (i.e.
> because the abundance of tools, libraries, parsers, existance of
> infrastructure) New langs, basically will have all the advantages of
> lisps or
> lisp's fundamental concepts or principles. I see that, perhaps in the
> next
> decade, as communication technologies further hurl us forward, the
> proliferation of langs will reduce to a trend of consolidation (e.g.
> fueled by
> virtual machines such as Microsoft's .NET. (and, btw, the breaking of
> social
> taboo of cross communication led by Xah Lee)).
>
> There is one slight hope for Lisp the lang as we understood it, and
> that is
> emacs lisp. Due to, it being deeply rooted in the industry as a
> powerful text
> editor, and the embedded lisp have major practical impact in getting
> people to
> know lisp and also actually use it for practical need. (this
> satisfying
> prospect is however mar'd by the tech geekers. e.g. the Common
> Lispers, and
> Scheme Lispers, perennially inject snide and sneer at emacs lisp that
> harms
> its progress, while the fucking emacs priests, want to coffin emacs
> perpetually in its 1980s UI and terminologies.)
>
> Xah
> ∑http://xahlee.org/
>
> ☄
I beg your pardon in advance but, your post is just a joke.
Do you think really that they only one syntax in Lisp ? I hope no !
The real power of Lisp is : it's a pure system to create DSL.
Best regards, Christophe
P� Sun, 13 Jul 2008 16:53:38 +0200, skrev ······@gmail.com
<······@gmail.com>:
comp.lang.lisp is a group for Common Lisp.
Many of us have hundreds of thousands of lines of code written in that
language.
Some of us need to get work done and have no time to wine over minor
improvements.
If it breaks the code base it is not welcome.
That does not mean I do not want a cleaner more coherent lisp.
I have studied Hascell, ML, OCALM and Mathematica too.
But it wouldn't be Common Lisp and I would discuss it on
comp.lang.functional.
Besides your bad english and lack of respect, etiquette and manners makes
it less than rewarding to discuss with you.
--------------
John Thingstad
John,
don't begin, to be a lisp moron.
John wrote:
« Some of us need to get work done and have no time to wine over minor
improvements. If it breaks the code base it is not welcome. »
Seeds of ideas, code, got mutilated by Common Lisp fuckheads, before
it even had a chance for proper discussion.
Like, suppose you are thinking about some issues of a greener planet.
Before you begin, some Bush fuckhead shouts: “No, changing human habit
is not likely. We want our trucks.”.
That's what you are doing now, not unlike, the gazillion Common Lisp
fuckheads are doing in “comp.lang.lisp”.
John wrote:
«comp.lang.lisp is a group for Common Lisp.»
«But it wouldn't be Common Lisp and I would discuss it on
comp.lang.functional.»
comp.lang.lisp is a group for lisp, not just for Common Lisp.
Go create your own “comp.lang.lisp.common”.
«Besides your bad english and lack of respect, etiquette and manners
makes it less than rewarding to discuss with you.»
The respect in my response to people's writings is based on this
ratio: (knowledge+love)/disrespectfulness exhibited in their posts.
(for example, if disrespectfulness is constant, then the greater their
knowledge and love, the greater will be my respect for them. Suppose
the knowledge+love is constant, then the greater their outward
disrespect, will gain greater of my disrepsect. If their knowledge
+love is greater than their outward disrespect, then overall they
still gain my respect. However, if their knowledge+love is less than
their show of disrespectfulness, then i dispise them.)
We all have different levels of IQs, environment we grew up, areas of
expertise, weaknesses. No human animal, knows all (in fact in modern
word hardly any human animal knew 1/10^googolplex percent of
knowledge). This is when discussion, comes in. When you know
something, and you sincerely believe you know it, dont be shy. When
you don't know something, don't fucking be a ass. The problem with
most sophomorons, is not knowing the extent of their ignorance.
When i encounter tech geekers, usually they don't know shit of the
subject relative to me, yet they are so aggressive, militant, to the
point to ban me or whatnot (e.g. eliminating any possible discussion
or explanation i could contribute or defend of their accusations).
That is when, you begin to see fuckheads and motherfucks sprinkled in
my writings.
My impression of you, is that you are usally if not always, on topic,
post with substance, and i haven't seen you going into wild defensive
drivels or sputtering moronic language xyz dogma like most common
lispers do.
You should buy me pizza.
O, i almost forgot, you wrote: «Besides your bad english....».
The level of badness of my english, is proportional to the number of
grammar pundits in the world (you can see them slaving in
alt.usage.english, for example). When society ceases to be influenced
by these morons, my english might become something you would
characterize as orthodox.
Further readings:
“Language and English”
http://xahlee.org/Periodic_dosage_dir/bangu/bangu.html
--------------------
PS 2 recently posted message here that touched on netiquette, is
archived permanently here:
What Do Tech Geeking Morons Want?
http://xahlee.org/UnixResource_dir/writ/techgeeking_morons.html
Aloofness vs Approachable
http://xahlee.org/UnixResource_dir/writ/aloof_vs_approachable.html
Xah
∑ http://xahlee.org/
☄
On Jul 15, 12:04 pm, "John Thingstad" <·······@online.no> wrote:
> På Sun, 13 Jul 2008 16:53:38 +0200, skrev ······@gmail.com
> <······@gmail.com>:
>
> comp.lang.lisp is a group for Common Lisp.
> Many of us have hundreds of thousands of lines of code written in that
> language.
> Some of us need to get work done and have no time to wine over minor
> improvements.
> If it breaks the code base it is not welcome.
> That does not mean I do not want a cleaner more coherent lisp.
> I have studied Hascell, ML, OCALM and Mathematica too.
> But it wouldn't be Common Lisp and I would discuss it on
> comp.lang.functional.
>
> Besides your bad english and lack of respect, etiquette and manners makes
> it less than rewarding to discuss with you.
>
> --------------
> John Thingstad
On Tue, 15 Jul 2008 21:04:13 +0200, John Thingstad wrote:
> På Sun, 13 Jul 2008 16:53:38 +0200, skrev ······@gmail.com
> <······@gmail.com>:
>
> Besides your bad english and lack of respect, etiquette and manners
> makes it less than rewarding to discuss with you.
Then why are you guys doing it? He writes these posts because he
believes that he has an audience here.
I just switched newsreaders recently. When it loaded the headers, I
realized that there was something wrong. In a minute, Xah and Harrop got
score -9999, forever, end of problem.
Have a nice day,
Tamas