181–190 of 193 posts
Earlier quoted context omitted.
Yes, truly the only thing holding C++ back has been lack of features. Have a link: http://yosefk.com/c++fqa/
Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?
Earlier quoted context omitted.
I think that's because they have a lots of Java code to compile. When there are a lot of GO codes to compile, it will take hours as well. I doubt GO's compile speed is significantly faster than Java. Both of them don't have the dependency problem plaguing C++. It would be interesting to compare the two.
I'm pretty sure that go's compile speed is significantly faster than java. It's hard to compare though because java compilation is not the same thing. There is the bytecode in the class files and on the fly compilation in the vm. As well as some stuff that happens when the bytecode is loaded and run. A lot of go's compile speed comes from how simple it's syntax is besides the gains it gets from avoiding C++ dependenc…
Earlier quoted context omitted.
> From the outside, C++ appears to be such a mess Implying that you don't exactly even know the language, if it really is such a mess you think it is. I bet a bunch it really isn't. > I actually cannot tell whether C++1 made it better or worse. This really just shows the fact that you are clueless about C++ and what C++11 brings to the table. Whatever you think has no relevance. Not because your opinion would be less…
Wait, wait. > Safety - Standardized smart pointers, nullptr, better type-safety > Of course, those who use the language just avoid them and those who don't use the language keep bitching about them. Strange. Dumb pointers are built into the language. They just look like an asterisk. Smart pointers are, at best, something like `unique_ptr `. So C++11 continues to have the error-prone variant as the default, and you ha…
> So C++11 continues to have the error-prone variant as the default
Yes, and rightly so. What would happen to the existing code if the "default" pointers became smart pointers? Would they be unique? shared? weak? Also backwards compatibility with C would be gone, stopping people from using C++ as a better C with improved functionality. Of course, everything would break and some people would possibly even rejoice!
> Your argument is that C++11 is great
No. My argument is that C++11 is an improvement and that there's nothing better in the market which could be used where C++ is being used in, without sacrificing portability, efficiency, productivity and existing investment in skill and knowledge. As I've mentioned in various replies, I'd be more than happy to move onto language which let's me do what I'm doing with C++ - unfortunately no such language exists. C# makes me tied to Microsoft's platform(Mono is bullshit, don't even bother). Java ties me to Oracle and Java's own platform built upon JVM, compromises efficiency, forces programming paradigm and exposes to whatever problems the Java implementation may have now and in the future. D seems to be like C++ with some changes, less tools, portability, performance and libraries available. Needless to say Python and Ruby aren't even considered. Rust is very unstable, features come and go, tools don't exist, books don't exist, perhaps the whole language won't exist in 5 years. Go seems more mature and seemingly the most potent candidate, although with various drawbacks(no support for libraries, whatever written in Go can't be included with other languages).
> In fact you deride anyone who uses the core language as merely not understanding C++ well enough or creating "poor design"
Anyone who plays with fire and burns themselves while doing so can do nothing but blame themselves, I'm sure you agree. There's no denying the fact that using C++ correctly is actually hard. It's not so much because of the language itself(I'm not saying language hasn't got problems) than the ways it's being taught. For example, if you Google for C++ tutorials, you see things like naked new and delete, using explicit resource management where RAII would've been sufficient, not taking advantage of STL, ... Take a modern book dedicated towards learning C++11 from the ground up(e.g. C++ Primer, 5th edition) which actually avoids lots of problems and uses the language in a safe, efficient way. I'm sure anyone learning the language that way instead of from books dating back to mid 90's, from people who still consider C++ as "C with Classes" actually avoids lots of the problems you've mentioned. I assume I don't have to mention about actually designing software and the complexity of it regardless of the language. It's very loosely tied to the language itself, rather than the core concepts, requirements and benefits behind the design that it's clear that the designer is to be blamed for any issues.
> You are blaming the user for not using the tool in a way it was clearly not designed, because that other way happens to work better. Maybe it's not just me. Maybe, just maybe, this tool sucks and you're so used to it that you can't believe anyone else would possibly not want to use it.
The "tool" is flexible. In many cases as the programming language and practices evolve, we find better ways to do things and I think this is a good thing. This happens with every language. How would a Python programmer from 1997 compare to what we have today?
I don't consider the language to be perfect, but it does what it's intended to do the best what there's available. Feel free to provide alternative languages for systems programming in the domain in which C and C++ work in. Alternatively I wouldn't mind alternatives even for the domain in which I work in(3D simulations, games, computer graphics).
> and without having to deal with rhetoric like this implying that anyone who doesn't think favorite tool X is the height of perfection must just not understand it well enough.
A language does not have to be the height of perfection to be the best tool to do the job with. As it should be quite clear by now, I don't consider Go or Rust to be viable alternatives for C++ in many domains for the upcoming years. We both know why.
Earlier quoted context omitted.
Nice, but you're 4 years late, sir! Everything can be viewed in a bad light if it's wanted to and we both know it. So how about actually talking about the bigger picture, and problems with programming languages and the actual art of creating large-scale software rather than trying to be smart?
C++0x has some useful features, but it doesn't address Yossi's complaints about C++, which are at a more fundamental level.
Earlier quoted context omitted.
Some tasks - such as implementing kernels - are poorly suited for garbage collection. And while there do exist garbage collectors that can be used in hard real-time scenarios ( http://queue.acm.org/detail.cfm?id=1217268 ), that's not the norm. I think there will always be a place, at the lowest levels, for manual memory management. Providing abstractions to make that as safe and manageable as possible is a Good Thing…
Some tasks - such as implementing kernels - are poorly suited for garbage collection Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications. Of course there's a bunch of different definitions of "hard realt…
Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
Earlier quoted context omitted.
I'm a C die-hard as well. Tell you what I'm doing lately, that makes me less and less interested in the new-school elite, and just generally enjoying a language 'enigma' moment: putting Lua in everything. That is, I mean to say, Rust is neat and all but we can do it all in Lua, pretty well, too. Table types are fabulous, kids! And being able to take any collection of C libraries, and glue them together into 'ones own…
Is this intentionally snide? You appear to be implying that nobody should try to solve problems, because we already know how to work around them.
Earlier quoted context omitted.
Some tasks - such as implementing kernels - are poorly suited for garbage collection Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications. Of course there's a bunch of different definitions of "hard realt…
Your definition of hard real time is the accepted definition; playing movies and such is soft real time. Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
Earlier quoted context omitted.
C++0x has some useful features, but it doesn't address Yossi's complaints about C++, which are at a more fundamental level.
Yossi, by his own words, is a whiner. The fundamental reason behind is attitude towards C++ is to stir up controversy, rather than to provide objective criticism. If his attitude was sincere, I'm sure he wouldn't have spent so much effort in mastering the language.
Earlier quoted context omitted.
Yossi, by his own words, is a whiner. The fundamental reason behind is attitude towards C++ is to stir up controversy, rather than to provide objective criticism. If his attitude was sincere, I'm sure he wouldn't have spent so much effort in mastering the language.
ad hominem.
Any form of critique towards a biased source can always be countered with claims of it being an ad hominem argument - which it strictly speaking usually is - but that alone does not make the critique false or the original source any more reliable.
As an example, many of the points Yossi makes are subjective and opinionated and as such FQA is nowhere near an unbiased and reliable source of problems within the language. Nobody who actually wants to be serious about the subject cites FQA as a whole. At best, individual points he makes with which many agree with. Including Bjarne himself.
Earlier quoted context omitted.
Your definition of hard real time is the accepted definition; playing movies and such is soft real time. Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
I don't think Go is intended to replace C. It was intended to replace C++.