3 ms·

I think it is a pretty shallow view at standard. CL implementations grow and have agreed interfaces (or portability layers). A few examples: - sockets via usoc

I think it is a pretty shallow view at standard. CL implementations grow and have agreed interfaces (or portability layers). A few examples: - sockets via usocket - threading via bordeaux-threads - metaobject protocol via closer-mop - foreign function interface via cffi all these are not mentioned in the standard at all, but are implemented and used in production environment. Having base standard and extensions which may be used portably (via portability layers) is better situation than having no standard (for instance python or ruby) and a reference implementation.

pjmlp 9y ago
Which usually is what leads to feature expressions spaghetti. Also, it means that a Lisp newbie won't be aware of what are the best libraries that are portable across Lisps for such features. EDIT: typo correction (missing are)
- jackdaniel 9y ago
  Feature expressions shouldn't be used in normal applications, only in portability libraries. To use threads on any implementation which supports them (given it's supported by the recommended portability layer): > (ql:quickload 'bordeaux-threads) > (bt:make-thread (lambda () (sleep 1) (print "hijack"))) that's all, no feature expressions whatsoever. Quicklisp is a system manager (something similar to npm in sense that it helps you to download dependencies). Regarding best libraries: isn't that true for any language? Newbie doesn't know good libraries, because he is a newbie. He has to learn which libraries are good and which are bad. edit: and by each supported implementation I mean in fact all active complete Common Lisp implementations: ArmedBear, Allegro, clisp, Clozure, Corman, Embeddable, Man-Kai, LispWorks, Steel-Bank and Scieener.
  - pjmlp 9y ago
    I kind of agree with you, however the beauty of a language standard is being the point of reference for libraries and language semantics. In any case, the Lisp like languages I use aren't Common Lisp (Clojure, Emacs Lisp, Script-Fu), so that was just an idea.
  - moomin 9y ago
    I think the point is you can't really have it both ways. CL prides itself on its extensive and portable standard library, but has huge gaps by the standards of modern languages.
    - flavio81 9y ago
      > but has huge gaps by the standards of modern language Please detail, because i'm sure that the Lisp community would love to fill those gaps. After all, Lisp is addictive to the point of resembling a hard drug.
      - moomin 9y ago
        Well, start with the stuff that OP's just been arguing doesn't need a standard implementation. :)
- kgwgk 9y ago
  Only if portability is a goal. One can stick to one implementation and use the extensions provided. There are also portability isssues when people wants to use different python implementations!
  - deleted 9y ago
    [deleted]
KirinDave 9y ago
> Having base standard and extensions which may be used portably (via portability layers) is better situation than having no standard (for instance python or ruby) and a reference implementation. Is it though? I agree CL has (after slightly over 2 decades) worked out a standardization path for some core features that you simply cannot live without (e.g., usocket). But all these variants are noticeably dated abstractions and in many cases the more modern expressions (e.g., threading vs more modern concurrency tooling) can't (or don't) use the compat libraries. I'd rather have one good, crossplatform reference implementation than many competing but slightly incompatible implementations that only agree on very old standards. In that sense, I'd rather use Racket than CL. It's true, letting go of some CL features is painful and you'll never get them back. CL's condition-restarts are an especially poignant loss in this modern era of Golang's almost comically regressive error handling schemes. I'd like to think that if CL'er start to disperse more into other language communities that their gentle pressure and eloquent examples can help motivate other communities to adopt these features.
- jackdaniel 9y ago
  Good example of what you're talking about is lparallel library (check out lparallel.org) - it is modern concurrency library build on top bordeaux-threads. lfarm is example of another library workinng on top of usocket which does the same for distributed computing.

pjmlp 9y ago

Which usually is what leads to feature expressions spaghetti. Also, it means that a Lisp newbie won't be aware of what are the best libraries that are portable across Lisps for such features. EDIT: typo correction (missing are)

jackdaniel 9y ago
Feature expressions shouldn't be used in normal applications, only in portability libraries. To use threads on any implementation which supports them (given it's supported by the recommended portability layer): > (ql:quickload 'bordeaux-threads) > (bt:make-thread (lambda () (sleep 1) (print "hijack"))) that's all, no feature expressions whatsoever. Quicklisp is a system manager (something similar to npm in sense that it helps you to download dependencies). Regarding best libraries: isn't that true for any language? Newbie doesn't know good libraries, because he is a newbie. He has to learn which libraries are good and which are bad. edit: and by each supported implementation I mean in fact all active complete Common Lisp implementations: ArmedBear, Allegro, clisp, Clozure, Corman, Embeddable, Man-Kai, LispWorks, Steel-Bank and Scieener.
- pjmlp 9y ago
  I kind of agree with you, however the beauty of a language standard is being the point of reference for libraries and language semantics. In any case, the Lisp like languages I use aren't Common Lisp (Clojure, Emacs Lisp, Script-Fu), so that was just an idea.
- moomin 9y ago
  I think the point is you can't really have it both ways. CL prides itself on its extensive and portable standard library, but has huge gaps by the standards of modern languages.
  - flavio81 9y ago
    > but has huge gaps by the standards of modern language Please detail, because i'm sure that the Lisp community would love to fill those gaps. After all, Lisp is addictive to the point of resembling a hard drug.
    - moomin 9y ago
      Well, start with the stuff that OP's just been arguing doesn't need a standard implementation. :)
kgwgk 9y ago
Only if portability is a goal. One can stick to one implementation and use the extensions provided. There are also portability isssues when people wants to use different python implementations!
- deleted 9y ago
  [deleted]

KirinDave 9y ago

> Having base standard and extensions which may be used portably (via portability layers) is better situation than having no standard (for instance python or ruby) and a reference implementation. Is it though? I agree CL has (after slightly over 2 decades) worked out a standardization path for some core features that you simply cannot live without (e.g., usocket). But all these variants are noticeably dated abstractions and in many cases the more modern expressions (e.g., threading vs more modern concurrency tooling) can't (or don't) use the compat libraries. I'd rather have one good, crossplatform reference implementation than many competing but slightly incompatible implementations that only agree on very old standards. In that sense, I'd rather use Racket than CL. It's true, letting go of some CL features is painful and you'll never get them back. CL's condition-restarts are an especially poignant loss in this modern era of Golang's almost comically regressive error handling schemes. I'd like to think that if CL'er start to disperse more into other language communities that their gentle pressure and eloquent examples can help motivate other communities to adopt these features.

jackdaniel 9y ago
Good example of what you're talking about is lparallel library (check out lparallel.org) - it is modern concurrency library build on top bordeaux-threads. lfarm is example of another library workinng on top of usocket which does the same for distributed computing.