Re:New languages & successor to C++ ?
by
rjh
·
· Score: 4
First, I think you could successfully persuade Bjarne to agree that C++ is not C's successor; it is now its own totally distinct language from C, which supports a very large subset of the ISO C90 specification.
C has no successor, because it doesn't need one. C is meant to be a portable assembly language, and it does that remarkably well. It will continue to do it remarkably well for years to come. The problem set C was originally meant to address is still around, and C still addresses that problem set very well.
C++ did not "do it pretty badly". People who condemn C++ so broadly generally don't know the first thing about the language (free hint: there's a lot more to it than the "class" keyword). Is the language spec large? Yes. The Jargon File is dead accurate when it says that the language spec is just at the limit of memory. The language spec is large because C++, moreso than any language other than Perl, is a Swiss Army chainsaw.
You want generic programming? It's in there. You want an OO language? It's in there. You want a pure OO language? You can write pure OO in C++ (need a few libraries). You want a procedural language? It's in there. C++ can be usefully used in a staggering variety of problem sets, but only if the programmer understands that there's more than one way to solve things.
C++ gets its bad reputation more from lousy programmers than from flaws in the language itself.
My own C++ code winds up looking like Perl by the time I'm done with it. Something as simple as:
... Presto. You get the encryption functionality, you get error handling, you get secure memory management facilities, you get versatile file and network I/O, all without needing to bat an eyelash.
Sometime, take a look at Bjarne Stroustrup's homepages. He's got a great comparison of C versus C++ for a trivial enter-your-name program.
C has no successor because it doesn't need one. The problem set C was meant to address is still with us, and C is still a great way to solve those problems.
C++ is not C's successor. It was not meant to be. It addresses a much larger, much different problem set.
Smart hackers will know when a C++ approach is called for (more accurately, which C++ approach is called for--there are many to choose from), and when a C approach is called for, and when a LISP or Standard ML approach is called for.
Specialization is for weenies.:)
Re:New languages & successor to C++ ?
by
sconeu
·
· Score: 4
\i{How is C/C++ going to be patched *cough hacked cough* to support 128-bit integers? "long long long"?}
maybe "really long long"?
There goes my karma!
-- General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Is Plan 9 taking off?? I would really like to ditch this Linux crap and use something a little more current!!
plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.
however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language
(Limbo) in which Ritchie has had
a strong influence.
in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.
there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows!
if you want to get a feel for it, there's even a
shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.
Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.
it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.
(Really pushes it hardest??? Oh right, as opposed to Linux where so many of my devices aren't represented as files. Let's face it, a friend of mine cats vi to/dev/audio for an alarm clock. How much harder can you push the concept? )
lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.
plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).
ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.
i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.
First, I think you could successfully persuade Bjarne to agree that C++ is not C's successor; it is now its own totally distinct language from C, which supports a very large subset of the ISO C90 specification.
/* Variable and object decls */
/* Three lines for all the functionality */
:)
C has no successor, because it doesn't need one. C is meant to be a portable assembly language, and it does that remarkably well. It will continue to do it remarkably well for years to come. The problem set C was originally meant to address is still around, and C still addresses that problem set very well.
C++ did not "do it pretty badly". People who condemn C++ so broadly generally don't know the first thing about the language (free hint: there's a lot more to it than the "class" keyword). Is the language spec large? Yes. The Jargon File is dead accurate when it says that the language spec is just at the limit of memory. The language spec is large because C++, moreso than any language other than Perl, is a Swiss Army chainsaw.
You want generic programming? It's in there. You want an OO language? It's in there. You want a pure OO language? You can write pure OO in C++ (need a few libraries). You want a procedural language? It's in there. C++ can be usefully used in a staggering variety of problem sets, but only if the programmer understands that there's more than one way to solve things.
C++ gets its bad reputation more from lousy programmers than from flaws in the language itself.
My own C++ code winds up looking like Perl by the time I'm done with it. Something as simple as:
int main(int argc, const char *argv[])
{
try
{
string key(argv[1]);
fishtank::blowfish cipher(key, fishtank::ENCRYPT);
std::ifstream infile("myfile.txt");
std::ofstream outfile("myfile.txt.encrypted");
cipher << infile;
cipher.process();
cipher >> outfile;
}
catch (exception &e)
{
std::cerr << "Exception condition caught" << endl;
std::cerr << e.what() << endl;
return 1;
}
return cipher.result();
}
... Presto. You get the encryption functionality, you get error handling, you get secure memory management facilities, you get versatile file and network I/O, all without needing to bat an eyelash.
Sometime, take a look at Bjarne Stroustrup's homepages. He's got a great comparison of C versus C++ for a trivial enter-your-name program.
C has no successor because it doesn't need one. The problem set C was meant to address is still with us, and C is still a great way to solve those problems.
C++ is not C's successor. It was not meant to be. It addresses a much larger, much different problem set.
Smart hackers will know when a C++ approach is called for (more accurately, which C++ approach is called for--there are many to choose from), and when a C approach is called for, and when a LISP or Standard ML approach is called for.
Specialization is for weenies.
\i{How is C/C++ going to be patched *cough hacked cough* to support 128-bit integers? "long long long"?}
maybe "really long long"?
There goes my karma!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
plan 9 is cool (it's the OS that i use for development), but due to the usual difficulty of developing PC drivers (in particular graphics cards) it probably won't work with your existing h/w configuration.
however, as dennis says in the interview, most of plan 9's features are in Inferno. in fact, Inferno's is basically a slimmed down Plan 9 with virtual machine and a new language (Limbo) in which Ritchie has had a strong influence.
in lots of ways, Inferno is considerably more sleek than plan 9 - it is a real OS, but it's also a "virtual OS" that will run hosted under plan 9 or Windows or Linux or BSD or... the same programs run identically on all Inferno platforms.
there's even a version of Inferno that runs as a plug-in inside Internet Explorer on Windows! if you want to get a feel for it, there's even a shell prompt to play with for command line addicts. not to mention a few other little demos to get a feel for the performance of the thing. i'm afraid the plugin doesn't currently run under Netscape or platforms other than Linux, but the full download does.
Inferno and Plan 9 are both OSs "done right", maintaining a healthy balance between performance-related pragmatism and theoretical purity. compared to the tangled morass that is Java or any of the more recent Unix variants (and i'm afraid i don't exclude Linux), they're a breath of fresh air.
it was plan 9 which John Carmack once described as "achingly beautiful" and he's not wrong.
lots harder.
in plan 9, any old program can present a filesystem, and it can then interpret operations on that filesystem at will. basically, you can mount one end of a pipe. filesystem requests on any file or directory below the mountpoint turn into RPC messages down the pipe. so MIME mailboxes are presented as a filesystem, the editor cum window system acme allows program interaction through a filesystem, access to ftp is provided through a filesystem, etc, etc.
plan 9 doesn't have an ioctl call, which means that an enormous amount of functionality is available via straight shell commands (echo, cat, et al).
ok, so the ideas might not be completely new, but the implementation works really well in practise. and it means that a sophisticated system can be built out of small chunks of code, which in turn means that the whole system is more understandable and more reliable.
i can create windows with echo, look back through history with cd and extract parts of cpio archives with cat - and all of this functionality can be transparently exported and imported securely across the net.
tell me that's not pushing it further!