Hacker News Reader

Comment by linguae | Hacker News Reader

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 industry has a lot of code in Java even when it takes much less time to write code in Lisp. What happened to the programmer’s time is more important than the machine’s?”

I think one issue that Common Lisp and many other programming languages face is that while a programmer’s time is more valuable than a machine’s, there are dynamics at play when maintaining commercial software projects that favor coding in more popular languages, such as the ability to easily hire developers knowledgeable in the language and/or paradigm. For example, imagine being a manager of a project written in Haskell that liberally uses functional programming concepts such as monads. It’s easier to hire developers knowledgeable in standard procedural or object-oriented programming languages than it is to find developers knowledgeable in functional programming, and getting a non-FP programmer up to speed on functional programming requires training, which takes time and money.

I love languages like Common Lisp, Scheme, and Smalltalk. However, if I’m working on a team project and my teammates don’t know these languages, then I choose a more common language like Python. Programming is more than just expressing computation; it’s also about communication, and one major purpose of language is to communicate with others.

View on HN

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.

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

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.

> but unlike Haskell where you need to know monads to be productive

I disagree. You don't need to author monads to be productive in Haskell (and in a production codebase rarely would, the monads you use change rarely). Having written a good of deal of Lisp going out to production in the form of Clojure and a good deal of Haskell I really think monads and macros are a rather fitting analogy here. It's really the same deal. You need to know how use monads in Haskell just as you need to know how to use macros in a Lisp. Are you going to be writing a lot of your own new ones in a pre-existing production codebase? Unlikely. Are you going to be creating a couple of them here and there in a lot of the new libraries you write? Probably. Are they both things that sound really scary to outsiders but are really quite tame if you have a team surrounding you helping you out? Yeah.

> It’s really not as “dangerous” as everyone seems to make it out to be.

Again I don't think it's dangerous. I just think it's a weird direction to take. There are no good languages in isolation. There are only languages that are the best fits for a given team.

EDIT:

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

Indeed, I'm not particular champion of Go or Java (the traditional boring languages people bring up). Their very boring-ness has its own drawbacks as you say, ones that I feel acutely whenever I've worked on teams using them. But these are a series of true trade-offs, one where different situations will call with different needs. I have met plenty of people who are extremely competent Common Lisp, Haskell, Clojure, etc. programmers who have proactively chosen to go with a "boring" language for a new team (for a variety of reasons, not necessarily because the "interesting" language has sharp edges).

The team (and by extension the company) precedes and determines the language, not the other way around.

I do agree most Haskell programmers don’t need to be authoring monads to be productive. My take was more along the lines that monads expose an interface/API to the programmer that is used pervasively in “ordinary programming”. This interface/API is defined rather abstractly and doesn’t come equipped with “obvious”, self-evident definitions. You can get pretty far in Haskell though just sort of parroting these operators for specific class instances of interest, like IO and Maybe.

This is, I claim, unlike macros where you really don’t need to know about the machinery of macros (or even of their existence) to understand and use AND, OR, DOLIST, LOOP, etc. The notion of a macro doesn’t “leak” in “ordinary programming” whereas ‘>>=‘ or ‘return’ do, even if in just type errors.

(Sorry for the copious scare-quotes.)

> This is, I claim, unlike macros where you really don’t need to know about the machinery of macros (or even of their existence) to understand and use AND, OR, DOLIST, LOOP, etc.

Nah you do need to know about them, otherwise you won't understand a bunch of weird errors in your program (e.g. hmmmm... why does (reduce or my-collection) blow up?).

I agree you don't need to know much about them. Really a novice Lisp programmer just needs to know, "don't use macros in anything that isn't a first-order construct, otherwise just treat it like a normal function," and that'll get them pretty far. But that's, as you say, really just the same difficulty as "sort of parroting these operators for specific class instances of interest, like IO and Maybe."

And to understand one more level further down is really easy in both cases if you have any amount of hand-holding by an experienced mentor.

if you have an error with macros you can just expand them. Very few macros expand to more than 5-10 lines (loop being an exception).

Yes if you have problems with macros there are ways of debugging them. My point (in reply to reikonomusha) was simply that you do need to know about "the machinery of macros" and certainly their existence to do day-to-day programming in a Lisp.

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

You need to know what the macros a given codebase uses do if you want to work in that codebase. This is actually a worse situation than in Haskell, where if you're comfortable with monads in general you can probably be productive in a given codebase without knowing about the specifics of the monads that codebase is using.

It’s not “actually” a worse situation except in some pathological academic sense. The point of a macro is to make some idea clearer to understand by way of syntax. If it’s not doing that, it’s probably a bad macro.

If you restrict yourself to a reasonable-to-understand subset of possible macros - such as those that could be expressed as monads in Haskell - then a reader that knows that you've so restricted yourself can work in your codebase without understanding all your macros (as long as you don't have any bugs in your macro implementations). But in that case why use a language with macros?

You can teach someone to use the built-in loop macro without using the term "macro."

It's far more hairy and complicated then any non built-in macro you will encounter in the wild. Literally the only time I worry about macro vs special operator vs function is when doing higher order programming, which is less common in lisp than Haskell

You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features? If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?

> You can teach someone to use a fixed set of macros. But again, in that case why use a language with macro features?

Because sometimes writing a simple macro makes it easier to write (and read) other code.

> If you're never going to use a non-built-in macro with the complexity of the built-in macros, why does the language need this complex macro system rather than a set of built-in keywords and a simpler extension system?

There's a lot to unpack here. A good lisp developer will very rarely need to write a macro that approaches the complexity of the loop macro. Firstly, that's not never. Being able to write a hairy macro is more like an air-bag than power windows. You're glad to have it when you need it, but you mostly forget its there the rest of the time. Secondly the same macro system that lets you write something like loop also lets you write simpler macros that make code both easier to read and harder to write incorrectly.

Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system.

There are also plenty of people who think loop is too complicated and too inflexible and so avoid it.

Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators?

I don't actually see the extensibility of lisp as its "killer feature" but I definitely see it as a net positive, while a lot of people seem to see it as a net negative. I blame books like "Let Over Lambda" which are more to be seen as examples of what you can do rather than what you should do.

There's lots of things to hate about C, but the fact that you can do:

    enum { TRUE = 0, FALSE=1 };

is not one of them. There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them.

> Finally everything you said about macros and loop can be applied to other languages and the standard library. If nobody's going to write anything as complex as printf(), why does C need variadic functions? If nobody's going to write anything as complex as itertools, why does python need higher-order functions and generators?

IMO the essence of good language design is balancing expressiveness with enough constraint to make code understandable. I agree that printf is a mistake (string interpolation is enough of a special case that it's better as a language-level builtin). As for itertools I'd say that I do write code that's just as complex as the itertools builtins, but also that the itertools builtins don't hurt code readability so much because they're all (more or less) legitimate functions that can be reasoned about compositionally. Code that contains a call to a complex itertools builtin is not particularly hard to understand, because even the most complex itertools builtin returns a plain(ish) value that obeys simple rules. Not so for code that contains a call to a complex macro.

> Lisp does not have a "complex" macro system. It has one of the simplest extension systems of any language I've used that has an extension system.

"complex macro" system rather than complex "macro system", but yeah, I expressed myself badly. The problem isn't complexity per se (and as you say, the actual system is very simple) but that it's an unconstrained one where a macro can do almost anything.

> There's plenty to hate about lisp, but the fact that it's possible to write bad macros is not one of them.

I disagree. In my experience the main reason people give for moving away from lisp on any given project is "maintainability", and if you dig a little deeper that usually boils down to "we wrote too many bad macros". And a lot of the "limited tooling" complaints boil down to the effectiveness of IDEs etc. being limited by the presence of macros.

> a macro can do almost anything

A program can do almost anything; that's the result of internal Turing completeness, plus unfettered external platform access. Macros do not cause this. A program can do anything using nothing but functions.

Macros are supposed to be used when they organize some particular anything in a way that makes it easier to understand and maintain (or even more performant) compared to the best available macro-free approach.

Everything can be abused: control structures, data structures, functions, variables, ...

I think most programmers would agree that running a code-generation program at build time is something that should be approached with a little more caution (not saying that you blanket shouldn't do it, but you should check the reputation of the code generator, what the output looks like, how well your debugger/profiler can handle it...) than using a plain-code library. But a lot of people seem to somehow fail to realise that using a macro is the same thing.

Everything can be abused, which is why it's best to write everything in the most restrictive environment that still allows expressing what you need to. See Dhall or Noether for what that looks like for everyday code. At the language design level, there may be cases where users need to apply an arbitrary Turing-complete AST->AST function, but it shouldn't be the first thing they reach for; if there are features (such as do notation) or patterns (such as Python decorators) that allow expressing most macro use cases via a more constrained (and therefore less maintainability-impacting) feature, that's a big win.

> The point of a macro is to make some idea clearer to understand by way of syntax.

The question I think is clearer for who? Macros, as all abstractions, seem to be a way to make the expert faster at the expense of the beginner. Lisp is probably better at avoiding accidental complexity coming with it, but I don't think it avoids complexity entirely.

The way to settle this, at least for a given macro or macros, is to bring the expert and beginner together, and have both of them examine the macro calls, their documentation, and a version of the code in which the macro calls have been replaced by their hand-written expansions.

>Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand.

I dunno, using a DSL for linked lists as the only syntax construct is pretty radical. CAR/CDR and CONS pair dot notation must feel pretty esoteric. The concept of macros that transform the syntax tree is unusual, and knowing when to use them requires a restraint that comes only with experience. I could see it taking months if not years to fully grasp the zen of Lisp.

Same could be said about the zen of, eg, Python though. Deep experience pays off for library/framework authors, but most practitioners don’t have daily need for __new__ or slots or...

Come on.

    (if (= x 2)
        (print "x is two!")
        (print "x is not two!"))

    (defclass person ()
      name
      address)

will not take a professional programmer who is prepared to receive a 6-figure salary “months” to learn. We might as well call

    [2*x for x in range(10) if x % 2 == 0]

a “DSL for constructing lists” in Python which, incidentally, also doesn’t take most paid programmers months to learn. This doesn’t even get into the zoo of syntax that languages like Python have to offer, like decorators, generator expressions, walrus operators, loop keywords (“else” in a for-loop?), etc.

In my experience training both interns and new hires, getting from zero-to-first-commit is like a week. Getting on code reviews, 2-3 weeks. Feeling confident and comfortable, 4-5.

Also, nobody is being paid to feel language zen. Yes, mastering Lisp or becoming anything close to an expert might take years. But being a language academic usually isn’t the goal of the working programmer.

It seems like there would be a large space (that's sidestepped here) between learning basic syntactic differences and 'mastering' Lisp. Are there not novel concepts (outside of syntax) which programmers struggle with in that space? And does gp's comment about needing to learn 'restraint' from experience not apply to that middle space too?

IME if you were diligent about only hiring very smart + intrinsically interested programmers, the kind of outcome you're describing might be realistic. But I don't see this going well if you draw from the large pool otherwise available of more paycheck-motivated programmers who may or may not have a strong grasp of conceptual underpinnings of programming languages.

In anything, Lisp included, there are difficult concepts to comprehend. You can throw a dart and it’ll probably land on an interesting and difficult subject.

throws dart

How does finalization of objects in a generationally garbage collected implementation of Lisp work?

throws dart

How does a local dynamic variable interact with a new thread being spawned?

throws dart

What is a “three-comma macro” and how do I write one?

You get the picture.

Lisp has plenty of concepts that you can spend ages mulling over. But I contend that Common Lisp is in a sweet spot where it’s not particularly dogmatic about those concepts and as such don't consistently present themselves as hurdles to learning the language and being productive.

Honestly the biggest hurdle of Common Lisp is that Emacs is the #1 doctor-recommended solution for editing Lisp—in the open source world at least.

Paycheck programmers are “easier” to teach in fact because they don’t care about the “zen” of Lisp or any of that. Tell them the rules, tell them what code to mimic, and tell them what issue tickets need servicing. If they’re otherwise fine programmers, they’ll make some mistakes, but those mistakes get ironed out during code reviews, and they happen less and less frequently.

But of course, the “intrinsically motivated” programmers are likely to produce better solutions to problems more consistently, and I try to hire for that regardless of the language.

That makes a lot of sense.

> What is a “three-comma macro” and how do I write one?

Had to look that up:

https://www.cliki.net/Three%20Comma%20Programmer

Are there genuine cases where you need a sigle "three-comma" macro, rather than layering a handful of simpler macros?

I always break up that sort of thing using auxiliary functions. It's much more understandable.

If that's the difference, why would anyone care about using lisp? The examples you've chosen are nothing more than "parens before the statement instead of squiggles after", more or less. Why would anyone advocate for lisp if that was the difference.

I'm not a lisper, so that's an honest question. I can't believe people are so evangelical about the language over such a trite difference from C/Python/Java.

A language is much, much more than syntax. I showed some trivial syntax, but I didn’t talk about how fast it might be to execute that code, nor easy or hard it might be to debug it, how straightforward it is to pull in a dependency, etc. You’re right, there’s little that can be inferred from such a simple code example, except one thing: the syntax really isn’t that hard to grok.

With that said, to throw a bone, for me, Lisp is valuable because it’s an incrementally and interactively developed language that makes available syntactic extension to the programmer. This makes it possible to be extraordinarily productive as a programmer on even the most difficult technical challenges.

Incremental and interactive: there is no edit-compile-run cycle. Feedback is instantaneous. Debugging is extremely fast. Concentration rarely falters.

Syntactic extension: One can author new syntax that fits problem domains. If I’m writing a lot of RESTy APIs, I might make a nice syntax for them that makes the route and consequent action front-and-center with no boilerplate.

There’s so much more than just these though. Common Lisp implementations are incredible stable and mature, there’s a huge library ecosystem, it’s possible to write code as fast as C, and the language has stood the test of several decades of time.

That's the issue parent was raising I believe. You cannot answer a question about complex aspect of a thing by showing the simple parts.

Workflow wise, that's my answer: https://lisp-journey.gitlab.io/pythonvslisp/

I read this earlier ... that tip about hitting "v" in the debugger was so useful!

That Python snippet reminds me of my least favorite part of CL: the LOOP macro. Although calling it part of CL is a bit of a misnomer since the standard specifies it as, paraphrasing, do loops n stuff.

There's like 20 pages of details on the loop macro; certainly more than "do loops and stuff"

Too late to edit. Loop takes up an entire chapter of the ANSI specification and that chapter is 30 pages long.

PDF made from latex files of Final Draft; LOOP is Chapter 6:

https://lisp.com.br/archive/ansi_cl_standard_draft_nice.pdf

It's more like 3 pages, with examples, when presented formally[1]. My point though is the standard specified behavior is quite limited, but it gives implementers broad latitude to "do loops and stuff" in a non-portable way[2] while still being in some sense standard. For example, Lispworks extends LOOP over SQL queries[3]. So sure I was being a bit tongue-in-cheek, but LOOP really is a set of not particularly compatible imperative languages that happen to be embedded in the various CL implementations. This is an artifact of the CL standardization process, which was virtually taking the set union of the features of the most popular implementations of the time, except in notable cases like LOOP where it was so hairy and incompatible that the standards body had to pick a relatively minimal intersection instead.

[1] http://www.lispworks.com/documentation/HyperSpec/Body/m_loop...

[2] http://www.lispworks.com/documentation/HyperSpec/Body/06_ai....

[3] http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-...

I don't think your second link says what you claim it does. Aside from being explicit that using let is totally fine (good) and that types are allowed, but not required to be specified (just like everywhere else that bindings are established), it just says that implementations can optimize things (duh?) and that there is no standardized way to extend it.

The last point is probably everyone's biggest beef with LOOP since it's in stark contrast to most other things in the standard which often have very good ways to extend things.

I find loop to be a fairly nice DSL for iteration. It could be better, it could be worse, and I like it better than all the DO constructs.

> I don't think your second link says what you claim it does.

Based on the historical context of the standardization effort, I read "There is no standardized mechanism for users to add extensions to loop." as the standards body punting and basically giving implementers free reign to include whatever extensions they like. That's certainly what they did anyhow. However on a more careful reading I agree I probably misread that particular line. That's not to say that the practical effect isn't what I observed though. It's hard to find a solid reference, but look at this mess[1]. "Each of the above three LOOP variations can coexist in the same LISP environment." gives a hint of the messiness that follows.

[1] https://github.com/sbcl/sbcl/blob/master/src/code/loop.lisp

Having different iteration constructs or having multiple versions of the same was not untypical on a Lisp Machine, which booted into a single Lisp runtime, but which contained several different Lisp dialects and their language constructs. That way one did not need to reboot the computer to use a different LOOP variant - because the Lisp image was shared in the OS.

The LOOP code you mentioned came from MIT and Symbolics from the 70s/80s, when multiple Lisp dialects were under use and sometimes, on a Lisp Machine, in the same runtime. The original MIT LOOP implementation had a single source code, which could be loaded into different Lisp dialects and systems.

The CL standardization of LOOP was more than ten years later.

Multiple implementations of loop being able coexist in the same language is an example of clean design that speaks in favor of macros.

If there is an issue in the implementation of for in your C++ compiler, or JavaScript machine, can you cleanly bring in another for implementation and switch the code over to it?

While code that is not affected by the problem sticks with the same one?

Some folks swear by ITERATE.

https://common-lisp.net/~loliveira/tmp/iterate-manual/iterat...

I did have an issue with ITERATE, in that it does a kind of macroexpansion that interacts poorly with macrolets.

I struggled with loop too, but I finally just learnt it by example: https://lispcookbook.github.io/cl-cookbook/iteration.html and it's awesome.

I remember young guys on Coursera proglang MOOC, many were very very very frustrated by the flattened layers of abstraction of lisp.

The most peculiar part of this was the group of elder already versed in lisp / macros and eDSLs who couldn't find a way to explain to them. A ancestor to the Monad curse.

Personally I abhor complexity and to me cons / car / cdr everywhere felt like a revelation :)

"Lisp doesn’t really have many, if at all, super weird concepts that need months of thinking about in order to understand."

I don't think we can have both that and the traditional "Lisp is a great language to learn to expand your mind."

"Training seems like some lost art as we collectively move toward a more disposable programming ethos."

Speaking as an engineering lead, my problem is increasingly not that I have an unwillingness to train, but that I need to do something other than train; that is, I need to exploit the training to get some real work done at some point. On my team, to be a fully functional member already requires fluency in 4 general purpose programming languages, 2 devops langauges, all the misc other details needed like SQL knowledge that I could hardly even enumerate off the top of my head if I wanted to, and the associated system knowledge for half-a-dozen systems as to how they are deployed, how to fix them, etc. Bringing up a fresh college grad who happens to have zero of these could be the work of plural years already.

I compare this to what was required in my first engineering job in ~1997: One programming language (VBScript), basic SQL, and "fluency" in HTML that today would be considered "basic" HTML, and with that we had everything we needed at the time. Adding things to the stack was easy to justify back then. It's harder now.

If you want to add another language to the pile, I'm going to need you to have a darned good reason beyond "It's a good language" or "But I like it".

2 weeks is an absurd underestimate for obtaining Lisp fluency, by the way. Surface syntax understanding and the ability to build something someone else already built, sure, but learning the libraries, the existing code base, the other quirks (especially in a language like Lisp that is all but made out of quirks if you start using the language well), there's no way that's two weeks.

It's not that I'm not open to languages, it's that even on my own personal team I can't afford to have everyone drag in whatever language they want to use for some task. It's not a coincidence that so many companies end up with the Approved Language list. Smarter companies with such a list will have a way to get specific exemptions and make it not too hard to get them for good reasons (e.g., if your list is C++ and Javascript one has a good case for adding Python for an ML or NumPy project), but if you let everyone drag in whatever language they like you'll end up with enforced fragmentation of teams and significant difficulties with bringing new developers up to speed in positions where they have to become fluent in perhaps literally 10 general purpose languages to function fully.

> Training seems like some lost art as we collectively move toward a more disposable programming ethos.

I think you're right on that, and that is damaging for Lisp. These days most training seems to be done by external sources, for example Pluralsight, Udemy, medium articles about how to do a specific things, etc. Since those have commercial incentives, they target the biggest audiance, which is usually JavaScript, Java, Python, or something like that. On the other hand, the companies don't want to train people in a specific language, so they hire people that already know their language. That creates a positive feedback cycle that makes less used languages even less used. Same thing about open source contributions (tooling, libraries, etc). I think the insistance on Emacs may also be damaging because it's an even bigger barrier of entry.

That's why Clojure has been invented. It runs in the JVM, highly maintainable code, front-end development with Clojurescript etc.

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

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

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.

Isn't that a chicken and egg problem though? The question is how do you bootstrap?

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.

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

The C comparison is particularly apt considering that C is newer than lisp.

Came with a free beer operating system.

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.

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

The usual response is that Dart wasn't really backed by Google in general but just a few people on and around the Dart team.

Python - Zope, and all the companies Guido worked at

Ruby - Rails made it happen

PHP - Perl without CGI hurdles, and FB really

C and C++ - AT&T, UNIX, Apple, IBM, Microsoft, Borland, CORBA

Not sure about c, c++ Those corporate backings happened WAY after they got popular. Rails is not a corporation.

How do you do UNIX without C or C++?

Rails was made by a corporation.

Radar blips in adoption is not being popular.

There's some internal uptake of Common Lisp inside Google. Legacy of the ITA Software acquisition?

One the significant maintainers of SBCL is at Google.

At least now we have a list of companies not to be ashamed of: https://github.com/azzamsa/awesome-lisp-companies/ There are big names and big players. Now to see one pushing CL is another topic.

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.

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.

> Most Lisp programs are not written in their own DSL.

Well, except for hu.dwim packages. Pesky Hungarian Common Lisp. :)

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.

How many excellent developers know Haskell? Python?

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.

I think there are a lot more of excellent Python devs than excellent Haskell devs.

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.

Suppose there are 20x [1] more Python developers, though that seems really low to me, I would've guessed more like 500x. Suppose skill is distributed exponentially. How much better is the average haskeller than pythonista? 1.1x? 2x? 10x? Given those assumptions, how many developers at each level of quality are there? I got curious so https://i.imgur.com/kEkmAsf.png . I think that means average Haskellers have to be a lot better than average Pythonistas before there start being more 5x-quality developers in Haskell than Python (because there are so many Python developers).

[1] https://insights.stackoverflow.com/survey/2020#technology-pr...

That's the wrong question. If you try to attract as many developers as possible, you're going to attract more good developers, that's true. But you're going to attract much more bad developers.

The right question is — how many of developers who know Haskell are excellent? And how many of developers who know Python are? The first figure would be much higher.

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

Reply on news.ycombinator.com