6 ms·

For me, it's a question of tooling. I would love to see a Common Lisp expert do an entire book on Armed Bear Common Lisp (Common Lisp entirely on the JVM). Edi

by claystu 10y ago

For me, it's a question of tooling. I would love to see a Common Lisp expert do an entire book on Armed Bear Common Lisp (Common Lisp entirely on the JVM). Edi Weitz hinted at what might be possible in his book, Common Lisp Recipes, but only very superficially. To me, the power of Common Lisp married to the ubiquity and library of the JVM is the great possible future for CL.

entelechy 10y ago
what do you think about clojure ?
- unixhero 10y ago
  Or perl6 on jvm
- claystu 10y ago
  I've never tried clojure; it looks interesting, though different from Common Lisp. I have invested some time--though not a lot--in Common Lisp and enjoyed it. I would like to actually use CL for something. Unfortunately, my feeling was that the infrastructure--especially for GUI's--wasn't there the way it is with lots of other languages and that was a real deal breaker. In this, I don't believe I'm alone. Armed Bear Common Lisp already exists. The JVM with all its libraries exists. Common Lisp on the JVM seems like an easy win-win to me, but I would like to see somebody really proficient in CL explore that in depth first.
  - nikofeyn 10y ago
    racket has some nice gui libraries.
  - jlarocco 10y ago
    There are several GUI libraries for CL. The best and most complete is Qtools (and CommonQt), which wrap Qt. IMO it makes Qt development easier in Lisp than it is in C++. Installation on Linux is super easy, just make sure the Qt libs and dev libraries are installed from your package manager, and then install with QuickLisp. On OSX it was tricky installing the Qt libs, but after that installing with QuickLisp just worked. I haven't tried on Windows, but supposedly it works for people. https://github.com/Shinmera/qtools https://github.com/Shinmera/qtools I've also used ltk a few times, and it's okay, but it's wrapping Tk, so ... I think there are also interfaces for wxWidgets and Gtk, but I've always liked Qt, so I haven't looked very hard.
jlg23 10y ago
> For me, it's a question of tooling. emacs & slime[1] > I would love to see a Common Lisp expert do an entire book on Armed Bear Common Lisp I'm curious what you'd expect from such a book. There are some excellent books on CL in general and good libraries that provide a convenient layer over implementation specific things (e.g.: uiop or cl-fad). One usually does not think about a specific CL implementation when writing code - I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style. [1] https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/
- claystu 10y ago
  > emacs & slime[1] I've spent a lot of time with emacs, and slime was what I used when I was exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm fairly at home with it, but I've come to prefer more graphical IDE's. Judging from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not alone. Telling programmers it's emacs+slime or the highway is not a strength; it discourages everyone who prefers those other environments. > I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style. I was suggesting ABCL because it is a full implementation of CL on the JVM. If there are other CL's with ABCL's level of maturity on the JVM, then they would work just as well. Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.
  - taeric 10y ago
    What do the graphical environments gain you, in most cases? I'll not argue that they don't usually have better defaults configured. Autocomplete, in particular, typically works out of the box. These can work in emacs, though. (Even in vim, to be honest.) Seems most of them "win" by having more effective advocacy than they do more effective features.
    - claystu 10y ago
      >What do the graphical environments gain you Simplicity. In my IDE, I start it up and then program. With emacs, it always felt like I spent a lot of time curating the editor. Part of that was because customizing emacs is fun--I have this big .emacs file that imports an even bigger .elisp file--but I also always seemed to be referring to some documentation because I'd forgotten that particular set of key-chords or messing with something to get it to work. I've come to prefer simplicity. In fact, after years of using emacs, I switched to vim for the moments when I want to program on the command line. (I think my only customization in VIM is mapping jj to escape)
deleted 10y ago
[deleted]
coliveira 10y ago
Having a Lisp implemented in the JVM has its advantages, but also its downsides. For one, all these libraries available for the JVM are targeting Java, not Lisp. This means that they are expected to be used as Java objects, not as part of a Lisp program that follows a more functional style. The result is that you lost a great part of the advantage of using Lisp, since you're forced everywhere to make concessions to the OO programming style when using these libraries.

by claystu 10y ago

entelechy 10y ago

what do you think about clojure ?

unixhero 10y ago
Or perl6 on jvm
claystu 10y ago
I've never tried clojure; it looks interesting, though different from Common Lisp. I have invested some time--though not a lot--in Common Lisp and enjoyed it. I would like to actually use CL for something. Unfortunately, my feeling was that the infrastructure--especially for GUI's--wasn't there the way it is with lots of other languages and that was a real deal breaker. In this, I don't believe I'm alone. Armed Bear Common Lisp already exists. The JVM with all its libraries exists. Common Lisp on the JVM seems like an easy win-win to me, but I would like to see somebody really proficient in CL explore that in depth first.
- nikofeyn 10y ago
  racket has some nice gui libraries.
- jlarocco 10y ago
  There are several GUI libraries for CL. The best and most complete is Qtools (and CommonQt), which wrap Qt. IMO it makes Qt development easier in Lisp than it is in C++. Installation on Linux is super easy, just make sure the Qt libs and dev libraries are installed from your package manager, and then install with QuickLisp. On OSX it was tricky installing the Qt libs, but after that installing with QuickLisp just worked. I haven't tried on Windows, but supposedly it works for people. https://github.com/Shinmera/qtools https://github.com/Shinmera/qtools I've also used ltk a few times, and it's okay, but it's wrapping Tk, so ... I think there are also interfaces for wxWidgets and Gtk, but I've always liked Qt, so I haven't looked very hard.

jlg23 10y ago

> For me, it's a question of tooling. emacs & slime[1] > I would love to see a Common Lisp expert do an entire book on Armed Bear Common Lisp I'm curious what you'd expect from such a book. There are some excellent books on CL in general and good libraries that provide a convenient layer over implementation specific things (e.g.: uiop or cl-fad). One usually does not think about a specific CL implementation when writing code - I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style. [1] https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/

claystu 10y ago
> emacs & slime[1] I've spent a lot of time with emacs, and slime was what I used when I was exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm fairly at home with it, but I've come to prefer more graphical IDE's. Judging from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not alone. Telling programmers it's emacs+slime or the highway is not a strength; it discourages everyone who prefers those other environments. > I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style. I was suggesting ABCL because it is a full implementation of CL on the JVM. If there are other CL's with ABCL's level of maturity on the JVM, then they would work just as well. Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.
- taeric 10y ago
  What do the graphical environments gain you, in most cases? I'll not argue that they don't usually have better defaults configured. Autocomplete, in particular, typically works out of the box. These can work in emacs, though. (Even in vim, to be honest.) Seems most of them "win" by having more effective advocacy than they do more effective features.
  - claystu 10y ago
    >What do the graphical environments gain you Simplicity. In my IDE, I start it up and then program. With emacs, it always felt like I spent a lot of time curating the editor. Part of that was because customizing emacs is fun--I have this big .emacs file that imports an even bigger .elisp file--but I also always seemed to be referring to some documentation because I'd forgotten that particular set of key-chords or messing with something to get it to work. I've come to prefer simplicity. In fact, after years of using emacs, I switched to vim for the moments when I want to program on the command line. (I think my only customization in VIM is mapping jj to escape)

deleted 10y ago

[deleted]

coliveira 10y ago

Having a Lisp implemented in the JVM has its advantages, but also its downsides. For one, all these libraries available for the JVM are targeting Java, not Lisp. This means that they are expected to be used as Java objects, not as part of a Lisp program that follows a more functional style. The result is that you lost a great part of the advantage of using Lisp, since you're forced everywhere to make concessions to the OO programming style when using these libraries.