When I was selecting a language for my product Segito, I considered most languages I knew and finally settled on C++ for a variety of reasons. The languages I considered were C++, Java, C# and Python, while others like Ruby and PHP were not in the running.
The reasons for choosing C++ are listed below, in no particular order:
With statically typed languages, these errors get caught at compile time. No doubt, good software engineering is the sum-total of many different best practices, but this is one class of error that can very easily be eliminated by letting the compiler do the work.
One common counter to this is that such errors can be caught by writing good unit tests, but in my opinion, that's a self defeating argument. If you are going to save time using Python and spend it writing unit tests, you have achieved nothing.
The advantage is that C++ training is not a viable mass-market business for software training institutes so although the number of resumes processed will be low, the hiring-to-interview ratio will be much higher.
I like to compare C++ with the English language: both have their own warts, both have more exceptions than rules, both can be extremely frustrating to learn and people complain about both endlessly. But if your business depends on a community and you need a common language that everyone understands, it is the only option available to you. No matter how perfect your native language may be.
The reasons for choosing C++ are listed below, in no particular order:
Cross platform support
The biggest issue I had with the non C++ languages was support and availability of the dependencies. For each of those languages, there was at least one platform that did not support it, or had only sketchy support.- The JRE is not available on iOS (there are plans to support it by Sun/Oracle) and Symbian
- .NET is not available on Android, although there is a recent commercial Mono 3rd party port.
- Python for iOS is available only as a 3rd party port.
Size/Speed
The second biggest advantage C++ has over the rest is size, including dependencies. The current win32 release of Segito is about 1.5 Mb (800Kb installer) while the OSX .app package is about 2.5Mb.
For everything else, while the size of the executable would have been small, the runtime environment would have been significantly larger.
- The latest JRE for Windows is about 15Mb
- The .NET 4 runtime for Windows is about 24Mb
- The Mono runtime for OSX is 84Mb
C++ allows us to write bare metal apps that contain nothing more than what is needed.
IDE
Almost all target platforms have free, native OEM supported IDE's for C++, while the rest have at best, third-party support.
- Windows has Visual Studio Express Edition which is extremely fast and lightweight. The 2008 edition running in a Windows VM on OSX starts up in less than 1 second and a full rebuild of the whole app takes less than 30 seconds.
- OSX and iOS has Xcode, although it is a bit of an acquired taste for someone from a Windows/Linux background.
- Linux has KDevelop and QtCreator, which although third-party, are both excellent IDE's in their own right.
A big disadvantage here, however, is the need to maintain multiple projects but that is outweighed by the rest of the advantages.
Static typing
While static typing in programming languages may not seem like a significant factor, very often the business importance is missed. Dynamically typed languages are very useful to churn out applications quickly - one can use Python to write an application much faster than using C++.
But what happens when the start-up gets funded and goes to the next level? When the initial founder-developers are replaced by a team of 20 new developers, the new team does not have the familiarity with the code base like the original developers did. This is when the bug count start increasing. For example, it becomes easy to call functions with parameters of incorrect type and this will result in subtle bugs that will never get discovered until they bomb at run time. If you are lucky, they will get caught in the QA phase, and if not, your customer will find it, resulting in loss of productivity and goodwill.
As the team size grows and/or there is a churn in the team, such bugs in the code will increase exponentially.
As the team size grows and/or there is a churn in the team, such bugs in the code will increase exponentially.
With statically typed languages, these errors get caught at compile time. No doubt, good software engineering is the sum-total of many different best practices, but this is one class of error that can very easily be eliminated by letting the compiler do the work.
One common counter to this is that such errors can be caught by writing good unit tests, but in my opinion, that's a self defeating argument. If you are going to save time using Python and spend it writing unit tests, you have achieved nothing.
Skill-set availability
This is an advantage and a disadvantage at the same time, more of the latter. Most educational institutes teach C++, but most organizations use anything but C++. So the probability of finding good and experienced C++ programmers is quite low, but c'est la vie!The advantage is that C++ training is not a viable mass-market business for software training institutes so although the number of resumes processed will be low, the hiring-to-interview ratio will be much higher.
Summary
That said, I am not a hardcore all-or-nothing C++ fanatic. The above was my thought-process for selecting a language for a product that is expected to run on a wide variety of desktop and mobile platforms. The enterprise server component of Segito is written in C# and there will almost certainly be a Java version in the near future.I like to compare C++ with the English language: both have their own warts, both have more exceptions than rules, both can be extremely frustrating to learn and people complain about both endlessly. But if your business depends on a community and you need a common language that everyone understands, it is the only option available to you. No matter how perfect your native language may be.
8 comments:
This is great, Renji. I have a question, though: despite C++ cross-platform availability, how do you deal with its small library coverage? There's no common GUI in C++. Accessing OS-level resources beyond memory and the file system (e.g., fire up notifications in iOS, Android and Windows Phone 7) is not covered by standard libraries either. What do you do in those cases? I ask because in my case is a pain: I have to maintain versions for the different OS for those functionalities. There's no much left for pure C++ other than pure application logic. In small applications it may be more costly going C++ plus ad hoc extensions than just keeping separated versions. Not sure if you agree.
I think you made a good choice, however, some of the reasoning is questionable.
Schools tend to teach Java, not C++. (Even if the majority did teach C++, I don't think I'd rely on that for my project.)
Platform support is a slippery slope argument. Most platforms support mainstream languages in some form or another. C++ is a good choice because it is a rich language, and produces codes which set the standard for performance.
OS/UI specifics are not exposed in C#/Java either. So not only you would have to have per-OS code in your project, you'd have to dance around VM/native barrier as well. Just sayin'.
While I agree that C++ is a good choice for all the reasons you listed, I haven't seen anywhere that you can use C++ on Windows Phone 7. There's rumors that WP8 will enable it, but it's not confirmed.
first off:
Java was based on C++ and objective C
C# was based on Java 2.0
And python was based on C++/C/Perl if i'm not mistaking
so basically you will have the most possibilities / freedom with C++, but then again this makes it harder to do something because of those possibilities.
C++ is a good chose for programming any project, but it takes a lot of skills/knowledge to do it. if it is the best option, you never know sometimes you don't need the freedom.
Have you considered using CMake to get rid of the IDE specific project structures? It works great with KDevelop and Visual Studio. Don't know about XCode, but at least you can use it to create osx makefiles. It also works for native android apps.
Good Summary.
Good thinking although not exactly true in the detail.
C++ has its own runtime library that is lighter, heavier, single version per OS or compiler related.. all depends on the platform. Eg. there is a reason why in Windows you may find VCRT from VS 2005, 2008 and 2010 installed in parallel to each other.
As Diego mentioned, you get language that is very portable, yet each platform has its own frameworks beyond standard library. To wrap them all into a common pattern of framework that gives you the benefit of shared code is difficult and often challenging. Scope of the project can simply push you into having 3 projects for 3 platforms just because of that...
Tools are generally good but Android + NDK = Pain in the ass, honestly... ;)
There is no best platform/language... folks from Java/C# can counter your opinions freely if they really wanted to in many aspects where C++ is difficult but there is no point in that..
I personally like to leave the freedom of choice but C++ has won in my mind when I wanted full control over my code, bigger chance (but sometimes illusional) for portability and performance (but that strongly depends on frameworks rather than individual coding skill)
Post a Comment