8 ms·

Common Lisp is an extremely compact, regular and small language. It comes with a huge standard library that you can but don’t have to use. By that measure, Java

Common Lisp is an extremely compact, regular and small language. It comes with a huge standard library that you can but don’t have to use. By that measure, Javascript would be a large language because it has a big NPM ecosystem. Common Lisp wanted to avoid the problem so that people don’t have to write seven versions of the left pad library. As a result it includes useful stuff in the standard library.

tsimionescu 5y ago
This is probably a bit unfair, because technically things like the object system and conditions and loop are part of the standard library, but they can also be considered part of the core language given their importance in much CL software.
- mrcode007 5y ago
  CLOS is implemented in Common Lisp. These two books explain how it’s done: https://en.m.wikipedia.org/wiki/Object-Oriented_Programming_in_Common_Lisp https://en.m.wikipedia.org/wiki/Object-Oriented_Programming_... https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Pr...
  - tsimionescu 5y ago
    I know it is. That's not the point. The point is that you need to know CLOS with its many rules to understand many CL code bases, just like you need to understand C++ classes. The fact that C++ classes are part of the C++ core langauge while CLOS is a library doesn't really change this aspect.
    - mrcode007 5y ago
      I agree with the claim that knowing CLOS is useful to read code bases. Where I think we differ is that I don’t consider CLOS a part of the language itself. I consider it a part of a particular implementation of the language. You can be a fluent and prolific CL programmer without ever writing any code that relies on CLOS, defstruct or defclass, etc. The big difference between C++ and CL in this particular instance is that you can’t write C++ without writing or using classes/structs. For example, using STL almost always involves using or writing custom comparator “classes”. Even if you choose to go with lambdas, the whole concept of a container is object oriented. In CL, you can, if you want, stick with lists all the way down without ever touching defclass/defstruct at all. An equivalent abstraction level of the C++ code would only use integral data types. Whereas in CL those types are part of the language.

tsimionescu 5y ago

This is probably a bit unfair, because technically things like the object system and conditions and loop are part of the standard library, but they can also be considered part of the core language given their importance in much CL software.

mrcode007 5y ago
CLOS is implemented in Common Lisp. These two books explain how it’s done: https://en.m.wikipedia.org/wiki/Object-Oriented_Programming_in_Common_Lisp https://en.m.wikipedia.org/wiki/Object-Oriented_Programming_... https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Pr...
- tsimionescu 5y ago
  I know it is. That's not the point. The point is that you need to know CLOS with its many rules to understand many CL code bases, just like you need to understand C++ classes. The fact that C++ classes are part of the C++ core langauge while CLOS is a library doesn't really change this aspect.
  - mrcode007 5y ago
    I agree with the claim that knowing CLOS is useful to read code bases. Where I think we differ is that I don’t consider CLOS a part of the language itself. I consider it a part of a particular implementation of the language. You can be a fluent and prolific CL programmer without ever writing any code that relies on CLOS, defstruct or defclass, etc. The big difference between C++ and CL in this particular instance is that you can’t write C++ without writing or using classes/structs. For example, using STL almost always involves using or writing custom comparator “classes”. Even if you choose to go with lambdas, the whole concept of a container is object oriented. In CL, you can, if you want, stick with lists all the way down without ever touching defclass/defstruct at all. An equivalent abstraction level of the C++ code would only use integral data types. Whereas in CL those types are part of the language.