I maintain statistics on all my books, including C++ All-In-One for Dummies, 3rd Edition. These statistics are based on reader e-mail and other sources of input that I get. I even take the comments on Amazon.com into account. One of the most common C++ questions I get (not the most common, but it’s up there) is why someone would want to use the language in the first place. It’s true, C++ isn’t the language to use if you’re creating a database application. However, it is the language to use if you’re writing low-level code that has to run fast. C++ also sees use in a vast number of libraries because library code has to be fast. For example, check out the Python libraries at some point and you’ll find C++ staring back at you. In fact, part of the Python documentation discusses how to use C++ to create extensions.
I decided to look through some of my past notes to see if there was some succinct discussion of just why C++ is a useful language for the average developer to know. That’s when I ran across an InfoWorld article entitled, “Stroustrup: Why the 35-year-old C++ still dominates ‘real’ dev.” Given that the guy being interviewed is Bjarne Stroustrup, the inventor of C++, it’s a great source of information. The interview is revealing because it’s obvious that Bjarne is taking a measured view of C++ and not simply telling everyone to use it for every occasion (quite the contrary, in fact).
The bottom line in C++ development is speed. Along with speed, you also get flexibility and great access to the hardware. As with anything, you pay a price for getting these features. In the case of C++, you’ll experience increased development time, greater complexity, and more difficulty in locating bugs. Some people are taking a new route to C++ speed though and that’s to write their code in one language and move it to C++ from there. For example, some Python developers are now cross-compiling their code into C++ to gain a speed advantage. You can read about it in the InfoWorld article entitled, “Python-to-C++ compiler promises speedier execution.”
A lot of readers will close a message to me asking whether there is a single language they can learn to do everything well. Unfortunately, there isn’t any such language and given the nature of computer languages, I doubt there ever will be. Every language has a niche for which it’s indispensable. The smart developer has a toolbox full of languages suited for every job the developer intends to tackle.
Do you find that you really don’t understand how the languages in my books can help you? Let me know your book-specific language questions at John@JohnMuellerBooks.com. It’s always my goal that you understand how the material you’ve learned while reading one of my books will eventually help you in the long run. After all, what’s the point of reading a book that doesn’t help you in some material way? Thanks, as always, for your staunch support of my writing efforts!
It can be difficult to choose just the right kind of source code examples to include in my books. In fact, readers often write to ask why I didn’t choose a different kind of example for a book. For example, a lot of readers tend to prefer console applications because they’re:
- Easy to understand
- Easy to write
- Demonstrate the code clearly
- Don’t rely on any automation
Given these reasons, it would seem as if I’d use console applications for all of my examples in all of my books. In fact, these benefits (and others) are the reason I used console applications in C++ All-In-One Desk Reference For Dummies. In fact, to this list, you can add the benefit of the same example code running on multiple platforms to the list. The same example code runs on Mac, Linux, and Windows platforms with the GCC compiler. Even with this book, however, I’ve had readers write to ask why I didn’t use a different compiler or IDE and why I didn’t include examples that demonstrate the ability to use C++ to create user interfaces in anything but Visual Studio (the new edition of the book won’t include the Visual Studio examples).
Some books don’t lend themselves to console applications. For example, one of the purposes of Microsoft ADO.NET Entity Framework Step by Step is to show how you can use the automation provided by Visual Studio to write your applications with less code and in significantly less time. Not everyone likes the automation and I’ve actually had a few readers ask why I couldn’t write the examples using a console application format. The problem is that few people use the Entity Framework with console applications and the automation is there to simplify things. I understand that other books may provide console application examples, but I chose to provide the examples in a form that the majority of my readers would use in a real world setting.
Trying to come up with a book that pleases everyone is simply impossible because everyone has different needs. It all comes down to people wanting the best deal possible in a book, which means seeing an example that uses their environment on their platform and demonstrating precisely the kind of code they need to write. It’s an unrealistic expectation for any book. My Getting the Most from Your Technical Reading Experience post explains how you can optimize the purchasing experience to obtain the best book for your needs. The caveat is that no matter how good the purchase is, the book will never answer all of your questions and most definitely won’t answer them in precisely the way you need them answered for fulfill an application development requirement.
Of course, I’m always open to your input. It’s the reason I run this blog and ask for your input in nearly every post. My purpose in writing is to answer as many questions as I can for as many readers as I can in the best way possible. Sometimes that means I need to take a step back and rethink a particular process I’m using, technique I’m applying, or perspective I’m pursuing. I encourage you to continue contacting me at John@JohnMuellerBooks.com with your book-related queries. I always use your input to help create better books in the future.
Many readers have asked over the years why I spent time learning the computer languages that I have. Some languages were learned as part of the requirement for getting my computer science degree and a few were learned as part of getting a job. However, most languages were learned as a means to communicate better with the computer. A computer speaks only one language—machine code, which is nearly impossible for humans to learn. My first coding experiences started with machine code and then progressed to languages such as Macro Assembler (MASM). As technology has improved and my needs have changed, I’ve learned other languages, which is why I wrote “6 Ways to Determine a New Programming Language is a Turkey.”
Some of the languages I’ve learned over the years really were turkeys. The language is probably acceptable, but I didn’t get anything for my efforts. The language wasn’t right for me—it didn’t help me to communicate better with the computer. You’ll likely find that you experience the same problem if you spend enough time writing code. The more time you spend writing applications, the more languages you eventually learn.
I rarely get into arguments with other people who feel the language they like best is superior to all others. I realized a long time ago that the language really is superior from their perspective. If I were in their precise situation and writing exactly the same kinds of application they’re writing, I’d probably come to the same conclusion. That’s why the choice of language is both personal and imprecise. My article helps you make an informed choice based on the criteria that I use most often to select a new language. An informed choice will reduce the mistakes you make when selecting a language.
The point at which some developers make a mistake is in thinking that the computer pays any attention at all to the language they choose. The computer couldn’t care less. All the computer knows is machine code. The language you choose is for your benefit, not the computer’s benefit. The moment you start thinking that a language does anything at all for the computer, the chances of choosing a turkey increase greatly.
There are some mechanics of computer languages that you do need to consider. For example, you need to know that the language you choose will translate into machine code your computer understands. You also need to know that the more comfortable you make things for yourself, the less efficient the code becomes. That’s not really a problem in today’s environment of high-powered computers, but that reality did affect my decisions early in my career. At the time, MASM provided the most efficient means possible to communicate with a computer without resorting to machine code. Even so, MASM was difficult to work with and I welcomed the introduction of C as a means of making things easier on myself.
Of course, this all leads into the question of which language you feel works best for your needs today. Some developers know just one language well—others, like myself, have an entire toolbox full of languages to use to meet specific needs. Where do you fall into the list? As I continue to write books, I’d like to hear about languages and techniques for using those languages that interest you most. Let me know your thoughts on computer languages at John@JohnMuellerBooks.com.