25 ms·

Where Lisp Fits

83 points by Adrock 13y ago

mrottenkolber 13y ago
Have to say by now I am tired of clicking on a Lisp titled article and having to read about Clojure. Please stop hyping Clojure. It's not LISP and its not Lisp either. We have a Lisp, it's called Common Lisp, its perfectly fine, far superior to Clojure and will prevail Clojure by decades. To underline how awfully skiddish Clojure is from a lispers perspective, the first thing he mentions is the "thrush macro": http://clojuredocs.org/clojure_core/clojure.core/-%3E http://clojuredocs.org/clojure_core/clojure.core/-%3E Which is needlessy to say a typical example of the skiddish culture of Clojure. The brain train goes like this: "Oh we have grown this ugly zombie breed between a ruby and a java, how to we make it look intentional? Oh that's easy just put on a little of this completely pointless macro cream to make it look hip!" Worst: The article isn't even about Clojure. Please in the future label Clojure as what it is (an experiment in STM), and do not forget to mention that we have a great standardized language with great implementations which make the whole industry look bad. And we have that because engineers worked on it for decades. Edit: Thank you kind power-user for going through the whole thread and downvoting every comment I made, that's the kind of cargo-cult marketing I was talking about. I think downvoting shouldn't exist, makes it unpleasant to comment on topics where you don't share the mafias opinion. Yay HN!
- Adrock 13y ago
  OP here. I didn't realize that Clojure was a trigger word! I just included that bit at the beginning to give a little context on how I got into this topic, not to hype anything.
  - mrottenkolber 13y ago
    No problem. I just fear that people overlook the serious CL.
    - yogthos 13y ago
      In my opinion, the CL community is doing a fantastic job making sure that most people don't look at the language. Instead of being bitter that Clojure is getting all the attention, why not focusing on making CL more approachable. There seems to be a lot of disconnect between the CL community and the rest of the world. Any time pain points are brought up by beginners they're immediately brushed off in a rather derisive manner. For example, consider the fact that the only decent open source IDE for CL is Emacs. This will filter out majority of people out of the gate, since Emacs is notoriously difficult to learn and it feels archaic. I'm not arguing about merits of Emacs here, I'm just pointing out what it looks like to somebody who's not already invested in it. If you're going to be learning a really esoteric looking language, the last thing you want is to be learning a really weird IDE at the same time. You'd have to be pretty dedicated to continue in this situation. When the Light Table project got started, there was tons of animosity from Emacs users saying that it does nothing new and you could easily do all this in Emacs. That's great, except nobody bothered to do that with Emacs or package it into a beginner friendly experience. If somebody wanted to try Clojure, I'd just point them to download LT and they can get up and running literally within minutes. They can see all the joys of using the REPL, having code completion and all the basic features you'd expect out of the box. All of a sudden you can focus on learning the language and actually enjoy doing so. CL has been around for ages predating languages like Ruby and Python by a wide margin, and it does pretty much everything they do better. If the CL community actually bothered to make the initial experience palatable these languages might not even exist today. Instead, all the energy seems to be poured into shitting on other languages and feeling bitter that CL is not getting the attention it deserves.
  - maaku 13y ago
    It's not, or at least it shouldn't be...
- rolandukor 13y ago
  Forgive my ignorance, but what are your greviances with clojure? It seems to me to be a very practical LISP.
  - mrottenkolber 13y ago
    Like I said its an experiment. CL is a great piece of work forged by decades of engineering _consensus_. Feel free to take a look at ABCL if you want to know where the man hours of clojure should have went into. Its just like ruby, a trend that a lot of effort is wasted on, because the fundamentals are plain wrong.
    - rolandukor 13y ago
      Unfortunately, you haven't told me anything. I will leave it at that.
      - mrottenkolber 13y ago
        To sum it up: CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time. Clojure: An opinionated experiment with a single implementation that might just as well have been a library for CL (we do have STM libraries though, so there isn't really a point). ABCL is a CL implementation for the JVM.
        _delirium 13y ago
        > CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time. This was once true, but CL's standards body last made a significant revision twenty years ago, and no longer exists. It petered into inactivity by the late '90s, formally lost its voting privileges due to lack of quorum by the early 2000s, and was dissolved in 2004 (http://mailman.rose-hulman.edu/pipermail/ncits/2004-August/000125.html http://mailman.rose-hulman.edu/pipermail/ncits/2004-August/0...). Nowadays the consensus process is more community driven, more of a messy "modern-style" language evolution, and doesn't involve a formal standards body or any kind of centralized process. Implementations add proprietary extensions to experiment, and then compatibility libraries layer over those extensions, slowly becoming de-facto standards. For example multithreading can't be implemented in standard CL, and various CLs instead expose their own private threading APIs. Bordeaux-threads then arises as a compatibility layer and attempt at achieving consensus around a portable threading API. Perhaps that isn't a problem, but it simply isn't the case that CL has a big standards body that defines what has been proven to be good: it has no standard body, which as a result defines nothing post-1994; the base language is frozen in time.
- jonnybgood 13y ago
  Instead of telling us your feelings are hurt that Clojure is being called a lisp, you should explain why you think Clojure is not a lisp.
  - mrottenkolber 13y ago
    It's _a_ Lisp. It's not _the_ lisp and not a particular good one either.
    - elwell 13y ago
      What did you mean by this then? > It's not LISP and its not Lisp either
      - hga 13y ago
        Well, as I score it, it's not a LISP, as in LISt Processing, since lists are no longer the principle collection type, and others are first class syntactically. Not to mention the use of vectors (denoted with square braces []) for special form syntax like in defn and let. But it's most certainly a "Lisp".
        rsanders 13y ago
        By "lists", you mean "linked lists as implemented with pairs"? What's the practical difference between lists and the seq abstraction (immutability aside)? It's true that Clojure provides a lot of data types, but none that would be unfamiliar to a CL programmer. And you can handle all of them more or less like lists, and as a bonus you can use the same set of functions to do so. I would think that the immutability of these data structures would be a bigger difference, both conceptually and in the difficulty of porting CL code into Clojure.
        hga 13y ago
        Yes, as implemented with pairs, syntactically with parens. None, except vectors and maps (and sets and regexs and ...) being syntactically first class, and being used heavily, not just in special form syntax but in real use. For a whole lot of programming, maps are where it's at for your data structures. True, these shouldn't be unfamiliar to a CL programmer (although the pervasive use of maps might well be, don't remember how much association lists and properly lists were used). As someone who adopted the mostly functional Scheme style I don't find the enforced immutability a bigger difference, but I could well see that being true for CL programmers. And for many/some? the bias against OO vs. CL's CLOS, which many claim is the very best OO system ever (as far as I know the only popular one with a MOP).
- swannodette 13y ago
  Nothing against Common Lisp but CL is not the lisp and it never will be. CL is a lisp same as Clojure - http://www.islisp.info/faq.html http://www.islisp.info/faq.html. Also you seem to have no problems critiquing a language which you obviously have no significant experience with - "Clojure is an experiment in STM". Guffaw.
  - hga 13y ago
    As a historical example, mainline LISP prior to CL was dynamically scoped, something corrected in Scheme and adopted by CL a decade later, which, from my Maclisp and Lisp Machine Lisp background at the time was perhaps its biggest breaking change (very possibly not from the viewpoint of an Interlisp person).
  - lispm 13y ago
    Clojure is a new language. Everything in Clojure had to be implemented new. There is zero compatibility and zero code sharing to/with Common Lisp, Emacs Lisp, Autolisp, ISLisp, Standard Lisp, Maclisp, Lisp Machine Lisp, ...
    - hga 13y ago
      Which are all examples of mainline LISP. What about Scheme? Sure, it was bootstrapped in Maclisp, but not too long after had pretty much "zero compatibility and zero code sharing" with mainline LISPs. But is it not a LISP?
      - lispm 13y ago
        There are different types of Lisps. 1) the Lisps: they carry the name and share basics: Lisp 1.5 ... Common Lisp, ... 2) the derived dialects with some compatibility: Scheme, Interlisp, ... 3) the derived^2 dialects: Logo, MDL, Dylan, Racket, Clojure, ... 4) the derived^3 dialects: ML, ... The Lisps is category one were and are able to share code. Emacs Lisp implements some of Common Lisp. Something complex like the LOOP macro was once a single source file for Maclisp, Lisp Machine Lisp and Common Lisp. Clojure shares no source code with any other Lisp. It renames basic vocabulary ('atom') and lacks some older concepts. It's basically a new language.
- S4M 13y ago
  I agree that the "thrush macro" is not such a good example to show the greatness of the Lisp family of language. IMHO it's a nice syntactic sugar but it doesn't bring something fundamentally new. Still IMHO, a more suited example of the power of the macros would be how to write a memoize macro that enables to cache the results of some function.
- sdegutis 13y ago
  This kind of blind zealotry kills innovation.
  - agentultra 13y ago
    It's true and it happens on both sides. I've met Lisp programmers who came in by way of Clojure who openly criticize CL for its use of parentheses and its age. It's quite silly.
    - hga 13y ago
      The age and more importantly stasis is a fair cop, especially if the Clojure programmer cares about SMP programming, where Common Lisp does not officially even have a story. Clojure was among other things designed with SMP and functional programming in mind, and thread safety is the rule rather than the exception. If the age is a reference to Common Lisp bearing almost all the warts of mainline Lisp (minus dynamic scoping) it's also a fair cop, Scheme inspired Lisp dialects like Clojure have gained tremendously by throwing away a lot of historical baggage. Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. On the other hand if you don't like CL's parens, I wonder how you can like Clojure? Almost all the special form syntax is parens, and old Lispers like me are somewhat annoyed by the vectors (first class syntax with square brackets, []) used by e.g. let. Are there very many Clojure programmers like this? Any prominent ones???
      - agentultra 13y ago
        > The age and more importantly stasis is a fair cop I don't see how threading makes "age" a valid argument. CL is a language defined by a specification. Implementations have provided threading APIs for a while now and library authors have written cross-implementation threading APIs. Without even mentioning threading in the specification it's trivial to write multi-threaded CL applications today and I think that's a strength. In a similar fashion, C++ hadn't included a threading API until C++11 (iirc). Yet implementations provided it and library authors had filled the gap for years until a standard API was adopted into the core standard library. If CL was a language defined by an implementation that hadn't been updated in 10 years I might agree with you. As for syntax it's odd. Rich Hickey himself has advocated the use of syntax-literals for data-structures citing legibility as a primary concern. One familiar with CL's access to the reader and read-table would allow the programmer to implement reader macros for the same effect without losing compatibility with the rest of CL (and the standard implements a few: #() for vectors for example, '() for (QUOTE ...) etc). Either way preference of syntax is superfluous when you have programmatic access to your language's parser and yet Cljoure programmers unfamiliar with this concept advocate that syntax-literals are the way of the future and CL's lack of syntax for various constructs is a weakness. It's a non-issue. I've written reader macros for various flavours of assemblers. It's quite versatile. Age isn't a very good criticism. A good specification is meant to withstand the years. CL's has done a pretty good job at that. wrt baggage though, I will concede that perhaps they specified too much in the filepath API. A conformant CL implementation today will have to support some very obscure filesystems... which can be daunting for prospective implementation developers.
- kjjw 13y ago
  Are you 5?
- unpleasnt_truth 13y ago
  (You don't like to hear this, but it's your german soul crying here, more than anything else.)
- gtrak 13y ago
  This is somewhat irrational critique, clojure was an opportunity to start fresh and graft a concurrency-focused lisp onto a pervasive runtime, not to reimplement ABCL. It fills a need. I was always somewhat halfway interested in learning common lisp, but when clojure came along I actually got excited enough to do something about it. You even say you're 'very happy' to be working in it, but I think 'an experiment in STM' is too reductionist and shallow to address the numerous use-cases that are improved by persistent data structures and the other features that clojure provides.
roywiggins 13y ago
No mention of lambda calculus? Lisp is to Lambda Calculus as Pascal is to Turing Machines. More or less. Oh, beaten to the punch in the article's comments. Carry on.
- Adrock 13y ago
  OP here... here's my reply from the comments: Yep, I'm aware of the Church-Turing thesis and the relationship between TM and the Lambda Calculus. I originally had a mention of it, but I removed it because I was really more focused on the RegEx -> CFG -> ? chain and I couldn't find anything that made that connection with the Lambda Calculus. Any sources that make that connection would be appreciated!
  - roywiggins 13y ago
    You might like Thue; it operates solely on replacement rules and is trivially an unrestricted grammar: http://esolangs.org/wiki/Thue http://esolangs.org/wiki/Thue
  - UNIXgod 13y ago
    I enjoyed the article. Your connection your looking for is with Stephen Cole Kleene who also a student of Church just like Turing.
todd8 13y ago
I've heard all of these arguments in support of Lisp for many years, but I'm still not convinced. Indisputably, Lisp is remarkable and holds a special place in the pantheon of programming languages. Every argument in it's favor makes sense, a lot of sense. Reading these arguments in favor of Lisp is not like reading a blog touting the benefits of Javascript where even the positive points don't really sound so positive. The arguments made for Lisp are persuasive. Lisp is different. It's really quite unique; it has an elegant simplicity underlying its implementation and a deep connection to the foundations of computation. Think of this, Gregor Kiczales's book Art of the Metaobject Protocol was published 23 years ago! I learned to program in Lisp 40 years ago. What other languages did I use back in those days? Assembly language (IBM 360, CDC 6600, IBM 1130, etc), PL/1, Fortran, APL, COBOL. Nobody, argues today that we should be trying out PL/1 or we should give COBOL a try. (Are there any projects on Github using these languages from our hazy, distant past?) Lisp's beauty and power have kept it alive and vital all these years. But, there's something wrong with this story. If Lisp is really so great, why hasn't it triumphed? I use Lisp all the time: my editor needs it during periodic tune ups. However, I can't think of when I've reached for it first when I've had a choice. Python is just easier to get things done in. If my programs don't run fast enough I don't think of Lisp, I think of C or C++. Haskell is where it's at as far as programming language research goes, not Lisp. The important observation is that it's not just me. Lisp has had time to prove itself. It made it to the finals, and it deserves the lifetime achievement award. We can honor it's beauty, it's longevity, it's power, and even it's fantastic reincarnations (Clojure), but this isn't enough. If Lisp really was the language that we should be programming in, it would have demonstrated it by now.
- mrottenkolber 13y ago
  I think it proved its superiority many times. Its just that certain people couldn't admit it to themselves. Other langs are just a great way to ignore cold hard engineering facts and give grunt-work developers a feeling of perfection. Of course you don't need a lisp to build CRUD apps. Companies don't want to depend on highly trained engineers either. I don't care for being cheap though. I'd rather know 10% of lisp than 100% of yet another dead-end language.
tlarkworthy 13y ago
An interesting next step to Turning machines I read about recently was Kolmogorov-Uspensky machines. They allow pointers and are nearer to real machines we use. Whilst they still recognising the same languages in polynomial time as Turing machines, for some things they can compute and order of complexity class faster. Turing machines often end up traversing up and down the tape, linearising binary tree lookups for instance, whereas KU can do binary tree lookups in O(log(n)). Both machines do the lookups in P, but KU's particular P can be provably lower. [1] http://esolangs.org/wiki/Kolmogorov_machine http://esolangs.org/wiki/Kolmogorov_machine
Zigurd 13y ago
TFA doesn't actually say where Lisp fits. I rather wish some contender for The Next Mobile OS would make a "Lisp Android" - An ART-like Lisp runtime with a zygote-like fast start for processes and copy-on-write to crunch down memory use from multiple instances of the runtime. That's where I think Lisp would really fit. But it would take a lot of unconventional thinking about Lisp implementation and APIs.
grdvnl 13y ago
nitpick: Here is the link that describes why Clojure's threading macro is not really a pure thrush operator. http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/ http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/
calroc 13y ago
Backus' paper on Functional Programming might be of interest; click on: "ACM Turing Award Lecture" http://amturing.acm.org/award_winners/backus_0703524.cfm http://amturing.acm.org/award_winners/backus_0703524.cfm

83 points by Adrock 13y ago

Have to say by now I am tired of clicking on a Lisp titled article and having to read about Clojure. Please stop hyping Clojure. It's not LISP and its not Lisp either. We have a Lisp, it's called Common Lisp, its perfectly fine, far superior to Clojure and will prevail Clojure by decades. To underline how awfully skiddish Clojure is from a lispers perspective, the first thing he mentions is the "thrush macro": http://clojuredocs.org/clojure_core/clojure.core/-%3E http://clojuredocs.org/clojure_core/clojure.core/-%3E Which is needlessy to say a typical example of the skiddish culture of Clojure. The brain train goes like this: "Oh we have grown this ugly zombie breed between a ruby and a java, how to we make it look intentional? Oh that's easy just put on a little of this completely pointless macro cream to make it look hip!" Worst: The article isn't even about Clojure. Please in the future label Clojure as what it is (an experiment in STM), and do not forget to mention that we have a great standardized language with great implementations which make the whole industry look bad. And we have that because engineers worked on it for decades. Edit: Thank you kind power-user for going through the whole thread and downvoting every comment I made, that's the kind of cargo-cult marketing I was talking about. I think downvoting shouldn't exist, makes it unpleasant to comment on topics where you don't share the mafias opinion. Yay HN!

Adrock 13y ago
OP here. I didn't realize that Clojure was a trigger word! I just included that bit at the beginning to give a little context on how I got into this topic, not to hype anything.
- mrottenkolber 13y ago
  No problem. I just fear that people overlook the serious CL.
  - yogthos 13y ago
    In my opinion, the CL community is doing a fantastic job making sure that most people don't look at the language. Instead of being bitter that Clojure is getting all the attention, why not focusing on making CL more approachable. There seems to be a lot of disconnect between the CL community and the rest of the world. Any time pain points are brought up by beginners they're immediately brushed off in a rather derisive manner. For example, consider the fact that the only decent open source IDE for CL is Emacs. This will filter out majority of people out of the gate, since Emacs is notoriously difficult to learn and it feels archaic. I'm not arguing about merits of Emacs here, I'm just pointing out what it looks like to somebody who's not already invested in it. If you're going to be learning a really esoteric looking language, the last thing you want is to be learning a really weird IDE at the same time. You'd have to be pretty dedicated to continue in this situation. When the Light Table project got started, there was tons of animosity from Emacs users saying that it does nothing new and you could easily do all this in Emacs. That's great, except nobody bothered to do that with Emacs or package it into a beginner friendly experience. If somebody wanted to try Clojure, I'd just point them to download LT and they can get up and running literally within minutes. They can see all the joys of using the REPL, having code completion and all the basic features you'd expect out of the box. All of a sudden you can focus on learning the language and actually enjoy doing so. CL has been around for ages predating languages like Ruby and Python by a wide margin, and it does pretty much everything they do better. If the CL community actually bothered to make the initial experience palatable these languages might not even exist today. Instead, all the energy seems to be poured into shitting on other languages and feeling bitter that CL is not getting the attention it deserves.
- maaku 13y ago
  It's not, or at least it shouldn't be...
rolandukor 13y ago
Forgive my ignorance, but what are your greviances with clojure? It seems to me to be a very practical LISP.
- mrottenkolber 13y ago
  Like I said its an experiment. CL is a great piece of work forged by decades of engineering _consensus_. Feel free to take a look at ABCL if you want to know where the man hours of clojure should have went into. Its just like ruby, a trend that a lot of effort is wasted on, because the fundamentals are plain wrong.
  - rolandukor 13y ago
    Unfortunately, you haven't told me anything. I will leave it at that.
    - mrottenkolber 13y ago
      To sum it up: CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time. Clojure: An opinionated experiment with a single implementation that might just as well have been a library for CL (we do have STM libraries though, so there isn't really a point). ABCL is a CL implementation for the JVM.
      - _delirium 13y ago
        > CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time. This was once true, but CL's standards body last made a significant revision twenty years ago, and no longer exists. It petered into inactivity by the late '90s, formally lost its voting privileges due to lack of quorum by the early 2000s, and was dissolved in 2004 (http://mailman.rose-hulman.edu/pipermail/ncits/2004-August/000125.html http://mailman.rose-hulman.edu/pipermail/ncits/2004-August/0...). Nowadays the consensus process is more community driven, more of a messy "modern-style" language evolution, and doesn't involve a formal standards body or any kind of centralized process. Implementations add proprietary extensions to experiment, and then compatibility libraries layer over those extensions, slowly becoming de-facto standards. For example multithreading can't be implemented in standard CL, and various CLs instead expose their own private threading APIs. Bordeaux-threads then arises as a compatibility layer and attempt at achieving consensus around a portable threading API. Perhaps that isn't a problem, but it simply isn't the case that CL has a big standards body that defines what has been proven to be good: it has no standard body, which as a result defines nothing post-1994; the base language is frozen in time.
jonnybgood 13y ago
Instead of telling us your feelings are hurt that Clojure is being called a lisp, you should explain why you think Clojure is not a lisp.
- mrottenkolber 13y ago
  It's _a_ Lisp. It's not _the_ lisp and not a particular good one either.
  - elwell 13y ago
    What did you mean by this then? > It's not LISP and its not Lisp either
    - hga 13y ago
      Well, as I score it, it's not a LISP, as in LISt Processing, since lists are no longer the principle collection type, and others are first class syntactically. Not to mention the use of vectors (denoted with square braces []) for special form syntax like in defn and let. But it's most certainly a "Lisp".
      - rsanders 13y ago
        By "lists", you mean "linked lists as implemented with pairs"? What's the practical difference between lists and the seq abstraction (immutability aside)? It's true that Clojure provides a lot of data types, but none that would be unfamiliar to a CL programmer. And you can handle all of them more or less like lists, and as a bonus you can use the same set of functions to do so. I would think that the immutability of these data structures would be a bigger difference, both conceptually and in the difficulty of porting CL code into Clojure.
        hga 13y ago
        Yes, as implemented with pairs, syntactically with parens. None, except vectors and maps (and sets and regexs and ...) being syntactically first class, and being used heavily, not just in special form syntax but in real use. For a whole lot of programming, maps are where it's at for your data structures. True, these shouldn't be unfamiliar to a CL programmer (although the pervasive use of maps might well be, don't remember how much association lists and properly lists were used). As someone who adopted the mostly functional Scheme style I don't find the enforced immutability a bigger difference, but I could well see that being true for CL programmers. And for many/some? the bias against OO vs. CL's CLOS, which many claim is the very best OO system ever (as far as I know the only popular one with a MOP).
swannodette 13y ago
Nothing against Common Lisp but CL is not the lisp and it never will be. CL is a lisp same as Clojure - http://www.islisp.info/faq.html http://www.islisp.info/faq.html. Also you seem to have no problems critiquing a language which you obviously have no significant experience with - "Clojure is an experiment in STM". Guffaw.
- hga 13y ago
  As a historical example, mainline LISP prior to CL was dynamically scoped, something corrected in Scheme and adopted by CL a decade later, which, from my Maclisp and Lisp Machine Lisp background at the time was perhaps its biggest breaking change (very possibly not from the viewpoint of an Interlisp person).
- lispm 13y ago
  Clojure is a new language. Everything in Clojure had to be implemented new. There is zero compatibility and zero code sharing to/with Common Lisp, Emacs Lisp, Autolisp, ISLisp, Standard Lisp, Maclisp, Lisp Machine Lisp, ...
  - hga 13y ago
    Which are all examples of mainline LISP. What about Scheme? Sure, it was bootstrapped in Maclisp, but not too long after had pretty much "zero compatibility and zero code sharing" with mainline LISPs. But is it not a LISP?
    - lispm 13y ago
      There are different types of Lisps. 1) the Lisps: they carry the name and share basics: Lisp 1.5 ... Common Lisp, ... 2) the derived dialects with some compatibility: Scheme, Interlisp, ... 3) the derived^2 dialects: Logo, MDL, Dylan, Racket, Clojure, ... 4) the derived^3 dialects: ML, ... The Lisps is category one were and are able to share code. Emacs Lisp implements some of Common Lisp. Something complex like the LOOP macro was once a single source file for Maclisp, Lisp Machine Lisp and Common Lisp. Clojure shares no source code with any other Lisp. It renames basic vocabulary ('atom') and lacks some older concepts. It's basically a new language.
S4M 13y ago
I agree that the "thrush macro" is not such a good example to show the greatness of the Lisp family of language. IMHO it's a nice syntactic sugar but it doesn't bring something fundamentally new. Still IMHO, a more suited example of the power of the macros would be how to write a memoize macro that enables to cache the results of some function.
sdegutis 13y ago
This kind of blind zealotry kills innovation.
- agentultra 13y ago
  It's true and it happens on both sides. I've met Lisp programmers who came in by way of Clojure who openly criticize CL for its use of parentheses and its age. It's quite silly.
  - hga 13y ago
    The age and more importantly stasis is a fair cop, especially if the Clojure programmer cares about SMP programming, where Common Lisp does not officially even have a story. Clojure was among other things designed with SMP and functional programming in mind, and thread safety is the rule rather than the exception. If the age is a reference to Common Lisp bearing almost all the warts of mainline Lisp (minus dynamic scoping) it's also a fair cop, Scheme inspired Lisp dialects like Clojure have gained tremendously by throwing away a lot of historical baggage. Then there's some rather horrible things Symbolics forced upon CL to increase Lisp Machine Lisp compatibility, but that are hard to implement in stock hardware. On the other hand if you don't like CL's parens, I wonder how you can like Clojure? Almost all the special form syntax is parens, and old Lispers like me are somewhat annoyed by the vectors (first class syntax with square brackets, []) used by e.g. let. Are there very many Clojure programmers like this? Any prominent ones???
    - agentultra 13y ago
      > The age and more importantly stasis is a fair cop I don't see how threading makes "age" a valid argument. CL is a language defined by a specification. Implementations have provided threading APIs for a while now and library authors have written cross-implementation threading APIs. Without even mentioning threading in the specification it's trivial to write multi-threaded CL applications today and I think that's a strength. In a similar fashion, C++ hadn't included a threading API until C++11 (iirc). Yet implementations provided it and library authors had filled the gap for years until a standard API was adopted into the core standard library. If CL was a language defined by an implementation that hadn't been updated in 10 years I might agree with you. As for syntax it's odd. Rich Hickey himself has advocated the use of syntax-literals for data-structures citing legibility as a primary concern. One familiar with CL's access to the reader and read-table would allow the programmer to implement reader macros for the same effect without losing compatibility with the rest of CL (and the standard implements a few: #() for vectors for example, '() for (QUOTE ...) etc). Either way preference of syntax is superfluous when you have programmatic access to your language's parser and yet Cljoure programmers unfamiliar with this concept advocate that syntax-literals are the way of the future and CL's lack of syntax for various constructs is a weakness. It's a non-issue. I've written reader macros for various flavours of assemblers. It's quite versatile. Age isn't a very good criticism. A good specification is meant to withstand the years. CL's has done a pretty good job at that. wrt baggage though, I will concede that perhaps they specified too much in the filepath API. A conformant CL implementation today will have to support some very obscure filesystems... which can be daunting for prospective implementation developers.
kjjw 13y ago
Are you 5?
unpleasnt_truth 13y ago
(You don't like to hear this, but it's your german soul crying here, more than anything else.)
gtrak 13y ago
This is somewhat irrational critique, clojure was an opportunity to start fresh and graft a concurrency-focused lisp onto a pervasive runtime, not to reimplement ABCL. It fills a need. I was always somewhat halfway interested in learning common lisp, but when clojure came along I actually got excited enough to do something about it. You even say you're 'very happy' to be working in it, but I think 'an experiment in STM' is too reductionist and shallow to address the numerous use-cases that are improved by persistent data structures and the other features that clojure provides.

roywiggins 13y ago

No mention of lambda calculus? Lisp is to Lambda Calculus as Pascal is to Turing Machines. More or less. Oh, beaten to the punch in the article's comments. Carry on.

Adrock 13y ago
OP here... here's my reply from the comments: Yep, I'm aware of the Church-Turing thesis and the relationship between TM and the Lambda Calculus. I originally had a mention of it, but I removed it because I was really more focused on the RegEx -> CFG -> ? chain and I couldn't find anything that made that connection with the Lambda Calculus. Any sources that make that connection would be appreciated!
- roywiggins 13y ago
  You might like Thue; it operates solely on replacement rules and is trivially an unrestricted grammar: http://esolangs.org/wiki/Thue http://esolangs.org/wiki/Thue
- UNIXgod 13y ago
  I enjoyed the article. Your connection your looking for is with Stephen Cole Kleene who also a student of Church just like Turing.

todd8 13y ago

I've heard all of these arguments in support of Lisp for many years, but I'm still not convinced. Indisputably, Lisp is remarkable and holds a special place in the pantheon of programming languages. Every argument in it's favor makes sense, a lot of sense. Reading these arguments in favor of Lisp is not like reading a blog touting the benefits of Javascript where even the positive points don't really sound so positive. The arguments made for Lisp are persuasive. Lisp is different. It's really quite unique; it has an elegant simplicity underlying its implementation and a deep connection to the foundations of computation. Think of this, Gregor Kiczales's book Art of the Metaobject Protocol was published 23 years ago! I learned to program in Lisp 40 years ago. What other languages did I use back in those days? Assembly language (IBM 360, CDC 6600, IBM 1130, etc), PL/1, Fortran, APL, COBOL. Nobody, argues today that we should be trying out PL/1 or we should give COBOL a try. (Are there any projects on Github using these languages from our hazy, distant past?) Lisp's beauty and power have kept it alive and vital all these years. But, there's something wrong with this story. If Lisp is really so great, why hasn't it triumphed? I use Lisp all the time: my editor needs it during periodic tune ups. However, I can't think of when I've reached for it first when I've had a choice. Python is just easier to get things done in. If my programs don't run fast enough I don't think of Lisp, I think of C or C++. Haskell is where it's at as far as programming language research goes, not Lisp. The important observation is that it's not just me. Lisp has had time to prove itself. It made it to the finals, and it deserves the lifetime achievement award. We can honor it's beauty, it's longevity, it's power, and even it's fantastic reincarnations (Clojure), but this isn't enough. If Lisp really was the language that we should be programming in, it would have demonstrated it by now.

mrottenkolber 13y ago
I think it proved its superiority many times. Its just that certain people couldn't admit it to themselves. Other langs are just a great way to ignore cold hard engineering facts and give grunt-work developers a feeling of perfection. Of course you don't need a lisp to build CRUD apps. Companies don't want to depend on highly trained engineers either. I don't care for being cheap though. I'd rather know 10% of lisp than 100% of yet another dead-end language.

tlarkworthy 13y ago

An interesting next step to Turning machines I read about recently was Kolmogorov-Uspensky machines. They allow pointers and are nearer to real machines we use. Whilst they still recognising the same languages in polynomial time as Turing machines, for some things they can compute and order of complexity class faster. Turing machines often end up traversing up and down the tape, linearising binary tree lookups for instance, whereas KU can do binary tree lookups in O(log(n)). Both machines do the lookups in P, but KU's particular P can be provably lower. [1] http://esolangs.org/wiki/Kolmogorov_machine http://esolangs.org/wiki/Kolmogorov_machine

Zigurd 13y ago

TFA doesn't actually say where Lisp fits. I rather wish some contender for The Next Mobile OS would make a "Lisp Android" - An ART-like Lisp runtime with a zygote-like fast start for processes and copy-on-write to crunch down memory use from multiple instances of the runtime. That's where I think Lisp would really fit. But it would take a lot of unconventional thinking about Lisp implementation and APIs.

grdvnl 13y ago

nitpick: Here is the link that describes why Clojure's threading macro is not really a pure thrush operator. http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/ http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/

calroc 13y ago

Backus' paper on Functional Programming might be of interest; click on: "ACM Turing Award Lecture" http://amturing.acm.org/award_winners/backus_0703524.cfm http://amturing.acm.org/award_winners/backus_0703524.cfm