It seems that there are some newish Lisps that are heeding the lessons of the latest crop of successful programming languages: they’re focusing on dev experience, tooling, and documentation to a greater degree than many of the earlier generations. I wonder if that seems to be the case to others.
For someone trying to learn LISPs right now, are there any others from this crop you could share or recommend? I’m enjoying the family of languages, but am feeling almost universally underwhelmed by the development experiences.
racket has an excellent development experience. I’ve tried and enjoyed clojure and chicken scheme in the past but these days racket is my lisp of choice.
For the next release of Fennel we’ve been focusing on friendliness: a setup guide, compiler error suggestions, readline completion and bracket matching, simplified installation, and the ability to debug macros by expanding them in the repl.
can you share what’s your development experiences have been so far with Lisps?
There are multiple Commercial Lisps ($$$) with excellent IDE support; eg– Lispworks, Allegro etc.,.
Most open source lisps(and schemes) have integration with Emacs (of course). Some people also use vim for their lisps, though that’s still considered somewhat counter-cultural.
Clojure has CIDER for emacs, cursive - an intelliJ plugin, light table (no longer developed, AFAIK), and even a VScode plugin.
Gerbil has something similar to CIDER called treadmill
Sure! I’ve been mostly working with sbcl CL, Guile Scheme, and Chicken Scheme. I’m very familiar with Emacs, so getting Slime set up was no problem.
What I’ve struggled with is the path to A) managing dependencies well, i.e., locking (most things I get the sense just always pull the latest version of things?), and B) figuring out a standard path to deployment.
The issue might just be documentation or steep learning curve, but coming from, say, the first few steps in a language like Rust, where the first steps are:
get rust with rustup
create new project with cargo new
edit some code
build code, copy compiled executable somewhere
Trying to figure the analogous set of steps in lisps just seems to require learning many tools and making many decisions: e.g., quicklisp vs asdf vs buildapp.
I’ve had good preliminary experiences with Janet. But I haven’t put it through its paces yet; I want to build a multi module CLI app before I claim victory.
Can I ask what things you use the command line for? Just curious, not doubting you or anything. I’ve used magit for 10+ years and I don’t think Ive used the git command line in 8+ years. Magit definitely introduced me to alot of git features that are so trivial to use and would be a nightmare to do via the command line (IMHO).
I think I can say magit is my all time favorite piece of software. It kind of acts as the hub for all of my development. I should probably go donate again right now.
I think that the driver is that I’ve reached my limit (buffer’s full,
loosing neurons, etc..) in the number of magic short keystrokes that I
can remember. I learned git on the command line before I discovered magit.
I’ve never been big on aliases and shortcuts and etc,
it’s easier for me to remember N+M things and how to combine them than
it is to remember N*M aliases and etc…. I hang onto nouns and verbs easily (although git
commands are, well, irregular…).
I also like to be able to do these things on minimally-configured machines, on remote systems, and/or
in other people’s accounts so leaning hard on any gui is a personal anti-pattern. I can even use vi in a pinch… ;)
By way of a list:
I almost always stage and commit from a magit buffer (partial
staging is a godsend).
If I interactive rebase, I do it in magit.
I probably create/switch branches about 40% of the time in magit.
I generally git init from the command line.
I have an alias, ‘git hist’ that I use to get an overview of the
branching structure from the command line. I’ll sometimes poke
around and do the equiv. in magit but not often enough that it
sticks. From my ~/.gitconfig:
Cool thanks for the explanation. That makes sense. My workstation is a remote machine at digital ocean that I use ssh(mosh) and tmux with emacs always running. So my computers just act as a browser and gateway to that workstation, where all the work actually happens. I don’t use other peoples computers ever so I think its easier for me to work the way I do.
Interestingly, I am also split between magit and the command line, and where the splits occur for me are almost identical to this list! The only major thing I would add is that I tend to do all my remote adding/editing/removing from the command line as well.
alot of git features that are so trivial to use and would be a nightmare to do via the command line (IMHO).
I strive to organize my work so that I rarely have to do anything nightmare-ish. Basic nvie style git flow and it’s derivatives.
My only common dirty trick is when I forget to create a branch and drop a bunch of commits on my base branch. It happens often enough that I can do the recovery dance from memory and it’s not really nightmarish.
I’m curious, what git features you use that are trivial in magit and really difficult on the command line. The only ones that come to mind for me are interactive rebase and staging/committing an unfortunate conglomerate of work in bits, which are both way easier in a “tui/gui” environment.
I’m curious, what git features you use that are trivial in magit and really difficult on the command line.
Not the parent, but for myself:
Increasing/decreasing hunk sizes and selectively choosing what hunks to stage/unstage is the biggest one for me. I still use git a lot on the command line but its interface for doing this stuff is… not good. magit is stupid easy +/- (s)tage (u)nstage etc… also ediff and conflict resolution via magit is rather nice as well.
Gotcha, wasn’t clear what you meant there. But another bit thats nice is undoing/redoing things from prior commits as well. Its all really well done in magit. As well as getting stuff out of stashes/etc….
Heh, sure, I use more than this to be clear but the overall hunk handling in magit is…. I think divine is the best word I can think of. I still use the command line though, I’ve a ton of old aliases for drilling through histories that magit really doesn’t help with. As well as just being able to deal with using git plain on systems where my local emacs setup isn’t available is also nice. I’ve never been big on getting so used to other tools that I’m incapacitated when I don’t have my preferred thing.
I’m curious, what git features you use that are trivial in magit and really difficult on the command line.
You mentioned staging/committing, but even for me, just seeing what is changed and staged is a big help. It’s better than “git status” because everything is nicely presented – you can collapse and expand sections as you want. You can even hit enter on a diff hunk to go to that hunk and edit it! As you mentioned, you can stage/commit, but I like it even when I want to commit everything, not just when I’m dealing with “an unfortunate conglomerate of work”. I like to review my changes before staging them, even when it’s not an especially complicated set of changes.
Oh, definitely. It didn’t come across that way. I just wanted to point out that I find magit a better experience not just for unusual, disaster-recovery situations.
I said “nightmare” above but that’s definitely an exaggeration. Most of these have been mentioned. But I think for me it comes down to not context switching. I can just do what I want with a couple keystrokes without dropping to the command line and remembering git syntax. Maybe that syntax is so ingrained for you guys, like the magit keystrokes are for me so, in the end it comes down to being comfortable.
Interactive rebase (and the tons of features this provides), stashes, rebase and merge conflict resolution, cherry picking, hunk staging, visual representation of the entire project state.
But we all just work different. I’m not trying to convince anyone to change their workflow. I was just curious. I’ve seen people here say they use diff or log in the command line for example. Which I find odd since instead of switching to a terminal and typing a command you can just press tab on a file and see the diff and press enter to go to that place in the file or s to stage it. Using the command line here just feels like extra work, especially if there are 5+ files you are diffing. There just seems to be way more value in using magit for this (IMHumbleO). Same with l l for log. But with using magit’s log you can scroll up and down, press enter on a commit, etc. Where as on the command line you have to look for SHA hashes to get the code in that commit, or count how many commits to use HEAD~x.
They just feel like and extension of where I am. And none of the magit features seem, to me at least, to have any shortcomings or trade offs. It just feel likes a complete win.
Sometimes I get ingrained in my workflow it seems like the only logical one, which is obviously not true and a dumb mindset for me to have.
Thanks for sharing.
since it’s my main/always-on Syncthing server, it’s also got two identical usb drives that I use for storage of everything (books, code, documents, backups), and a nightly cron job mirrors one usb to the other with rsync. So it’s kind of like a hacky RAID setup, in case one of the USB sticks stops working.
That’s about all it does. The only other thing I did to make it all work nicely was to add a daily cron job for a DDNS script, which checks its IP, and if it’s changed (since ISPs do that from time to time), it updates its DNS records at my domain registrar. That way I get nice domains for things.
It seems that there are some newish Lisps that are heeding the lessons of the latest crop of successful programming languages: they’re focusing on dev experience, tooling, and documentation to a greater degree than many of the earlier generations. I wonder if that seems to be the case to others.
For someone trying to learn LISPs right now, are there any others from this crop you could share or recommend? I’m enjoying the family of languages, but am feeling almost universally underwhelmed by the development experiences.
racket has an excellent development experience. I’ve tried and enjoyed clojure and chicken scheme in the past but these days racket is my lisp of choice.
For the next release of Fennel we’ve been focusing on friendliness: a setup guide, compiler error suggestions, readline completion and bracket matching, simplified installation, and the ability to debug macros by expanding them in the repl.
can you share what’s your development experiences have been so far with Lisps?
There are multiple Commercial Lisps ($$$) with excellent IDE support; eg– Lispworks, Allegro etc.,.
Most open source lisps(and schemes) have integration with Emacs (of course). Some people also use vim for their lisps, though that’s still considered somewhat counter-cultural.
Clojure has CIDER for emacs, cursive - an intelliJ plugin, light table (no longer developed, AFAIK), and even a VScode plugin.
Gerbil has something similar to CIDER called treadmill
Sure! I’ve been mostly working with sbcl CL, Guile Scheme, and Chicken Scheme. I’m very familiar with Emacs, so getting Slime set up was no problem.
What I’ve struggled with is the path to A) managing dependencies well, i.e., locking (most things I get the sense just always pull the latest version of things?), and B) figuring out a standard path to deployment.
The issue might just be documentation or steep learning curve, but coming from, say, the first few steps in a language like Rust, where the first steps are:
Trying to figure the analogous set of steps in lisps just seems to require learning many tools and making many decisions: e.g., quicklisp vs asdf vs buildapp.
I’ve had good preliminary experiences with Janet. But I haven’t put it through its paces yet; I want to build a multi module CLI app before I claim victory.
I’ve found that I split my time between the command-line and magit in emacs.
Can I ask what things you use the command line for? Just curious, not doubting you or anything. I’ve used magit for 10+ years and I don’t think Ive used the git command line in 8+ years. Magit definitely introduced me to alot of git features that are so trivial to use and would be a nightmare to do via the command line (IMHO).
I think I can say magit is my all time favorite piece of software. It kind of acts as the hub for all of my development. I should probably go donate again right now.
Absolutely.
I think that the driver is that I’ve reached my limit (buffer’s full, loosing neurons, etc..) in the number of magic short keystrokes that I can remember. I learned git on the command line before I discovered magit.
I’ve never been big on aliases and shortcuts and etc, it’s easier for me to remember N+M things and how to combine them than it is to remember N*M aliases and etc…. I hang onto nouns and verbs easily (although git commands are, well, irregular…).
I also like to be able to do these things on minimally-configured machines, on remote systems, and/or in other people’s accounts so leaning hard on any gui is a personal anti-pattern. I can even use vi in a pinch… ;)
By way of a list:
I almost always stage and commit from a magit buffer (partial staging is a godsend).
If I interactive rebase, I do it in magit.
I probably create/switch branches about 40% of the time in magit.
I generally
git initfrom the command line.I have an alias, ‘git hist’ that I use to get an overview of the branching structure from the command line. I’ll sometimes poke around and do the equiv. in magit but not often enough that it sticks. From my
~/.gitconfig:I
git rmfrom the command line.I nearly always
git fetchandgit mergefrom the command line.git pushseems to be split about 50/50, depending on what window is focused.Cool thanks for the explanation. That makes sense. My workstation is a remote machine at digital ocean that I use ssh(mosh) and tmux with emacs always running. So my computers just act as a browser and gateway to that workstation, where all the work actually happens. I don’t use other peoples computers ever so I think its easier for me to work the way I do.
Have a good weekend!
Interestingly, I am also split between magit and the command line, and where the splits occur for me are almost identical to this list! The only major thing I would add is that I tend to do all my remote adding/editing/removing from the command line as well.
Oops, remotes…. Yep, command line (though my usage is pretty simple…)
Great minds think alike!
One other thought on rereading your question….
I strive to organize my work so that I rarely have to do anything nightmare-ish. Basic nvie style git flow and it’s derivatives.
My only common dirty trick is when I forget to create a branch and drop a bunch of commits on my base branch. It happens often enough that I can do the recovery dance from memory and it’s not really nightmarish.
I’m curious, what git features you use that are trivial in magit and really difficult on the command line. The only ones that come to mind for me are interactive rebase and staging/committing an unfortunate conglomerate of work in bits, which are both way easier in a “tui/gui” environment.
Not the parent, but for myself:
Increasing/decreasing hunk sizes and selectively choosing what hunks to stage/unstage is the biggest one for me. I still use git a lot on the command line but its interface for doing this stuff is… not good. magit is stupid easy +/- (s)tage (u)nstage etc… also ediff and conflict resolution via magit is rather nice as well.
Absolutely, that’s what I’d shorthanded as “partial staging….”
Gotcha, wasn’t clear what you meant there. But another bit thats nice is undoing/redoing things from prior commits as well. Its all really well done in magit. As well as getting stuff out of stashes/etc….
Face it, it’s all nice :)
It’s been great to read what bits other folks use.
Heh, sure, I use more than this to be clear but the overall hunk handling in magit is…. I think divine is the best word I can think of. I still use the command line though, I’ve a ton of old aliases for drilling through histories that magit really doesn’t help with. As well as just being able to deal with using git plain on systems where my local emacs setup isn’t available is also nice. I’ve never been big on getting so used to other tools that I’m incapacitated when I don’t have my preferred thing.
You mentioned staging/committing, but even for me, just seeing what is changed and staged is a big help. It’s better than “git status” because everything is nicely presented – you can collapse and expand sections as you want. You can even hit enter on a diff hunk to go to that hunk and edit it! As you mentioned, you can stage/commit, but I like it even when I want to commit everything, not just when I’m dealing with “an unfortunate conglomerate of work”. I like to review my changes before staging them, even when it’s not an especially complicated set of changes.
Don’t want to leave the impression that ‘unfortunate conglomerates” is my general modus operandi, it’s definitely the oops.
In the usual, neat, case I find myself splitting between exploring them in magit and just scrolling the output of
git diffin a terminal window.Oh, definitely. It didn’t come across that way. I just wanted to point out that I find magit a better experience not just for unusual, disaster-recovery situations.
I said “nightmare” above but that’s definitely an exaggeration. Most of these have been mentioned. But I think for me it comes down to not context switching. I can just do what I want with a couple keystrokes without dropping to the command line and remembering git syntax. Maybe that syntax is so ingrained for you guys, like the magit keystrokes are for me so, in the end it comes down to being comfortable.
Interactive rebase (and the tons of features this provides), stashes, rebase and merge conflict resolution, cherry picking, hunk staging, visual representation of the entire project state.
But we all just work different. I’m not trying to convince anyone to change their workflow. I was just curious. I’ve seen people here say they use diff or log in the command line for example. Which I find odd since instead of switching to a terminal and typing a command you can just press
tabon a file and see the diff and press enter to go to that place in the file orsto stage it. Using the command line here just feels like extra work, especially if there are 5+ files you are diffing. There just seems to be way more value in using magit for this (IMHumbleO). Same withl lfor log. But with using magit’s log you can scroll up and down, press enter on a commit, etc. Where as on the command line you have to look for SHA hashes to get the code in that commit, or count how many commits to use HEAD~x.They just feel like and extension of where I am. And none of the magit features seem, to me at least, to have any shortcomings or trade offs. It just feel likes a complete win.
Sometimes I get ingrained in my workflow it seems like the only logical one, which is obviously not true and a dumb mindset for me to have. Thanks for sharing.
That’s about all it does. The only other thing I did to make it all work nicely was to add a daily cron job for a DDNS script, which checks its IP, and if it’s changed (since ISPs do that from time to time), it updates its DNS records at my domain registrar. That way I get nice domains for things.
What is the URL of your gopherhole? finger redacted@1436.ninja for contact, please, if you’d rather not post…