[aurelius]

I don't buy it.

TXR is not built "on its own Lisp", it's built on C. If you believe that lisp is so great, then why didn't you just use ANSI Common Lisp? Why is TXR even necessary when I can do all the same data processing stuff in Perl, which is far more versatile and ubiquitous?

And all this nonsense about writing TXR in C because it's "more widely understood", "low dependencies", "easily packaged" - after 15-some years of advocacy in comp.lang.lisp, it's laughable that defsystem, asdf, and SBCL/CLISP/CMUCL aren't good enough for you.

Lisp is either as good as all the Naggums, Tiltons, and Pitmans of c.l.l. proclaim, or it's not. By writing TXR in C, you've just proved that it's not.

[lispm]

Oh shit.

SBCL's runtime contains traces of C. https://github.com/sbcl/sbcl/tree/master/src/runtime

CLISP is written on top of C.

CMUCL's runtime contains traces of C.

Now we are fucked...

I'm so glad that at least my Lisp Machine has no C. Oh wait, it has a C compiler...

[aurelius]

The point is that lisp advocates rarely seem to use any of these lisp implementations to do anything noteworthy or useful. They always seem to fall back on C, or some other language that's more "widely available" or "has minimal dependencies" or "has more potential contributors" or "can be more easily compared with other similar programs".

I find this hypocrisy to be quite intriguing.

[lispm]

> The point is that lisp advocates rarely seem to use any of these lisp implementations to do anything noteworthy or useful.

That's possible. There are many Lisp dialects and implementations which have few applications. That's true for a lot of other language implementations, too. There are literally thousands implementations of various programming languages with very few actual applications. Maybe it is fun to implement your own language from the ground up. Nothing which interest me, but it does not bother me.

If he wants to implement a small new Lisp dialect its perfectly fine to implement it in C or similar.

> They always seem to fall back on C, or some other language that's more "widely available" or "has minimal dependencies" or "has more potential contributors" or "can be more easily compared with other similar programs".

Some new dialect is written with the help of C? That bothers you?

Wow.

Actually 95% of all Lisp systems contain traces of C and some are deeply integrated in C or on top of C (CLISP, ECL, GCL, CLICC, MOCL, dozens of Scheme implementations and various other Lisp dialects). There are various books about implementing Lisp in C.

Really nobody in the Lisp community loses any sleep that somebody implements parts of Lisp in C.

> I find this hypocrisy to be quite intriguing.

Because some random guys implement their own language in C? Why do we have Python, Ruby, Rebol? There was already PERL or AWK or ... Somebody decided to write their own scripting language. So what?

[aurelius]

> Because some random guys implement their own language in C? Why do we have Python, Ruby, Rebol? There was already PERL or AWK or ... Somebody decided to write their own scripting language. So what?

When a Python advocate wants to do some data processing, do they first write their own Python implementation in C? No. When a Ruby advocate wants to make a Rails website, do they first write their own implementation of Ruby in C? No.

Several fine implementations of lisp already exist that compile down to machine code and, if the lisp community is to believed, have performance "close to C". So why does a lisp advocate feel the need to re-write lisp in C for a project that didn't actually need it? The lisp community would have us all believe that lisp is the "programmable programming language", and all the other rhetoric about how every other language has just stolen ideas from lisp, etc., etc.. They all truly seem to believe that lisp is something special. That's why I find it laughable that someone like Kaz Kylheku, a 15 year veteran of comp.lang.lisp, decided not to implement TXR by using a pre-existing lisp implementation.

[lispm]

> When a Python advocate wants to do some data processing, do they first write their own Python implementation in C?

They write it in C. Checkout the Python world sometimes.

* CrossTwine Linker - a combination of CPython and an add-on library offering improved performance (currently proprietary)

* unladen-swallow - "an optimization branch of CPython, intended to be fully compatible and significantly faster", originally considered for merging with CPython

* IronPython - Python in C# for the Common Language Runtime (CLR/.NET) and the FePy project's IronPython Community Edition

* 2c-python - a static Python-to-C compiler, apparently translating CPython bytecode to C

* Nuitka - a Python-to-C++ compiler using libpython at run-time, attempting some compile-time and run-time optimisations. Interacts with CPython runtime.

* Shed Skin - a Python-to-C++ compiler, restricted to an implicitly statically typed subset of the language for which it can automatically infer efficient types through whole program analysis

* unPython - a Python to C compiler using type annotations

* Nimrod - statically typed, compiles to C, features parameterised types, macros, and so on

and so on...

> So why does a lisp advocate feel the need to re-write lisp in C for a project that didn't actually need it? The lisp community would have us all believe that lisp is the "programmable programming language"

Why don't you understand the difference between 'a lisp advocate' and 'the lisp community'?

> nd all the other rhetoric about how every other language has just stolen ideas from lisp, etc., etc..

Nonsense.

> That's why I find it laughable that someone like Kaz Kylheku, a 15 year veteran of comp.lang.lisp, decided not to implement TXR by using a pre-existing lisp implementation.

I find it laughable that you find it laughable...

[aurelius]

Every single Python project you stated simply proves my point. They are Python compilers of some sort. TXR, on the other hand, is a data processing language implemented in its own lisp which is implemented in C. In other words, TXR is an application of lisp, not just a compiler or interpreter like those Python projects you listed. So, all your examples are irrelevant.

TXR didn't need its own dialect of lisp. So, the question remains: why didn't Kaz use SBCL or CLISP? They're good enough for c.l.l. kooks like him to recommend to everyone else, but why're they not good enough for him to use?