What makes lisp special

You have a mechanism, or a paintbrush, if you like. You can have any syntax you could possibly want. Like Python or C 's with syntax. In end, this is what attracts people to Lisp - ultimate flexibility. You will find a comprehensive debate around lisp macro here. In most programming languages, syntax is complex. Macros have to take apart program syntax, analyze it, and reassemble it. They do not have access to the program's parser, so they have to depend on heuristics and best-guesses.

Sometimes their cut-rate analysis is wrong, and then they break. But Lisp is different. Lisp macros do have access to the parser, and it is a really simple parser. A Lisp macro is not handed a string, but a preparsed piece of source code in the form of a list, because the source of a Lisp program is not a string; it is a list.

And Lisp programs are really good at taking apart lists and putting them back together. They do this reliably, every day. Here is an extended example. Lisp has a macro, called "setf", that performs assignment.

The simplest form of setf is. Lisp also has lists; you can use the "car" and "cdr" functions to get the first element of a list or the rest of the list, respectively. Now what if you want to replace the first element of a list with a new value? There is a standard function for doing that, and incredibly, its name is even worse than "car".

It is "rplaca". But you do not have to remember "rplaca", because you can write. What is really happening here is that "setf" is a macro. It says to itself "Oh, the programmer is trying to set the car of somthing. The function to use for that is 'rplaca'. There's also no way you can write a C macro to do the job for you.

But, since a lisp macro is essentially a lisp program that takes snippets of code as input and returns code to replace the "invocation" of the macro, you can extend your "primitives" repertoire as far as you want, usually ending up with a more readable program. To do the same in C, you would have to write a custom pre-processor that eats your initial not-quite-C source and spits out something that a C compiler can understand.

It's not a wrong way to go about it, but it's not necessarily the easiest. Lisp macros allow you to decide when if at all any part or expression will be evaluated. To put a simple example, think of C's:. What this says is: Evaluate expr1 , and, should it be true, evaluate expr2 , etc.

Calling something like:. Will evaluate all three exprs before yielding an answer regardless of whether expr1 was false! And thats not even getting into Reader macros. They're very useful tools for managing repetitive code, but they're limited in quite severe ways.

All of that melts away if the langauge you use for metaprogramming is the same language you use for programming! A lisp macro takes a program fragment as input. This program fragment is represented a data structure which can be manipulated and transformed any way you like.

In the end the macro outputs another program fragment, and this fragment is what is executed at runtime. C does not have a macro facility, however an equivalent would be if the compiler parsed the code into a CodeDOM-tree, and passed that to a method, which transformed this into another CodeDOM, which is then compiled into IL. This could be used to implement "sugar" syntax like the for each -statement using -clause, linq select -expressions and so on, as macros that transforms into the underlying code.

If Java had macros, you could implement Linq syntax in Java, without needing Sun to change the base language. Here is pseudo-code for how a lisp-style macro in C for implementing using could look:.

Since the existing answers give good concrete examples explaining what macros achieve and how, perhaps it'd help to collect together some of the thoughts on why the macro facility is a significant gain in relation to other languages ; first from these answers, then a great one from elsewhere:. Java added a similar kind of loop construct with the "enhanced" for loop in Java 1.

Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern.

A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language.

Then Sun has to publish a JSR and convene an industry-wide "expert group" to hash everything out. That process--according to Sun--takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. That maybe the solution to the mystery of the "profound enlightenment experience" around Lisp is that it makes some very happy, but not me. I haven't, I'll look into it, thanks.

I haven't given up on solving that mystery yet. DanielRibeiro on Aug 3, parent prev next [—]. I think whole point of comparing programming languages from this angle is pointless. You should not go and judge a language by several phrases. Like all other languages, programming languages are also just that, languages - tools to express your thoughts. To me and many others Common Lisp reduces the friction between those thoughts and written description of them.

It is so much more to this language than just its syntax and politics. It is joy to develop in thanks to SLIME, it almost never gets in your way, it performs, it has wisdom of half a century and people who possess it.

Yes, it is far from perfect, but then again - there is no perfect language! In other words, please don't judge the language by how you can pronounce "how can I get to the city centre", it sounds similar in most. And I like the language which allows me to do this on my terms, rather than that of Guido, Matz or whoever.

And to me Common Lisp is pretty close to that. Just as a side note, folks on lisp and sbcl are one of the most pragmatic and intelligent people I have ever seen, I learned more from their discussions than by reading a couple of books.

To any of you reading, rock on Lispers ;. I know and enjoy Lisp, but I don't use it anymore. I do, however, use Ruby, which is an acceptable Lisp. In general, Lisp doesn't seem special anymore because 1 language implementers have taken Lisp's most important lessons and applied them to their own languages and 2 said languages have become relatively popular.

A lot's happened since "Beating the Averages". Lisp works with me to get the job done. Other languages typically impose a Way to get the job done. I don't think like other language designers often. So I like a flexible language.

Patterns, IMO, are boilerplate code to work around the limitations of a language. I haven't encountered a need for that in Lisp yet. It's a good sign to me.

I also have dynamically scoped variables, generic functions, parametric dispatch or multimethods or whatever you call it , macros, and a very powerful OO system if I need it. Best of all is that all of it is unified by a small amount of syntax, backed by a small set of axioms, and surrounded by a wonderful but small community.

This is just not true! Sure sometimes you have syntax suger in Ruby that makes something smaller but othertimes you don't in lisp I can always make everything smaller with macros. I would bet that Ruby is not shorter for most programmes. His hole argument is based around that in lisp you have wo write lambda Not saying anthing against ruby but this article is just very strange.

I have a question for those that have done a lot of programming in Lisp: Is macro programming a really big part of Lisp programming? I mean, what percentage of a typical project would be macros? I ask the question because you can achieve the same results in most dynamic languages by grabbing the string representation of a function, run it through a parser, modify the resulting AST and then regenerating the function string before passing to an eval CoffeeScript being a good example of this approach.

Sure, it's messier than in Lisp, but in return for the messiness of macros, you get much easier to read syntax in most of your code. Is the use of macros really such a big part of Lisp programs that it justifies the lack of syntax everywhere else? Macros are not something you need everyday at least not your own macros but when you need them you really need them. CoffeScript is a good example, if JavaScript would have been a real lisp there would be no need for CoffeeScript at all because you could build it in JS.

Your example of meta programming is very very messy and putting eval everywhere would also be a security nightmare and if you do it this way you don't end up with nice syntax. Macros are not messy to use they look like a normal function that meens often you don't even know or care if something is implmented in a macro or a function. The other big part of the macros look like language build ins for example in a REST-Framework you would have something like 'defresource'.

The auther of the framework can give you the best syntax to discribe what his library does. Look on Stackoverflow for DSLs in Clojure Writting good macros your self is a little harder and can look wired because your just not used to code looking like this. Almost everything that is normally build in the compiler is just a macro. Firstly, CoffeeScript is built in JavaScript. Does that make it a 'real' Lisp? Secondly, Lisp macros are every bit as big a security risk as using eval In both cases, if you are taking input from source code, and not from outside sources, there is no security risk.

Thirdly, yes, my example is messy. But it is still doable, and I just have a hard time believing that this kind of programming is a major percentage of the code of a Lisp program. To be clear on that comment, I can easily believe that you end up invoking macros a lot, but I don't believe that a large percentage of the code written for a project is actually macros. What percentage of code in a typical project is macros? This is an important point, because if you only have a few hundred lines of this stuff in a typical Lisp program, and it can be reproduced by using a parser in another dynamic language, then the advantage just isn't that big.

For argument's sake, imagine having a module available in Javascript that provides the Jison parser along with the Javascript grammar, which just re-emits the original Javascript source. So far so easy, this stuff already exists in CoffeeScript, go copy it from there. Now, having loaded such a module, is Lisp really in a much better position than this modified Javascript?

The point is that you can do random AST transformation at compiletime. You think of macros as a kind of pay of for s-exp syntax. I have to say that even without macros I would think s-exp syntax is nicer. Sure in Ruby you can do alot when you play around with that suger stuff but this stuff often doesn't come free.

Depending on what you do you are writting a lot of macros. In lisp the interface to a library is almost always in a DSL style witch makes them easy to use. The Lisp language has evolved into Common Lisp and Scheme, as well as a variety of dialects.

They all work in a similar fashion to the original language specification. In some cases, they differ in naming and elements used. However, they all use the same Lisp concepts, including macros.

It is not a stretch to say understanding Lisp is similar to the inscrutable process of becoming a Jedi in Star Wars and being given a light saber. The power of Lisp is most evident when you have learned at least one other language then move to Lisp.

Where other languages set the basic rules about how the language operates, for example, Lisp often lets the coder set the rules. Where other languages may offer lots of features to complete a large number of tasks, Lisp often can do the same tasks with less features.

Understanding how to use the Force in Stars Wars makes little sense until you learn how. The same dynamic applies to Lisp. Tim is an award-winning writer and technologist who enjoys teaching tech to non-technical people.

He has many years experience with web sites and applications in business, technical, and creative roles.

He and his wife have two kids, now teenagers, who are mad about video games. There are a ton of ways to make a Twitter bot. Here are a number of resources, ideas, and clues to follow up. Algorithms control our lives online and offline. Here are some examples to show what is an algorithm and how they work. I have updated the installation instructions for this Github project to make it even easier to install and play with. A collection of bot makers and professor types attend an online bot convention to talk about Twitter bots and more.

You can tell a bit about the software used to create the web page you're reading by looking at the URL in your web browser. McCarthy and his students also made a few other simplifications, including a switch to prefix notation and a memory model change that meant the language only had one real type. McCarthy explained Lisp to his readers by building it up out of only a very small collection of rules.

Graham is able to explain Lisp using only seven primitive operators, two different notations for functions, and a half-dozen higher-level functions defined in terms of the primitive operators.

That Lisp can be specified by such a small sequence of basic rules no doubt contributes to its mystique. Early on, Lisp spread quickly, probably because its regular syntax made implementing it on new machines relatively straightforward.

Later, researchers would keep using it because of how well it handled symbolic expressions, important in an era when so much of artificial intelligence was symbolic. By the mids, though, artificial intelligence researchers were running out of computer power. The solution, originally proposed by Peter Deutsch at MIT, was to engineer a computer specifically designed to run Lisp programs.

These Lisp machines, as I described in my last post on Chaosnet , would give each user a dedicated processor optimized for Lisp. They would also eventually come with development environments written entirely in Lisp for hardcore Lisp programmers. Lisp machines, devised in an awkward moment at the tail of the minicomputer era but before the full flowering of the microcomputer revolution, were high-performance personal computers for the programming elite.

For a while, it seemed as if Lisp machines would be the wave of the future. Several companies sprang into existence and raced to commercialize the technology. Throughout the s, Symbolics produced a line of computers known as the series, which were popular in the AI field and in industries requiring high-powered computing.

The series computers featured large screens, bit-mapped graphics, a mouse interface, and powerful graphics and animation software. These were impressive machines that enabled impressive programs. For example, Bob Culley, who worked in robotics research and contacted me via Twitter, was able to implement and visualize a path-finding algorithm on a Symbolics in He explained to me that bit-mapped graphics and object-oriented programming available on Lisp machines via the Flavors extension were very new in the s.