fft1976 wrote:
> Found this on Reddit: http://www.reddit.com/r/programming/comments/8l3bq/wolfram_and_lisp/
>
> Are LISP programmers still bitter that Wolfram chose C instead of LISP?
Any competitive advantage C might have once had is long gone. Being 2-5
slower as C but much more productive by choosing a HLL like Lisp,
Haskell, OCaml, Java or C# is the rule today. Heck, even scripting
languages 100x slower than C are the rule today.
I remember Xah Lee was nuts about Wolfram.
On May 19, 7:07 am, namekuseijin <···················@gmail.com>
wrote:
> fft1976 wrote:
> > Found this on Reddit:http://www.reddit.com/r/programming/comments/8l3bq/wolfram_and_lisp/
> > Are LISP programmers still bitter that Wolfram chose C instead of LISP?
> Any competitive advantage C might have once had is long gone.
I'm unsure that there was any competitive advantage for Mathematica,
given what a monument to Greenspun's Tenth Law it is (although the ad
hoc, informally-specified half-implementations don't stop with Common
Lisp.) I just wish WRI hadn't *stopped* Greenspunning before they got
to UNWIND-PROTECT abd HANDLER-BIND.
It's got a great "standard library", though.
Cheers,
Pillsy
···@zedat.fu-berlin.de (Stefan Ram) writes:
> namekuseijin <···················@gmail.com> writes:
>>Any competitive advantage C might have once had is long gone. Being 2-5
>>slower as C but much more productive by choosing a HLL like Lisp,
>>Haskell, OCaml, Java or C# is the rule today. Heck, even scripting
>>languages 100x slower than C are the rule today.
>
> �Here's the thing: C is everywhere. Recently Tim Bray made
> basically the same point; all the major operating systems,
> all the high-level language runtimes, all the databases,
> and all major productivity applications are written in C.�
>
> http://girtby.net/archives/2008/08/23/in-defence-of-c/
But this argument is nullified by open source and the Internet. For
20 years now, any language is as anywhere as C, since, in the worst
case, you only have to download the sources (and/or binaries) from the
Internet. (And the same is true for libraries, notwhistanding the
whiners who would like things to be more automatic or oblivious).
A good example is darcs. I've never seen any complain that darcs is
programmed in Haskell. Why? Because when you compile/install darcs,
the makefile downloads and install ghc if it wasn't already present on
the system.
Lisp programmers shouldn't hesitate to follow darcs' example (ie. to
distribute their lisp programs to random systems, along with a lisp
implementation).
> �=head2 What language is Parrot written in?
>
> C.
>
> =head2 For the love of God, man, why?!?!?!?
>
> Because it's the best we've got.�
>
> http://search.cpan.org/src/SFINK/parrot-0.0.11.2/docs/faq.pod
Well, today I ate a mtabbal. That's the best I got (for the money I
had). If I was 100,000 times richer, I could have had caviar. That
would have been the best I'd have got.
The difference is that Lisp is a wget away, you don't need to be
100,000 richer...
So this argument is ridiculous.
> �I've come to the conclusion that any programmer that would
> prefer the project to be in C++ over C is likely a
> programmer that I really *would* prefer to [move on], so
> that he doesn't come and [disturb] any project I'm
> involved with. (...)� (Linus Torvalds, 2007)
>
> http://lwn.net/Articles/249460/
Well, between C and C++ you can argue.
> The TIOBE Programming Community Index for May 2009 shows a larger
> popularity for C than for C++:
>
> http://www.tiobe.com/content/paperinfo/tpci/index.html
Idem.
> �Web server? Compilers? Operating Systems? To program
> anything interesting, you need to know a whole lot of C.�
>
> http://www.stifflog.com/2007/02/18/language-of-the-gods-c/
There are several web servers written in Common Lisp, scheme (or even
emacs lisp) too.
There are several compilers written in Common Lisp, scheme (or even
emacs lisp) too. Most of the most advanced programming language were
once implemened in Lisp actually.
There are several OS written in Common Lisp, scheme, or lisp (or even
emacs can be considered an OS) too.
So this argument is nullified to. It may be a reference to the
popularity argument, but this is something else.
--
__Pascal Bourguignon__
>>>>> "Pascal" == Pascal J Bourguignon <···@informatimago.com> writes:
Pascal> ···@zedat.fu-berlin.de (Stefan Ram) writes:
>> namekuseijin <···················@gmail.com> writes:
>>> Any competitive advantage C might have once had is long gone. Being 2-5
>>> slower as C but much more productive by choosing a HLL like Lisp,
>>> Haskell, OCaml, Java or C# is the rule today. Heck, even scripting
>>> languages 100x slower than C are the rule today.
>>
>> �Here's the thing: C is everywhere. Recently Tim Bray made
>> basically the same point; all the major operating systems,
>> all the high-level language runtimes, all the databases,
>> and all major productivity applications are written in C.�
>>
>> http://girtby.net/archives/2008/08/23/in-defence-of-c/
Pascal> But this argument is nullified by open source and the Internet. For
Pascal> 20 years now, any language is as anywhere as C, since, in the worst
Pascal> case, you only have to download the sources (and/or binaries) from the
Pascal> Internet. (And the same is true for libraries, notwhistanding the
Pascal> whiners who would like things to be more automatic or oblivious).
Pascal> A good example is darcs. I've never seen any complain that darcs is
Pascal> programmed in Haskell. Why? Because when you compile/install darcs,
Pascal> the makefile downloads and install ghc if it wasn't already present on
Pascal> the system.
Ah, if it were really this simple. I tried that a while back on my
Mac. I don't remember all the details, but I think it failed to
download ghc. I hacked so that it could. Then ghc refused to build.
And on top of that it wanted to replace some system libraries with its
own versions, which I stupidly allowed. My Mac still works, but I
wonder what damage I've done.
In the end, I decided I didn't really need darcs or Haskell.
Portable code isn't.
YMMV. All Sales Final. No Refund, No Exchange.
Ray
On May 19, 5:15 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> > »I've come to the conclusion that any programmer that would
> > prefer the project to be in C++ over C is likely a
> > programmer that I really *would* prefer to [move on], so
> > that he doesn't come and [disturb] any project I'm
> > involved with. (...)« (Linus Torvalds, 2007)
>
> >http://lwn.net/Articles/249460/
>
> Well, between C and C++ you can argue.
I think Wolfram dealt a devastating blow to LISP by spurning it very
publicly and choosing C to write Mathematica. So how about a Git in
LISP?
I wonder what this Linux Torvalds fella would say about LISP? "All
CONS, no PROS" or something like that?
"fft1976" <·······@gmail.com> wrote in message
·········································@b1g2000vbc.googlegroups.com...
On May 19, 5:15 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> > �I've come to the conclusion that any programmer that would
> > prefer the project to be in C++ over C is likely a
> > programmer that I really *would* prefer to [move on], so
> > that he doesn't come and [disturb] any project I'm
> > involved with. (...)� (Linus Torvalds, 2007)
>
> >http://lwn.net/Articles/249460/
>
> Well, between C and C++ you can argue.
<
I think Wolfram dealt a devastating blow to LISP by spurning it very
publicly and choosing C to write Mathematica. So how about a Git in
LISP?
I wonder what this Linux Torvalds fella would say about LISP? "All
CONS, no PROS" or something like that?
>
they are not that much suited to the same things I think.
LISP is good at doing fancy things;
C is good at doing things fast (and deriving lots of flexibility from its
lowlevelness...).
LISP can't do many things C does well, nor does it interface so well with
this otherwise C-based world;
C can be made to do many things LISP can do, even if not by default, and
winning no real prize in "elegance"...
LISP uses S-Exps (thus, a syntax both obscure and often disliked by people);
C uses a relatively fammiliar syntax (granted not one always well liked).
typically, people desire a language that does most common things acceptably,
than a language which does some (relatively obscure) things well, but
everything else not so well, if at all...
on average, these tradeoffs favor C...
as noted, C can be used to implement much of LISP's featureset, including:
Garbage Collection; Dynamic Types; CONS, Lists, Symbols and Keywords, ...
(this is done via making all of this work via an API...).
closures can be faked purely in C, but with implementing an (in-app)
assembler, one can give them the "look and feel" of real function pointers
(in the "closure" itself, scope-capture, ... can be done manually...).
likewise, C compilers can have them added as an extension (all this done by
the compiler+runtime), though granted "language extensions" may fall outside
the definition.
having implemented much of a compiler framework, I gain additional
abilities:
I can dynamically compile code fragments (and patch many pieces of existing
code, ...);
reflection is possible (via lots of metadata "mined" by said compiler
framework);
...
FWIW, if we allow a "defmacro" consisting of printing C syntax into a buffer
and feeding it through "eval", this can be done as well...
and, as well, C goes on doing the things C does so well...
so, in a general sense, they are not so evenly matched, C shows the net
advantage...
On Jun 2, 1:28 pm, "cr88192" <·······@hotmail.com> wrote:
> "fft1976" <·······@gmail.com> wrote in message
>
> ·········································@b1g2000vbc.googlegroups.com...
> On May 19, 5:15 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > > »I've come to the conclusion that any programmer that would
> > > prefer the project to be in C++ over C is likely a
> > > programmer that I really *would* prefer to [move on], so
> > > that he doesn't come and [disturb] any project I'm
> > > involved with. (...)« (Linus Torvalds, 2007)
>
> > >http://lwn.net/Articles/249460/
>
> > Well, between C and C++ you can argue.
>
> <
> I think Wolfram dealt a devastating blow to LISP by spurning it very
> publicly and choosing C to write Mathematica. So how about a Git in
> LISP?
>
> I wonder what this Linux Torvalds fella would say about LISP? "All
> CONS, no PROS" or something like that?
>
>
>
> they are not that much suited to the same things I think.
>
> LISP is good at doing fancy things;
> C is good at doing things fast (and deriving lots of flexibility from its
> lowlevelness...).
>
> LISP can't do many things C does well, nor does it interface so well with
> this otherwise C-based world;
> C can be made to do many things LISP can do, even if not by default, and
> winning no real prize in "elegance"...
>
> LISP uses S-Exps (thus, a syntax both obscure and often disliked by people);
> C uses a relatively fammiliar syntax (granted not one always well liked).
>
> typically, people desire a language that does most common things acceptably,
> than a language which does some (relatively obscure) things well, but
> everything else not so well, if at all...
>
> on average, these tradeoffs favor C...
>
> as noted, C can be used to implement much of LISP's featureset, including:
> Garbage Collection; Dynamic Types; CONS, Lists, Symbols and Keywords, ...
> (this is done via making all of this work via an API...).
>
> closures can be faked purely in C, but with implementing an (in-app)
> assembler, one can give them the "look and feel" of real function pointers
> (in the "closure" itself, scope-capture, ... can be done manually...).
> likewise, C compilers can have them added as an extension (all this done by
> the compiler+runtime), though granted "language extensions" may fall outside
> the definition.
>
> having implemented much of a compiler framework, I gain additional
> abilities:
> I can dynamically compile code fragments (and patch many pieces of existing
> code, ...);
> reflection is possible (via lots of metadata "mined" by said compiler
> framework);
> ...
>
> FWIW, if we allow a "defmacro" consisting of printing C syntax into a buffer
> and feeding it through "eval", this can be done as well...
>
> and, as well, C goes on doing the things C does so well...
>
> so, in a general sense, they are not so evenly matched, C shows the net
> advantage...
Agreed, implementing Lisp in C does give C an advantage.
On Jun 2, 8:28 pm, "cr88192" <·······@hotmail.com> wrote:
> as noted, C can be used to implement much of LISP's featureset, including:
> Garbage Collection; Dynamic Types; CONS, Lists, Symbols and Keywords, ...
> (this is done via making all of this work via an API...).
>
> closures can be faked purely in C, but with implementing an (in-app)
> assembler, one can give them the "look and feel" of real function pointers
> (in the "closure" itself, scope-capture, ... can be done manually...).
> likewise, C compilers can have them added as an extension (all this done by
> the compiler+runtime), though granted "language extensions" may fall outside
> the definition.
>
> having implemented much of a compiler framework, I gain additional
> abilities:
> I can dynamically compile code fragments (and patch many pieces of existing
> code, ...);
> reflection is possible (via lots of metadata "mined" by said compiler
> framework);
> ...
>
> FWIW, if we allow a "defmacro" consisting of printing C syntax into a buffer
> and feeding it through "eval", this can be done as well...
So, you've recalled the infamous Greenspun's 10th ;)
>
> and, as well, C goes on doing the things C does so well...
Yes, but doesn't start doing WELL the things Lisp does well...
Best regards,
Vsevolod Dyomkin
"Vsevolod Dyomkin" <········@gmail.com> wrote in message
·········································@21g2000vbk.googlegroups.com...
> On Jun 2, 8:28 pm, "cr88192" <·······@hotmail.com> wrote:
>> as noted, C can be used to implement much of LISP's featureset,
>> including:
>> Garbage Collection; Dynamic Types; CONS, Lists, Symbols and Keywords, ...
>> (this is done via making all of this work via an API...).
>>
>> closures can be faked purely in C, but with implementing an (in-app)
>> assembler, one can give them the "look and feel" of real function
>> pointers
>> (in the "closure" itself, scope-capture, ... can be done manually...).
>> likewise, C compilers can have them added as an extension (all this done
>> by
>> the compiler+runtime), though granted "language extensions" may fall
>> outside
>> the definition.
>>
>> having implemented much of a compiler framework, I gain additional
>> abilities:
>> I can dynamically compile code fragments (and patch many pieces of
>> existing
>> code, ...);
>> reflection is possible (via lots of metadata "mined" by said compiler
>> framework);
>> ...
>>
>> FWIW, if we allow a "defmacro" consisting of printing C syntax into a
>> buffer
>> and feeding it through "eval", this can be done as well...
>
> So, you've recalled the infamous Greenspun's 10th ;)
>
maybe...
>>
>> and, as well, C goes on doing the things C does so well...
>
> Yes, but doesn't start doing WELL the things Lisp does well...
>
well, it does well the things it does well...
those things which end up being hacked on, it can do, sort of...
>
> Best regards,
> Vsevolod Dyomkin
On Jun 2, 2:24 pm, Vsevolod Dyomkin <········@gmail.com> wrote:
> On Jun 2, 8:28 pm, "cr88192" <·······@hotmail.com> wrote:
>
>
>
>
>
> > as noted, C can be used to implement much of LISP's featureset, including:
> > Garbage Collection; Dynamic Types; CONS, Lists, Symbols and Keywords, ...
> > (this is done via making all of this work via an API...).
>
> > closures can be faked purely in C, but with implementing an (in-app)
> > assembler, one can give them the "look and feel" of real function pointers
> > (in the "closure" itself, scope-capture, ... can be done manually...).
> > likewise, C compilers can have them added as an extension (all this done by
> > the compiler+runtime), though granted "language extensions" may fall outside
> > the definition.
>
> > having implemented much of a compiler framework, I gain additional
> > abilities:
> > I can dynamically compile code fragments (and patch many pieces of existing
> > code, ...);
> > reflection is possible (via lots of metadata "mined" by said compiler
> > framework);
> > ...
>
> > FWIW, if we allow a "defmacro" consisting of printing C syntax into a buffer
> > and feeding it through "eval", this can be done as well...
>
> So, you've recalled the infamous Greenspun's 10th ;)
>
>
>
> > and, as well, C goes on doing the things C does so well...
>
> Yes, but doesn't start doing WELL the things Lisp does well...
As the saying goes, to a man who only knows how to use a hammer,
everything looks like a nail.
It seems to me that writing operating systems, database systems, and
simple filter operators like grep might be good candidates for C.
And it seems to me that writing things like Autocad extensions or
theorem provers might be good candidates for lisp.
Of course, there will be some overlap where either tool will perform
equally well to solve the task, especially dependent upon the skills
of the resources at hand.
At any rate, tool are useful to accomplish successful job completion.
A good craftsman knows how to use a number of them, and the more the
better.
IMO-YMMV
P.S.
"Which language is better?" posted to multiple language groups is
literally *always* a troll. So we've all been had, I am sure.
From: Pascal J. Bourguignon
Subject: Re: Using C for competitive advantage
Date:
Message-ID: <87zlcpdlrl.fsf@galatea.local>
user923005 <·······@connx.com> writes:
> "Which language is better?" posted to multiple language groups is
> literally *always* a troll. So we've all been had, I am sure.
Definitely. Since the last two weeks of trolling between
comp.lang.lisp and comp.programming.java, I try to remember removing
all the newsgroups but the one I read it from, from my answer.
--
__Pascal Bourguignon__
> So how about a Git in LISP?
Well, there is one distributed version control system written in
a high-level functional language, Darcs[1], which is written in Haskell.
Darcs and Git fill fairly close ecological niches, and it is interesting
to compare the two to see how the differences in programming languages
influence the final design.
Git is much faster than Darcs; Git will grab half a gig of data in
seconds, where Darcs collapses at a few hundred megabytes.
Darcs has a friendly user interface, with just a couple dozen different
commands. Most Darcs commands are extremely powerful, and work in
a variety of circumstances.
This is very much unlike Git, which has 135 commands, most of which
perform extremely low-level activities. As a case in point, Git has
7 different merge commands, all of which are useful in different
circumstances. Darcs has 0 -- merges are performed automatically, as
a side-effect of a pull.
Juliusz
Reinventing LISP in C is not how C is meant to be used, is it?
Before some LISP code monkey quotes Greenspun, tell me, does Linux
reinvent LISP, or is Linux insufficiently complex? What about Git?
By the way, closures are not runtime-generated code!
On 2009-06-03, fft1976 <·······@gmail.com> wrote:
> By the way, closures are not runtime-generated code!
No, but in Lisp we /can/ generate code at run-time and compile it to a closure.
You are right in that this is not an inherent capability of closures;
some languages have closures, but no run-time code generation.
From: Pascal J. Bourguignon
Subject: Re: Using C for competitive advantage
Date:
Message-ID: <874ouxf0gc.fsf@galatea.local>
fft1976 <·······@gmail.com> writes:
> Reinventing LISP in C is not how C is meant to be used, is it?
Mu. The question is what the requirements are, what specifications
must you implement?
If the program you have to implement requires Lisp, then use Lisp. If
you are forbidden to use Lisp, then use C, greenspun, and leave a
happy customer. Otherwise you should resign.
> Before some LISP code monkey quotes Greenspun, tell me, does Linux
> reinvent LISP, or is Linux insufficiently complex? What about Git?
Probably, their specifications don't require Lisp. That's probably
their main problem, and in that aspect, I'd concur with their critics.
> By the way, closures are not runtime-generated code!
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Probably, their specifications don't require Lisp. That's probably
> their main problem, and in that aspect, I'd concur with their critics.
Specifications that don't require LISP is a problem?
"fft1976" <·······@gmail.com> wrote in message
·········································@37g2000yqp.googlegroups.com...
> Reinventing LISP in C is not how C is meant to be used, is it?
>
but, it is very useful for some tasks, and can be used along with good old
traditional C practices...
> Before some LISP code monkey quotes Greenspun, tell me, does Linux
> reinvent LISP, or is Linux insufficiently complex? What about Git?
>
Linux does not, but Linux does not need to for what it does (as an OS...).
> By the way, closures are not runtime-generated code!
runtime code generation, however, is one way to get closures in C...
this is actually because of a subtle issue in how C is usually implemented:
a function pointer is just a raw address to some code, so to call it, more
or less the call-frame is set up, and control is transferred to this
address...
often, there is no other context for this function available.
so, one can generate a new piece of code, which itself knows where the
captured state is, and so can pass it on to the closed-over function (in the
implementation, for example, as a hidden argument...).
the actual underlying mechanisms, however, are far more general and powerful
than something just "getting LISP implemented in C...".
FWIW, I will note that my compiler represents its AST's in XML, and not
S-Exps... (the reason is that XML is actually more flexible and adaptable...
even if heavier weight and more effort to work with...).
this may well be part of why XML eats S-Exps' cake, as for all their merit
S-Exps would seem to have a notable flaw for general-purpose data
processing: in non-trivial cases they are about as flexible as if the
structure were made of glass... (in XML you can almost always add a new
attribute or namespace to fudge around whatever comes up, but S-Exps tend to
provide no real way to "bend" the structure with new data, only the
combination of so many 'forms'...).
so, one can't usually bend the forms, and instead adaptations may tend to
require fundamental alterations to the structure, ...
although, sadly, XML does have its performance costs... and, yes, I still do
use S-Exps in more than a few places...
On 2009-06-05 21:29:39 -0400, "cr88192" <·······@hotmail.com> said:
> this may well be part of why XML eats S-Exps' cake, as for all their merit
> S-Exps would seem to have a notable flaw for general-purpose data
> processing: in non-trivial cases they are about as flexible as if the
> structure were made of glass... (in XML you can almost always add a new
> attribute or namespace to fudge around whatever comes up, but S-Exps tend to
> provide no real way to "bend" the structure with new data, only the
> combination of so many 'forms'...).
Many of us here think it's the other way round.
from: <http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf>
" XML is touted as an external format for representing data.
This is not a hard problem. All we require are two proper-
ties:
• Self-describing From the external representation one
should be able to derive the corresponding internal
representation.
• Round-tripping If one converts from an internal rep-
resentation to the external representation and back
again, the new internal representation should equal the
old.
Lisp S-expressions, for example, possess these properties.
XML has neither property. It is not always self-describing,
since the internal format corresponding to an external XML
description depends crucially on the XML Schema that is
used for validation (for instance, to tell whether data is an
integer or a string). And it is not always round-tripping,
since some pathological Schemas lack this property (for in-
stance, if there is a type union of integers and strings). So
the essence of XML is this: the problem it solves is not hard,
and it does not solve the problem well."
--
Raffael Cavallaro
Raffael Cavallaro <················@pas.espam.s.il.vous.plait.mac.com> writes:
> On 2009-06-05 21:29:39 -0400, "cr88192" <·······@hotmail.com> said:
>
>> this may well be part of why XML eats S-Exps' cake, as for all their merit
>> S-Exps would seem to have a notable flaw for general-purpose data
>> processing: in non-trivial cases they are about as flexible as if the
>> structure were made of glass... (in XML you can almost always add a new
>> attribute or namespace to fudge around whatever comes up, but S-Exps tend to
>> provide no real way to "bend" the structure with new data, only the
>> combination of so many 'forms'...).
>
> Many of us here think it's the other way round.
>
> from: <http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf>
>
> " XML is touted as an external format for representing data.
> This is not a hard problem. All we require are two proper-
> ties:
> ~ Self-describing From the external representation one
> should be able to derive the corresponding internal
> representation.
> ~ Round-tripping If one converts from an internal rep-
> resentation to the external representation and back
> again, the new internal representation should equal the
> old.
>
> Lisp S-expressions, for example, possess these properties.
>
> XML has neither property. It is not always self-describing,
> since the internal format corresponding to an external XML
> description depends crucially on the XML Schema that is
> used for validation (for instance, to tell whether data is an
> integer or a string). And it is not always round-tripping,
> since some pathological Schemas lack this property (for in-
> stance, if there is a type union of integers and strings). So
> the essence of XML is this: the problem it solves is not hard,
> and it does not solve the problem well."
Right... as long as XML documents cannot be understood without
reference to a system/application/whatever, it is only a solution to
the "quoting" problem - a mechanism for describing data using a
limited alphabet, and a facility for quoting symbols that would
otherwise be interpreted as belonging to the set of "control"
symbols.
Now, in XML there are certain code points that are illegal
(even in encoded form), and the quoting mechanisms are none too good,
so I'd be happy to agree with your conclusion. The only advantage to
XML is that there are a fair number of decent libraries available for
parsing/constructing XML. On the other hand, because XML appears to
be so simple, there is no shortage of programmers that implement their
own XML parsers/builders - and get it wrong.
On 2009-06-06, cr88192 <·······@hotmail.com> wrote:
> FWIW, I will note that my compiler represents its AST's in XML, and not
> S-Exps... (the reason is that XML is actually more flexible and adaptable...
> even if heavier weight and more effort to work with...).
You're using character strings for representing trees inside a compiler?
From: Pascal J. Bourguignon
Subject: Re: Using C for competitive advantage
Date:
Message-ID: <87k53pcs7f.fsf@galatea.local>
"cr88192" <·······@hotmail.com> writes:
> this may well be part of why XML eats S-Exps' cake, as for all their merit
> S-Exps would seem to have a notable flaw for general-purpose data
> processing: in non-trivial cases they are about as flexible as if the
> structure were made of glass... (in XML you can almost always add a new
> attribute or namespace to fudge around whatever comes up, but S-Exps tend to
> provide no real way to "bend" the structure with new data, only the
> combination of so many 'forms'...).
>
> so, one can't usually bend the forms, and instead adaptations may tend to
> require fundamental alterations to the structure, ...
>
>
> although, sadly, XML does have its performance costs... and, yes, I still do
> use S-Exps in more than a few places...
http://groups.google.com/groups/search?safe=off&q=xml+author%3Aerik+author%3Anaggum&btnG=Search&sitesearch=
--
__Pascal Bourguignon__
fft1976 wrote:
....
>
> I think Wolfram dealt a devastating blow to LISP by spurning it very
> publicly and choosing C to write Mathematica. So how about a Git in
> LISP?
Just as Wolfram dealt a devastating blow to scientific computing and
differential equations by claiming that the world is a cellular
automaton. :)
On Jun 3, 12:29 pm, Richard Fateman <·······@cs.berkeley.edu> wrote:
> Just as Wolfram dealt a devastating blow to scientific computing and
> differential equations by claiming that the world is a cellular
> automaton. :)
Did he really claim that, or did he propose it as a hypothesis to
consider? Do you disagree that Wolfram is a genius, btw?
fft1976 <·······@gmail.com> writes:
> Do you disagree that Wolfram is a genius, btw?
Wolfram is certainly a genius. He is also an insufferable git.
--
Aatu Koskensilta (················@uta.fi)
"Wovon mann nicht sprechen kann, dar�ber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
On 4 June, 12:56, Aatu Koskensilta <················@uta.fi> wrote:
> fft1976 <·······@gmail.com> writes:
> > Do you disagree that Wolfram is a genius, btw?
>
> Wolfram is certainly a genius. He is also an insufferable git.
Who is the greatest genius, Archimedes Plutonium or Wolfram?
Does Wolfram have any plutonium atoms in his brain?
Aatu Koskensilta <················@uta.fi> wrote:
> fft1976 <·······@gmail.com> writes:
>
> > Do you disagree that Wolfram is a genius, btw?
>
> Wolfram is certainly a genius. He is also an insufferable git.
The two often go together...
> "Wovon mann nicht sprechen kann, dar�ber muss man schweigen"
> - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
...point in case.
Richard
On Jun 4, 4:56 am, Aatu Koskensilta <················@uta.fi> wrote:
> fft1976 <·······@gmail.com> writes:
> > Do you disagree that Wolfram is a genius, btw?
>
> Wolfram is certainly a genius. He is also an insufferable git.
>
You are probably thinking of Linux Torvalds. He himself said he was a
git, and that's why he named his CVS clone like that. I don't think he
likes LISP any more than he likes Richard Stallmann.
On Jun 5, 1:26 am, fft1976 <·······@gmail.com> wrote:
> On Jun 4, 4:56 am, Aatu Koskensilta <················@uta.fi> wrote:
>
> > fft1976 <·······@gmail.com> writes:
> > > Do you disagree that Wolfram is a genius, btw?
>
> > Wolfram is certainly a genius. He is also an insufferable git.
>
> You are probably thinking of Linux Torvalds. He himself said he was a
> git, and that's why he named his CVS clone like that. I don't think he
> likes LISP any more than he likes Richard Stallmann.
"CVS clone"? :-D
-alex
fft1976 wrote:
> On Jun 4, 4:56 am, Aatu Koskensilta <················@uta.fi> wrote:
>> fft1976 <·······@gmail.com> writes:
>>> Do you disagree that Wolfram is a genius, btw?
>> Wolfram is certainly a genius. He is also an insufferable git.
>>
>
> You are probably thinking of Linux Torvalds. He himself said he was a
> git, and that's why he named his CVS clone like that. I don't think he
> likes LISP any more than he likes Richard Stallmann.
Nope, he was thinking of Wolfram, who has a reputation for being
uncertain far fewer times than he might be mistaken.
fft1976 <·······@gmail.com> writes:
> On Jun 4, 4:56�am, Aatu Koskensilta <················@uta.fi> wrote:
>
>> Wolfram is certainly a genius. He is also an insufferable git.
>
> You are probably thinking of Linux Torvalds.
A peculiar suggestion. But perhaps it was intended jocularly. Linus may
well be something of a git at times, but he differs from Wolfram in an
important regard, that of demonstrably having a sense of humour and
being able to occasionally apply it to himself. Insufferable gits
invariably fail to see anything amusing in even their most bizarre
antics -- and some of Wolfram's more megalomaniacal pontifications in _A
New Kind of Science_, for example, certainly are quite bizarre indeed.
--
Aatu Koskensilta (················@uta.fi)
"Wovon mann nicht sprechen kann, dar�ber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
From: John Thingstad
Subject: Re: Using C for competitive advantage
Date:
Message-ID: <op.uuzvxysbut4oq5@pandora>
På Thu, 04 Jun 2009 06:59:42 +0200, skrev Madhu <·······@meer.net>:
>
> * Richard Fateman <··············@cs.berkeley.edu> :
> Wrote on Wed, 03 Jun 2009 12:29:44 -0700:
>
> |> I think Wolfram dealt a devastating blow to LISP by spurning it very
> |> publicly and choosing C to write Mathematica. So how about a Git in
> |> LISP?
> |
> | Just as Wolfram dealt a devastating blow to scientific computing and
> | differential equations by claiming that the world is a cellular
> | automaton. :)
>
> "Stephen Wolfram is the creator of Mathematica and is widely regarded as
> the most important innovator in scientific and technical computing
> today." [1]
It's from the introduction in the mathematica manual. Writen by (you
guessed it) Stephen Wolfram.
And yes he is one of the biggest EGO's in the world :)
---------------------
John Thingstad
On 4 June, 11:11, "John Thingstad" <·······@online.no> wrote:
> På Thu, 04 Jun 2009 06:59:42 +0200, skrev Madhu <·······@meer.net>:
>
> > * Richard Fateman <··············@cs.berkeley.edu> :
> > Wrote on Wed, 03 Jun 2009 12:29:44 -0700:
>
> > |> I think Wolfram dealt a devastating blow to LISP by spurning it very
> > |> publicly and choosing C to write Mathematica. So how about a Git in
> > |> LISP?
> > |
> > | Just as Wolfram dealt a devastating blow to scientific computing and
> > | differential equations by claiming that the world is a cellular
> > | automaton. :)
>
> > "Stephen Wolfram is the creator of Mathematica and is widely regarded as
> > the most important innovator in scientific and technical computing
> > today." [1]
>
> It's from the introduction in the mathematica manual. Writen by (you
> guessed it) Stephen Wolfram.
Even before reading the above I was assuming that "widely regarded"
means amongst the people whose opinion counts. And since only
Wolfram's opinion counts and he no doubt considers himself to be
"the most important..." that makes the statement true.
> And yes he is one of the biggest EGO's in the world :
Madhu <·······@meer.net> writes:
> | Just as Wolfram dealt a devastating blow to scientific computing and
> | differential equations by claiming that the world is a cellular
> | automaton. :)
>
> "Stephen Wolfram is the creator of Mathematica and is widely regarded as
> the most important innovator in scientific and technical computing
> today." [1]
...
> [1] (seen quoted, I haven't visited the website to see the source)
most likely source: Stephen Wolfram
-miles
--
If you can't beat them, arrange to have them beaten. [George Carlin]
namekuseijin <···················@gmail.com> wrote:
> fft1976 wrote:
> > Found this on Reddit: http://www.reddit.com/r/programming/comments/8l3bq/wolfram_and_lisp/
> >
> > Are LISP programmers still bitter that Wolfram chose C instead of LISP?
>
> Any competitive advantage C might have once had is long gone. Being 2-5
> slower as C but much more productive by choosing a HLL like Lisp,
*Snigger*
Richard