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.
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 € 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.
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.
> 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.
It doesn't bother me as much as maybe it seems from the rant, I don't think about them hardly at all. But when I do, it's frustrating, because just about every other ecosystem out there is better. The rant highlights IntelliJ from the Java world as an alternative. Somehow, JetBrains is able to cater to individual developers and incredibly giant enterprises just fine. They care about their IDE and associated software. LispWorks and Franz do not, to the same degree. That's fine, it's their businesses, but it's disappointing when you want to see Lisp succeed and you have two great proprietary IDEs and implementations that are effectively untouchable for a huge portion of Lispers and would-be-Lispers.
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.
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.
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.
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.
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].
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.
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 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.
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.
> downright dismissive of modern techniques like containers and DevOps practices
The last project in CL I made for other people to use (several years ago now) included a Dockerfile people seemed to appreciate it and nobody seemed to dismiss it.
> Are there any serious attempts at reworking the Common Lisp standard for more modern problems?
There are many extensions for more modern problems either as a library or in individualCL implementations. Where the extensions are highly overlapping, there is a library that unifies the interface (usually named "trivial-FOO"). There are exactly zero paying customers that need to wait for a feature to be in the standard for them to adopt that feature, so there is zero impetus to update the standard.
> 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.
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.
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.
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.
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.
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.
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/>
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.
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.
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>).
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.
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.
Pro-tip for SBCL servers: Manually call the GC periodically. All non-FFI related crashes I've had on SBCL servers were allocation failures. They may have squashed all of those bugs now, but I still do this.
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?
[+] [-] mark_l_watson|3 years ago|reply
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.
[+] [-] _ph_|3 years ago|reply
As an enthusiast, I would be happy to spend a few hundred € 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.
[+] [-] galdor|3 years ago|reply
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.
[+] [-] lelanthran|3 years ago|reply
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.
[+] [-] Jach|3 years ago|reply
It doesn't bother me as much as maybe it seems from the rant, I don't think about them hardly at all. But when I do, it's frustrating, because just about every other ecosystem out there is better. The rant highlights IntelliJ from the Java world as an alternative. Somehow, JetBrains is able to cater to individual developers and incredibly giant enterprises just fine. They care about their IDE and associated software. LispWorks and Franz do not, to the same degree. That's fine, it's their businesses, but it's disappointing when you want to see Lisp succeed and you have two great proprietary IDEs and implementations that are effectively untouchable for a huge portion of Lispers and would-be-Lispers.
[+] [-] jlarocco|3 years ago|reply
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|3 years ago|reply
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 :-)
[+] [-] brudgers|3 years ago|reply
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.
[+] [-] ducktective|3 years ago|reply
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?
[+] [-] butternoodle|3 years ago|reply
[+] [-] 147|3 years ago|reply
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.
[+] [-] vindarel|3 years ago|reply
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|3 years ago|reply
[+] [-] Avshalom|3 years ago|reply
There's also a chatbot company on the front page posted by a new account. I kinda suspect they're related.
[+] [-] arethuza|3 years ago|reply
[+] [-] galdor|3 years ago|reply
You use ASDF:LOAD-SYSTEM to have ASDF load all the content of the system, making it available to you.
[+] [-] lispm|3 years ago|reply
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.
[+] [-] dutchblacksmith|3 years ago|reply
[+] [-] hvs|3 years ago|reply
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.
[+] [-] smcn|3 years ago|reply
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
[+] [-] u89012|3 years ago|reply
[+] [-] vindarel|3 years ago|reply
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.
[+] [-] tsimionescu|3 years ago|reply
It's also quite remarkable that the project was started by a chemistry researcher.
[+] [-] ahefner|3 years ago|reply
[+] [-] l_theanine|3 years ago|reply
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|3 years ago|reply
[+] [-] aidenn0|3 years ago|reply
The last project in CL I made for other people to use (several years ago now) included a Dockerfile people seemed to appreciate it and nobody seemed to dismiss it.
> Are there any serious attempts at reworking the Common Lisp standard for more modern problems?
There are many extensions for more modern problems either as a library or in individualCL implementations. Where the extensions are highly overlapping, there is a library that unifies the interface (usually named "trivial-FOO"). There are exactly zero paying customers that need to wait for a feature to be in the standard for them to adopt that feature, so there is zero impetus to update the standard.
[+] [-] tmtvl|3 years ago|reply
[+] [-] blue039|3 years ago|reply
> 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.
[+] [-] mikedelago|3 years ago|reply
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.
[+] [-] mkh|3 years ago|reply
The repository is now at https://gitlab.com/gnu-clisp/clisp
[+] [-] cellularmitosis|3 years ago|reply
[+] [-] galdor|3 years ago|reply
[+] [-] account-5|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] tmtvl|3 years ago|reply
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/>
[+] [-] panick21_|3 years ago|reply
You can also use Clojure if you already know Java, or ClojureScript a fantastic compile-to-JS language.
[+] [-] smcn|3 years ago|reply
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|3 years ago|reply
[+] [-] kazinator|3 years ago|reply
The licensing server back end for the Tankan kanji learning application runs on CLISP.
[+] [-] tmtvl|3 years ago|reply
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|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] chris_armstrong|3 years ago|reply
[+] [-] jackdaniel|3 years ago|reply
n.b isn't this thread infested with bots? 4 or 5 nicks created 4 days ago with incomplete messages..
[+] [-] SeanLuke|3 years ago|reply
Also very good for education purposes.
[+] [-] vindarel|3 years ago|reply
---
[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]
[+] [-] aidenn0|3 years ago|reply
[+] [-] matrix12|3 years ago|reply
[+] [-] orthecreedence|3 years ago|reply