4 ms·

> 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, l

by 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]
- Jach 8y ago
  It's a curious situation for sure. QBasic shares the property that you can run decades old code unmodified, but we don't celebrate that language. I think a certain amount of resistance to updating it must also come from looking at other languages that have no spec whatsoever (not even an old one) and are doing or have done just fine. Then you look at the various problems that would be addressed by an ANSI update, and see that so many of them are resolved with libraries that work across implementations, some bundled OOTB with implementations, and easy to get via quicklisp if not. And as you bring up, though there's not a standard for hash literals, which aesthetically sucks, you still have a gorillion choices you can import including writing your own in a few lines to fit your aesthetics if you can't stand the alists. Lisp is powerful enough to support such flexible choices without a headache. A serious effort would probably benefit from talking to the C++ people. Since my knowledge of C++ is basically stuck at C++98 + a few Boost utils, my outside perspective is that C++0x and eventually C++11-C++17 were just standardizing what were already halfway de-facto standards in Boost (halfway because you could get a lot of questionable looks for including Boost from some parts of the community, and the limitations of C++ meant some things didn't look or debug as nice as if there were compiler support). Still, with the standard the syntax has grown quite a bit and some of it can be more pleasing than the Boost macros. Did it break anyone? Probably, but at least compilers let them compile with old standards. It'd be a good conversation with C++ committee people especially to see what it took to finally update such an old spec. A CL update would surely need a similar feature of running under the old spec, since e.g. if you're adding literal hash table support you're almost surely going to break someone who was using that syntax choice for something else.
  - deleted 8y ago
    [deleted]

by junke 8y ago

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]
Jach 8y ago
It's a curious situation for sure. QBasic shares the property that you can run decades old code unmodified, but we don't celebrate that language. I think a certain amount of resistance to updating it must also come from looking at other languages that have no spec whatsoever (not even an old one) and are doing or have done just fine. Then you look at the various problems that would be addressed by an ANSI update, and see that so many of them are resolved with libraries that work across implementations, some bundled OOTB with implementations, and easy to get via quicklisp if not. And as you bring up, though there's not a standard for hash literals, which aesthetically sucks, you still have a gorillion choices you can import including writing your own in a few lines to fit your aesthetics if you can't stand the alists. Lisp is powerful enough to support such flexible choices without a headache. A serious effort would probably benefit from talking to the C++ people. Since my knowledge of C++ is basically stuck at C++98 + a few Boost utils, my outside perspective is that C++0x and eventually C++11-C++17 were just standardizing what were already halfway de-facto standards in Boost (halfway because you could get a lot of questionable looks for including Boost from some parts of the community, and the limitations of C++ meant some things didn't look or debug as nice as if there were compiler support). Still, with the standard the syntax has grown quite a bit and some of it can be more pleasing than the Boost macros. Did it break anyone? Probably, but at least compilers let them compile with old standards. It'd be a good conversation with C++ committee people especially to see what it took to finally update such an old spec. A CL update would surely need a similar feature of running under the old spec, since e.g. if you're adding literal hash table support you're almost surely going to break someone who was using that syntax choice for something else.
- deleted 8y ago
  [deleted]