3 ms·

I think this is the perfect opinion to have for a middle manager at a large FAANG with seemingly infinite developer supply and little existential incentive to i

I think this is the perfect opinion to have for a middle manager at a large FAANG with seemingly infinite developer supply and little existential incentive to innovate. In practice, C++ and Python codebases have insane amounts of churn. They're constantly moving targets and require a lot of overhead to keep in shape, from just about every perspective: performance, security, maintainability, implementation compatibility, etc. It's tolerated though because it's standard practice, and we developers get a paycheck anyway. Languages like OCaml, Common Lisp, Haskell, and other niche but obviously practical languages continue to be indispensable to certain cohorts of companies and developers. While I do agree that Lisp specifically peaked in popularity decades ago, it still exists in the commercial domain with resounding staying power, even in environments where it could in theory be replaced by C++ or Python. It's also abundantly clear there's a hunger for new (or at least replacement) languages for the stalwarts. Rust, Julia, Mojo, Swift, and OCaml are a few such languages that get attention in their commercial investment and development, often with the specific purpose of replacing Python or C++. As a personal anecdote, I find professional Common Lisp programmers generally to be quite sensitive to matters of bloat. Some programmers go as far to chisel away needless cons cells (or allocation in general), and constantly be in touch with the compiled assembly—something frequently ignored by professional C++ programmers of comparable experience. I would love to hear the "very sound technical reasons" explaining Common Lisp's obscurity. Given the vast and diverse biome of programming languages in use today, including and especially in professional settings, I'm quite interested in understanding what technical reasons uniquely relegate Lisp to obscurity.

perrygeo 3y ago
My take (not OP) is that it's not so much the technical features of Lisp itself, but the fact that other languages evolved competing features. Over the years, they have slowly chipped away at Lisp's advantages. 50 years ago, Lisp was uniquely powerful with no rival. Today, Lisp is yet-another powerful language to choose from.
- vindarel 3y ago
  I disagree: Common Lisp has many remaining powerful features AND a large set of them, when a language maybe caught up with one. The interactive debugger is unmatched, image-based development nearly doesn't exist elsewhere, the condition system… Example: fix a bug without quitting the debugger, re-compile the fixed function with one keystroke (instant feedback), go back to the debugger, choose a stack frame to resume execution from, see the execution pass. You didn't re-run everything from zero. SBCL has pretty good type inference at a keytstroke (not complete, but useful, for a Haskell on top of CL see Coalton), it's fast, different implementations, stability…
  - deleted 2y ago
    [deleted]
deleted 3y ago
[deleted]
bitwize 3y ago
> As a personal anecdote, I find professional Common Lisp programmers generally to be quite sensitive to matters of bloat. Some programmers go as far to chisel away needless cons cells (or allocation in general), and constantly be in touch with the compiled assembly—something frequently ignored by professional C++ programmers of comparable experience. C++ and Rust programmers usually don't have to go down into the assembly. The language itself provides fine-grained control over when and how allocations take place, and how memory is laid out. It's a doddle to establish efficient allocation patterns and lay out memory to take advantage of locality of reference so you don't blow up your data cache. Lisp, not so much; in addition to the pointer-heavy semantics of Lisp objects you have the inherent nondeterminism of a GC. So not surprising that when a Lisp program stutters or hangs, the programmer has to go down to assembly level to determine the memory usage pattern that's causing the slowdown. With C++ or Rust, the memory usage patterns are (usually) obvious from the code itself. > I would love to hear the "very sound technical reasons" explaining Common Lisp's obscurity. * Lisp is dynamically typed. Yes, I know Common Lisp allows for type annotations, but the type system is just barely enough to enable speed hacks in the compiler; it is neither sound nor robust when compared to, say, fully parametric type systems (now commonplace in blub languages like C# and TypeScript). The lesson of the past couple decades or so is that strong, static typing is an unmitigated win, especially when building large systems; to choose dynamic typing in 2024 is to forgo early checking of all sorts of bugs. * GC. You will incur a performance and memory consumption penalty using a GC'd language, an in this day and age with RAII and ARC, those are penalties you need not incur in order to safely, conveniently use memory within deterministic space and time constraints. With languages like Rust we can get the same kinds of advantages with static lifetimes that we do with static types. There is no need to defer object lifetime management to runtime; and to do so just wastes electricity and contributes to climate change. * The syntax. Programmers are not just annoyed by all the parens. Today, they're used to being able to get a list of all the methods valid on a given object by typing '.' after the object's name. You need a certain kind of syntax to do that, plus static typing, and Lisp eschews both. * Lispers wax nostalgic for the Lisp machines, which were pretty groundbreaking in their day... but as the sibling to my comment points out, the tooling for other languages has caught up if not surpassed the best Lisp development environments since. Microsoft has had edit and continue in its IDEs since decades ago; I believe Eclipse got something similar later. Modern refactoring tools. Project Lombok. There has been a lot of research done into how to improve the developer experience in practical languages. Meanwhile, Lispers are still recommending frickin' Emacs to beginners. * Plus, the library support for practical languages like Java, JavaScript, Python, or C# -- or even C++ -- is just so much better than what's available for Common Lisp.

perrygeo 3y ago

My take (not OP) is that it's not so much the technical features of Lisp itself, but the fact that other languages evolved competing features. Over the years, they have slowly chipped away at Lisp's advantages. 50 years ago, Lisp was uniquely powerful with no rival. Today, Lisp is yet-another powerful language to choose from.

vindarel 3y ago
I disagree: Common Lisp has many remaining powerful features AND a large set of them, when a language maybe caught up with one. The interactive debugger is unmatched, image-based development nearly doesn't exist elsewhere, the condition system… Example: fix a bug without quitting the debugger, re-compile the fixed function with one keystroke (instant feedback), go back to the debugger, choose a stack frame to resume execution from, see the execution pass. You didn't re-run everything from zero. SBCL has pretty good type inference at a keytstroke (not complete, but useful, for a Haskell on top of CL see Coalton), it's fast, different implementations, stability…
- deleted 2y ago
  [deleted]

deleted 3y ago

[deleted]

bitwize 3y ago

> As a personal anecdote, I find professional Common Lisp programmers generally to be quite sensitive to matters of bloat. Some programmers go as far to chisel away needless cons cells (or allocation in general), and constantly be in touch with the compiled assembly—something frequently ignored by professional C++ programmers of comparable experience. C++ and Rust programmers usually don't have to go down into the assembly. The language itself provides fine-grained control over when and how allocations take place, and how memory is laid out. It's a doddle to establish efficient allocation patterns and lay out memory to take advantage of locality of reference so you don't blow up your data cache. Lisp, not so much; in addition to the pointer-heavy semantics of Lisp objects you have the inherent nondeterminism of a GC. So not surprising that when a Lisp program stutters or hangs, the programmer has to go down to assembly level to determine the memory usage pattern that's causing the slowdown. With C++ or Rust, the memory usage patterns are (usually) obvious from the code itself. > I would love to hear the "very sound technical reasons" explaining Common Lisp's obscurity. * Lisp is dynamically typed. Yes, I know Common Lisp allows for type annotations, but the type system is just barely enough to enable speed hacks in the compiler; it is neither sound nor robust when compared to, say, fully parametric type systems (now commonplace in blub languages like C# and TypeScript). The lesson of the past couple decades or so is that strong, static typing is an unmitigated win, especially when building large systems; to choose dynamic typing in 2024 is to forgo early checking of all sorts of bugs. * GC. You will incur a performance and memory consumption penalty using a GC'd language, an in this day and age with RAII and ARC, those are penalties you need not incur in order to safely, conveniently use memory within deterministic space and time constraints. With languages like Rust we can get the same kinds of advantages with static lifetimes that we do with static types. There is no need to defer object lifetime management to runtime; and to do so just wastes electricity and contributes to climate change. * The syntax. Programmers are not just annoyed by all the parens. Today, they're used to being able to get a list of all the methods valid on a given object by typing '.' after the object's name. You need a certain kind of syntax to do that, plus static typing, and Lisp eschews both. * Lispers wax nostalgic for the Lisp machines, which were pretty groundbreaking in their day... but as the sibling to my comment points out, the tooling for other languages has caught up if not surpassed the best Lisp development environments since. Microsoft has had edit and continue in its IDEs since decades ago; I believe Eclipse got something similar later. Modern refactoring tools. Project Lombok. There has been a lot of research done into how to improve the developer experience in practical languages. Meanwhile, Lispers are still recommending frickin' Emacs to beginners. * Plus, the library support for practical languages like Java, JavaScript, Python, or C# -- or even C++ -- is just so much better than what's available for Common Lisp.