I’ve been following people like Jonathan Blow, as well as Paul Graham. I’ve learned Lisp and kind of like it, but I’ve heard Jonathan Blow say that A) GC is bad, and B) not to use Lisp and other similar languages. Could you explain these reasons not to use Lisp/higher-level languages with more features?
To paraphrase Ansel Adams (who was speaking of cameras), there is no one best language only the best language for the project you're doing. It may very well be that Lisp is the right language for your project. That depends largely on what the project is and what advantage you are seeking from Lisp (or another choice) that helps complete your project and, most importantly, reduces debugging time later since that's where you'll spend 60% of your coding effort.<p>We are building our product with a Lisp back end because it deals with NLP and large bodies of text where Lisp is ideal. The user interface, however, is HTML/JS (Angular) because that language offers much more flexibility for UI design.
Jonathan Blow is an opinionated game programmer/language creator who is eg concerned about memory management eating into his 360 Hz display frametime[1]. GC is still used in many games, eg Unity engine, so it's not a universally held view in the field of games. You should probably tell us more about what domain you are working in and/or read his opinions in the contex of his domain.<p>As for your (B), besides the "is it bad" essay question you probably want to look at languages specifically. As you know there are many Lisp style languages and they have big differences. Eg Clojure, Scheme and Common Lisp are all very different and have different kinds of communities. It's a language family of more internal variety than eg modern Algol style imperative managed statically typed languages (Java/C#/Go).<p>[1] A topic of some of his tweets recently
Sounds like your question is about high-level GCed languages in general. The person you're referencing appears to be in the gaming industry where GC is especially problematic.<p>If we're talking about Lisp specifically vs similar languages, people probably end up not using it for non-technical reason. Community, hire-ability and so forth.
I've read a lot about Lisps with an open mind, worked through SICP in Racket, and worked on some personal projects in Clojure. It was all fine, but at no point did I feel like there wasn't another language that would have done as well, possibly better. The one area where I was never fully comfortable was the lack of static type checking. I've also dabbled with Haskell and though it it is the most clean and consistent language I've used. I never got to the point where I could wield higher kinded types to my advantage, I felt like I was doing extra work to satisfy the language requirements without necessarily getting the benefits back from it. I realize there's benefits of doing so, but it's unclear when/if I'll even break even.<p>Recently I tried F# having seen OCaml in the past but not really using it. F# seems to have progressed quite a bit since it was just OCaml on .NET. I'm able to work rather fluently with it having already been exposed to Java/Kotlin/Scala/Elixir which seemed close to what I want but seeming to fall short in ways I couldn't quite describe. F# came the closest to what I've always hoped to find in a language. It too has its quirks, some within itself and partly from interoperating within .NET Core. I've yet to use it on larger projects and on a team but the static type checking has already helped me save so much time on iterating design that I wont look at any Lisp for generic work. If I had a need for some specific DSL task it may come in handy as I've often baked minimally expressive configuration languages in the past for no good reason.
Depends on what you are implementing and how.<p>I find Lisp good if you have a rough top-down design and lots of bottom-up implementation details to suss-out. You can test each bit as you build and in passing you might implement a DSL for your domain. There are many compiled Lisps (both CL and Scheme) so performance can be quite good.<p>Generally, it is hard to deploy Lisp on client systems (if that is a requirement) without introducing many dependencies. Loko Scheme being an exception, since it (like Golang) compiles to a single executable with no dependencies.<p>GC and VMs are common in many alternative environments so that's not a point of difference.<p>If you like Lisp and your dev and target environments are suitable and you are a solo developer or have a team of Lispers then why not use it? In most general terms Lisp is no better nor worse than the alternatives.
Assuming performance isn't a problem (which it may well not be), this does a good job of laying out all the other arguments against Lisp: <a href="http://winestockwebdesign.com/Essays/Lisp_Curse.html" rel="nofollow">http://winestockwebdesign.com/Essays/Lisp_Curse.html</a><p>Basically: Lisp projects have trouble scaling to larger teams (and communities) because of how fluid it is. That said, for a solo project or a small team, no language has more expressive power.<p>That said, Jonathan Blow has the occasional good opinion and a lot of really bad ones. His anti-abstraction zealotry is the basis of most of the bad ones. As another commenter here said, there are no universal truths when choosing a technology; it's always about using the right tool for the job.
Because static typing is important for working productively with medium-to-large programs, because the Lisps have decrepit ecosystems, and because they aren't even good dynamically typed languages either, with the possible exception of Clojure. There is nothing that Common Lisp has, that other languages don't have, that makes it necessary.