Any "10x argument" is just lazy thinking. 'Productivity' is governed by so many factors, its just unrealistic that 'choice of programming language' would have such an enormous effect (unless you benchmark CL against let's say COBOL).

On a fun note: The old guard of Common Lisp (like Norvig IIRC) was very fond of Python when it hit mainstream because for them it had a whole lot of the feature set that lisp had which other popular languages lacked.

[disclaimer: I am a die-hard Lisp and Clojure fan but the other fans just make me cringe at times]

Pity that Python did not embrace the Lisp features related to machine code generation.

You mean having bytecode and native code ? maybe they can start that for 3.2+ .. surely it would be more interesting than optional type signatures :)

Yes.

It's interesting, lisps, [o|oca]ml .. have often both, but somehow this practice never went mainstream.. even js got huge influx of money to push vm super fast but no native code practices.

I consider Java and .NET mainstream enough. :)

traumatic selective memory at work

I agree. And I think that the constant BS claims of certain Lisp advocates actually damages the Lisp community. Especially the silly “I am smarter because I use Lisp” claims you often see in Lisp articles. My answer is always: OK great. Why don’t you instead first build some impressive stuff in Lisp and then show us how Lisp made it possible for you to build it 10x faster. Then you might actually make people believe you. Especially given that pretty much all successful software out there is written in (or run on top of) C/C++.

this is just personal taste but i think that GNU Emacs blows any other software ever written out of every universe that ever existed :)

Maybe because it is written in C? Hehehehe :)

its written in emacs lisp and c. most of the code base is in the former :)

Ask Vi lovers if they agree :)

of course they do. they just chose evil-mode

Hahaha you are funny.

when i wrote this reply i didn't expect it to generate such a discussion. it was meant as a sort of smart-arsy opposite side to the same coin of which the other side was parent's claim that lisp is not suitable for large teams. the claim that lisp is not suitable for large teams seems ridiculous to me, especially given the prevalence of javascript and python in industry. surely lisp cannot be worse in large teams than these languages. usually people mention type safety in support of these claims (which again makes no sense given the prevalence of js and python), but this point is even more mute now given coalton's existence which allows you to have haskell-like type safety in common lisp - https://coalton-lang.github.io/

on the other hand i think people can be more productive in lisp provided certain criteria are met: they are motivated to solve the problem at hand; and that they enjoy and are capable to use the tooling that is offered in lisp to its full extent. but this is not surprising because in order to understand lisp to this extent you have to understand far more about computing than just knowing lisp syntax, which is trivial btw

Look I know Lisp quite well, have written more than one dialect of Lisp for fun, and have 25+ years of professional software development experience behind me. I don’t think there is anything you need to somehow understand better about “computing” to use Lisp. But you are welcome to convince me otherwise. Do you have any concrete examples?

> I don’t think there is anything you need to somehow understand better about “computing” to use Lisp

I am not saying that at all. If anything I said the opposite of that. I think, given how simple Lisp's syntax is, being able to write/use Lisp is almost trivial. However being able to use Lisp is a way that has given it an almost mythical status (one being discussed in this thread is the so-called "x10 programmer") requires far more than just being able to write Lisp

Can you give examples? I see a lot of hype but no actuals. Becoming super productive in any language requires a lot more skills than just learning the syntax and semantics of a language. So why do you think Lisp is different? It would help if you could point at real world projects that demonstrate your claims.

i can't tell you because the *lisp-king-lizard* will come and eat me if i divulge secrets

EDIT: see the problem i have with your post is its tone and refusal to read what i actually wrote. if you read it properly i am not saying anything different to what you seem to be saying: if you are a good programmer you can be productive in any language, including lisp. if you are a crappy programmer, knowing how to write lisp is not going to save you. knowing how to write lisp is trivial. even implementing some (minimal) dialect of lisp is not too difficult

on the other hand, i think that repl-driven development that is available to many (all?) common lisp implementations is unmatched in any language, and i think that this is unique to common lisp. please see the post by mikelevins in this thread that details this process. i think this can be a great productivity booster for production as well as exploratory programming. in any event i enjoy it a lot

No need to risk that. Just impress us by telling us about the awesome software you have written with your 10x more productive language. I can’t wait.

… crickets …

Still waiting :)

A video about Lisp being used for difficult commercial computational problems: https://youtu.be/f9vRcSAneiw

cheers mate! your work is killer btw :) go hard

ok i couldn't resist ... Lisp is written in Lisp :)

The question is what you have written in Lisp. My guess is very little? Anything used in production anywhere? Go on. It's OK to brag a little :)

get well buddy :)

Ahhh so you have written zero production software in Lisp. As expected.

still waiting on those lisp implementations of yours mate. ur full of it and you know it ;)

And C is written in C, and Haskell is written in Haskell etc. etc. :)

And Emacs is written in C by the way :)

If you think about GNU Emacs, that one is written in C and Emacs Lisp. The original one was written in TECO. I'm using two other ones, which are written in Lisp.

Ah TECO. I spent some seriously quality time writing compilers in Bliss 36 with TECO. I still have muscle memory of TECO.