3 ms·

a large part of the CL community treats the spec a bit like a sacred text, in the sense that it is both very good and impossible to change. The most important r

by blue1 8y ago

a large part of the CL community treats the spec a bit like a sacred text, in the sense that it is both very good and impossible to change. The most important reason apparently is that there are no more the resources to do it. Maybe also the struggling commercial vendors do not want to standardize their offer to become too similar to open source implementations?

znpy 8y ago
> a large part of the CL community treats the spec a bit like a sacred text Amen!
junke 8y ago
> a large part of the CL community treats the spec a bit like a sacred text That's not my experience. I'd say that people know what the CL spec currently is, love its stability, and might fear what it could become after an "upgrade". Anybody can write something like CL21, for example, with one's own style and notations. That's why it is frowned upon to do so and to claim that "this" library is how "the" new Lisp should be. Part of growing in Lisp (and programming) is to learn how to work with a language, not against it, and avoid fixing what is not broken. However, I trust Common Lisp compiler developers and vendors to know how to make backward-compatible, useful changes: current common lisp environments have way more facilities and building blocks than the bare minimum required. They also know the pain points that currently exist in the standard in a way that goes beyond aesthetic things.
- blue1 8y ago
  It seems to me that this is a case of making a virtue of necessity: since the language does not evolve, many have learned to love the fact that it does not. To me it looks a lot like a form of Stockholm Syndrome. I find interesting your remark that "anybody can write something like CL21". (Though, not all problems can be solved with a library, but let's stick to this side). In most language, you can't do this kind of customization. In Lisp you can, but anyone else can too, and the result is that after 25 years there is still no standard way to write a hash literal, for example, or to concatenate strings in a non-verbose way. It is difficult to claim that these are good things.
  - phoe-krk 8y ago
    or to concatenate strings in a non-verbose way UIOP:STRCAT. UIOP is present on every contemporary Lisp image as a part of ASDF.
    - blue1 8y ago
      I know it is easy. In this particular example, it is also trivial to write it from scratch. But, if UIOP:STRCAT is such a "standardized" solution as you claim, then I believe it should become part of a (hypothetical updated) Standard, not a second-class citizen behind a member of the ancient aristocracy like Lord CONCATENATE. What I mean is that I think there should be some kind of mechanism so that standardized solutions emerge (from widely used libraries for example) and become part of the Standard. Like it happily happens in many other domains.
      - phoe-krk 8y ago
        I never said that the updated standard should not happen - quite the contrary. I'm saying only that a string contatenation function is already available on every modern Lisp image that has ASDF loaded, and is therefore usable from user code.
      - junke 8y ago
        In Go, in Javascript, in Python, in C++, you have the luxury of having thousands of people who just implement things for you while you sleep. See the list of "gold members" for the Standard C++ Foundation: https://isocpp.org/about https://isocpp.org/about. See the list for Python: https://www.python.org/psf/sponsorship/sponsors/ https://www.python.org/psf/sponsorship/sponsors/ There are people whose jobs is to work on that. When you write "it should become part of a standard", you use the passive voice: who is going to do it? In CL, the effort is focused on things that matter to each individual, or each company that uses it, and sometimes a (de-facto) standard library comes to life.
      - deleted 8y ago
        [deleted]
  - 8y ago
throwaway487548 8y ago
> treats the spec a bit like a sacred text, This is not necessarily bad, especially in the context of education. It is well known for ages that a bit of mystery and sacredness makes rather boring moral education much more emotionally charged. There are no active Common Lisp based courses, as far as I know, the last one was that one of the Alegro team, but it was rather an attempt of promotion and has been done without "religious vigor" unlike the famous CS61A by prof. Brian Harvey, which could be viewed as almost sectarian, especially the very first version from 2008. Similar course could be easily made based on Common Lisp, which includes more advanced concepts in CLOS. At least some zeal is good for education. CS61A and the original SICP course by the Wizards are good and still relevant examples.
bitwize 8y ago
Indeed. Common Lisp should be more like C++, where the right way to write Hello World changes every few years. If your language isn't moving fast and breaking things, it means it's abandoned and probably shouldn't be used for real work.
- blue1 8y ago
  I know you're being sarcastic, but even in the ANSI CL spec the word "deprecated" appears in some places. It's just that since nothing followed to it, the deprecation had no practical effect: the fixedness of the CL spec is just an accidental result of history. As an aging developer I also detest environments that break things every other day, but I have realized that on the other hand system that never move have indeed a tendency to wither, usually in comfortable niches, while the flow of things moves elsewhere.

by blue1 8y ago

znpy 8y ago

> a large part of the CL community treats the spec a bit like a sacred text Amen!

junke 8y ago

> a large part of the CL community treats the spec a bit like a sacred text That's not my experience. I'd say that people know what the CL spec currently is, love its stability, and might fear what it could become after an "upgrade". Anybody can write something like CL21, for example, with one's own style and notations. That's why it is frowned upon to do so and to claim that "this" library is how "the" new Lisp should be. Part of growing in Lisp (and programming) is to learn how to work with a language, not against it, and avoid fixing what is not broken. However, I trust Common Lisp compiler developers and vendors to know how to make backward-compatible, useful changes: current common lisp environments have way more facilities and building blocks than the bare minimum required. They also know the pain points that currently exist in the standard in a way that goes beyond aesthetic things.

blue1 8y ago
It seems to me that this is a case of making a virtue of necessity: since the language does not evolve, many have learned to love the fact that it does not. To me it looks a lot like a form of Stockholm Syndrome. I find interesting your remark that "anybody can write something like CL21". (Though, not all problems can be solved with a library, but let's stick to this side). In most language, you can't do this kind of customization. In Lisp you can, but anyone else can too, and the result is that after 25 years there is still no standard way to write a hash literal, for example, or to concatenate strings in a non-verbose way. It is difficult to claim that these are good things.
- phoe-krk 8y ago
  or to concatenate strings in a non-verbose way UIOP:STRCAT. UIOP is present on every contemporary Lisp image as a part of ASDF.
  - blue1 8y ago
    I know it is easy. In this particular example, it is also trivial to write it from scratch. But, if UIOP:STRCAT is such a "standardized" solution as you claim, then I believe it should become part of a (hypothetical updated) Standard, not a second-class citizen behind a member of the ancient aristocracy like Lord CONCATENATE. What I mean is that I think there should be some kind of mechanism so that standardized solutions emerge (from widely used libraries for example) and become part of the Standard. Like it happily happens in many other domains.
    - phoe-krk 8y ago
      I never said that the updated standard should not happen - quite the contrary. I'm saying only that a string contatenation function is already available on every modern Lisp image that has ASDF loaded, and is therefore usable from user code.
    - junke 8y ago
      In Go, in Javascript, in Python, in C++, you have the luxury of having thousands of people who just implement things for you while you sleep. See the list of "gold members" for the Standard C++ Foundation: https://isocpp.org/about https://isocpp.org/about. See the list for Python: https://www.python.org/psf/sponsorship/sponsors/ https://www.python.org/psf/sponsorship/sponsors/ There are people whose jobs is to work on that. When you write "it should become part of a standard", you use the passive voice: who is going to do it? In CL, the effort is focused on things that matter to each individual, or each company that uses it, and sometimes a (de-facto) standard library comes to life.
    - deleted 8y ago
      [deleted]
- 8y ago

throwaway487548 8y ago

> treats the spec a bit like a sacred text, This is not necessarily bad, especially in the context of education. It is well known for ages that a bit of mystery and sacredness makes rather boring moral education much more emotionally charged. There are no active Common Lisp based courses, as far as I know, the last one was that one of the Alegro team, but it was rather an attempt of promotion and has been done without "religious vigor" unlike the famous CS61A by prof. Brian Harvey, which could be viewed as almost sectarian, especially the very first version from 2008. Similar course could be easily made based on Common Lisp, which includes more advanced concepts in CLOS. At least some zeal is good for education. CS61A and the original SICP course by the Wizards are good and still relevant examples.

bitwize 8y ago

Indeed. Common Lisp should be more like C++, where the right way to write Hello World changes every few years. If your language isn't moving fast and breaking things, it means it's abandoned and probably shouldn't be used for real work.

blue1 8y ago
I know you're being sarcastic, but even in the ANSI CL spec the word "deprecated" appears in some places. It's just that since nothing followed to it, the deprecation had no practical effect: the fixedness of the CL spec is just an accidental result of history. As an aging developer I also detest environments that break things every other day, but I have realized that on the other hand system that never move have indeed a tendency to wither, usually in comfortable niches, while the flow of things moves elsewhere.