Using C for competitive advantage

[fft1976]

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?

 

[Stefan Ram]

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/

»=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

»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/

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

»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/

 

[Pascal J. Bourguignon]

»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.

 

[Pillsy]

fft1976 wrote:

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

 

[Raymond Toy]

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

 

[Richard Bos]

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

 

[Tony]

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?

Scientific needs are not mainstream.

 

[fft1976]

      »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?

 

[cr88192]

»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...

 

[anonymous.c.lisper]

»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.

 

[Juliusz Chroboczek]

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

 

[Vsevolod Dyomkin]

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

 

[cr88192]

So, you've recalled the infamous Greenspun's 10th

maybe...



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...

 

[fft1976]

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!

 

[user923005]

So, you've recalled the infamous Greenspun's 10th




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.

 

[Richard Fateman]

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.

 

[fft1976]

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?

 

[Kaz Kylheku]

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.

 

[Aatu Koskensilta]

Do you disagree that Wolfram is a genius, btw?

Wolfram is certainly a genius. He is also an insufferable git.

 

[Richard Bos]

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