15 ms·

you don't need to run lisp in a large team. if you adopt lisp you only need 10 programmers to do what 100 will do in another language :)

ducharmdev 5y ago
I hear sentiments like this often with lisp, but if this were the case, why isn't everyone using lisp?
- mrcode007 5y ago
  Largely because of myths surrounding it, for example parenthesis syntax and lack of editor support. With paredit, you get meta level direct AST manipulation support in emacs that is still light years ahead of any programming IDE out there. I think the other fear factor is you have to think a lot more about how to approach the problem when writing Common Lisp and it requires a more complete engineer due to a smaller library ecosystem. Usually there is one and sometimes two libraries for doing X and if not you’re up for making a library yourself. I’m attaching an example of how quickly you can write TLS 1.3 by a single person in Common Lisp. At the time I wrote this library most websites still struggled with TLS 1.3 support. The point is that most software creators don’t have the breath and depth of knowledge required to be proficient in LISP if they only posses siloed domain knowledge. Links: https://github.com/mateuszb/tls1.3 https://github.com/mateuszb/tls1.3 If you want an example of expressivity you can take a look at EC crypto with a full NIST test vector set in about 300 lines of code https://github.com/mateuszb/tls1.3/blob/master/elliptic-curves.lisp https://github.com/mateuszb/tls1.3/blob/master/elliptic-curv...
  - bmitc 5y ago
    > With paredit, you get meta level direct AST manipulation support in emacs that is still light years ahead of any programming IDE out there. Do you happen to know of a video or article with visual examples that demonstrates this? I always hear about these things with Common Lisp, but I have personally never seen it. I’d love to understand how this works or enables people.
    - rags2riches 5y ago
      There's the Animated Guide to Paredit: http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht... It really feels more like you're working on a tree of code than just editing text.
      - bmitc 5y ago
        That’s helpful. I’ll read it more in depth when I’m off mobile as that site is hard to read on mobile. Although, I think there’s still something missing between those demonstrations and the quoted claims. I have never used Paredit when doing Scheme or Racket, so maybe I should just hunker down with it at some point (I have looked into it before). I don’t use Emacs (tried it a few times), but there are several Paredit-based VSCode extensions.
        mrcode007 5y ago
        Paredit is the editor part, but then there is also SLIME REPL. In lisp, unlike in other programming languages, you don't start writing your code with a blank slate and an empty source file. A common approach is to start with an initial core. The idea is that all programs start the same, with an initial core, that contains runtime and standard library. You can test things out in a REPL, that you run side by side with a text editor. As you work things out in REPL, you can start moving them to the text file and the program starts taking form and shape. It's a much more exploration driven design and with fast structure editing of paredit you can really transplant or reorganize pieces of code really quickly. The idea is to grow the program from the initial core into something else inside-out style. It's akin to being dropped into a running program, and modifying it as it is running but that is not possible with most languages easily and as interactively as in Common Lisp for example. With SLIME the REPL and text editor integration, you can for example write a buggy function, test it in REPL and find out about the error. Modify it in the text editor, press Ctrl-c twice, and the function is hot reloaded on the fly. No reloads, no re-imports, no-caching, no program restarts. Next time the function is called, it is replaced with a new stuff you just wrote. It really is pretty magical. It just works, and works for classes, objects, meta classes, functions, variables, etc. The language is unlike other languages, because it offers object introspection (often mistakenly referred to as reflection) and object intercession; introspection and intercession combined give you a true reflection. It is the latter technique that supports all of the above, for an imho superior development experience. It really just works, and it works marvelously well. No yak shaving for hours on end trying to get some dependency chain to work, compiler errors, package version mismatches, etc. No need for build team, no need for testing/qa team, no need for most of your usual dev overhead we are so used to these days :)
- speed_spread 5y ago
  Because you need to find those 10 lisp programmers. The ratio of mediocre Java to good lisp programmers is probably more than 100:1. With only 10 specialists, attrition can become a problem quickly. It's a different optimization.
  - User23 5y ago
    On the other hand there are virtually no mediocre Lisp programmers.
    - exdsq 5y ago
      Why not?
      - quickthrower2 5y ago
        Probably the same in APL, Coq, Prolog and Haskell etc. Weird but mathematically oriented languages that don’t easily get you jobs are persued by passionate programmers. It is like there are no mediocre hikers on the north pole!
        exdsq 5y ago
        You should see some Haskell I've written in production and you'll change your mind quick enough ;)
    - klyrs 5y ago
      I've met quite a few lisp programmers over the years, about half of them mediocre -- particularly those who only knew lisp. Reason being that they learned lisp for a job, and that was just the language the job was in. I might believe that only good programmers pick up lisp on their own, but mediocre programmers follow the money. The excellent lisp programmers I've known have been polyglots -- folks who can dig deep, know how memory works, know how cpus work, know how their lisp works under the hood. The mediocre ones just bash stuff together, oblivious of the details, and the result is no better than javascript.
- User23 5y ago
  Because MPAI.
- Jach 5y ago
  Because such simple one-factor sentiments, even if they are true, are not how people evaluate using one thing over another. At best they might consider it in a multi-factor analysis. But with this particular sentiment it still probably won't be considered much because it's too hard to evaluate the truthiness of such a general claim -- I suspect it's more true in some cases but not so true in others. You'd be more interested in considering the specifics of language+ecosystem (not language alone) and how they relate to your problem domain.
- bitwize 5y ago
  Lots of reasons. 1) Lisp acquired a reputation of being associated with AI, back when that was a bad thing, lots of government-funded "expert system" boondoggles and the like. It is not considered a general purpose language, despite being one. 2) Lisp is thought to have poor library support. Unlike Java or JavaScript, which have standard libraries for every task, Lisp is thought to lack this. Quicklisp helps, but it's not as comprehensive as Maven or npm. 3) Lisp is associated with a certain programmer type: highly intelligent, persnickety, only interested in solving interesting problems. Companies prefer programmers who have only a moderate amount of technical skill but who are diligent, who will take orders and get the job done without complaint. 4) Not many programmers actually know Lisp, because not many bother to learn it. If CS students are exposed to Lisp in college, they will complain about it and won't touch it again after passing required classes that use it. This means Lisp has a much smaller qualified candidate pool and it's much harder to hire Lisp programmers. 5) Software projects, especially enterprise software projects, are optimized to require lots of programmers each of whom develop one component without stepping on each other's toes. In the enterprise, not breaking existing things is more important than building new things rapidly. This is why OO languages like Java are so well loved... they help encapsulate programmers from each other as well as encapsulating units of functionality. Each programmer poses more risk in a small team where every programmer's responsibility is larger (and every programmer could theoretically rebuild the whole system themself given enough time) than in a large team where none of the programmers have a complete understanding of the system and everybody stays in their lane. 7) Larger programming teams are just more impressive. As a manager if you have 100 direct reports instead of 10, you are a bigger deal. You can command a bigger budget, which also makes you seem more important. So the odds are pretty stacked against Lisp. It doesn't scale well to large teams, but it lets a small team get more done. The incentives in most software development reward large teams of programmers just barely smart enough to get the job done, not small surgical teams of wizardly Lisp hackers. So Lisp remains niche, perhaps rightly so.
  - daniel-cussen 5y ago
    You might be able to hire 100 Lisp engineers. It's just super expensive, they're going for really high prices right now, and it might be way overkill.
throwaway17_17 5y ago
Much like the sibling comment I have heard variations of this proposition before. But instead of wondering why don’t more groups take this approach, I want to know what make it possible in the first place. So, in your experience, or even just via some passes down stories, etc., what is it about Lisp that allows for this efficiency? I have heard, although it is always just a quick statement with no explanation that it is the macros. And then one of siblings children comments seems to support the idea that Lisp programmers as a whole may be more experienced/better/more well rounded developers in general, so maybe that’s it. I am genuinely interested in peoples thoughts on this matter and am not being flippant or sarcastic.
- mmmm2 5y ago
  I can't speak from a professional level about this, but I'll tell you why I started using Common Lisp for my personal development. One day I was thinking it would be awesome if someone created a really powerful language with great facilities for abstraction: first class functions, objects, meta objects, etc. It should use dynamic typing during development with an excellent REPL and a built in debugger available everywhere, but it should have the ability to add type declarations when the code got more settled. Even better, this language should include ways of hinting to the compiler how to make a chunk of code faster, and if that wasn't enough, you should be able to replace chunks of code seamlessly with highly optimized C code. I thought about how to implement a language like this for a while, but when I looked into it I discovered Common Lisp does most of this already. It's static typing isn't perfect, though now there is https://coalton-lang.github.io/ https://coalton-lang.github.io/ if that's your thing. So that did it for me, but really this is only part of what you can do with Common Lisp. I think it still has a niche in places where the "right thing" isn't know yet. For example, I read a Reddit post saying that Common Lisp would be a poor choice now for a web startup, and that Paul Graham overstates Common Lisp's case as the reason for Viaweb's success. This is probably true in 2022, but I think it's instructive to look at why Paul claimed Lisp was so helpful back in 1996. There was no Rails or Django, no React or single page web apps. Viaweb built Scheme style continuations onto Common Lisp to simulate an SPA before AJAX was a thing, and on top of that created a slick HTML templating language based off lisp macros. To do that in Perl, or C, would have required something like writing a scheme interpreter, and would have taken much longer for a 2 person team. Is that a 100x advantage? Hard to say. Ultimately, I do think it still has advantages, you just have to find the areas where nothing else will really do the job.
quickthrower2 5y ago
… because the problem they are working on by virtue of being somewhere that can use lisp is not a feature mill …
mjul 5y ago
I hear this a lot but my experience tells me otherwise. For example, I worked on a Clojure project that would leverage this supposed “10x” power of lisp. Despite hiring the even key Clojure contributors, this hypothesis was falsified. The project went from around 35 to over 400 people and it is moving at a the speed of glacial ice. Once you have a project with more than a few people a better language does not have much impact: it is all dominated by people factors and how to fit the project into its larger context.
- wirrbel 5y ago
  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]
  - pjmlp 5y ago
    Pity that Python did not embrace the Lisp features related to machine code generation.
    - agumonkey 5y ago
      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 :)
      - pjmlp 5y ago
        Yes.
        agumonkey 5y ago
agumonkey 5y ago
hey, I can miss deadlines all by myself.
kaba0 5y ago
Such a strong claim requires a similarly strong evidence. And I don’t know of any empirical evidence stating that, so I will remain with Brooks’s claim that no 10x productivity boost is possible between high level languages.
- medo-bear 5y ago
  look at my reply to sibling :)
mbrodersen 5y ago
Sorry but that simply isn’t true. And I know Lisp quite well, and have written my own Lisp implementations just for fun. I like Lisp in many ways but it is not my first pick when it comes to productivity.
- medo-bear 5y ago
  When you capitalize lisp as in Lisp, that usually refers to Common Lisp (also the lisp being discussed in the whole thread). Have you implemented Common Lisp?
  - deleted 5y ago
    [deleted]
  - mbrodersen 5y ago
    OK that was not my intention. I was talking about Lisp flavours in general. I kinda prefer Scheme myself.
    - medo-bear 5y ago
      i think that most of things discussed here pertain strictly to cl. also implementing some random minimal lisp does not make you an expert in common lisp at all. try to implement common lisp and tell me how it goes
      - deterministic 5y ago
        What a bizarre argument. Have you implemented Common Lisp yourself? If not then you know nothing about Lisp then?
        medo-bear 5y ago
        but it was you who claimed to be an expert in lisp and said that you implemented several lisps in support of that claim
wglb 5y ago
This isn't quite the experience that I have had. To confess, I am probably, on a good day, 0.8x programmer. (I have known a handful of 10x programmers. And more than a few 0.1x programmers.) My first big project was in FORTRAN II. The way that IF statements worked was really horrific, what with three statement labels. Next up was a massive project in Sigma5 assembler with interrupt driven tasks. Once we implemented co-routines, co-operative inter-process communication was a breeze, with very few multi-thread errors. I cringe when I see folks struggling with async-await hell. Prior to go, the only language that I saw that did co-routines well was Bliss-36. Later I did a lot of C (pre-web). When I picked up C++, I ended up with fewer crashes, as I found it easier to deal with pointers to objects. I came to Lisp later on, and am still working with it. It is a lot better than other languages for me in several ways. First, it is quite expressive. Secondly, with a slime, it is trivial to debug using break statements, ability to instantly navigate to the source of a function, be it yours or deep in the heart of e.g. SBCL. I use Lisp exclusively now (with an embarrassing amount of bash mixed in), but not because it is 10x for me. I am likely several X more productive, but in part due to the debug ability plus the repl. Also, sbcl is really fast, even if you don't resort to hackish tricks like was done for sbcl to intimidate other languages in the mandelbrot benchmark game. Or log4cl compared with the speed of log4j. Where some real leverage comes in with Lisp is the ability to express things that are significantly more difficult in other languages. There are things done in Lisp that are just plain impractical in other languages. But there are some things that the programs are just about as annoying as in any other language. Look at the code dealing with http in either of the libraries drakma or dexador. Lisp ain't much help making that awful protocol go away. And often in larger projects, minor advantages of a language compound to end up with a 2x or better result. So this argument about a language being a miracle productivity tool is a pretty old one. I had a boss, a PhD fellow much smarter than I claim that higher-level assembler languages would make writing an operating system trivially easy. I was a bit suspicious of that then, and am quite certain of it now.
- medo-bear 5y ago
  hi. thanks for sharing your experience. i just saw in your profile that your domain is security. if i may ask, do you have experience with lisp in this field, particularly as far as networking and encryption is concerned? as regards this 10x business, i actually wasn't being very serious. it was just a playful response to the parent's claim that lisp is not suitable for large teams

ducharmdev 5y ago

I hear sentiments like this often with lisp, but if this were the case, why isn't everyone using lisp?

mrcode007 5y ago
Largely because of myths surrounding it, for example parenthesis syntax and lack of editor support. With paredit, you get meta level direct AST manipulation support in emacs that is still light years ahead of any programming IDE out there. I think the other fear factor is you have to think a lot more about how to approach the problem when writing Common Lisp and it requires a more complete engineer due to a smaller library ecosystem. Usually there is one and sometimes two libraries for doing X and if not you’re up for making a library yourself. I’m attaching an example of how quickly you can write TLS 1.3 by a single person in Common Lisp. At the time I wrote this library most websites still struggled with TLS 1.3 support. The point is that most software creators don’t have the breath and depth of knowledge required to be proficient in LISP if they only posses siloed domain knowledge. Links: https://github.com/mateuszb/tls1.3 https://github.com/mateuszb/tls1.3 If you want an example of expressivity you can take a look at EC crypto with a full NIST test vector set in about 300 lines of code https://github.com/mateuszb/tls1.3/blob/master/elliptic-curves.lisp https://github.com/mateuszb/tls1.3/blob/master/elliptic-curv...
- bmitc 5y ago
  > With paredit, you get meta level direct AST manipulation support in emacs that is still light years ahead of any programming IDE out there. Do you happen to know of a video or article with visual examples that demonstrates this? I always hear about these things with Common Lisp, but I have personally never seen it. I’d love to understand how this works or enables people.
  - rags2riches 5y ago
    There's the Animated Guide to Paredit: http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht... It really feels more like you're working on a tree of code than just editing text.
    - bmitc 5y ago
      That’s helpful. I’ll read it more in depth when I’m off mobile as that site is hard to read on mobile. Although, I think there’s still something missing between those demonstrations and the quoted claims. I have never used Paredit when doing Scheme or Racket, so maybe I should just hunker down with it at some point (I have looked into it before). I don’t use Emacs (tried it a few times), but there are several Paredit-based VSCode extensions.
      - mrcode007 5y ago
        Paredit is the editor part, but then there is also SLIME REPL. In lisp, unlike in other programming languages, you don't start writing your code with a blank slate and an empty source file. A common approach is to start with an initial core. The idea is that all programs start the same, with an initial core, that contains runtime and standard library. You can test things out in a REPL, that you run side by side with a text editor. As you work things out in REPL, you can start moving them to the text file and the program starts taking form and shape. It's a much more exploration driven design and with fast structure editing of paredit you can really transplant or reorganize pieces of code really quickly. The idea is to grow the program from the initial core into something else inside-out style. It's akin to being dropped into a running program, and modifying it as it is running but that is not possible with most languages easily and as interactively as in Common Lisp for example. With SLIME the REPL and text editor integration, you can for example write a buggy function, test it in REPL and find out about the error. Modify it in the text editor, press Ctrl-c twice, and the function is hot reloaded on the fly. No reloads, no re-imports, no-caching, no program restarts. Next time the function is called, it is replaced with a new stuff you just wrote. It really is pretty magical. It just works, and works for classes, objects, meta classes, functions, variables, etc. The language is unlike other languages, because it offers object introspection (often mistakenly referred to as reflection) and object intercession; introspection and intercession combined give you a true reflection. It is the latter technique that supports all of the above, for an imho superior development experience. It really just works, and it works marvelously well. No yak shaving for hours on end trying to get some dependency chain to work, compiler errors, package version mismatches, etc. No need for build team, no need for testing/qa team, no need for most of your usual dev overhead we are so used to these days :)
speed_spread 5y ago
Because you need to find those 10 lisp programmers. The ratio of mediocre Java to good lisp programmers is probably more than 100:1. With only 10 specialists, attrition can become a problem quickly. It's a different optimization.
- User23 5y ago
  On the other hand there are virtually no mediocre Lisp programmers.
  - exdsq 5y ago
    Why not?
    - quickthrower2 5y ago
      Probably the same in APL, Coq, Prolog and Haskell etc. Weird but mathematically oriented languages that don’t easily get you jobs are persued by passionate programmers. It is like there are no mediocre hikers on the north pole!
      - exdsq 5y ago
        You should see some Haskell I've written in production and you'll change your mind quick enough ;)
  - klyrs 5y ago
    I've met quite a few lisp programmers over the years, about half of them mediocre -- particularly those who only knew lisp. Reason being that they learned lisp for a job, and that was just the language the job was in. I might believe that only good programmers pick up lisp on their own, but mediocre programmers follow the money. The excellent lisp programmers I've known have been polyglots -- folks who can dig deep, know how memory works, know how cpus work, know how their lisp works under the hood. The mediocre ones just bash stuff together, oblivious of the details, and the result is no better than javascript.
User23 5y ago
Because MPAI.
Jach 5y ago
Because such simple one-factor sentiments, even if they are true, are not how people evaluate using one thing over another. At best they might consider it in a multi-factor analysis. But with this particular sentiment it still probably won't be considered much because it's too hard to evaluate the truthiness of such a general claim -- I suspect it's more true in some cases but not so true in others. You'd be more interested in considering the specifics of language+ecosystem (not language alone) and how they relate to your problem domain.
bitwize 5y ago
Lots of reasons. 1) Lisp acquired a reputation of being associated with AI, back when that was a bad thing, lots of government-funded "expert system" boondoggles and the like. It is not considered a general purpose language, despite being one. 2) Lisp is thought to have poor library support. Unlike Java or JavaScript, which have standard libraries for every task, Lisp is thought to lack this. Quicklisp helps, but it's not as comprehensive as Maven or npm. 3) Lisp is associated with a certain programmer type: highly intelligent, persnickety, only interested in solving interesting problems. Companies prefer programmers who have only a moderate amount of technical skill but who are diligent, who will take orders and get the job done without complaint. 4) Not many programmers actually know Lisp, because not many bother to learn it. If CS students are exposed to Lisp in college, they will complain about it and won't touch it again after passing required classes that use it. This means Lisp has a much smaller qualified candidate pool and it's much harder to hire Lisp programmers. 5) Software projects, especially enterprise software projects, are optimized to require lots of programmers each of whom develop one component without stepping on each other's toes. In the enterprise, not breaking existing things is more important than building new things rapidly. This is why OO languages like Java are so well loved... they help encapsulate programmers from each other as well as encapsulating units of functionality. Each programmer poses more risk in a small team where every programmer's responsibility is larger (and every programmer could theoretically rebuild the whole system themself given enough time) than in a large team where none of the programmers have a complete understanding of the system and everybody stays in their lane. 7) Larger programming teams are just more impressive. As a manager if you have 100 direct reports instead of 10, you are a bigger deal. You can command a bigger budget, which also makes you seem more important. So the odds are pretty stacked against Lisp. It doesn't scale well to large teams, but it lets a small team get more done. The incentives in most software development reward large teams of programmers just barely smart enough to get the job done, not small surgical teams of wizardly Lisp hackers. So Lisp remains niche, perhaps rightly so.
- daniel-cussen 5y ago
  You might be able to hire 100 Lisp engineers. It's just super expensive, they're going for really high prices right now, and it might be way overkill.

throwaway17_17 5y ago

Much like the sibling comment I have heard variations of this proposition before. But instead of wondering why don’t more groups take this approach, I want to know what make it possible in the first place. So, in your experience, or even just via some passes down stories, etc., what is it about Lisp that allows for this efficiency? I have heard, although it is always just a quick statement with no explanation that it is the macros. And then one of siblings children comments seems to support the idea that Lisp programmers as a whole may be more experienced/better/more well rounded developers in general, so maybe that’s it. I am genuinely interested in peoples thoughts on this matter and am not being flippant or sarcastic.

mmmm2 5y ago
I can't speak from a professional level about this, but I'll tell you why I started using Common Lisp for my personal development. One day I was thinking it would be awesome if someone created a really powerful language with great facilities for abstraction: first class functions, objects, meta objects, etc. It should use dynamic typing during development with an excellent REPL and a built in debugger available everywhere, but it should have the ability to add type declarations when the code got more settled. Even better, this language should include ways of hinting to the compiler how to make a chunk of code faster, and if that wasn't enough, you should be able to replace chunks of code seamlessly with highly optimized C code. I thought about how to implement a language like this for a while, but when I looked into it I discovered Common Lisp does most of this already. It's static typing isn't perfect, though now there is https://coalton-lang.github.io/ https://coalton-lang.github.io/ if that's your thing. So that did it for me, but really this is only part of what you can do with Common Lisp. I think it still has a niche in places where the "right thing" isn't know yet. For example, I read a Reddit post saying that Common Lisp would be a poor choice now for a web startup, and that Paul Graham overstates Common Lisp's case as the reason for Viaweb's success. This is probably true in 2022, but I think it's instructive to look at why Paul claimed Lisp was so helpful back in 1996. There was no Rails or Django, no React or single page web apps. Viaweb built Scheme style continuations onto Common Lisp to simulate an SPA before AJAX was a thing, and on top of that created a slick HTML templating language based off lisp macros. To do that in Perl, or C, would have required something like writing a scheme interpreter, and would have taken much longer for a 2 person team. Is that a 100x advantage? Hard to say. Ultimately, I do think it still has advantages, you just have to find the areas where nothing else will really do the job.

quickthrower2 5y ago

… because the problem they are working on by virtue of being somewhere that can use lisp is not a feature mill …

mjul 5y ago

I hear this a lot but my experience tells me otherwise. For example, I worked on a Clojure project that would leverage this supposed “10x” power of lisp. Despite hiring the even key Clojure contributors, this hypothesis was falsified. The project went from around 35 to over 400 people and it is moving at a the speed of glacial ice. Once you have a project with more than a few people a better language does not have much impact: it is all dominated by people factors and how to fit the project into its larger context.

wirrbel 5y ago
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]
- pjmlp 5y ago
  Pity that Python did not embrace the Lisp features related to machine code generation.
  - agumonkey 5y ago
    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 :)
    - pjmlp 5y ago
      Yes.
      - agumonkey 5y ago

agumonkey 5y ago

hey, I can miss deadlines all by myself.

kaba0 5y ago

Such a strong claim requires a similarly strong evidence. And I don’t know of any empirical evidence stating that, so I will remain with Brooks’s claim that no 10x productivity boost is possible between high level languages.

medo-bear 5y ago
look at my reply to sibling :)

mbrodersen 5y ago

Sorry but that simply isn’t true. And I know Lisp quite well, and have written my own Lisp implementations just for fun. I like Lisp in many ways but it is not my first pick when it comes to productivity.

medo-bear 5y ago
When you capitalize lisp as in Lisp, that usually refers to Common Lisp (also the lisp being discussed in the whole thread). Have you implemented Common Lisp?
- deleted 5y ago
  [deleted]
- mbrodersen 5y ago
  OK that was not my intention. I was talking about Lisp flavours in general. I kinda prefer Scheme myself.
  - medo-bear 5y ago
    i think that most of things discussed here pertain strictly to cl. also implementing some random minimal lisp does not make you an expert in common lisp at all. try to implement common lisp and tell me how it goes
    - deterministic 5y ago
      What a bizarre argument. Have you implemented Common Lisp yourself? If not then you know nothing about Lisp then?
      - medo-bear 5y ago
        but it was you who claimed to be an expert in lisp and said that you implemented several lisps in support of that claim

wglb 5y ago

This isn't quite the experience that I have had. To confess, I am probably, on a good day, 0.8x programmer. (I have known a handful of 10x programmers. And more than a few 0.1x programmers.) My first big project was in FORTRAN II. The way that IF statements worked was really horrific, what with three statement labels. Next up was a massive project in Sigma5 assembler with interrupt driven tasks. Once we implemented co-routines, co-operative inter-process communication was a breeze, with very few multi-thread errors. I cringe when I see folks struggling with async-await hell. Prior to go, the only language that I saw that did co-routines well was Bliss-36. Later I did a lot of C (pre-web). When I picked up C++, I ended up with fewer crashes, as I found it easier to deal with pointers to objects. I came to Lisp later on, and am still working with it. It is a lot better than other languages for me in several ways. First, it is quite expressive. Secondly, with a slime, it is trivial to debug using break statements, ability to instantly navigate to the source of a function, be it yours or deep in the heart of e.g. SBCL. I use Lisp exclusively now (with an embarrassing amount of bash mixed in), but not because it is 10x for me. I am likely several X more productive, but in part due to the debug ability plus the repl. Also, sbcl is really fast, even if you don't resort to hackish tricks like was done for sbcl to intimidate other languages in the mandelbrot benchmark game. Or log4cl compared with the speed of log4j. Where some real leverage comes in with Lisp is the ability to express things that are significantly more difficult in other languages. There are things done in Lisp that are just plain impractical in other languages. But there are some things that the programs are just about as annoying as in any other language. Look at the code dealing with http in either of the libraries drakma or dexador. Lisp ain't much help making that awful protocol go away. And often in larger projects, minor advantages of a language compound to end up with a 2x or better result. So this argument about a language being a miracle productivity tool is a pretty old one. I had a boss, a PhD fellow much smarter than I claim that higher-level assembler languages would make writing an operating system trivially easy. I was a bit suspicious of that then, and am quite certain of it now.

medo-bear 5y ago
hi. thanks for sharing your experience. i just saw in your profile that your domain is security. if i may ask, do you have experience with lisp in this field, particularly as far as networking and encryption is concerned? as regards this 10x business, i actually wasn't being very serious. it was just a playful response to the parent's claim that lisp is not suitable for large teams