11–20 of 53 posts
Yes, there's a lot of depth to C++ but you derive a lot of benefit from other's wizardry even if you're not a magician yourself.
Maybe this guy didn't invest as much time on C++ as he did on his other languages.
I guess he's not a systems programmer. What language did Slava Pestov turn to when he recently re-wrote Factor's VM? C++ programmers: we do the dirty work so you don't have to.
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
Lets face it C++ is something like 30 years old this year. For a 30 year language to have so many flaws, and for newer languages to make a better job of integrating OO while still keeping the power: you have to ask whether the C++ community really knows all about technology and nothing about design. The whole project has been mislead from start to finish. It strikes me it had to take a couple of ada programmers to write the STL.
From my perspective, most of the stuff about C++ complexity rings untrue. Most people I know seem to know enough about C++ that they can produce pretty good code. Yes, there's a lot of depth to C++ but you derive a lot of benefit from other's wizardry even if you're not a magician yourself. Maybe this guy didn't invest as much time on C++ as he did on his other languages.
If you are just plugging components together I can think of better languages.
In my experience C++ demands more time that most languages to master. Which is a far longer time than, say, C.
That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually faster, with some properly done benchmarks or some valid technical examples.
More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC. I do not know why this fact remains so little-known. [1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same.
Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc.
The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass.
In these days of 16G developer desktops, is this an unreasonable demand? :)
I guess he's not a systems programmer. What language did Slava Pestov turn to when he recently re-wrote Factor's VM? C++ programmers: we do the dirty work so you don't have to.
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
С - simple and stable, C++ - huge and changing. C - portable and easily parseable, C++ - unpredictable and unparseable. C - good, C++ - bad.
I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.
Strict typing was mostly about trapping programming errors at compilation rather than runtime. Perhaps something despite all the effort C++ has struggled to improve defect count through typing (C++ systems often fail for far more obscure reasons, and the strict typing can cause hideous compile-time errors).
I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.
one of the requirements for this kind of speed is for a language to be statically typed No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
Earlier quoted context omitted.
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
Please never, never, never ever write C/C++. С - simple and stable, C++ - huge and changing. C - portable and easily parseable, C++ - unpredictable and unparseable. C - good, C++ - bad.
Earlier quoted context omitted.
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
Hardly, I know many people who spent years learning C++ in the 90's only to avoid it now. The reason is they had no love for the language. The C++ language design has serious flaws that whenever someone brings them up there's the usual, rolling of the eyes and the "yeah we know" sort of look. The if you criticise you must be a dumb attitude is encouraged by the C++ community too, and that was not borrowed from the C…
* VM implementations (I mentioned Factor, but also HotSpot, Microsoft's CLR, SquirrelFish, TraceMonkey, V8 and Opera's Carakan are all high-performance VMs written in C++ (x). Note also that all major layout engines are written in C++. Complex but fast and highly-tuned beasts)
* Production rendering. PRMan, MentalRay and pretty much every other renderer in day-to-day use on film and video post-production are written in C++.
People who write these systems care deeply about performance. They'll dip into assembly when they have to. While fast, C won't cut it because in these cases, it doesn't give you enough abstraction to avoid making your code a mess (strong typing, operator overloading and templates in particular, but also virtual method dispatch)*. I'm sure if you ask them, they'd tell you that they'd love to use something nicer and more modern. But it doesn't yet exist.
This is not to say that C++ is the right tool for writing web applications, or even the average desktop application, or even - increasingly these days - games. But somebody needs to write the stack underneath, and that stack needs to be fast.
(x) note Mono as an example of a VM that sticks with C. But it contains a lot of object-oriented shennanigans that probably could be better expressed in C++, and the core developers came from a strong C culture.
Earlier quoted context omitted.
Indeed. So many of these articles can be boiled down to: "As long as we limit the comparison to things (our language) does well, and exclude things C/C++ do that (our language) can't do at all, (our language) totally 0wnz C/C++".
Please never, never, never ever write C/C++. С - simple and stable, C++ - huge and changing. C - portable and easily parseable, C++ - unpredictable and unparseable. C - good, C++ - bad.
The old C infrastructure is really outdated already -- you can use C and a very limited subset of C++ (without OO), and be perfectly happy.