5 ms·

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent

by sklogic 12y ago

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

lispm 12y ago
Depends on what you mean by 'big'. Physically it is not too big for typical applications. 'mentally' it may be too big for some developers. After a while then greenspun's tenth rule kicks in... 'Common Lisp' also does not mean it needs the full language. Some applications use subsets.
- sklogic 12y ago
  Big is over 1000 pages of a spec.
wtbob 12y ago
I know folks used to say that Common Lisp was too big, comparing it to C or Pascal. But is it really big compared to, e.g., Python, JavaScript or Ruby? If anything, a common complaint now is that too little is standardised (which is true, but good portable libraries exist for most such things). And, as lispm notes, one can implement a subset of Common Lisp—all that's required is that one define the subset.
- sklogic 12y ago
  Interestingly, so far people preferred to implement dialects of Lisp-1 mostly. Not that many Common Lisp subsets or even Common Lisp-inspired languages around. I can only name Shen as one obvious exception from this rule.
sedachv 12y ago
> And it's a Lisp-2, which is quite a deterrent for many. I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.
- sklogic 12y ago
  For me it's clearly a deterrent - it does not fit at all into my model of building hierarchies of DSLs.
  - sedachv 12y ago
    > it does not fit at all into my model of building hierarchies of DSLs Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry that my function name is going to clobber some reference in the template system.
    - sklogic 12y ago
      See https://github.com/combinatorylogic/mbase https://github.com/combinatorylogic/mbase Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort. Of course, macros must have their own namespace, but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.
      - sedachv 12y ago
        > Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort. How so? And why only two namespaces? Common Lisp probably has a dozen: package name, lexical variable, dynamic variable, function (stores either function or macro function), documentation string, property list, type name, class name, slot name, etc. As long as you have first-class identifiers, you can define arbitrary namespaces without having to worry about conflicts between the namespaces. > Of course, macros must have their own namespace That doesn't have to be true, and is not true in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Body/03_bba.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_bba... Having an identifier denote a function and a macro at the same time like that enables adding partial evaluation and other compile-time optimizations to DSLs without having to dig into the compiler. > but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway. ? You have to mix them if you want a compiler in your runtime.

by sklogic 12y ago

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

lispm 12y ago

Depends on what you mean by 'big'. Physically it is not too big for typical applications. 'mentally' it may be too big for some developers. After a while then greenspun's tenth rule kicks in... 'Common Lisp' also does not mean it needs the full language. Some applications use subsets.

sklogic 12y ago
Big is over 1000 pages of a spec.

wtbob 12y ago

I know folks used to say that Common Lisp was too big, comparing it to C or Pascal. But is it really big compared to, e.g., Python, JavaScript or Ruby? If anything, a common complaint now is that too little is standardised (which is true, but good portable libraries exist for most such things). And, as lispm notes, one can implement a subset of Common Lisp—all that's required is that one define the subset.

sklogic 12y ago
Interestingly, so far people preferred to implement dialects of Lisp-1 mostly. Not that many Common Lisp subsets or even Common Lisp-inspired languages around. I can only name Shen as one obvious exception from this rule.

sedachv 12y ago

> And it's a Lisp-2, which is quite a deterrent for many. I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.

sklogic 12y ago
For me it's clearly a deterrent - it does not fit at all into my model of building hierarchies of DSLs.
- sedachv 12y ago
  > it does not fit at all into my model of building hierarchies of DSLs Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry that my function name is going to clobber some reference in the template system.
  - sklogic 12y ago
    See https://github.com/combinatorylogic/mbase https://github.com/combinatorylogic/mbase Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort. Of course, macros must have their own namespace, but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.
    - sedachv 12y ago
      > Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort. How so? And why only two namespaces? Common Lisp probably has a dozen: package name, lexical variable, dynamic variable, function (stores either function or macro function), documentation string, property list, type name, class name, slot name, etc. As long as you have first-class identifiers, you can define arbitrary namespaces without having to worry about conflicts between the namespaces. > Of course, macros must have their own namespace That doesn't have to be true, and is not true in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Body/03_bba.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_bba... Having an identifier denote a function and a macro at the same time like that enables adding partial evaluation and other compile-time optimizations to DSLs without having to dig into the compiler. > but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway. ? You have to mix them if you want a compiler in your runtime.