8 ms·

Why Lisp?

91 points by octopus 14y ago

rman666 14y ago
It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.
- octopus 14y ago
  Today you have 3 main alternatives: * Common Lisp (used by the author of the article) * Scheme * Clojure
  - sillysaurus 14y ago
    One thing that intrigues me about clojure is that it affords some unique benefits, by virtue of being a lisp. For fun I want to try to write a clojure program which generates C code for a tiny game engine. e.g. you run the program, and it spits out .c and .h files which you can then compile and run. Then, the challenge is to make it generate java code, too. I.e. in addition to the C code, which you can build and run, it also generates that same functionality in Java code, which you can run on JRE. So the game engine itself would be specified in clojure, and yet it would be "automatically implemented" across two very-different platforms! It's a fun challenge, I think. Maybe not doable, or doable only in a horrible way, but still fun. But the point is this: that's a great example of a problem which would be pretty much impossible in a non-lisp language. In order to achieve that in Python, you'd probably be forced to implement a lightweight lisp within Python. So that may demonstrate an answer to the question, "Why Lisp?" ... certain problems can be solved only in lisp, or by reimplementing the list-processing concepts of lisp.
    - octopus 14y ago
      There is already a project that translates ClojureScript to Scheme https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme from which you can generate C code. Theoretically you could use the generated C code on any OS with a standard C compiler.
    - airfoil 14y ago
      Why generate Java code if Clojure runs on the JVM? Why is it "pretty much impossible" generate the game engine C code in a non-lisp language? What is it about Lisp that makes it possible?
      - sillysaurus 14y ago
        The motivation behind "generating Java" was that the game could then be deployed in a browser, just like Minecraft is. Maybe Clojure can already do that though. I haven't looked yet. =) Clojure runs on the JVM, but perhaps Clojure is expensive in the context of a 60-frame-per-second realtime app. I doubt it would be significantly more expensive than Java, but that's something to test. So by generating Java, then it would be an interesting system because it winds up producing the same sort of code which Notch made by hand to deploy Minecraft to a browser. Yet it's derived "from the clojure code". And yet it's also generating C code, which is also derived "from the clojure code". So it's very meta, which I can't resist exploring. Why is it "pretty much impossible" generate the game engine C code in a non-lisp language? Well, it's straightforward for you write a program which generates some C code. But how about "either C, or Java"? Or "either C, or Java, or Haskell", ... etc. You'll soon discover that the nature of the implementation is completely different for different languages. A Haskell game engine would look utterly nothing like a C implementation would look. So the situation is, you would need an intermediate source code representation of your game engine which supports introspection. And whatever data structure you use must also be able to be modified during the "code generation", because it's not until the codegen step that you know what sort of special-casing you'll have to do (in order to generate code which implements your game engine in e.g. haskell, or brainfuck, or... etc. Point being: each of those has a different set of special-case requirements, and you can't know which until you're already in the codegen phase.) So, you could use a different language, and you could represent your "game engine source code" as, say, JSON. And you could have conventions for what your various operations "within that JSON string" actually mean -- e.g. whether you use infix notation, or prefix notation, or.. etc. And then you could have a notation for how to specify a function, within that JSON string. And so on. But then, at the end of it all, you wind up with a poorly implemented version of what lisp already offers you. It lets you do all of that automatically, because those features are built right in to the language. Indeed, the language is the primary reason the features are possible: Everything is a list, and everything has access to all lists at all phases of the program's lifespan. You can run at compile time, or compile at run time, etc. You have access to the entire syntax tree at all times, in every program you write, which enables you to manipulate it. You simply can't do that with e.g. Python. Hence the requirement for an "intermediate thing, which you can manipulate" -- we happened to decide on using JSON as the representation, but you could've easily decided to use something else, etc. The point is, that "intermediate representation" is just a poorly-reimplemented version of the toolset which Lisp gives you by default.
  - strobe 14y ago
    And, It's really hard to choose one! All of 3 dialects has own unique benefits and lacks.
    - z92 14y ago
      What does Clojure lacks in the language?
      - chimeracoder 14y ago
        Clojure adds syntax, which breaks some of the inherent symmetry of Lisp slightly[0]. This isn't something you're likely to notice unless you do a lot of heavy metaprogramming. Clojure cannot guarantee elimination of tail calls, because of the limitations of the underlying JVM. This also means that it can't properly handle corecursion in the same way that pretty much every single other Lisp can. (Both of these have been discussed before many times before on HN, so I can pre-empt the next comment in this thread, which will be someone pointing out that Clojure provides "loop" and the "recur" macro - to which I'd respond, yes, they're logically equivalent in the end, but having to force the transformation to a loop explicitly breaks the paradigm, which for me is the whole point of using a Lisp. This is one of those topics that can be discussed ad nauseum with no "conclusion", so it's not worth spending too much time on it.) Lastly, anytime you're dealing with binary compatibility between various JVM languages, the abstraction is inherently a bit leaky. I haven't used Clojure myself, so I can't comment specifically there, but from my experience with using Java libraries in Scala, I can testify that some of the warts of Java end up leaking into Scala code. Nothing debilitating, just a bit frustrating[1]. [0] Racket does too, but the "syntax" added (square brackets) has the same semantics, so it's really just an equivalent token - an alias, if you will. [1] One particular example I remember has to do with how Foo.class in Java works, and how a library dependent on this particular pattern has to be used in Scala - it just gets a bit messy.
        peatmoss 14y ago
        I wonder if, in the future, this limitation of Clojure will go away. I know there has been talk of the JVM folk adding things like support for tail recursion. That said, I'm not smart enough to know whether talking about adding support for tail recursion translates to "Once we're agreed, let us go ahead and solve this tractable problem," or if it translates to "Gee this would be nice, but it's wicked hard."
  - qznc 14y ago
    Scheme is not a single alternative. Racket [0] is a Scheme, which can be compared to things like Python or Ruby. There are other implementations, which should be used for different uses. For example, Chibi Scheme [1] is a nice alternative to Lua, but not to Python or Ruby. Given your other two Lisps, I rather make this list: * Common Lisp (which implementation?) * Racket * Clojure [0] http://racket-lang.org/ http://racket-lang.org/ [1] http://synthcode.com/wiki/chibi-scheme http://synthcode.com/wiki/chibi-scheme
    - gnosis 14y ago
      I think Chicken[1] is a very attractive Scheme alternative. It's full-featured, fast, compiles down to C, has a very nice library (egg) system, and a relatively large and active user community (as far as Schemes go). [1] - http://call-cc.org/ http://call-cc.org/
      - klutometis 14y ago
        Hear, hear; I've been using Chicken for commercial and personal projects for about five years now. It keeps getting better. Occasionally, Racket has a package that I'd like to port (e.g. datalog); but I find it otherwise overbearing. Chicken has found some local maximum of efficiency and availability of useful libraries.
    - pmelendez 14y ago
      I would add Tiny Scheme as an embedding scripting language or as base of a DSL
- vseloved 14y ago
  Common Lisp. Everything else is so much Lisp as php is perl or C++ is C.
martinced 14y ago
I'm a big Lisp dialects proponent but I don't like that article very much. It's very naive and the author is unexperienced IMHO. For example the author writes: "I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen." Ouch. The author doesn't seem to be very knowledgeable of "best practices" and IDEs from the last ten years available in the Java/C# world. Lisp dialects can really shine in various ways but "refactoring" ain't exactly one area where Emacs (which he mentions and which I do love) beats "modern IDEs". Apparently the author's only experience comes from old JavaScript development environments and some Perl hacking. He's hardly "connected" with real-word, modern, way of developing software. His description as to how he's upgrading servers by manually copying binaries also shows he's disconnected from actual enterprise deployment techniques. Overall it feels very amateurish. But kudos for picking a Lisp dialect and sticking to it and reaping the benefits of that smart choice...
- michaelochurch 14y ago
  I dislike most of these "modern IDEs". They seem to encourage Big Programs that shouldn't be written in the first place. http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/ http://michaelochurch.wordpress.com/2013/01/09/ide-culture-v... (IDE culture vs. Unix philosophy). However, you are right that, in terms of features, they deliver, if you keep your directory structure, language choice, and development practices within certain bounds.
  - blablabla123 14y ago
    Yes... I mean even if the programs are big, IDEs encourage a massive footprint of just about anything. (I would not go so far to declare big programs per se as a bad thing.) Massive build instructions, massive Interface declarations, massive amount of stub files... Things happen with IDEs that would never happen when using a plain editor. Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt.
zalew 14y ago
> This is helped by a great feature of the environment (Emacs/SLIME) which provides cross-referencing tools, for example, I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen. wow, rly? you have this in Eclipse (and probably every 'modern' IDE out there) for every language.
- demallien 14y ago
  Or, you know, cscope?
JohnFromBuffalo 14y ago
Because Lisp answers all questions recursively. Even robots understand this.
lucian1900 14y ago
Interesting that "Lisp" is assumed to be Common Lisp and that Scheme is assumed to be strictly a learning tool. I've found Racket to be much more useful than any other Common Lisp/Scheme.
- gnosis 14y ago
  I have to agree with that. I find Scheme to be a lot cleaner, more modern, and easier to use than Common Lisp. I really only see two reasons to choose Common Lisp over Scheme. The first is that CL has a ton of libraries compared to most Schemes (though Racket has quite a few of its own.. I'm not sure how those two would compare on the library front). The second reason is that CL has a much larger community.
- vseloved 14y ago
  Well, Common Lisp is Lisp, Racket is Scheme, they are different. This perpetual confusion is just useless. Let's call things by their names. You don't call C++ C or php perl, right?
  - qu4z-2 14y ago
    Common Lisp is Lisp. Racket is Scheme. Scheme is Lisp. SBCL is Common Lisp.
    - vseloved 14y ago
      Let's translate it to C: C99 is C. C++0x is C++. C++ is C. Clang is C99. Do all the lines seem correct?
      - qu4z-2 14y ago
        I disagree with your translation. I admit that "SBCL is Common Lisp" is a stretch, but no more than your original "Racket is Scheme". How about instead: LISP 1.5 is like C Common Lisp is like C++ Scheme is like Objective-C (ignoring all the other Lisp dialects that have fallen by the wayside: Maclisp, Interlisp, ZetaLisp)
dschiptsov 14y ago
few more slogans: * Ruby's emphasis on writing DLS came from Lisp world, where this practice have been developed. * Some of Python's elegant forms - with, lambda and various comprehensions - like this: return (x, y) or a = [3, 4, 5] came form Lisp. * Lisp's macros are unmatched. Those of C/C++ are mere string substitution. * REPL is Lisp's invention. * Shadowing (re-binding) of variables and procedures used routinely - we don't need any special "dependency injection". * Logically, everything is a pointer, so, technically, every "object" if a first-class citizen. * Lisp is mostly-functional, so, in cases where you must have mutation, you just do it. Enough for today.) Over-excitement is a vulnerability.)
xradionut 14y ago
There's only a few reasons to use Lisp. It's educational from a math/comp-sci aspect, you enjoy programming in it, and you can make money doing so. Career wise, it's way down on the list of languages/environments in which I would choose to do my daily coding. (And I don't currently have my brother-in-law calling me on a weekly basis to assist in automating various tasks in AutoLisp... )
- outworlder 14y ago
  If your only source of Lisp exposure is AutoLisp, that would explain the dislike. AutoLisp is very primitive even when compared with minimalist Scheme interpreters.
- vseloved 14y ago
  There are more reasons to use Lisp actually: the biggest one of which is, probably, that many programs become much simpler in it. But, actually, such argument is meaningless. The only meaningful argument would be to compare the pros and cons of using Lisp versus some other language for a specific field with some specific constraints. For instance, I won't be trying to use Lisp over JavaScript for writing Firefox plugins, but, probably I would use it over Objective C for this task ;)

Why Lisp?

91 points by octopus 14y ago

rman666 14y ago

It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.

octopus 14y ago
Today you have 3 main alternatives: * Common Lisp (used by the author of the article) * Scheme * Clojure
- sillysaurus 14y ago
  One thing that intrigues me about clojure is that it affords some unique benefits, by virtue of being a lisp. For fun I want to try to write a clojure program which generates C code for a tiny game engine. e.g. you run the program, and it spits out .c and .h files which you can then compile and run. Then, the challenge is to make it generate java code, too. I.e. in addition to the C code, which you can build and run, it also generates that same functionality in Java code, which you can run on JRE. So the game engine itself would be specified in clojure, and yet it would be "automatically implemented" across two very-different platforms! It's a fun challenge, I think. Maybe not doable, or doable only in a horrible way, but still fun. But the point is this: that's a great example of a problem which would be pretty much impossible in a non-lisp language. In order to achieve that in Python, you'd probably be forced to implement a lightweight lisp within Python. So that may demonstrate an answer to the question, "Why Lisp?" ... certain problems can be solved only in lisp, or by reimplementing the list-processing concepts of lisp.
  - octopus 14y ago
    There is already a project that translates ClojureScript to Scheme https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme from which you can generate C code. Theoretically you could use the generated C code on any OS with a standard C compiler.
  - airfoil 14y ago
    Why generate Java code if Clojure runs on the JVM? Why is it "pretty much impossible" generate the game engine C code in a non-lisp language? What is it about Lisp that makes it possible?
    - sillysaurus 14y ago
      The motivation behind "generating Java" was that the game could then be deployed in a browser, just like Minecraft is. Maybe Clojure can already do that though. I haven't looked yet. =) Clojure runs on the JVM, but perhaps Clojure is expensive in the context of a 60-frame-per-second realtime app. I doubt it would be significantly more expensive than Java, but that's something to test. So by generating Java, then it would be an interesting system because it winds up producing the same sort of code which Notch made by hand to deploy Minecraft to a browser. Yet it's derived "from the clojure code". And yet it's also generating C code, which is also derived "from the clojure code". So it's very meta, which I can't resist exploring. Why is it "pretty much impossible" generate the game engine C code in a non-lisp language? Well, it's straightforward for you write a program which generates some C code. But how about "either C, or Java"? Or "either C, or Java, or Haskell", ... etc. You'll soon discover that the nature of the implementation is completely different for different languages. A Haskell game engine would look utterly nothing like a C implementation would look. So the situation is, you would need an intermediate source code representation of your game engine which supports introspection. And whatever data structure you use must also be able to be modified during the "code generation", because it's not until the codegen step that you know what sort of special-casing you'll have to do (in order to generate code which implements your game engine in e.g. haskell, or brainfuck, or... etc. Point being: each of those has a different set of special-case requirements, and you can't know which until you're already in the codegen phase.) So, you could use a different language, and you could represent your "game engine source code" as, say, JSON. And you could have conventions for what your various operations "within that JSON string" actually mean -- e.g. whether you use infix notation, or prefix notation, or.. etc. And then you could have a notation for how to specify a function, within that JSON string. And so on. But then, at the end of it all, you wind up with a poorly implemented version of what lisp already offers you. It lets you do all of that automatically, because those features are built right in to the language. Indeed, the language is the primary reason the features are possible: Everything is a list, and everything has access to all lists at all phases of the program's lifespan. You can run at compile time, or compile at run time, etc. You have access to the entire syntax tree at all times, in every program you write, which enables you to manipulate it. You simply can't do that with e.g. Python. Hence the requirement for an "intermediate thing, which you can manipulate" -- we happened to decide on using JSON as the representation, but you could've easily decided to use something else, etc. The point is, that "intermediate representation" is just a poorly-reimplemented version of the toolset which Lisp gives you by default.
- strobe 14y ago
  And, It's really hard to choose one! All of 3 dialects has own unique benefits and lacks.
  - z92 14y ago
    What does Clojure lacks in the language?
    - chimeracoder 14y ago
      Clojure adds syntax, which breaks some of the inherent symmetry of Lisp slightly[0]. This isn't something you're likely to notice unless you do a lot of heavy metaprogramming. Clojure cannot guarantee elimination of tail calls, because of the limitations of the underlying JVM. This also means that it can't properly handle corecursion in the same way that pretty much every single other Lisp can. (Both of these have been discussed before many times before on HN, so I can pre-empt the next comment in this thread, which will be someone pointing out that Clojure provides "loop" and the "recur" macro - to which I'd respond, yes, they're logically equivalent in the end, but having to force the transformation to a loop explicitly breaks the paradigm, which for me is the whole point of using a Lisp. This is one of those topics that can be discussed ad nauseum with no "conclusion", so it's not worth spending too much time on it.) Lastly, anytime you're dealing with binary compatibility between various JVM languages, the abstraction is inherently a bit leaky. I haven't used Clojure myself, so I can't comment specifically there, but from my experience with using Java libraries in Scala, I can testify that some of the warts of Java end up leaking into Scala code. Nothing debilitating, just a bit frustrating[1]. [0] Racket does too, but the "syntax" added (square brackets) has the same semantics, so it's really just an equivalent token - an alias, if you will. [1] One particular example I remember has to do with how Foo.class in Java works, and how a library dependent on this particular pattern has to be used in Scala - it just gets a bit messy.
      - peatmoss 14y ago
        I wonder if, in the future, this limitation of Clojure will go away. I know there has been talk of the JVM folk adding things like support for tail recursion. That said, I'm not smart enough to know whether talking about adding support for tail recursion translates to "Once we're agreed, let us go ahead and solve this tractable problem," or if it translates to "Gee this would be nice, but it's wicked hard."
- qznc 14y ago
  Scheme is not a single alternative. Racket [0] is a Scheme, which can be compared to things like Python or Ruby. There are other implementations, which should be used for different uses. For example, Chibi Scheme [1] is a nice alternative to Lua, but not to Python or Ruby. Given your other two Lisps, I rather make this list: * Common Lisp (which implementation?) * Racket * Clojure [0] http://racket-lang.org/ http://racket-lang.org/ [1] http://synthcode.com/wiki/chibi-scheme http://synthcode.com/wiki/chibi-scheme
  - gnosis 14y ago
    I think Chicken[1] is a very attractive Scheme alternative. It's full-featured, fast, compiles down to C, has a very nice library (egg) system, and a relatively large and active user community (as far as Schemes go). [1] - http://call-cc.org/ http://call-cc.org/
    - klutometis 14y ago
      Hear, hear; I've been using Chicken for commercial and personal projects for about five years now. It keeps getting better. Occasionally, Racket has a package that I'd like to port (e.g. datalog); but I find it otherwise overbearing. Chicken has found some local maximum of efficiency and availability of useful libraries.
  - pmelendez 14y ago
    I would add Tiny Scheme as an embedding scripting language or as base of a DSL
vseloved 14y ago
Common Lisp. Everything else is so much Lisp as php is perl or C++ is C.

martinced 14y ago

I'm a big Lisp dialects proponent but I don't like that article very much. It's very naive and the author is unexperienced IMHO. For example the author writes: "I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen." Ouch. The author doesn't seem to be very knowledgeable of "best practices" and IDEs from the last ten years available in the Java/C# world. Lisp dialects can really shine in various ways but "refactoring" ain't exactly one area where Emacs (which he mentions and which I do love) beats "modern IDEs". Apparently the author's only experience comes from old JavaScript development environments and some Perl hacking. He's hardly "connected" with real-word, modern, way of developing software. His description as to how he's upgrading servers by manually copying binaries also shows he's disconnected from actual enterprise deployment techniques. Overall it feels very amateurish. But kudos for picking a Lisp dialect and sticking to it and reaping the benefits of that smart choice...

michaelochurch 14y ago
I dislike most of these "modern IDEs". They seem to encourage Big Programs that shouldn't be written in the first place. http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/ http://michaelochurch.wordpress.com/2013/01/09/ide-culture-v... (IDE culture vs. Unix philosophy). However, you are right that, in terms of features, they deliver, if you keep your directory structure, language choice, and development practices within certain bounds.
- blablabla123 14y ago
  Yes... I mean even if the programs are big, IDEs encourage a massive footprint of just about anything. (I would not go so far to declare big programs per se as a bad thing.) Massive build instructions, massive Interface declarations, massive amount of stub files... Things happen with IDEs that would never happen when using a plain editor. Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt.

zalew 14y ago

> This is helped by a great feature of the environment (Emacs/SLIME) which provides cross-referencing tools, for example, I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen. wow, rly? you have this in Eclipse (and probably every 'modern' IDE out there) for every language.

demallien 14y ago
Or, you know, cscope?

JohnFromBuffalo 14y ago

Because Lisp answers all questions recursively. Even robots understand this.

lucian1900 14y ago

Interesting that "Lisp" is assumed to be Common Lisp and that Scheme is assumed to be strictly a learning tool. I've found Racket to be much more useful than any other Common Lisp/Scheme.

gnosis 14y ago
I have to agree with that. I find Scheme to be a lot cleaner, more modern, and easier to use than Common Lisp. I really only see two reasons to choose Common Lisp over Scheme. The first is that CL has a ton of libraries compared to most Schemes (though Racket has quite a few of its own.. I'm not sure how those two would compare on the library front). The second reason is that CL has a much larger community.
vseloved 14y ago
Well, Common Lisp is Lisp, Racket is Scheme, they are different. This perpetual confusion is just useless. Let's call things by their names. You don't call C++ C or php perl, right?
- qu4z-2 14y ago
  Common Lisp is Lisp. Racket is Scheme. Scheme is Lisp. SBCL is Common Lisp.
  - vseloved 14y ago
    Let's translate it to C: C99 is C. C++0x is C++. C++ is C. Clang is C99. Do all the lines seem correct?
    - qu4z-2 14y ago
      I disagree with your translation. I admit that "SBCL is Common Lisp" is a stretch, but no more than your original "Racket is Scheme". How about instead: LISP 1.5 is like C Common Lisp is like C++ Scheme is like Objective-C (ignoring all the other Lisp dialects that have fallen by the wayside: Maclisp, Interlisp, ZetaLisp)

dschiptsov 14y ago

few more slogans: * Ruby's emphasis on writing DLS came from Lisp world, where this practice have been developed. * Some of Python's elegant forms - with, lambda and various comprehensions - like this: return (x, y) or a = [3, 4, 5] came form Lisp. * Lisp's macros are unmatched. Those of C/C++ are mere string substitution. * REPL is Lisp's invention. * Shadowing (re-binding) of variables and procedures used routinely - we don't need any special "dependency injection". * Logically, everything is a pointer, so, technically, every "object" if a first-class citizen. * Lisp is mostly-functional, so, in cases where you must have mutation, you just do it. Enough for today.) Over-excitement is a vulnerability.)

xradionut 14y ago

There's only a few reasons to use Lisp. It's educational from a math/comp-sci aspect, you enjoy programming in it, and you can make money doing so. Career wise, it's way down on the list of languages/environments in which I would choose to do my daily coding. (And I don't currently have my brother-in-law calling me on a weekly basis to assist in automating various tasks in AutoLisp... )

outworlder 14y ago
If your only source of Lisp exposure is AutoLisp, that would explain the dislike. AutoLisp is very primitive even when compared with minimalist Scheme interpreters.
vseloved 14y ago
There are more reasons to use Lisp actually: the biggest one of which is, probably, that many programs become much simpler in it. But, actually, such argument is meaningless. The only meaningful argument would be to compare the pros and cons of using Lisp versus some other language for a specific field with some specific constraints. For instance, I won't be trying to use Lisp over JavaScript for writing Firefox plugins, but, probably I would use it over Objective C for this task ;)