Which is the best implementation of LISP family of languages for real world programming ?
in [Lisp]
|
Prev: Which is the best implementation of LISP family of languagesfor real world programming ?
Next: A small backquote logjam
From: Pascal J. Bourguignon on 10 Jun 2010 20:24 bolega <gnuist006(a)gmail.com> writes: > On Jun 10, 2:51�pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> bolega <gnuist...(a)gmail.com> writes: >> > Which is the best implementation of LISP family of languages for real >> > world programming ? >> >> What's the real world? >> What's real world programming? >> >> -- >> __Pascal Bourguignon__ � � � � � � � � � �http://www.informatimago.com/ > > I mean ordinary people, who may want to do things with their computers Ah, ordinary people. Then the answer is easy: iPhone and iPad. That's computers for ordinary people, and very good at that! > for scripting, tasks that python can do, possibly when a language is > weak and another has library, then use some function from there even > if it is compiled. Notice that for a library to work with python, python requires that it be put under a format acceptable to python. In the lisp world, we never imagined to be able to force people to adapt their libraries to our needs and requimenets. We have FFI, and we try very hard to work with all sort of random libraries whatever their implementation language and quality, as if we were mere C programs. Sometimes with success, sometimes with failure. That said, given that the requirements of lisp and of python are similar, any library that is pythonified, can be integrated in the lisp environments easily, automatically even, it should only require some coding if it's not already done. > A set of work around techniques will always be > needed. Things that perl does, Ie. being part of the problem. Again, you could search cll archives about that (using Erik Naggum as author this time). Or you could use this: http://xach.com/naggum/articles/ http://www.xach.com/naggum/articles/3163193555464012(a)naggum.no.html > python does, failing at meta programming. > bash does failing at anything but oneliner "scripts". > things like java applets for various animations What applets? Have you ever seen a java applet? Last time I saw one it must have been fifteen years ago. > possibly some unoptimized but fast protyping of parsers Optimized parser generators were developed 30 years ago. What's your problem? > to fix files or convert formats etc. a wide > array of user tasks. files to be fixed and format convertion are not user tasks. They're programming tasks, if they're not management problems in the first place. Therefore you need a programming language, to write programs, to fix files, and to convert formats. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Espen Vestre on 11 Jun 2010 04:37 pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > What applets? Have you ever seen a java applet? Last time I saw one > it must have been fifteen years ago. I see one each time I log into my internet banking service. Unfortunately. -- (espen)
From: Nicolas Neuss on 12 Jun 2010 03:54 tfgordon <thomas.frederick.gordon(a)googlemail.com> writes: > Consider Clojure: http://clojure.org/ > > You might want to watch one of these videos for an overview: > > http://clojure.blip.tv/ > > There is also evidence that Clojure is currently the most popular > Lisp, more "popular" than Scheme or Common Lisp, whatever that means: > > http://www.google.com/trends?q=common+lisp,+scheme+language,+clojure Maybe you can derive that the trend for Clojure is better (not surprisingly given its youth), but using such searches for guessing absolute numbers is meaningless. For example, if you compare "Scheme language" and "Clojure language", you don't see Clojure at all. Nicolas
From: Eli Barzilay on 12 Jun 2010 10:01 Elena <egarrulo(a)gmail.com> writes: > On 12 Giu, 03:27, Sam TH <sam...(a)gmail.com> wrote: >> While SLIB is hard to run in Racket, Racket comes with a comprehensive >> library (seehttp://docs.racket-lang.org) which provides much of the >> specific functionality of SLIB as well as much more besides. >> Contributions of missing libraries are more than welcome. >> >> Additionally, the original question asked for a LISP for real-world >> programming, a category in which Racket excels, rather than an SLIB >> host. > > My arguments were against the assumption that Racket is a super set > of Scheme. It is not, since it lacks common Scheme facilities > (required by SLIB). Racket is a superset of Scheme, it doesn't lack any facilities that SLIB requires. However, SLIB tries to do much on its own: it grabs `require', which is a very core name in Racket, and builds its own module-like system on top of `load', which collides with Racket's own module system. In short, SLIB relies on such "features" as "`require' is not used" and "`load' is the only way to organize code into pieces", and Racket doesn't have these "features". Racket does have very good support for an R5RS language, and my guess is that it would be easy to make SLIB work there -- IIRC, SLIB requires some extensions with a per-implementation compatibility layer to unify them, and this will require some small amount of work given that Racket's R5RS is very strict in providing exactly R5RS. It might also run into some problems with the fact that most Racket code uses immutable pairs, but that's unlikely to be a problem since SLIB will cover additional list functions (at least that's what I remember). Whether there's a point in this exercise is a different issue, and so far nobody has seen any need. > Racket has a comprehensive library, that's for sure, but why would you > throw away libraries which were already there? They were not thrown out. SLIB is not part of Racket and was never part of PLT Scheme. What PLT did have for years, is a small file that was supposed to support using an SLIB installation. But setting this up was not easy to do (IIRC, there were problems that people ran into with SLIB's "vicinity" or something like that), and even people who used SLIB would do that directly without using this support. At some point it became clear that nobody is using this support: it was severely broken and nobody noticed -- and nobody volunteered to maintain it so it was dropped... Now, you can obviously claim that the Racket library ecosystem is to blame for this lack of support. Had it not have such a comprehensive library, there surely would be a much stronger motivation for someone to step up and make SLIB usable in it; but unfortunately, Racket has enough libraries that makes it much less necessary to do so. Count "very few libraries, if any" as another R5RS "feature" that Racket lacks. Finally, note that SLIB in itself is in no way useless to Racket in general. For example, I have used an implementation of sort that was based on it for a long time (only replaced recently with a half-copying vector based sort). Another example is Schelog that was recently "ported" to Racket as Racklog. SLIB has always played an important role in keeping such bits alive. >> > Racket is a language and an environment on their own. For >> > instance: debugging facilities are hidden into its IDE, therefore >> > you'll have to leave your debugging environment of choice. >> >> This is not the case. See the documentation for the errortrace >> library [1] for information on how to use it. As befits an IDE, >> it's able to provide additional debugging facilities, but they are >> not required. > > If the environment were open, why would some facilities be hidden in > its tools? Among other things, you can't single step Racket outside > of DrRacket. That sounds as a closed environment to me. How is that closed when the code for doing so is all there as part of any *OPEN* source project? I don't even need to defend some black C-level voodoo that does it, since it's all done in scheme code. It's true that most of the current code uses the GUI, but that's only because nobody felt the need yet for doing so outside of the GUI. (As someone who uses Emacs for editing, I can say that I'm perfectly fine with random printouts for debugging.) Note also that the Racket debugger was originally based on MzTake -- a project that implemented a scriptable debugger via reactive programming, and was not limited to the GUI. >> > Yes, you can run a REpL outside of its IDE, but you can't do much >> > more than that. >> >> Many people, including core Racket developers, work primarily via >> the REPL outside of DrRacket. > > I guess those people must not maintain code written by people > outside their team. Being one of these people, I find your statements odd. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Štěpán Němec on 12 Jun 2010 13:54
Eli Barzilay <eli(a)barzilay.org> writes: >> If the environment were open, why would some facilities be hidden in >> its tools? Among other things, you can't single step Racket outside >> of DrRacket. That sounds as a closed environment to me. > > How is that closed when the code for doing so is all there as part of > any *OPEN* source project? I don't even need to defend some black > C-level voodoo that does it, since it's all done in scheme code. It's > true that most of the current code uses the GUI, but that's only > because nobody felt the need yet for doing so outside of the GUI. [snip] I find this really hard to believe. I use the GUI only for the debugger and macro stepper. I would _love_ to have that functionality available in a regular REPL (OTOH, especially the macro stepper uses a lot of "eye-candyish" features, so it is a bit hard to imagine in some kind of text-only interface). Štěpán |