19 ms·
Common Lisp vs Racket
- dunefox 4y agoI don't use either and both languages are on my todo list, but I think I would have already used Racket if I liked the editing experience more - DrRacket is just not going to cut it, if I'm completely honest. CL with Spacemacs is pretty good.
- amitprayal 4y agoI think I would be better to compare CL with Clojure rather than Racket...since Clojure has found some usage outside academia
- pjmlp 4y agoIndustrial use of Common Lisp, https://franz.com/success/ https://franz.com/success/ http://www.lispworks.com/success-stories/ http://www.lispworks.com/success-stories/
- ctrlmeta 4y agoI think the parent comment is suggesting that a comparison of CL vs. Clojure is more useful than the current comparison of CL vs. Racket.
- pjmlp 4y agoI got it the other way around, oops.
- fredrikholm 4y agoOP questioned Rackets use in industry, not CL. AFAIK, the only (more known) uses of Racket is as a scripting language for Naughty Dogs PS3-era games, and it was made to make Arc (which runs HN).
- simongray 4y agoOr how about all three + Java: https://clojure.org/reference/lisps https://clojure.org/reference/lisps
- Syzygies 4y agoA document that puts these differences in context is Rich Hickey's "A History of Clojure" https://download.clojure.org/papers/clojure-hopl-iv-final.pdf https://download.clojure.org/papers/clojure-hopl-iv-final.pd... The design decisions in this paper strongly resonate with me. It helped me to overcome my aversion to JVM-hosted languages, and settle down to learn Clojure. I'm a research mathematician, at one extreme where code is steps up a mountain. I don't need to summit twice, so productivity is far more important than speed. Nevertheless, the fastest Clojure time trials use GraalVM: https://www.graalvm.org/ https://www.graalvm.org/
- medo-bear 4y agofrom the same person ... https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1025e4 https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1...
- jmeister 4y agoThanks.
- nextos 4y agoI've written quite a lot of Clojure and some Racket, but never really settled down on CL aside from reading PCL and most of PAIP. In other words, I never coded something sufficiently big to understand the pros of CL. Hence, I'm curious. What stuff I'm missing out in terms of language features and libraries?
- medo-bear 4y agofor me the following things stand out use common lisp (sbcl) if you want c-level performance use common lisp if you want to make optimizing compilers use common lisp if you want smalltalk type repl driven interactive development
- rscho 4y agoI'm not a compiler expert by any means, but I would've thought the more functional nature of racket to be a plus for writing compilers. Plus, there's the nanopass framework.
- lispm 4y agoThere is no shortage of Lisp compilers. The new Racket compiler was derived from the Chez Scheme compiler.
- medo-bear 4y agoohh ... almost forgot ... CLOS https://en.m.wikipedia.org/wiki/Common_Lisp_Object_System https://en.m.wikipedia.org/wiki/Common_Lisp_Object_System
- abudabi123 4y agoI'm curious to know what was lost to the Lisp users in the change on Apple's Newton device going from the early Ralph implementation in Lisp to cplusplus. On r/lisp there was a rant that included a reflection that things would be done in a third the time. There was an ask for $60M to apply Lisp to know a different world. Apple can easily afford a $180M experiment to see Ralph/Dylan implementation of iOS/macOS. If proved successful would the software platform leap how the hardware has done across multiple architectures? The ARM M series devices are a there and back again move given Apple Newton was on ARM and Apple invested which kept the idea alive.
- pjmlp 4y agoA Common Lisp example that leaves out Lispworks and Allegro Common Lisp focusing only on SBCL + emacs, as usual.
- medo-bear 4y agobut sbcl is far more common than those two. its also free, unlike those two. i think this is ok as long as its stated cleary (and it is)
- pjmlp 4y agoAnd so the knowledge of a poor development experience for Common Lisp keeps spreading.
- abrax3141 4y agoWho said poor development environment. Emacs is a terrific lisp editor and straight sbcl (or any real lisp) is a better dev env than almost any other straight pl env.
- medo-bear 4y agoi think you mean sbcl+emacs+slime/sly. straight sbcl is pretty limited
- abrax3141 4y agoTo be clear, slime isn’t necessary.
- pjmlp 4y agoCompared to how Lisp Machines used to like, yes it is poorer. Commercial CL environments are the surviving ones that still offer a similar experience.
- abrax3141 4y ago
- santimoller66 4y ago[dead]
- kasajian 4y agoI just can't get past referring Scheme as "schemes". Forcing myself to read the rest of the article. Am I getting punk'ed?
- thaumasiotes 4y ago> I just can't get past referring Scheme as "schemes". That isn't something that happens in the article. Compare this sentence: >> Now if you still want to use Scheme, Racket blows the other Schemes out of the water with what you get out of the box. […] But it is not without its problems. > Am I getting punk'ed? Only by yourself.
- kbutler 4y agoI prefer _schemes_ over _Common_Lisps_, and I prefer Racket of the Schemes. The author is just using the plural to acknowledge there are multiple variants of the scheme and common list languages and environments. This is not uncommon.
- greymalik 4y agoAm I missing the part where it says the specific use cases the author is speaking about? It sounds like their arguments are based on ”real-world” development, while my guess is that Racket might fare better when you’re looking strictly at a tool for learning.
- dj_mc_merlin 4y agoAt the beginner (high school / undergrad) level all Lisps are more or less the same. The finer points of Lisp-1 vs 2, CLOS, etc. are not comprehensible without a lot of prior work.. and by that point you should optimize for real world practice anyway IMO (something which many university courses do not do). If we're talking middle school then there are some arguments to be made that Racket's easy-to-use graphics libraries are more conductive to learning. It will never be Flash though.
- atemerev 4y agoCommon Lisp is awesome. SBCL is fast, there are a lot of decent libraries (https://awesome-cl.com/ https://awesome-cl.com/), and you can use it immediately in production. Lisp REPL-centric development requires some adjustment, and basically* you don't have other IDE options besides Emacs with Slime or Sly, but Common Lisp was the reason I finally learned how to live with Emacs. * — there are also Slyblime for Sublime Text and ALIVE for VS Code, but they are very beta-quality.
- klipt 4y agoFor someone who's never used Emacs properly, what's a good tutorial for using Emacs together with CL in the synergizing ways that people claim are so amazing?
- Jach 4y agoMaybe start with https://lispcookbook.github.io/cl-cookbook/emacs-ide.html https://lispcookbook.github.io/cl-cookbook/emacs-ide.html The 'magic' though isn't really that emacs dependent; if you like vim (like I do) you can use vim and still get that amazing experience. https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... has some details on alternatives. Anyway, the magic or synergy is really a combination of: CL itself being designed to support interactive development, a little server you embed (typically automatically if starting from an editor) in a running CL program called Swank, and a standard set of commands to talk to that server (and the underlying Lisp) and interface with your editor called SLIME (https://slime.common-lisp.dev/doc/html/ https://slime.common-lisp.dev/doc/html/). The basics of the commands do things like send code over for compilation and redefining things, running things, responding to errors, debugging things, jumping to definition locations.. things you'd normally expect an IDE to do, except because of CL itself so much of that is part of the language and not a separate IDE. Some more editor-specific things come into play that some people really love, and while they may be best done in emacs they're not unique to emacs either. (Example: suppose you messed up the order of your arguments to a function, so it's written like (my-func (list something) some-other-arg) -- editors have support to swap those two arguments in one go, rather than having to backspace and retype or whatever. I personally don't find such features that magical, and are table-stakes even for things like Eclipse editing Java. Meanwhile even emacs is still weak for some things like large-scale automated semantics-aware refactoring...) I'm fond of this short 5-part blog series https://malisper.me/debugging-lisp-part-1-recompilation/ https://malisper.me/debugging-lisp-part-1-recompilation/ (has some emacs gifs) that shows some of these features. But notably again, the experience isn't limited to emacs.
- mark_l_watson 4y agoDepends on what you are working on. I happen to like Racket a lot but no one has ever paid me money for Racket development. In the last 40 years, lots of paid Common Lisp work. Racket’s portable GUI and app builder are very good, as is LispWorks’.
- mhaberl 4y agoHow do you find CL gigs? What kind of companies/apps use CL? Are they all legacy systems? How does it pay in relation to projects using "mainstream" languages?
- reikonomusha 4y agoHRL Laboratories writes new code in Common Lisp for quantum computing. They have internships and full-time positions. Google employs Common Lisp programmers as well for their flight search product. RavenPack, SISCOG, GrammaTech, Grammarly, SRI (?), MIND.AI, and others as well (or at least used to). Check out [1]. [1] https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies
- mark_l_watson 4y agoI have written two Common Lisp books, one for Springer Verlag and one self published- that helps.
- MichaelCollins 4y ago> Racket’s portable GUI and app builder are very good, Ehh.. they're pretty good and I'm thankful for them. I don't think I'd go as far as 'very good' though; the selection of widgets provided is basic. My rule of thumb is that if your application only needs the sort of functionality you can find somewhere in DrRacket, then racket/gui will be pretty good. But if you need a widget you can't find in DrRacket, then you'll probably have to implement that widget yourself.
- reikonomusha 4y agoI'm a heavy user of Common Lisp, and I only dabble in Racket from time to time. While Common Lisp is my tool of choice for a lot of reasons stated in the post, since the post largely skews favorably toward Common Lisp, I'll offer two things that Racket shines at: 1. Documentation Racket has a beautiful documentation system called Scribble [0]. Almost all documentation written for Common Lisp is ugly, inconsistent, and doesn't follow any sort of standard. Common Lisp has a gazillion "documentation generators" which do little more than slurp up all the documentation strings and barf them back out as e.g. HTML. Common Lisp users tend to just rely on READMEs + jump-to-definition to learn how a project works. A few Lisp programmers (e.g., Shinmera, Edi Weitz) have made their own documentation systems that look better than average, but are still at least an order of magnitude less capable than Racket's offering. Racket's documentation system is aesthetically pleasing, very well organized, and makes the programmer want to write long-form documentation. Moreover, Racket (the language) sets a superlative example of what its users can strive for in terms of quality of clear, no-nonsense writing. 2. Languages and DSLs One of Lisp's (any dialect) defining features is the ability to build domain-specific languages, syntactic extensions, and the like by way of a special kind of function that can run prior to the code's execution. These special functions are called "macros", and across Lisp dialects, there are lots of different takes on them. Common Lisp gives you a grab bag of facilities for writing code that lets you change syntax at different levels: DEFMACRO (scoped variant: MACROLET), DEFINE-COMPILER-MACRO, DEFINE-SYMBOL-MACRO (scoped variant: SYMBOL-MACROLET), SET-MACRO-CHARACTER, and a few others. At best, I'd consider these only loosely related, and they all work on really "raw" data representations (parsed S-expressions and character streams). In part because of this, ANSI Common Lisp doesn't provide access to any notion of environment, source location, etc. when writing new macros. Macros defined by the above operators "live" in different places and are compartmentalized in different ways. There are some Lisp libraries that help you tame definitions and keep them fenced in, like NAMED-READTABLES which helps you organize where reader macros (macros which change how Lisp is parsed at the character-level) live and how to turn them off and on in a sane way. Contrast with Racket which has explicit documentation on how to write macros [1,2], how to debug them [3], and how to encapsulate them a new DSL embedded in the system [4]. Racket—as a technical system—clearly defined the phases of compilation, what objects are manipulated during the phases (e.g., "syntax objects"), how to provide debugging information, and so on. In the end, Common Lisp's system for making DSLs feels a little runny. It's supremely hacker-friendly, but it's a bit more difficult to deliver, in one fell swoop, a language as a library. Racket, on the other hand, at the expense of having increased rigidity and needing to read two or three complete chapters of a manual, you get a way to neatly bundle up a language. This is why Racket had nice DSLs like Typed Racket, Hackett, Scheme RnRS, etc. I use Common Lisp and I develop relatively large DSLs in the language, and even if I want to, it's hard—if not impossible—to write large DSLs that have nice error messages, source locations, etc. without writing an entirely new "reader" (lisp's term for a code parser) myself every time. Smaller DSLs where user code doesn't exceed more than a few lines? Examples like: - regex syntax - string interpolation syntax - a pattern matching feature Common Lisp is great, and you get a ton of mileage out of the facilities it provides. But larger ones? Examples like: - an embedded language for writing documentation with markup - a complete language with lazy evaluation semantics - a language for non-deterministic programming (like SCREAMER, Prolog) - a language for strictly typed functional programming (like Coalton, Hackett) Tackling these in Common Lisp requires ambition and a very steady hand, whereas Racket's overall system (language, implementation, documentation) makes that a comparatively painless exercise. [0] https://docs.racket-lang.org/scribble/ https://docs.racket-lang.org/scribble/ [1] https://docs.racket-lang.org/guide/macros.html https://docs.racket-lang.org/guide/macros.html [2] https://www.greghendershott.com/fear-of-macros/ https://www.greghendershott.com/fear-of-macros/ [3] https://docs.racket-lang.org/macro-debugger/index.html https://docs.racket-lang.org/macro-debugger/index.html [4] https://docs.racket-lang.org/guide/languages.html https://docs.racket-lang.org/guide/languages.html
- yyyk2 4y agoThe GUI situation in Common Lisp is pretty pitiful. AFAIK the best you get is ECL+QT5 or cffi-cl-gtk (which is GTK 3). I don't see a very favorable comparison for Racket at all in anything else though. When people talk about the benefits of Lisp, they are usually talking about the benefits of /Common/ Lisp. Other languages often misunderstand what makes Common Lisp so great, like in the case of Scheme's overly complex pseudo-macro system.
- vindarel 4y agoyeah… there are good IUP bindings, and embedding a CL web app into Electron (or Neutralino) is easy, once you have your standalone binary (I'll blog about that). https://github.com/CodyReichert/awesome-cl#gui https://github.com/CodyReichert/awesome-cl#gui
- _ph_ 4y agoThere are also TK bindindings https://github.com/herth/ltk https://github.com/herth/ltk
- rscho 4y agoI'd argue that the brightest minds in computer science understand what makes lisp great perfectly. In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme... which sports much more than 'a pseudo-macro system'.
- yyyk2 4y ago> I'd argue that the brightest minds in computer science understand what makes lisp great perfectly. That is your personal opinion. Personally, I consider the design of Common Lisp to be much superior. > In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme... If by "their use case" you mean teaching CS, then I would agree. > which sports much more than 'a pseudo-macro system'. Well, Scheme doesn't really have many features. It's meant to be a simple (and by extension limited) language. I mentioned their pseudo-macro system since it's one of the parts where Scheme (badly) disconnects from its Lisp lineage.
- pdimitar 4y agoAll of that barely matters to me. Where's the transparent parallelization? 2022 is going to be over soon, no language has any excuse to lack an easy way to do message passing and automatic thread pool management like Erlang and Rust's `tokio` do.
- Syzygies 4y agoWow, I did a double take, you sound like me. When I said something similar praising Haskell's effortless parallelism, someone made a reply that lead to my learning Clojure.
- pdimitar 4y agoThat Haskell has a transparent parallelism is news to me. Does it do the things that Erlang does? Or at least Rust's `tokio` async runtime?
- ywei3410 4y agoYes, Haskell has green threads/co-routines. Racket /also/ has `thread` which is a co-routine but afaik you cannot pass the co-routine off to another native thread and there are certain constraints passing data between different threads, similar to transferring ownership. I am not aware of the SBCL ecosystem to comment.
- invisiblerobot 4y agohttps://youtu.be/sl2zo7tzrO8 https://youtu.be/sl2zo7tzrO8 HAXL
- SighMagi 4y agoLparallel is typical employed for transparent parallelization, thread management etc. https://lparallel.org/cognates/ https://lparallel.org/cognates/
- reikonomusha 4y agoThere is a good excuse: Not having multi-{m,b,t}illion-dollar corporate entities working on the language full-time is a good reason for something to not exist. Not having a corporation back the development of a language has tons of downstream effects, including: - lack of support opportunities - lack of employment opportunities - lack of evolution and development of an ecosystem - higher churn and/or attrition - fewer opportunity to do long-term design and implementation projects Yes, sometimes there are FOSS miracle workers who are so extraordinarily productive without being paid, but they're few and far between. (Aside from that, not all users need such functionality.)
- neilv 4y agoSome of these objections are the author taking well-known properties of CL as must-haves, and evaluating other languages against them. Considering them must-haves is perfectly reasonable for a programmer who wants to work in that style. For example, being able to (put roughly) modify any part of the system at any time, and let the semantics decide what happens. Scheme/Racket absolutely is not CL, and Racket has been moving further away from CL than Scheme already was. I've worked on critical production systems in both Scheme/Racket and CL professionally, and they are very different languages, and people wouldn't confuse them if they didn't both use S-exp syntax. (Individual Lisp family developers are also different. There are some shared memes, but you don't end a Lisp family language expert today, and shunning that $500K Python job, without being stubbornly self-motivated and/or self-destructive.) One of the keys to learning Scheme originally was to put aside my biases about what was important, try to use and then understand the idiomatic way, so that you can then decide what makes sense. (Examples: My own first bias when learning Scheme was trying to micro-optimize for runtime as I coded, like I would in C, but I didn't know what cost model I should reason about. If you look at the first Scheme code I wrote, https://pkgs.racket-lang.org/package/html-parsing https://pkgs.racket-lang.org/package/html-parsing , it's a little like a C programmer with some non-Scheme Lisp experience.) One of the next barriers was learning to avoid mutations and premature exits, and to leverage tail recursion. Before I learned that, I couldn't have told you that can make code easier to read.) When we were first learning computer things, there was an implicit suspension of disbelief or acknowledgement of not knowing. As we grow more knowledgeable, we have to be careful not to plateau or become rigid, assuming we know the right way, and dismissing things that are nonintuitive. Sometimes we will be right to dismiss them (and often will be, in corners of "tech"), but sometimes we will miss out. It's even not necessarily a net loss if we invest in understanding a perspective, and then determine its flaws, because we may still have added some new useful ideas to our mental toolkit.
- amyjess 4y ago> A better developer experience. Emacs + Slime is way better development and debugging experience than either Emacs + Geiser, or Emacs + Racket-Mode or Drracket. I've thought about learning a Lisp in the past, but the Lisp community's insistence on using Emacs has completely put me off of it. I will not use Emacs under any circumstances, and you couldn't pay me enough money to change. And this had lead me to conclude that Lisp is simply not for me.
- Jtsummers 4y agoYou can always use a commercial Lisp vendor's solution or vim + slimv for CL or Dr. Racket for Racket. There are other comments in this thread about the vim + slimv alternative to emacs + slime (I don't use it myself since I learned emacs as a freshman in college and stuck with it, so check out their comments to get an idea of how its done).
- boohoohoo123 4y agoI don't think anyone insists that you use Emacs? Anyway, not sure why anyone but you should care about you learning something? Everyone have to deal with their own psychological barriers somehow.
- dr-neptune 4y agoIs it because you are used to vim bindings? Emacs offers an "evil mode" that implements modal bindings
- amyjess 4y agoI have multiple reasons for not wanting to use Emacs. I detest every facet of the UI, among other things. Also I don't care about Vim bindings. I use Kate for writing code about 75% of the time anyway and would prefer to continue doing so.
- Jach 4y agoWhat do you use the other 25% of the time? Anything in https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... ? I've never used Kate before now, but I gave it a spin. Seems you could use it for some primitive Lisping (certainly to just teach yourself the basics, or make edits to existing programs), but I wouldn't recommend it long-term. A big win with Lisp is in interactive development, so you want an editor that supports something like Slime -- particularly the ability to have a running program and interactively run code, which might define new functions or redefine old ones or change some state, whatever, and have such changes immediately take effect. I suspect a plugin for Kate could be made, but I didn't see one after a very brief search. The maintainers probably want to encourage more use of LSP anyway. There is an LSP server for Common Lisp, but it's pretty basic, and is still at odds with how you want to do things. (Perhaps Clojure has a more developed one.) It at least "works" with Kate in the sense that Kate successfully launches and talks to it after making a custom settings.json, and gives me simple symbol completion and docstrings on hover. But to learn about my own functions and their docstrings, I need to be able to load my code into the Lisp instance that's also running the LSP server. (Traditionally IDE-ish features in Lisp aren't done by external tools statically scanning files, but by introspectively asking the Lisp program itself for the info, which may include file info.) I did hack something together so that I was able to copy-paste some code from Kate to the split terminal panel running a second instance of Lisp that talked to the one Kate launched, but this isn't very productive. You could maybe get by with writing some code, saving, and then reloading the whole set of files (system) with one command when you want, but you'd need even more work to make errors interactively recoverable, which is another really nice feature of Lisp development when you have proper editor support.
- Labo333 4y agoThose days I'm really rooting for PicoLisp (https://picolisp.com/wiki/?home https://picolisp.com/wiki/?home)