23 ms·
A Standard. One thing that has not been mentioned here. The lisp community came together and created a standard. I maintain code from the 1980, part of which i
by daly 9y ago
A Standard. One thing that has not been mentioned here. The lisp community came together and created a standard.
I maintain code from the 1980, part of which is in Common Lisp and part of which is in C. The C code breaks. The latest failure seems to be caused by the GCC compiler changing the semantics of 'inline'. The include files differ between platforms.
The Lisp code just runs.
There are no arguments like Python 2.7 vs Python 3.x. No arguments about C++11 vs C++14. No arguments about Clojure from 4 years ago and Clojure today. No arguments about any of that.
There is a standard. ONE standard. It only matters when you have to maintain someone else's legacy code. But it really matters.
- rurban 9y agoWell, amongst Lispers we do argument a lot about the missing or overarchitectured bits. The ffi, threads, the conditions system, the MOP, ... But only the various FFI's pose a minor problem. It's complaining on a very high level.
- daly 9y agoProbably the most difficult area in the CL standard is handling pathnames. There are so many possible pitfalls. FFI is an area that, despite best efforts, is likely not a good candidate for inclusion in a standard. It would be better to have all of the implementations converge on a convention since the underlying foreign systems will change over time. Not everything that "just works" has to be in a standard. C++ issues a "new standard" every 3 years or so which is just nonsense. Even Stroustrop said that the "new C++" is not the "old C++". They are adding ideas (e.g. Concepts) that virtually no one is asking for or knows how to use. Ten years from now that C++ maintenance job you have will be a nightmare. PL/I tried to be everything to everyone for every task and eventually disappeared. C++ is on the same long-term death march. You heard it here first.