The author almost immediately writes off Common Lisp for lack of "frictionless access to a rich ecosystem of code written in the same language as your software", then recommends Clojure. Most of the ecosystem you have access to in Clojure is, in fact, not built in Clojure, and most Clojure libraries were/are wrappers around Java or Javascript.<p>Footnote 1 makes no sense, suggesting that the only way to get access to "a bunch of other useful code" is to embed it into a C program and that understanding your dependencies is somehow easier in Javascript.<p>In reality, Quicklisp[1] offers effortless access to over 1200 libraries and programs. It's nowhere near the 200 thousand packages in npm, but the overall quality is good and these libraries cover a surprisingly large number of things.<p>The post tries to display Clojure as "Lisp, but with access to open source". Clojure is a fine programming language, but it's also completely different from Common Lisp. CL has high quality optimizing compilers performing extensive type checking, a powerful object system, easy access to C libraries, etc. If you need Java interop, you can just use ABCL[2].<p>[1]: <a href="https://www.quicklisp.org/" rel="nofollow">https://www.quicklisp.org/</a>
[2]: <a href="http://abcl.org/" rel="nofollow">http://abcl.org/</a>
If you're asking yourself what kinds of problems is a Lisp good for you should probably watch this: <a href="https://www.youtube.com/watch?v=8X69_42Mj-g" rel="nofollow">https://www.youtube.com/watch?v=8X69_42Mj-g</a> (A computational chemist built himself his own Common Lisp implementation because no other language available was powerful enough for his needs...)<p>It basically boils to: if you're solving a <i>truly new and interesting problems</i> for which the current libraries and ecosystems don't matter that much to you anyhow (because what you do is too bleeding-edge / ahead of everyone else, so you'll write your own better stuff anyhow), than you might want to choose a Lisp.<p>And if your problem is so bleeding-edge and exotic that you also need to build your own programming-language for it, than you might just as well build yourself a Lisp (like the guy in the video did) and add your needed features to it, because this would be easier than any other approaches and allow you to spend more time on your problem and not on the language...<p>EDIT+: another example is DWave using SBCL: <a href="http://www.dwavesys.com/careers/senior-software-developer" rel="nofollow">http://www.dwavesys.com/careers/senior-software-developer</a> - if quantum (or analog... anyway...) computing is not "truly new and cutting edge", than I don't know what is
I can't believe an article about Lisp left out QuickLisp. It's the most popular Common Lisp package manager and has over 1200 open source libraries in it, and most of them are written in Common Lisp, or are bindings to native C/C++ libraries. Using libraries written in the same language you're using has a lot of advantages. Using Java libraries from a Lisp seems clunky.<p>Also, judging solely by the number of available packages is not a good measurement. Browse through NPM, and it's pretty obvious there are a LOT of duplicates, and that people have published libraries for the silliest little things. Search for "PNG", for example, and in the first page of results there are two different png diff libraries, a few libraries for determining if a buffer contains a PNG byte-stream, multiple stream and un-stream libraries, etc. That's all done with a single library in CL.<p>And finally, I don't think Clojure is that great. It's better than Java, and it's what I'd use if I had a lot of legacy Java code to work with, but it wouldn't be my first choice for a new project written in Lisp. I would hazard a guess that it's popular because it's less clunky than Java, without the over the top type system of Scala.
This seems like a little bit (probably a lot) of hyperbole around clojure.<p>While I love clojure, selling it as a "secret sauce" you just sprinkle on your startup and it succeeds is definitely not the message I think the community should be trying to send.<p>Lisps have benefits, they're pretty well documented (just the fact that lisp is multi-paradigm in and of itself is a large benefit), but they're not infallible. If you give macros to the wrong programmer, you will slow your entire team down.
The author seems to not know that there is open source in Common Lisp as well as most every other language. Open Source per se is orthogonal to whether Lisp or Language X is a great language to have in one's toolkit.<p>Clojure mind share is quite low compared to scala as far as languages built on top of the JVM go. Personally I think clojure and clojurescript is pretty cool but not so cool so far as to tempt me away from python, javascript and CL.<p>For a startup don't even worry about what language your competitors, if any, are using. Simply produce the best product you can and get it to market and break even before you even begin to think about these other things. HINT: in this age there is not one or a few areas and a bunch of competitors but millions of unique cool niche ideas and products. Build a better system for pushing out new app and product ideas consistently on the side. It isn't like the case of web store competitors at all. Also today there is a large market to buy startups that produce some webapp product that grows enough legs to more than break even.<p>You don't predicate your business on a secret but on producing a good product people want at a price point they are happy to pay. Secrets are hard to keep. Particularly when the author just told us about his secret weapon and advises as many as possible to use the same "secret".<p>Back in the "old days" we would joke that if we wanted to derail our competition then we should simply give them our source code. Their best geeks would be bemused and befuddled for months. Today we are drowning in reams of "free code" that may or may not be suitable. Then we have a side helping of hundreds of web APIs to pick from for various subparts of a product. So much time is spent understanding and adapting open source and choosing among and massaging our data to use so many external APIs that it is a wonder anything gets done. :P
Aside, the size of the NPM database ... is that really indicative of the amount of JS code out there? For example, how many trivial modules like "isarray" are there, whose sole active code is this single line?<p><pre><code> return Object.prototype.toString.call(arr) == '[object Array]';
</code></pre>
Is npm really the largest codebase, larger than PyPI, Maven and Ruby Gems?<p>On a more subjective level, does npm solve more nontrivial problems than any other programming language repository?
> Clojure hit the scene as a modern lisp that embraced the JVM.<p>> By now, Clojure is the de facto standard lisp for new applications.<p>What's with the whole, "modern," meme when people talk about Clojure? SBCL only forked off from CMU CL in 1999. Clozure CL is still well supported and actively developed. It's not like CL was written in the 1960s and had never changed ever since. The final standard was published in 1994. The alpha and beta of the JDK weren't released until a year later. Given that Clojure leverages so much of the JVM what exactly makes it the modern, de-facto standard for new applications? Don't we already have an ANSI standard for such a Lisp?<p>Is it modern because it can invent without restriction of a specification? That's a good thing and plenty of other Lisps are doing that... but what makes it, "modern," and why is it the standard? Is its relative immaturity a feature when you're taking on the world in a startup?<p>Either way it's not much of a secret anymore but I still don't see many startups advertising that they use Lisp -- even Clojure is rather rare. I hope more people give Lisp a try and kick butt.
Looks like a subtle ad for Clojure. Which I don't mind because I am slowly falling in love with Clojure. I am not sure if it's a "secret" or we should "write all the things in Clojure" but I'd love to see more companies use it, including start ups. I wouldn't mind working for one. Combine JVM's power with Om/Reagent and I think it's a solid stack. Although I am not advanced Clojure programmer. I wonder how it's doing in production?
I've never quite bought into the lisp idea that maximum "power" or "expressiveness" is always good. I could see it being an advantage for library authors who could present better, safer interfaces to the library's functionality. But if you have a startup, how much time do you have to build libraries and refine their interfaces?<p>I doubt that these qualities are <i>so</i> good that they would be a material advantage for application developers. And certainly not material enough that it would affect the outcome of a startup (unless it makes the engineers more motivated).<p>That being said, I hope clojure succeeds, and it's on my list to learn sometime (though not in the top 3).
But we need types people! Properly static ones that can be used to encode your intentions and handle inconsistency before even running the program. And yes I know that Clojure has an optional type system. But optional means that you cannot rely on having types in the libraries that you use. So you can't fit your stuff together with their stuff and have reasonable expectations that it will work once the user does that one thing you didn't think would be a most reasonable thing to do (of course it is, what were you thinking! And tell me again why you didn't just let the computer do that thinking for you?).
Flamewar in the comments here... Just throwing in my 2c.<p>I've been programming Clojure on the side for about a year now. It all started when I did the exercises in the Clojure for the Brave and True-book, and also simultaneously picked up Emacs and Cider (a nice IDE indeed, and keyboard-based).<p>Clj is just code like anything else. Anything you can do in Clojure you can do in Java. But with that language, I find myself creating things which I could not in other languages. Solutions come easier. Programs don't become long, but they get a lot done, and are performant.<p>I dig it, and really recommend it to anyone who is bored with their day job.
It's not secret, it's just that everybody who knows about it chooses not to use it.<p>Additionally, the fact that it's dynamically typed probably seals its fate (which is already pretty darned sealed).
I'll offer myself a shameless plug here. We've been using Clojure/ClojureScript for my current startup cloudmonkey.io and we absolutely love it.
This was a great read. I've always heard about Clojure and now I have a better idea as to what it is. I'm still going to stick with what I've heard all along: it doesn't matter what language you write in, it matters <i>how</i> you write it.
In the expressjs example, I wonder how practical is to do all that interop instead of just using plain JS? I mean, is awesome that Clojurescript can leverage all those JS libs, but its worth writing lots of interop just to use Clojurescript? Of course, as Clojurescript libraries grow this will not be an issue, but it is nowhere close to JS for web dev.<p>For me, a more practical approach for server side would be to use Clojure instead of Clojurescript, the problem is Clojure does not have the rich ecosystem of web libraries as nodejs does.
I tried Clojure, but immediately got the impression that the run-time type-system is ill-designed. I cannot recall the details, but I can remember odd things like different run-time types used for empty lists than for non-empty lists. A simple program doing a "switch" on some run-time types turned out to be really cluttered. But of course, there's always the possibility that I was doing something wrong :)
Here are some heretical thoughts. The language is irrelevant. The text editor is irrelevant. The OS is irrelevant. The size of your monitor is irrelevant. All your productivity hacks are irrelevant. The only relevant thing is your ability to formulate and solve problems.<p>You might say the language can help with both the formulation and the solution but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. So you can use lisp and I'll use ruby and at the end it'll all be a wash because the fundamental bottleneck will always be the speed at which you can formulate and solve problems and how quickly you can respond to market dynamics. All other choices are accidents of history.<p>Graham and his buddy were just good problem solvers.
><i>And all along, you're using a Lisp, which PG shows[2] is the most powerful kind of programming language.</i><p>This is too hand wavy for me.
Lisp? Meh! The real secret is Agda.<p>The real real secret is using a language so obscure that you end up writing the compiler for production use, by studying the compiler that some researcher created for a paper.