
Lisp is still a secret weapon - kepzorz
http://kep.io/is-lisp-still-a-secret-weapon/
======
jorams
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.

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.

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.

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].

[1]: [https://www.quicklisp.org/](https://www.quicklisp.org/) [2]:
[http://abcl.org/](http://abcl.org/)

~~~
bad_user
Seeing Common Lisp fans arguing against Clojure fans is funny since your
market share combined is insignificant compared with the mainstream choices.
You should learn from each other and grow that pie together.

I also don't agree with you. Intuitively Lisp might be a secret weapon for
startups, but not for open source where the communities of the mainstream
choices are more productive, simply because of popularity. Java is a huge
ecosystem of working and mature solutions. If you don't depend on Java, you
depend on C. And for the kind of problems Lisp is suited for, I'd rather take
Java. You're also missing the point on JavaScript. Say what you will about the
quality of npm packages, but ClojureScript can reach people that your favorite
CLisp cannot, due to the browser.

Also you can't seriously recommend ABCL.

~~~
arximboldi

      > Intuitively Lisp might be a secret weapon for startups, but not for open source 
      > where the communities of the mainstream choices are more productive, simply because
      > of popularity
    

Open source is not a popularity contest. In fact, open source, and specially
free and libre software, is a great place for leftfield technologies to
flourish. In fact, Lisp had a place in free software before Github even
existed, with various flavours being the scripting language of choice in
popular projects like Emacs, Gimp or Gnome.

It is rather in the proprietary corporate world where there is often
resistance to adopt languages outside of the mainstream. The more supply of
developers for a technology is available, the lower cost of labour. It's hard
for the merits of a technology to argue against this fact in the face of
management.

~~~
coldtea
Nobody who uses it really likes Emacs list and Guile didn't get far. Not the
best success stories to give.

------
nnq
If you're asking yourself what kinds of problems is a Lisp good for you should
probably watch this:
[https://www.youtube.com/watch?v=8X69_42Mj-g](https://www.youtube.com/watch?v=8X69_42Mj-g)
(A computational chemist built himself his own Common Lisp implementation
because no other language available was powerful enough for his needs...)

It basically boils to: if you're solving a _truly new and interesting
problems_ 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.

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...

EDIT+: another example is DWave using SBCL:
[http://www.dwavesys.com/careers/senior-software-
developer](http://www.dwavesys.com/careers/senior-software-developer) \- if
quantum (or analog... anyway...) computing is not "truly new and cutting
edge", than I don't know what is

------
jlarocco
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.

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.

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.

~~~
Per_Bothner
You might want to check out Kawa:
[http://www/gnu.org/software/kawa](http://www/gnu.org/software/kawa) . It's
mature (since 1996); runs on the JVM; compatible with Scheme standards
(basically full R7RS except for continuations); great Java/JVM interop;
trivial and flexible deployment (just a jar, unlike Clojure which assumes its
own eco-system); extremely fast start-up (easily beats ABCL and Clojure); good
compile-time and run-type error-reporting; and best-of-class runtime speed
(comparable to Java/Scala with appropriate use of optional type specifiers).

~~~
yellowapple
Your Kawa URL is broken; should be
[https://www.gnu.org/software/kawa/](https://www.gnu.org/software/kawa/)

------
hardwaresofton
This seems like a little bit (probably a lot) of hyperbole around clojure.

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.

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.

------
sjatkins
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.

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.

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.

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".

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

------
jordigh
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?

    
    
         return Object.prototype.toString.call(arr) == '[object Array]';
    

Is npm really the largest codebase, larger than PyPI, Maven and Ruby Gems?

On a more subjective level, does npm solve more nontrivial problems than any
other programming language repository?

------
agentultra
> Clojure hit the scene as a modern lisp that embraced the JVM.

> By now, Clojure is the de facto standard lisp for new applications.

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?

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?

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.

~~~
Guthur
I too would love to know the basis of the "Modern Lisp" meme. There is very
little in Clojure that has not been done before.

~~~
jwr
As a long time Common Lisper, allow me to disagree. The STM and concurrency
features of Clojure are what brought me in, and they certainly haven't been
"done before". Common Lisp's concurrency story was always poor.

You could also argue that the effects of lazy evalutation and transducers
could have been achieved before using SERIES package, but then you surely
haven't tried to actually use and debug SERIES code.

~~~
agentultra
> The STM and concurrency features of Clojure are what brought me in, and they
> certainly haven't been "done before". Common Lisp's concurrency story was
> always poor.

It's the JVM that does most of the work here for Clojure. You get the same
features when working in Java if you wanted them.

Most CL implementations provide access to native threads and kernel polling
facilities (kqueue, select, epoll, etc).

If "modern," means, "leverages the libraries and implementation of a well-
funded ecosystem" then I suppose you have a point. Clojure is quite modern.
And that is confusing.

> You could also argue that the effects of lazy evalutation and transducers
> could have been achieved before using SERIES package, but then you surely
> haven't tried to actually use and debug SERIES code.

I'd much rather debug CL code any day. Even at its worst it is still far ahead
of Java's tracebacks and having to mentally map them back to where the error
occurred in your Clojure code.

------
nate_martin
Are there any examples of companies that achieved success by way of language
choice other than Viaweb?

~~~
biot
WhatsApp is a good contender: [http://highscalability.com/blog/2014/2/26/the-
whatsapp-archi...](http://highscalability.com/blog/2014/2/26/the-whatsapp-
architecture-facebook-bought-for-19-billion.html)

------
austenallred
I get the sentiment, but I don't think a programming language is what Thiel
was thinking of when he talked about "a secret."

------
fierycatnet
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?

~~~
jimbokun
In what way is it subtle? Seems quite blatant to me.

------
jeffdavis
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?

I doubt that these qualities are _so_ 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).

That being said, I hope clojure succeeds, and it's on my list to learn
sometime (though not in the top 3).

------
Havoc
Characterising a well know language as a "secret weapon" seems a little odd to
me.

------
worldsayshi
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?).

~~~
i_s
Types do have a lot of benefits but they also come with a big cost: some
programs are very hard to express in modern type systems. For example,
consider a pattern that is becoming more common today in UI programming (even
in plain javascript): keeping your UI in one big tree data structure, and then
working on arbitrary paths (represented by a sequence of keys) into that data
structure. That is not a pattern you can encode in a type system.

Types also come with a lot of inherent complexity that you don't get with
dynamic programs. Recently, I wrote a Type Provider for web Routing in F#, and
it is orders of magnitude more complicated than what a dynamic approach would
have been. It is nice that it is not possible to express a program that uses
route parameters the wrong way, or provide a route that is unreachable, etc,
but it takes a lot more work than a dynamic version with no such safety.

One domain where I think static typing is worth it is for parsing. After
having used FParsec to parse a structure, and also having tried it
dynamically, I felt the static typing added little complexity for all the
safety it brought, so it was very much worth it. But there are also some
dynamic parsing libraries that much easier to get started with, such as
Instaparse, so YMMV.

~~~
skimpycompiler
Types + pattern matching -- best combination for working with trees.

I'm not sure if there's a library in F# similar to HXT, but in Haskell,
working with large xml structures is a breeze.

~~~
davexunit
I use a pattern matcher that can match against types in Scheme, a language
without static typing. Static types are just not the crucial feature that some
people make them out to be. I believe this criticism of Pascal and C from SICP
applies to other languages with static types (sans the pointer stuff):

    
    
        Pascal and C admit structures whose elements are structures. However,
        this requires that the programmer manipulate pointers explicitly, and
        adhere to the restriction that each field of a structure can contain
        only elements of a prespecified form. Unlike Lisp with its pairs,
        these languages have no built-in general-purpose glue that makes it
        easy to manipulate compound data in a uniform way.
    

With static typing, it's also difficult to write procedures that operate on
arguments of which the type is none of the procedure's business.

[https://sarabander.github.io/sicp/html/2_002e2.xhtml#FOOT73](https://sarabander.github.io/sicp/html/2_002e2.xhtml#FOOT73)

~~~
skimpycompiler
Well, I was definitely not mentioning Pascal and C. Haskell's type system is
much easier to work with.

The thing is that any operation you are using on those arguments (of which the
type is none of the procedure's business) can be described by an interface
which the argument implements.

You're much safer knowing in compile time that the operations you'll use will
be valid, instead of hoping something doesn't crash in runtime.

------
kuyfiuyg
Flamewar in the comments here... Just throwing in my 2c.

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).

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.

I dig it, and really recommend it to anyone who is bored with their day job.

------
incepted
It's not secret, it's just that everybody who knows about it chooses not to
use it.

Additionally, the fact that it's dynamically typed probably seals its fate
(which is already pretty darned sealed).

~~~
Guthur
How does being dynamically typed seal it's fate?

Dynamic typing does not seem to be on the way out at all, cases in point;
Javascript (everywhere), Python, Ruby to name the big ones.

~~~
incepted
Javascript will probably be around for a while but Python and Ruby have been
constantly shrinking in mind share and buzz these past years (mostly because
of Go but also because there are now faster, statically typed languages that
subsume them).

The simple truth is that statically typed languages have been much better at
improving in areas where dynamically typed languages used to be the only ones
shining than the other way around.

In a few years, we'll look back at dynamically typed languages with the same
fondness as we do Pascal: it was a good idea at the time but we do better now.

~~~
mycelium
> Javascript will probably be around for a while but Python and Ruby have been
> constantly shrinking in mind share and buzz these past years

At least in the scientific and data analysis communities, Python is exploding.
I'd say it's neck and neck with R. R's infrastructure outside data analysis is
weak but improving. Go isn't even a part of the conversation.

Can't speak to Ruby, but as the "big data" hype cycle continues Python will
continue to blow up.

------
raspasov
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.

------
jtwebman
He didn't sell me on why Lisp is better than any other language? Why would you
pick Lisp or Clojure over say Elixir, Scala, or even F#?

JT

~~~
sheepmullet
> Why would you pick Lisp or Clojure over say Elixir, Scala, or even F#?

They are all great choices!

F# is an excellent choice if you are happy living within the .net ecosystem.
I'd highly recommend it if you are a c# dev. Tooling is great. Ecosystem is
really good etc. Performance is really good.

Elixir? Its a really good option for high concurrency apps. It's based upon
Erlang and has access to heavily battle tested libraries. Tooling and
ecosystem not as good for many kinds of applications as the jvm/clr.

Scala? Another good option somewhat limited by its complexity. I personally
prefer F# and I think it has better tooling. Nevertheless it's a great option
for the jvm crowd.

Why did I choose clojure? Mainly for its good defaults, a community focused on
simplicity, data, and composability, a great jvm AND JavaScript story, macros,
amazing tooling, and ease of learning.

~~~
jtwebman
Thanks for the breakdown!

------
snake117
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 _how_ you
write it.

------
Scarbutt
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.

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.

~~~
base698
If you're starting from from scratch it looks really awesome. No callback hell
and in believable tooling. Watch these talks to see what I mean about tooling:

Few minutes [https://youtu.be/KZjFVdU8VLI](https://youtu.be/KZjFVdU8VLI)

Longer [http://www.infoq.com/presentations/clojurescript-web-
ios](http://www.infoq.com/presentations/clojurescript-web-ios)

------
amelius
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 :)

~~~
bad_user
In a dynamic language you're not supposed to rely on types, but on (dynamic)
interfaces. Also Clojure, as a design choice, converts your collection into a
lazy list when applying operators, then you need to convert it back if you
want by using "into".

------
dkarapetyan
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.

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.

Graham and his buddy were just good problem solvers.

~~~
Scarbutt
I wonder if Graham was presented with the same problem today, will he pick a
lisp and write everything from scratch or pick up a less "expressive" language
because it has a strong and mature ecosystem of libs.

~~~
byron_fast
The reason Paul Graham used Lisp is it was the only reasonable way at the time
to implement RTML, which was the HTML macro language with online editor that
Viaweb was built out of. RTML was how every website in Viaweb was constructed,
it is what allowed them to move quickly and customers to customize with
unequaled flexibility.

It was their key competitive advantage and Lisp was critical to its creation
and function. It would be foolish to attempt to implement RTML in something
else. Perhaps slightly less foolish in 2015 but not by much.

------
coldtea
> _And all along, you 're using a Lisp, which PG shows[2] is the most powerful
> kind of programming language._

This is too hand wavy for me.

------
bbcbasic
Lisp? Meh! The real secret is Agda.

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.

~~~
antod
Does that mean BBC Basic is no longer your preferred secret weapon?

Or was your post just a diversionary tactic to protect your competitive
advantage?

~~~
bbcbasic
I am waiting for the cycle to repeat and basic to be cool again. I give it
just 30 years.

