> I sometimes wonder why Lisp has not been more popular in the technology industry. I think one of the problems is one of marketing. The hackers of the 60s wouldn't have cared but there must be a number of people and businesses since who have been put off, consciously or unconsciously, by the language having the same name as a speech impediment. I'm being entirely serious; I think the language would have been more po…
> I'm being entirely serious; I think the language would have been more popular with a cooler name. How do you explain the lack of popularity of Lisp dialects that do not use "Lisp" in their name, for example, Arc, Racket and Clojure. I know that HN was written in Arc, Arc was written in Racket and Clojure is used in a handful of companies but a far greater number of companies and projects use Python.
Cool names might be neccessary, but not sufficient, for popularity?
My AI class teacher was one of the founders of Siscog. I learned scheme and lisp at college too. Glad to see his company being mentioned.
You might be pleased or displeased to know that at Técnico they no longer teach Scheme in the introductory programming course, nowadays it's Python. When I did the AI course, the project was still to be developed in Lisp, but more recently I recall hearing that they were thinking of switching to another language because "nobody can stand lisp". Fun fact: one of the founders of Siscog, Ernesto Morgado[1], is big in the rice business, and is/was the president of multiple rice millers associations. Both Pavão Martins and Ernesto Morgado still lecture at Técnico.
Lisp is quite popular at my current workplace. A few popular open source projects published by our organization have been written in Clojure (a dialect of Lisp that runs on JVM and CLR). A few domain specific languages used internally in our organization are also inspired by Lisp. On a more personal front, I find Lisp to be simple, elegant, and expressive. I use Common Lisp (SBCL) for personal use. Working with Lisp…
I'd say several reasons:
1.) a lot of folks have trouble with the abstactness
2.) a lot of folks think C syntax is how all languages should be
3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new
4.) poor windows support for SBCL...it literally tells you it is experimental if I recall correctly. Setup wasn't straightforward
5.) tooling is complex and emacs is recommended for both SBCL & Clojure, which is arguably more difficult than hitting run in most modern IDEs
6.) multi-core seems to only be in Clojure
7.) lack of decent libraries. There is always someone quick to say that this is false and that they have everything you need, but coming from Python and Perl's CPAN, I couldn't disagree more
8.) learning resources are very hit or miss. I found it hard to pay attention to many of the top lisp books because a lot of the examples such as building an mp3 database would be one line of code or two in python. Of course they're just trying to show concepts and terse expressions isn't where lisp shines, but the effect is underwhelming.
9.) your fellow developers won't use it and a large company will probably have an IT department that won't let you run in production without it being far better known: Java, C#, Python, R, C++, Perl, Ruby, JavaScript...etc without major pushback...notice how many people equate lisp with personal projects?
Great site, seems to have a good collection of lisp resources. I am waiting for the documentation to go online, it says it is still parsing the TeX sources of the commonlisp hyperspec. As a side note, I downloaded the Lispworks Common Lisp Hyperspec, but I could only find the HTML version. I see that the project is on Github, maybe someone will parse the Hyperspec and generate the documentation pages. I am adding a r…
> I sometimes wonder why Lisp has not been more popular in the technology industry. I think one of the problems is one of marketing. The hackers of the 60s wouldn't have cared but there must be a number of people and businesses since who have been put off, consciously or unconsciously, by the language having the same name as a speech impediment. I'm being entirely serious; I think the language would have been more po…
> I'm being entirely serious; I think the language would have been more popular with a cooler name. How do you explain the lack of popularity of Lisp dialects that do not use "Lisp" in their name, for example, Arc, Racket and Clojure. I know that HN was written in Arc, Arc was written in Racket and Clojure is used in a handful of companies but a far greater number of companies and projects use Python.
Probably because Arc is an incomplete hobby project of Paul Graham that will never be finished now and has only a tiny following of a few people. Yes it runs this site, but not much else. Clojure isn't very easy to learn and I found the Racket ecosystem too minimum. The name sure doesn't help.
I know the article is about Common Lisp, but I have a question about Racket, Typed Racket specifically. Can anyone say if types and Lisp play well together? Are there any success stories?
It might surprise you, but Lisp is actually mixed typed. Here 'object' is of the type integer:
(defmethod description ((object integer))
(format nil "The integer ~D" object))
Often those who are curious to try Lisp are faced with a number of choices: Which dialect to choose? Which implementation to choose? Which book or tutorial should one follow? Is it necessary use Emacs? SLIME? Here are my recommendations: - Choose Common Lisp because it has been the most popular dialect of Lisp in the overall history of Lisp. It is more convenient than Scheme if one decides to develop serious software…
I'd recomment a ClozureCL instead of SBCL for a newcomer, because CCL does not do some optimizations and it is easier to debug. For example, it will show you local variables created by `let`, but SBCL – does not.
Running
(declaim (optimize (debug 3)))
in your repl will turn these optimizations off and give you roughly the same debugging experience.
Not really, the empty list, None, and False are distinct values in Python. In [1]: [] is None Out[1]: False In [2]: [] is False Out[2]: False In [3]: [] == False Out[3]: False In [4]: [] == None Out[4]: False In [5]: False is None Out[5]: False In [6]: False == None Out[6]: False This kind of relatively fine-grained distinction between different types of data is essential for operation in a world where other systems…
Not really, the empty list, None, and False are distinct values in Python. In [1]: [] is None Out[1]: False In [2]: [] is False Out[2]: False In [3]: [] == False Out[3]: False In [4]: [] == None Out[4]: False In [5]: False is None Out[5]: False In [6]: False == None Out[6]: False This kind of relatively fine-grained distinction between different types of data is essential for operation in a world where other systems…
However: if not []: print("looks boolean to me...")
Python code rarely looks like this
For things like optional arguments you usually use None with an "if l is None" parameter
Meanwhile you can't iterate over None, so [x for x in None] blows up
Closure (to my understanding) allows a null value in the place of any empty seq. This seems like a major bug swallower to me
Not really, the empty list, None, and False are distinct values in Python. In [1]: [] is None Out[1]: False In [2]: [] is False Out[2]: False In [3]: [] == False Out[3]: False In [4]: [] == None Out[4]: False In [5]: False is None Out[5]: False In [6]: False == None Out[6]: False This kind of relatively fine-grained distinction between different types of data is essential for operation in a world where other systems…
However: if not []: print("looks boolean to me...")
Can't win em all I suppose :P
My point is that, for me, Common Lisp is particularly defficient in this regard, in a way that means I can't really consider using Common Lisp for development work today.