[HN Gopher] Common Lisp Implementations in 2023
___________________________________________________________________
Common Lisp Implementations in 2023
Author : oumua_don17
Score : 209 points
Date : 2023-02-23 11:16 UTC (11 hours ago)
(HTM) web link (www.n16f.net)
(TXT) w3m dump (www.n16f.net)
| [deleted]
| LegendaryPlayer 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."
| SimplySweet4 wrote:
| [dead]
| orthecreedence wrote:
| Sad to see Clozure CL abandoned, that was my main squeeze back in
| my lisp days (I was on Windows and SBCL wasn't cut out for it at
| the time). How's SBCL on Windows these days?
| kazinator wrote:
| CCL is not "abandoned". I recently brushed the dust off an
| application that I last released in 2014. It uses CCL on
| Windows. I was pleased to see there is a recent new version
| from 2021. I upgraded to that and did some new work, making new
| releases.
| orthecreedence wrote:
| Well, that's good, but the article made it sound like it was
| no more. Maybe it's just that it's feature-complete.
| lispm wrote:
| There are bugs which have not been fixed, maybe they are -
| who knows. For example on ARM processor it dies in
| multiprocessing.
|
| Next: CCL comes originally from the Mac platform (the
| original Coral Lisp started on the early Mac, Apple even
| owned Macintosh Common Lisp for a few years, that code was
| used to create OpenMCL, aka Clozure CL) and there is still
| no Apple Silicon port and there is no real progress to get
| there.
| Ashemush8 wrote:
| I won't list expired job announces, but this year Lispers could
| apply for jobs in: web development(WebCheckout, freelance
| announces), cloud service providers (Keepit), big-data analysis
| (Ravenpack, and chances are they are still hiring)), quantum
| computing (HLR Laboratories), AI (Mind AI, SRI International),
| real-time data aggregration and alerting engines for energy
| systems (3E); for a startup building autism tech (and using CLOG
| already); there have been a job seeking to rewrite a Python
| backend to Common Lisp (RIFFIT); there have been some bounties;
| etc.
|
| Prior Lisp experience was not 100% necessary. There were openings
| for junior and senior levels, remote and not remote (Australia
| for "a big corp", U.S., Spain, Ukraine...).
| Cloudy_days7 wrote:
| [flagged]
| smcn wrote:
| There was a great comment about LispWorks over on the reddit
| discussion, linked here[0]. I really need to give it a shot at
| some point, especially as someone doing CL professionally.
|
| I know that Lisp is popular on HN but that it's mostly a kind of
| zoo like experience where the _proper_ devs come here to gawk at
| us but I really cannot recommend it enough for any kind of work.
| We use it for stock market analysis but almost every piece of
| code we write is CL. I 'm currently trying to convince people to
| switch over our CSS over to LASS[1].
|
| 0:
| https://www.reddit.com/r/Common_Lisp/comments/11979q4/commen...
|
| 1: https://github.com/Shinmera/LASS
| CitySlicker6 wrote:
| [flagged]
| 147 wrote:
| There's a weird spike in new accounts with what appear to be AI
| generated comments in this thread.
|
| One problem I run into when learning Common Lisp is ASDF. For
| some reason I can't figure out how to use it properly. For
| example, when I open a system definition in a new REPL, what's
| the expected workflow? I'm using emacs and slime by the way.
| Maybe my environment is set up wrong. I also have to prefix the
| `defsystem`s with `asdf:`. When I look at examples in open source
| projects they just straight up use `uiop` functions and
| `defsystem` in their `.asd` files without the package.
| Avshalom wrote:
| >There's a weird spike in new accounts with what appear to be
| AI generated comments in this thread.
|
| There's also a chatbot company on the front page posted by a
| new account. I kinda suspect they're related.
| dutchblacksmith wrote:
| Just use quicklisp, it handles ASDF in a nice manner. Then jou
| just grow into using ASDF.
| galdor wrote:
| What do you mean by "open [...] in a new REPL"?
|
| You use ASDF:LOAD-SYSTEM to have ASDF load all the content of
| the system, making it available to you.
| 147 wrote:
| I edited the comment to add some additional details.
|
| Am I not supposed to load or compile the contents of an
| `.asd` file?
| galdor wrote:
| No you do not have to. ASDF knows where to find your ASD
| files:
|
| https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-
| to-f...
|
| Personally I use the (:tree (:home "dev/lisp")) form.
| vindarel wrote:
| Just don't put a node_modules/ in there!
| 147 wrote:
| Thanks a lot for this actually. I just gave it a shot and
| it seems to have been the piece I've been missing.
| lispm wrote:
| You need to have ASDF itself loaded into your Lisp.
|
| Yes one can also load system definitions, they are Lisp code.
| But usually it is expected that they are found automatically,
| when calling a system operation (load, compile, ...), when
| registered correctly.
| arethuza wrote:
| As a former "good old fashioned AI" researcher who used Lisp
| (LispWorks) between '89 and '95 this seems oddly appropriate!
| vindarel wrote:
| This should help: https://lispcookbook.github.io/cl-
| cookbook/getting-started.h...
|
| The workflow is:
|
| - open the .asd file,
|
| - compile it so that your Lisp image knows about it: C-c C-k in
| Slime, or (asdf:load-asd "project.asd")
|
| - you are ready to "quickload" it.
|
| The link shows how you can tell ASDF to find your projects at
| startup, so than you can "quickload" it directly.
| nidnogg wrote:
| Thanks, I honestly felt a bit gaslighted with the way no one
| was mentioning anything about these accounts.
| SuperGamer2 wrote:
| The author of the first post said he was "migrating from Common
| Lisp to Julia as [his] primary programming language". He was
| starting "to grow increasingly frustrated with various aspects of
| the language" and the CL ecosystem. Many of his arguments were
| harsh towards CL and didn't mention existing better alternatives.
| GirlFunk87 wrote:
| [flagged]
| Ninja_cat8 wrote:
| [dead]
| AnnieMannie8 wrote:
| [flagged]
| FoodieFatty9 wrote:
| "Finally, there's the XLISP-STAT archive. Prior to Luke Tierney,
| the author of XLISP-Stat joining the core R team, XLISP-STAT was
| the dominate statistical computing platform. There's heaps of
| stuff in the archive, most at least as good as what's in base R,
| that could be ported to Lisp-Stat."
| noloblo wrote:
| if sbcl significantly faster than racket why and when do
| practitioners use racket?
| _ph_ wrote:
| What do you mean by that? A lot of people use racket, a lot of
| people use SBCL, which is indeed significantly faster. They are
| actually completely different software for different purposes
| and very different strengths.
| noloblo wrote:
| what are strengths of sbcl over racket?
|
| what are strengths of racket over sbcl?
|
| if sbcl raw speed > racket speed wouldn't most expert lispers
| by default choose sbcl?
|
| what purposes does racket uniquely serve not served by sbcl?
| _ph_ wrote:
| > what are strengths of sbcl over racket?
|
| SBCL is a Common Lisp implementation, racket implements
| variants of Scheme. SBCL is natively compiled, creates
| standalone executables.
|
| > what are strengths of racket over sbcl?
|
| It implements various scheme dialects, the ability to
| integrate different languages in one image is unique. It
| offers an integrated enviroment with a lot of libraries
| included, that is why it is popular in academia.
|
| > if sbcl raw speed > racket speed wouldn't most expert
| lispers by default choose sbcl?
|
| First of all, they implement different programming
| languages, that means they are not competing directly with
| each other and are very different beasts as discribed
| above. Racket seems to be very popular in academia, while
| SBCL is more used for practical software development. At
| least that is the impression I have.
|
| > what purposes does racket uniquely serve not served by
| sbcl?
|
| I think I have answered that above.
| lispm wrote:
| > the ability to integrate different languages in one
| image is unique
|
| Somehow.
|
| It should be possible to load a C, Prolog and Python
| implementations into one sbcl image.
|
| The Symbolics Lisp Machine emulator I use comes with C,
| Pascal, Fortran, several Common Lisp variants, Lisp
| Machine Lisp in one image.
|
| Kalman Reti once gave a demo how to debug mixed Lisp and
| C code in a REPL on such a Lisp Machine:
| https://www.youtube.com/watch?v=o4-YnLpLgtk
| wk_end wrote:
| They're completely different languages. Common Lisp isn't
| Racket. Racket is "a Lisp", but it's not Common Lisp (or
| even Scheme, which it's much more closely based on). You're
| writing something like:
|
| If Java raw speed > TypeScript raw speed wouldn't most
| expert curly-bracers by default choose Java?
|
| Differences include all the differences different languages
| have: features (hygienic macros, continuations, conditions,
| CLOS, ...), libraries (standard or otherwise), tooling...
| vindarel wrote:
| This LispWorks comment on reddit is very interesting:
|
| ---
|
| [cite]
|
| As a Lispworks user, yes it is super pricey, but it does make
| sense for certain people. Arguably, Lispworks provides features
| that aren't available in any other programming language, Lisp or
| not.
|
| * Support for just about every platform I can imagine. Yes it's
| expensive, but if I want to port to a new platform I can pay
| Lispworks, and get it over with. It'll mostly work without too
| much changes. It works on Android, iOS, Windows, Linux, Mac, and
| some really obscure systems.
|
| * Application delivery with tree shaking. May be there are other
| languages that do this, but I haven't worked with something like
| this before in my career. (Maybe proguard for Java, but that's
| very rudimentary compared to LW's delivery). The tool I work on
| delivers a binary that people need to download during the CI jobs
| for every run, so having it be 100MB is way too big. After
| compression, my LW delivered binaries come to around 9MB.
|
| * You mention support being expensive. Actually, for simple
| support questions LW does a pretty good job of responding back to
| you. I've asked tonnes of questions over the years, and have not
| paid for a separate support contract apart from the yearly
| maintenance contract. I suspect they like people asking
| questions, because then they fix those bugs and it becomes even
| more rock solid.
|
| * The documentation is glorious. And in the off-chance that I
| need to know something that's not documented, I just mail them
| and they'll respond usually by the next working day.
|
| * Very stable Java support (although the API could be better),
| let's me use the entire Java ecosystem of libraries when I need
| it.
|
| * The platform itself is rock-solid. Now SBCL is fantastic, but
| when I ran my servers on SBCL, I would have a crash every now and
| then. With LW, I can have my server running weeks (current uptime
| is a month) with reloading code multiple times a day, and
| everything is still super stable.
|
| There's more, but I think the rest is more negotiable. For
| instance, the FLI is a lot more polished than using CFFI, which
| makes a huge difference in productivity when writing native code.
| Or the fact that its remote-debugger facility can be used as a
| very stable protocol to programmatically control a remote LW
| process. I don't use the IDE btw, so I'm not even considering
| that. I don't use CAPI either, but I mean to someday.
|
| 2023, Arnold @tdrhq of Screenshotbot
| (https://github.com/screenshotbot/screenshotbot-oss) on reddit:
| https://www.reddit.com/r/Common_Lisp/comments/11979q4/common...
|
| [/cite]
| galdor wrote:
| First time one of my articles lands on HN! Feel free to ask any
| follow up question.
| matrix12 wrote:
| Franz releases updates continuously bringing in new features. The
| update.sh handles these patches, and new items.
| SultrySiren6 wrote:
| [flagged]
| Fishyfish32 wrote:
| [flagged]
| HairyHarry09 wrote:
| [flagged]
| YourAmbition7 wrote:
| Two months later, in another blog post, he admits the previous
| article "was unfair to both languages", and while "[he] is still
| mostly using Julia", "Common Lisp is still on the table for
| [him]".
| vindarel wrote:
| That is not the same author, so I don't understand your
| comment.
| BookWormy5 wrote:
| "Common Lisp is a viable platform for statistics and machine
| learning. It isn't (yet) quite as well organised as R or Python,
| but it's all there."
| Amumulava5 wrote:
| [flagged]
| codr7 wrote:
| Interesting! CL & embedded sounds like a dream job to me.
| FunnyGuy567 wrote:
| [flagged]
| WinningTeam9 wrote:
| On LiberaChat, he says he's back from Julia to Common Lisp: "As
| of yesterday, I'm back to making libraries in CL. I cannot
| consider Julia as a serious language anymore, for it has deceived
| me after 7 years of research."
| CallingBoss7 wrote:
| [flagged]
| HorribleTasks wrote:
| [dead]
| BearMomma09 wrote:
| [flagged]
| mikedelago wrote:
| I had a great time writing common lisp for the better part of
| 2022, including doing about half of Advent of Code in it. It's
| such an awesome language and once you get an understanding of
| macros, it really does feel powerful.
|
| Unfortunately, I hit a bit of a wall. I don't really have any
| personal projects to work with CL, and if I used CL (or any
| lisp/scheme dialect for that matter) at work I'd be in trouble.
|
| Nice to have in the back pocket though, and I'm excited to reach
| for it in the future.
| InterruptingCow wrote:
| Gosh, a few days too late for an exciting news to be in this
| overview: we just learn about a new Jetbrains plugin for CL.
| Exciting times!
| dutchblacksmith wrote:
| Lispworks starts with an affordable hobbyist edition. There is
| also a hobbyist development edition.
| _ph_ wrote:
| Sorry, I have to disagree. EUR500-600 for just the ability to
| use the IDE but not being able to create an executable doesn't
| sound very appealing to me. And that all limited to "non-
| commercial" use. And per platform. So you can't just switch
| between different OSes.
| SchoolDaze6 wrote:
| MGL-MAT - a library for working with multi-dimensional arrays
| which supports efficient interfacing to foreign and CUDA code.
| BLAS and CUBLAS bindings are available.
| VictoriousMan wrote:
| A simple Lisp implementation is built in C. This Lisp
| implementation is only intended to compile a special-purpose
| bootstrapping Lisp compiler; it is not intended for any other
| purpose and may not be suitable for general use. This
| implementation is then used to compile a full Lisp
| implementation, written in Lisp.
| SoulmateTravels wrote:
| [flagged]
| tmtvl wrote:
| No love for NPT (<https://github.com/nptcl/npt>)? Well, I get it,
| it is very, very new.
|
| One note about ABCL is that it doesn't support TCO, which the
| Common Lisp spec doesn't mandate. For people who want a Lisp on
| the JVM and really want tail calls, I would recommend checking
| out Kawa (<https://www.gnu.org/software/kawa/index.html>).
| abecedarius wrote:
| So, say what's promising about NPT? The readme doesn't try to;
| neither does the first page of the docs.
| tmtvl wrote:
| The documentation (B1_Using) does explain that:
|
| > _npt was developed with the intention of embedding it in
| the C language._
|
| Kind of like Guile, but Common Lisp rather than Scheme.
| abecedarius wrote:
| Thanks. Someone coming to this project page cold is not
| going to find that third-level sub-page unless they're
| motivated; the table of contents doesn't reveal that that's
| where they'll find a rationale. Hope this helps.
| QueenSpre9 wrote:
| [flagged]
| LoudNProud wrote:
| [flagged]
| [deleted]
| SudokuMaster4u wrote:
| ECL (Embeddable Common Lisp) is an implementation that compiles
| Common Lisp to C, and is useful for bringing Common Lisp to new
| platforms and to embedded environments.
| jackdaniel wrote:
| ECL license is LGPL-2.1-or-later (not LGPL2), the same applies to
| Clasp (which was forked from ECL).
|
| n.b isn't this thread infested with bots? 4 or 5 nicks created 4
| days ago with incomplete messages..
| galdor wrote:
| Indeed, corrected. Thank you!
|
| I'm not sure what is happening, there are multiple small posts
| which look like spam, with green nicknames.
|
| Edit: green nicknames are from new accounts. On this page, all
| of them are spam. At some point it would make sense to just
| hide them all.
| jackdaniel wrote:
| the correction is not really correct - you say lgpl-2.1
| without the "or later version". It is sometimes abbreviated
| ls LGPL-2.1+, but SPDX identifier is preferable since it is
| semi-standard for abbreviating license names.
| TropicalDelight wrote:
| [dead]
| kazinator wrote:
| CLISP is excellent for learning Common Lisp; it has a readline-
| based REPL with editing and tab completion, so you don't need
| anything other than the CLISP installation.
|
| The licensing server back end for the Tankan kanji learning
| application runs on CLISP.
| HotMess23 wrote:
| [flagged]
| SportyCheek78 wrote:
| [flagged]
| WonderWeirdo0 wrote:
| [flagged]
| l_theanine wrote:
| Are there any serious attempts at reworking the Common Lisp
| standard for more modern problems?
|
| I know the space is active, but when I see the old bright yellow
| CLHS linked to from documentation sites, I just frown a bit. The
| Lisp community very nearly goes out of its way to be unhospitable
| to the younger generation of coders, and downright dismissive of
| modern techniques like containers and DevOps practices.
|
| Not that the Scheme community is doing a radically better job,
| but at least the RnRS standard is marching forward at an
| acceptable pace.
|
| A few years ago there was CL21, but it didn't really garner
| enough support from the community to really take form into
| anything worthwhile. I think we need a "Lisp for 20XX" council or
| something to gather up ideas and begin a reconstruction era for
| Lisp in this century.
| vindarel wrote:
| re CLHS, there is a new rendering, much more welcoming and
| practical! https://cl-community-spec.github.io/pages/index.html
| (a search box, syntax highlighting!!)
| l_theanine wrote:
| Indeed, that is VERY nice! That's exactly the type of upgrade
| I bet a lot of people can appreciate. The search is
| particularly crisp, feels instantaneous.
| tmtvl wrote:
| The GCL documentation (browsable with an info browser, like
| Emacs) contains a fairly complete reference of the standard.
| blue039 wrote:
| This is just not true...
|
| > I know the space is active, but when I see the old bright
| yellow CLHS linked to from documentation sites, I just frown a
| bit.
|
| This is how documentation has been FOREVER. The newer
| documentation is not necessarily better. In fact, I find the
| "forced by the compiler" type docs that come from Rust et al to
| be infuriating at times. PyDoc is no better. I much prefer the
| terse documentation when I need to know something for sure
| rather than just copy-pasting examples out of docs.
|
| > downright dismissive of modern techniques like containers and
| DevOps practices.
|
| Citation needed? Lisp containerizes just fine. Unless you mean
| hand-holding-via-blog-post which yeah, I guess the community
| can be hostile. If you hang around the IRC people are often
| very helpful. The greybeards in the field are very experienced
| and very intelligent. To be crass, many of these "modern"
| developers you refer to need a LOT of handholding. CL doesn't
| provide this handholding. Honestly, it is no harder than
| getting actual work done in Haskell. You spend a lot of time in
| documentation and not a lot of people can help you. Of those
| people that can, your problem is not hard enough to interest
| them because they are VERY good. That being said I had no
| problem at all getting help from the community IRC and mailing
| lists.
|
| As far as I can tell CL is fine for the 21st century. A more
| streamlined package system would be nice but quicklisp and ASDF
| aren't that complicated.
|
| Frankly, I dont think you've spent any time working in CL at
| any real size. You could argue it doesnt scale well across
| large teams and that'd be fair. Your other criticisms
| though...don't make sense and don't align with my experience at
| all.
| HackerMaster5 wrote:
| [flagged]
| FilterlessLad wrote:
| [flagged]
| WickedlyCool wrote:
| [flagged]
| Wininger5 wrote:
| [flagged]
| SunnyXpeach0 wrote:
| [flagged]
| zetalyrae wrote:
| Common Lisp implementations in 2023:
|
| - SBCL
|
| Everything else is de-facto dead or in a proprietary silo.
| eggy wrote:
| What about Clasp or ABCL?
| jackdaniel wrote:
| /me gasps - how rude! :~)
| anta40 wrote:
| What about GCL? "NEW! (20230113) GCL 2.6.14 is released"
| galdor wrote:
| I tried to use it when writing my article. It could not even
| load my initialization file because it is not standard
| compliant (it does not support the :VERBOSE argument of
| COMPILE-FILE).
|
| The fact that they use GCC under the hood is interesting
| though, I'd be curious to see how fast it can get. But
| standard compliance comes first.
| zetalyrae wrote:
| Never heard of anyone using it. AIUI not standards-compliant.
| LGPL for a Common Lisp impl. is not something I want to touch
| with a ten foot pole.
| CutiePieu2 wrote:
| [flagged]
| chris_armstrong wrote:
| Compared to languages that have a single implementation, have
| multiple commercial and open source implementations in reasonable
| states of continuous development seems like a good place to be.
| SeanLuke wrote:
| > The free "Personal Edition" limits the program size and the
| amount of time it can run, making it pretty much useless for
| anything but evaluation.
|
| Also very good for education purposes.
| ButterySocial9 wrote:
| [flagged]
| GamersFever0 wrote:
| [flagged]
| mkh wrote:
| One should note that while it is true that the last CLISP release
| was a long time ago and there is not a lot of development going
| on right now, it's not dead. Bruno Haible just commited last
| week.
|
| The repository is now at https://gitlab.com/gnu-clisp/clisp
| cellularmitosis wrote:
| That is exactly the problem, there have been many commits to
| HEAD but no release for 12 years??? It isn't dead, it is
| undead. Strange.
| u89012 wrote:
| I just spent months working on a large piece of software and
| could say without a doubt, Lisp is awesome! But I also want to
| say that most implementations are hashing out a spec written
| decades ago and not trying to improve what's obviously lacking --
| a full modern standard library! Trying to piece together
| functionality from here and there (and Quicklisp which is an
| unversioned mess) will only take you so far and in the end you
| will realize the amount of time wasted chasing this great
| language! AFAIK Lisp needs more backing from the heavyweights to
| make any reasonable progress which I'm sure won't happen.
| mark_l_watson wrote:
| Good comments. Quicklisp has certainly helped.
|
| A few years ago, after Common Lisp being my favorite language
| since around 1982, I thought that I might switch for my
| personal projects to Racket Scheme since it does have good
| library support. What holds me back is that I have found
| plentiful work opportunities over the last several decades with
| Common Lisp, but except for getting paid by Springer-Verlag to
| write a Scheme book, I have never been paid to use Scheme.
|
| Also, to be really honest, so much of my work in the last ten
| years has involved deep learning, that I have somewhat
| reluctantly learned to love Python for writing short programs.
| can3p wrote:
| I think every programmer that tries common lisp eventually
| comes to the same conclusion, however none of the new versions
| of "standard" libraries got any traction to my knowledge.
| Usually it's used only by the author who created it which makes
| their code unique in some sense, like a recent post from Ron
| Garret [0].
|
| The spec is really valued by cl community and I guess I'll tell
| an unpopular opinion now, but I think there could be a place
| for an ecosystem built around one of the compilers like sbcl
| with all the old cruft removed and a really good all purpose
| standard library (similar in capabilities to the one of go for
| example). What that will achieve is that it will allow new
| developers to write the code without reading on why the things
| were designed is a certain way 40 years ago because of now
| forgotten os or hardware limitation.
|
| Similar to what was done with neovim project
|
| [0]: http://blog.rongarret.info/2023/01/lisping-at-jpl-
| revisited....
| lispegistus wrote:
| What part of Common Lisp would you consider old cruft and
| what value would removing it bring to the language that would
| offset the value we have from having one of the most stable
| language definitions still in use? I can think of a few dusty
| parts of the language that are rarely used today but it's
| perfectly safe to ignore.
|
| Lisp has a good all purpose library ecosystem, it's just
| informal rather than baked into the language, and I haven't
| had any significant issues with quicklisp since it came out
| however many years ago. Writing portable common lisp is not
| at all difficult and there is no problem like with say Scheme
| of one library needing a specific compiler. And libraries
| tend to have a long shelf-life too. How much of Python's
| standard library is old cruft with better alternative
| packages available now for example? Didn't they have to prune
| a bunch of stuff in the python2->3 transition? There is
| considerable risk in including standard libraries in a
| standard, and the risk is that those libraries will end up
| being outdated eventually. You want to add more potential for
| more old cruft to be in Lisp and then pruned again? Why? Just
| use quicklisp or one of it's alternatives that are cropping
| up.
|
| Lisp is not Go, it's an agreement between many different
| parties about what lisp is, it's not a codebase under the
| defacto control of one organization, or even an informal
| group or "community". This is extremely valuable and recent
| events around Go show why, I am extremely glad that I never
| payed much attention to Go because honestly I cannot trust
| it's governance model, but a specification that hasn't been
| and won't be updated in decades I can trust completely, and
| if one implementation betrays that trust, I can always move
| to one of the many alternatives listed in the OP.
|
| sidenote:
|
| > I think every programmer that tries common lisp eventually
| comes to the same conclusion
|
| if this refers to "Lisp needs more backing from the
| heavyweights", then OH GODS PLEASE NOOO! I want to write code
| that will run in a year without modification and won't have
| some corporation put spyware in my compiler while trying to
| convince me it's for my own good and have my IDE slurp my
| code to train some LLM to make it easier to pile even more
| pointless unmaintainable code upon the world. The
| "heavyweights" have shown themselves very poor stewards of
| the discipline of computing indeed.
| SiVal wrote:
| _recent events around Go show why, I am extremely glad that
| I never payed much attention to Go..._
|
| What are you referring to? This is a literal question, not
| advocacy. I haven't been paying enough attention to know
| what you mean.
| galdor wrote:
| But no one is stopping you from building a "full modern
| standard library". I am doing just that with
| https://github.com/galdor/tungsten. Of course it would be nice
| to have a large company do all the work as it is the case for
| Go, but it is not going to happen. As always, you either do the
| work yourself or pay someone to do it.
|
| The specification is limited, no doubt about that, but I am
| convinced that any modernization effort would end up in a huge
| mess with everyone trying to inject their own preferences from
| the languages they already know with no regard for the spirit
| of the original specification.
| vindarel wrote:
| I quite agree, so I'm making a meta-library to have useful
| libraries available out of the box: https://github.com/ciel-
| lang/CIEL/ It's CL, batteries included. You can use it as a
| library, as a core CL image (loads up faster), and as a binary
| to have a REPL, and to run scripts: ciel
| --script myscript.lisp
|
| (edit) or just ./myscript
|
| with a #!/usr/bin/env ciel shebang.
|
| where you have access to HTTP clients, JSON parsers, CSV
| readers, DB drivers... and much more, out of the box.
|
| It is not done, I am dogfooding it.
| cellularmitosis wrote:
| I've noticed many lisps and schemes are not set up to simply
| accept a single file name as the sole command line argument,
| which is something common to nearly every other platform.
| Seems like an easy target for reducing friction for
| newcomers.
| vindarel wrote:
| Thanks for the feedback. I'll look into it, it's early
| enough to change.
|
| (edit) forgot to mention we can simply call ./myscript with
| the right shebang line. Gets as succinct as one can.
| ducktective wrote:
| Excellent. It's kinda like Janet, right (in terms of being a
| battery-included LISP)?
| vindarel wrote:
| Yes, and kinda like Babashka for Clojure, in terms of fast
| starting scripting environment with one binary and useful
| built-in utilities.
| ducktective wrote:
| You are very active in CL community, vindarel. Thanks!
| oblio wrote:
| > and Quicklisp which is an unversioned mess
|
| Quicklisp is the Common Lisp package manager from what I
| remember. It doesn't version its packages?
| tmtvl wrote:
| Not really, but there are ways around it:
| http://blog.quicklisp.org/2011/08/going-back-in-dist-
| time.ht...
| oblio wrote:
| I'm confused, is this about Quicklisp itself or about the
| packages it manages?
|
| I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs
| libfoo 1.0?
| tmtvl wrote:
| It's about the packages, a Quicklisp dist has a list of
| packages of specific versions (like libfoo 1.1, libbar
| 1.0, and libbaz 1.2) and you can switch to an older dist
| (which can have libfoo 1.0, no libbar, and libbaz 1.2).
| oblio wrote:
| Oh, so it's actually a carefully curated limited list?
| Because otherwise the combinatorial explosion would make
| this unmanageable super fast.
| Lost_cause2 wrote:
| [flagged]
| YourCandy5 wrote:
| [flagged]
| mark_l_watson wrote:
| I always like seeing Common Lisp links, but personally I was a
| bit put off by the very strong anti-commercial comments about
| LispWorks and Franz.
|
| I had a business idea requiring Common Lisp a few years ago and I
| purchased a LispWorks Professional license. Small standalone
| executables with a tree shaker [1] and I has received very good
| support without paying for the high priority support service. I
| also paid the maintenance fee last year for continued updates.
| Coincidentally, I am an advisor and chief architect for a small
| AI company and they use LispWorks also.
|
| Many years ago, I worked as a consultant on a medical AI project
| and my customer paid a fair amount of money to Franz for software
| licensing and tech support that included helping with
| development. Incredibly useful!
|
| I also love open source Common Lisp and Scheme implementations.
|
| Anyway, I would respectfully suggest to the author to maybe tone
| down the rhetoric a bit since different individual developers and
| companies have different requirements.
|
| [1] you can also make small standalone apps with SBCL by building
| from source and setting a flag to allow compressed heap files.
| brudgers wrote:
| Looking at the price of the "Hobbyist DV" version, it is not
| out of line with what people often spend on hobbies like
| photography, music, and cycling.
|
| Or just on beer and/or wine.
|
| Or books.
|
| Not to say people don't spend less on their hobbies, just that
| a license is a less than a Sony A7R3 or a used Les Paul.
| _ph_ wrote:
| Yes, if a hobbyist absolutely wants to buy a Lispworks
| license, that should be possible for many people. But that
| isn't the only criterium. The question is: is anyone as happy
| to pay the price compared to spend the money on other things,
| like buying a camera or lens. There is some perception of
| value involved. For example I do spend a lot of money on my
| camera equipment and some people are suprised by it, though I
| spend way less on my car than they do. But on the other side,
| many people can't spend so much on any hobby or car.
|
| On the other side there is SBCL. This is really a great Lisp
| implementation, in some ways clearly superior even, this
| limits the amount what at least I am willing to pay for some
| fancyness of the commercial edition. As far as I can see, I
| struggle to preceive a critical advantage for Lispworks. And
| the price is way above the impulse by territory.
| ducktective wrote:
| > Small standalone executables with a tree shaker
|
| How small? Are they static and hassle-free like Go/Rust
| binaries?
|
| > you can also make small standalone apps with SBCL
|
| Same question. Also what's the downside? Slower run-time?
| vindarel wrote:
| With SBCL, the bare-bones image would be +-100MB, with core
| compression (a single flag to set in the .asd file) I get
| apps at +-25MB. The startup time of the latter is +-0.30s,
| the bigger executable is faster. My app would be a web app,
| with the webserver, templates, and many libraries. This
| binary also contains the Lisp debugger and compiler, which is
| useful to interact with it when it's running.
|
| In a latest version, SBCL switched to compression with zstd,
| which makes the compression process 4 times faster,
| decompression around 2 times, and it saves around +10% more
| space.
|
| On reddit (link below), a user speaks about LispWorks
| binaries of +-9MB.
| mark_l_watson wrote:
| Yes, compressed SBCL images load so fast that a few years
| ago I had a command line tool that I wrote using a
| compressed image. I think the load time for the tool was
| perhaps 100 milliseconds.
| jlarocco wrote:
| Yeah, I totally agree.
|
| I only use Lisp as a hobby so I stick to the free
| implementations, but if I made money with it I definitely
| wouldn't mind paying for LispWorks or Allegro.
|
| An $8k license fee really isn't that much for enterprise
| software.
| oblio wrote:
| He's right, though.
|
| If I'm a somewhat polyglot developer ambivalent to any language
| out there, why would I pay those licensing costs when I can
| just go elsewhere instead?
|
| That's what regular devs do, they don't even bother writing
| articles or commenting on HN :-)
| jgerrish wrote:
| > That's what regular devs do, they don't even bother writing
| articles or commenting on HN :-)
|
| I'll take the bait, and roll up several of my comments into
| one.
|
| First, the support contract costs from the commercial vendors
| can make sense. It's one of the most expensive parts of
| software. We joke about fixing relatives' printers, but it's
| not false. Support costs introduce a counter-balance.
|
| Second, a message to everyone looking into or using
| QuickLisp, it uses http instead of https:
| https://github.com/quicklisp/quicklisp-client/issues/167
|
| You can patch your version to fix this. I'd also recommend
| adding firewall rules to deny in case your patches roll back.
| And any other mitigation. Or stricter policies, such as not
| using it, if it makes sense for your organization.
|
| And the AI bots? I hope there aren't people herding them who
| don't want to, that's how you get unloving brats and a crappy
| world.
| squeaky-clean wrote:
| Is support costs for a language actually worth it? I've
| used Python professionally for about 10 years now and never
| hit an actual python runtime bug or needed to contact the
| PSF for support. A language vendor telling me about the
| faith I should have in their support sounds like I
| shouldn't have faith in the language.
|
| I've never learned a lisp because every runtime and tooling
| set up seems 20 years behind modern. I'd be interested in
| learning with a good lisp variant, but not if I have to
| pay.
|
| It's like how Adobe doesn't really do anything major to
| prevent piracy. And because of that hobbyists learn their
| tools and then companies have to pay for those tools
| because it's the dominant tool in that industry.
| taeric wrote:
| Support at this level can also include help making
| something perform well. Or help understanding bugs in
| your code. That is, it isn't just a "prove we are at
| fault and we will fix it thing" which plagues a lot of
| moderate sized projects online.
| galdor wrote:
| The commercial aspect is not a problem in my opinion (but again
| english is not my main language so I might have conveyed the
| wrong tone). The issue is the pricing model which may work for
| established company ready to invest money from the start, but
| is simply out of touch with independant developers and small
| companies exploring the possibility of using Common Lisp.
|
| Open sourcing Lispworks and selling support contracts and an
| enterprise version (with CAPI, CORBA, etc.) would make more
| sense. The world has changed: all other languages have open
| source implementations; most servers are open source, most
| databases too. It is hard to convince a company to use Common
| Lisp, but even harder to justify paying for a proprietary
| implementation.
|
| And for me personally, Lispworks would force me to buy two
| licenses (Linux and FreeBSD) for personal use, and two for my
| solo company. It simply does not make any sense financially
| speaking.
| matrix12 wrote:
| The linux lispworks runs fine for me on Freebsd with
| linux_compat.
| andsoitis wrote:
| You wrote of LispWorks: " The professional and enterprise
| licenses do not really make sense for anyone"
|
| Perhaps a question I would ask is what are you trying to
| convey with this statement? It appears to be quite
| subjective.
| fsckboy wrote:
| You quote him saying "The professional and enterprise
| licenses do not really make sense for anyone"
|
| your quote is the definition of "out of context", you left
| out his colon leading to the rest of his sentence where he
| explains what he means, i.e. what you are asking.
|
| "The professional and enterprise licenses do not really
| make sense for anyone: you will have to buy separate
| licenses for every..." ...now, I'm not quoting the rest of
| it because while it's easy to engage with a substantive
| argument, you didn't say anything.
|
| Still your move.
| kjs3 wrote:
| Since you're going to be a condescending
| pendant...everything after the colon is why it doesn't
| make sense for _him_ , not why it doesn't make sense for
| _anyone_ , and it's very clear that's the point he's
| making. It's a common fallacy around here: " _I_ think
| this, therefore it 's applicable to _everyone_ ".
| anta40 wrote:
| I assume you have some specific needs that couldn't be
| handled by open source Lisps like SBCL, CCL, etc?
| oblio wrote:
| No, his needs are probably better handled by Java or .NET
| or Go or whatever. And that's how Lisp atrophies. The
| complaint is a valid one.
| varjag wrote:
| Enterprise Java licenses are charged per developer seat,
| just saying.
| oblio wrote:
| Any company worth their salt doesn't pay for that,
| though. Heck, even stuffy enterprises like banks, who
| usually pay for everything, frequently don't do that.
|
| The main JDK distros are big and stable enough to make
| this strategy viable in an enterprise environment.
| lispm wrote:
| Hasn't this just recently changed to per employee?
|
| https://www.infoworld.com/article/3686611/oracle-per-
| employe...
| nextos wrote:
| I am also curious about this, what specific needs are
| better served by CL than Clojure or any Scheme / Racket?
|
| Starting a CL project in 2023 seems risky to me given that
| most libraries are stagnant. I would love to be proven
| wrong.
| codehalo wrote:
| Could it be that most of the critical libraries are
| stable? Can you give an example of a necessary library
| that is stagnant?
| nextos wrote:
| CLSQL, most graphics toolkits or lisp-stat.
| lispm wrote:
| > Open sourcing Lispworks and selling support contracts and
| an enterprise version (with CAPI, CORBA, etc.) would make
| more sense.
|
| I don't think it makes any sense, since the market for such
| complex Lisp systems is tiny. It would not generate a
| reliable revenue stream for such a niche technology.
|
| It's not that it has not been tried in the past, but all Lisp
| vendors from the past, and there were a dozen or more with
| different license models / pricing, have gone. Left are Franz
| and LispWorks. Both are 30+ years in business.
| kgwgk wrote:
| > The issue is the pricing model which may work for
| established company ready to invest money from the start, but
| ...
|
| That's a much more nuanced way to put it - compared to "The
| professional and enterprise licenses do not really make sense
| for anyone".
| oblio wrote:
| > That's a much more nuanced way to put it - compared to
| "The professional and enterprise licenses do not really
| make sense for anyone".
|
| Where does he say that?
| kgwgk wrote:
| https://www.n16f.net/blog/common-lisp-implementations-
| in-202...
| oblio wrote:
| I've read it and if you're referring to this:
|
| > I do not have anything personal against commercial
| software, and I strongly support developers being paid
| for their work. But this kind of licensing makes
| Lispworks irrelevant to everyone but those already using
| their proprietary libraries.
|
| is he wrong?
|
| Go ask 100 random devs working for various companies. My
| money's on 99% on them avoiding those licensing terms in
| favor of probably anything else.
| kgwgk wrote:
| In case it was not clear I was referring to this literal
| quote from the linked article: "The
| professional and enterprise licenses do not really make
| sense for anyone"
|
| which does indeed convey a more negative tone than this
| literal quote from the comment that I replied to:
| "the pricing model which may work for established company
| ready to invest money from the start"
| oblio wrote:
| Ah, I was looking at the wrong quote.
|
| However, I think techies are too nitpicky.
|
| In casual use "everyone" or "anyone" do not mean: "I
| literally asked everyone on the surface of the planet".
|
| And he's not wrong.
|
| Unless you have a preexisting commitment to Lisp and
| ecosystem or your needs are so specific that you need
| this precise piece of software, you won't use it.
| varjag wrote:
| I think it's a prior that anyone considering the choice
| of a Common Lisp implementation for production has a
| preexisting commitment to Lisp.
| kazinator wrote:
| What's an example of something that is used for
| production without preexisting commitment?
| lispm wrote:
| On the page, commenting about LispWorks.
| [deleted]
| _ph_ wrote:
| I am convinced that Lispworks is a great product. From what I
| can see it comes with a nice IDE and some nice libraries. I
| would have loved to give it a try, but unfortunately I was
| never able to do do so. And that is where the critique of the
| licensing scheme comes from. I am sure there are quite a few
| professionals for whom Lispworks has great value and the
| license costs are just a non-issue. But despite being a
| professional Lisp programmer for more than 15 years, I never
| came close to licensing Lispworks. Nor in the 20 years of being
| a Lisp enthusiast.
|
| As an enthusiast, I would be happy to spend a few hundred EUR
| for private usage, but not thousands. I would like to be able
| to really evaluate the product before spending a significant
| amount of money on it, but with the limits of the personal
| edition, it immediately quit on the first attempt of starting
| my back-then tiny hobby project.
|
| Don't get me wrong, a company has the right to select the
| business model which fits them best and I might not be their
| intended audience. But that is why I never bought from them and
| as I never used the product didn't really put under strong
| consideration when choosing a Lisp implementation for
| commercial work.
|
| On the other side, with SBCL I have a really strong Lisp
| implementation. The compiler is likely to produce better code
| and it is readily available. Slime might lack the fanciness of
| a standalone IDE, but as a longtime Emacs user, that might
| actually be an advantage.
| lispm wrote:
| > I would like to be able to really evaluate the product
| before spending a significant amount of money on it, but with
| the limits of the personal edition, it immediately quit on
| the first attempt of starting my back-then tiny hobby
| project.
|
| Usually one contacts the vendor and asks for a time-limited
| full version of the product for evaluation.
|
| > On the other side, with SBCL I have a really strong Lisp
| implementation.
|
| That's one of the advantages of a language standard with
| multiple competing / complementing implementations.
| kgwgk wrote:
| > As an enthusiast, I would be happy to spend a few hundred
| EUR for private usage, but not thousands.
|
| Note that the cost for private usage starts at a few hundred
| EUR. You only get to "thousands" if you include multiple
| platforms or several support incidents.
| _ph_ wrote:
| Well, it starts at EUR480 (Linux) - EUR720 for the Mac for
| a pure IDE, without the ability to produce executables. You
| are limited to run your programs inside the development
| environment, this limits its applicability a lot. You can't
| write a simple command line utility this way, just to name
| one example. You cannot give it to a friend etc. The
| HobbyistDV edition is in my eyes the first really usable
| one. It is already over EUR1400, and that is for a single
| OS, a single CPU architecture. Especially as a hobbyist I
| might be able to play around with it a bit. I would be
| interested if there is any customer who has more than one
| hobbyistDV license. And that doesn't seem to include any
| updates.
| kgwgk wrote:
| > The HobbyistDV edition is in my eyes the first really
| usable one. It is already over EUR1400
|
| Less than 1000 if you can live with 32 bits but I wonder
| if someone goes for that option nowadays.
|
| > and that is for a single OS, a single CPU architecture.
|
| The MacOS version supports both Apple Silicon and Intel.
| lelanthran wrote:
| > I always like seeing Common Lisp links, but personally I was
| a bit put off by the very strong anti-commercial comments about
| LispWorks and Franz.
|
| What? I found it informative - clear and to the point about
| what frustrations you can expect with the licenses.
|
| I mean, FCOL, he even made the effort to search google for the
| cost of the licenses because Franz hides them.
|
| What exactly in the following texts do you describe as "strong
| anti-commercial comments"?
|
| ------------------------------------------------------
|
| > Moving to proprietary implementations; Lispworks has been
| around for more than 30 years and the company producing it
| still release new versions on a regular basis.
|
| > While Lispworks supports most features you would expect from
| a commercial product (native compiler, multithreading, FFI, GUI
| library, various graphical tools, a Prolog implementation...),
| it is hampered by its licensing system.
|
| > The free "Personal Edition" limits the program size and the
| amount of time it can run, making it pretty much useless for
| anything but evaluation. The professional and enterprise
| licenses do not really make sense for anyone: you will have to
| buy separate licenses for every single platform at more than a
| thousand euros per license (with the enterprise version being
| 2-3 times more expensive). Of course you will have to buy a
| maintenance contract on a yearly basis... but it does not
| include technical support. It will have to be bought with
| "incident packs" costing thousands of euros; because yes,
| paying for a product and a maintenance contract does not mean
| they will fix bugs, and you will have to pay for each of them.
|
| -----------------------------------
|
| Releases are uncommon, the last one being almost 6 years ago.
| But Allegro is a mature implementation packed with features not
| easily replicated such as AllegroCache, AllegroServe, libraries
| for multiple protocols and data formats, analysis tools, a
| concurrent garbage collector and even an OpenGL interface.
|
| Allegro suffers the same issue as Lispworks: the enterprise-
| style pricing system is incredibly frustrating. The website
| advertises a hefty $599 starting price (which at least includes
| technical support), but there is no mention of what it
| contains. Interested developpers will have to contact Franz
| Inc. to get other prices. A quick Google search will reveal
| rumours of enterprise versions priced above 8000 dollars. No
| comment.
| varjag wrote:
| > It will have to be bought with "incident packs" costing
| thousands of euros; because yes, paying for a product and a
| maintenance contract does not mean they will fix bugs, and
| you will have to pay for each of them.
|
| This is something the author made up on the spot. They will
| most definitely fix the bugs regardless if you have support
| contract.
| galdor wrote:
| I did not "make it up on the spot", I simply read their
| website:
|
| "Typically incidents are chargeable when they require work
| from us such as writing, compiling or testing patches,
| updating documentation, analysing or debugging your code,
| finding workarounds, providing technical advice or other
| significant effort.
|
| In particular, please note that we may regard fixes for
| bugs in its own Lisp products, and for shortcomings in the
| documentation, as chargeable."
|
| Source: http://www.lispworks.com/support/description.html#c
| hargeable
|
| Note how the list and following text clearly indicate that
| you can and will be charged for bugs in their own products.
| lispm wrote:
| You wrote:
|
| > Of course you will have to buy a maintenance contract
| on a yearly basis...
|
| One does not have to buy a maintenance contract. It's
| entirely up to the customer if he/she does that.
|
| > but it does not include technical support. It will have
| to be bought with "incident packs" costing thousands of
| euros; because yes, paying for a product and a
| maintenance contract does not mean they will fix bugs,
| and you will have to pay for each of them.
|
| You don't have to pay for each of them. They clearly say
| that they "may" charge you money and they inform you if
| that is the case.
|
| I have been reporting many things and for most fixes (for
| their bugs) I didn't have to pay anything additionally.
| For a lot of those I got patches immediately, sometimes
| they told me that it will be fixed in the next release,
| especially if it was in combination of a new feature. For
| example I once complained that the terminal
| listener/debugger wasn't supporting UTF-8. That feature
| got added in some release later. If I would have wanted
| to have it earlier, I surely would have had to pay for
| it.
| RefreshingView wrote:
| [flagged]
| knome wrote:
| Are RefreshingView, FunnyGuy567, SultrySiren6, and GirlFunk87
| all someone spamming the site with gpt bots?
|
| How annoying.
|
| edit: TropicalDelight, SimplySweet4, WonderWeirdo0,
| WickedlyCool and SoulmateTravels as well.
| frou_dh wrote:
| Seems like there is virtually copy/paste from old comments,
| e.g. https://news.ycombinator.com/item?id=34910103 I remember
| reading the original
| https://news.ycombinator.com/item?id=32324797
| WinningHero9 wrote:
| [dead]
| Dragonborn5 wrote:
| [flagged]
| hvs wrote:
| For a period much earlier in my career (think early 00's) I
| seriously desired to work in Common Lisp professionally. Through
| a series of life decisions and other opportunities, that never
| really happened. But I continued to work on Lisp projects on my
| own and use it for various things. I don't consider it a
| "superpower," and I don't think it makes me 10x more productive
| or anything like that. Most modern languages have stolen most of
| the thunder from Lisp (other than macros) so I would be hard-
| pressed to recommend it for greenfield development.
|
| That said, I love working in it. I don't have any illusions that
| it will make a "comeback" or that I will ever make money writing
| it (I long ago switched to looking for job opportunities based on
| the problem domain rather than the toolset), but I continue to
| use it personally because it makes me happier than any other
| language.
| OneAndOnly8 wrote:
| [flagged]
| MinxJinx42 wrote:
| [flagged]
| YouWillLose wrote:
| [dead]
| account-5 wrote:
| I would like to learn Lisp but am easily confused with where to
| start. What implementation do I use? On a general level do I
| start with CL, schema, racket, etc (apologies I know this thread
| is about common lisp). It's all very confusing.
|
| I'm like this with most things, like I want to learn Forth too
| but have that same problem. I learned vanilla JavaScript because
| I didn't know where to start with the 1000+ frameworks; and as a
| result am learning flutter/dart for cross platform apps.
|
| Any advice would be much appreciated!
| galdor wrote:
| In my opinion, the simplest way is to start with Common Lisp,
| with SBCL and the Practical Common Lisp book by Peter Seibel.
|
| Make sure you are comfortable with Emacs. It is possible to
| write Common Lisp without it, but Emacs and SLIME are so much
| better than anything else it feels like cheating.
| runevault wrote:
| I didn't feel like relearning Emacs when I started diving
| back into CL so I've been using VSCode with the Alive
| extension and once I got it fully up and running with
| Quicklisp etc my SBCL has run great.
| serf wrote:
| >..simplest way
|
| >..make sure you are comfortable with Emacs.
|
| As an emacs user myself, I must say -- that's a _high_ bar
| for trying to digest a new language.
| mikedelago wrote:
| Agree, it's kind of a pain. There is ALIVE for vscode and
| VLIME for vim which are fine for just getting started.
|
| and more: https://lispcookbook.github.io/cl-
| cookbook/editor-support.ht...
| User23 wrote:
| On the plus side there is a fair amount of conceptual
| overlap between Elisp and Common Lisp.
|
| Learning Lisp really is more learning a complete
| development environment; a development philosophy even.
| Sure you can write Lisp as you would C, editing in a basic
| editor and then compiling and running the complete program
| in a a shell, but it's really missing the point. While that
| reduces the learning curve significantly, it reduces the
| benefits even more.
| mikedelago wrote:
| I will say, using VLIME with vim is pretty nice as well. Once
| you get the keys memorized, you mostly match an Emacs/SLIME
| experience.
| panick21_ wrote:
| Racket is a good education language and has lots of features
| with batteries included.
|
| You can also use Clojure if you already know Java, or
| ClojureScript a fantastic compile-to-JS language.
| tmtvl wrote:
| While personally I got started with Lisp through the
| OpenCourseWare Structure and Interpretation of Computer
| Programs videos (and working through the book using Guile), you
| could also try Common Lisp: A Gentle Introduction to Symbolic
| Computation (<https://www.cs.cmu.edu/~dst/LispBook/>). For
| Common Lisp I would recommend using SBCL, it is a very high
| quality and popular implementation.
|
| Additional resources I would recommend:
|
| For Common Lisp: CLiki, the Common Lisp wiki:
| <https://cliki.net/>
|
| For Scheme: Either the R7RS or R6RS documentation depending on
| which implementation you choose (Chez and Loko use R6RS, Gauche
| uses R7RS, and Guile can use either):
| <https://standards.scheme.org/>
| smcn wrote:
| Common Lisp, specifically SBCL. Most popular choice (outside of
| Clojure and Emacs Lisp?). That's the easy answer. You'll
| encounter more libraries and online answers/resources which
| will help any growing pains.
|
| Quicklisp is used for package management and quickproject is a
| great starting point to get you writing lisp asap.
|
| Practical Common Lisp is a great introduction to the language.
|
| https://www.quicklisp.org/beta/
|
| https://xach.com/lisp/quickproject/
| taeric wrote:
| If you are not looking at a specific project to get going,
| https://mitpress.mit.edu/9780262546379/the-little-learner/ was
| just released and is a very fun treatment of both lisp and
| machine learning.
| runevault wrote:
| I thought Little Learner assumed you already knew
| Lisp/scheme. You'd probably want to go through at LEAST
| Little Schemer from same author first to get the basics.
| taeric wrote:
| The first chapter goes over everything you'd need to know
| of scheme to get running. And it has its own choices in how
| they are using scheme. In particular, they curry all of the
| functions, it looks. My understanding is that this is on
| purpose for things they do later in the book.
|
| Which shows I have not finished it, yet. :D I am finding it
| fun, already.
| Spicy_taco00 wrote:
| [flagged]
| BadassBaeu wrote:
| [flagged]
| RockinOut wrote:
| [flagged]
| tsimionescu wrote:
| It may be worth mentioning that CLASP is one of the only
| languages/runtime systems that can interoperate with C++ code
| directly - say, to catch C++ exceptions, or pass around
| std::vector<T> and so on.
|
| It's also quite remarkable that the project was started by a
| chemistry researcher.
| FrostedCupcake wrote:
| [dead]
___________________________________________________________________
(page generated 2023-02-23 23:01 UTC)