5 ms·

I've only written a little bit of it, but it brings me anxiety. Any language without static types brings me a certain degree of anxiety, thinking at all times

by _bxg1 7y ago

I've only written a little bit of it, but it brings me anxiety. Any language without static types brings me a certain degree of anxiety, thinking at all times about all the ways a given piece of code might be misused and go terribly wrong. But in Lisp you add another layer: that anything looking like a function call could actually be a macro, further blowing open the door of possibilities for what an unfamiliar piece of code might do. Of course, parsing Lisp is an exercise in tranquility ;) It's all about the programmer's personality, I think. Graydon Hoare expressed my feelings: "Basically I've an anxious, pessimist personality; most systems I try to build are a reflection of how terrifying software-as-it-is-made feels to me. I'm seeking peace and security amid a nightmare of chaos."

ninkendo 7y ago
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.
slifin 7y ago
It's weird to frame lispers as optimistic, possibly a bit insulting since the typical lisper is far from new to programming Lispers also have features and methods that mean they sleep peacefully at night too In a modern lisp like Clojure a type checking tooling is a helpful but small aspect of that
globular-toast 7y ago
Why would it be misused? I could just as easily misuse a function written with static types. Think about all the ambiguities in the English language. Imagine if you just couldn't get your point across to someone because the words you chose together bring up a different image than the one you intended. And if you really want to have nightmares think about all the ways using the public highway might go wrong. At some point you have to stop worrying about things that aren't a problem in practice. Type errors represent a tiny proportion of the bugs in dynamically typed programs. It just isn't a problem. Emacs doesn't even have namespaces or anything, yet it still works.
vindarel 7y ago
Hello late: Common Lisp does quite a lot of compile-time type checks though: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html it's not as extensive as type-safe languages, but clearly far better than any interpreted one. Add the interactivity where you compile a function (yes, just a function) with a keystroke and thus get the errors or warnings instantly, that makes a pleasant experience. We're also waiting for the Coalton library to mature, it brings Hindley-Milner type inference on top of CL…

by _bxg1 7y ago

ninkendo 7y ago

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.

slifin 7y ago

It's weird to frame lispers as optimistic, possibly a bit insulting since the typical lisper is far from new to programming Lispers also have features and methods that mean they sleep peacefully at night too In a modern lisp like Clojure a type checking tooling is a helpful but small aspect of that

globular-toast 7y ago

Why would it be misused? I could just as easily misuse a function written with static types. Think about all the ambiguities in the English language. Imagine if you just couldn't get your point across to someone because the words you chose together bring up a different image than the one you intended. And if you really want to have nightmares think about all the ways using the public highway might go wrong. At some point you have to stop worrying about things that aren't a problem in practice. Type errors represent a tiny proportion of the bugs in dynamically typed programs. It just isn't a problem. Emacs doesn't even have namespaces or anything, yet it still works.

vindarel 7y ago

Hello late: Common Lisp does quite a lot of compile-time type checks though: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html it's not as extensive as type-safe languages, but clearly far better than any interpreted one. Add the interactivity where you compile a function (yes, just a function) with a keystroke and thus get the errors or warnings instantly, that makes a pleasant experience. We're also waiting for the Coalton library to mature, it brings Hindley-Milner type inference on top of CL…