4 ms·

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

by lispm 12y ago

> 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 12y ago
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?
- deleted 12y ago
  [deleted]
- lispm 12y ago
  It's a tool with some embedded kind of Lisp dialect. There are zillions of it. > why didn't Kaz use SBCL or CLISP? Why should he? He can do whatever he want. I personally don't care at all about what he does. Why are you? Kind of strange obsession with comp.lang.lisp. Are you one of the trolls posting there? > 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? Probably he did it to annoy real programmers like you?
  - aurelius 12y ago
    > > why didn't Kaz use SBCL or CLISP? > Why should he? Kaz invested a bunch of time implementing a whole new backquote implementation for CLISP, but it's still not good enough for him to use CLISP to implement TXR? It doesn't make any sense! Any right-thinking programmer should care about inconsistencies such as this. If I'm evaluating a programming language, and I see someone in its community writing their own language implementation to support an application that could've easily been written using one of the standard language implementations, then it looks to me like the standard implementations aren't mature enough or trustworthy enough for me to use for my application. Not only that, but it suggests that maybe this particular language isn't as good as its advocates claim, especially if I have to drop back down to C in order to meet certain requirements (e.g., portability, speed, wider understanding, etc.). But any right-thinking programmer already knows that lisp is not worth wasting any time on. It's dead, and people like Kaz, and projects like TXR, are going to make sure it stays that way.
    - lispm 12y ago
      the 'right-thinking programmer'. How bizarre.
    - kazinator 12y ago
      I am not convinced that CLISP can be used to write another programming language which is itself completely BSD-licensed. See here: http://sourceforge.net/p/clisp/clisp/ci/default/tree/COPYRIGHT http://sourceforge.net/p/clisp/clisp/ci/default/tree/COPYRIG... CLISP's licensing is somewhat confusing and appears to dictate the license to the application. So, for example, I probably wouldn't use it for a commercial, closed-source application. For the same reasons, it cannot be used for a BSD-licensed application. (However, I did use CLISP for the licensing back-end of such an application: that back-end runs on a server and isn't redistributed. Things you don't distribute to others cannot run afoul of the GPL.) CLISP's license lets you make compiled .fasl files, and these are not covered by its copyright (unless they rely on CLISP internal symbols). However, that is where it ends. Memory images saved with CLISP are under the GPL. (Memory images are the key to creating a stand-alone executable with CLISP!) If you have to add libraries to CLISP itself, you also run into the GPL. I believe that this would cause issues to the users of TXR, which they do not have today. For a user to be able to run the .fasl files, they need CLISP, and of course that has to be distributed to them under the GPL terms, and you can't add C libraries to that CLISP without taining them with the GPL. You can wrap TXR entirely in a proprietary application, including all of its internals: the whole image, basically. This wouldn't be possible if some of its internals were the CLISP image. Regarding the GPL, I do not believe in that any more. I will not use this license for any new project. It is not a free software license in my eyes. Free really means you can do anything you want; any restriction logically means "not entirely free". Proprietary products that use free code do not take away anyone's ability to use the original. The problem with the FSF people is that they regard the mere existence of something as offensive. "It's not enough that there is a free program; we must litigate to death the non-free program which is based on the same code before we can be happy."

by lispm 12y ago

aurelius 12y ago

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?

deleted 12y ago
[deleted]
lispm 12y ago
It's a tool with some embedded kind of Lisp dialect. There are zillions of it. > why didn't Kaz use SBCL or CLISP? Why should he? He can do whatever he want. I personally don't care at all about what he does. Why are you? Kind of strange obsession with comp.lang.lisp. Are you one of the trolls posting there? > 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? Probably he did it to annoy real programmers like you?
- aurelius 12y ago
  > > why didn't Kaz use SBCL or CLISP? > Why should he? Kaz invested a bunch of time implementing a whole new backquote implementation for CLISP, but it's still not good enough for him to use CLISP to implement TXR? It doesn't make any sense! Any right-thinking programmer should care about inconsistencies such as this. If I'm evaluating a programming language, and I see someone in its community writing their own language implementation to support an application that could've easily been written using one of the standard language implementations, then it looks to me like the standard implementations aren't mature enough or trustworthy enough for me to use for my application. Not only that, but it suggests that maybe this particular language isn't as good as its advocates claim, especially if I have to drop back down to C in order to meet certain requirements (e.g., portability, speed, wider understanding, etc.). But any right-thinking programmer already knows that lisp is not worth wasting any time on. It's dead, and people like Kaz, and projects like TXR, are going to make sure it stays that way.
  - lispm 12y ago
    the 'right-thinking programmer'. How bizarre.
  - kazinator 12y ago
    I am not convinced that CLISP can be used to write another programming language which is itself completely BSD-licensed. See here: http://sourceforge.net/p/clisp/clisp/ci/default/tree/COPYRIGHT http://sourceforge.net/p/clisp/clisp/ci/default/tree/COPYRIG... CLISP's licensing is somewhat confusing and appears to dictate the license to the application. So, for example, I probably wouldn't use it for a commercial, closed-source application. For the same reasons, it cannot be used for a BSD-licensed application. (However, I did use CLISP for the licensing back-end of such an application: that back-end runs on a server and isn't redistributed. Things you don't distribute to others cannot run afoul of the GPL.) CLISP's license lets you make compiled .fasl files, and these are not covered by its copyright (unless they rely on CLISP internal symbols). However, that is where it ends. Memory images saved with CLISP are under the GPL. (Memory images are the key to creating a stand-alone executable with CLISP!) If you have to add libraries to CLISP itself, you also run into the GPL. I believe that this would cause issues to the users of TXR, which they do not have today. For a user to be able to run the .fasl files, they need CLISP, and of course that has to be distributed to them under the GPL terms, and you can't add C libraries to that CLISP without taining them with the GPL. You can wrap TXR entirely in a proprietary application, including all of its internals: the whole image, basically. This wouldn't be possible if some of its internals were the CLISP image. Regarding the GPL, I do not believe in that any more. I will not use this license for any new project. It is not a free software license in my eyes. Free really means you can do anything you want; any restriction logically means "not entirely free". Proprietary products that use free code do not take away anyone's ability to use the original. The problem with the FSF people is that they regard the mere existence of something as offensive. "It's not enough that there is a free program; we must litigate to death the non-free program which is based on the same code before we can be happy."