[HN Gopher] Common Lisp vs Racket
___________________________________________________________________
Common Lisp vs Racket
Author : ducktective
Score : 202 points
Date : 2022-09-05 12:56 UTC (10 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| mark_l_watson wrote:
| Depends 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 wrote:
| How 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 wrote:
| HRL 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
| MichaelCollins wrote:
| > _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.
| kasajian wrote:
| I just can't get past referring Scheme as "schemes". Forcing
| myself to read the rest of the article. Am I getting punk'ed?
| thaumasiotes wrote:
| > 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 wrote:
| I 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.
| neilv wrote:
| Some 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 , 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.
| discardable_dan wrote:
| This analysis is spot on. The author is annoyed about the
| absence of many things that, in most programming languages,
| would be seen as outright absurd. People have come to realize
| multi-methods, monkey-patching, and mutable interfaces break
| down when writing code at scale, across a large team. It's no
| surprise that Racket has internalized these lessons, and
| someone in love with Common Lisp would see these as
| shortcomings. A Haskell programmer could similarly rant about
| Python's lack of closures, a C++ programmer about JavaScript's
| lack of templates, and so on. There are many reasons to hate
| many languages, but "that language isn't this language" is a
| rather petty one.
| joppy wrote:
| Where are you finding $500k python jobs?
| atemerev wrote:
| Common Lisp is awesome. SBCL is fast, there are a lot of decent
| libraries (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 wrote:
| For 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?
| whartung wrote:
| Honestly, watch some of this series.
|
| Kaveh's Common Lisp Lesson 01
| https://www.youtube.com/watch?v=nSJcuOLmkl8
|
| He doesn't take you by the hand to setup an environment, but
| it's a neat exposure (introduction isn't quite the right
| word) to someone using CL to do interesting things.
|
| Mind its a bit Mac and Clozure CL specific if you wanted to
| follow along, but it's still a good watch of just seeing
| someone doing stuff without explicitly telling you what
| they're doing. Sometimes you just want to get stuff through
| osmosis, and he does interesting, basic things with CL at all
| sorts of levels.
| Jach wrote:
| Maybe start with 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.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/).
|
| 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/ (has
| some emacs gifs) that shows some of these features. But
| notably again, the experience isn't limited to emacs.
| pjmlp wrote:
| A Common Lisp example that leaves out Lispworks and Allegro
| Common Lisp focusing only on SBCL + emacs, as usual.
| Shorel wrote:
| Wasn't the price of these implementations one of the factors
| for the (symbolic) AI winter?
|
| I would say it's just karma.
| forgotpwd16 wrote:
| Not at all. Both of those projects started inside the second
| AI winter. They can even be seen as an attempt to save Lisp
| after the market collapse for Lisp-specialized hardware. That
| said tooling for other contemporary languages was high as
| well back then. Won't be surprised if relatively to the total
| costs for them LispWorks and ACL were cheaper.
| lispm wrote:
| These implementations survived the AI Winter, despite their
| high prices.
|
| A lot of the cheaper commercial implementations did not
| survive or did not thrive: Corman Lisp (now open source, but
| not used much), Golden Common Lisp, Exper Common Lisp,
| Procycon Common Lisp (got bought by Franz), MuLisp, Macintosh
| Common Lisp, ...
| phoe-krk wrote:
| Care to pay the author for an Allegro CL and/or LispWorks
| license so they can broaden their article?
| pjmlp wrote:
| Community licenses are available, I don't need to pay
| anything.
| guenthert wrote:
| Lets assume the author shared his experience, rather then a
| comparison of features. Experience gained by actual usage.
| Those community licenses are severely restricted, to the
| point of being unattractive (to me and I suspect many
| others). I cannot be bothered to sign up and install
| crippleware when productive tools are available for free.
| LW might be best thing since sliced bread, but I'm afraid,
| I'll never know for sure.
| pjmlp wrote:
| And yet those community features offer a better graphical
| development experience, InteliJ of Lisp, so to speak.
| _ph_ wrote:
| They offer a more graphical development experience. Yes.
| Whether it is better than Slime, would need to be
| discussed. But the point is quite irrelevant in the
| moment, when you just cannot develop anything due to
| memory limitations.
| lispm wrote:
| I would think that one of their advantages is that they
| have GUIs more similar to what the underlying platform
| looks and feels. This is easier to learn and easier to
| use, compared to tools based on GNU Emacs, which is
| basically its own platform. There are a lot user
| interfaces in GNU Emacs which are not very user friendly
| and not so good looking.
| _ph_ wrote:
| Yeah, the Emacs UI is definitely a bit lacking. It could
| be greatly improved if they embraced Gtk a bit more.
| Especially if some widgets could be handled from elisp.
| But what it lacks in polish, it often makes up with
| usability, once you are a more advanced user. And of
| course, the sky is the limit for customizability.
|
| I haven't used the recent versions of ACL and LW, so I
| cannot make a direct comparison, but for the experienced
| user, Emacs offers a lot of productivity.
| phoe-krk wrote:
| And severely limited at the same time, to the point where
| people, IMO understandably, prefer to use 100% free
| alternatives rather than write about the subpar experience
| available with "community licenses". Free versions of both
| LW and ACL have major hurdles that are getting in the way
| of developing software on these implementations.
| pjmlp wrote:
| That subpar experience is still better.
| _ph_ wrote:
| Not if your lisp image exits even with simple programs.
| e3bc54b2 wrote:
| SBCL is de-facto most popular implementation of Common Lisp, if
| I dare say. It is free, it is well maintained, it is easily
| available, and it is fast. As a student/enthusiast, it doesn't
| get much better.
|
| Lispworks/Allegro is better if specialized requirements or
| actual money is on the table. Lispworks supports mobile
| platforms IIRC which SBCL does not, for ex. But if all one
| needs is server side deployments or personal projects, there is
| no need, nor any use of commercial implementations, as good as
| they might be.
| _ph_ wrote:
| One has to stress: SBCL is probably by far the best Lisp
| compiler out there. So it is not only free, but also good.
| Might require a few type annotations to get the best
| performance though. And the diagnostic messages can sometimes
| be annoying, but they are right :)
| avodonosov wrote:
| My choice is CCL
| xhevahir wrote:
| The last I heard CCL still didn't support Apple's new range
| of processors, which sounds bad for its future.
| pjmlp wrote:
| Basically like GCC with VI, or using Clion or Visual Studio
| kind of difference.
| medo-bear wrote:
| but 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 wrote:
| And so the knowledge of a poor development experience for
| Common Lisp keeps spreading.
| abrax3141 wrote:
| Who 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.
| pjmlp wrote:
| Compared 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 wrote:
| Yeah, but that's just complaining that just because we
| used to have flying cars we still should. We decided as a
| society to give up on flying cars. They're gone. Move on
| with your (our) boring 2D lives.
| ryukafalz wrote:
| I don't think it's fair to say that we've given up on
| Lisp machines because we chose to do so. Most people
| never got to experience them to begin with! Certainly not
| enough people to build as thorough a software ecosystem
| as we expect nowadays.
| medo-bear wrote:
| i think you mean sbcl+emacs+slime/sly. straight sbcl is
| pretty limited
| abrax3141 wrote:
| To be clear, slime isn't necessary.
| dang wrote:
| Please don't take HN threads into internecine PL flamewar.
| It's not in the interests of the thread, the HN community,
| or the Lisp community.
|
| On HN, we've always particularly wanted to avoid the nasty
| tribal fights that have afflicted CL discussions in the
| past.
| pjmlp wrote:
| It is not a flamewar, rather being deprived of the
| knowledge of what a full blown Common Lisp experience
| used to be like.
| dang wrote:
| Yes but we need you to make those points substantively,
| neutrally, interestingly--without swipes or putdowns:
| https://news.ycombinator.com/newsguidelines.html. If you
| just post grumpy one-liners we're going to get a
| flamewar, and the primary fault for that lies with the
| comment that starts it.
|
| I know from many past comments that you have a ton of
| knowledge to share--it would be way better if you would
| explain some of that to the rest of us, rather than
| holding it back and just giving us a shallow version of
| your final conclusion, with a pointed end.
| chalst wrote:
| This is, like some other of your comments, very
| condescending. I won't speculate on what you hope to
| achieve by these remarks, just comment that I don't think
| this kind of condescension has done Common Lisp much good
| over its history.
| pjmlp wrote:
| Oh well, I already know how Common Lisp environments of
| yore used to be like.
|
| If others don't care to learn about them so be it.
| abrax3141 wrote:
| I've used all of these semi-extensively (slightly less so
| LW). The environments you get with FL and LW are useful if
| you aren't an experienced Emacs user, and each of the pro
| ones comes with a lot of useful support (and FL's amazing but
| expensive gdb), but these days, if all you want to do is get
| programming done, and don't need, or don't want to pay for a
| highly supported world-class engineering platform, you can do
| pretty much everything you want at a lot less cost and weight
| with sbcl, emacs, amd some calling to python. Libraries. If
| some multi-millionaire wanted to do the world a solid, they'd
| buy and open source (and pay for continuing support) for FL.
| aidenn0 wrote:
| As a lifelong vi user, SLIME is useful even if you aren't
| an experienced emacs user.
|
| For a while I used SLIME as my debugger and vim as my
| editor.
| ctrlmeta wrote:
| How do you use SLIME in Vim? Isn't SLIME written in Emacs
| Lisp which runs only in Emacs? Honest question how you
| could run an Emacs package in Vim?
| Jach wrote:
| To provide a bit more context, most of SLIME is just
| Common Lisp code (https://github.com/slime/slime), with a
| bunch of Emacs Lisp code alongside to support interfacing
| with Emacs. But you don't need that Emacs Lisp code to
| take advantage of almost all of the functionality SLIME
| provides. For instance, if you want to know who-calls a
| function, there's some command in emacs to do it, but all
| that command is doing is just a bit of elisp code which
| sends a message to Swank (a server running inside Common
| Lisp) and Swank invokes some native CL code to figure
| that out and return the results, then finally a bit of
| elisp code presents the results in some way. Vim can do
| the same thing just fine with vimscript/python (what the
| Slimv plugin uses) or otherwise, the bulk of the work in
| figuring out the list of callers of some function is done
| by the CL code (and CL implementation itself).
| Jtsummers wrote:
| SLIME is, but there is Slimv which is a SWANK client for
| vim:
|
| https://github.com/kovisoft/slimv
|
| (Never used it myself so can't comment on it beyond
| noting its existence.)
| hiptobecubic wrote:
| You don't. You run it in emacs. That's what they are
| saying.
| aidenn0 wrote:
| I have an article I wrote about how I did this, but may
| have lost it to time.
|
| The short version is I have SLIME running inside Emacs,
| and my text files open in vim. I would just reload the
| changed file(s) when needed (originally with cl:load-
| file, then later with asdf, which is roughly "make" for
| lisp). I used slime similarly to how I would use gdb. It
| was a big improvement over using vim with the clisp[1]
| REPL both because SLIME was more powerful than the clisp
| repl, and because it worked with other implementations
| like CMU CL (which sbcl now is a fork of).
|
| I mostly just used the menus for interacting with emacs,
| but since the shortcuts are listed beside commands, I did
| learn the more commonly used ones.
|
| I continued like this for years until I discoveredevil-
| mode[2], which was the first thing close enough to vim to
| be usable for me (and even then I had to add a few
| keybindings that it was missing).
|
| 1: clisp is a specific implementation of common lisp, not
| an abbreviation
|
| 2: https://github.com/emacs-evil/evil
| ducktective wrote:
| I'm inclined to try to learn a Lisp, but the tight
| integration with Emacs is putting me off. I spent a lot
| of time and effort to learn vim and I'm wondering why a
| family of languages should be _this_ dependent on a
| specific editor...
| abrax3141 wrote:
| It's not. You can use any editor. Emacs just happens to
| have a package called slime that helps - I'm told. I've
| been using just lisp+emacs w/o slime for decades. To be
| clear, except for slime, which as above is optional, any
| editor will do just fine.
| Jtsummers wrote:
| > why a family of languages should be _this_ dependent on
| a specific editor...
|
| The language isn't, but SLIME is because emacs isn't
| _just_ an editor, it 's a platform and system that people
| develop applications on top of. And the community was
| already there, using emacs, to continue with that option.
| e3bc54b2 wrote:
| > I'm wondering why a family of languages should be this
| dependent on a specific editor...
|
| As mentioned by others, its not. But Emacs is also a Lisp
| runtime. People who are attracted to Emacs eventually
| learn some Lisp (Emacs Lisp, closer to CL than Racket et
| al) or were attracted because of Lisp in the first place.
| As a result, the overlap between CL devs and Emacs users
| is naturally higher than that for other editors. This
| translates into people developing more and better tools
| for their editor, and higher popularity usually
| translated into more and better tools (with obvious
| exceptions).
|
| As mentioned by other commenters, SLIME can be used with
| Vim too, if that's your thing. But just like SBCL, Emacs
| is kinda of de-facto editor of choice, not by force, but
| by love of its users :)
| whartung wrote:
| I've done the vast bulk of my CL work using just vi.
| Specifically, I was doing the typical "reload the lisp
| file" life cycle, rather than the interactive "just
| redefine this defun" style of development. Even when I
| used Lispworks, it was "save file, reload it" style of
| development.
|
| I used CLISP because it had GNU readline. (e) to edit my
| file, (l) to reload it, and off to the races (I wrote
| those trivial defuns). No packages, no imports, no asdf.
| Everything in CL-USER.
|
| I did switch to emacs for one simple reason: tab to
| reindent. Other than that it was the most basic of emacs
| use (load file, save file, ^s to search, cmd-XCV for cut
| and paste, pgup, pgdn). No Sexpr navigation, no buffer
| juggling, none of that, no lisp integration whatsoever
| outside of paren matching and the tab to indent.
| abrax3141 wrote:
| Aw, dude, if you're not buffer juggling - esp with three
| or four shells! - you're missing out on one of the great
| joys/mysteries of life!
| _ph_ wrote:
| Besides that I can only recommend Slime, you can
| basically convert any program that doesn't use readline
| into one via rlwrap. Very useful :)
| db48x wrote:
| SLIME is a third-party tool that integrates with Common
| Lisp; it isn't part of the language. With most Common
| Lisp implementations you can just use the repl to call
| (inspect _foo_ ) to see what slots _foo_ has and their
| values. It will probably be a little clunky since
| drilling down into the details might require you to type
| numbers at a prompt. Meanwhile SLIME presents the same
| information in a UI, so you can click on things (or type
| the numbers if you prefer).
|
| It just happens that SLIME is a pretty well designed UI
| (the acronym stands for Superior Lisp Interaction Mode
| for Emacs, so I guess that was the goal). It's miles
| ahead of what you get from most other languages, even
| C++, but most of what makes it so great comes from
| features that were already present in the language
| implementations. It also combines very well with other
| advanced Emacs packages such as Paredit.
|
| Interestingly, SLIME is implemented as a network protocol
| to allow for remote debugging, so you can implement a new
| UI for it any way you want. I've never used it, but you
| might check out SLIMV instead.
| https://www.vim.org/scripts/script.php?script_id=2531
| klipt wrote:
| You can emulate vim key bindings in Emacs with ViperMode.
| aidenn0 wrote:
| No you can't. evil-mode gets pretty close though.
| xigoi wrote:
| Vim isn't just keybindings.
| Jach wrote:
| Join me vim brother and don't settle for forcing yourself
| to use emacs while developing in CL when you don't have
| to! You even have two vim options!
| https://github.com/kovisoft/slimv and
| https://github.com/vlime/vlime with a great comparison of
| the two: https://susam.net/blog/lisp-in-vim.html
| thisgyjuijhyeee wrote:
| You make it sound like SBCL is an also ran. SBCL powers
| Google flights.
| abrax3141 wrote:
| Def didn't mean that. I use sbcl+emacs all the time. It's
| my go to platform. I've used FL and LW but don't need
| them. SBCL+emacs is all you really need. (I started
| lisping before slime so never really got into it. If it's
| half as good as folks claim then maybe square all of the
| above. But someone else will have to chime in on that.)
| medo-bear wrote:
| what calls to python libraries are you referring to?
|
| i think it would be nice for someone to do a comparison of
| development in emacs+slime vs allegro cl vs lisp works
| abrax3141 wrote:
| Unfortunately I've rolled my own ugly python ffi just to
| use python libraries. It's slow as frozen honey bcs it
| gets to the great python libraries by slogging through
| python itself to do the data (de)muxing. That millionaire
| I mentioned should figure out how to get sbcl to call to
| python packages directly.
| AlexeyBrin wrote:
| What Common Lisp implementation is FL ?
| abrax3141 wrote:
| Sorry. Allegro used to be called Franz Lisp. ACL would be
| a more correct usage.
| larsbrinkhoff wrote:
| Although Franz Inc supported Franz Lisp and developed
| Allegro Common Lisp, it is my impression they are
| distinct implementations. I can't find any hard evidence
| one way or another. Do you know?
| abrax3141 wrote:
| A think FL just morphed into ACL by renaming, and
| probably some code changes, but not reimplementation, but
| not having been there, I'm not 100% sure. Since then, of
| course, it's essentially a different implementation bvo
| many revs.
| lispm wrote:
| They say Allegro CL was a new implementation written from
| scratch:
|
| https://franz.com/about/company.history.lhtml
| [deleted]
| santimoller66 wrote:
| greymalik wrote:
| Am 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 wrote:
| At 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.
| abrax3141 wrote:
| Scheme diverges from lisp pretty fast.
| rscho wrote:
| I am surprised to hear that multiple namespaces with
| identical symbols is not a source of confusion for learners.
| IMO, in high school I would've been lost.
| pdimitar wrote:
| All 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.
| reikonomusha wrote:
| There 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.)
| Syzygies wrote:
| Wow, 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.
| SighMagi wrote:
| Lparallel is typical employed for transparent parallelization,
| thread management etc. https://lparallel.org/cognates/
| amitprayal wrote:
| I think I would be better to compare CL with Clojure rather than
| Racket...since Clojure has found some usage outside academia
| medo-bear wrote:
| from the same person ...
| https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1...
| jmeister wrote:
| Thanks.
| pjmlp wrote:
| Industrial use of Common Lisp,
|
| https://franz.com/success/
|
| http://www.lispworks.com/success-stories/
| ctrlmeta wrote:
| I 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 wrote:
| I got it the other way around, oops.
| fredrikholm wrote:
| OP 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).
| pjmlp wrote:
| I got it the other way around, oops.
| p_l wrote:
| Not even exactly the scripting language, more so that they
| used PLT Scheme (now Racket) for writing tooling, including
| compiler into various scheme variants they used as internal
| scripting in games.
| nextos wrote:
| I'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 wrote:
| for 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 wrote:
| I'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 wrote:
| There is no shortage of Lisp compilers.
|
| The new Racket compiler was derived from the Chez Scheme
| compiler.
| simongray wrote:
| Or how about all three + Java:
| https://clojure.org/reference/lisps
| Syzygies wrote:
| A document that puts these differences in context is Rich
| Hickey's "A History of Clojure"
|
| 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/
| amyjess wrote:
| > 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.
| boohoohoo123 wrote:
| I 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 wrote:
| Is it because you are used to vim bindings? Emacs offers an
| "evil mode" that implements modal bindings
| amyjess wrote:
| I 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.
| Jtsummers wrote:
| You 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).
| yyyk2 wrote:
| The 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.
| lispm wrote:
| The best GUI support for Common Lisp one gets from the
| commercial implementations Allegro CL and LispWorks. Both have
| cross-platform GUI libraries (ACL for Windows and Gtk,
| LispWorks for Windows, Gtk, macOS and Motif). Both have their
| IDE implemented with their respective GUI library. If one would
| wants to write a substantial GUI application in Common Lisp,
| that's one of the reasons people pay quite a bit money for
| those implementations and for commercial support.
|
| There have been very substantial GUI applications implemented
| with both systems.
| rscho wrote:
| I'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 wrote:
| > 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.
| zelphirkalt wrote:
| > 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.
|
| A language does not necessarily become limited, when it is
| simple. If the right simple concepts are available, all
| kinds of stuff can be build with them, bootstrapping more
| complex concepts or features. It becomes rather a question
| of how much is already there, done by others, or how much
| work oneself want to put in to have some concept in ones
| language. So I wouldn't necessarily say, that it becomes a
| limited language.
| rscho wrote:
| Scheme is geared towards two things: research and teaching.
| It's a lingua franca for demonstrating implementations of
| new CS concepts in ways that members of the community
| understand. Being easy to implement from scratch is a must
| for both uses cases. Being a less imperative language also
| makes Scheme closer to the math.
| _ph_ wrote:
| There are also TK bindindings https://github.com/herth/ltk
| reikonomusha wrote:
| I'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/
|
| [1] https://docs.racket-lang.org/guide/macros.html
|
| [2] https://www.greghendershott.com/fear-of-macros/
|
| [3] https://docs.racket-lang.org/macro-debugger/index.html
|
| [4] https://docs.racket-lang.org/guide/languages.html
| pyb wrote:
| Unfortunately, I think perhaps might have come to a different
| conclusion if you'd tried Racket's so-called "hygienic" macros
| in anger. I've found them difficult to properly understand, not
| very usable in practice, and overly complex for non-trivial
| cases.
|
| This is not what you'll usually read in forums, I think
| DEFMACRO is the better design here.
| reikonomusha wrote:
| Racket's macro system is quite baroque and supports a lot of
| things. You don't need to use hygienic "syntax-rules" at all.
| Consider writing your own transformer [1], which can be an
| arbitrary lambda function without restriction.
|
| Or, import defmacro [2] and use that.
|
| As can be seen, Racket actually provides more power and
| choice in this regard, including support for Common Lisp's
| way.
|
| In any case, I make no claim to either being better or worse.
| I just think Racket is more principled in its mechanisms for
| defining and delivering a DSL to a user.
|
| [1] https://docs.racket-lang.org/guide/proc-macros.html
|
| [2] https://docs.racket-lang.org/compatibility/defmacro.html
| pyb wrote:
| Agree with "Racket is more principled..." Where I differ
| with you if that I'd say that Racket theorically provides
| more power, but the system is not tractable in practice. I
| suspect all large Racket programs were written by people
| with PhD's from Northwestern.
|
| BTW, Racket's defmacro is only partially compatible with
| Common Lisp defmacro. It doesn't really work. I even seem
| to remember (? from long ago) that it's impossible to
| implement a genuine CL defmacro in Racket.
| soegaard wrote:
| You are hanging out in the wrong forums :-)
|
| The `defmacro` model is "simpler", true - but it is fragile
| and breaks down when you want to do complicated things.
|
| Check this blog post written by someone, who knows hos Common
| Lisp.
|
| EVAL-WHEN considered harmful to your mental health
| https://fare.livejournal.com/146698.html
| Jach wrote:
| More to the point of how simple (and easy) defmacro is
| compared to syntax-case and syntax-rules, I like another
| fare post: https://fare.livejournal.com/189741.html If
| you're as smart as fare, it "isn't too hard to translate
| it".
|
| Though I concede this case could be analogous to trying to
| write a Doubly Linked List in Rust, it's not enough to say
| definitively yea or nay. So I'd more like to see a concrete
| case you have in mind where the tradeoffs are squarely
| against CL. Like, the loop macro is more complicated than
| any I have written myself, but you can break it down, and
| it's not that bad -- I think Norvig's version is pretty
| neat to study: https://norvig.com/paip/loop.lisp This
| project (and it's not the only one!) adding C syntax to CL
| https://github.com/y2q-actionman/with-c-syntax I think is
| more complicated than loop, and is sort of where I'd put
| the level of "complicated things" at that I'd like to see
| an example from the Scheme world that clearly shows
| defmacro's deficiencies on some metrics. (Fewer bugs?
| Easier to add new features to? Shorter code? Faster
| performance either at compile time or runtime or both?
| Easier to understand or faster to implement for people with
| similar levels of skill in the language?)
| bmitc wrote:
| What about package management? I feel Racket's is more
| standardized. I get pretty confused trying to install some
| requested Common Lisp packages. Browsing to the package
| websites, there's no commonality, and there's even usually no
| information on how to install them.
| Jtsummers wrote:
| https://www.quicklisp.org/beta/
|
| Quicklisp has become the main way many (most?) people handle
| installing a library for Common Lisp. Under the hood, ASDF is
| used for defining the system and specifying how it should be
| compiled and such as has also been standard in the community
| for a very long time.
| db48x wrote:
| I've never used Racket, but reading your description of the
| documentation (and Scribble) makes me want to check out that
| aspect of it. I wonder how it compares with rustdoc? I do
| mostly Rust these days and its generated documentation is
| usually really good.
| db48x wrote:
| Oh, I see. Scribble looks a little like TeX, but actually
| it's an alternate read syntax/dsl. The first example where
| they show off the real utility of it is:
| @tabular[#:sep @hspace[1] (list (list
| @bold{Animal} @bold{Food}) (list
| "mouse" "cookie") (list "moose"
| "muffin"))]
|
| which really drops it in your lap. "tabular" isn't from some
| fixed list of keywords, it is an ordinary racket function
| that you can call, with ordinary arguments that can be
| strings, lists, etc. Presumably there will be an example in
| the next page or two with @define[...] in it to close the
| loop.
|
| And the table of contents promises literate programming as
| well. Someone was really thinking when they put this
| together; I really like it.
|
| The documentation generated for individual functions (such as
| <https://docs.racket-
| lang.org/scribble/base.html#(def._((lib....>) is fairly nice
| as well. Readable, linked together by hyperlinks on the type
| predicates as well as hyperlinks in the body of the
| documentation itself; it's pretty good. Rustdoc puts links to
| the source code for each one though, and I would soon miss
| that.
| lispm wrote:
| See Scribe from the end 70s:
| https://en.wikipedia.org/wiki/Scribe_(markup_language)
| sph wrote:
| The generated Rust docs... are not very good. And on more
| complex types you have a ton of traits, with methods and all
| their lifetimes and generic parameters which are really hard
| to follow if you're unfamiliar with a library or Rust in
| general. Also, even the biggest libraries (clap for example)
| reserve a couple paragraphs for the front page prose and
| leave the type docs to speak for themselves... which is just
| not good enough.
|
| I would go as far as to say that a non-negligible part of why
| people are intimidated by Rust is the rustdoc format and
| layout. Thankfully it makes up for it with an incredible Rust
| Book.
|
| To me the gold standard of docs is Elixir followed by Racket.
| Even Go's docs are better than Rust, but that's mostly
| because of a much simpler type system, so simpler
| autogenerated docs for structs and their methods.
| db48x wrote:
| I really got annoyed by the Go package docs after I
| programmed in Go regularly for about a year. They were just
| so artless and flat. Each one is just a big list of all the
| stuff in the package, with no indication that the code has
| any structure to it at all. It was a few years ago though;
| perhaps it has gotten better?
|
| Scribble beats rustdoc hands-down when it comes to
| authoring documentation, but even with Rustdoc you can do a
| good job of it if you try
| (http://db48x.net/reposurgeon/rust-port-
| docs/reposurgeon/path...). I'll have to check out Elixir
| next.
| sph wrote:
| Go docs are pretty terse and lifeless, agreed.
|
| Here's an example of Elixir docs:
| https://hexdocs.pm/ecto/Ecto.html
|
| Note the layout, the amount of prose to introduce a
| module and the function documentation that is not limited
| to just a quick line but often has multiple examples and
| tries quite hard to be clear and extensive.
|
| There is no reason Rust docs couldn't be that good, but
| the example has to come from the top: improve the std
| docs, and everything will follow suit.
| cultofmetatron wrote:
| ecto and phoenix are shining examples of well written
| docs but its hardly the standard for elixir as a whole.
| many of the docs for most libraries are just lists of
| functions. some might have a short description though
| you're usually relying on a dialyzer definition at best.
| sph wrote:
| Fair enough, but neither Ecto nor Phoenix are part of the
| stdlib, but being written by the some of core language
| maintainers with such a focus on documentation, they
| provide a great example for everybody to follow. Having
| excellent docs on the core libraries, the main SQL
| datamapper and web framework is the reason why Elixir is
| so loved even though it's quite a niche language.
|
| As a new Rust fan I would just love to have the std docs
| half as good as Elixir's. I constantly get lost in
| rustdoc.
| michaelwww wrote:
| As someone trying to understand what people find special about
| Lisp, this was helpful. I get it now about macros, but doesn't
| modifying the language in the compiler phase just complicate
| solving the actual runtime problem? I feel I would get
| distracted into writing my own DSL. I've never wanted to modify
| the language as I was writing in it.
| adamddev1 wrote:
| I've loved using Racket docs while working through HTDP. Very
| clear pleasant to search/look through. Great definitions both
| with formal specification as well as practical examples, and
| all the types etc are nicely hperlinked together.
| abrax3141 wrote:
| https://lisp-journey.gitlab.io/blog/overview-of-documentatio...
| klipt wrote:
| > 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.
|
| We have to go deeper! Could you write a DSL in CL to help you
| write new DSLs as easily as in Racket?
| zelphirkalt wrote:
| This is what Racket people have done to write Typed Racket in
| it. I think it is called Turnstile: https://docs.racket-
| lang.org/turnstile/.
| rscho wrote:
| I don't think typed racket uses turnstile? At least, typed
| racket is far older than turnstile is.
| zelphirkalt wrote:
| Huh, I was under the impression, that it was based on
| turnstile and was sure, that I saw that somewhere, but
| now I cannot find any indication of it being the case. So
| maybe I am mistaken.
|
| Nevermind then, turnstile is still something fitting for
| this topic : )
| ruricolist wrote:
| I have a project to do that,
| https://github.com/ruricolist/vernacular, although I'm not
| working on it right now.
| Labo333 wrote:
| Those days I'm really rooting for PicoLisp
| (https://picolisp.com/wiki/?home)
___________________________________________________________________
(page generated 2022-09-05 23:00 UTC)