Re: If Scheme is so good why MIT drops it?
Xah Lee
> > How do you explain that something as inferior as Python beat Lisp in
> > the market place despite starting 40 years later.
>
> The same way like VHS 'beat' the film formats for home videos.
> The same way it will be 'beaten'.
wishful thinking tech geeking idiots always think that. It's a
psychological defense mechansim. When you are the loser, you enjoin
fancy adages to comfort yourself. Thus, Mac people, lisp people, and
unix people when it comse to Microsoft, always quote the same
mothefucking VHS vs Beta fuck.
In my life experience and interest on this issue in the past 5 years,
i found that, the world is basically pretty fair, all things
considered. Successful are successful not because they are unethical
or whatever motherfuck. Successful people, or products, in any
industry, may it be computing, singer, musics, software,
business ... , are due to reasonable causes, social and or technical.
e.g. the mundane hard working, good price/performance ratio, good
advertising, talent, and with perhaps a little what we'd have to call
fortuity.
Scheme, has become more obscure because it wasn't that great in the
first fucking place. Scheme grew upon a myth that it being elegant,
and this cult largely came from the fact when lisps are all
bewildering industrial langs and Scheme is one come with a design to
reduced lisps's ugliness. Since, the word “elegance” stuck with
Scheme.
As a illustration, the following 2 tech aspects we can see Scheme's
problem: (1) the cons business. (2) no namespace/library mechanism. In
the 1990s or before, these 2 reasons are not sufficient to kill it,
since other langs isn't much better in these areas, and much worse in
general. But today, starting about after 2000s, with proliferation of
langs and tools, Scheme isn't fit to compete for popularity.
References:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
• Lisp's List Problem
http://xahlee.org/emacs/lisp_list_problem.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
• Xah Lee's Computing Experience Bio
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
Xah
∑ http://xahlee.org/
☄
Peter Keller
> Scheme, has become more obscure because it wasn't that great in the
> first fucking place. Scheme grew upon a myth that it being elegant,
> and this cult largely came from the fact when lisps are all
> bewildering industrial langs and Scheme is one come with a design to
> Scheme.
Then why are most modern languages evolving towards all of the
functionality of functional languages? Things like lexical closure,
higher order functions, garbage collection, etc, are commonplace in your
"accepted and modern" languages these days. Give it another 20 years
and full macro systems will be common place as well. Why does this
diffusion happen?
Because languages like Scheme are "crucible" languages. People explore
the language in their implementations and then the knowledge of what works
and what doesn't gets disseminated throughout the relatively small culture
of language/compiler designers.
Syntax isn't what drives a language forward, any reasonable one will
do just fine. The four things which dominate language acceptance is A)
pure luck, B) the tools one uses to interact with it, C) expressivity
coupled with suggestivity, and D) available libraries.
If you think that because I said libraries I somehow justify your
argument, that isn't so. If you notice, C's libraries are probably the
most prolific and widest in use. Yet, there is no library structure at
all and most other languages create FFIs specifically to bring in the
functionality of C libraries.
Syntax isn't elegant: ideas are elegant.
-pete
vippstar
<snip>
> Syntax isn't elegant: ideas are elegant.
My car is elegant, the ad told me.
Pascal J. Bourguignon
Both my car and my cdr are elegant, I tell you.
--
__Pascal Bourguignon__
Mr.Cat
it.
2. Namespace/library mechanism is not absent. It exists in r6rs. In
r5rs it is not absent, it is just implementation-specific.
Mr.Cat
arbitrary graphs (a common example is a circular list).
Xah Lee
dear idiot,
see the FAQ at bottom of:
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Excerpt:
Q: If you don't like cons, lisp has arrays and hashmaps, too.
A: Suppose there's a lang called gisp. In gisp, there's cons but also
fons. Fons are just like cons except it has 3 cells with 3 accessors:
car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
the lang. Every some 100 lines of code you'll see a use of fons with
its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
etc. You got annoyed by this. You as a critic, complains that fons is
bad. But then some gisp fanatics retorts: “If you don't like fons,
gisp has cons, too!”.
You see, by “having something too”, does not solve the problem of
pollution. Sure, you can use just cons in gisp, but every lib or
other's code you encounter, there's a invasion of fons with its cbar,
cbbar, cbbbar. The problem created by fons does not go away by “having
cons too”.
Xah
∑ http://xahlee.org/
☄
Xah Lee
> In comp.lang.scheme Xah Lee <xah...@gmail.com> wrote:
>
> > Scheme, has become more obscure because it wasn't that great in the
> > first fucking place. Scheme grew upon a myth that it being elegant,
> > and this cult largely came from the fact when lisps are all
> > bewildering industrial langs and Scheme is one come with a design to
> > reduced lisps's ugliness. Since, the word ?elegance? stuck with
> > Scheme.
>
> Then why are most modern languages evolving towards all of the
> functionality of functional languages? Things like lexical closure,
> higher order functions, garbage collection, etc, are commonplace in your
> "accepted and modern" languages these days.
you as a Scheme or Lisp fan, perceives that the world is all copying
you.
Mac fans, perceives that Windows is all copying Mac, even today.
More realistically, the world didn't just copy you. Lisp is one of the
early languages, and in our opinion, a good one, containing many good
ideas. However, just because many lisp's ideas are common in many of
today's lang, you can't say that the world all copied lisp. For
example, automatic memory management, list datatype, are natural ideas
that would naturally come into being with increased computer hardware
power and progress of computer science.
In late 1990s, when Perl is raging, it is common to see here debates
about whether Perl is a lisp. Quite fucking idiotic. When XML is
raging in early 2000s, lisper fanatics think that the world finally
understood sexp, but did a lousy job in copying. What a motherfucking
idiocy. Today, especially like few years ago Ruby is raging with its
Rail whatnotfuck, you see people discussing with subjcet lines like Is
Ruby Lisp Done Right? What a motherfuck.
On the other hand, many, many, today's lang's features are not in
lisp.
It's the magic of wishful thinking at work.
Also, there's functional langs the likes of Mathematica, ML/OCaml/F#,
Haskell, erlang, OZ... and getting more popular today. Some of these
have roots in the 1980s. Lisps, in comparison to these, don't seem to
have a dick. Of course, the hardcore lispers look at these askance,
thinking that they are seeing some oddity of outter space that has
little earthy bearings; the same way imperative coding monkies look at
lisp — something they don't understand and ignore.
Also, lisp's macros, a feature that gets lispers much ado about
nothing. In Mathematica (b ~1989), the whole language can be
considered as a extended lisp macros system. When i learned about
lisp's macros while practical coding elisp, i find lisp macros are
rather so trivial, painful to use, and laughable. In fact, i never use
it, never see a need to use it. But you see lisp fanatics getting
giddy about macros all day, like Hasklers idiots drivel about monads
all day. All day, day and night. Macros! Monads!
> Give it another 20 years
> and full macro systems will be common place as well. Why does this
> diffusion happen?
LOL. (LOL = Laughing Out Loud.) Dream on.
In 20 years, bots will code for you, and meat brains would have
embedded silicon chips, and quantum computing would be reasonable too!
I'm not too sure Common Lisp, Scheme Lisp, Emacs Lisp, would still
exist. LOL.
> Because languages like Scheme are "crucible" languages. People explore
> the language in their implementations and then the knowledge of what works
> and what doesn't gets disseminated throughout the relatively small culture
> of language/compiler designers.
> Syntax isn't what drives a language forward, any reasonable one will
> do just fine.
Is this the “syntax is not important” adage? This is another idiotic
myth, popular among sophomoric computer language geekers, counting
some book writers.
Syntax, is the MOST important aspect of a computer language! Witness
lisp's nested parens. Without it, lisp wouldn't develope its
characteristics and features.
> The four things which dominate language acceptance is A)
> pure luck, B) the tools one uses to interact with it, C) expressivity
> coupled with suggestivity, and D) available libraries.
>
> If you think that because I said libraries I somehow justify your
> argument, that isn't so. If you notice, C's libraries are probably the
> most prolific and widest in use. Yet, there is no library structure at
> all and most other languages create FFIs specifically to bring in the
> functionality of C libraries.
>
> Syntax isn't elegant: ideas are elegant.
What a motherfucking meaningless idiocy.
Xah
∑ http://xahlee.org/
☄
Jon Harrop
> On Jul 21, 4:29 am, "Mr.Cat" <abakhir...@gmail.com> wrote:
>> 1. What's wrong with cons again? If you don't like it - just don't use
>> it.
>> 2. Namespace/library mechanism is not absent. It exists in r6rs. In
>> r5rs it is not absent, it is just implementation-specific.
>
> dear idiot,
>
> see the FAQ at bottom of:
>
> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> Excerpt:
>
> Q: If you don't like cons, lisp has arrays and hashmaps, too.
>
> A: Suppose there's a lang called gisp. In gisp, there's cons but also
> fons. Fons are just like cons except it has 3 cells with 3 accessors:
> car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> the lang. Every some 100 lines of code you'll see a use of fons with
> its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> etc. You got annoyed by this. You as a critic, complains that fons is
> bad. But then some gisp fanatics retorts: “If you don't like fons,
> gisp has cons, too!”.
ROTFL. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop
> In comp.lang.scheme Xah Lee <xah...@gmail.com> wrote:
>> Scheme, has become more obscure because it wasn't that great in the
>> first fucking place. Scheme grew upon a myth that it being elegant,
>> and this cult largely came from the fact when lisps are all
>> bewildering industrial langs and Scheme is one come with a design to
>> reduced lisps's ugliness. Since, the word ?elegance? stuck with
>> Scheme.
>
> Then why are most modern languages evolving towards all of the
> functionality of functional languages? Things like lexical closure,
> higher order functions, garbage collection, etc, are commonplace in your
> "accepted and modern" languages these days.
Yes.
> Give it another 20 years and full macro systems will be common place as
> well.
No.
Just because some good ideas were adopted does not mean that all ideas are
good and will be adopted. Indeed, what language features specific to Scheme
have gone mainstream?
Alex Queiroz
On Jul 21, 12:31 pm, Xah Lee <xah...@gmail.com> wrote:
>
> Also, lisp's macros, a feature that gets lispers much ado about
> nothing. In Mathematica (b ~1989), the whole language can be
> considered as a extended lisp macros system. When i learned about
> lisp's macros while practical coding elisp, i find lisp macros are
> rather so trivial, painful to use, and laughable. In fact, i never use
> it, never see a need to use it. But you see lisp fanatics getting
> giddy about macros all day, like Hasklers idiots drivel about monads
> all day. All day, day and night. Macros! Monads!
>
This is interesting. This shows you cannot really code in Lisp,
be it Elisp, CL or Scheme. But deeply in your disturbed mind you
believe you can, and to solve this cognitive dissonance you end up
harrassing everyone with your idiotic ideias of how to improve Lisp.
-alex
Peter Keller
> Peter Keller wrote:
>> Give it another 20 years and full macro systems will be common place as
>> well.
>
> No.
>
> Just because some good ideas were adopted does not mean that all ideas are
> good and will be adopted. Indeed, what language features specific to Scheme
> have gone mainstream?
*Specific* to scheme? I personally don't know of any--but from the LISP
family, here's one:
http://en.wikipedia.org/wiki/Perl_6#Macros
Notice the words:
"It is this Lisp-like macro concept that Perl 6 will take advantage of."
-pete
vippstar
Except that fons is useless while I can see use in cons - I can't
imagine lisp without it. Perhaps you can do that though, so please
explain or link me to an article of yours if you've already done so,
how do you imagine lisp without cons cells.
Pascal Costanza
http://www.paulgraham.com/diff.html
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Keith H Duggar
> mothefucking VHS vs Beta fuck.
> first fucking place
> Quite fucking idiotic
> motherfucking idiocy
> Rail whatnotfuck
> What a motherfuck.
> What a motherfucking meaningless idiocy.
Xah, this should get your creative juices flowing:
http://www.duggar.org/pub/humor/FWordIsBeautiful.wav
KHD
Xah Lee
> Xah Lee wrote:
>
> > A: Suppose there's a lang called gisp. In gisp, there's cons but also
> > fons. Fons are just like cons except it has 3 cells with 3 accessors:
> > car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in
> > the lang. Every some 100 lines of code you'll see a use of fons with
> > its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar,
> > etc. You got annoyed by this. You as a critic, complains that fons is
> > bad. But then some gisp fanatics retorts: “If you don't like fons,
> > gisp has cons, too!”.
>
> Haines, E. C., The TREET List Processing Language. M.S. Thesis, MIT,
> Cambridge, Mass., August 1964. Also SR-133, The MITRE Corporation,
> Bedford, Mass., April 1965.
>
> As I recall, a lisp with 3 addresses per cell.
>
> I think it had car, cdr, csr.
>
> It didn't catch on.
Thanks Richard!
Rare is newsgroup discussions come out something informative.
(PS, i'm adding a little addendum to my essay about the existance of
TREET. If no objections, i'm crediting it to you as informer)
Xah
∑ http://xahlee.org/
☄
fft1976
> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
This sounds very interesting, but the translation is very bad. Did you
use babelfish?
gugamilare
> On Jul 21, 5:27 am, Xah Lee <xah...@gmail.com> wrote:
>
> > • Fundamental Problems of Lisp
> > http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> This sounds very interesting,
You can't be serious.
Mr.Cat
...
> Q: If you don't like cons, lisp has arrays and hashmaps, too.
No need to be insulting here.
When it comes to lists, scheme is rather close to other functional
languages like haskell or erlang. Lists haskell/erlang also have cons-
cell semantics, but it is a bit less explicit. At the same time in
scheme you're not limited to cons/car/cdr whe dealing with lists.
You've got different utility functions (i.e. srfi-1), pattern matching
and so on.
Peter Keller
>> Syntax isn't elegant: ideas are elegant.
>
> What a motherfucking meaningless idiocy.
For example: I read the articles on your website and while I think your syntax
was passable, your ideas were not. I don't think there is any language you
could translate that stuff into to make the concepts in it better.
See the difference?
-pete
Aaron W. Hsu
> When it comes to lists, scheme is rather close to other functional
> languages like haskell or erlang. Lists haskell/erlang also have cons-
> cell semantics, but it is a bit less explicit. At the same time in
> scheme you're not limited to cons/car/cdr whe dealing with lists.
> You've got different utility functions (i.e. srfi-1), pattern matching
> and so on.
Xah is, I believe, complaining about the very existence of the construct
in the core language, arguing that its frequent use represents a problem
to him and writing his own code. Apparently, the use of CONS in any code
makes that code bad, for some value of bad. I hope that the illegitimacy
of such "reasoning" appears self-evident to the majority of readers.
Aaron Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
fft1976
> On Tue, 21 Jul 2009 19:13:45 -0400, Mr.Cat <abakhir...@gmail.com> wrote:
> > When it comes to lists, scheme is rather close to other functional
> > languages like haskell or erlang. Lists haskell/erlang also have cons-
> > cell semantics, but it is a bit less explicit. At the same time in
> > scheme you're not limited to cons/car/cdr whe dealing with lists.
> > You've got different utility functions (i.e. srfi-1), pattern matching
> > and so on.
>
> Xah is, I believe, complaining about the very existence of the construct
> in the core language, arguing that its frequent use represents a problem
> to him and writing his own code. Apparently, the use of CONS in any code
> makes that code bad, for some value of bad. I hope that the illegitimacy
> of such "reasoning" appears self-evident to the majority of readers.
>
But the same people who think undesirable optional features are not a
valid reason to complain about a language (Common Lisp), will turn
around and claim that C++ sucks compared to C.
I maintain that Xah is smarter than most people here. He's simply
misunderstood (because he seems to be using babelfish for his posts)
Aaron W. Hsu
> But the same people who think undesirable optional features are not a
> valid reason to complain about a language (Common Lisp), will turn
> around and claim that C++ sucks compared to C.
Someone who writes C++ without using any features not found in C is not
using C++, but C, for all intents and purposes. It would be one thing if
Xah complained that linked lists/chains and recursion are not useful or
constitute a problem when they represent the core nature of a language
(which I think could be argued for Scheme). He is not. He is arguing that
a set of procedures, if I understand him, operating on some data
structure, used in many Scheme libraries and code, makes Scheme inherently
flawed.
The big difference here is that Scheme is dynamic enough to allow
programmers to use whatever they feel they want to use, and to have a
syntax on top of it that they like. If you think Scheme's CONS is a
problematic procedure, write your own syntaxes and procedures to operate
on the core data structures the way you want. Or, write your own data
types so that you can do things the way you want. If you don't like C++'s
features that extend C, well, then C++ doesn't really provide anything
further: you can't really add features, in a sense.
The arguments are different.
Aaron W. Hsu
Mr.Cat
> I maintain that Xah is smarter than most people here. He's simply
> misunderstood (because he seems to be using babelfish for his posts)
Maybe. There is one worthy idea in his essays:
>The cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp langs, is thus not something that can be easily mended.
>This is unfortunate. However, this situation could be improved. (by, for examples:
>(A) create a standard that all list data structures must be proper lists.
>(B) Expose only higher-level list manipulation functions (i.e. interfaces to cons) in all newer literature.
>(C) Even mark cons related constructs as obsolete)
But this is already done for scheme (except for making cons obsolete
of course). Thus, I don't know what are we going to discuss here.
Bata
Michele Simionato
> >(A) create a standard that all list data structures must be proper lists.
> >(B) Expose only higher-level list manipulation functions (i.e. interfaces to cons) in all newer literature.
> >(C) Even mark cons related constructs as obsolete)
>
> But this is already done for scheme (except for making cons obsolete
> of course).
What are you talking about? Nor A, nor B, nor C are done in Scheme.
Jon Harrop
> Except that fons is useless while I can see use in cons - I can't
> imagine lisp without it. Perhaps you can do that though, so please
> explain or link me to an article of yours if you've already done so,
> how do you imagine lisp without cons cells.
Easy: just treat cons as the special case of a 2-element array. That is
essentially what Mathematica does and it works just fine.
I believe the original motivation for separating cons out was performance
but, as we know now, that just led to slightly less cripplingly-bad
performance.
Aaron W. Hsu
And thank goodness for that.
Aaron
vippstar
> vippstar wrote:
> > Except that fons is useless while I can see use in cons - I can't
> > imagine lisp without it. Perhaps you can do that though, so please
> > explain or link me to an article of yours if you've already done so,
> > how do you imagine lisp without cons cells.
>
> Easy: just treat cons as the special case of a 2-element array. That is
> essentially what Mathematica does and it works just fine.
just that. An array can not hold two different types of elements,
which is necessary for cons to represent a list:
'(1 . (2 . nil))
1 -> INTEGER
(2 . nil) -> CONS
I don't know how Mathematica does this, but mathematicas arrays likely
have different semantics than the usual arrays, likely making them
much slower.
> I believe the original motivation for separating cons out was performance
> but, as we know now, that just led to slightly less cripplingly-bad
> performance.
What do you mean 'seperating cons out'? I don't understand, seperating
it out of what?
Jon Harrop
> On Jul 22, 10:05 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Easy: just treat cons as the special case of a 2-element array. That is
>> essentially what Mathematica does and it works just fine.
>
> Cons is not a two-element array, it contains more information than
Not necessarily in dynamic languages.
>> I believe the original motivation for separating cons out was performance
>> but, as we know now, that just led to slightly less cripplingly-bad
>> performance.
>
> What do you mean 'seperating cons out'? I don't understand, seperating
> it out of what?
Introducing an artificial distinction between cons and arbitrary-length
arrays.
Raffael Cavallaro
> An array can not hold two different types of elements,
> which is necessary for cons to represent a list:
? (defparameter *heterogeneous-array* (make-array 2 :initial-contents
(list pi "a string")))
*HETEROGENEOUS-ARRAY*
? (type-of (aref *heterogeneous-array* 0))
DOUBLE-FLOAT
? (type-of (aref *heterogeneous-array* 1))
(SIMPLE-BASE-STRING 8)
--
Raffael Cavallaro
joseph...@gmail.com
Cons pairs are typically represented as two consecutive machine words,
one for car, one for cdr, using the low-tag bits in a reference to
identify those words as a cons pair; 2-element arrays typically must
have an array header that indicates that the object 1) is an array and
2) has two generic elements, in addition to the two machine words that
hold the array elements themselves.
Perhaps in your phrase "slightly less cripplingly-bad performance" you
were referring to Mathematica, which is hardly an example of how to do
Lisp right.
Jon Harrop
> On Jul 22, 3:05 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> I believe the original motivation for separating cons out was performance
>> but, as we know now, that just led to slightly less cripplingly-bad
>> performance.
>
> one for car, one for cdr, using the low-tag bits in a reference to
> identify those words as a cons pair; 2-element arrays typically must
> have an array header that indicates that the object 1) is an array and
> 2) has two generic elements, in addition to the two machine words that
> hold the array elements themselves.
>
> Perhaps in your phrase "slightly less cripplingly-bad performance" you
> were referring to Mathematica, which is hardly an example of how to do
> Lisp right.
No, I was referring to the irrelevance of such bit twiddling of pointers
when implementing a performant Lisp today.
Jon Harrop
> The big difference here is that Scheme is dynamic enough to allow
No, the big difference is that Lispers are deluded enough to think that it
is feasible to Greenspun everything yourself given a sufficiently dynamic
language. Look at the state of concurrent GCs in the Lisp world, for
example.
Nicolas Neuss
> Aaron W. Hsu wrote:
>> The big difference here is that Scheme is dynamic enough to allow
>> programmers to use whatever they feel they want to use...
>
> No, the big difference is that Lispers are deluded enough to think that it
> is feasible to Greenspun everything yourself given a sufficiently dynamic
> language. Look at the state of concurrent GCs in the Lisp world, for
> example.
What does it mean that a (Common) Lisper "greenspuns" something? It does
not make much sense, because Greenspun's tenth is:
"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Common
Lisp"
and a CL program will usually use all of Common Lisp (if you do not use a
tree-shaker when distributing your application).
So I propose that you should change your terminology, leaving the poor Phil
Greenspun alone, by creating Harrop's first rule:
"Any sufficiently complicated Common Lisp program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of the
union of C, Ocaml, and F#."
Is this what you have in your mind? Or should the union extend to even
more languages?
Nicolas
Jon Harrop
Yes. Greenspun's rule was abstractly about programmers using low-level
languages for high-level work having to implement high-level features. He
was referring concretely to things like the constant reimplementation of
linked lists in C programs. Today, Greenspun's tenth rule is obsolete in
its concrete form because the vast majority of programmers have moved on to
higher-level languages but his rule will always remain applicable
abstractly as languages evolve. Pattern matching and concurrent garbage
collection are two examples.
Nicolas Neuss
>> So I propose that you should change your terminology, leaving the poor
>> Phil Greenspun alone, by creating Harrop's first rule:
>>
>> "Any sufficiently complicated Common Lisp program contains an ad hoc,
>> informally-specified, bug-ridden, slow implementation of half of the
>> union of C, Ocaml, and F#."
>>
>> Is this what you have in your mind?
>
> Yes. Greenspun's rule was abstractly about programmers using low-level
> languages for high-level work having to implement high-level features. He
> was referring concretely to things like the constant reimplementation of
> linked lists in C programs. Today, Greenspun's tenth rule is obsolete in
> its concrete form because the vast majority of programmers have moved on to
> higher-level languages but his rule will always remain applicable
> abstractly as languages evolve. Pattern matching and concurrent garbage
> collection are two examples.
Apparently Harrop's first rule is
"Any sufficiently complicated Common Lisp program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of every language
feature that is not built-in."
Don't you have some concrete language in mind with which you replace Common
Lisp in Greenspun's rule?
Nicolas
--
- Mommy, look, what is that big froggy doing on top of the little
froggy?
- Uh... Well, he is just trying to see if their patterns match, honey.
- That's pattern matching? Why don't people do pattern matching too?
- They do when they feel like it and it's convenient, they just don't
need to let the whole world know they learned to do it.
(dix...@gmail.com, comp.lang.lisp, 2.7.2007)
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> writes:
>> Yes. Greenspun's rule was abstractly about programmers using low-level
>> languages for high-level work having to implement high-level features. He
>> was referring concretely to things like the constant reimplementation of
>> linked lists in C programs. Today, Greenspun's tenth rule is obsolete in
>> its concrete form because the vast majority of programmers have moved on
>> to higher-level languages but his rule will always remain applicable
>> abstractly as languages evolve. Pattern matching and concurrent garbage
>> collection are two examples.
>
> Apparently Harrop's first rule is
>
> "Any sufficiently complicated Common Lisp program contains an ad hoc,
> informally-specified, bug-ridden, slow implementation of every language
> feature that is not built-in."
Try:
"Any sufficiently complicated program written in a lower-level language
contains an ad hoc, informally-specified, bug-ridden, slow implementation
of half of a higher-level language implementation."
of which Greenspun's is a special case for C and CL.
> Don't you have some concrete language in mind with which you replace
> Common Lisp in Greenspun's rule?
In the case of CL you can use Scala or F#.
fortunatus
> ...the vast majority of programmers have moved on to
> higher-level languages...
Ahhhhhhh-ha-ha-ha-ha-ha-ha-ha! Vahhhhh-ha-ha-ha-ha-ha-ha-ha!
Vahhhh-ha-st! Va-ha-ha-ha-ha-ha! Vah-ha-ahst Ma-ha-ha-ha-ha!
I cah-ha-ha-n't manah-ha-ha-ge to say-hay-hay-hay it!
Peter Keller
# BEGIN CODE
organize boss's crappy requirements into priority list;
reasonably implement each feature in list;
test, diff, and commit implemented features into repository;
# END CODE
And you'd compile it like this:
Linux > doit --minimize=time,money foo.dwim
-pete
ACL
Since when does lisp have cripplingly bad performance?
It seems fine to me.
I think there is even a scheme implementation that is as good
performance as C in a lot of cases.
ACL
Lets remove the distinction between data-structures and blocks of
memory.
Everything is just a bunch of 1's and 0's stored in a chunk of memory
anyway.
Marek Kubica
Jon Harrop <j...@ffconsultancy.com> wrote:
> Pattern matching and concurrent garbage collection are two examples.
Pattern matching is a part of PLT Scheme. What does this tell us?
regards,
Marek
Aaron W. Hsu
wrote:
> Pattern matching is a part of PLT Scheme. What does this tell us?
Pattern Matching is a lot of places and is available as nice libraries
that are portable, too.
Andrew Reilly
> On Thu, 23 Jul 2009 20:04:22 -0400, Marek Kubica
> <ma...@xivilization.net> wrote:
>
>> Pattern matching is a part of PLT Scheme. What does this tell us?
>
> Pattern Matching is a lot of places and is available as nice libraries
> that are portable, too.
Indeed, the way that the schemes have been able to add pattern matching
through library facilities (along with various object models and other
features often thought of as "language characteristics") is, I think, a
tremendous vindication of the power of advanced macrology. It is a
beautiful blurring of the line between the compiler and the program.
[Regarding the earlier comment about concurrent garbage collection: how
is that not a quality-of-implementation issue, rather than a language
issue? It's been said that the JVM has (or can have, if you turn it on)
concurrent garbage collection. There are JVM-hosted lisp and scheme
implementations, therefore there are lisp and scheme implementations with
concurrent garbage collection. QED.]
Cheers,
--
Andrew
Benjamin L. Russell
wrote:
>the vast majority of programmers have moved on to
>higher-level languages
Evidence?
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Tobias C. Rittweiler
> Indeed, the way that the schemes have been able to add pattern matching
> through library facilities (along with various object models and other
> features often thought of as "language characteristics") is, I think, a
> tremendous vindication of the power of advanced macrology. It is a
> beautiful blurring of the line between the compiler and the program.
I don't think that is as perfectly true as it may sound.
Pattern-matching as a DESTRUCTURING-BIND on steroids is certainly
nice. But when someone with ML, etc. background talks about
pattern-matching he/she often means that in combination with variant
types, and the compiler being able to emit efficient jump-tables for
simple pattern-matching code.
Sure you can get that too via macros, but only if an implementation lays
down the necessary tools for you.
-T.
Nicolas Neuss
> Try:
>
> "Any sufficiently complicated program written in a lower-level language
> contains an ad hoc, informally-specified, bug-ridden, slow implementation
> of half of a higher-level language implementation."
>
> of which Greenspun's is a special case for C and CL.
Your rule sounds very wishy-washy to me, and I don't think that Greenspun
would like to be credited with it. Without mentioning concrete languages,
it is only wishful thinking ending up at dissing real programming languages
in favor of Peter Keller's DWIM suggestion (probably achieved by
Mathematica becoming intelligent which will happen in the next years
according to your colleague Xah Lee).
>> Don't you have some concrete language in mind with which you replace
>> Common Lisp in Greenspun's rule?
>
> In the case of CL you can use Scala or F#.
OK, here we have at least something concrete. Let's look at those options.
- I'm one of those people who think that Microsoft is the worst thing that
ever happened to software industry. (Of course, if Microsoft has shit
sufficiently much in your brain, you'll see it exactly the other way
round.) So F# is not an option for me.
- Scala installed with the Ubuntu (Hardy) package system failed to run[*],
so I can't check this myself, but: Does this dream language have at least
an interactive REPL? I'm a large friend of incremental and interactive
development.
Nicolas
[*] Exception in thread "main" java.lang.NoClassDefFoundError: scala.tools.nsc.MainGenericRunner
at gnu.java.lang.MainThread.run(libgcj.so.81)
Caused by: java.lang.ClassNotFoundException: scala.tools.nsc.MainGenericRunner not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.81)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.81)
at java.lang.ClassLoader.loadClass(libgcj.so.81)
at java.lang.ClassLoader.loadClass(libgcj.so.81)
at gnu.java.lang.MainThread.run(libgcj.so.81)
Nicolas
Marek Kubica
Yes it has. If you want to try, use Scala with the Sun JDK or the
OpenJDK (but then you probably need Scala 2.7.3, because the OpenJDK
had some bug on Debian, possibly that it is in Ubuntu, too).
regards,
Marek
Jon Harrop
> On Thu, 23 Jul 2009 20:04:22 -0400, Marek Kubica <ma...@xivilization.net>
> wrote:
>> Pattern matching is a part of PLT Scheme. What does this tell us?
>
> Pattern Matching is a lot of places and is available as nice libraries
> that are portable, too.
Lists are available as nice portable C libraries as well.
Yet C programmers continue to Greenspun lists and Common Lisp programmers
continue to Greenspun pattern matchers.
Jon Harrop
> Your rule sounds very wishy-washy to me...
You struggle with abstract concepts.
>> In the case of CL you can use Scala or F#.
>
> OK, here we have at least something concrete. Let's look at those
> options.
>
> - I'm one of those people who think that Microsoft is the worst thing that
> ever happened to software industry. (Of course, if Microsoft has shit
> sufficiently much in your brain, you'll see it exactly the other way
> round.) So F# is not an option for me.
You are not a professional programmer.
> - Scala installed with the Ubuntu (Hardy) package system failed to run[*],
> so I can't check this myself, but: Does this dream language have at least
> an interactive REPL? I'm a large friend of incremental and interactive
> development.
Your experience outside Lisp is very limited.
Address the above issues and you will be able to understand what I wrote.
Until then, you're just repeating that Lisp is better than everything you
don't know.
Jon Harrop
> On Thu, 23 Jul 2009 18:09:13 +0100, Jon Harrop <j...@ffconsultancy.com>
> wrote:
>>the vast majority of programmers have moved on to
>>higher-level languages
>
> Evidence?
Java and C# have the largest market shares. 54% of the jobs:
http://www.itjobswatch.co.uk/jobs/uk/java.do
http://www.itjobswatch.co.uk/jobs/uk/csharp.do
and 27% of the units of cheap books sold:
http://radar.oreilly.com/2009/02/state-of-the-computer-book-mar-22.html
The market share of C has fallen to only ~10%.
Nicolas Neuss
> You are not a professional programmer.
That's right.
>> - Scala installed with the Ubuntu (Hardy) package system failed to run[*],
>> so I can't check this myself, but: Does this dream language have at least
>> an interactive REPL? I'm a large friend of incremental and interactive
>> development.
>
> Your experience outside Lisp is very limited.
Also right (mainly C and some C++). And that's also the reason why I
restrict myself essentially to comp.lang.[lisp|scheme]. Somehow, I think
this is more honest than not having experience in Lisp or Scheme and
spamtrolling these newsgroups.
> Address the above issues and you will be able to understand what I wrote.
> Until then, you're just repeating that Lisp is better than everything you
> don't know.
Sorry? Where did I say that? I only would like to be _convinced_ by hard
facts, instead of having only the word of someone who has commercial
interests in propagating another language.
Nicolas
Thomas F. Burdick
wrote:
> - I'm one of those people who think that Microsoft is the worst thing that
> ever happened to software industry.
[...]
> - Scala installed with the Ubuntu (Hardy) package system failed to run[*],
Hmm.
Nicolas Neuss
:-) You may have a point here. Does Scala install painlessly on Windows?
Nicolas
Marek Kubica
Provided that you have a JVM I'd say: Yes. They both have an installer
available as well as a zipfile containing compiled files that can be
run by the JVM (even on Windows).
regards,
Marek
Jon Harrop
> Jon Harrop <j...@spamfrog.com> writes:
>> You are not a professional programmer.
>
> That's right.
You are an academic funded by taxes paid for by the professional developers
who use Microsoft technologies. Perhaps you cannot comprehend their value
but you could at least try to imagine that it exists.
>>> - Scala installed with the Ubuntu (Hardy) package system failed to
>>> run[*], so I can't check this myself, but: Does this dream language have
>>> at least
>>> an interactive REPL? I'm a large friend of incremental and interactive
>>> development.
>>
>> Your experience outside Lisp is very limited.
>
> Also right (mainly C and some C++). And that's also the reason why I
> restrict myself essentially to comp.lang.[lisp|scheme].
That does not justify posting misinformation about other languages on Lisp
and Scheme newsgroups.
> Somehow, I think this is more honest than not having experience in Lisp or
> Scheme and spamtrolling these newsgroups.
You don't see me asking if Lisp has a REPL.
> ...
> I only would like to be _convinced_ by hard facts,
Then go in search of the facts and teach yourself about Scala and its REPL.
Nicolas Neuss
> You are an academic funded by taxes paid for by the professional
> developers who use Microsoft technologies.
Not all of them, and not all of them happily.
> Perhaps you cannot comprehend their value but you could at least try to
> imagine that it exists.
Yes, there exists a value. Yet, I think the damage done by that monopoly
outweighs this value.
> That does not justify posting misinformation about other languages on Lisp
> and Scheme newsgroups.
>
>> Somehow, I think this is more honest than not having experience in Lisp or
>> Scheme and spamtrolling these newsgroups.
>
> You don't see me asking if Lisp has a REPL.
Oh, Jon, if only your imputations were as harmless as that.
>> I only would like to be _convinced_ by hard facts,
>
> Then go in search of the facts and teach yourself about Scala and its
> REPL.
I have already printed some documentation.
Nicolas
--
PD Dr. Nicolas Neuss University Karlsruhe Tel: 0049-721-608-7634
Email: ne...@math.uni-karlsruhe.de
WWW: <http://www.mathematik.uni-karlsruhe.de/~neuss>
Nicolas Neuss
> You are an academic funded by taxes paid for by the professional
> developers who use Microsoft technologies.
Not all of them, and not all of them happily.
> Perhaps you cannot comprehend their value but you could at least try to
> imagine that it exists.
Yes, there exists a value. Yet, I think the damage done by that monopoly
outweighs this value.
> That does not justify posting misinformation about other languages on Lisp
> and Scheme newsgroups.
>
>> Somehow, I think this is more honest than not having experience in Lisp or
>> Scheme and spamtrolling these newsgroups.
>
> You don't see me asking if Lisp has a REPL.
Oh, Jon, if only your imputations were as harmless as that.
>> I only would like to be _convinced_ by hard facts,
>
> Then go in search of the facts and teach yourself about Scala and its
> REPL.
I have already printed some documentation.
Nicolas
--
Sorry for those of you who read this article twice. I canceled the first one
which included also my usual Email signature.
Jon Harrop
> Jon Harrop <jon@...> writes:
>> Perhaps you cannot comprehend their value but you could at least try to
>> imagine that it exists.
>
> Yes, there exists a value. Yet, I think the damage done by that monopoly
> outweighs this value.
Fair enough. I don't think Microsoft's monopoly has done more damage than
the large numbers of academics who use tax payers money to develop software
and then try to sell it back to the tax payers who already paid for it.
IMHO, that should be prohibited.
>>> Somehow, I think this is more honest than not having experience in Lisp
>>> or Scheme and spamtrolling these newsgroups.
>>
>> You don't see me asking if Lisp has a REPL.
>
> Oh, Jon, if only your imputations were as harmless as that.
Not harmless but then not baseless either. I do my research and gamble my
own money accordingly. I am considering gambling on Scala because it seems
to be popular and may be commercially viable so I've installed it on both
Linux and Windows, tried different IDEs, played with its REPL, written a
dozen programs, struggled to compile them, done some benchmarks and so on.
I don't like its lack of automatic generalization and I found its community
tiresome but if other people find it bearable then maybe I should spend
more time with it.
>>> I only would like to be _convinced_ by hard facts,
>>
>> Then go in search of the facts and teach yourself about Scala and its
>> REPL.
>
> I have already printed some documentation.
Great! I'm keen to see what you think of it...
A.L.
<last...@math.uni-karlsruhe.de> wrote:
>"Thomas F. Burdick" <tbur...@gmail.com> writes:
>
>> On Jul 24, 9:46�am, Nicolas Neuss <lastn...@math.uni-karlsruhe.de>
>> wrote:
>>
>>> - I'm one of those people who think that Microsoft is the worst thing that
>>> ever happened to software industry.
>>
>> [...]
>>
>>> - Scala installed with the Ubuntu (Hardy) package system failed to run[*],
>>
>> Hmm.
>
>You may have a point here. Does Scala install painlessly on Windows?
Yes
A.L.
joseph...@gmail.com
> josephoswald...@gmail.com wrote:
> > On Jul 22, 3:05 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> >> I believe the original motivation for separating cons out was performance
> >> but, as we know now, that just led to slightly less cripplingly-bad
> >> performance.
>
> > one for car, one for cdr, using the low-tag bits in a reference to
> > identify those words as a cons pair; 2-element arrays typically must
> > have an array header that indicates that the object 1) is an array and
> > 2) has two generic elements, in addition to the two machine words that
> > hold the array elements themselves.
>
> > Perhaps in your phrase "slightly less cripplingly-bad performance" you
> > were referring to Mathematica, which is hardly an example of how to do
> > Lisp right.
>
> No, I was referring to the irrelevance of such bit twiddling of pointers
> when implementing a performant Lisp today.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Froggy, you aren't making yourself clear here.
What do "performant Lisp" implementations do today to implement cons
pairs? Do they add multiple words of overhead (your "2 element array"
technique), or do they use the same data tagging techniques that have
been used for decades to implement Lisps on conventional un-tagged
machines, or something else like depending on the JVM or CLR to do
whatever they do under the hood?
The bits of a lowtag are rarely twiddled: fast CAR and CDR simply
fetch the machine word at a fixed offset from the CONS (tagged
address) value. The lowtag bits are extracted only when an operation
wants to detect if a value is a CONS cell or not. The lowtag is set
only by the CONS operation, which allocates two words of memory, puts
the CAR value in one, the CDR value in the other, then returns the
location of that word pair, offset by a value that is the CONS-
specific lowtag. On most architectures today, addresses are byte-
aligned, while machine words are 4- or 8-byte aligned, so this lowtag
is mostly using what would be zero bits anyhow, meaning CONS pairs can
typically be located at any even word address, with zero padding
needed.
No allocation, writing, or reading of an array header. No wasted
memory. CAR and CDR can be single machine instructions when the type-
check for CONS can be omitted.
How can this be made more performant?
Tim Bradshaw
> Since when does lisp have cripplingly bad performance?
> It seems fine to me.
It is fine. The person to whom you're responding has something to sell
you which isn't Lisp.
Gendarme
IMO this says less about Scala than it does about Unix, and how the
latter is still not quite up to snuff in the usability department. In
particular, until installing things on Unix is as painless and reliable
as it is on other platforms, it will not be a viable competitor to
Microsoft on the desktop.
Paul Donnelly
Package managers? Usually Linux users cite these as a big feature.
Jim Burton
IME "installing things on Unix", if debian and its clones count, is
painless and reliable, certainly if the software is available as a
package; less hassle than Windows in fact:
$ sudo apt-get install scala
If you're not aware that apt/yum whatever will handle dependencies
nicely and keep your whole system up to date, you can't have used linux
in quite a while because although this used to mark debian out now
just about every modern distro has good package management. Of the other
*NIXes FreeBSD is just as good, probably the others too.
--
Jim Burton
j...@sdf-eu.org
Gendarme
And yet ...
"Scala installed with the Ubuntu (Hardy) package system failed to run."
There still seems to be a problem on Unix of things not working "out of
the box", which seems related to the tendency of those things to depend
on centralized shared libraries, be compiled locally from source, or both.
Windows apps tend to be self-contained, unpacking into a directory with
the program binary and any needed DLLs. This can result in disk space
bloat through DLL duplication, but it also results in things working
reliably even if the user installs two things that use slightly
different versions of the same library.
(This didn't used to be the case; google "DLL hell". But from Windows XP
on, it's not been a problem. Unfortunately, what Windows gets here it
loses elsewhere; buggy code causes reliability and security problems,
mostly owing to poor code quality rather than install/dependency
management issues. Every system has its weaknesses. But if things won't
even install properly, that's a much bigger showstopper than if they
will, but occasionally crash, hence Windows comes out on top especially
for nontechnical users without the knowledge or inclination to try to
figure out why some install script or newly-installed program barfs up a
cryptic error message instead of doing as advertised.)
A.L.
I installed Scala from within Eclipse. As I know (however I have never
tested) Eclipse runs also on Linux. I don't see any problem here....
A.L.
Jon Harrop
Note that 99% of developers have something to sell you which isn't Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Jon Harrop
> What do "performant Lisp" implementations do today to implement cons
> pairs?
They build on existing performant VMs where all bit twiddling has been
abstracted away.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Tim Bradshaw
> until installing things on Unix is as painless and reliable as it is on
> other platforms
This is just meaningless. *Which* Unix(-like) system? Solaris is a
pain, for sure[*], but the various Debian-derived systems are great.
OSX varies from better than Debianoid systems (just drop the .app
directory somewhere suitable) to not-quite-as-good (no easy way of
uninstalling packages).
[*] OpenSolaris may be better
Marek Kubica
Or updating. And they probably ship all non-standard libs with
themselves making packages big and the DLLs eventually outdated, just
like on Windows, where everybody has his own copy of zlib.
The only problem I see with APT is that it is complex to build packages
that work for everyone (Debian Stable/Testing, Ubuntu etc). Actually,
it is already complex to build packages at all, maint-guide is rather
long, compared with how much wisdom other package managers (unices) or
installers (windows) require.
regards,
Marek
Scott Burson
> >> Since when does lisp have cripplingly bad performance?
> >> It seems fine to me.
>
> > It is fine. The person to whom you're responding has something to sell
> > you which isn't Lisp.
>
> Note that 99% of developers have something to sell you which isn't Lisp.
Since this statement, even if true, would prove nothing whatsoever, it
can only be considered to be more adolescent heckling.
-- Scott
Gendarme
> On 2009-07-24 20:40:39 +0100, Gendarme <endar...@otmailhay.invaliday>
> said:
>
>> until installing things on Unix is as painless and reliable as it is
>> on other platforms
>
> This is just meaningless. *Which* Unix(-like) system?
Any, with the possible exception of Mac OSX.
As the example involving Scala on Ubuntu demonstrates, package managers
have not completely banished the old Unix bugbear of things not
installing properly or not working out of the box, instead requiring
arcane wizardliness to get them installed and running.
That's the situation on Linux. On the *BSD side I think users are still
stuck with the time-worn procedure of "pray, ./configure, make, make
install, tear out hair". (As the old joke goes, you can tell what D&D
class someone is by what they do before/after ./configure, make, make
install: if they pray beforehand, cleric; begin by sacrificing a goat in
a pentagram drawn with obsidian dust, necro; just type in the commands,
then take a baseball bat to their monitor afterward, warrior; try it,
swear, and then install a pirated copy of Windows on the machine, rogue;
actually get it to compile and run successfully, wizard.)
Jon Harrop
> On Jul 25, 1:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Tim Bradshaw wrote:
>> > On 2009-07-23 22:15:35 +0100, ACL <anonymous.c.lis...@gmail.com> said:
>> >> Since when does lisp have cripplingly bad performance?
>> >> It seems fine to me.
>>
>> > It is fine. The person to whom you're responding has something to sell
>> > you which isn't Lisp.
>>
>> Note that 99% of developers have something to sell you which isn't Lisp.
>
Even if true?
Tim Bradshaw
> Note that 99% of developers have something to sell you which isn't Lisp.
I care about Lisp's popularity the same way I care about Mahler's
Richard Fateman
> vippstar wrote:
>> Except that fons is useless while I can see use in cons - I can't
>> imagine lisp without it. Perhaps you can do that though, so please
>> explain or link me to an article of yours if you've already done so,
>> how do you imagine lisp without cons cells.
>
> Easy: just treat cons as the special case of a 2-element array. That is
> essentially what Mathematica does and it works just fine.
1. Mathematica, last I looked, uses the name List for something that
most of us would call a vector. Prepending a value to the front of a
List L, the O(1) operation in Lisp called cons, takes, in Mathematica,
O(n) time where n is the length of L. This is not "fine" to many
people. Another operation that Mathematica associates with creating such
a new data structure is that it goes through all the elements to update
them -- to see if they depend on some value that has changed recently.
This is not "fine" to many people.
As for storing a cons cell as a 2-element array, this is a case of
economy of storage and operation (for the cons) vs. redundant (larger)
storage and slower general operation (for the array).
>
> I believe the original motivation for separating cons out was performance
> but, as we know now, that just led to slightly less cripplingly-bad
> performance.
You are of course free to believe anything at all, but your attestation
as to the "original motivation" is not particularly credible. Are you
talking about the roots of Lisp, e.g. Lisp 1.5 and earlier? Are you
claiming that you have a better instruction sequence for accessing
elements 0 and 1 of an array than CAR and CDR on the IBM 709X?
You can read the Lisp 1.5 programmer's manual online:
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
In some lisps (Maclisp, Franz Lisp) there were data object called hunks,
which could be allocated in power-of-2 sizes, and which did not have
special headers -- they were tagged by virtue of their locations. Hunks
of size 2,4, ... 512 were on different pages.
And cons cells were on different pages.
This was a feature of BIBOP allocation of objects in those Lisps. So if
you really wanted a kind-of cons-cell with, say 4 or 8 spots, you could
allocate them etc.
Common Lisp does not have hunks.
RJF
Benjamin L. Russell
<endar...@otmailhay.invaliday> wrote:
>Tim Bradshaw wrote:
>
>(As the old joke goes, you can tell what D&D
>class someone is by what they do before/after ./configure, make, make
>install: if they pray beforehand, cleric; begin by sacrificing a goat in
>a pentagram drawn with obsidian dust, necro; just type in the commands,
>then take a baseball bat to their monitor afterward, warrior; try it,
>swear, and then install a pirated copy of Windows on the machine, rogue;
>actually get it to compile and run successfully, wizard.)
Interesting joke. Reference?
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Pillsy
[....]
> As a illustration, the following 2 tech aspects we can see Scheme's
> problem: (1) the cons business.
The idea that exposing something as low-level as "cons" is a major
obstacle to a language's popularity has seems to have two major
problems.
A. It implicitly depends on the assertion that exposing[1] low-level
constructs is a major impediment to a language's widespread adoption,
but C exposes an even lower-level detail than conses, in the form of
pointers, and doing anything useful in C without understanding
pointers is virtually impossible. This hasn't prevented C from
becoming vastly more widely used than Lisp or any of the functional
languages you often cite as somehow superseding it.
B. It's extremely common for functional languages that aren't Lisp to
have conses as well, and to represent lists as recursively built out
of conses. That's because they're a very convenient data structure
when you're doing things (constructing lists, or reducing across them,
or mapping over them) in a functional way, using recursive functions.
If you don't have them, it makes functional programming a pain, and
trying to program in a functional style in Mathematica is often a real
pain because you don't have conses. Oh, sure, you can fake a cons with
a two-element Mathematica List, but then you either need to
gratuitously flatten things all over the place, or you need to use
convoluted and non-idiomatic things in order to do your mapping and
reducing.
C. Lisp does provide simple syntax for expressing those lists built
out of conses. The parenthesized syntax of Lisp is precisely that: a
simple syntax for representing lists built recursively from conses!
All that remains is that conses are too low-level a representation for
a list datatype. This is a more common complaint (Ron Garret makes the
same complaint elsewhere in this discussion), but I don't really agree
with it either. At some point, and probably sooner rather than later,
you're going to kill the performance of an otherwise perfectly
legitimate algorithm if you don't know what sort of underlying list
representation you have. People are likely to want both
representations depending on the context, so why not provide both and
ensure that the various functions people want to use on abstract lists
work with both representations?
Cheers,
Pillsy
toby
> On 2009-07-24 20:40:39 +0100, Gendarme <endarme...@otmailhay.invaliday> said:
>
> > until installing things on Unix is as painless and reliable as it is on
> > other platforms
>
> This is just meaningless. *Which* Unix(-like) system? Solaris is a
> pain, for sure[*], but the various Debian-derived systems are great.
> OSX varies from better than Debianoid systems (just drop the .app
> directory somewhere suitable) to not-quite-as-good (no easy way of
> uninstalling packages).
.app != OS X package
An app is not a package; it is entirely unmanaged - which is why it's
so easy for non-technical users.
The OS X package system, such as it is, is very primitive compared
even to Solaris svr4 packaging, let alone a truly modern system like
Portage. As you say, there is not even a visible mechanism to remove
packages (I have used OSXPM in the past, but ewwww).
>
> [*] OpenSolaris may be better
Yes, it has an entirely new package system. Boy, we sure waste a lot
of time reinventing the wheel... :)
Pascal J. Bourguignon
Who's fault?
In NeXTSTEP, it was possible to remove installed packages. It's
possible that the feature wasn't perfect, but at least it existed.
This feature has been removed by Apple Computer, Inc. The point is
that we cannot do anything about it, since sources are proprietary.
We can only pray they reintroduce the feature within the next ten
years, and make us pay a hefty price for the new release.
In the meantime, you will excuse me if I prefer to use (and produce
AFAIC) GPL software, on which indeed we will have to reinvent the
wheel, until we reach the current level. And then we will develop new
features as we see fit. It's possible that they won't be better than
the features developed by commercial developers, but at least they'll
be features we can count on, and that nobody will be able to remove
from our software.
--
__Pascal Bourguignon__
Nick Keighley
> Gendarme <endarme...@otmailhay.invaliday> writes:
<snip>
> > IMO this says less about Scala than it does about Unix, and how the
> > latter is still not quite up to snuff in the usability department. In
> > particular, until installing things on Unix is as painless and
> > reliable as it is on other platforms, it will not be a viable
> > competitor to Microsoft on the desktop.
>
> IME "installing things on Unix", if debian and its clones count, is
> painless and reliable, certainly if the software is available as a
> package; less hassle than Windows in fact:
>
> $ sudo apt-get install scala
you've got to be joking...
> If you're not aware that apt/yum whatever will handle dependencies
> nicely and keep your whole system up to date, you can't have used linux
> in quite a while because although this used to mark debian out now
> just about every modern distro has good package management. Of the other
> *NIXes FreeBSD is just as good, probably the others too.
I think this rather illustrates the point about the unfriendliness
of Unix installations! I shouldn't *need* to know about a whole
alphabet soup of mnemonics in order to load a piece of software
onto my computer.
Pascal J. Bourguignon
Right. You shouldn't have to know a whole alphabet soup of mnemonics
in order to post on usenet either. Start forgetting about "z", you
didn't used it in that post. You coul also forget about "y", you used
it, but I assure you we'd have understood it as well without the "y".
Go on with "x" which is quite useless a alphabetical letter. Don't
stop here. When you can reduce your usenet post to the empty string,
and you'll have forgotten all about alphabet, soups and mnemonic
words, you will be able to go back to parietal pictural expression
(and post them of flickr with a grrh!).
--
__Pascal Bourguignon__
Thomas F. Burdick
wrote:
> "Thomas F. Burdick" <tburd...@gmail.com> writes:
>
> > On Jul 24, 9:46 am, Nicolas Neuss <lastn...@math.uni-karlsruhe.de>
> > wrote:
>
> >> - I'm one of those people who think that Microsoft is the worst thing that
> >> ever happened to software industry.
>
> > [...]
>
> >> - Scala installed with the Ubuntu (Hardy) package system failed to run[*],
>
> > Hmm.
>
Don't know about Scala, but F# did :-)
Andrew Reilly
That's pretty funny. You're happy to cope with a thousand-page language
manual, and an ad-hoc package manager in lisp, but a couple of unix
command lines are beyond you?
I'd say "what's the world coming to", but I'd seem like more of a
curmudgeon than I am, and it's pretty obvious anyway. Over in comp.dsp
they've invented the term "stupidents", which seems fairly appropriate...
Cheers,
--
Andrew
Mark Tarver
wrote:
>
> - Show quoted text -
This is simply juvenile. Nick is making a perfectly valid point about
the Linux mindset which has hindered its general adoption. Knowledge
of the alphabet has what to do with his point?
Mark
Pillsy
wrote:
> On 24 July, 23:40, Jim Burton <j...@sdf-eu.org> wrote:
>
> > Gendarme <endarme...@otmailhay.invaliday> writes:
>
> <snip>
> > IME "installing things on Unix", if debian and its clones count, is
> > painless and reliable, certainly if the software is available as a
> > package; less hassle than Windows in fact:
> > $ sudo apt-get install scala
> you've got to be joking...
Not at all. Compare going to a terminal window and typing a simple
shell command--four words, no use of any remotely advanced features--
to doing the web searching necessary to find the download site,
navigating to the link for download, and running the downloaded
installer. I've never found the latter to be less hassle than the
former, nor does it provide anything like the automatic dependency
management that apt-get does.
> > If you're not aware that apt/yum whatever will handle dependencies
> > nicely and keep your whole system up to date, you can't have used linux
> > in quite a while because although this used to mark debian out now
> > just about every modern distro has good package management. Of the other
> > *NIXes FreeBSD is just as good, probably the others too.
> I think this rather illustrates the point about the unfriendliness
> of Unix installations! I shouldn't *need* to know about a whole
> alphabet soup of mnemonics in order to load a piece of software
> onto my computer.
You need to know about *three* mnemonics to load the software, "sudo",
"apt-get" and "install". That's not much knowledge at all; it's at
least an order of magnitude less than what you'll need to learn in
order to use Scala once you've downloaded it, and you only need to
learn it once.
Cheers,
Pillsy
Jon Harrop
> Jon Harrop wrote:
>> vippstar wrote:
>>> Except that fons is useless while I can see use in cons - I can't
>>> imagine lisp without it. Perhaps you can do that though, so please
>>> explain or link me to an article of yours if you've already done so,
>>> how do you imagine lisp without cons cells.
>>
>> Easy: just treat cons as the special case of a 2-element array. That is
>> essentially what Mathematica does and it works just fine.
>
> 1. Mathematica, last I looked, uses the name List for something that
> most of us would call a vector. Prepending a value to the front of a
> List L, the O(1) operation in Lisp called cons, takes, in Mathematica,
> O(n) time where n is the length of L. This is not "fine" to many
> people. Another operation that Mathematica associates with creating such
> a new data structure is that it goes through all the elements to update
> them -- to see if they depend on some value that has changed recently.
> This is not "fine" to many people.
That is neither relevant nor accurate. We are talking about 2-element arrays
which are obviously O(1). If you want to build sequences efficiently in
Mathematica use Sow and Reap as the documentation describes. The AppendTo
and PrependTo functions do not rewrite their sequence inputs as you claim.
If Mathematica were "not fine to many people" it would not have orders of
magnitude more users than Lisp or anything you have ever written (given
away for free, even).
> As for storing a cons cell as a 2-element array, this is a case of
> economy of storage and operation (for the cons) vs. redundant (larger)
> storage and slower general operation (for the array).
No, it is the case of sacrificing the bit twiddling of cons cells for the
power of a production-quality VM like the JVM or CLR. The benefits those
VMs offer in the context of parallelism alone far outweigh the benefits of
bit twiddled cons cells in any of today's Lisp implementations.
>> I believe the original motivation for separating cons out was performance
>> but, as we know now, that just led to slightly less cripplingly-bad
>> performance.
>
> You are of course free to believe anything at all, but your attestation
> as to the "original motivation" is not particularly credible. Are you
> talking about the roots of Lisp, e.g. Lisp 1.5 and earlier? Are you
> claiming that you have a better instruction sequence for accessing
> elements 0 and 1 of an array than CAR and CDR on the IBM 709X?
> You can read the Lisp 1.5 programmer's manual online:
In other words, it was done for performance exactly as I said.
Jon Harrop
> On Jul 20, 10:04 am, Xah Lee <xah...@gmail.com> wrote:
>> As a illustration, the following 2 tech aspects we can see Scheme's
>> problem: (1) the cons business.
>
> The idea that exposing something as low-level as "cons" is a major
> obstacle to a language's popularity has seems to have two major
> problems.
>
> A. It implicitly depends on the assertion that exposing[1] low-level
> constructs is a major impediment to a language's widespread adoption,
> but C exposes an even lower-level detail than conses, in the form of
> pointers, and doing anything useful in C without understanding
> pointers is virtually impossible. This hasn't prevented C from
> becoming vastly more widely used than Lisp or any of the functional
> languages you often cite as somehow superseding it.
Pointers in C do the job well. Cons cells in Lisp do not.
> B. It's extremely common for functional languages that aren't Lisp to
> have conses as well,
No. They often use the name "cons" to refer to non-empty lists but they are
not cons cells in the Lisp sense.
> If you don't have them, it makes functional programming a pain...
No. In all modern FPL implementations, lists are just another data structure
provided in the standard library. Variant types are the core feature
provided in the language itself that lists are built upon.
> All that remains is that conses are too low-level a representation for
> a list datatype. This is a more common complaint (Ron Garret makes the
> same complaint elsewhere in this discussion), but I don't really agree
> with it either. At some point, and probably sooner rather than later,
> you're going to kill the performance of an otherwise perfectly
> legitimate algorithm if you don't know what sort of underlying list
> representation you have. People are likely to want both
> representations depending on the context, so why not provide both and
> ensure that the various functions people want to use on abstract lists
> work with both representations?
Why not forget about cons cells because they have been of no practical
relevance for several decades?
Marek Kubica
Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
> This is simply juvenile. Nick is making a perfectly valid point about
> the Linux mindset which has hindered its general adoption. Knowledge
> of the alphabet has what to do with his point?
Nick has missed the existence of graphical frontends, thus rendering
the whole argument moot. Start the Package Manager (GUI), search in the
search box what you want to install, click install, done.
regards,
Marek
Pillsy
> Pillsy wrote:
[...]
> > A. It implicitly depends on the assertion that exposing[1] low-level
> > constructs is a major impediment to a language's widespread adoption,
> > but C exposes an even lower-level detail than conses, in the form of
> > pointers, and doing anything useful in C without understanding
> > pointers is virtually impossible. This hasn't prevented C from
> > becoming vastly more widely used than Lisp or any of the functional
> > languages you often cite as somehow superseding it.
> Pointers in C do the job well. Cons cells in Lisp do not.
Assumes facts not in evidence.
> > B. It's extremely common for functional languages that aren't Lisp to
> > have conses as well,
> No. They often use the name "cons" to refer to non-empty lists but they are
> not cons cells in the Lisp sense.
This is not a particularly interesting difference, because it hinges
much more on the different approaches to typing taken by FPLs and Lisp
than anything else.
Of course, I expect this to launch you on a tirade about the evils of
dynamic typing, which is probably a more useful approach than
continuing this nonsensical attack on conses.
[...]
> > If you don't have them, it makes functional programming a pain...
> No. In all modern FPL implementations, lists are just another data structure
> provided in the standard library.
And your point is?
[...]
> > People are likely to want both representations depending on the context,
> > so why not provide both and ensure that the various functions people want to
> > use on abstract lists work with both representations?
> Why not forget about cons cells because they have been of no practical
> relevance for several decades?
If they're of no practical relevance, why provide them in the standard
library?
If they are of practical relevance, why quibble over details of
implementation?
Later,
Pillsy
Jon Harrop
> On Jul 28, 12:29 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Pillsy wrote:
> [...]
>> > A. It implicitly depends on the assertion that exposing[1] low-level
>> > constructs is a major impediment to a language's widespread adoption,
>> > but C exposes an even lower-level detail than conses, in the form of
>> > pointers, and doing anything useful in C without understanding
>> > pointers is virtually impossible. This hasn't prevented C from
>> > becoming vastly more widely used than Lisp or any of the functional
>> > languages you often cite as somehow superseding it.
>
>> Pointers in C do the job well. Cons cells in Lisp do not.
>
> Assumes facts not in evidence.
Pointers remain popular in systems programming languages. Cons died with
Lisp.
>> > B. It's extremely common for functional languages that aren't Lisp to
>> > have conses as well,
>
>> No. They often use the name "cons" to refer to non-empty lists but they
>> are not cons cells in the Lisp sense.
>
> This is not a particularly interesting difference, because it hinges
> much more on the different approaches to typing taken by FPLs and Lisp
> than anything else.
No, it has nothing whatsoever to do with the type system. There is nothing
special about the representation of a non-empty list in languages like SML,
OCaml, Haskell and F#. It is just another variant type constructor.
>> > If you don't have them, it makes functional programming a pain...
>
>> No. In all modern FPL implementations, lists are just another data
>> structure provided in the standard library.
>
> And your point is?
Your statement was totally factually incorrect.
>> > People are likely to want both representations depending on the
>> > context, so why not provide both and ensure that the various functions
>> > people want to use on abstract lists work with both representations?
>
>> Why not forget about cons cells because they have been of no practical
>> relevance for several decades?
>
> If they're of no practical relevance, why provide them in the standard
> library?
Indeed. Get rid of them entirely as all modern FPLs already did.
Pillsy
> > much more on the different approaches to typing taken by FPLs and Lisp
> > than anything else.
> *No, it has nothing whatsoever to do with the type system.* There is nothing
> special about the representation of a non-empty list in languages like SML,
> OCaml, Haskell and F#. *It is just another variant type constructor.*
Emphasis mine. Remind me why should I pay more attention to you than
you pay to yourself?
You still haven't explained why the details of how conses are
implemented (whether as variant types in an FPL,. or as cons cells in
Lisp) is a shortcoming of Lisp. I would hardly be surprised if you to
continue to not explain that, because it's such a self-evidently
idiotic position that I think even you wouldn't want to defend it.
Later,
Pillsy
[...]
Peter Keller
[ snip "them" is meaning cons cell]
>> If they're of no practical relevance, why provide them in the standard
>> library?
>
> Indeed. Get rid of them entirely as all modern FPLs already did.
So, the obvious solution to this conundrum is why don't one of the
people who are stating that cons cell should be removed from the language
implement a small dialect of scheme which in fact does just that. With
an actual kernel of a language people can download and try out, a better
choice can be made. The small dialect doesn't need the full monty of all
of the features of scheme behind it, but enough to show that it would
or wouldn't be a good idea.
-pete
Jon Harrop
> You still haven't explained why the details of how conses are
> implemented (whether as variant types in an FPL,. or as cons cells in
> Lisp) is a shortcoming of Lisp.
They are an obsolete special case, i.e. historical baggage.
Richard Fateman
> Richard Fateman wrote:
>> Jon Harrop wrote:
>>> vippstar wrote:
>>>> Except that fons is useless while I can see use in cons - I can't
>>>> imagine lisp without it. Perhaps you can do that though, so please
>>>> explain or link me to an article of yours if you've already done so,
>>>> how do you imagine lisp without cons cells.
>>> Easy: just treat cons as the special case of a 2-element array. That is
>>> essentially what Mathematica does and it works just fine.
>> 1. Mathematica, last I looked, uses the name List for something that
>> most of us would call a vector. Prepending a value to the front of a
>> List L, the O(1) operation in Lisp called cons, takes, in Mathematica,
>> O(n) time where n is the length of L. This is not "fine" to many
>> people. Another operation that Mathematica associates with creating such
>> a new data structure is that it goes through all the elements to update
>> them -- to see if they depend on some value that has changed recently.
>> This is not "fine" to many people.
>
> That is neither relevant nor accurate. We are talking about 2-element arrays
> which are obviously O(1).
Well, 4 element arrays would also be O(1).
As for the timing, to do Prepend, consider this, in Mathematica:
b1= Table[a[i],{i,1,10}];
b2= Table[a[i],{i,1,100000}];
b3= Table[a[i],{i,1,1000000}];
Timing[Prepend[b1,zero];] --> {0., Null}
/* that's time in seconds, also the suppressed [not printed] answer
because of the ";"*/
Timing[Prepend[b2,zero];] --> {0.032, Null}
Timing[Prepend[b2,zero];] --> {0.203, Null}
The relevance is that Lists in Mathematica are arrays, and arrays are,
generally speaking, unsuitable for making conses because every time you
construct a CONS-like object Mathematica checks to see if it has to
re-evaluate the CAR and CDR, so to speak. Recursively.
So this is not, as I said, just fine. Making a CONS cell in Mathematica
out of this structure would be a very bad idea.
> If you want to build sequences efficiently in
> Mathematica use Sow and Reap as the documentation describes.
Sow and Reap were introduced in Mathematica version 5.0.
I see no reason for you to think that this is efficient, compared to
some other method (unspecified!) to produce the same sequence.
The AppendTo
> and PrependTo functions do not rewrite their sequence inputs as you claim.
I'm not sure what you mean by "rewrite". They construct entirely new
sequences.
> If Mathematica were "not fine to many people" it would not have orders of
> magnitude more users than Lisp or anything you have ever written (given
> away for free, even).
Hm, 1 order of magnitude is, in common usage, a factor of ten.
"Orders of magnitude" would, I suppose, be a factor of 100 or 1000 or more.
According to sourceforge
http://sourceforge.net/projects/maxima/files/
The latest version (April 2009) of windows Maxima (a program written in
Lisp, descendant of Macsyma) and which I wrote parts of, has been
downloaded 27,691 times directly. Who knows how many times it has been
transferred. Another 2500 or so for Linux and Mac OSX.
The previous version (Dec. 2008) was downloaded 36,000 times or so.
Now I don't know how one counts "users" -- Mathematica could count "paid
up licenses" but do you think Mathematica has 100 X 30,000 paid up
licenses? That's 3 million. If each licensee pays on average, say $500,
that means the Mathematica earns $1.5 billion/year. Does this jibe
with your understanding of that company?
That's just Maxima compared to Mathematica.
While I have nothing to do with the implementation of common lisp called
CLISP, I note that sourceforge says it has been downloaded 317,000 times.
This could, of course, be one user downloading it 317,000 times, but I
doubt it. Then there are also scheme implementations, and programs that
link lisp to graphics, java, lapack, ...
And those are just a few of the free programs, add to that the
commercial sales, autocad, and the possible claims that anyone who uses
emacs is a lisp user.
Jon, when you make statements that are so easily disproven, you give
trolling a bad name.
>
>> As for storing a cons cell as a 2-element array, this is a case of
>> economy of storage and operation (for the cons) vs. redundant (larger)
>> storage and slower general operation (for the array).
>
> No, it is the case of sacrificing the bit twiddling of cons cells for the
> power of a production-quality VM like the JVM or CLR.
Are you selling toothpaste? all new, brighter teeth, organic?
My guess is that you are somehow objecting to the use of tagged
pointers, which is often a really good implementation idea.
> The benefits those
> VMs offer in the context of parallelism alone far outweigh the benefits of
> bit twiddled cons cells in any of today's Lisp implementations.
I can't imagine why you think that the overhead of a virtual machine is
(what, faster?) than, or incompatible with, tagged pointers. Or why
tagged pointers are incompatible with parallelism.
Perhaps you would turn your keen eye to comparing the benefits of real
memory management and a quality garbage collector (as in some Lisps) to
the state of the art in JVM or similar memory management?
>>>(JH) I believe the original motivation for separating cons out was performance
>>> but, as we know now, that just led to slightly less cripplingly-bad
>>> performance.
>> (RJF) You are of course free to believe anything at all, but your attestation
>> as to the "original motivation" is not particularly credible. Are you
>> talking about the roots of Lisp, e.g. Lisp 1.5 and earlier? Are you
>> claiming that you have a better instruction sequence for accessing
>> elements 0 and 1 of an array than CAR and CDR on the IBM 709X?
>> You can read the Lisp 1.5 programmer's manual online:
>
> In other words, it was done for performance exactly as I said.
Uh, I guess you are free to claim that you agree with me.
It is presumptuous of you to claim that I agree with you. The point you
seem determined to miss is that CAR and CDR were not somehow second
choice abstractions compared to (say) arrays, some sacrifice in the name
of efficiency. Indeed the concept of "ordered pair" is in some sense an
extraordinarily powerful tool for building anything, and this was
realized fairly early. AND, as it happens, easy/fast to implement on
most machines.
RJF
Jon Harrop
> Jon Harrop wrote:
>> That is neither relevant nor accurate. We are talking about 2-element
>> arrays which are obviously O(1).
>
> Well, 4 element arrays would also be O(1).
> As for the timing, to do Prepend, consider this, in Mathematica:
>
> b1= Table[a[i],{i,1,10}];
> b2= Table[a[i],{i,1,100000}];
> b3= Table[a[i],{i,1,1000000}];
>
> Timing[Prepend[b1,zero];] --> {0., Null}
>
> /* that's time in seconds, also the suppressed [not printed] answer
> because of the ";"*/
>
> Timing[Prepend[b2,zero];] --> {0.032, Null}
> Timing[Prepend[b2,zero];] --> {0.203, Null}
You are timing the creation of an array with 10^5 elements. We are talking
about 2-element arrays...
> The relevance is that Lists in Mathematica are arrays, and arrays are,
> generally speaking, unsuitable for making conses because every time you
> construct a CONS-like object Mathematica checks to see if it has to
> re-evaluate the CAR and CDR, so to speak. Recursively.
As an aside, the time stamp on the first cons should cause Mathematica to
stop rewriting immediately. However, this has nothing to do with the topic
of conversation: replacing cons with 2-element arrays in a Lisp.
> So this is not, as I said, just fine.
Nor is it relevant.
>> If you want to build sequences efficiently in
>> Mathematica use Sow and Reap as the documentation describes.
>
> Sow and Reap were introduced in Mathematica version 5.0.
> I see no reason for you to think that this is efficient, compared to
> some other method (unspecified!) to produce the same sequence.
RTFM.
>> If Mathematica were "not fine to many people" it would not have orders of
>> magnitude more users than Lisp or anything you have ever written (given
>> away for free, even).
>
> Hm, 1 order of magnitude is, in common usage, a factor of ten.
> "Orders of magnitude" would, I suppose, be a factor of 100 or 1000 or
> more.
Yes.
> According to sourceforge
> http://sourceforge.net/projects/maxima/files/
>
> The latest version (April 2009) of windows Maxima (a program written in
> Lisp, descendant of Macsyma) and which I wrote parts of, has been
> downloaded 27,691 times directly. Who knows how many times it has been
> transferred. Another 2500 or so for Linux and Mac OSX.
>
> The previous version (Dec. 2008) was downloaded 36,000 times or so.
>
> Now I don't know how one counts "users" -- Mathematica could count "paid
> up licenses" but do you think Mathematica has 100 X 30,000 paid up
> licenses? That's 3 million.
>
> If each licensee pays on average, say $500, that means the Mathematica
> earns $1.5 billion/year.
The most common Mathematica licence is only $50. You seriously think those
Mathematica users upgrade every 5 weeks?
> Does this jibe with your understanding of that company?
Stephen Wolfram is now a billionaire thanks to sales of Mathematica. That
equates to 1e9/50 = 20,000,000 student licenses sold. In reality, WRI will
have pulled in far more than $1bn in licenses because they have significant
overheads (like paying hundreds of employees for decades).
So yes, I can easily believe that Mathematica has millions of active users.
> That's just Maxima compared to Mathematica.
>
> While I have nothing to do with the implementation of common lisp called
> CLISP, I note that sourceforge says it has been downloaded 317,000 times.
> This could, of course, be one user downloading it 317,000 times, but I
> doubt it.
You think hundreds of thousands of people are programming with clisp?
Ubuntu lists 4,273 clisp installs of which only 112 are actively used. I
seriously doubt clisp has over 1,000 users.
> Then there are also scheme implementations, and programs that
> link lisp to graphics, java, lapack, ...
How is that relevant?
> ...anyone who uses emacs is a lisp user...
That's hilarious.
Even if you count end users, the Ubuntu popcon gives under 100k emacs
installs ever (the vast majority of whom know nothing about Lisp) whereas
Wolfram Alpha pulled in a million users in a single month.
> Jon, when you make statements that are so easily disproven, you give
> trolling a bad name.
Yes, you didn't have to clutch at extraordinarily long straws to "prove"
that at all.
>>> As for storing a cons cell as a 2-element array, this is a case of
>>> economy of storage and operation (for the cons) vs. redundant (larger)
>>> storage and slower general operation (for the array).
>>
>> No, it is the case of sacrificing the bit twiddling of cons cells for the
>> power of a production-quality VM like the JVM or CLR.
>
> Are you selling toothpaste? all new, brighter teeth, organic?
Eh?
>> The benefits those
>> VMs offer in the context of parallelism alone far outweigh the benefits
>> of bit twiddled cons cells in any of today's Lisp implementations.
>
> I can't imagine why you think that the overhead of a virtual machine is
> (what, faster?) than, or incompatible with, tagged pointers.
Oh, you're going to implement cons cells in the JVM or CLR?
> Or why tagged pointers are incompatible with parallelism.
You would have to implement a Lisp with a production-quality concurrent GC.
That is certainly possible but nobody has actually done it yet.
> Perhaps you would turn your keen eye to comparing the benefits of real
> memory management and a quality garbage collector (as in some Lisps) to
> the state of the art in JVM or similar memory management?
Turn my eye to the topic I have been discussing all along?
>>>>(JH) I believe the original motivation for separating cons out was
>>>>performance
>>>> but, as we know now, that just led to slightly less cripplingly-bad
>>>> performance.
>>> (RJF) You are of course free to believe anything at all, but your
>>> attestation
>>> as to the "original motivation" is not particularly credible. Are you
>>> talking about the roots of Lisp, e.g. Lisp 1.5 and earlier? Are you
>>> claiming that you have a better instruction sequence for accessing
>>> elements 0 and 1 of an array than CAR and CDR on the IBM 709X?
>>> You can read the Lisp 1.5 programmer's manual online:
>>
>> In other words, it was done for performance exactly as I said.
>
> Uh, I guess you are free to claim that you agree with me.
>
> It is presumptuous of you to claim that I agree with you. The point you
> seem determined to miss is that CAR and CDR were not somehow second
> choice abstractions compared to (say) arrays, some sacrifice in the name
> of efficiency. Indeed the concept of "ordered pair" is in some sense an
> extraordinarily powerful tool for building anything, and this was
> realized fairly early. AND, as it happens, easy/fast to implement on
> most machines.
A 2-element array is an ordered pair. Indeed, that was the whole point...
Peter Keller
>> You still haven't explained why the details of how conses are
>> implemented (whether as variant types in an FPL,. or as cons cells in
>> Lisp) is a shortcoming of Lisp.
>
> They are an obsolete special case, i.e. historical baggage.
So, why does the C++ STL have Pair? It is a special case of Vector. Why
not get rid of Pair from the STL and rewrite all of the codes to use a
Vector instead?
If you can show how your argument works in this case, where the
fundamental aspect of the C++ language and its libraries don't utilize
the exposed pair, like they do in Scheme, maybe people would understand
better.
-pete
Dimiter "malkia" Stanev
Ditto. With Debian I'm finding installing apps easier and easier. I wish
Mac OS X, and Windows were up to that.
But I know that this is due to the work of lots of people - sometimes
for each package a person maintaining it. That's a lot of people's work
just to make sure that the package compiles, works and communicates well
with other packages.
Occasionally I'm getting stuck though, especially when I checkout
something directly from source, then ./configure it, and then I'm lost -
should I install it in /usr/local/include, or should I create a package
for it and install it... etc... It's exactly those details (that are
known to a maintainer) that scare me... :)
Back on Windows/MAC OS X - I just always use the source code version,
put them in one folder, do some little connections and I'm done. I could
do that on Linux too - but I'm always tempted to use the -dev packages
from the installation... until it starts hurting
Rainer Joswig
> As an aside, the time stamp on the first cons should cause Mathematica to
> stop rewriting immediately. However, this has nothing to do with the topic
> of conversation: replacing cons with 2-element arrays in a Lisp.
Yeah, let's talk about that. Why would you replace cons cells with 2-
element arrays?