3 ms·

Back in the 70s IBM used a language called PL/I (aka "Pig Language for Idiots). It had EVERYTHING. Every idea from every language showed up in PL/I. Compiling o

by daly 10y ago

Back in the 70s IBM used a language called PL/I (aka "Pig Language for Idiots). It had EVERYTHING. Every idea from every language showed up in PL/I. Compiling on a 6Mhz IBM mainframe took a LONG time. The language was, for its time, very complex. We had one person in the building who was the PL/I guru. If you really needed to understand something he could work out the answer. Everyone else chose a simple subset of the language and never used the fancy features. Unfortunately everyone chose different subsets so maintaining other people's code was a pain. C++ has the same problem; big, slow, and a collection of ideas imported from other languages. For example, "concepts" have been proposed for the next "standard". They appear to be lifted from Axiom's Spad language. The C++ committee seems to feel that "importing" ideas is a way to make C++ into a better, newer "standard". Unfortunately that is simply causing havoc. Forty year old code that no longer compiles because some bright spot decided to change the semantics of "inline" is a huge waste of time. Forty year old code in Common Lisp, which also has a standard, a single standard, just works. The code is fast because there are years worth of optimizations by the compiler writers. C++ isn't a language. It is a laboratory where some people work out ways to do poorly what other languages do well. C++ isn't a language. It is a parade of languages with "standards". Do you really want to have to "fix" legacy working code because it no longer works in C++21? Programming is hard enough. Fixing old code because it "no longer conforms to the standard" is a huge, unnecessary cost in both time and money. Use it at your own peril. Just be aware that the code you write today won't compile next year.

overgard 10y ago
I don't know, every feature added to C++11 and 14 made my life easier. I do think it's a pig of a language, but all the current features and all the upcoming features are things I want. I view C++ a lot like the english language; complex and inconsistent: yep! Incredibly useful: yep!
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".
rootbear 10y ago
"C++ isn't a language. It is a laboratory where some people work out ways to do poorly what other languages do well." Amen! I studied PL/I, in the University of Maryland dialect called PL/UM, in the 70s as a student. I was very glad that it did not catch on. As C++ grew in size and complexity, I realized that it was this generation's C++ but that it had, sadly, succeeded wildly. If PL/I had been a more well known failure, perhaps the authors of C++ would have heeded it's warning. I've been programming in C for a long time. I occasionally dig up decades old code and compile it, usually just for fun. Much of the time, I just need to add a few include files, as old C was more tolerant of calling undeclared functions and such. With all of the changes to C, from K&R, to C89, to C99, to C11, it's nice that the core features have been pleasingly stable. The instability of C++ that the OP comments on is one reason I don't like C++ and I'm happy that I don't have to use it often.

by daly 10y ago

overgard 10y ago

I don't know, every feature added to C++11 and 14 made my life easier. I do think it's a pig of a language, but all the current features and all the upcoming features are things I want. I view C++ a lot like the english language; complex and inconsistent: yep! Incredibly useful: yep!

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".

rootbear 10y ago

"C++ isn't a language. It is a laboratory where some people work out ways to do poorly what other languages do well." Amen! I studied PL/I, in the University of Maryland dialect called PL/UM, in the 70s as a student. I was very glad that it did not catch on. As C++ grew in size and complexity, I realized that it was this generation's C++ but that it had, sadly, succeeded wildly. If PL/I had been a more well known failure, perhaps the authors of C++ would have heeded it's warning. I've been programming in C for a long time. I occasionally dig up decades old code and compile it, usually just for fun. Much of the time, I just need to add a few include files, as old C was more tolerant of calling undeclared functions and such. With all of the changes to C, from K&R, to C89, to C99, to C11, it's nice that the core features have been pleasingly stable. The instability of C++ that the OP comments on is one reason I don't like C++ and I'm happy that I don't have to use it often.