4 ms·

I’ve never written in lisp, and my lack of knowledge of it always makes me feel a bit of respect towards people who do. Like maybe it’s this amazing thing that

I’ve never written in lisp, and my lack of knowledge of it always makes me feel a bit of respect towards people who do. Like maybe it’s this amazing thing that if I was smart enough to understand, I would achieve transcendence, or something. But the biggest thing I look for in a programming language, is “how many bugs can it stop me from writing”, and a lack of any compile time checking is what keeps me from even bothering to look at it. I’ve spent many years programming in perl, then ruby, before finally using Go and then Java and then Typescript and now Swift, and I feel like the period of time where I would tolerate a lack compile-time type checks is gone. It’s just table stakes at this point. Maybe lisp is the end game for non-type-checked languages and it’s the best a dynamic language can hope to be. But I just don’t care at this point, because that whole category of languages seems to be a broken idea to me at this point.

_bxg1 7y ago
I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. You can't rely on interfaces; you have to fully hold everything in your mental model. When this is feasible - usually meaning that you or a small cohesive team wrote all of it yourselves - the tradeoff is a huge amount of expressiveness. The barriers between the program in your mind and the program in the code get very small, and you can just make things, concisely, unhindered. This is all well and good, but expressiveness tends to be at odds with constraints, safety, and team communication. Lisp is just one extreme of that spectrum. Personally I feel better having some of those constraints even on throwaway solo projects, though that might not be perfectly rational. I will also say that Clojure's heavy focus on immutable data helps somewhat with this problem. You can at least count on functions not having side-effects. Usually. Hopefully.
- flavio81 7y ago
  >I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. That's FUD. Just make your code modular. Lisp gives you tools: namespaces, and systems. >You can at least count on functions not having side-effects. The great majority of functions in Lisp don't mutate data.
flavio81 7y ago
>and a lack of any compile time checking is what keeps me from even bothering to look at it. Common Lisp more than compensates due to some key features: 1. any bug can be corrected at runtime without having to stop the program 2. the type system is completely strong, not weak 3. it actually has a pretty nice type system. 4. the conditions-restart exception handling system is world-class
- _bxg1 7y ago
  > it actually has a pretty nice type system Not by default. And herein lies the core social problem with Lisp: [new/non-lisp programmers]: Lisp doesn't have X! [lisp programmers]: Just make your own X! Lisp is extensible! Or pick from the twelve implementations already out there! Here's the thing: probably all of those implementations are going to be half-baked. And good luck finding editor support for the one you end up going with when there's no standard to rally around. And have fun re-learning the nuances of basic language features every time you join a new team. A simple core language does not mean simple code: http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
  - vindarel 7y ago
    > > it actually has a pretty nice type system > Not by default > Or pick from the twelve implementations already out there! Just pick SBCL!
- oblio 7y ago
  > 1. any bug can be corrected at runtime without having to stop the program Can you do this in an automatable and testable way? I.e. can you provide a migration script as part of an automated deployment to an Ops team?
  - vindarel 7y ago
    Hello late. Do you mean can we script the hot reload? Yes, here's a quick link: https://lispcookbook.github.io/cl-cookbook/web.html#hot-reload https://lispcookbook.github.io/cl-cookbook/web.html#hot-relo... you basically start a Swank server on the running app, connect to it from your machine, send it new code and call the compiler.

_bxg1 7y ago

I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. You can't rely on interfaces; you have to fully hold everything in your mental model. When this is feasible - usually meaning that you or a small cohesive team wrote all of it yourselves - the tradeoff is a huge amount of expressiveness. The barriers between the program in your mind and the program in the code get very small, and you can just make things, concisely, unhindered. This is all well and good, but expressiveness tends to be at odds with constraints, safety, and team communication. Lisp is just one extreme of that spectrum. Personally I feel better having some of those constraints even on throwaway solo projects, though that might not be perfectly rational. I will also say that Clojure's heavy focus on immutable data helps somewhat with this problem. You can at least count on functions not having side-effects. Usually. Hopefully.

flavio81 7y ago
>I wouldn't say it's a broken idea. It's just an idea that doesn't scale. Working in a dynamic codebase - especially a Lisp one - basically means you have to be familiar with how everything you're using works. That's FUD. Just make your code modular. Lisp gives you tools: namespaces, and systems. >You can at least count on functions not having side-effects. The great majority of functions in Lisp don't mutate data.

flavio81 7y ago

>and a lack of any compile time checking is what keeps me from even bothering to look at it. Common Lisp more than compensates due to some key features: 1. any bug can be corrected at runtime without having to stop the program 2. the type system is completely strong, not weak 3. it actually has a pretty nice type system. 4. the conditions-restart exception handling system is world-class

_bxg1 7y ago
> it actually has a pretty nice type system Not by default. And herein lies the core social problem with Lisp: [new/non-lisp programmers]: Lisp doesn't have X! [lisp programmers]: Just make your own X! Lisp is extensible! Or pick from the twelve implementations already out there! Here's the thing: probably all of those implementations are going to be half-baked. And good luck finding editor support for the one you end up going with when there's no standard to rally around. And have fun re-learning the nuances of basic language features every time you join a new team. A simple core language does not mean simple code: http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
- vindarel 7y ago
  > > it actually has a pretty nice type system > Not by default > Or pick from the twelve implementations already out there! Just pick SBCL!
oblio 7y ago
> 1. any bug can be corrected at runtime without having to stop the program Can you do this in an automatable and testable way? I.e. can you provide a migration script as part of an automated deployment to an Ops team?
- vindarel 7y ago
  Hello late. Do you mean can we script the hot reload? Yes, here's a quick link: https://lispcookbook.github.io/cl-cookbook/web.html#hot-reload https://lispcookbook.github.io/cl-cookbook/web.html#hot-relo... you basically start a Swank server on the running app, connect to it from your machine, send it new code and call the compiler.