9 ms·

From the article: “My heart was broken because Common Lisp is such a fine fine language and it is a joy to work in and hardly anyone uses it in industry. The in

• didibus 5y ago
  Isn't that a chicken and egg problem though? The question is how do you bootstrap?
  • chongli 5y ago
    The best way to bootstrap language adoption is to get a big tech company to push it. Java (Sun, Oracle, Google Android), C# (Microsoft), JavaScript (all browser vendors, Facebook React), Rust (Mozilla/Microsoft), Swift (Apple), Go (Google). Most of the popular languages are backed by one or more large tech companies. This gives managers the confidence to adopt them without reservation. It's the old "nobody ever got fired for choosing IBM" line, broadened.
    • vindarel 5y ago
      At least now we have a list of companies not to be ashamed of: https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ There are big names and big players. Now to see one pushing CL is another topic.
    • dnautics 5y ago
      Then there's python. Ruby (currently waning in popularity, but we are talking about bootstrapping popularity), php (well fb is a major company but php was popular long before that), perl, not to mention C and C++. These languages have all at one point been "top" languages (moreso than swift, anyways).
      • TchoBeer 5y ago
        The C comparison is particularly apt considering that C is newer than lisp.
        • pjmlp 5y ago
          Came with a free beer operating system.
      • chongli 5y ago
        Well, big tech backing is a sufficient condition for popularity, but not a necessary one. If you're looking for necessary conditions then that's a far more difficult question. Why do other things (books, songs, movies, games) become popular? Some things just go viral for whatever reason and it's very difficult to explain why, even after the fact. Like trying to predict where lightning will strike next.
        • dnautics 5y ago
          Big tech backing is no where near sufficient. Dart almost died (and the jury is still out). Facebook created a statically typed erlang, and I think that one is already dead, not a year after it was supposed to be announced
  • lolinder 5y ago
    It's a harder problem when the language is unopinionated. It's easy to bootstrap productivity when everyone is already on the same page about how you write code in this language. Whether it's "OO" or "pythonic", having clear opinions that are baked into the language and shared across the industry means anyone can become productive quickly in a new code base. The problem that lisp has is that its very expressivity means that most lisp programs are written in their own custom DSL. This is exactly what people love about it but makes knowledge transfer between organizations hard.
    • reikonomusha 5y ago
      Most Lisp programs are not written in their own DSL. Programming teams can be opinionated. Just someone with authority needs to write down the opinions. Common Lisp in particular can be pretty opinionated if everybody shares the same configuration of SLIME and Emacs. There are a few policy rules atop that really make code style consistent and watertight. But, unlike Go, it’s not “for free” with a canonical tool.
      • pfdietz 5y ago
        > Most Lisp programs are not written in their own DSL. Well, except for hu.dwim packages. Pesky Hungarian Common Lisp. :)
• golergka 5y ago
  On the other hand, developers who choose to learn Haskell are usually above average, so if you're really looking to hire above average developers, you're making your job easier.
  • neolog 5y ago
    How many excellent developers know Haskell? Python?
    • zelphirkalt 5y ago
      I think many excellent devs know Haskell, have used it at some point or at least played with it, or can get up to speed in it within a few, maybe 2 or 3, weeks.
      • neolog 5y ago
        I think there are a lot more of excellent Python devs than excellent Haskell devs.
        • zelphirkalt 5y ago
          While that may be true and does not actually oppose what I wrote, I think we are talking about 2 different kinds of excellency. One kind of excellency is to be able to quickly solve problems in one given language. For example an excellent Python developer. There are many of those. The other kind of excellency, in my opinion, goes much further than that. A very solid background in CS, a deep understanding of programming concepts of not only one but many programming languages, some knowledge in programming language theory, knowledge about various programming paradigms, their concepts and how to apply them in problem solving and daily programming tasks. The second kind of excellency I am quite sure to find within a developer, who got a background with Haskell and some proper work done in that on their CV. I would be less sure, to find that in just any good Python developer. Why do I think so? I think so, because Python is becoming more and more popular and is an "easy language to learn" and kind of follows the mainstream OOP approach. So people learning it get some exposure to the other things I count under the second type of excellency, not too bad, but not really that much, unless they are special cases and actively make an effort to get that exposure. In Haskell you are thrown into another not so mainstream programming paradigm, you are learning a not so mainstream language, and you touch on many programming concepts, which you might not necessarily get in touch with using Python. (Don't get me wrong, I write a lot of Python code myself, but exposure to and frequent usage of some other languges, including mostly functional programming ones and strongly statically typed ones, make me miss a lot of things in Python and make me see the language's shortcomings.) That second kind of excellency is learned by studying hard or years of experience, and requires you to dip your toes into unfamiliar waters. This kind of excellency enables you to quickly learn about the power of alternative systems or languges and grasp what they can do for you. In the end it is all about getting to know and understanding lots of concepts. The more exposure you have to different (!) things, the more knowledgable you will be. So even better chances to find an excellent developer of the second kind, if that person happens to have experience in Haskell and Python or whatever other languages you come up with, which are significantly differnt from whatever others one already knows.
• elias94 5y ago
  That's why Clojure has been invented. It runs in the JVM, highly maintainable code, front-end development with Clojurescript etc.
• reikonomusha 5y ago
  Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. Training seems like some lost art as we collectively move toward a more disposable programming ethos. Training a good programmer how to write Lisp is, what, two weeks of work? Learn how to make variables, write functions, define classes, and compile a project. That gets you 80% of the way there, and definitely gets you across the “productivity threshold”. Somehow, in the same breath, we find it okay to spend weeks agreeing on how to ship Python code, what the standard development environment is, and how a 2->3 transition of 100,000 lines of code will be accomplished.
  • dwohnitmok 5y ago
    > Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand. I mean Haskell advocates will say the same about Haskell (monads are really not that bad: I'd be surprised if someone on a team of experienced Haskell programmers would take more than a week to come up to speed on them. It's more the rich interplay of monads and other concepts that either rewards deeper study or is a dangerous rabbit hole depending on your perspective). In both cases it's a matter of how deep the rabbit hole goes in the concepts that the languages do offer and how much a given code base uses those concepts to their fullest potential. It's a double-edged sword. The same concepts that yield so many layers of power, expressiveness, and universality can yield frighteningly arcane codebases in the hands of advanced novices, those with "just enough knowledge to do harm." There's a reason the meme of Lisp programmers going through a phase where they want to "macro all the things" before calming down and using them more judiciously is a meme. Likewise a boring language like Go that purposefully puts abstraction ceilings has a double-edged sword whose edges cut the other way. An excellent team with good taste will be at home in whatever language they end up choosing, almost by definition. The opposite direction is a road much more fraught with danger.
    • reikonomusha 5y ago
      Haskell programmers may say the same thing about Haskell, but it’s not the same thing as far as Lisp is concerned. Yes, it’s possible to concoct the weirdest stuff in Lisp, but that would probably be bad code. Some macros might take time to learn, but unlike Haskell where you need to know monads to be productive, you do not need to know how to author macros to read and write most Lisp. Languages that have these “abstraction ceilings”, as you put it, have their own danger as well—just a different danger. Namely, you’re choosing boringness of the language as a feature, in many cases requiring some multiple of additional programmers, which means some multiple of additional time spent hiring and money spent paying salaries. For some companies, money isn’t a problem, so choosing boring tech with a gazillion programmers and double-digit churn rate is just fine. Programming in Go doesn’t automatically resolve all the issues of running and maintaining a technical project. It makes one particular problem trivially solved (inconsistent code format, expressiveness going off the rails, etc.). But choices and policy around how code is contributed to, how software is documented, how architecture is developed and reviewed, how dependencies are managed and added, how code is reviewed, etc. still falls on humans to conceive and implement as agreed-upon policies. In Lisp, how code is formatted and what language features might be off-limits can also be solved by way of such policy-making. Its not theoretical either; even Google publishes a style guide on Lisp development that they follow internally, and it works fine. It’s really not as “dangerous” as everyone seems to make it out to be.
• e3bc54b2 5y ago
  What manafers tend to forget is the selwction bias. While it is definitely harder to find a Lisp/Haskell programmer than say, a Java programmer, the former has a much higher chance of being competent and quick-learner, because thats the kind of people that tend to learn non-mainstream languages. They will likely be onboarded faster, and likely to be far more productive than their peers. I'm forgettimg whose quote it was, but it goes (in 2000s) something along "I'd rather hire a Python programmer, even if the application is written in Java, because a Python prpgrammer has selected him/herself by putting in efforts to learn Python."
• chrisjharris 5y ago
  I partly agree but this can too easily become an argument in favour of the lowest common denominator. I can hardly imagine a language that's easier to learn than Python, and for that reason a) lots of people already know it, and b) those that don't can learn fast. But that's at least partly because it just doesn't have features that are widely regarded as beneficial - a type system, metaprogramming, good functional constructs etc. Before anyone comes back at me for suggesting that Python lacks essential features, I know there are third-party libraries or core features to do this stuff, but they're pretty far off-meta, so your team isn't going to know them, or having good idioms/consensus for using them, and so at that point you might as well just learn something a little more advanced anyway (Julia would be an excellent choice).
• finder83 5y ago
  One other large issue is that less popular languages (CL, Scheme, Smalltalk, etc) sometimes just don't have the library you need or the libraries are immature and not fully developed. Database adapters for something like SQL Server is a great example. Most languages have a Postgres library, but sometimes the business requires a SQL Server connection...it's rarely been by choice that I've wanted to use it, but by necessity. Another is Salesforce...I don't know anyone who would voluntarily want to work with Salesforce, but more and more it's often a requirement to have a working soap library, Salesforce client, etc. Sure, you could write your own...but I can't think of something less interesting to do in development, when you could just switch languages and integrate directly without having to write a lot of glue code. I do feel like I get more done in Common Lisp when the language 100% hits my use case, but it seems invariable that my use case involves external services I didn't plan on that have to be re-implemented or a work around/microservice written for them in a different language.
• agumonkey 5y ago
  Part of the dynamics was also the late 90s OO shift. It was a catastrophy where utter verbosity was confused with engineering. It's basically 1/lisp ..