C++ is a horrible language ~ Linus Torvalds
I don't recall ever bashing Scala. I did mention back when rapidcoder was still xorebxebx that I did not like the language as much as I liked C++, but I never explicitly bashed it.
Java... well, I'll admit that for me that's a mixed bag. While I do not like its "make everything easy on the programmer at the expense of giving her control" philosophy (that what it feels like to me), I can see that for some (especially beginning) programmers, that is a good thing. I will respond to claims that I believe to be inherently untrue about the Java platform, but I try not to let my opinions get in the way of that.
-Albatross
Java... well, I'll admit that for me that's a mixed bag. While I do not like its "make everything easy on the programmer at the expense of giving her control" philosophy (that what it feels like to me), I can see that for some (especially beginning) programmers, that is a good thing. I will respond to claims that I believe to be inherently untrue about the Java platform, but I try not to let my opinions get in the way of that.
-Albatross
I am surprised Linus made such remarks but personally for me, I would not go to the extent of bashing other programming languages that I did not use or use and gave up. I believe each programming language is created for a purpose and for some business cases, programming language A excels and for some other business cases, other programming language B excels and so on and so forth.
I don't think C++ is a horrible language, it just have it's those nuances that take getting used to. But the same could be said of C as well. And also for Java and also for Perl and so on and so forth.
So instead of arguing over the programming language preferences, why not dwell on which programming language fit the business case on hand isn't it ? That is, some programming language is just easier and better than others in solving certain specific business cases.
Sidenote: I am still waiting for some programming language that work *very fast* on the regular expression department. Currently, it seems Perl is doing very well. I hope there are challengers though :)
I don't think C++ is a horrible language, it just have it's those nuances that take getting used to. But the same could be said of C as well. And also for Java and also for Perl and so on and so forth.
So instead of arguing over the programming language preferences, why not dwell on which programming language fit the business case on hand isn't it ? That is, some programming language is just easier and better than others in solving certain specific business cases.
Sidenote: I am still waiting for some programming language that work *very fast* on the regular expression department. Currently, it seems Perl is doing very well. I hope there are challengers though :)
Let me note in defence of Linus that his statement is out of context. The fact that he is commenting on propositions like "why don't you use boost/stl?" implies that someone actually *did* suggest that to him. Considering the level on which Linus must work, I can speculate that, whoever offered C++ to him, was making at the very least a very uninformed suggestion.
His reaction is the same as my reaction would be if a kid comes around and asks: why don't you use Visual Basic for your project instead of C++? Of course, I am by no means expert in Visual Basic, and maybe Visual basic would not be a bad tool for my purpose. However, from conventional wisdom, I can speculate that C++ is much better; I will definitely bash at the person suggesting it, and along the way, I would bash at Visual Basic.
There is no doubt that Visual Basic is superior to C++ for certain tasks (think of producing triangular buttons in Windows) and immensely inferior for others (think for a starter of using Visual Basic on Ubuntu).
His reaction is the same as my reaction would be if a kid comes around and asks: why don't you use Visual Basic for your project instead of C++? Of course, I am by no means expert in Visual Basic, and maybe Visual basic would not be a bad tool for my purpose. However, from conventional wisdom, I can speculate that C++ is much better; I will definitely bash at the person suggesting it, and along the way, I would bash at Visual Basic.
There is no doubt that Visual Basic is superior to C++ for certain tasks (think of producing triangular buttons in Windows) and immensely inferior for others (think for a starter of using Visual Basic on Ubuntu).
Last edited on
Sure, but he reacts like this every time C++ is mentioned when he's around, regardless of who says it or in what context. Like that time someone asked if Linux headers could be made C++-friendly to make writing C++ kernel modules easier (Google "torvalds c++ linux kernel modules" and I'm sure you'll find the thread). Whether one language is actually more appropriate or not doesn't appear factor in much.
| However, from conventional wisdom, I can speculate that C++ is much better; I will definitely bash at the person suggesting it, and along the way, I would bash at Visual Basic. |
Sometimes it never hurts to try out suggestion ppl propose. At least you have hands-on experience instead of just hearing it from ppl. Only with hands-on can you truly gauge for yourself if the proposer suggestion is good or not. It could be wrong entirely but I wouldn't want to discount any possibility of some programming languages out there that is easier and faster to solve certain specific set of problems.
To be honest, I think he has a point [in his line of work]. All the abstracted/standardized/templated design is easy, but it doesn't do well for efficiency. If you're an experienced programmer, you might be better off making your own purpose-specific versions of any method/class found in the STL, if speed is an issue. I'm a very unexperienced programmer, but the more I learn, the more I turn to C methods and away from the STL stuff I used to use everywhere. Even my crudely made container classes generally outperform the STL versions.
With that ease-of-use comes the risk of creating bad habits. The biggest issue with premade C++ stuff I have is that you often have no idea what's happening behind the screens, making it very difficult to predict what effect on efficiency your ideas will have. Not that long ago, I believed that STL vectors were "improved arrays". One reason was that I believed vector copying was in constant time, because I could simply call the copy() command, rather than having to loop over an array.
For a beginner, it's very difficult to judge the computational complexity of your program when most of the heavy stuff is happening in the files you've included rather than in the code you wrote. That, in turn, creates bad programmers (or at least programmers with bad habits).
With that ease-of-use comes the risk of creating bad habits. The biggest issue with premade C++ stuff I have is that you often have no idea what's happening behind the screens, making it very difficult to predict what effect on efficiency your ideas will have. Not that long ago, I believed that STL vectors were "improved arrays". One reason was that I believed vector copying was in constant time, because I could simply call the copy() command, rather than having to loop over an array.
For a beginner, it's very difficult to judge the computational complexity of your program when most of the heavy stuff is happening in the files you've included rather than in the code you wrote. That, in turn, creates bad programmers (or at least programmers with bad habits).
Anything that one does not understand can be hard to use correctly/efficiently/etc.. The STL can be remarkably efficient and carries a number of other benefits, as well. It's foolish to write it off unless you have identified it as a bottleneck via profiling and can provide data that shows a home-grown solution out-performing it.
That's the problem with criticizing other languages--it's something that a beginner does. Rather than learning how to use the language effectively, they complain and go back to what they do know. No matter how common this may be, it doesn't prove any language is bad.
Now, in my professional career, the life-long C programmers are no different. There is a reluctance to change that often out weighs everything else.
That's the problem with criticizing other languages--it's something that a beginner does. Rather than learning how to use the language effectively, they complain and go back to what they do know. No matter how common this may be, it doesn't prove any language is bad.
Now, in my professional career, the life-long C programmers are no different. There is a reluctance to change that often out weighs everything else.
Of course. I realize every language has a reason to exist and that there is no one language that outperforms all others in every task. In my spare time, I do the Euler challenges (http://projecteuler.net/) and when you complete a task, you get access to the forum topic on that problem. It's a great way to gain insights into which tasks a language is designed for.
However, any and all premade code is dangerous for beginners as they don't know/understand what's actually happening when you use it. I find the STL vector the perfect example. A beginner will think it's the perfect container, as it supports anything you need (resizing, random access, erasing per index, etc). A few weeks later he'll discover the costs of the vector's functionality and he'll have a hard time switching back to arrays.
Once I started learning about efficient programming techniques, it wasn't long before I realized that most of my overhead was caused by vector functionality rather than actual algorithm logic.
However, any and all premade code is dangerous for beginners as they don't know/understand what's actually happening when you use it. I find the STL vector the perfect example. A beginner will think it's the perfect container, as it supports anything you need (resizing, random access, erasing per index, etc). A few weeks later he'll discover the costs of the vector's functionality and he'll have a hard time switching back to arrays.
Once I started learning about efficient programming techniques, it wasn't long before I realized that most of my overhead was caused by vector functionality rather than actual algorithm logic.
closed account (1yR4jE8b)
Resizing a vector shouldn't be taking much longer then creating a new dynamically allocated array, copying all elements over, and deleting the old one -- this is pretty much what happens internally in an STL vector anyway.
Arrays and vectors are very similar and useful for practically all of the same situations, vectors and lists on the other hand are completely different.
Arrays and vectors are very similar and useful for practically all of the same situations, vectors and lists on the other hand are completely different.
That's the entire point: resizing a vector is a very costly operation, but there the user doesn't know that unless he actually thinks about it (or checks the code). Once you know, you start thinking of ways to reduce the need for resizing.
There is usually little to zero overhead when using a vector (except a small overhead when you're filling a vector of builtin types such as int). You were probably working in debug mode.
No more costly than reallocating and copying a dynamic array.
Yes, that's the key. However, avoiding vector certainly isn't.
Uh huh. This is explained in pretty much any C++ book or reference that covers vectors. Like here:
http://www.cplusplus.com/reference/stl/vector/
And when you learn even more, you'll turn back to the STL.
It is true that you can sometimes construct a custom container that outperforms any STL container in specific cases (when you know the expected usage pattern and/or have knowledge about characteristics of the contained type that you can exploit). However, cases where this makes a relevant difference are rare.
| That's the entire point: resizing a vector is a very costly operation |
No more costly than reallocating and copying a dynamic array.
| Once you know, you start thinking of ways to reduce the need for resizing. |
Yes, that's the key. However, avoiding vector certainly isn't.
| but there the user doesn't know that unless he actually thinks about it (or checks the code). |
Uh huh. This is explained in pretty much any C++ book or reference that covers vectors. Like here:
http://www.cplusplus.com/reference/stl/vector/
| but the more I learn, the more I turn to C methods and away from the STL stuff I used to use everywhere. |
And when you learn even more, you'll turn back to the STL.
It is true that you can sometimes construct a custom container that outperforms any STL container in specific cases (when you know the expected usage pattern and/or have knowledge about characteristics of the contained type that you can exploit). However, cases where this makes a relevant difference are rare.
Last edited on
It would be nice, though, if there were more STL containers that were optimized for different purposes, just to give programmers that option without having to write it themselves or resort to external libraries. At least, I would greatly appreciate it. Take std::map, for example. It's a very generic multipurpose map, but it's generally more space-efficient when the keys or values are large. What if I want a map that excels at handling small keys?
-Albatross
-Albatross
Last edited on
| Once I started learning about efficient programming techniques, it wasn't long before I realized that most of my overhead was caused by vector functionality rather than actual algorithm logic. |
I'm saying that much of the overhead would have been caused by user ignorance (no offense).
| That's the entire point: resizing a vector is a very costly operation, but there the user doesn't know that unless he actually thinks about it (or checks the code). Once you know, you start thinking of ways to reduce the need for resizing. ico |
Appending an element to a vector is amortized constant time. It is a very fast operation as the number of elements increases.
Last edited on
The current posts seem to dwell on the technical aspects of the language but if you are looking at it from a business case point of view, would you want to spend time crafting super-efficient data structures which is still far from delivering the output business users want ?
Business case should drive the language and not the other way round. Look at those B2B online websites back-end systems, depending on the requirements, they are jolly well written in Java,Perl,PHP and for some rare cases C/C++.
Programming languages evolve to help us developers meet the business case challenge. C -> C++ was an evolution but still not fast enough (in terms of time-line for apps ready for business user to use) and hence Java is born. To business users, time to market is extremely important and if their requirements do not need that stringent, Java applications can be produced much faster than using C++ or worst C where you build all your data structures and algorithms.
C/C++ would be more ideal when performance is paramount and most likely back-end non-GUI kind of applications. And also for those desktop games applications I guess.
Business case should drive the language and not the other way round. Look at those B2B online websites back-end systems, depending on the requirements, they are jolly well written in Java,Perl,PHP and for some rare cases C/C++.
Programming languages evolve to help us developers meet the business case challenge. C -> C++ was an evolution but still not fast enough (in terms of time-line for apps ready for business user to use) and hence Java is born. To business users, time to market is extremely important and if their requirements do not need that stringent, Java applications can be produced much faster than using C++ or worst C where you build all your data structures and algorithms.
C/C++ would be more ideal when performance is paramount and most likely back-end non-GUI kind of applications. And also for those desktop games applications I guess.
@Athar & moorecm:
You're missing my point. I know the overhead was because of my ignorance, not because of the way vectors work. My point was: I (and many others) fail to use vectors efficiently, because we don't know how they work.
I (and many others) didn't get a proper introduction to data classes. We google "how do I change the size of an array?" and get "use vectors, noob" as response. The code in the vector class is pretty dense and scary at first, so we'll just use it as a black box magical solution.
Recent example: http://www.cplusplus.com/forum/beginner/54668/
@moorecm: Insertion isn't efficient, regardless of how often you do it. push is, but insertion isn't.
You're missing my point. I know the overhead was because of my ignorance, not because of the way vectors work. My point was: I (and many others) fail to use vectors efficiently, because we don't know how they work.
I (and many others) didn't get a proper introduction to data classes. We google "how do I change the size of an array?" and get "use vectors, noob" as response. The code in the vector class is pretty dense and scary at first, so we'll just use it as a black box magical solution.
Recent example: http://www.cplusplus.com/forum/beginner/54668/
@moorecm: Insertion isn't efficient, regardless of how often you do it. push is, but insertion isn't.
| I (and many others) fail to use vectors efficiently, because we don't know how they work. |
| I (and many others) didn't get a proper introduction to data classes. |
closed account (1vRz3TCk)
| helios wrote: |
|---|
| Otherwise you're not writing C++, you're making a mess with a computer. |
-=#Quietly Laughing#=-
C doesn't really include any algorithms or data structures in its standard library other than qsort().
Last edited on