5 ms·

Three thoughts (in the context of Common Lisp specifically): - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wid

Three thoughts (in the context of Common Lisp specifically): - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. - There needs to be a little bit of a culture shift around Lisp to actually write programs that do things. How many programs can you download via apt or brew that are written in Lisp? They're executables at the end of the day so nothing in principle stops this from happening, but there's just a thread of modern Lisp culture where it's more fun to play around in the REPL and write creative libraries than to ship. (There are notable exceptions of course.) - I personally like the quirkiness of Common Lisp, but there are so many ways to write it (imperative, functional, etc.), so many ways to structure your programs (one package, package per file, package inferred system, etc.), and so many ways to offer APIs (plain old data and functions, generic function protocols, etc.) that it makes it a combination of confusing and intimidating. I think shifting toward something a little more structured and disciplined like Coalton, while still giving the escape hatches to all of Common Lisp, would help a lot of people "join in" on building new code or building upon existing code.

0xcafefood 8mo ago
Agreed. I think Clojure strikes a pretty reasonable balance here. It's opinionated about the programming paradigm, scales back some of the pain that comes from reader macros, and solves some of the bootstrapping problems by compatibility with other JVM languages.
- harperlee 8mo ago
  I love clojure but the points still stand, kind-of. - There is Calva for VS Code but the community default is emacs and cider - How many programs in apt or brew are written in clojure? I'd concede that the community is great and focused on productivity, but it's so niche that you don't see much work out there made in clojure, and there is also a vestigial lisp sentiment to prefer building your own library from scratch instead of contributing to a standard library, which spreads the efforts of a small community too much - Third one you need to mutate it a little bit: clojure is opinionated instead of having "so many ways", but its opinions, while great, are foreign to most programmers
  - skydhash 8mo ago
    > There is Calva for VS Code but the community default is emacs and cider Emacs isn’t required. You can always create a REPL plugin. Emacs just does a lot of heavy lifting for you due to comint, sexp navigation, and process management being included. > building your own library from scratch instead of contributing to a standard library Simple data structures lead to very generic function. You don’t have to write tower or massive spread of abstractions like in Java or TypeScript. A struct is nothing than a hashmap that can help a typechecker. Most lisp programs prefer primitives or functions instead of manipulating complex objects -never ‘buffer.name’ but ‘(get-buffer-name buffer)’-. From a module, what you need are functions and an opaque state holder. With such philosophy, you don’t need a lot of libraries, which are often designed to be complex, when you need a simple model. > Third one you need to mutate it a little bit You don’t. Clojure already does the optimization for you for the standard data structures, and they are the only things you need in most cases.
    - Pay08 8mo ago
      I'm pretty sure he's talking about mutating the argument, as in taking issue with the opinionated nature of Clojure.
reddit_clone 8mo ago
Well CL is supposedly the programmable programming language. So none of this is surprising..
nocman 8mo ago
> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.
- Pay08 8mo ago
  Better syntax highlighting immediately comes to mind. Maybe code actions/automatic refactoring too.
  - skydhash 8mo ago
    Lisp does not have that much syntax for highlighting to be a problem. Lisp is also a symbolic language. Meaning the code work on symbols, not data, only at evaluation the value of the symbol is known. There’s a lot of symbols manipulation routines like macros, intern, package loading,… that prevent to statically know the code. It’s why people use the REPL flow.
    - Pay08 8mo ago
      The problem is not a lack of syntax highlighting per se, but the inconsistency of existing syntax highlighting. This is especially annoying in Common Lisp due to the existence of symbol macros, where syntax highlighting would be immensely helpful. I get that there are issues with symbol manipulation, but AFAIK language servers already evaluate code, even if not for syntax highlighting. I view this whole thing as an issue caused by the REPL workflow, not the inverse. Not to say that I would be willing to give up said workflow but it could certainly use improvements.
- reikonomusha 8mo ago
  - Ease of setup and install. Turnkey. Good defaults. - Non-buffer based workflows. - Easy access to settings. - Easy ways to change or switch my compiler. - Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?) - Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer pops up (breaking the arrangement of all your code windows you set up), this buffer may not even be the only one (but the others are hidden somewhere), and it's not clear what you can even click or expand to see more information (there's a tremendous amount, extremely non-discoverable). - Good getting started: built in guide for structural editing, REPL workflow, etc. ...and much much more. I say all of this as someone who basically has only used and invested in Emacs for 20 years. I love sharing Emacs with people who like weird technologies and rabbit holes, the real "hacker"-type people. I hate sharing Emacs with people who want to be productive in an hour or so with a Lisp project, because I know within 5 minutes they'll be disappointed, and never get the best of the experience because it's too much uninteresting investment. I prefer writing Lisp with Emacs+SLIME over anything else. It's extraordinarily powerful, and with enough grit, you can get it to do almost anything you want. But I'm also jealous of people who get to use, say, polished JetBrains products whose goal is to try to give you the best experience possible for your specific programming language.
vindarel 8mo ago
New projects are making the newcomer experience easier: - ICL https://github.com/atgreen/icl/ https://github.com/atgreen/icl/ a full featured REPL in the terminal and the browser. - JSCL's playground 100% in the browser https://wiki3-ai.github.io/jscl-kernel/ https://wiki3-ai.github.io/jscl-kernel/ (very new) - constantly new editor plugins. A new one: Zed https://github.com/etyurkin/zed-cl https://github.com/etyurkin/zed-cl (all editors, for readers, including VSCode, Pulsar etc: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Those editors appeared in recent years. So, I see a good trend in the ecosystem).

0xcafefood 8mo ago

Agreed. I think Clojure strikes a pretty reasonable balance here. It's opinionated about the programming paradigm, scales back some of the pain that comes from reader macros, and solves some of the bootstrapping problems by compatibility with other JVM languages.

harperlee 8mo ago
I love clojure but the points still stand, kind-of. - There is Calva for VS Code but the community default is emacs and cider - How many programs in apt or brew are written in clojure? I'd concede that the community is great and focused on productivity, but it's so niche that you don't see much work out there made in clojure, and there is also a vestigial lisp sentiment to prefer building your own library from scratch instead of contributing to a standard library, which spreads the efforts of a small community too much - Third one you need to mutate it a little bit: clojure is opinionated instead of having "so many ways", but its opinions, while great, are foreign to most programmers
- skydhash 8mo ago
  > There is Calva for VS Code but the community default is emacs and cider Emacs isn’t required. You can always create a REPL plugin. Emacs just does a lot of heavy lifting for you due to comint, sexp navigation, and process management being included. > building your own library from scratch instead of contributing to a standard library Simple data structures lead to very generic function. You don’t have to write tower or massive spread of abstractions like in Java or TypeScript. A struct is nothing than a hashmap that can help a typechecker. Most lisp programs prefer primitives or functions instead of manipulating complex objects -never ‘buffer.name’ but ‘(get-buffer-name buffer)’-. From a module, what you need are functions and an opaque state holder. With such philosophy, you don’t need a lot of libraries, which are often designed to be complex, when you need a simple model. > Third one you need to mutate it a little bit You don’t. Clojure already does the optimization for you for the standard data structures, and they are the only things you need in most cases.
  - Pay08 8mo ago
    I'm pretty sure he's talking about mutating the argument, as in taking issue with the opinionated nature of Clojure.

reddit_clone 8mo ago

Well CL is supposedly the programmable programming language. So none of this is surprising..

nocman 8mo ago

> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished. Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.

Pay08 8mo ago
Better syntax highlighting immediately comes to mind. Maybe code actions/automatic refactoring too.
- skydhash 8mo ago
  Lisp does not have that much syntax for highlighting to be a problem. Lisp is also a symbolic language. Meaning the code work on symbols, not data, only at evaluation the value of the symbol is known. There’s a lot of symbols manipulation routines like macros, intern, package loading,… that prevent to statically know the code. It’s why people use the REPL flow.
  - Pay08 8mo ago
    The problem is not a lack of syntax highlighting per se, but the inconsistency of existing syntax highlighting. This is especially annoying in Common Lisp due to the existence of symbol macros, where syntax highlighting would be immensely helpful. I get that there are issues with symbol manipulation, but AFAIK language servers already evaluate code, even if not for syntax highlighting. I view this whole thing as an issue caused by the REPL workflow, not the inverse. Not to say that I would be willing to give up said workflow but it could certainly use improvements.
reikonomusha 8mo ago
- Ease of setup and install. Turnkey. Good defaults. - Non-buffer based workflows. - Easy access to settings. - Easy ways to change or switch my compiler. - Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?) - Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer pops up (breaking the arrangement of all your code windows you set up), this buffer may not even be the only one (but the others are hidden somewhere), and it's not clear what you can even click or expand to see more information (there's a tremendous amount, extremely non-discoverable). - Good getting started: built in guide for structural editing, REPL workflow, etc. ...and much much more. I say all of this as someone who basically has only used and invested in Emacs for 20 years. I love sharing Emacs with people who like weird technologies and rabbit holes, the real "hacker"-type people. I hate sharing Emacs with people who want to be productive in an hour or so with a Lisp project, because I know within 5 minutes they'll be disappointed, and never get the best of the experience because it's too much uninteresting investment. I prefer writing Lisp with Emacs+SLIME over anything else. It's extraordinarily powerful, and with enough grit, you can get it to do almost anything you want. But I'm also jealous of people who get to use, say, polished JetBrains products whose goal is to try to give you the best experience possible for your specific programming language.

vindarel 8mo ago

New projects are making the newcomer experience easier: - ICL https://github.com/atgreen/icl/ https://github.com/atgreen/icl/ a full featured REPL in the terminal and the browser. - JSCL's playground 100% in the browser https://wiki3-ai.github.io/jscl-kernel/ https://wiki3-ai.github.io/jscl-kernel/ (very new) - constantly new editor plugins. A new one: Zed https://github.com/etyurkin/zed-cl https://github.com/etyurkin/zed-cl (all editors, for readers, including VSCode, Pulsar etc: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Those editors appeared in recent years. So, I see a good trend in the ecosystem).