3 ms·
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
by l_theanine 4y ago
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 4y agore CLHS, there is a new rendering, much more welcoming and practical! https://cl-community-spec.github.io/pages/index.html https://cl-community-spec.github.io/pages/index.html (a search box, syntax highlighting!!)
- l_theanine 4y agoIndeed, 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 4y agoThe GCL documentation (browsable with an info browser, like Emacs) contains a fairly complete reference of the standard.
- blue039 4y agoThis 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.
- aidenn0 4y ago> 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.