5 ms·

How the Curse of Lisp impacts your business (even if you don't use Lisp)

25 points by ironmagma 2y ago

freilanzer 2y ago
> Well, a particular genre of programming languages (Lisps) is essentially immune to the network effect, unlike most other languages. This is because Lisp makes it very easy to write your own libraries from scratch; people who use Lisp tend to do that instead of reusing third-party dependencies. What? Lisp makes implementing libraries no easier or harder than most other languages. Even the original author afair criticised his own article about the lisp curse some time ago.
lispm 2y ago
> people who use Lisp tend to do that instead of reusing third-party dependencies Is there any actual evidence for this?
- jjtheblunt 2y ago
  the evolution of quicklisp seems evidence to the contrary, i believe
corinroyal 2y ago
We have a fantastic Common Lisp package ecosystem with Quicklisp and we use other people's libraries all the time. Most of us are savvy enough to share our 80% solutions so that others can add their 20%. I wish more people would realize that the Common Lisp we program in today is not your Grandma's Common Lisp. Lisp usage and culture change over time just like in every other language ecosystem. I never see my Lisp reflected in these tired tropes.
- ironmagma 2y ago
  Thanks for the feedback, I have never heard anyone contest the 'Lisp Curse' claim, and mostly the Lisp I've written has been small-time, so this article is not supposed to be about lisps per se, more the business impact of the idea. But that said, obviously Clojure with deps.edn exists. Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval? That seems quite slow if you are looking to socialize your changes, use someone else's recent bug fix, or to defragment a project.
  - kazinator 2y ago
    The Lisp Curse article was written by a web developer with zero Lisp experience in even a hobby setting, let alone professional. He just made it up, like a hallucinating LLM.
  - kazinator 2y ago
    If there is some Lisp package that has frequent updates that are not picked up via Quicklisp, and you want to keep up with those, then just put the tree of that thing in your project, and refer to its .asd file from yours.
    - trocado 2y ago
      Or just clone into local-projects and quicklisp will load from there.
      - ungamedplayer 2y ago
        Or use qlot and drag from many supported source repos.
  - lispm 2y ago
    > I have never heard anyone contest the 'Lisp Curse' claim You could have asked in the community for opinions. > This is because Lisp makes it very easy to write your own libraries from scratch; That's not generally true. Some libraries are maintained for decades, since it would be difficult to reproduce them. The reasons for writing new libraries, instead of an existing one are more like: * disagreement with coding styles * very different underlying platform * need for a different license * lack of maintainers for code written decades ago > people who use Lisp tend to do that instead of reusing third-party dependencies. I don't think that's the case. There are widely used libraries for a bunch of things and having a stable and standardized language makes it actually easier to write platform independent code and enables code sharing. There are reasons why people write their own libraries, often because existing libraries were written for different platforms (especially the operating system). In the free software area of Common Lisp, a system like SBCL is popular because of the network effect in a small niche of Lisp programs. Libraries tend to be better supported in SBCL -> more use for SBCL.
- deleted 2y ago
  [deleted]
- ReleaseCandidat 2y ago
  > Quicklisp [...] not your Grandma's Common Lisp. Ocicl, if we are not talking about your Mother's Common Lisp ;) https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl
  - corinroyal 2y ago
    I love it! My grandma was a "computer" who held patents on coax connectors and kept some early CAD mainframes alive. Can't wait to try OSICL.
kazinator 2y ago
Another article by a non-practitioner of Lisp trying to harm Lisp people. Because we are few in number, it's hard to defend against, and harmful. It is not easy to write your own libraries in Lisp. You're not going to write your own cryptography, web serving, database access, regular expressions and whatnot, and if so, not to the level of quality of available libraries. People developing applications in Lisp use libraries.
- ironmagma 2y ago
  First, I'm not a non-practitioner of Lisp, I've written a fair amount of it. And more importantly, the article isn't about any programming language. Further, I have heard this phenomenon bolstered by heavy Lisp users IRL and Eric Normand who hosts LispCast. It's insane to me that you would think this is written to harm Lisp users, as I love the community and the languages. My point is something that applies to every (other) language, and it's a point about fragmentation. If you use packages in your favorite language, that's great, and not who I'm talking to.
  - kazinator 2y ago
    > written to harm Lisp users Who cares what is the intent or not if all that remains is the effect at the end of the day.
    - ironmagma 2y ago
      How is that the effect? The maximum extent of damage, if any, is referencing an already-widely-referenced text. I'm not attacking anyone, or anything, aside from the concept of dependency avoidance. Honestly, having a curse named after you makes you cool in my book, at least when you adopt the "no publicity is bad publicity" outlook. Especially when the core critique is that the curse is that the language is too powerful.
      - deleted 2y ago
        [deleted]
      - 2y ago
flembat 2y ago
The fact that millions of programs use the exact same code, is what makes exploring that code for vulnerabilities worthwhile. If there was more original code, it would have less impact when a vulnerability was exploited and much more effort would be needed to attack each application. Luckily LLM can help us create and test that unique code at a lower cost than before. The problem with everyone not rolling their own library code, is that the experts code often contains issues that exist but do not become public knowledge for years, because libary users don't bother to look at it or understand the code, they don't understand how it works or use it correctly.
zzo38computer 2y ago
As far as I am concerned, the only (almost) valid point they made is this one: > When you have an internally-maintained piece of code, it does not benefit from the incoming bugfixes that an external dependency might enjoy. But, even this one is not always good. Your internal code might not have the bugs that would affect your program, might be less efficient due to doing things that are not relevant to your program, and you might be able to fix the bug more easily in your own program than you would with an external dependency, especially if they do not fix it in time. There is also vulnerabilities, and other stuff. Furthermore, the external dependencies might make the program larger than it should be. There are many good reasons to avoid external dependencies.
- ironmagma 2y ago
  Key word is might. Yes, it’s a game of probability, and also a game of “is it, though?” I would posit that something maintained by the wider public is less likely to contain bugs than something maintained by a smaller/less varied group (you or your company). Yes, you can point to xz-utils as an example of the ineffectiveness of groups at catching attacks, but it’s also famous because it’s exceptionally bad and probably not normal.
  - zzo38computer 2y ago
    Whether or not that is true (and what kind of bugs) might depend on the specific software. Furthermore, sometimes changes to external dependencies may introduce bugs (which might or might not be malicious; both kinds can and do happen), which might be fixed in a later version but that might take some time. Another alternative is that if the dependency is only one or two files, you can just make your own copy of them and use those instead, and maintain them by yourself, reviewing any changes to the official version and applying them to your own if you consider them necessary; this might also allow you to fix bugs that haven't been corrected and to omit features that you do not need. Another reason you might wish to avoid external dependencies is if they cannot be packaged together with the software; if they come from a different source, then there is the possibility that the external source may be no longer available (which might or might not be malicious; again, both kinds can and do happen). (If they are not very large and only one or two files, then you can just include it with your software.) If your software uses external dependencies, you might also specify exact versions by both version numbers and cryptographic hashes. The use of cryptographic hashes will mitigate some types of attacks as well as to potentially allow finding other copies if the source that you got it from is no longer available. Another issue, depending on the kind of dependencies, may be interfaces with other software (possibly including the operating system), in which case there may potentially be multiple possible implementations, and the system administrator may wish to install their own. In the package manager for operating system design that I had considered, this is also an issue that I had considered. A package can have multiple identifiers of any kinds. Additionally, there are other features of the operating system which can help many things. Hopefully, these things will be able avoid many kind of problems.
lordnacho 2y ago
Your main reply to "not invented here" is "okay, invent it here and maintain it here then, buddy". One of the key skills of a a senior dev is to be able to judge the tradeoff between rolling your own and borrowing someone else's. In your life as a dev you'll be making this choice all the time. The pros and cons are generic: time spent, potential bugs, security, free upgrades, specific vs general solutions, external reliance, and so on. But you will exercise this judgement constantly. Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP?
- ironmagma 2y ago
  The main reply was to use more things off the shelf, or at least be aware there is a business cost of not doing so. Ironically this blog post isn’t even targeted at developers but more management types, but it wouldn’t be life without being spectacularly wrong on HN and raked over the coals on it. In short though I agree it’s not like you can just use off the shelf for everything or that that is even a good idea to try as that has its own set of problems.
- danielheath 2y ago
  > Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP? As someone who has dabbled in lisp: IME, everything is easier - enough so that I more-often _consider_ inventing something that solves my subset of the problem. I suspect this contributes to the poor library availability situation (I understand that's improved markedly in recent years, but still).
- jhbadger 2y ago
  It's still somewhat common, but over the past couple of decades we've created package managers like QuickLisp that allow calling external dependencies in Common Lisp as easy as it is in Python (and even systems to allow us to interact with Python to get access to its ecosystem), plus a version of Common Lisp (Armed Bear Common Lisp) that runs on the JVM to get access to that ecosystem (not to mention the Lisp-adjacent language Clojure).
mihaaly 2y ago
The author generously omit the long jurney through the negative side of external dependencies. This is somewhat frivolous and too unbalanced to be reliable this way. The truth must be somewhere inbetween again.
mark_l_watson 2y ago
I feel like the author is perhaps making a valid criticism of Common Lisp that was only valid in ancient history. In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself. With the advent of Quicklisp, many repos on public services like GitHub, etc., it is now easy to find and use good libraries for Common Lisp. Of course there is a network effect: a language like Python is much more popular so there are many more libraries available. That said Common Lisp, Racket, and other Lisps all have good ecosystems and are fun and productive to use.
- lispm 2y ago
  > In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself. The early .com companies on the Internet were all deeply involved in Lisp/AI companies: Symbolics, BBN, Thinking Machines, MCC, Xerox, SRI, ...). Plus a bunch of universities (MIT had hundreds of networked machines running some Lisp, including Lisp Machines). Many of the R&D groups were on the Internet. Larger amounts of code were for example shared via tape. For example the Symbolics User Group already shared code. The CMU CL wrote their Lisp implementation as public domain and shared all their implementation code: Lisp, editor, UI, ... Lots of old code from that time is all collected in the CMU AI Archive, which was established early 90s: https://www.cs.cmu.edu/Groups/AI/0.html https://www.cs.cmu.edu/Groups/AI/0.html At that time a lot of new stuff was developed, like CLX, the X11 interface for Common Lisp. Every Lisper on X11 was using it. TI developed CLUE and CLIO on top of CLX. LispWorks developed their gui toolkit on top of CLUE and CLX. Sure, there were lone developers but Lisp in the 80s was widely used in universities and R&D. All were networked. MCC had 200 Lisp Machines in their network, IIRC. MIT more. SRI similar. Xerox. BBN even developed their own Lisp OS + machine. Symbolics had support for DECNET, TCP/IP, IBM Mainframes, ... The Common Lisp standard, developed in the 1980s was probably the first developed with heavy e-mail support. There was a lot of stuff shared.
  - mark_l_watson 2y ago
    All true! In my case, except hearing about stuff at AAAI conferences, I was mostly ignorant of most of the projects you mentioned.
deleted 2y ago
[deleted]
recursivedoubts 2y ago
Compare and contrast with “the curse of JavaScript” which is the opposite problem of an explosion of dependencies and the management thereof. The business guys might not like it (“it’s too hard to replace engineers”) but, from a software engineering perspective, a tendency towards fewer dependencies is better for the system.
- ironmagma 2y ago
  This gets at an interesting nuance. The under-reliance on dependencies actually poses issues at a system level, not at an individual product level, which makes it hard to sell business types on the existence of the problem. Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know. The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.
neilv 2y ago
What about the curse of an entire field that's so systemically incompetent -- starting with how it hires, and therefore, now, how it trains -- that the field is incapable of (for example) building a system that's not riddled with security vulnerabilities, yet the field confidently churns out a flood of blog posts about best practices?
- deleted 2y ago
  [deleted]
- ironmagma 2y ago
  Yeah the entire field of tech is pretty broken. Is the solution supposed to be to not write about it?
- klibertp 2y ago
  > churns out a flood of blog posts about best practices? ...most of which are cargo-culting carbon-copies of "gurus" and "authorities" (and "Uncle Bob"). No critical thought in sight, but a lot of mental gymnastics to justify conclusions that don't follow from whatever was written above. The massive influx of poorly prepared junior programmers in the last decade doesn't help. Somehow, beginner programmers tend to overgeneralize from too narrow a perspective, leading to fallacious but firmly held beliefs. This is nothing new and happens to most beginners; the problem is that we're dealing with a massive wave of beginners that seems to be still gaining momentum instead of subsiding. One of the effects is that the experienced, mature programmers' voices are drowned in the noise, save for a few "gurus" who are often better writers than programmers. The whole field shunning its own history doesn't help either. The culture of moving fast created a misperception that things older than half a year have no value. Similarly, agile and co. made it so we live in perpetual "now," rarely considering the long-term consequences of our work. This leads to resume-driven development and contributes to enshitification of everything, yet nobody seems to realize there even is a problem, much less have any intention of fixing it. Honestly, I'm struggling to find my place in the field after two decades of coding.
  - ironmagma 2y ago
    All the things you said about junior developers hold for senior developers too. This field of computer science is over a hundred years old, but we don’t (and can’t) treat it that way. The overgeneralization stems from having strong beliefs. Where do you get the idea we have a massive wall of beginners? Just a week ago was posted, “The End of Jr Engineers.”
neilv 2y ago
Imagine, one time, some writer, writing a short story of laying in bed with their sleeping spouse on a peaceful summer night, wrote wistfully of how they loved that their spouse's hair smelled faintly of citrus at that moment. And a blogger stumbled upon this piece, and decided there was a widespread problem with people rubbing oranges on their heads, and, further, with the general problem of the author's entire nationality of people, and that this urgently needed to be exposed to the public, in a patient explanatory blog post. Seeing this blog post, others, realizing that there's been a misunderstanding, but knowing more about that nation (and/or fruits, and/or hair care), than about PR damage control, proceeded to respond, with a flood of various corrections, all over the map. For example, "I prefer fresh-squeezed lemon, so long as you're careful to avoid traumatic brain injury." And "Those people are not that bad; the many stories of kidnappings are often exaggerations of muggings." In all seriousness. And anyone observing is thinking "I'm even more confused than before, but those people sure are defensive about whatever the heck ungodly things they're doing with fruits. It might be a nice place to visit, for a day trip, but I wouldn't want to live with those crazy fanatics."
- ironmagma 2y ago
  I think if I cared about damage control I would have deleted the article a long time ago as so many people have clearly missed the point of the post. Again I would never (and didn’t) draw an issue with an entire nationality of people squeezing oranges in their hair, particularly being an orange-squeezer myself. If anything, it would be better if almost everyone would be squeezing citrus in their hair every day, as we would more readily be able to point to the side effects associated with doing so without it seeming like an affront to one group of people. True, this analogy is confusing, but it’s also great that you created it.
diffxx 2y ago
This feels like an argument against learning how to play an instrument. Why would anyone do that when there are so many other highly skilled players out there?
- ironmagma 2y ago
  Learning an instrument is a great thing to do and I can highly recommend it. What I can't recommend is learning an instrument from scratch when you were hired to play that instrument in an orchestra, as you are being paid to play in the orchestra.

25 points by ironmagma 2y ago

> Well, a particular genre of programming languages (Lisps) is essentially immune to the network effect, unlike most other languages. This is because Lisp makes it very easy to write your own libraries from scratch; people who use Lisp tend to do that instead of reusing third-party dependencies. What? Lisp makes implementing libraries no easier or harder than most other languages. Even the original author afair criticised his own article about the lisp curse some time ago.

lispm 2y ago

> people who use Lisp tend to do that instead of reusing third-party dependencies Is there any actual evidence for this?

jjtheblunt 2y ago
the evolution of quicklisp seems evidence to the contrary, i believe

corinroyal 2y ago

We have a fantastic Common Lisp package ecosystem with Quicklisp and we use other people's libraries all the time. Most of us are savvy enough to share our 80% solutions so that others can add their 20%. I wish more people would realize that the Common Lisp we program in today is not your Grandma's Common Lisp. Lisp usage and culture change over time just like in every other language ecosystem. I never see my Lisp reflected in these tired tropes.

ironmagma 2y ago
Thanks for the feedback, I have never heard anyone contest the 'Lisp Curse' claim, and mostly the Lisp I've written has been small-time, so this article is not supposed to be about lisps per se, more the business impact of the idea. But that said, obviously Clojure with deps.edn exists. Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval? That seems quite slow if you are looking to socialize your changes, use someone else's recent bug fix, or to defragment a project.
- kazinator 2y ago
  The Lisp Curse article was written by a web developer with zero Lisp experience in even a hobby setting, let alone professional. He just made it up, like a hallucinating LLM.
- kazinator 2y ago
  If there is some Lisp package that has frequent updates that are not picked up via Quicklisp, and you want to keep up with those, then just put the tree of that thing in your project, and refer to its .asd file from yours.
  - trocado 2y ago
    Or just clone into local-projects and quicklisp will load from there.
    - ungamedplayer 2y ago
      Or use qlot and drag from many supported source repos.
- lispm 2y ago
  > I have never heard anyone contest the 'Lisp Curse' claim You could have asked in the community for opinions. > This is because Lisp makes it very easy to write your own libraries from scratch; That's not generally true. Some libraries are maintained for decades, since it would be difficult to reproduce them. The reasons for writing new libraries, instead of an existing one are more like: * disagreement with coding styles * very different underlying platform * need for a different license * lack of maintainers for code written decades ago > people who use Lisp tend to do that instead of reusing third-party dependencies. I don't think that's the case. There are widely used libraries for a bunch of things and having a stable and standardized language makes it actually easier to write platform independent code and enables code sharing. There are reasons why people write their own libraries, often because existing libraries were written for different platforms (especially the operating system). In the free software area of Common Lisp, a system like SBCL is popular because of the network effect in a small niche of Lisp programs. Libraries tend to be better supported in SBCL -> more use for SBCL.
deleted 2y ago
[deleted]
ReleaseCandidat 2y ago
> Quicklisp [...] not your Grandma's Common Lisp. Ocicl, if we are not talking about your Mother's Common Lisp ;) https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl
- corinroyal 2y ago
  I love it! My grandma was a "computer" who held patents on coax connectors and kept some early CAD mainframes alive. Can't wait to try OSICL.

kazinator 2y ago

Another article by a non-practitioner of Lisp trying to harm Lisp people. Because we are few in number, it's hard to defend against, and harmful. It is not easy to write your own libraries in Lisp. You're not going to write your own cryptography, web serving, database access, regular expressions and whatnot, and if so, not to the level of quality of available libraries. People developing applications in Lisp use libraries.

ironmagma 2y ago
First, I'm not a non-practitioner of Lisp, I've written a fair amount of it. And more importantly, the article isn't about any programming language. Further, I have heard this phenomenon bolstered by heavy Lisp users IRL and Eric Normand who hosts LispCast. It's insane to me that you would think this is written to harm Lisp users, as I love the community and the languages. My point is something that applies to every (other) language, and it's a point about fragmentation. If you use packages in your favorite language, that's great, and not who I'm talking to.
- kazinator 2y ago
  > written to harm Lisp users Who cares what is the intent or not if all that remains is the effect at the end of the day.
  - ironmagma 2y ago
    How is that the effect? The maximum extent of damage, if any, is referencing an already-widely-referenced text. I'm not attacking anyone, or anything, aside from the concept of dependency avoidance. Honestly, having a curse named after you makes you cool in my book, at least when you adopt the "no publicity is bad publicity" outlook. Especially when the core critique is that the curse is that the language is too powerful.
    - deleted 2y ago
      [deleted]
    - 2y ago

flembat 2y ago

The fact that millions of programs use the exact same code, is what makes exploring that code for vulnerabilities worthwhile. If there was more original code, it would have less impact when a vulnerability was exploited and much more effort would be needed to attack each application. Luckily LLM can help us create and test that unique code at a lower cost than before. The problem with everyone not rolling their own library code, is that the experts code often contains issues that exist but do not become public knowledge for years, because libary users don't bother to look at it or understand the code, they don't understand how it works or use it correctly.

zzo38computer 2y ago

As far as I am concerned, the only (almost) valid point they made is this one: > When you have an internally-maintained piece of code, it does not benefit from the incoming bugfixes that an external dependency might enjoy. But, even this one is not always good. Your internal code might not have the bugs that would affect your program, might be less efficient due to doing things that are not relevant to your program, and you might be able to fix the bug more easily in your own program than you would with an external dependency, especially if they do not fix it in time. There is also vulnerabilities, and other stuff. Furthermore, the external dependencies might make the program larger than it should be. There are many good reasons to avoid external dependencies.

ironmagma 2y ago
Key word is might. Yes, it’s a game of probability, and also a game of “is it, though?” I would posit that something maintained by the wider public is less likely to contain bugs than something maintained by a smaller/less varied group (you or your company). Yes, you can point to xz-utils as an example of the ineffectiveness of groups at catching attacks, but it’s also famous because it’s exceptionally bad and probably not normal.
- zzo38computer 2y ago
  Whether or not that is true (and what kind of bugs) might depend on the specific software. Furthermore, sometimes changes to external dependencies may introduce bugs (which might or might not be malicious; both kinds can and do happen), which might be fixed in a later version but that might take some time. Another alternative is that if the dependency is only one or two files, you can just make your own copy of them and use those instead, and maintain them by yourself, reviewing any changes to the official version and applying them to your own if you consider them necessary; this might also allow you to fix bugs that haven't been corrected and to omit features that you do not need. Another reason you might wish to avoid external dependencies is if they cannot be packaged together with the software; if they come from a different source, then there is the possibility that the external source may be no longer available (which might or might not be malicious; again, both kinds can and do happen). (If they are not very large and only one or two files, then you can just include it with your software.) If your software uses external dependencies, you might also specify exact versions by both version numbers and cryptographic hashes. The use of cryptographic hashes will mitigate some types of attacks as well as to potentially allow finding other copies if the source that you got it from is no longer available. Another issue, depending on the kind of dependencies, may be interfaces with other software (possibly including the operating system), in which case there may potentially be multiple possible implementations, and the system administrator may wish to install their own. In the package manager for operating system design that I had considered, this is also an issue that I had considered. A package can have multiple identifiers of any kinds. Additionally, there are other features of the operating system which can help many things. Hopefully, these things will be able avoid many kind of problems.

lordnacho 2y ago

Your main reply to "not invented here" is "okay, invent it here and maintain it here then, buddy". One of the key skills of a a senior dev is to be able to judge the tradeoff between rolling your own and borrowing someone else's. In your life as a dev you'll be making this choice all the time. The pros and cons are generic: time spent, potential bugs, security, free upgrades, specific vs general solutions, external reliance, and so on. But you will exercise this judgement constantly. Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP?

ironmagma 2y ago
The main reply was to use more things off the shelf, or at least be aware there is a business cost of not doing so. Ironically this blog post isn’t even targeted at developers but more management types, but it wouldn’t be life without being spectacularly wrong on HN and raked over the coals on it. In short though I agree it’s not like you can just use off the shelf for everything or that that is even a good idea to try as that has its own set of problems.
danielheath 2y ago
> Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP? As someone who has dabbled in lisp: IME, everything is easier - enough so that I more-often _consider_ inventing something that solves my subset of the problem. I suspect this contributes to the poor library availability situation (I understand that's improved markedly in recent years, but still).
jhbadger 2y ago
It's still somewhat common, but over the past couple of decades we've created package managers like QuickLisp that allow calling external dependencies in Common Lisp as easy as it is in Python (and even systems to allow us to interact with Python to get access to its ecosystem), plus a version of Common Lisp (Armed Bear Common Lisp) that runs on the JVM to get access to that ecosystem (not to mention the Lisp-adjacent language Clojure).

mihaaly 2y ago

The author generously omit the long jurney through the negative side of external dependencies. This is somewhat frivolous and too unbalanced to be reliable this way. The truth must be somewhere inbetween again.

mark_l_watson 2y ago

I feel like the author is perhaps making a valid criticism of Common Lisp that was only valid in ancient history. In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself. With the advent of Quicklisp, many repos on public services like GitHub, etc., it is now easy to find and use good libraries for Common Lisp. Of course there is a network effect: a language like Python is much more popular so there are many more libraries available. That said Common Lisp, Racket, and other Lisps all have good ecosystems and are fun and productive to use.

lispm 2y ago
> In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself. The early .com companies on the Internet were all deeply involved in Lisp/AI companies: Symbolics, BBN, Thinking Machines, MCC, Xerox, SRI, ...). Plus a bunch of universities (MIT had hundreds of networked machines running some Lisp, including Lisp Machines). Many of the R&D groups were on the Internet. Larger amounts of code were for example shared via tape. For example the Symbolics User Group already shared code. The CMU CL wrote their Lisp implementation as public domain and shared all their implementation code: Lisp, editor, UI, ... Lots of old code from that time is all collected in the CMU AI Archive, which was established early 90s: https://www.cs.cmu.edu/Groups/AI/0.html https://www.cs.cmu.edu/Groups/AI/0.html At that time a lot of new stuff was developed, like CLX, the X11 interface for Common Lisp. Every Lisper on X11 was using it. TI developed CLUE and CLIO on top of CLX. LispWorks developed their gui toolkit on top of CLUE and CLX. Sure, there were lone developers but Lisp in the 80s was widely used in universities and R&D. All were networked. MCC had 200 Lisp Machines in their network, IIRC. MIT more. SRI similar. Xerox. BBN even developed their own Lisp OS + machine. Symbolics had support for DECNET, TCP/IP, IBM Mainframes, ... The Common Lisp standard, developed in the 1980s was probably the first developed with heavy e-mail support. There was a lot of stuff shared.
- mark_l_watson 2y ago
  All true! In my case, except hearing about stuff at AAAI conferences, I was mostly ignorant of most of the projects you mentioned.

deleted 2y ago

[deleted]

recursivedoubts 2y ago

Compare and contrast with “the curse of JavaScript” which is the opposite problem of an explosion of dependencies and the management thereof. The business guys might not like it (“it’s too hard to replace engineers”) but, from a software engineering perspective, a tendency towards fewer dependencies is better for the system.

ironmagma 2y ago
This gets at an interesting nuance. The under-reliance on dependencies actually poses issues at a system level, not at an individual product level, which makes it hard to sell business types on the existence of the problem. Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know. The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.

neilv 2y ago

What about the curse of an entire field that's so systemically incompetent -- starting with how it hires, and therefore, now, how it trains -- that the field is incapable of (for example) building a system that's not riddled with security vulnerabilities, yet the field confidently churns out a flood of blog posts about best practices?

deleted 2y ago
[deleted]
ironmagma 2y ago
Yeah the entire field of tech is pretty broken. Is the solution supposed to be to not write about it?
klibertp 2y ago
> churns out a flood of blog posts about best practices? ...most of which are cargo-culting carbon-copies of "gurus" and "authorities" (and "Uncle Bob"). No critical thought in sight, but a lot of mental gymnastics to justify conclusions that don't follow from whatever was written above. The massive influx of poorly prepared junior programmers in the last decade doesn't help. Somehow, beginner programmers tend to overgeneralize from too narrow a perspective, leading to fallacious but firmly held beliefs. This is nothing new and happens to most beginners; the problem is that we're dealing with a massive wave of beginners that seems to be still gaining momentum instead of subsiding. One of the effects is that the experienced, mature programmers' voices are drowned in the noise, save for a few "gurus" who are often better writers than programmers. The whole field shunning its own history doesn't help either. The culture of moving fast created a misperception that things older than half a year have no value. Similarly, agile and co. made it so we live in perpetual "now," rarely considering the long-term consequences of our work. This leads to resume-driven development and contributes to enshitification of everything, yet nobody seems to realize there even is a problem, much less have any intention of fixing it. Honestly, I'm struggling to find my place in the field after two decades of coding.
- ironmagma 2y ago
  All the things you said about junior developers hold for senior developers too. This field of computer science is over a hundred years old, but we don’t (and can’t) treat it that way. The overgeneralization stems from having strong beliefs. Where do you get the idea we have a massive wall of beginners? Just a week ago was posted, “The End of Jr Engineers.”

neilv 2y ago

Imagine, one time, some writer, writing a short story of laying in bed with their sleeping spouse on a peaceful summer night, wrote wistfully of how they loved that their spouse's hair smelled faintly of citrus at that moment. And a blogger stumbled upon this piece, and decided there was a widespread problem with people rubbing oranges on their heads, and, further, with the general problem of the author's entire nationality of people, and that this urgently needed to be exposed to the public, in a patient explanatory blog post. Seeing this blog post, others, realizing that there's been a misunderstanding, but knowing more about that nation (and/or fruits, and/or hair care), than about PR damage control, proceeded to respond, with a flood of various corrections, all over the map. For example, "I prefer fresh-squeezed lemon, so long as you're careful to avoid traumatic brain injury." And "Those people are not that bad; the many stories of kidnappings are often exaggerations of muggings." In all seriousness. And anyone observing is thinking "I'm even more confused than before, but those people sure are defensive about whatever the heck ungodly things they're doing with fruits. It might be a nice place to visit, for a day trip, but I wouldn't want to live with those crazy fanatics."

ironmagma 2y ago
I think if I cared about damage control I would have deleted the article a long time ago as so many people have clearly missed the point of the post. Again I would never (and didn’t) draw an issue with an entire nationality of people squeezing oranges in their hair, particularly being an orange-squeezer myself. If anything, it would be better if almost everyone would be squeezing citrus in their hair every day, as we would more readily be able to point to the side effects associated with doing so without it seeming like an affront to one group of people. True, this analogy is confusing, but it’s also great that you created it.

diffxx 2y ago

This feels like an argument against learning how to play an instrument. Why would anyone do that when there are so many other highly skilled players out there?

ironmagma 2y ago
Learning an instrument is a great thing to do and I can highly recommend it. What I can't recommend is learning an instrument from scratch when you were hired to play that instrument in an orchestra, as you are being paid to play in the orchestra.