9 ms·

Lisp is still a secret weapon

162 points by kepzorz 11y ago

austenallred 11y ago
I get the sentiment, but I don't think a programming language is what Thiel was thinking of when he talked about "a secret."
- deleted 11y ago
  [deleted]
worldsayshi 11y ago
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?).
- skimpycompiler 11y ago
  I fully agree. Without types you just can't do much, or at least, if you're super good, compiler can't do much. And most of the time you're trying to make something faster.
  - skimpycompiler 11y ago
    HackerNews, a type hating community.
- worldsayshi 11y ago
  One day we will find that perfect type system (and associated compiler/IDE/Interactive front end) and then everyone will take one big sigh of relief. And then we all will start fixing problems in a way that makes them stay fixed.
  - abc_lisper 11y ago
    I agree types prevent people from shooting in their foot. Types are what make program ide friendly, and programmer friendly. Got that. But types are also what cause us to think with in the box i.e to say powerful type hierarchies, the ones that save us from writing boiler-plate are also the ones that are difficult to understand, and in Java, somewhat weird. Not to mention they are needlessly specific - Unless you have ML style parameterized types. Also, note that if you are working in type safe language, does not mean you can escape writing tests. You still have to write tests. Just like human body is not all bone, though it gives structure, nor a bridge is all steel, even though that is what keeps it together, likewise I don't believe all aspects of a project should be written in a strictly and statically typed language. Dynamic types have their niche, and the nice thing about dynamic types is you are just concerned with ideas aka abstractions instead of type algebra and its mechanics. Once you have protected your interfaces(with a type safe language), you are past "Idk what i am reading" stage, and hence in a safer place to do type agnostic things - and the sweet thing with clojure and lisps, yeah sweet if you get it, you can almost always break what you think your ceiling of capabilities is.
    - deleted 11y ago
      [deleted]
- i_s 11y ago
  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.
  - Roboprog 11y ago
    That pretty much describes my Angular data models, yes. My internal helper functions get passed sub-structures from the model, but Angular bindings get strings like "top.area.sub.fld" to name a variable. Doubtless, there's another way to do this without a global / dynamic data tree, but this is working, at least for me.
  - skimpycompiler 11y ago
    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.
    - jbeja 11y ago
      There is also zippers
    - davexunit 11y ago
- pakled_engineer 11y ago
  Typed Racket working for me lately https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-1/guide.html https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-... But again no massive ecosystem of libraries to simply plug in so unsure if 'secret weapon'. Also I have experienced the nightmare of trying to port non typed libraries to typed Clojure and falling into a rabbit hole of errors propagating. Haven't had the same problem with Racket but ecosystem is not even close to Clojure so anecdotes worthless.
- bjterry 11y ago
  Perhaps the ideal language would be one where every library is statically typed, either through social or technological means, but the application language is optionally typed. This would be a pretty big departure from most normal languages, but with opinionated languages like Go (which comes with its own code formatter) existing, it's not too crazy.
jorams 11y ago
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/
- noir_lord 11y ago
  That 200k figure isn't very comparable to other languages either as there are a lot of pacakages that just do a tiny thing and a hell if a lot of overlap in packages. While that's got upsides I must admit I prefer one or two relatively complete and stable packages over way more numerically but leas stable complete packages. But I come from a desktop background so I'm spoilt in that regard I guess. I view every additional depency as a weakness a year from now.
  - spronkey 11y ago
    Completely agree. Maintaining a node project is a nightmare job if you rely on any more than a trivial number of packages. The ecosystem is quicksand.
    - noir_lord 11y ago
      More akin to standing in quick sand while someone sets you fire and a succession of literal band wagons drives past ;).
Scarbutt 11y ago
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 11y ago
  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
- sheepmullet 11y ago
  > In the expressjs example, I wonder how practical is to do all that interop instead of just using plain JS? It depends. Interop in clojurescript isn't any more difficult than using plain JS but if your code is very interop heavy I don't think you gain a lot by using Clojurescript. For a web application though interop code is going to be a tiny fraction of the overall code.
fierycatnet 11y ago
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 11y ago
  In what way is it subtle? Seems quite blatant to me.
bbcbasic 11y ago
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.
- bbcbasic 11y ago
  The fact I am being downvoted is indicative that I am on to something. Think about it :-)
  - Ericson2314 11y ago
    I think yours is the best response to these sorts of painful-to-read HN threads.
    - bbcbasic 11y ago
      It was a serious answer though. If your USP is your technology, using Lisp is meh, you better be using something that is like dynamite to the problem you are trying to solve. And the problem you are solving is more like high-frequency trading or data analysis not a peer-to-peer marketplace for rickshaw riders and their passengers.
      - Ericson2314 11y ago
        Oh I don't mean to imply you weren't serious. I'd be very scared if I was competing with someone using Agda and I wasn't.
- antod 11y ago
  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 11y ago
    I am waiting for the cycle to repeat and basic to be cool again. I give it just 30 years.
nate_martin 11y ago
Are there any examples of companies that achieved success by way of language choice other than Viaweb?
- biot 11y ago
  WhatsApp is a good contender: http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...
- ced 11y ago
  Orbitz tackled a hard technical problem with Common Lisp. I don't know if it was the "secret weapon", but it must have been fairly critical. They needed efficiency. http://www.paulgraham.com/carl.html http://www.paulgraham.com/carl.html
- xiaoma 11y ago
  37signals / Basecamp
- incepted 11y ago
  Viaweb is not even an example of that. They're a startup that succeeded while using a niche language. That's correlation, not causation, despite everything pg says.
- e12e 11y ago
  I always thought dabbledb[1] was a good example of choosing Smalltalk. Sadly the product died, after the team moved to Twitter. Still not sure why they didn't just open up the source. [1] https://www.youtube.com/watch?v=6wZmYMWKLkY https://www.youtube.com/watch?v=6wZmYMWKLkY
- notahacker 11y ago
  I understand Lisp was pretty critical to ITA software's approach to solving hard technical problems
jtwebman 11y ago
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
- bbcbasic 11y ago
  With Lisp your program is data, like any other data, so it is easy to transform with macros etc. (Disclaimer I have never written a lisp program) On the other hand languages like Haskell have a powerful type system that largely negates the need for macros. However when you do want to macro in Haskell you have template Haskell and it is quite ugly. In a nutshell: Language wars are stupid.
- cheez 11y ago
  It's like Python, but you can transform the structure of your program with the language itself.
  - mycelium 11y ago
    https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
- wmil 11y ago
  I've seen some impressive integration between Clojure and Emacs. A quick edit - run cycle is a huge win. As are good debugging tools.
  - davexunit 11y ago
    See Geiser + Guile/Racket or SLIME + Common Lisp for other examples of excellent Lisp development environments.
- sheepmullet 11y ago
  > 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.
jeffdavis 11y ago
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).
snake117 11y ago
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.
- deleted 11y ago
  [deleted]
amelius 11y ago
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 11y ago
  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 11y ago
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.
- raspasov 11y ago
  You are absolutely right. However, if you use a cluttered language with a dozen choices for a data structure or concurrency (as far as I know Ruby is not one of them), you'll run into many accidental problems before you even get to solving your business domain problem.
- agumonkey 11y ago
  It goes hand in hand. Back in the days people said lisp in newbies hands will be backfire, but handled by those with abstraction skills it will give you ability to express things you cannot with other systems. Many here agree that technology should not matter, but it does at one point. Some trait of the culture behind and around languages are very very important. Lisp tree recursion, "lexicality" and ad-hoc genericity is not present in other languages. Immutability in the ml land (even though side effects are permitted in some) is also something few people have to live in and understand. Both these things give you new idioms, hints, point of view about how to solve problems. It also sheds light on the other ones.
  - dkarapetyan 11y ago
    I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the easy part and it really doesn't matter what the target language ends up being. Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. So I don't think it goes hand in hand. The fundamental bottleneck is always what's in your head.
raspasov 11y ago
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.
Havoc 11y ago
Characterising a well know language as a "secret weapon" seems a little odd to me.
jlarocco 11y ago
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 11y ago
  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 11y ago
    Your Kawa URL is broken; should be https://www.gnu.org/software/kawa/ https://www.gnu.org/software/kawa/
hardwaresofton 11y ago
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 11y ago
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 11y ago
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?
incepted 11y ago
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 11y ago
  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 11y ago
    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.
    - Guthur 11y ago
      For what figures there are your claim has no basis. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Top 10 is full of dynamic languages, Go is not in the top 20 and all the languages you claim are fading are climbing in this particular metric.
    - mycelium 11y ago
      > 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.
agentultra 11y ago
> 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 11y ago
  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.
  - dllthomas 11y ago
    In general, I would not expect something "modern" to be doing new things, but doing everything that has come to be expected and doing it well. I have no opinion that I would defend as to the degree to which that applies to Clojure.
  - jwr 11y ago
    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.
nnq 11y ago
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
kuyfiuyg 11y ago
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.
coldtea 11y ago
>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.

162 points by kepzorz 11y ago

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

deleted 11y ago
[deleted]

worldsayshi 11y ago

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

skimpycompiler 11y ago
I fully agree. Without types you just can't do much, or at least, if you're super good, compiler can't do much. And most of the time you're trying to make something faster.
- skimpycompiler 11y ago
  HackerNews, a type hating community.
worldsayshi 11y ago
One day we will find that perfect type system (and associated compiler/IDE/Interactive front end) and then everyone will take one big sigh of relief. And then we all will start fixing problems in a way that makes them stay fixed.
- abc_lisper 11y ago
  I agree types prevent people from shooting in their foot. Types are what make program ide friendly, and programmer friendly. Got that. But types are also what cause us to think with in the box i.e to say powerful type hierarchies, the ones that save us from writing boiler-plate are also the ones that are difficult to understand, and in Java, somewhat weird. Not to mention they are needlessly specific - Unless you have ML style parameterized types. Also, note that if you are working in type safe language, does not mean you can escape writing tests. You still have to write tests. Just like human body is not all bone, though it gives structure, nor a bridge is all steel, even though that is what keeps it together, likewise I don't believe all aspects of a project should be written in a strictly and statically typed language. Dynamic types have their niche, and the nice thing about dynamic types is you are just concerned with ideas aka abstractions instead of type algebra and its mechanics. Once you have protected your interfaces(with a type safe language), you are past "Idk what i am reading" stage, and hence in a safer place to do type agnostic things - and the sweet thing with clojure and lisps, yeah sweet if you get it, you can almost always break what you think your ceiling of capabilities is.
  - deleted 11y ago
    [deleted]
i_s 11y ago
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.
- Roboprog 11y ago
  That pretty much describes my Angular data models, yes. My internal helper functions get passed sub-structures from the model, but Angular bindings get strings like "top.area.sub.fld" to name a variable. Doubtless, there's another way to do this without a global / dynamic data tree, but this is working, at least for me.
- skimpycompiler 11y ago
  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.
  - jbeja 11y ago
    There is also zippers
  - davexunit 11y ago
pakled_engineer 11y ago
Typed Racket working for me lately https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-1/guide.html https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-... But again no massive ecosystem of libraries to simply plug in so unsure if 'secret weapon'. Also I have experienced the nightmare of trying to port non typed libraries to typed Clojure and falling into a rabbit hole of errors propagating. Haven't had the same problem with Racket but ecosystem is not even close to Clojure so anecdotes worthless.
bjterry 11y ago
Perhaps the ideal language would be one where every library is statically typed, either through social or technological means, but the application language is optionally typed. This would be a pretty big departure from most normal languages, but with opinionated languages like Go (which comes with its own code formatter) existing, it's not too crazy.

jorams 11y ago

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/

noir_lord 11y ago
That 200k figure isn't very comparable to other languages either as there are a lot of pacakages that just do a tiny thing and a hell if a lot of overlap in packages. While that's got upsides I must admit I prefer one or two relatively complete and stable packages over way more numerically but leas stable complete packages. But I come from a desktop background so I'm spoilt in that regard I guess. I view every additional depency as a weakness a year from now.
- spronkey 11y ago
  Completely agree. Maintaining a node project is a nightmare job if you rely on any more than a trivial number of packages. The ecosystem is quicksand.
  - noir_lord 11y ago
    More akin to standing in quick sand while someone sets you fire and a succession of literal band wagons drives past ;).

Scarbutt 11y ago

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 11y ago
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
sheepmullet 11y ago
> In the expressjs example, I wonder how practical is to do all that interop instead of just using plain JS? It depends. Interop in clojurescript isn't any more difficult than using plain JS but if your code is very interop heavy I don't think you gain a lot by using Clojurescript. For a web application though interop code is going to be a tiny fraction of the overall code.

fierycatnet 11y ago

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 11y ago
In what way is it subtle? Seems quite blatant to me.

bbcbasic 11y ago

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.

bbcbasic 11y ago
The fact I am being downvoted is indicative that I am on to something. Think about it :-)
- Ericson2314 11y ago
  I think yours is the best response to these sorts of painful-to-read HN threads.
  - bbcbasic 11y ago
    It was a serious answer though. If your USP is your technology, using Lisp is meh, you better be using something that is like dynamite to the problem you are trying to solve. And the problem you are solving is more like high-frequency trading or data analysis not a peer-to-peer marketplace for rickshaw riders and their passengers.
    - Ericson2314 11y ago
      Oh I don't mean to imply you weren't serious. I'd be very scared if I was competing with someone using Agda and I wasn't.
antod 11y ago
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 11y ago
  I am waiting for the cycle to repeat and basic to be cool again. I give it just 30 years.

nate_martin 11y ago

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

biot 11y ago
WhatsApp is a good contender: http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...
ced 11y ago
Orbitz tackled a hard technical problem with Common Lisp. I don't know if it was the "secret weapon", but it must have been fairly critical. They needed efficiency. http://www.paulgraham.com/carl.html http://www.paulgraham.com/carl.html
xiaoma 11y ago
37signals / Basecamp
incepted 11y ago
Viaweb is not even an example of that. They're a startup that succeeded while using a niche language. That's correlation, not causation, despite everything pg says.
e12e 11y ago
I always thought dabbledb[1] was a good example of choosing Smalltalk. Sadly the product died, after the team moved to Twitter. Still not sure why they didn't just open up the source. [1] https://www.youtube.com/watch?v=6wZmYMWKLkY https://www.youtube.com/watch?v=6wZmYMWKLkY
notahacker 11y ago
I understand Lisp was pretty critical to ITA software's approach to solving hard technical problems

jtwebman 11y ago

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

bbcbasic 11y ago
With Lisp your program is data, like any other data, so it is easy to transform with macros etc. (Disclaimer I have never written a lisp program) On the other hand languages like Haskell have a powerful type system that largely negates the need for macros. However when you do want to macro in Haskell you have template Haskell and it is quite ugly. In a nutshell: Language wars are stupid.
cheez 11y ago
It's like Python, but you can transform the structure of your program with the language itself.
- mycelium 11y ago
  https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
wmil 11y ago
I've seen some impressive integration between Clojure and Emacs. A quick edit - run cycle is a huge win. As are good debugging tools.
- davexunit 11y ago
  See Geiser + Guile/Racket or SLIME + Common Lisp for other examples of excellent Lisp development environments.
sheepmullet 11y ago
> 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.

jeffdavis 11y ago

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

snake117 11y ago

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.

deleted 11y ago
[deleted]

amelius 11y ago

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 11y ago
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 11y ago

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.

raspasov 11y ago
You are absolutely right. However, if you use a cluttered language with a dozen choices for a data structure or concurrency (as far as I know Ruby is not one of them), you'll run into many accidental problems before you even get to solving your business domain problem.
agumonkey 11y ago
It goes hand in hand. Back in the days people said lisp in newbies hands will be backfire, but handled by those with abstraction skills it will give you ability to express things you cannot with other systems. Many here agree that technology should not matter, but it does at one point. Some trait of the culture behind and around languages are very very important. Lisp tree recursion, "lexicality" and ad-hoc genericity is not present in other languages. Immutability in the ml land (even though side effects are permitted in some) is also something few people have to live in and understand. Both these things give you new idioms, hints, point of view about how to solve problems. It also sheds light on the other ones.
- dkarapetyan 11y ago
  I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the easy part and it really doesn't matter what the target language ends up being. Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. So I don't think it goes hand in hand. The fundamental bottleneck is always what's in your head.

raspasov 11y ago

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.

Havoc 11y ago

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

jlarocco 11y ago

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 11y ago
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 11y ago
  Your Kawa URL is broken; should be https://www.gnu.org/software/kawa/ https://www.gnu.org/software/kawa/

hardwaresofton 11y ago

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 11y ago

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 11y ago

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?

incepted 11y ago

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 11y ago
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 11y ago
  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.
  - Guthur 11y ago
    For what figures there are your claim has no basis. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Top 10 is full of dynamic languages, Go is not in the top 20 and all the languages you claim are fading are climbing in this particular metric.
  - mycelium 11y ago
    > 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.

agentultra 11y ago

> 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 11y ago
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.
- dllthomas 11y ago
  In general, I would not expect something "modern" to be doing new things, but doing everything that has come to be expected and doing it well. I have no opinion that I would defend as to the degree to which that applies to Clojure.
- jwr 11y ago
  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.

nnq 11y ago

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

kuyfiuyg 11y ago

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.

coldtea 11y ago

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