4 ms·

> Forty year old code in Common Lisp, which also has a standard, a single standard, just works. Mostly. If not, just (pushnew :symbolics features) or w

by jlg23 10y ago

> Forty year old code in Common Lisp, which also has a standard, a single standard, just works. Mostly. If not, just (pushnew :symbolics *features*) or whatever the code was created on. Especially the very old lisp code regularly needs some coercion to be made run on a standard compliant cl. The "just works" part is proven wrong by the regularly reoccurring attempts to agree on extensions to the standard and the myriads of libraries out there that provide generic wrappers around implementation specifics. > C++ isn't a language. It is a laboratory where some people work out ways to do poorly what other languages do well. "Lisp isn't a language, it's a building material." -- Alan Kay and "A poor coder can write poor code in any language." -- me

Animats 10y ago
Almost. I recently revived the original Boyer-Moore theorem prover from the 1992 sources. I had to make only one change to get it to run with Gnu Common LISP. The name "EXECUTE" is now being used by a standard library, and I had to rename a function.[1] (It's fun running that on modern hardware. It was painfully slow when I ran the original around 1980. Now it can prove the basic theorems of number theory in a few seconds.) [1] https://github.com/John-Nagle/nqthm https://github.com/John-Nagle/nqthm
daly 10y ago
It is true that my lisp 1.5, maclisp, lisp360, VMLisp, Interlisp, and Symbolics code need rewrites to run but that code predates the Common Lisp standard. There are things I'd like to see in Common Lisp but not enough to require a new standard. If there is ever a new standards effort it should start by absolutely, positively REQUIRING that ALL code compliant with the prior standard MUST work unchanged under the new standard. The new C++ features like 'auto' simplify life in new code, which should not have been complicated in the first place. Where life gets ugly is with existing code written years ago. My C++ legacy code regularly breaks. gcc seems to default to C++11 but g++ uses C++14 by default. Breaking 'inline' behavior is just wrong. It seems that the Boost library is partially broken, apparently due to compiler implementation issues. Stop-gap measures, like compiler flags, just make the pain all that more intense. I'd be quite happy if the standards committee decided to create new languages (e.g. C11, C14, C17, etc) so it would be possible to say "I use C11". As it now stands I don't believe ANYONE who says they "know" C++. Are you up to speed on "concepts"? Even Stroustrop described the last "standard" as "a totally new language".

> Forty year old code in Common Lisp, which also has a standard, a single standard, just works. Mostly. If not, just (pushnew :symbolics *features*) or w

by jlg23 10y ago

Animats 10y ago

Almost. I recently revived the original Boyer-Moore theorem prover from the 1992 sources. I had to make only one change to get it to run with Gnu Common LISP. The name "EXECUTE" is now being used by a standard library, and I had to rename a function.[1] (It's fun running that on modern hardware. It was painfully slow when I ran the original around 1980. Now it can prove the basic theorems of number theory in a few seconds.) [1] https://github.com/John-Nagle/nqthm https://github.com/John-Nagle/nqthm

daly 10y ago

It is true that my lisp 1.5, maclisp, lisp360, VMLisp, Interlisp, and Symbolics code need rewrites to run but that code predates the Common Lisp standard. There are things I'd like to see in Common Lisp but not enough to require a new standard. If there is ever a new standards effort it should start by absolutely, positively REQUIRING that ALL code compliant with the prior standard MUST work unchanged under the new standard. The new C++ features like 'auto' simplify life in new code, which should not have been complicated in the first place. Where life gets ugly is with existing code written years ago. My C++ legacy code regularly breaks. gcc seems to default to C++11 but g++ uses C++14 by default. Breaking 'inline' behavior is just wrong. It seems that the Boost library is partially broken, apparently due to compiler implementation issues. Stop-gap measures, like compiler flags, just make the pain all that more intense. I'd be quite happy if the standards committee decided to create new languages (e.g. C11, C14, C17, etc) so it would be possible to say "I use C11". As it now stands I don't believe ANYONE who says they "know" C++. Are you up to speed on "concepts"? Even Stroustrop described the last "standard" as "a totally new language".