44 ms·

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

• s_kilk 9y ago
  > I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? Is it the lack of an extensive library ecosystem? Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. I could tell instantly that I'd have a hard time interfacing with data from other real-world systems, so I decided to skip CL and stick to Clojure and various Schemes for my lispy kicks.
  • xyrouter 9y ago
    Isn't that true in Python too?
    • s_kilk 9y ago
      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 presume that you can handle these distinctions.
      • kleiba 9y ago
        However: if not []: print("looks boolean to me...")
        • rtpg 9y ago
          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
          • yen223 9y ago
            > Python code rarely looks like this Using implicit truthiness to test for empty sequences is idiomatic Python, for better or worse.
            • rtpg 9y ago
              Sorry, you're actually very right. I think I misread this in the case of a default argument example (which at least for codebases I work with are diligent about doing None tests for ) but if you know that the value is set to a sequence then the boolean test is common
        • s_kilk 9y ago
          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.
          • s_kilk 9y ago
            (Nice to see the Lisp Defence Force out in strength.)
          • kazinator 9y ago
            Different programming languages play different games with booleans, empties, undefinedness and such. In all of them, people are able to Get Stuff Done, correctly handling inputs from the world. In the POSIX shell, a failed termination status of a command is a false condition. Storing false as a datum is usually represented by an empty or unset variable. Yet, people are able to write robust shell scripts to boot systems, build programs and so on. Everything you wrote is based on a guess; not even anecdotal experience. That is below the expected level of discussion on HN. The nil/empty/false thing is an excellent tradeoff in code that manipulates lists, rendering it succinct. For instance an expression like (when attributes (do-this ...)) means, (do-this ...) when attributes are present; i.e. the list of attributes is not empty. All the default nil return values that occur are automatically empty lists, which is very convenient. For instance a two-clause if (if condition then) returns nil if condition is false. If the caller expects a list, then that is perfect; it's the empty list. All these little conveniences dove-tail together to clarify the code. The empty/false conflation doesn't do anything in code that doesn't manipulate lists. For instance, if you're manipulating numbers, or strings, there is no ambiguity: nil isn't a number and it isn't a string. It is distinct from 0, 0.0, and "". You cannot have a meaningful opinion about this that anyone should take seriously unless you have experience with it: having experienced both the convenience in writing list manipulation code (particularly code-writing code) and the situations in which the ambiguity between nil (the atom) and nil (the empty list) was actually a problem.
  • rauhl 9y ago
    > Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. Oddly enough, that’s almost always something I consider a feature, even when I'm interfacing with the outside world. If I’m expecting a list, then NIL is just an empty list; if I'm expecting a value, then distinguishing NIL & false hasn’t caused me trouble. Worst-case, it’s been something I take care of at the mapping level, and don’t worry about anywhere else. In return, actually using Lisp is really pleasant. Using Scheme tends to be a lot more verbose, because it makes a distinction where it doesn’t really have to.
  • lisper 9y ago
    You can easily change that behavior if you really want to. (in-package :my-package) (shadow 'if) (defmacro if (condition then else) `(cl:if (true? ,condition) ,then ,else)) (defgeneric true? (thing) t) Defining appropriate defmethods to make things work the way you want is left as an exercise.
    • kazinator 9y ago
      However, wanting to is rather a problem for the psychiatrist's couch.
      • lisper 9y ago
        Why? I actually agree with the OP that conflating the empty list and the boolean false value is a mistake. (I don't think it's enough of a big deal for me to want to change it, but in a perfect world I do think it is better to distinguish them.)
  • kazinator 9y ago
    Your guess was wrong; there is no such hard time. There is no difficulty in precisely mapping data from the "real world" onto Lisp data structures, in both directions. If it doesn't have nil that is also false and the empty list, it is not a Lisp. The conflation is a stroke of genius. I was immediately attracted to Lisp because of its clever handling of lists and booleans. Also how nil is a symbol, but () means the same thing as an alternative spelling. People who wake these things out are imbeciles who are mutilating their language to the point it shouldn't be called Lisp. How nil works in Lisp has a tremendous virtue: it blows away a lot of useless verbiage from code that manipulates code. Ancient Lisp in the 1960's didn't allow car and cdr on the empty list nil. The Interlisp people realized that it was an inconvenience to always have to test consp before using car or cdr so they turned the functions polymorphic, allowing (car nil) -> nil, and (cdr nil) -> nil. According to the HOPL History of Lisp paper, the MacLisp and Interlisp people held a conference. They didn't agree on some things, but MacLisp adopted (car nil) -> nil and (cdr nil) -> nil from Interlisp. It's a compelling idea; taking it out of a supposed Lisp dialect is a counterproductive regression.
    • osteele 9y ago
      > If it doesn't have nil that is also false and the empty list, it is not a Lisp. Scheme is generally considered a Lisp.
      • kazinator 9y ago
        {by whom} Not by me. I'm a skilled Lisp programmer, yet Scheme isn't usable to me a the rudimentary coding level using the core language. There are stumbling blocks at every turn against straightforward Lisp coding. How can it be a Lisp? I can't even rely on Scheme to evaluate the function arguments left to right. Many forms have an "undefined" return value; in Lisp, everything returns a defined value, as a fundamental tenet! Remember Alan Perlis: "Lisp programmers know the value of everything, but the cost of nothing." Well, Scheme programmers do not in fact know the value of everything; it is often undefined! Might Scheme not be a dialect of C, in fact? The expression f(i++, i++) is directly translatable from C to Scheme, undefinedness of behavior intact! "Lisp" has to do with the little design details, not superficial resemblance. Calling every language with parentheses a Lisp is like calling every web browser "Netscape". Chrome is Google Netscape, Firefox is Mozilla Netscape; Explorer is Microsoft Netscape. How can they all not be "Netscape"? They run Javascript, process HTML and CSS, fetch URLs and render content. Also, MS-DOS and Windows are Unix! Proof: their filesystem design has a directory structure in which "." means this directory and ".." means parent. There is a "cd" command in the command interpreter, and slash is accepted as a path separator such that the leading slash indicates an absolute path. Piping between processes is done with |. Gee, how can DOS and Windows not be Unix? Superficial resemblances mean that we can dilute any name we want, as thinly as we want, to the point that it means nothing.
• lenkite 9y ago
  I liked clojure when I dived into it but lack of static typing is a pain especially once you have got used to the wonderful refactoring and code-intelligence abilities you get by adopting the tools of static typed programming languages like Java/Go/C#/F#. Also performance!
  • xyrouter 9y ago
    The lack of static typing does not explain why there are so many companies using Python, Ruby and Perl but very few using Lisp. If the lack of static typing was the real cause of the lack of popularity of Lisp then Python, Ruby and Perl also would have been unpopular.
    • lenkite 9y ago
      Because each of these dynamic languages offered one feature which was/is the best in the world at the time. Python today has the best numeric computing libraries (numpy and sisters) which make it the most widely adopted language for scientific computing, ML, etc. Ruby had Rails - the web framework that trail-blazed convention over configuration and rapid productivity and was considered leading just a few years ago. Ruby's popularity has waned since then as performance and scalability has become far more critical than plain productivity alone. Perl had the best regex features and reporting facilities fifteen+ years ago. It has lost its crown and is rapidly declining since Perl 6 took forever and is basically a completely different language.
      • cafard 9y ago
        Perl also has CPAN. It had mind-share, as Python seems to have now.
      • Volt 9y ago
        Python enjoyed a whole lot of popularity before the ML trend took off. If that's the best thing going for it, I don't think it really answers the question.
  • lispm 9y ago
• chimprich 9y ago
  > 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 popular with a cooler name. Another problem is a perception of Lisp as being an old language. When I tell work colleagues about how great Lisp is, they're put off by it having been around a long time. I tell them that's ridiculous, the /computer/ has been around a long time, should we abandon that? But it is an uphill struggle.
  • xyrouter 9y ago
    > 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.
    • FractalLP 9y ago
      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.
    • dTal 9y ago
      Cool names might be neccessary, but not sufficient, for popularity?
• agumonkey 9y ago
  To me it's because lisp offer is too conceptual in a way. Lisp AST like faux-syntax, freedom of idioms, macros... to most it's a problem more than a feature. I believe a huge amount of people prefer the comfort and "magic" of strong grammatical separation. They like considering a language like a set of tools to learn rather than a set of concepts to craft whatever is possible. It also leverage social structures more. You're the coder, not the language designer, not the compiler writer etc etc People like that sort of distribution of work, even though it means you're dependant on these groups which can slow you down. For complex problems, without clear solution, Lisp is still used (from what I've read) because the people on these tasks are actually looking to find the right concepts and needs a metamaterial rather than a fixed set of bricks.
  • deleted 9y ago
    [deleted]
• jcelerier 9y ago
  > It's the same kind of sense of wonder one feels when one learns how the simple concepts of Euclid's postulates can be used to prove complex concepts in Geometry or how the Newton's laws of motion can be used to derive intricate and complex concepts in classical physics. Well, I think you've got your answer right there. Out of 100 people learning about newton's law of motions at university, how many are witnessing their intrinsinc beauty ? Maybe one or two ? And I feel like I'm being fairly generous; most just find it boring and just want to pass the test. They never feel that sense of wonder. I certainly never felt it for Newtonian physics either, but I'll admit that the relationship between linear algebra and matrices made my heart pinch a bit at the time. Likewise, most people (doing a programming job) are utterly bored by "how simple concepts can be composed elegantly" ; they just want to make the damn thing work, close their tickets and go back home. They don't read HN or LambdaTheUltimate any more than your average construction worker does read construction working forums, or your average accountant does read accounting forums.
• pjmlp 9y ago
  > I sometimes wonder why Lisp has not been more popular in the technology industry. One major reason was hardware. Lisp might have started in IBM mainframes, but the development environment from Xerox and the Lisp Machines that followed up where quite expensive for single developers, back when the industry was heavily focused on bringing down the costs of time-sharing services, which where owned mostly by mainframes, VAX and UNIX systems. So when the workstation market started, Lisp machines had to fight against UNIX workstations, while being quite expensive, they were still cheaper than Lisp ones. So the price, coupled with misunderstanding from Lisp from more regular developers busy with Algol, Fortran, PL/I and such, and lots of management mistakes doomed it. Also quite important, 8 and 16 bit home computers were not yet able to deal with the hardware requirements of Lisp enviroments. Note that this also affected C++. Lucid pivoted from Lisp Machines to C++, offering a Lisp like development environment that only now we are getting back thanks to LLVM and efforts from the major IDE vendors. Nowadays we have pocket computers more powerful than SGIs.
  • rjsw 9y ago
    Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't have anything to do with Lisp Machines.
    • pjmlp 9y ago
      Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.
      • lispm 9y ago
        Actually Lisp systems were no more expensive than other advanced language implementations. But one needed a bunch of expensive RAM. At that time there were already free implementations of Common Lisp for Unix: AKCL (later GCL), CMUCL, CLISP, XLISP, ... IDE for those were usualy GNU Emacs or Xemacs with ILISP. Windows had less choice for free implementations, but one used the commercial implementations anyway and some were not that expensive. On the Mac everyone used Macintosh Common Lisp - which at some point was owned and sold by Apple itself - not very expensive.
• FractalLP 9y ago
  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?
  • mtreis86 9y ago
    6 - what about https://common-lisp.net/project/bordeaux-threads/ https://common-lisp.net/project/bordeaux-threads/
    • klibertp 9y ago
      lparallel[0] is a higher-level abstraction built on threads. I use it for spawning threads which execute OS commands and wait for the results, without blocking the main thread. Works very well. And anyway, if you want concurrency and/or paralellism, just go for OTP (Erlang, Elixir, LFE). [1] https://lparallel.org/overview/ https://lparallel.org/overview/
    • flavio81 9y ago
      ... or STMX, which provides software transactional memory on Common Lisp in an ultra-easy-to-use way.
• AnimalMuppet 9y ago
  > I sometimes wonder why Lisp has not been more popular in the technology industry. Larry Wall said that a language should make the easy things easy, and the hard things possible. I think the problem is that Lisp doesn't make the easy things easy. Before you tar and feather me, hear me out. There are two different ways in which Lisp doesn't make the easy things easy. First, syntax. "But it's easy! In fact, it's the easiest!" you reply. But for the vast majority of programmers, Lisp syntax is not easy. You could argue that they just need to be trained. But the syntax is different enough that they are reluctant to try. Second, installation and package management. This is part of what is now expected to be easy. If Lisp doesn't have an install and package management that is as easy as, say, Perl, that's a problem that will turn people off to Lisp.
  • deleted 9y ago
    [deleted]
  • madmax96 9y ago
    >for the vast majority of programmers, Lisp syntax is not easy I suggest that learning Lisp's syntax is easier than learning C-like syntax. There is learning involved, however, and that undoubtedly keeps people from lisp. But s-expressions are the secret sauce; there is no modern lisp without them. >installation and package management This is basically a solved problem at this point. Clojure has both Lein and Boot to handle dependencies and building. CL has quicklisp (as easy as `(ql:quickload :my-system)` for installation) and asdf for "building" and system definition. When it comes down to solving problems, I feel that interactive development (with SLIME), Quicklisp, and ASDF make me extremely productive, and the easy things are easy.
    • dwheeler 9y ago
      Lisp's syntax is indeed easier to learn, but the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format. And you typically have to read more code than you write. I created 3 layered notations to keep Lisp's capabilities (including macros and homoiconicity) while making it easier for normal programmers to read. Instead of "getting rid" of S-expressions, I think adding just a few standard abbreviations to the Lisp reader makes Lisp more acceptable to more developers. See: https://sourceforge.net/projects/readable/ https://sourceforge.net/projects/readable/
• flavio81 9y ago
  >I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines (MIT CONS, etc) were able to run Lisp fast but those were dedicated, specialized hardware. And expensive. Enter the late 80s; Lisp ran great on personal computers but implementations AFAIK were mostly commercial, so reserved to big budgets. I'd say Common Lisp did have success on the industry, used for many things (3D, CAD/CAM, simulation, etc). Meanwhile the rest of the world was on Pascal, C, and C++. Nowadays things are different, there are many Common Lisp implementations that are free and are good (SBCL and CCL, for example, are lightning fast). But additionally, it is difficult to understand what advantages would Lisp bring. For this, the developer would have to grok (completely understand) the enormous value of metaprogramming, and to understand as well how flexible is CLOS.
  • lispm 9y ago
    > but it worked slower than using other languages minus Maclisp > Enter the late 80s; Lisp ran great on personal computers but implementations AFAIK were mostly commercial, so reserved to big budgets. CLISP, CMUCL, AKCL, XLisp, ... all were no cost. > SBCL and CCL SBCL is a fork of CMUCL which was started in 1981 as Spice Lisp. That was always no cost and several other projects took code and documentation from CMUCL. CCL is a free version of MCL - which was an affordable commercial Lisp for Macs in the end 80s.
    • flavio81 9y ago
      Thanks for the corrections, R.
• jimbokun 9y ago
  "I sometimes wonder why Lisp has not been more popular in the technology industry." One historical reason: https://en.wikipedia.org/wiki/AI_winter#The_collapse_of_the_Lisp_machine_market_in_1987 https://en.wikipedia.org/wiki/AI_winter#The_collapse_of_the_...