If Lisp Is So Great (2003)

Clojure: http://clojure.org/getting_started

Racket: http://docs.racket-lang.org/getting-started/

Common Lisp: https://www.quicklisp.org/beta/

Lisp is a family of languages. All the dialects are good in their own way - "standardization", if such a thing even makes sense, would be counter-productive.

The biggest issue for me vs other options is lack of community / packages

Pick Python, JavaScipt, even Perl and there's millions of solutions to pick from so you can get shit done. Maybe that stuff exists for lisp but I'm unaware of it.

If there was a popular lisp with something like npm, easy integration with non lisp libraries I might consider it.

There's also the issue of perf. The lisp I used was optimized for generating machine code for games. My understanding is most lisps don't perform at that level. Of course as a replacement for Python, perl, JavaScript that's not an issue. But it would be for C/C++ for games

Another issue is finding collaborators.

I think first time setup is a huge key for programming languages. For example Go has the benefit of an amazing out of the box standard library, unlike D and Ruby where you would install via a package manager the right tools to get a web project going, you could do it all from vanilla Go code.

Of course in both Ruby and D you could do it from vanilla code, but it's not as seamless and tried and tested I suppose?

Why don't you want to depend on the JVM?

You are deliberate ignoring the most well known modern lisp, which has straightforward installation, great tooling, and lots of support available.

Not to mention the JVM is one of the most powerful and highly optimised vm platforms and has hundreds of thousands of man years invested in high quality libraries.

> Speaking as an outsider, I think LISP would gain a lot more traction if its community coalesced around a single implementation

And surely they would focus around a JVM implementation. The only other platforms that even come close are c/c++, and the .net clr.

What are the reasons you don't want to depend on the JVM that don't apply doubly so to Common Lisp?

Nice "syntactical" touch :)

Let me try a variation:

(shiver 'me 'timbers)

http://practicaltypography.com/why-racket-why-lisp.html

It so quite possible the long term productivity will be better with the mediocre programmers team regardless of their tooling.

If you have a team of great programmers you also need to give them the possibility to do some interresting stuff.

And that's basically that, when the great programmer will come and ask to change tooling or improve you'll refuse. They'll understand you prevent them to do anything efficiantly and so they'll resign as they waste their time here.

But even with great tools at their disposal, a mediocre team of programmer will perform averagely.

Because you don't just need to have the tool lying around, you have to know how to use it, what is good, what is bad, when to do this or that. if there not somebody behind them to coatch them all the time, they will not leverage it.

When for example a person learn design patterns, they want to use them all the time.

The great developper know the patterns, understood the key concepts behind and know when to use and not use them.

As for the language it is more crutial than you think. It is basically the shared basic knowledge and discussion medium in your company. And your APis are also part of it. If you have high level concepts coming from both your API and programming language and your developper know them they'll think directly in theses high level concepts and will be able to ignore the irelevant details.

What make Java more efficiant mostly is that you can forget to think about freeing memory and it is almost impossible to get a core dump. Instead of having to learn and speak the concepts of allocating and freeing memory your developpers will be able to concentrate on other things.

And what make C more efficiant than assembly is that you can actually write easily functions, that you can define structures and that the compiler take care to compute the proper shift in memory to access the differents field and so on.

But java, especially before version 8 is lacking key concepts like basic functionnal programming. So when a developper want to filter a collection, a pretty common operation, he will just iterate, check the condition of the filtering and return a filtered collection. It will be very specific and the level of expressivity of this code will be quite low.

A great developper would at leas isolate that code into a function with meaningfull name or define a generic filter function and pass predicate as anonymous functions. But the lack of proper lambda expression will prevent to fully leverage it.

But once everybody is accustomed to functionnal programming they'll just use filter and a predicate. The intent is much more clear, almost self documenting.

The more expressive you can be, the more common knowledge you can have, and the more you can concentrate on issue key to your program and the less you can spend time on unecessary details, the more productivity you get.

And yes, this start with a good programming language with a good echosystem and a team that efficiant with it.

That's why Java or C/C++ are so often used: they are the easiest languages when you need to hire because more people know them. This doesn't mean they are the best language for your problem at hand.

By combining a great team of competant people, a small startup environement were you can concentrate on getting thing done and by using powerfull tools they made their software, managed to have it evolving faster than their competitor and then sold it to Yahoo.

Ironically since the tool has been brought back by Yahoo its growth stopped and nobody know of it anymore. Is it because of the different people working on it? Is it because they had now a different management structured that cared more of politics? Or was it because they decided to recode everything in C++ ?

To me that's likely a combination of all the things.

That's the key point. A great programming language and echosystem is a great start. But that's not enough. You also need pragmatic management that make decision for the good of the company and not for politics and you need to have employees that care of their job.

At the end, you should know if you are in a model of small efficiant teams or huge average teams. Most company start with the former and end up in the later as they grow. Ultimately that why the next start up has a possibility to beat them. You would never be able to beat microsoft if everybody inside had a startuper mind-set. They would own the world.

That why people fear google so much. I'am pretty sure they have lot of politics and are already more in the later phase than the former but they at least managed to keep bright people working for them.

Instead of being like yacc, which uses an external DSL to define the parser, with its own syntactic conventions, the Racket parset generator is built with macros. The reason yacc has to be a metaprogram instead of just a library is because of how the semantic actions are "chunks of code" which you can't really represent in C but in LISP its easy to represent "chunks of unevaluated code" in your program, which lets you define the parser generator as an embedded dsl implemented via macros.

Anyway, the reason I found this nice is that in Racket you can define your own macros to abstract over the repetitive parts of the grammar description. For example, in yacc you need to write multiple rules to describe a comma-separated list

    /* Use left recursion for efficient stack use
       and reverse at the end so the list is in
       left-to-right order */
    
    arglist:
      arglistrevdeclsx { $$ = reverse($1); }
    ;
    
    arglistrev:
      /*empty*/          { $$ = NULL; }
    | arglistrev ',' arg { $$ = cons($2, $1); }
    ;

    ;; create a non-terminal called arglist
    ;; that is a  list of "arg"s, separated by commas
    ,@(makelist arglist ',' arg)

    ;; and this code can be reused:
    ,@(makelist decllist ',' identifier)

Lisp was probably a good tool for pg's startup. It was an ecommerce builder, most lisps are great at metaprogramming and creating DSL's. But his startup also used C and some other languages for different problems.

What I think is great about Lisp is its idealistic simplicity.

(function parameter1 parameter2)

Everything is a list, pretty much everything that doesn't look like a list is just syntax sugar.

My opinion is: unless you have a hard requirement, just use the language you already know and like.

If you need to squeeze every tiny bit of performance, you might just need to use C++ or C.

If your client wants a complete website in a ridiculous short amount of time, going for python,ruby or even php would be a sane choice.

If your problem involves DSL's, metaprogramming or impressing people with how alien your code looks, check out some lisps, maybe Haskell.

Here are some more good answers to that question in a Stackexchange thread http://programmers.stackexchange.com/questions/9320/why-is-l....

edit: another one - http://stackoverflow.com/questions/2036244/whats-so-great-ab...

You open your editor and connect to Lisp. Then you spend your time interactively defining functions, changing them, defining variables and inspecting them, and so on.

This has consequences that you need to experience or see to understand how it plays out in practice. You tend to start coding in a different way. Paul Graham calls it bottom up programming.

There are also synergistic effects with features like macros which enable radical kinds of convenient code generation / DSL-building, and conditional restarts which are like exceptions but fundamentally more powerful in a way that helps greatly when doing interactive coding, the multiple dispatch object system, the online documentation system, and so on and so on.

Lisp is shock full of good ideas that are still absent from most other languages. But mere bullet lists aren't convincing, like in so many other situations.

I wrote a web service in Lisp and just for convenience I wanted to have it incrementally recompile and reload its own source code on every request if the commit hash of the working tree had changed. This was a three line hack.

I also generate a memory image every time I make a deploy, which means that the server starts in a finger snap including the whole runtime for all this dynamic stuff.

Another advantage for me is the HyperSpec, an excellent hyperlinked reference of the whole standard language. It's an industrial quality manual written by literate professionals and so it's exhaustive, correct, and mostly unambiguous.

I also simply enjoy how Emacs with Lisp is a world-class IDE. Right now I'm mostly offline with just slow pricey 3G but I made sure to install a bunch of Lisp packages and the HyperSpec and it's a joy to code using just Emacs and SBCL in the background. I can look up any documentation, semantic tab completion and argument list popups work perfectly since the editor is aware of all the code and the namespace rules and so on.

I just don't know any other language that's so pleasant and fun to develop with. (After learning it, of course.)

People call Lispers smug because they love the language more than any other, but I don't feel smug because I didn't come up with the thing, I just learned it and like it. I'm humbled by the engineering and quality of the tools and everything. It's not some weird academic obsession. It just makes me happy on a daily basis.

If you don't know what a webcrawler entails, then you might not be the right audience for Lisp as it exists at the moment.

For common lisp, the first thing I would search for is a HTTP Client and a HTML Parser. https://duckduckgo.com/?q=common+lisp+http+client https://duckduckgo.com/?q=common+lisp+html+parsing

CLiki.net is always a good resource.

If you've finished building a webcrawler, please create a website where you explain webcrawling for (common-)lisp. So the next one will not have the same problem :-)

And sorry I could not travel both

And be one traveler, long I stood

And looked down one as far as I could

To where it bent in the undergrowth;

... ...

I shall be telling this with a sigh

Somewhere ages and ages hence:

Two roads diverged in a wood, and I—

I took the one less traveled by,

And that has made all the difference.