3 ms·
> [...] Common Lisp, a language which is around 30 years old, but still has an active development community. OTOH many Common Lisp people lament the fact that
by zurn 14y ago
> [...] Common Lisp, a language which is around 30 years old, but still has an active development community.
OTOH many Common Lisp people lament the fact that the standardization stopped with the 1994 spec, saying
it led to the fragmentation of the implementations with
mutually incompatible extensions.
Do you think it would have hurt Common Lisp if there had been one dominant implementation that everyone followed and reused libraries from, like with Python?
- pnathan 14y ago> OTOH many Common Lisp people lament the fact that the standardization stopped with the 1994 spec, saying it led to the fragmentation of the implementations with mutually incompatible extensions. There is room for an update, I think. Probably something to do with thread memory semantics. But the language itself provides facility for a great deal of extension. E.g., the default threading API (bordeaux-threads) is be identical cross-implementation, although the exact Lisp system calls will vary. You have to be careful to consider what exactly needs to be changed and what can simply be added by a macro & library function. Certain guarantees relating to memory will fall in that area. Of course I do not think CL is perfect. For one thing, it could have used a respin post-CLOS to have a smoother type system and better interfaces. > Do you think it would have hurt Common Lisp if there had been one dominant implementation that everyone followed and reused libraries from, like with Python? Yes. There's only 1 python: python.org's python. Never mind Jython, IronPython, and PyPy. We all are tied to CPython. :-( It defines the situation, regardless of the docs. Really not ideal for the Python world. Having a regularly evolving standard means that you have to port your code constantly to ensure you're up to date with the latest hotness... or even be able to interrelate with newer code. One of the great strengths of the POSIX standard & C is that C89 has stayed constant and available on *nix for the last two decades; C itself has stayed mostly constant for about three and a half. The cost of forcing regular change is enormous and may well destroy a community. rachelbythebay, a blogger I follow, wrote a post I can't find right now, on the problems when you rely on this sort of situation. She does a lot of sysadmin work, usually (I guess) in C++, and was astounded when she learned that just upgrading your system might shatter your software in Perl or whathave you. I have that opinion (based on my experience) as well. Having to have had to contend with Python 2.4, 2.5, 2.6, and 2.7 all in the same company for the same codebase, I have this conclusion: do it right the first time, second if you can swing it. Common Lisp succeeds at that (n.b., before CL, lots of Lisp fragmentation existed). Python fails. C wins. Perl 5 is trying to have run-time machine switching based on specified version (may have details wrong there). Ruby fails. C++98 is "ok", C++11 may be a bear. I do think that a language should be excruciatingly small and very effective, and libraries should be built around that language; this allows libraries to be evolved/replaced without having the core language altered. C got this right. Scheme from R1-R4 also went this road, but as it is an academically driven language, its been in the shadows by and large. I guess newer Schemes have bigger standards though.