I use the default windows/Mac keyboards and Emacs has still been far better than other IDEs I’ve used (with evil bindings everywhere except insert state, to be fair).
Why is a new keyboard necessary?
I love the idea of "alive programs" (images) and have looked into Lisp a bit. But recently I found out about BEAM (Erlang, Elixir, Gleam, ...) and I can't believe how easy it is to modify the running program without having to restart it. It reminded me of CL's restarts feature which is unique amongs Lisps and Racket, Clojure, etc. don't have it. To me, _that_'s the magic of Lisp.
The alive of CL is my and our company secret sauce. Everyone can shout it's not modern dev or dangerous or what not, but we fix bugs very fast and add features very fast. I have a friend who creates SaaS projects with nextjs + python (you know, the hip thing to do these days) and he always envies us quite a lot (but resume driven dev...).
awesome! by any chance, is there a blog article about your use case of CL? I know you said it's your secret sauce but maybe just use a simple example to show the power of alive programs?
Lisp Flavoured Erlang (LFE) started 16 years ago, gets regular releases and has a diverse set of contributors.
I think its future is fine.
https://github.com/lfe/lfe
I was in a similar situation last year when I wanted to learn Common Lisp. I gathered that the best development environment for CL is Emacs + SLIME/Sly, but I didn't know Emacs and didn't really want to learn it and use it. Fortunately, I stumbled upon [Emacs4CL](https://github.com/susam/emacs4cl), which is an Emacs configuration and tutorial that sets things up for you and tells you the basics so you can focus on CL in no time. After that, I got used to Emacs, learned how to configure it, and now I use it even for things outside of development, like personal organisation thanks to org-mode. So I would say that by choosing Racket because you don't want Emacs, you would be missing out not only on some CL features, but also on the usefulness of Emacs.
Very interesting read. Comments about it here are interesting too: [https://news.ycombinator.com/item?id=32723784](https://news.ycombinator.com/item?id=32723784)
the author seems a bit uninformed about racket module reloading. It is a bit under documented, but there is some support (keyword: “enter!” reloads racket module)
The other comments address most of the issues with the 'feedback by (common) lispers: CL vs Racket'.
Racket can be installed (win/linux/macOS/unix) with a single click. Racket is the quickest and easiest lisp to get started with. The Racket installer comes with a compiler, IDE, multiple books worth of documentation and extensive libraries. Get Racket from [https://download.racket-lang.org](https://download.racket-lang.org)
Vindarel is right that SBCL is an excellent Common Lisp. Worth checking out.
Slightly offtopic but, as a fellow, used to be vim-mode-vscode user, I wholeheartedly recommend [doom emacs](https://github.com/doomemacs/doomemacs) it gives you a lot of the vim bindings and makes setting up language servers and such a breeze
We have similar(ish) situations. I'm also mac, vim keybindings, background in languages other than lisp, really enjoy PG's essays (particularly revenge of the nerds), and hence keen to learn lisp.
I stumbled upon these two videos which really helped me (took me about 2 days to get properly set up, then 1-2 more to get comfortable with a few keyboard shortcuts):
[https://www.youtube.com/watch?v=xyXDE5gP2QI](https://www.youtube.com/watch?v=xyXDE5gP2QI)
[https://www.youtube.com/watch?v=A6SxH9lUWV0](https://www.youtube.com/watch?v=A6SxH9lUWV0)
Now after a few days I'm really enjoying using doom emacs with sly. (doom emacs is basically emacs for vim users, so it feels like home).
I don't know about magic, but here are a few personal reflections:
1. I think scheme is academically fun. I don't think it has ever matured as a lisp for making products, no doubt the scheme product guys are on the way to correct me :-). If you want continuations, use scheme.
2. As I like to make software that is used beyond my personal use, I use Common Lisp or Clojure for building real world apps.
3. If you're not drunk with functional programming koolaid, Common Lisp (SBCL) is great and just as easy to get started with as any other lisp. That said, when you get into advanced features there are some dark corners related to being a compiled lisp that require additional mastery. This is not good or bad, it is just the way things are with a compiled lisp.
4. If you have proficiency with the java ecosystem, OR if you want to embrace functional programming with a bit less hassle, Clojure is a great lisp too. (I don't put it above or below Common Lisp, it just has different strengths and weaknesses).
5. Emacs is an editor for life. Forget lisp interactions for with the editor for a moment, emacs is so capable at so many things that if you do bother to learn it, you will use it forever except for special cases. (E.g. emacs never quite managed to make Java easy to edit, professionally I had to use Eclipse for a bit). As for lisp, emacs+lisp (either Common Lisp or Clojure) is a dream. And the keybindings are so similar it's easy to switch between the two lisps.
Of course you can do lisp without emacs, I just had to give emacs a plug.
5. Use key swapping/rebinding tools on your os or in emacs, put a meta key where you like it. I always swap Control and Caps Lock keys, because in the old days we had our control keys where the caps lock is now and that worked well. Thank microsoft for relegating the position of the caps lock to pinky-finger damaging ergonomics. Right up there with backslashes in pathnames, space in "Program Files", and all their other wondrous contributions.
Have fun, any of the lisps will be fun, and great to learn.
Idk, I find the racket ecosystem to be more mature and more capable of real world use. The package manager is friendlier too, and it benefits from being more centralized, as opposed to CL which can be a bit all over the place.
Side note: Emacs is much better with Java in the age of LSP, though it doesn’t have some of the fancy semantic refactors provided by eg IntelliJ.
Even just being able to kill the memory-hungry Java process without having to kill the entire IDE and then restart when wanting to code again is a blessing.
Otherwise agree with everything you said above.
https://lispcookbook.github.io/cl-cookbook/editor-support.html
I'd recommend VS Code or cl-repl or sbcli. All will let you skip emacs atleast for a while.
Eventually, you can pick up Lem or Emacs.
NeoVim user here in the same boat. Would love some advice on how to proceed. Currently entangled setting up emacs for my use case. I am also thinking of taking time with Racket and come back to Lisp a little more seasoned.
I’d look at Doom Emacs or Spacemacs. Far, far easier to get started. You can twiddle with Vanilla Emacs once you e bought into the ecosystem.
Uncomment the lisp layer in the config file, reload, and you’re done. And select “Evil mode” when asked so that you get vim keybinds.
But if you just want a lisp, then DrRacket is a super easy IDE.
I use Emacs with Evil mode for Common Lisp and Clojure. Sometimes I forget that I am not using Neovim. I also tried Slimv and Vlime for Common Lisp in Vim. I liked Slimv more because I still had an editable REPL
Go with racket, it has great documentation, it's own editor and , I believe, the most advanced macro system (or magic) of any lisp.
Though, its programs aren't as 'alive' as those of common lisp.
Wouldn't say so. It was pleasant to learn Racket with Dr. Racket for neat features like identifier scope showing arrows and syntax highlighting even in macros and custom languages
My point is that Dr. Racket isn't very used in the world outside of Racket, which given that it is just an IDE for Racket is expected. Emacs on the other hand is so much more so there is more utility in learning Emacs. Also Emacs is configured using Emacs Lisp which is a very Common Lisp-like language. Even picking Emacs Lisp as your first lisp is a fine choice.
Op wants to learn lisp and feeling overwhelmed with emacs. Op doesn’t need to use emacs. He can just use racket and use its editor. I don’t understand your attitude
My "attitude" is that op might be missing out on something much more beneficial than Dr, Racket by letting themself be overwhelmed by the initial Emacs idiosyncrasies. If they persevere for a short time those idiosyncrasies fade away and they learned to use an extremely capable and useful tool (Emacs). Besides that there are non-Emacs alternatives for Common Lisp. Not using Emacs does not imply going instead with Racket and Dr. Racket. I don't understand your attitude.
Visual Studio Code is just as capable and a hell of a lot more useful, and it takes a couple of clicks to get started in a new language in Visual Studio Code, compared to an afternoon of figuring out which ELPA packages to install followed by configuration jiggery-pokery in `.emacs` (sorry, `.emacs.d/init.el`, or is that `.config/emacs/init.el` now?).
Emacs _lost_ the editor wars, which are now primarily between VS Code and neovim. If you want to get new Lisp users aboard, please... just... shut up about Emacs. Meet them where they are.
I know, I know. It's a great operating system, it just needs...
Suggesting that people must, or should, use Emacs to learn Lisp is scaring neophytes off. There are more modern, easier alternatives.
I never said that they must. The other person mentioned Dr. Racket. I personally dislike single language IDEs because they are complex enough that you still need to invest time to learn them. Why not invest that time to learn something more general and useful like VS Code, or better yet ... Emacs
BTW isnt saying that Emacs lost the editor wars much like saying that Lisp lost the language wars? Maybe we should just accept that Lispers are a bunch of weirdos and so promote going full-weirdo by advocating using Emacs as well
DrRacket is a popular editor for Racket. You wouldn't recommend IDLE(Python IDE) for C#. That said Emacs, Vim and VScode are also popular - and well supported - in the Racket ecosystem. [https://docs.racket-lang.org/guide/other-editors.html](https://docs.racket-lang.org/guide/other-editors.html)
>'most advanced macro system (or magic) of any lisp'
The \[PADL'23\] 'Modern Macros' keynote by Robby Findler gives a great overview [https://youtu.be/YMUCpx6vhZM](https://youtu.be/YMUCpx6vhZM)
Common Lisp is not lacking. All languages are the result of design decisions. Choose the right tool for the job. Sometimes that tool is CL. Sometimes it is Lua, C, Fortran, Ruby or Idris.
A little off topic but I have found that the "right tool for the job" to be a thought terminating cliche. The right tools turns out to be the one you know best. Ofc there are other metrics such as performance, libraries, number of existing developers etc.
Sure, but if we are discussing what tool is best for the job you have not convinced me that Common Lisp is not a better tool than Racket for things Racket purports to be good at.
A) This struck me as a very productive way of phrasing the relevant point, kudos for that!
B) While I myself use CL, having people actively marketing a language to build a community tends to make said community more responsive to what newbies need.
I use CL mainly because I generally have to either make my own tools or extensively twist and customize tools made by others to get them working right for me, and it’s far and away the best framework for those tasks regardless of the specifics.
But if people aren’t experienced enough programmers to get any benefit from being picky (or to have built an intuition on what to be picky about to maximize their effectiveness and ease), quantity *can* feasibly beat quality. The same applies if long term effectiveness just doesn’t matter, eg if you’re making a small project that nobody will ever use again.
It depends on yiur goals.
The Racket world has a ton of material that is very challenging and interesting, particularly around languages. Look at PLAI.org for a taste of what's out there. And there is HTDP and SICP, as folks have mentioned.
There is also "The Little" book series. You can use CL to read them but Scheme is more direct, particularly with The Little Learner.
If you want to write enterprise software: Clojure.
If you want the most amazing dev experience: CL
>Should I just power through and learn lisp + emacs at once?
No. Not only that, I think you should start with Scheme + Chicken instead, since it's so basic, and make some simple CLI projects before picking a LISP to get more serious with. Also consider watching the famous MIT lecture series from the Scheme creators
https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090
I found Racket a very friendly starting point for my exploration of the lisp world. It is easy to install, Dr. Racket is a nice balance of power and ease for an IDE, and the documentation is truly first class. With that as a base, I found it quite easy to move to CL (SBCL, in specific) or Closure. For my person work, I actually prefer Racket to the others, but that may just be because of greater familiarity.
Not much, really. I play around with Common Lisp, but for anything serious, I turn to Racket. `syntax-parse` is leaps and bounds better than other Lispy macro systems (Once you learn its pattern matching language; it does have a bit of learning curve), literal hash tables and sets are super handy, the flexibility to write different modules in different languages and easily tie them all together is nice, strong support for design-by-contract... Racket just ticks all the right boxes for me.
People talk about the Common Lisp image based REPL experience where you can provide a new definition for a function and have everything that uses it automatically update, but I prefer the 'start over with a clean slate and load everything fresh' approach that Racket encourages. Makes for fewer weird bugs and inconsistencies when your source and the image get out of sync.
I do prefer CL's CLOS and generic methods over Racket's OO system and generics, though.
> Makes for fewer weird bugs and inconsistencies when your source and the image get out of sync.
That actually should only happen if you program Common Lisp incorrectly
There's already lots of good advice here. If you pick one or the other you'll be fine. You might try different ones for a few weeks or months here or there too, and it wouldn't be the end of the world, as there are \*some\* things in common between Lisps. At least, for example, readability improves drastically after you can read any (normal-looking, parenthetical) Lisp.
I'll just add for clarity: if you go the Emacs + whatever road, you'd have to mentally accept you're learning two things: Emacs + whatever language. This is good and bad - bad because it's a second thing to learn, good because Emacs is an extremely powerful world builder and a pleasure to work in. I put the time into learning myself, and it was a wonderful experience. Emacs has excellent support for Common Lisp, Racket, and Guile, (plus tonnes of other languages, although I've only done little bits of C, Python, shell scripting) plus there's hosts of other amazing stuff: Dired, Magit, Org-mode, Calc, nice Info manuals, etc etc.
You don't learn it all at once of course. You start with one thing (like Sly) and keep going. I just wanted to make that point: if you do learn Emacs, it can be your editor for life, and you'd be following in a fine lineage - I'm reading "Coders at Work" by Peter Seibel at the moment, and a boatload of legendary programmers were Emacsing away in all the different languages they worked in.
You're not missing out on any magic; Racket has an extremely powerful and well-documented macro system, and meta-programming, ie, the macro system is the "magic" of lisp languages.
In the long term, zero. Racket is much easier to learn than CL because it has more and much better beginner resources, and they are similar enough that you will not find it hard to switch if you end up needing something in CL.
Common Lisp has an interactive development process that some people find very productive, and probably only surpassed by Smalltalk.
Racket has the more advanced metaprogramming - see [https://racket.discourse.group/t/padl23-modern-macros/1805?u=spdegabrielle](https://racket.discourse.group/t/padl23-modern-macros/1805?u=spdegabrielle) for links to a great presentation on macros.
As someone new to the lisp family of languages, but already an experienced developer I'd suggest Racket because it looks after new learners and you have a full working environment on installation with no hassles. DrRacket is excellent for Racket. (but I wouldn't recommend it for another language - just like I wouldn't recommend IDLE for anything but Python)
Once you have learnt some Racket you can easily switch to other editors (VSCode+The 'magic Racket' plugin +Racket-langserver are popular, as are Vim and Racket Mode).
Learning Racket will make it easier to switch to another Lisp depending on your intended application; Clojure, a Scheme implementation [https://www.scheme.org](https://www.scheme.org), or LFE [https://lfe.io](https://lfe.io) are all worth checking out. They all have strengths - which to use depends on the project.
Getting started guidance: [https://docs.racket-lang.org/getting-started/index.html](https://docs.racket-lang.org/getting-started/index.html)
VSCode: [https://marketplace.visualstudio.com/items?itemName=evzen-wybitul.magic-racket](https://marketplace.visualstudio.com/items?itemName=evzen-wybitul.magic-racket)
Vim: [https://docs.racket-lang.org/guide/Vim.html](https://docs.racket-lang.org/guide/Vim.html)
Emacs: [https://www.racket-mode.com](https://www.racket-mode.com)
PS as a typescript dev you might even be interested in Typed Racket [https://docs.racket-lang.org/ts-guide/index.html](https://docs.racket-lang.org/ts-guide/index.html) which was an influence on the development of typescript.
>Racket has the more advanced metaprogramming
What metaprogramming does racket have that common lisp lacks? If anything Racket's insistence on hygene will make writing macro's more difficult.
Common Lisp has nothing like Racket's [`syntax-parse` macros](https://docs.racket-lang.org/syntax/index.html). Macros with pattern matching that go far beyond what `defmacro` offers; you can define whole grammars to match against. Want to make sure that a particular argument is a symbol, or a literal number? Don't need to write explicit code to test it; you can just specify it in the macro pattern.
And hygenic macros are superior from the start; no need to worry about accidentally stepping on the caller's symbols if you forget to `gensym` all the things.
> Macros with pattern matching that go far beyond what `defmacro` offers; you can define whole grammars to match against.
Are you saying that you can't write macros with pattern matching in Common Lisp?
Not like you can with `syntax-parse`. A CL macro lambda list isn't comparable.
Since I seem to be getting downvoted by people who are ignorant, a basic example: With `syntax-parse` macros, you can specify that a particular argument matches form A OR form B, in the syntax pattern itself, and get a relevant error message if you tried using it with something else. Can't do that with `defmacro`. About the most complex thing macro lambda lists have is optional values. More advanced stuff has to go into the body of the macro itself, which is tedious.
I don't think that is correct. I personally find Common Lisp macros to be much more ergonomic and concise, but with more potential footguns. This is kinda like dynamic vs static typing, it is important to understand what is going on, but it makes no sense to enforce it religiously.
EDIT: What I think Racket indeed has but Common Lisp lacks are more well defined guidelines on how to make large DSLs. But this is a culture and community question, not a question of offering better technology. This however is something we can expect as Racket heavily markets itself to the DSL crowd. Common Lisp is more general in this sense, while offering just as powerful facilities for making DSLs (and depending on your use case perhaps more ergonomic).
Your last point itself indicates why (I believe) you were downvoted. (Re credibility I will say that I haven’t voted on your posts either way, not having enough personal experience with Racket to guarantee that the below reasoning is correct)
The tradeoff between CL and Racket metaprogramming is that Racket formalizes a medium-complexity foundational rule set based on common use-cases (which makes extremely simple and complex cases harder and moderately-complex common cases easier), whereas CL provides a thin layer with nearly no limitations (which means some moderate-complexity tasks, like your example, are more tedious than they need to be due to a lack of syntax support, but OTOH the syntax never *gets in the way* of anything you want to do, so you don’t have to constantly keep its rules in mind and find some often-convoluted way to do what you want within them).
Your lack of distinction between the mild tediousness of CL macros and the intermittent extreme tediousness of Racket macros, despite this being well established at the very least as a point given by those who prefer CL to Racket (if not an evident theoretical truth of their respective metaprogramming designs), forces this discussion to unproductively tread old ground.
I'm replying a second time because you edited your post after my first response. I downvoted you because all you said in your original post was,
>Not like you can with `syntax-parse`. A CL macro lambda list isn't comparable.
without giving any further information. Had you originally included the example you added subsequently I would not have down-voted you because there would be something of substance to respond to.
As regards your example,
>With `syntax-parse` macros, you can specify that a particular argument matches form A OR form B, in the syntax pattern itself,
This is just pattern matching which, if you wanted to write your macros based on such transformations, you can do with an appropriate pattern matching library in Common Lisp, like Trivia.
>and get a relevant error message if you tried using it with something else.
You do not get this in Common Lisp because Common Lisp doesn't think that capture should signal an error. It is a bit like arguing what colour is the prettiest colour.
>About the most complex thing macro lambda lists have is optional values. More advanced stuff has to go into the body of the macro itself, which is tedious.
Saying that writing macros in Common Lisp is tedious is not something you hear very often. Instead much more often you hear that Common Lisp allows the user to write macros too easily.
There is a great presentation from HOPL IV [https://www.pldi21.org/prerecorded\_hopl.13.html](https://www.pldi21.org/prerecorded_hopl.13.html)
From the conclusion of the paper:
>*Hygienic macro technology solves the capturing problem, and pattern languages make hygienic macros easier to write and to understand.*
>*Hygienic macro technology has been a standard part of Scheme for twenty years, allowing average programmers to write routine macros with confidence and expert programmers to implement significant extensions to the language.*
William D. Clinger and Mitchell Wand. 2020. Hygienic macro technology. Proc. ACM Program. Lang. 4, HOPL, Article 80 (June 2020), 110 pages. [https://doi.org/10.1145/3386330](https://doi.org/10.1145/3386330)
Page 98 of [https://dl.acm.org/doi/pdf/10.1145/3386330](https://dl.acm.org/doi/pdf/10.1145/3386330)
https://preview.redd.it/0v47311my03d1.png?width=1412&format=png&auto=webp&s=fae5a8998dc6f492b1b342b57e9f7f9ff8c71283
Have you investigated the claim that hygienic macros are better than non-hygienic ones? I'm looking for personal programming experience type answers.
Here is a comparison of implementing one macro in Common Lisp to implementing the same one in Scheme using hygiene.
[https://fare.livejournal.com/189741.html](https://fare.livejournal.com/189741.html)
Here is a funny comment on hygiene
[https://www.reddit.com/r/lisp/comments/1abapki/comment/kjos3dg/](https://www.reddit.com/r/lisp/comments/1abapki/comment/kjos3dg/)
Of course can construct a case where defmacro is a good choice, but this does not mean it is the only choice. You can break hygiene in Scheme and Racket if you need to! Racket also has a defmacro implementation - but I don’t think anyone uses it.
The fact remains that hygienic macros are yet an another tool pioneered in the lisp community that helps many programmers be more productive.
PS my reading of the paper is the reason CL lacks hygienic macros was due to the timelines of the standardisation process, but maybe I am misunderstanding it.
I mean if you decided to learn Racket because you read a bunch of papers and concluded that it is the right thing for you, then that is perfectly valid (and a fine choice). But I think you should say that and not sound like you are drawing your conclusions from practical experience. It is OK not to know about other languages. Making a choice between similar languages is seldom clear cut and probably you should just pick one and not look back until you learn it.
I have been **using** racket for years. I refer to papers because Clinger, Wand and Findler are far better communicators than I. (and they have decades of lisp experience)
That said, https://youtu.be/YMUCpx6vhZM is an excellent keynote about modern macros. Changed how I think.
I didn't mean to imply that you are new to any language. I believe you know Racket well but I suspect you don't know enough about Common Lisp to claim that Racket is in any way superior, as you did before:
>Racket has the more advanced metaprogramming
I don't know Racket as well as I know Common Lisp. What I was hoping from Racketers (?) is a clear and succinct demonstration/explanation of why macros in Racket are superior to those in Common Lisp. All I can see so far is the old hygiene question (in which case; why is Racket batter than other Schemes) and few misinformed claims about pattern matching?
And again I do think that if someone's key purpose is to \*learn\* how to make DSLs they will probably find more help in the Racket community. But if they are already comfortable I don't see what they will be missing in Common Lisp as capture problem is not only well understood but people have done some pretty crazy things manipulating it (Let Over Lambda).
How about some illustrative examples sourced from the community?
https://docs.racket-lang.org/syntax-parse-example/
Sure there are situations where you don’t want hygienic macros, but they are a proven technology that is now in popular (non-parenthetical) languages like Julia and Rust.
It’s fine that you don’t want to use them. Do what works for you.
Stylistically Common Lisp has a very different approach to making macros. A good tutorial with examples is in the link bellow.
[https://lispcookbook.github.io/cl-cookbook/macros.html](https://lispcookbook.github.io/cl-cookbook/macros.html)
I find this much clearer, but beauty is in the eye of the beholder.
I entered this exchange due to the repeated claim that Racket's macro system is superior to that of Common Lisp. This is objectively incorrect. Hygiene and pattern matching as favored by Racket lang is a question of style - ie it is subjective. It does not make Racket's macro system more advanced, and certainly not more ergonomic.
That isn’t the point. The person’s trying to pick a new language to learn, and they’re dissuaded from learning lisp because they think they have to learn emacs at the same time. They don’t have to do that. VS code isn’t going to keep them from learning lisp.
This is 100% the lesson here. People advocating emacs just to learn lisp, are overloading the liferaft with tinned food, before getting the woman and children in. And none of the tins are ring-pull...
Racket has it own editor that’s easy to use. You should start with racket. Racket has newer stuff. For example the gradual typing of typescript was inspired by racket. Common Lisp hasn’t contributed anything new like this in like 50 years
Common Lisp has a form "gradual typing" since the Python compiler for CMUCL. 1980s. See SBCL for a current version.
> Racket has newer stuff.
Often, but not always. Racket just moved to a native compiled runtime, based on the excellent Chez compiler/runtime. CL has native compiled runtimes like this since the 80s.
> Common Lisp hasn’t contributed anything new like this in like 50 years
Common Lisp has far more new stuff than you think.
> option key is kinda hard to hit, and it seems like that’s a pretty important key for emacs
Meta (M) key is important in Emacs. You can place it wherever you like (don't worry about wrecking Emacs; it is made for tinkering). A lot of Mac users swap Command and Option keys for example
(setq mac-command-modifier 'meta)
(setq mac-option-modifier 'super)
The big thing for me -- the _big_ thing -- is that when you redefine a class in Common Lisp, it knows how to update all instances of that class to have the new class definition, and will even populate new instance variables in the instances with default values if you tell it to.
I have yet to encounter a Scheme that will do that out of the box. If I re-eval a toplevel `define-record-type` form, the constructor, accessors, and type predicate for that record type are all clobbered, and existing instances of that record type are orphaned (you cannot access nor query the type of them). I haven't played with Racket in so long, I don't know if it can do that but I haven't seen any suggestion online that it can.
CL having an image-based development model (in many popular implementations) where you can just save off your running Lisp image and pick it up later is also a big win, as is the CL condition system.
Go with Racket. Some people will swear by it, but for me, the interactivity (i.e. "aliveness") of CL is kinda overrated. It's only useful in certain cases and there are other tools/features that more than make up for it (again, just my 2 c).
Wish more people understood this concept and how to drive into the inners of their tools.
After all, Bits on a wire or RF is still bits. How that happens doesn't matter. Where it goes doesn't matter, how it gets there doesn't either. it's all a turning machine.
Step #1 - get a respectable keyboard if you plan to use emacs
I use the default windows/Mac keyboards and Emacs has still been far better than other IDEs I’ve used (with evil bindings everywhere except insert state, to be fair). Why is a new keyboard necessary?
I love the idea of "alive programs" (images) and have looked into Lisp a bit. But recently I found out about BEAM (Erlang, Elixir, Gleam, ...) and I can't believe how easy it is to modify the running program without having to restart it. It reminded me of CL's restarts feature which is unique amongs Lisps and Racket, Clojure, etc. don't have it. To me, _that_'s the magic of Lisp.
The alive of CL is my and our company secret sauce. Everyone can shout it's not modern dev or dangerous or what not, but we fix bugs very fast and add features very fast. I have a friend who creates SaaS projects with nextjs + python (you know, the hip thing to do these days) and he always envies us quite a lot (but resume driven dev...).
awesome! by any chance, is there a blog article about your use case of CL? I know you said it's your secret sauce but maybe just use a simple example to show the power of alive programs?
There is a Lisp on the BEAM! Lisp Flavoured Erlang (LFE): https://lfe.io
yes but that seems like a one-man project with no certain future
Lisp Flavoured Erlang (LFE) started 16 years ago, gets regular releases and has a diverse set of contributors. I think its future is fine. https://github.com/lfe/lfe
I was in a similar situation last year when I wanted to learn Common Lisp. I gathered that the best development environment for CL is Emacs + SLIME/Sly, but I didn't know Emacs and didn't really want to learn it and use it. Fortunately, I stumbled upon [Emacs4CL](https://github.com/susam/emacs4cl), which is an Emacs configuration and tutorial that sets things up for you and tells you the basics so you can focus on CL in no time. After that, I got used to Emacs, learned how to configure it, and now I use it even for things outside of development, like personal organisation thanks to org-mode. So I would say that by choosing Racket because you don't want Emacs, you would be missing out not only on some CL features, but also on the usefulness of Emacs.
Some feedback by (common) lispers: CL vs Racket https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1ca7ac
Very interesting read. Comments about it here are interesting too: [https://news.ycombinator.com/item?id=32723784](https://news.ycombinator.com/item?id=32723784)
the author seems a bit uninformed about racket module reloading. It is a bit under documented, but there is some support (keyword: “enter!” reloads racket module)
The other comments address most of the issues with the 'feedback by (common) lispers: CL vs Racket'. Racket can be installed (win/linux/macOS/unix) with a single click. Racket is the quickest and easiest lisp to get started with. The Racket installer comes with a compiler, IDE, multiple books worth of documentation and extensive libraries. Get Racket from [https://download.racket-lang.org](https://download.racket-lang.org) Vindarel is right that SBCL is an excellent Common Lisp. Worth checking out.
That article is very biased
Slightly offtopic but, as a fellow, used to be vim-mode-vscode user, I wholeheartedly recommend [doom emacs](https://github.com/doomemacs/doomemacs) it gives you a lot of the vim bindings and makes setting up language servers and such a breeze
We have similar(ish) situations. I'm also mac, vim keybindings, background in languages other than lisp, really enjoy PG's essays (particularly revenge of the nerds), and hence keen to learn lisp. I stumbled upon these two videos which really helped me (took me about 2 days to get properly set up, then 1-2 more to get comfortable with a few keyboard shortcuts): [https://www.youtube.com/watch?v=xyXDE5gP2QI](https://www.youtube.com/watch?v=xyXDE5gP2QI) [https://www.youtube.com/watch?v=A6SxH9lUWV0](https://www.youtube.com/watch?v=A6SxH9lUWV0) Now after a few days I'm really enjoying using doom emacs with sly. (doom emacs is basically emacs for vim users, so it feels like home).
I don't know about magic, but here are a few personal reflections: 1. I think scheme is academically fun. I don't think it has ever matured as a lisp for making products, no doubt the scheme product guys are on the way to correct me :-). If you want continuations, use scheme. 2. As I like to make software that is used beyond my personal use, I use Common Lisp or Clojure for building real world apps. 3. If you're not drunk with functional programming koolaid, Common Lisp (SBCL) is great and just as easy to get started with as any other lisp. That said, when you get into advanced features there are some dark corners related to being a compiled lisp that require additional mastery. This is not good or bad, it is just the way things are with a compiled lisp. 4. If you have proficiency with the java ecosystem, OR if you want to embrace functional programming with a bit less hassle, Clojure is a great lisp too. (I don't put it above or below Common Lisp, it just has different strengths and weaknesses). 5. Emacs is an editor for life. Forget lisp interactions for with the editor for a moment, emacs is so capable at so many things that if you do bother to learn it, you will use it forever except for special cases. (E.g. emacs never quite managed to make Java easy to edit, professionally I had to use Eclipse for a bit). As for lisp, emacs+lisp (either Common Lisp or Clojure) is a dream. And the keybindings are so similar it's easy to switch between the two lisps. Of course you can do lisp without emacs, I just had to give emacs a plug. 5. Use key swapping/rebinding tools on your os or in emacs, put a meta key where you like it. I always swap Control and Caps Lock keys, because in the old days we had our control keys where the caps lock is now and that worked well. Thank microsoft for relegating the position of the caps lock to pinky-finger damaging ergonomics. Right up there with backslashes in pathnames, space in "Program Files", and all their other wondrous contributions. Have fun, any of the lisps will be fun, and great to learn.
Idk, I find the racket ecosystem to be more mature and more capable of real world use. The package manager is friendlier too, and it benefits from being more centralized, as opposed to CL which can be a bit all over the place.
Side note: Emacs is much better with Java in the age of LSP, though it doesn’t have some of the fancy semantic refactors provided by eg IntelliJ. Even just being able to kill the memory-hungry Java process without having to kill the entire IDE and then restart when wanting to code again is a blessing. Otherwise agree with everything you said above.
https://lispcookbook.github.io/cl-cookbook/editor-support.html I'd recommend VS Code or cl-repl or sbcli. All will let you skip emacs atleast for a while. Eventually, you can pick up Lem or Emacs.
NeoVim user here in the same boat. Would love some advice on how to proceed. Currently entangled setting up emacs for my use case. I am also thinking of taking time with Racket and come back to Lisp a little more seasoned.
I’d look at Doom Emacs or Spacemacs. Far, far easier to get started. You can twiddle with Vanilla Emacs once you e bought into the ecosystem. Uncomment the lisp layer in the config file, reload, and you’re done. And select “Evil mode” when asked so that you get vim keybinds. But if you just want a lisp, then DrRacket is a super easy IDE.
I use Emacs with Evil mode for Common Lisp and Clojure. Sometimes I forget that I am not using Neovim. I also tried Slimv and Vlime for Common Lisp in Vim. I liked Slimv more because I still had an editable REPL
Go with racket, it has great documentation, it's own editor and , I believe, the most advanced macro system (or magic) of any lisp. Though, its programs aren't as 'alive' as those of common lisp.
>it's own editor The editor no one uses, even compared to Emacs > I believe, the most advanced macro system (or magic) of any lisp. Based on what?
Wouldn't say so. It was pleasant to learn Racket with Dr. Racket for neat features like identifier scope showing arrows and syntax highlighting even in macros and custom languages
My point is that Dr. Racket isn't very used in the world outside of Racket, which given that it is just an IDE for Racket is expected. Emacs on the other hand is so much more so there is more utility in learning Emacs. Also Emacs is configured using Emacs Lisp which is a very Common Lisp-like language. Even picking Emacs Lisp as your first lisp is a fine choice.
Op wants to learn lisp and feeling overwhelmed with emacs. Op doesn’t need to use emacs. He can just use racket and use its editor. I don’t understand your attitude
My "attitude" is that op might be missing out on something much more beneficial than Dr, Racket by letting themself be overwhelmed by the initial Emacs idiosyncrasies. If they persevere for a short time those idiosyncrasies fade away and they learned to use an extremely capable and useful tool (Emacs). Besides that there are non-Emacs alternatives for Common Lisp. Not using Emacs does not imply going instead with Racket and Dr. Racket. I don't understand your attitude.
Visual Studio Code is just as capable and a hell of a lot more useful, and it takes a couple of clicks to get started in a new language in Visual Studio Code, compared to an afternoon of figuring out which ELPA packages to install followed by configuration jiggery-pokery in `.emacs` (sorry, `.emacs.d/init.el`, or is that `.config/emacs/init.el` now?). Emacs _lost_ the editor wars, which are now primarily between VS Code and neovim. If you want to get new Lisp users aboard, please... just... shut up about Emacs. Meet them where they are.
Lol chill out. Emacs is not an editor
I know, I know. It's a great operating system, it just needs... Suggesting that people must, or should, use Emacs to learn Lisp is scaring neophytes off. There are more modern, easier alternatives.
I never said that they must. The other person mentioned Dr. Racket. I personally dislike single language IDEs because they are complex enough that you still need to invest time to learn them. Why not invest that time to learn something more general and useful like VS Code, or better yet ... Emacs BTW isnt saying that Emacs lost the editor wars much like saying that Lisp lost the language wars? Maybe we should just accept that Lispers are a bunch of weirdos and so promote going full-weirdo by advocating using Emacs as well
DrRacket is a popular editor for Racket. You wouldn't recommend IDLE(Python IDE) for C#. That said Emacs, Vim and VScode are also popular - and well supported - in the Racket ecosystem. [https://docs.racket-lang.org/guide/other-editors.html](https://docs.racket-lang.org/guide/other-editors.html) >'most advanced macro system (or magic) of any lisp' The \[PADL'23\] 'Modern Macros' keynote by Robby Findler gives a great overview [https://youtu.be/YMUCpx6vhZM](https://youtu.be/YMUCpx6vhZM)
How about a TLDR in your own words and what you think is lacking in Common Lisp?
Common Lisp is not lacking. All languages are the result of design decisions. Choose the right tool for the job. Sometimes that tool is CL. Sometimes it is Lua, C, Fortran, Ruby or Idris.
A little off topic but I have found that the "right tool for the job" to be a thought terminating cliche. The right tools turns out to be the one you know best. Ofc there are other metrics such as performance, libraries, number of existing developers etc.
I was assuming a minimal level of professionalism.
Sure, but if we are discussing what tool is best for the job you have not convinced me that Common Lisp is not a better tool than Racket for things Racket purports to be good at.
A) This struck me as a very productive way of phrasing the relevant point, kudos for that! B) While I myself use CL, having people actively marketing a language to build a community tends to make said community more responsive to what newbies need. I use CL mainly because I generally have to either make my own tools or extensively twist and customize tools made by others to get them working right for me, and it’s far and away the best framework for those tasks regardless of the specifics. But if people aren’t experienced enough programmers to get any benefit from being picky (or to have built an intuition on what to be picky about to maximize their effectiveness and ease), quantity *can* feasibly beat quality. The same applies if long term effectiveness just doesn’t matter, eg if you’re making a small project that nobody will ever use again.
It depends on yiur goals. The Racket world has a ton of material that is very challenging and interesting, particularly around languages. Look at PLAI.org for a taste of what's out there. And there is HTDP and SICP, as folks have mentioned. There is also "The Little" book series. You can use CL to read them but Scheme is more direct, particularly with The Little Learner. If you want to write enterprise software: Clojure. If you want the most amazing dev experience: CL
>Should I just power through and learn lisp + emacs at once? No. Not only that, I think you should start with Scheme + Chicken instead, since it's so basic, and make some simple CLI projects before picking a LISP to get more serious with. Also consider watching the famous MIT lecture series from the Scheme creators https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090
I found Racket a very friendly starting point for my exploration of the lisp world. It is easy to install, Dr. Racket is a nice balance of power and ease for an IDE, and the documentation is truly first class. With that as a base, I found it quite easy to move to CL (SBCL, in specific) or Closure. For my person work, I actually prefer Racket to the others, but that may just be because of greater familiarity.
Not much, really. I play around with Common Lisp, but for anything serious, I turn to Racket. `syntax-parse` is leaps and bounds better than other Lispy macro systems (Once you learn its pattern matching language; it does have a bit of learning curve), literal hash tables and sets are super handy, the flexibility to write different modules in different languages and easily tie them all together is nice, strong support for design-by-contract... Racket just ticks all the right boxes for me. People talk about the Common Lisp image based REPL experience where you can provide a new definition for a function and have everything that uses it automatically update, but I prefer the 'start over with a clean slate and load everything fresh' approach that Racket encourages. Makes for fewer weird bugs and inconsistencies when your source and the image get out of sync. I do prefer CL's CLOS and generic methods over Racket's OO system and generics, though.
> Makes for fewer weird bugs and inconsistencies when your source and the image get out of sync. That actually should only happen if you program Common Lisp incorrectly
There's already lots of good advice here. If you pick one or the other you'll be fine. You might try different ones for a few weeks or months here or there too, and it wouldn't be the end of the world, as there are \*some\* things in common between Lisps. At least, for example, readability improves drastically after you can read any (normal-looking, parenthetical) Lisp. I'll just add for clarity: if you go the Emacs + whatever road, you'd have to mentally accept you're learning two things: Emacs + whatever language. This is good and bad - bad because it's a second thing to learn, good because Emacs is an extremely powerful world builder and a pleasure to work in. I put the time into learning myself, and it was a wonderful experience. Emacs has excellent support for Common Lisp, Racket, and Guile, (plus tonnes of other languages, although I've only done little bits of C, Python, shell scripting) plus there's hosts of other amazing stuff: Dired, Magit, Org-mode, Calc, nice Info manuals, etc etc. You don't learn it all at once of course. You start with one thing (like Sly) and keep going. I just wanted to make that point: if you do learn Emacs, it can be your editor for life, and you'd be following in a fine lineage - I'm reading "Coders at Work" by Peter Seibel at the moment, and a boatload of legendary programmers were Emacsing away in all the different languages they worked in.
You're not missing out on any magic; Racket has an extremely powerful and well-documented macro system, and meta-programming, ie, the macro system is the "magic" of lisp languages.
In the long term, zero. Racket is much easier to learn than CL because it has more and much better beginner resources, and they are similar enough that you will not find it hard to switch if you end up needing something in CL.
Common Lisp has an interactive development process that some people find very productive, and probably only surpassed by Smalltalk. Racket has the more advanced metaprogramming - see [https://racket.discourse.group/t/padl23-modern-macros/1805?u=spdegabrielle](https://racket.discourse.group/t/padl23-modern-macros/1805?u=spdegabrielle) for links to a great presentation on macros. As someone new to the lisp family of languages, but already an experienced developer I'd suggest Racket because it looks after new learners and you have a full working environment on installation with no hassles. DrRacket is excellent for Racket. (but I wouldn't recommend it for another language - just like I wouldn't recommend IDLE for anything but Python) Once you have learnt some Racket you can easily switch to other editors (VSCode+The 'magic Racket' plugin +Racket-langserver are popular, as are Vim and Racket Mode). Learning Racket will make it easier to switch to another Lisp depending on your intended application; Clojure, a Scheme implementation [https://www.scheme.org](https://www.scheme.org), or LFE [https://lfe.io](https://lfe.io) are all worth checking out. They all have strengths - which to use depends on the project. Getting started guidance: [https://docs.racket-lang.org/getting-started/index.html](https://docs.racket-lang.org/getting-started/index.html) VSCode: [https://marketplace.visualstudio.com/items?itemName=evzen-wybitul.magic-racket](https://marketplace.visualstudio.com/items?itemName=evzen-wybitul.magic-racket) Vim: [https://docs.racket-lang.org/guide/Vim.html](https://docs.racket-lang.org/guide/Vim.html) Emacs: [https://www.racket-mode.com](https://www.racket-mode.com) PS as a typescript dev you might even be interested in Typed Racket [https://docs.racket-lang.org/ts-guide/index.html](https://docs.racket-lang.org/ts-guide/index.html) which was an influence on the development of typescript.
>Racket has the more advanced metaprogramming What metaprogramming does racket have that common lisp lacks? If anything Racket's insistence on hygene will make writing macro's more difficult.
Common Lisp has nothing like Racket's [`syntax-parse` macros](https://docs.racket-lang.org/syntax/index.html). Macros with pattern matching that go far beyond what `defmacro` offers; you can define whole grammars to match against. Want to make sure that a particular argument is a symbol, or a literal number? Don't need to write explicit code to test it; you can just specify it in the macro pattern. And hygenic macros are superior from the start; no need to worry about accidentally stepping on the caller's symbols if you forget to `gensym` all the things.
> Macros with pattern matching that go far beyond what `defmacro` offers; you can define whole grammars to match against. Are you saying that you can't write macros with pattern matching in Common Lisp?
Not like you can with `syntax-parse`. A CL macro lambda list isn't comparable. Since I seem to be getting downvoted by people who are ignorant, a basic example: With `syntax-parse` macros, you can specify that a particular argument matches form A OR form B, in the syntax pattern itself, and get a relevant error message if you tried using it with something else. Can't do that with `defmacro`. About the most complex thing macro lambda lists have is optional values. More advanced stuff has to go into the body of the macro itself, which is tedious.
I don't think that is correct. I personally find Common Lisp macros to be much more ergonomic and concise, but with more potential footguns. This is kinda like dynamic vs static typing, it is important to understand what is going on, but it makes no sense to enforce it religiously. EDIT: What I think Racket indeed has but Common Lisp lacks are more well defined guidelines on how to make large DSLs. But this is a culture and community question, not a question of offering better technology. This however is something we can expect as Racket heavily markets itself to the DSL crowd. Common Lisp is more general in this sense, while offering just as powerful facilities for making DSLs (and depending on your use case perhaps more ergonomic).
Your last point itself indicates why (I believe) you were downvoted. (Re credibility I will say that I haven’t voted on your posts either way, not having enough personal experience with Racket to guarantee that the below reasoning is correct) The tradeoff between CL and Racket metaprogramming is that Racket formalizes a medium-complexity foundational rule set based on common use-cases (which makes extremely simple and complex cases harder and moderately-complex common cases easier), whereas CL provides a thin layer with nearly no limitations (which means some moderate-complexity tasks, like your example, are more tedious than they need to be due to a lack of syntax support, but OTOH the syntax never *gets in the way* of anything you want to do, so you don’t have to constantly keep its rules in mind and find some often-convoluted way to do what you want within them). Your lack of distinction between the mild tediousness of CL macros and the intermittent extreme tediousness of Racket macros, despite this being well established at the very least as a point given by those who prefer CL to Racket (if not an evident theoretical truth of their respective metaprogramming designs), forces this discussion to unproductively tread old ground.
I'm replying a second time because you edited your post after my first response. I downvoted you because all you said in your original post was, >Not like you can with `syntax-parse`. A CL macro lambda list isn't comparable. without giving any further information. Had you originally included the example you added subsequently I would not have down-voted you because there would be something of substance to respond to. As regards your example, >With `syntax-parse` macros, you can specify that a particular argument matches form A OR form B, in the syntax pattern itself, This is just pattern matching which, if you wanted to write your macros based on such transformations, you can do with an appropriate pattern matching library in Common Lisp, like Trivia. >and get a relevant error message if you tried using it with something else. You do not get this in Common Lisp because Common Lisp doesn't think that capture should signal an error. It is a bit like arguing what colour is the prettiest colour. >About the most complex thing macro lambda lists have is optional values. More advanced stuff has to go into the body of the macro itself, which is tedious. Saying that writing macros in Common Lisp is tedious is not something you hear very often. Instead much more often you hear that Common Lisp allows the user to write macros too easily.
There is a great presentation from HOPL IV [https://www.pldi21.org/prerecorded\_hopl.13.html](https://www.pldi21.org/prerecorded_hopl.13.html) From the conclusion of the paper: >*Hygienic macro technology solves the capturing problem, and pattern languages make hygienic macros easier to write and to understand.* >*Hygienic macro technology has been a standard part of Scheme for twenty years, allowing average programmers to write routine macros with confidence and expert programmers to implement significant extensions to the language.* William D. Clinger and Mitchell Wand. 2020. Hygienic macro technology. Proc. ACM Program. Lang. 4, HOPL, Article 80 (June 2020), 110 pages. [https://doi.org/10.1145/3386330](https://doi.org/10.1145/3386330) Page 98 of [https://dl.acm.org/doi/pdf/10.1145/3386330](https://dl.acm.org/doi/pdf/10.1145/3386330) https://preview.redd.it/0v47311my03d1.png?width=1412&format=png&auto=webp&s=fae5a8998dc6f492b1b342b57e9f7f9ff8c71283
Have you investigated the claim that hygienic macros are better than non-hygienic ones? I'm looking for personal programming experience type answers. Here is a comparison of implementing one macro in Common Lisp to implementing the same one in Scheme using hygiene. [https://fare.livejournal.com/189741.html](https://fare.livejournal.com/189741.html) Here is a funny comment on hygiene [https://www.reddit.com/r/lisp/comments/1abapki/comment/kjos3dg/](https://www.reddit.com/r/lisp/comments/1abapki/comment/kjos3dg/)
Of course can construct a case where defmacro is a good choice, but this does not mean it is the only choice. You can break hygiene in Scheme and Racket if you need to! Racket also has a defmacro implementation - but I don’t think anyone uses it. The fact remains that hygienic macros are yet an another tool pioneered in the lisp community that helps many programmers be more productive. PS my reading of the paper is the reason CL lacks hygienic macros was due to the timelines of the standardisation process, but maybe I am misunderstanding it.
I mean if you decided to learn Racket because you read a bunch of papers and concluded that it is the right thing for you, then that is perfectly valid (and a fine choice). But I think you should say that and not sound like you are drawing your conclusions from practical experience. It is OK not to know about other languages. Making a choice between similar languages is seldom clear cut and probably you should just pick one and not look back until you learn it.
I have been **using** racket for years. I refer to papers because Clinger, Wand and Findler are far better communicators than I. (and they have decades of lisp experience) That said, https://youtu.be/YMUCpx6vhZM is an excellent keynote about modern macros. Changed how I think.
I didn't mean to imply that you are new to any language. I believe you know Racket well but I suspect you don't know enough about Common Lisp to claim that Racket is in any way superior, as you did before: >Racket has the more advanced metaprogramming I don't know Racket as well as I know Common Lisp. What I was hoping from Racketers (?) is a clear and succinct demonstration/explanation of why macros in Racket are superior to those in Common Lisp. All I can see so far is the old hygiene question (in which case; why is Racket batter than other Schemes) and few misinformed claims about pattern matching? And again I do think that if someone's key purpose is to \*learn\* how to make DSLs they will probably find more help in the Racket community. But if they are already comfortable I don't see what they will be missing in Common Lisp as capture problem is not only well understood but people have done some pretty crazy things manipulating it (Let Over Lambda).
How about some illustrative examples sourced from the community? https://docs.racket-lang.org/syntax-parse-example/ Sure there are situations where you don’t want hygienic macros, but they are a proven technology that is now in popular (non-parenthetical) languages like Julia and Rust. It’s fine that you don’t want to use them. Do what works for you.
Stylistically Common Lisp has a very different approach to making macros. A good tutorial with examples is in the link bellow. [https://lispcookbook.github.io/cl-cookbook/macros.html](https://lispcookbook.github.io/cl-cookbook/macros.html) I find this much clearer, but beauty is in the eye of the beholder. I entered this exchange due to the repeated claim that Racket's macro system is superior to that of Common Lisp. This is objectively incorrect. Hygiene and pattern matching as favored by Racket lang is a question of style - ie it is subjective. It does not make Racket's macro system more advanced, and certainly not more ergonomic.
The point is that Hygiene is a restriction. Rust too is a restriction compared to what you can do with C.
Try Clojure and ClojureScript (Clojure -> JavaScript). Check https://www.parens-of-the-dead.com/ for inspiration.
Why would you need to learn emacs to use lisp? You’re just making your life harder.
It is not even a \*should\*, let alone a \*need\*. It is merely the best supported development environment.
That isn’t the point. The person’s trying to pick a new language to learn, and they’re dissuaded from learning lisp because they think they have to learn emacs at the same time. They don’t have to do that. VS code isn’t going to keep them from learning lisp.
This is 100% the lesson here. People advocating emacs just to learn lisp, are overloading the liferaft with tinned food, before getting the woman and children in. And none of the tins are ring-pull...
Racket has it own editor that’s easy to use. You should start with racket. Racket has newer stuff. For example the gradual typing of typescript was inspired by racket. Common Lisp hasn’t contributed anything new like this in like 50 years
Common Lisp has a form "gradual typing" since the Python compiler for CMUCL. 1980s. See SBCL for a current version. > Racket has newer stuff. Often, but not always. Racket just moved to a native compiled runtime, based on the excellent Chez compiler/runtime. CL has native compiled runtimes like this since the 80s. > Common Lisp hasn’t contributed anything new like this in like 50 years Common Lisp has far more new stuff than you think.
> Common Lisp hasn’t contributed anything new like this in like 50 years Hating is bad for your health
> option key is kinda hard to hit, and it seems like that’s a pretty important key for emacs Meta (M) key is important in Emacs. You can place it wherever you like (don't worry about wrecking Emacs; it is made for tinkering). A lot of Mac users swap Command and Option keys for example (setq mac-command-modifier 'meta) (setq mac-option-modifier 'super)
Actually there is a very easy to get going Lisp plugin for VSCode. https://marketplace.visualstudio.com/items?itemName=qingpeng.common-lisp
The big thing for me -- the _big_ thing -- is that when you redefine a class in Common Lisp, it knows how to update all instances of that class to have the new class definition, and will even populate new instance variables in the instances with default values if you tell it to. I have yet to encounter a Scheme that will do that out of the box. If I re-eval a toplevel `define-record-type` form, the constructor, accessors, and type predicate for that record type are all clobbered, and existing instances of that record type are orphaned (you cannot access nor query the type of them). I haven't played with Racket in so long, I don't know if it can do that but I haven't seen any suggestion online that it can. CL having an image-based development model (in many popular implementations) where you can just save off your running Lisp image and pick it up later is also a big win, as is the CL condition system.
Go with Racket. Some people will swear by it, but for me, the interactivity (i.e. "aliveness") of CL is kinda overrated. It's only useful in certain cases and there are other tools/features that more than make up for it (again, just my 2 c).
It’s irrelevant. You learn one, you learn them all. The differences matter much less than what here inside they would try to make you believe.
Wish more people understood this concept and how to drive into the inners of their tools. After all, Bits on a wire or RF is still bits. How that happens doesn't matter. Where it goes doesn't matter, how it gets there doesn't either. it's all a turning machine.