18 ms·

Common Lisp's block / return-from and unwind-protect

126 points by bshanks 3y ago

wait_a_minute 3y ago
Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compound/produce great code and great applications that much faster than other languages? (For web development primarily)
- rokkitmensch 3y ago
  Yes, building anything non-trivial in CL will show the discerning programmer that there is nothing new under the sun.
  - waynesonfire 3y ago
    Could you clarify what you mean by 'there is nothing new under the sun' when referring to programming with Common Lisp? Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms? Your comment left me with a strange sentiment. I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
    - phoe-krk 3y ago
      > Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms? Yes. See effect handlers for an example, which are making rounds around the programming world as of late. They are equivalent to the Lisp condition system, except formalized to work in strongly statically typed programming environments. > I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects. Sort of, lots of things have thankfully trickled from Lisps to other languages (including whole languages like Julia). The pleasant feeling of conversing with the language and programming bit by bit in it is hard to replicate with things like LSPs, though, since the implementation is always running in the background and programming in it is based on mutating it until it contains the program you seek.
      - valcron1000 3y ago
        > They are equivalent to the Lisp condition system Not exactly correct due to the lack of higher order effects (https://news.ycombinator.com/item?id=20513370 https://news.ycombinator.com/item?id=20513370), but the condition system is "good enough" for a lot of use cases
        phoe-krk 3y ago
        TIL. The way I understand it, that's because CL is not required to perform CPS on its code and no CL implementation exists that does it on its own.
    - corinroyal 3y ago
      > I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects. Indeed, Lisp is no longer as revelatory as it once was, since many innovations have been adopted, even surpassed in specific cases. Still, no other language gives you the total package. The environment is far more than the sum of its features list. CL just gets out of your way and allows you to think about problems not programming.
    - rokkitmensch 3y ago
      > might be redundant I'm also the kind of weirdo who thinks that the old and new testaments are baseline requirements for a human to be "literate" (along with Ovid and Aristophanes). Despite these works having been recycled a large number of times, the originals still bear close scrutiny. You'll never know what modern $proglang authors screwed up until you go back and read the fundamentals. For a concrete example, consider the Python module system, and the pirouettes you have to do to use it programmatically. Until you look at (just for example) how this works in CL and RS5/6S, you'll not have the context to readily apprehend the hack job in question (although if you have a modicum of taste you may wrinkle your nose regardless). It'll also give you a good feel for what the true inventions have been since the early nineties.
      - lenkite 3y ago
        Could you summarize what is great about the CL module system ? How does it compare to other languages like Rust/Go ?
        rokkitmensch 3y ago
        Runtime access to read and redefine namespaces and their contents at whim. Similarly powerful to having the compiler available at runtime, another thing trickling very slowly into mainstream languages. "But why would you want this?! That sounds dangerous!" It's quite dangerous, but so is a 700cc dirt bike. "Can you give me any practical reason you'd want this?" Aside from the freedom to redefine other folks' code (see: the derogatory term "monkeypatching"), you can leverage runtime namespace access and manipulation to, when loading a "fasl" into a running Lisp image, identify all classes that you care about and then upgrade them to new definitions without restarting the Lisp process. Most mainstream languages completely punt on "deployment" (PHP [accidentally] aside, where you can joyfully edit production all day, a paradigm too many folks sneer at in the name of cargo cult professionalism), forcing the system operator to restart the process with new binaries (or pycs, whatever, I'm sure you can generalize the point). A CL system supports that model, of course, but one can also precompile binaries to be loaded into the running system, redefining system behavior without downtime. Binaries, we should note, that don't include the entire Lisp runtime. It's not that this provides some sort of day-to-day omg ergonomic bonus over the popular Algol families, but that I feel respected as a software author in a Lisp context in a way that I really don't in many other contexts ("nobody needs generics", to pick on some old low-hanging fruit), and the language providing interfaces to itself in itself is a delightfully low-friction cognitive model. To return to the dirt bike analogy, I could prattle all day about this, but unless you're the kind of person inclined to spend five hours a week learning to enjoy riding dirtbikes, I don't know that I can spill enough ink to convey the fun of managing a few hundred cc's around the track at speed. Countersteering, inertia management, traction, all of these things are going to go over your head if your idea of a fun time with motive power is a Rivian.
  - pjmlp 3y ago
    Except the little detail that JIT/AOT toolchains still aren't as widespread as they should be, with several languages offering only one variant, and there as still quite a few Lisp tricks either left behind in modern IDEs, or with various kinds of support depending on the language, like accessing everything across language and runtime, hot code reloading, time travel debugging. Ah, and most relevant, many folks still believe that writing OSes in what was once a macro Assember for PDP-11 is the only way.
- corinroyal 3y ago
  I'm learning programming at age fifty-four and have chosen Common Lisp as my one language for life. If you want something easy to learn with a ton of support pick Python, Elixir, and/or JS. CL sucks for mini-projects since the learning curve requires serious commitment and is SO different from what people are used to. CL requires a long-term commitment and demands the programmer challenge pop programming trends and deeply entrenched styles. You have to think beyond today to what could be and what once was. But if you're willing to do that, there is no better language. Not Haskell, not OCamel, not Rust/Go/Julia/Clojure/Scheme, or the current lang du jour. Whatever limitations Common Lisp had in the past are long gone. SBCL is blazingly fast, CL abstractions are profound yet practical. The type system gives you power without pettiness. Language-oriented programming is a superpower in a world of cut and paste library-oriented programming. Image-based computing often allows one to skip the impedance mismatch with DBs. In many cases and you can just persist the data structures as they are or serialize them where needed. The tooling with Roswell, Quicklisp, Qlot, Doom Emacs, and Sly make prototyping and exploratory programming wiz by. CLOG, Reblocks and Hunchentoot provide powerful abstractions for web programming, but Phoenix with Liveview is probably better for most. The debugging experience is so insanely powerful it freaks me out and makes other systems look rudimentary. CLOS, the object system, is best of breed and makes most of the standard criticisms of OO programming moot. The homoiconic list-based syntax and prefix notation are beautiful and never get in your way. Parentheses are invisible. The condition system makes flow control and error handling in other systems seem rigid and convoluted. Aspect-oriented programming is just what we do, not a thing tacked on. Macros and the meta-object protocol allow you to build a language on top of Lisp that allows users to conceptualize problems using nouns and verbs they already know. Drop into Coalton or Shen for strong, static typing where necessary, or April (hosted APL) for array wizardry that makes NumPy look like data-flow programming in Basic on a Timex Sinclair with a cassette drive. You can slice and dice whole datasets in a few characters of code. Bundle existing C libs with CFFI when you find a good one you need. Lisp-based systems are alive and grow and change as requirements do. It's harder to program yourself into a corner. Refactoring is continuous and mundane. In-source documentation is the right place for it, but Lispers tend to be shamefully lax in providing it. Shaaame! Newer Lispers tend to be better about docs--the culture is changing. Often you ask a question and get no response. Other times you get a detailed response from a legendary mind and just sit there in awe working your way through their thinking and feeling your inadequacy. The code is about as succinct as it can be to maintain readability. There are two camps on readability, some experienced Lispers find it harder, and most find it much easier to parse than ALGOL-derived syntax. Once mastered, quick things are quick, hard things are straightforward, and impossible things are doable. This is a system for people who need, not want, to change the world. It gives single programmers and small teams the power to take on armies of bureaucratic programmers. But you have to be willing to break the mold, handle charges of elitism, not be required to justify your choice to managers, tolerate a small hiring pool, train newbies hard and long, not get freaked out using some libs that are stable and haven't been updated in years, deal with the pace of development of a small community, have the patience and joy in problem-solving to handle frequent bafflement, read a ton of source code rather than search the forums, and be willing to roll your own when needed. If you can handle all the idiosyncrasies and have a burning need for elegance and power, then CL will reward and surprise into until dementia takes you. In short, all the good things you've heard are true, many of the standard critiques are uninformed, and problems people talk about that apply to most languages often don't apply.
- tiberius_p 3y ago
  Lisp is great for creating your own domain specific languages. S-expressions are basically abstract syntax trees written as code. Thus you can take any code written in any language and "lispify" it into an S-expression. Then you can apply various transformations/analyses on this expression to achieve various goals:linting, semantic modeling, compiling to machine code/bytecode, transpiling to another laguage, interpreting, optimizing, etc. Common Lisp also has the possibility of on-the-fly recompilation of classes and methods/functions which can be useful for debug and incremental development.I don't have much experience in the web development area but I would incline to think that you won't get much added value from using CL compared to other languages/frameworks. It can be useful if you want to develop your own framework with custom language constructs and features. But if you want to fast prototype a webapp idea you're better off trying the more popular solutions.
- f1shy 3y ago
  Not so recent, about 6 years ago, I had to communicate with many instruments (PS, Oscilloscope, SMU, etc) to test a new ASIC we developed. There where hundreds of tests to be done. We wanted to automate the measurement and evaluation of results, because they were so many. Also there where 5 fabs and 2 suppliers with different design, but “pin compatible”. I did the whole framework in emacs lisp, I had to implement ONC RPC and LXI on top to speak to the instruments… The whole thing took me 2 weeks. At the time I had no idea of Elisp; only a little vit of scheme. I was proficient in C, and I would say it had taken me at least 6 Months to do the same
- worthless-trash 3y ago
  I've written a few small CL web applications( with about 100 users active a day), along with a few terminal applications (with only ~10 users). Other languages I know is C , Erlang, Elixir and a bit of python. This will end up sounding a bit evangelical but so be it. I feel that the lisp code was easier to write and reason about, the being able to hot reload code from the repl significantly decreased the time to completion. I also 'connect' to a networked repl when sentry reports an unhandled error to figure out what has gone wrong. You might be tempted to believe that CL repl is "similar enough" to python's repl, however this is NOT the case. Being able to redefine functions, variables and macros while working on the code (without a restart) allows you to deal with errors. The syntax is a 'no brainer', Extreme consistency in function calls means that you don't need to think about it. Other languages which SOMETIMES use infix, sometimes require brackets, that is just crazy. Lisp libraries have less churn than 'modern languages', some libraries have not been touched for some time, unlike python/ruby/js. The code does not seem to rot and old lisp code runs on modern implementations. I work in emacs, lem, I know people who use vscode and alive, and vim. There is no 'hard' requirement to use emacs, you will get by as long as you have 'emacs like' repl integration. All in all, I do not regret working in lisp. It doesn't have the cult of the other languages and I'm fine with that.
  - msk-lywenn 3y ago
    I'd rather say there is a definite cult over lisp. But it's very different from the other languages which I'd qualify as rather hardcore. Lisp's cult is a magical cult. No other language as such amazing stories as the space probe remotely debugged from earth with a repl, the extreme hot reload and mystical intertwining of assembly on PS2 of Jak & Daxter's GOAL, the MIT course with a Fantasia level of teaching, The symbolic machines, etc. The only other language like that I can think of is smalltalk.
  - kagevf 3y ago
    When do you work in emacs vs lem?
    - worthless-trash 3y ago
- vindarel 3y ago
  I use a couple web apps in production©. The development experience is awesome, deployment is easy, the runtime is fast, the language and the ecosystem are stable. CL being CL, you get many errors, including type errors, at compile time (hitting C-c C-c, the feedback is instantaneous). You have less needs for stupid unit tests. My Sentry dashboard is empty :) Coming from Python I appreciate all that. We have a choice of libraries, but no big batteries-included web framework, so you must be ready to assemble pieces (or simply, to know web development). Ex: a login system? There are examples to look at, not a use-and-forget library. A CL webserver coupled with a client library like HTMX is great. I don't recommend Reblocks (weblocks) or CLOG yet for serious stuff. resources: the Cookbook, my lisp-journey #web content, my last youtube video (@vindarel channel).
  - wait_a_minute 3y ago
    Thank you very much for referencing your latest video, I'm watching it and glad to have such a timely example of what the development process can actually look like for CL web applications. Really cool stuff, will subscribe. :)
pfdietz 3y ago
Block/return-from is a lexical transfer of control that can be non-local (you can transfer out of a lambda or defun to an enclosing scope). For the dynamic equivalent there's catch/throw. Both transfers activate unwind-protect if they unwind the stack through it.
- brabel 3y ago
  One of the only languages where I saw this non-local returns is Kotlin. You can return from a function from within a lambda (and I believe this works on any number of levels), for example: fun go(list: List<String>): Boolean { list.forEach { if (it.isEmpty()) return@go true } return false }
  - gpderetta 3y ago
    Longjmp in standard C, swapcontext in POSIX C. I think GCC allows gotos to the containing function from a local function (but I never used GCC local functions). Smalltalk, and I believe ruby, allow non local return from blocks.
    - gumby 3y ago
      longjmp simply restores the machine registers (including PC and SP) and thus doesn’t respect any sort of unwind-protect, a concept unknown in C. unwind-protect is a more general form of the c++ raii (in fact c++ got raii from Common Lisp).
      - Findecanor 3y ago
        `longjmp` does not restore the machine registers on all platforms. The C standard guarantees only the contents of variables marked `volatile`: anything above that is implementation-dependent. I think that MSVC++ longjmp actually does proper unwinding, calling destructors in C++ functions on the stack, but don't quote me on that. I think it is also dependent on the compiler flags.
      - gpderetta 3y ago
formerly_proven 3y ago
Is Common Lisp the first kitchen sink language (ala C++)? It always seems to me like there's a lot of "Oh yeah, Common Lisp has a feature for this, too"-type blog posts, though very little about actual usage of it.
- pjmlp 3y ago
  Common Lisp is the uniformization of what Lisp Machines across Genera, TI, and Xerox PARC (although Interlisp-D was a different species) were offering for a full graphics workstation, alongside other systems. It was as kitchen sink as having POSIX (basically a full blown UNIX specification), to be expected to fill in the stuff missing from ISO C standard library.
- int_19h 3y ago
  It's a rather subjective assessment. ALGOL 68 and PL/I were apparently considered rather "kitchen sink" by the standards of their time.

126 points by bshanks 3y ago

Gah, another Lisp post to tempt me to add yet another mini project to my plate...I always am curious about trying more Lisp because I keep seeing commentary about how powerful it is to actually build applications once you get moving on building things. Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compound/produce great code and great applications that much faster than other languages? (For web development primarily)

rokkitmensch 3y ago
Yes, building anything non-trivial in CL will show the discerning programmer that there is nothing new under the sun.
- waynesonfire 3y ago
  Could you clarify what you mean by 'there is nothing new under the sun' when referring to programming with Common Lisp? Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms? Your comment left me with a strange sentiment. I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
  - phoe-krk 3y ago
    > Are you indicating that Lisp has already introduced many of the concepts and features that are now found in modern programming languages, implying that contemporary languages have largely assimilated Lisp's ideas and paradigms? Yes. See effect handlers for an example, which are making rounds around the programming world as of late. They are equivalent to the Lisp condition system, except formalized to work in strongly statically typed programming environments. > I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects. Sort of, lots of things have thankfully trickled from Lisps to other languages (including whole languages like Julia). The pleasant feeling of conversing with the language and programming bit by bit in it is hard to replicate with things like LSPs, though, since the implementation is always running in the background and programming in it is based on mutating it until it contains the program you seek.
    - valcron1000 3y ago
      > They are equivalent to the Lisp condition system Not exactly correct due to the lack of higher order effects (https://news.ycombinator.com/item?id=20513370 https://news.ycombinator.com/item?id=20513370), but the condition system is "good enough" for a lot of use cases
      - phoe-krk 3y ago
        TIL. The way I understand it, that's because CL is not required to perform CPS on its code and no CL implementation exists that does it on its own.
  - corinroyal 3y ago
    > I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects. Indeed, Lisp is no longer as revelatory as it once was, since many innovations have been adopted, even surpassed in specific cases. Still, no other language gives you the total package. The environment is far more than the sum of its features list. CL just gets out of your way and allows you to think about problems not programming.
  - rokkitmensch 3y ago
    > might be redundant I'm also the kind of weirdo who thinks that the old and new testaments are baseline requirements for a human to be "literate" (along with Ovid and Aristophanes). Despite these works having been recycled a large number of times, the originals still bear close scrutiny. You'll never know what modern $proglang authors screwed up until you go back and read the fundamentals. For a concrete example, consider the Python module system, and the pirouettes you have to do to use it programmatically. Until you look at (just for example) how this works in CL and RS5/6S, you'll not have the context to readily apprehend the hack job in question (although if you have a modicum of taste you may wrinkle your nose regardless). It'll also give you a good feel for what the true inventions have been since the early nineties.
    - lenkite 3y ago
      Could you summarize what is great about the CL module system ? How does it compare to other languages like Rust/Go ?
      - rokkitmensch 3y ago
        Runtime access to read and redefine namespaces and their contents at whim. Similarly powerful to having the compiler available at runtime, another thing trickling very slowly into mainstream languages. "But why would you want this?! That sounds dangerous!" It's quite dangerous, but so is a 700cc dirt bike. "Can you give me any practical reason you'd want this?" Aside from the freedom to redefine other folks' code (see: the derogatory term "monkeypatching"), you can leverage runtime namespace access and manipulation to, when loading a "fasl" into a running Lisp image, identify all classes that you care about and then upgrade them to new definitions without restarting the Lisp process. Most mainstream languages completely punt on "deployment" (PHP [accidentally] aside, where you can joyfully edit production all day, a paradigm too many folks sneer at in the name of cargo cult professionalism), forcing the system operator to restart the process with new binaries (or pycs, whatever, I'm sure you can generalize the point). A CL system supports that model, of course, but one can also precompile binaries to be loaded into the running system, redefining system behavior without downtime. Binaries, we should note, that don't include the entire Lisp runtime. It's not that this provides some sort of day-to-day omg ergonomic bonus over the popular Algol families, but that I feel respected as a software author in a Lisp context in a way that I really don't in many other contexts ("nobody needs generics", to pick on some old low-hanging fruit), and the language providing interfaces to itself in itself is a delightfully low-friction cognitive model. To return to the dirt bike analogy, I could prattle all day about this, but unless you're the kind of person inclined to spend five hours a week learning to enjoy riding dirtbikes, I don't know that I can spill enough ink to convey the fun of managing a few hundred cc's around the track at speed. Countersteering, inertia management, traction, all of these things are going to go over your head if your idea of a fun time with motive power is a Rivian.
- pjmlp 3y ago
  Except the little detail that JIT/AOT toolchains still aren't as widespread as they should be, with several languages offering only one variant, and there as still quite a few Lisp tricks either left behind in modern IDEs, or with various kinds of support depending on the language, like accessing everything across language and runtime, hot code reloading, time travel debugging. Ah, and most relevant, many folks still believe that writing OSes in what was once a macro Assember for PDP-11 is the only way.
corinroyal 3y ago
I'm learning programming at age fifty-four and have chosen Common Lisp as my one language for life. If you want something easy to learn with a ton of support pick Python, Elixir, and/or JS. CL sucks for mini-projects since the learning curve requires serious commitment and is SO different from what people are used to. CL requires a long-term commitment and demands the programmer challenge pop programming trends and deeply entrenched styles. You have to think beyond today to what could be and what once was. But if you're willing to do that, there is no better language. Not Haskell, not OCamel, not Rust/Go/Julia/Clojure/Scheme, or the current lang du jour. Whatever limitations Common Lisp had in the past are long gone. SBCL is blazingly fast, CL abstractions are profound yet practical. The type system gives you power without pettiness. Language-oriented programming is a superpower in a world of cut and paste library-oriented programming. Image-based computing often allows one to skip the impedance mismatch with DBs. In many cases and you can just persist the data structures as they are or serialize them where needed. The tooling with Roswell, Quicklisp, Qlot, Doom Emacs, and Sly make prototyping and exploratory programming wiz by. CLOG, Reblocks and Hunchentoot provide powerful abstractions for web programming, but Phoenix with Liveview is probably better for most. The debugging experience is so insanely powerful it freaks me out and makes other systems look rudimentary. CLOS, the object system, is best of breed and makes most of the standard criticisms of OO programming moot. The homoiconic list-based syntax and prefix notation are beautiful and never get in your way. Parentheses are invisible. The condition system makes flow control and error handling in other systems seem rigid and convoluted. Aspect-oriented programming is just what we do, not a thing tacked on. Macros and the meta-object protocol allow you to build a language on top of Lisp that allows users to conceptualize problems using nouns and verbs they already know. Drop into Coalton or Shen for strong, static typing where necessary, or April (hosted APL) for array wizardry that makes NumPy look like data-flow programming in Basic on a Timex Sinclair with a cassette drive. You can slice and dice whole datasets in a few characters of code. Bundle existing C libs with CFFI when you find a good one you need. Lisp-based systems are alive and grow and change as requirements do. It's harder to program yourself into a corner. Refactoring is continuous and mundane. In-source documentation is the right place for it, but Lispers tend to be shamefully lax in providing it. Shaaame! Newer Lispers tend to be better about docs--the culture is changing. Often you ask a question and get no response. Other times you get a detailed response from a legendary mind and just sit there in awe working your way through their thinking and feeling your inadequacy. The code is about as succinct as it can be to maintain readability. There are two camps on readability, some experienced Lispers find it harder, and most find it much easier to parse than ALGOL-derived syntax. Once mastered, quick things are quick, hard things are straightforward, and impossible things are doable. This is a system for people who need, not want, to change the world. It gives single programmers and small teams the power to take on armies of bureaucratic programmers. But you have to be willing to break the mold, handle charges of elitism, not be required to justify your choice to managers, tolerate a small hiring pool, train newbies hard and long, not get freaked out using some libs that are stable and haven't been updated in years, deal with the pace of development of a small community, have the patience and joy in problem-solving to handle frequent bafflement, read a ton of source code rather than search the forums, and be willing to roll your own when needed. If you can handle all the idiosyncrasies and have a burning need for elegance and power, then CL will reward and surprise into until dementia takes you. In short, all the good things you've heard are true, many of the standard critiques are uninformed, and problems people talk about that apply to most languages often don't apply.
tiberius_p 3y ago
Lisp is great for creating your own domain specific languages. S-expressions are basically abstract syntax trees written as code. Thus you can take any code written in any language and "lispify" it into an S-expression. Then you can apply various transformations/analyses on this expression to achieve various goals:linting, semantic modeling, compiling to machine code/bytecode, transpiling to another laguage, interpreting, optimizing, etc. Common Lisp also has the possibility of on-the-fly recompilation of classes and methods/functions which can be useful for debug and incremental development.I don't have much experience in the web development area but I would incline to think that you won't get much added value from using CL compared to other languages/frameworks. It can be useful if you want to develop your own framework with custom language constructs and features. But if you want to fast prototype a webapp idea you're better off trying the more popular solutions.
f1shy 3y ago
Not so recent, about 6 years ago, I had to communicate with many instruments (PS, Oscilloscope, SMU, etc) to test a new ASIC we developed. There where hundreds of tests to be done. We wanted to automate the measurement and evaluation of results, because they were so many. Also there where 5 fabs and 2 suppliers with different design, but “pin compatible”. I did the whole framework in emacs lisp, I had to implement ONC RPC and LXI on top to speak to the instruments… The whole thing took me 2 weeks. At the time I had no idea of Elisp; only a little vit of scheme. I was proficient in C, and I would say it had taken me at least 6 Months to do the same
worthless-trash 3y ago
I've written a few small CL web applications( with about 100 users active a day), along with a few terminal applications (with only ~10 users). Other languages I know is C , Erlang, Elixir and a bit of python. This will end up sounding a bit evangelical but so be it. I feel that the lisp code was easier to write and reason about, the being able to hot reload code from the repl significantly decreased the time to completion. I also 'connect' to a networked repl when sentry reports an unhandled error to figure out what has gone wrong. You might be tempted to believe that CL repl is "similar enough" to python's repl, however this is NOT the case. Being able to redefine functions, variables and macros while working on the code (without a restart) allows you to deal with errors. The syntax is a 'no brainer', Extreme consistency in function calls means that you don't need to think about it. Other languages which SOMETIMES use infix, sometimes require brackets, that is just crazy. Lisp libraries have less churn than 'modern languages', some libraries have not been touched for some time, unlike python/ruby/js. The code does not seem to rot and old lisp code runs on modern implementations. I work in emacs, lem, I know people who use vscode and alive, and vim. There is no 'hard' requirement to use emacs, you will get by as long as you have 'emacs like' repl integration. All in all, I do not regret working in lisp. It doesn't have the cult of the other languages and I'm fine with that.
- msk-lywenn 3y ago
  I'd rather say there is a definite cult over lisp. But it's very different from the other languages which I'd qualify as rather hardcore. Lisp's cult is a magical cult. No other language as such amazing stories as the space probe remotely debugged from earth with a repl, the extreme hot reload and mystical intertwining of assembly on PS2 of Jak & Daxter's GOAL, the MIT course with a Fantasia level of teaching, The symbolic machines, etc. The only other language like that I can think of is smalltalk.
- kagevf 3y ago
  When do you work in emacs vs lem?
  - worthless-trash 3y ago
vindarel 3y ago
I use a couple web apps in production©. The development experience is awesome, deployment is easy, the runtime is fast, the language and the ecosystem are stable. CL being CL, you get many errors, including type errors, at compile time (hitting C-c C-c, the feedback is instantaneous). You have less needs for stupid unit tests. My Sentry dashboard is empty :) Coming from Python I appreciate all that. We have a choice of libraries, but no big batteries-included web framework, so you must be ready to assemble pieces (or simply, to know web development). Ex: a login system? There are examples to look at, not a use-and-forget library. A CL webserver coupled with a client library like HTMX is great. I don't recommend Reblocks (weblocks) or CLOG yet for serious stuff. resources: the Cookbook, my lisp-journey #web content, my last youtube video (@vindarel channel).
- wait_a_minute 3y ago
  Thank you very much for referencing your latest video, I'm watching it and glad to have such a timely example of what the development process can actually look like for CL web applications. Really cool stuff, will subscribe. :)

pfdietz 3y ago

Block/return-from is a lexical transfer of control that can be non-local (you can transfer out of a lambda or defun to an enclosing scope). For the dynamic equivalent there's catch/throw. Both transfers activate unwind-protect if they unwind the stack through it.

brabel 3y ago
One of the only languages where I saw this non-local returns is Kotlin. You can return from a function from within a lambda (and I believe this works on any number of levels), for example: fun go(list: List<String>): Boolean { list.forEach { if (it.isEmpty()) return@go true } return false }
- gpderetta 3y ago
  Longjmp in standard C, swapcontext in POSIX C. I think GCC allows gotos to the containing function from a local function (but I never used GCC local functions). Smalltalk, and I believe ruby, allow non local return from blocks.
  - gumby 3y ago
    longjmp simply restores the machine registers (including PC and SP) and thus doesn’t respect any sort of unwind-protect, a concept unknown in C. unwind-protect is a more general form of the c++ raii (in fact c++ got raii from Common Lisp).
    - Findecanor 3y ago
      `longjmp` does not restore the machine registers on all platforms. The C standard guarantees only the contents of variables marked `volatile`: anything above that is implementation-dependent. I think that MSVC++ longjmp actually does proper unwinding, calling destructors in C++ functions on the stack, but don't quote me on that. I think it is also dependent on the compiler flags.
    - gpderetta 3y ago

formerly_proven 3y ago

Is Common Lisp the first kitchen sink language (ala C++)? It always seems to me like there's a lot of "Oh yeah, Common Lisp has a feature for this, too"-type blog posts, though very little about actual usage of it.

pjmlp 3y ago
Common Lisp is the uniformization of what Lisp Machines across Genera, TI, and Xerox PARC (although Interlisp-D was a different species) were offering for a full graphics workstation, alongside other systems. It was as kitchen sink as having POSIX (basically a full blown UNIX specification), to be expected to fill in the stuff missing from ISO C standard library.
int_19h 3y ago
It's a rather subjective assessment. ALGOL 68 and PL/I were apparently considered rather "kitchen sink" by the standards of their time.