On Sat, Nov 03, 2012 at 08:19:15AM +0100, Paulo Pinto wrote: [...] > Languages get adopted because of business value, not due to the > coolness of their feature set, how boring it may sell. > > If we want to sell D to companies using C++ for years, slowly > migrating to JVM, .NET worlds, or just updating their codebases to > C++11, then we need to sell D's business value not feature lists. [...]
I understand that business types ultimately don't care for feature lists, etc., but the thing about D isn't so much the features themselves, but rather how those features save development costs. For example, I've been working on this particular project in my day job for a while now, and I see almost every day how the lack of a certain feature in C++ or C (or the bad design/implementation of said feature) is costing lots and lots of duplicated or plain wasted development time. Lots of code is copy-n-pasted, or otherwise duplicated, because of the lack of reusable constructs. A certain database subsystem was designed with a particular use in mind, with structs that may contain some nested lists, etc.. Recently they wanted to introduce a JSON-based interface for it. It ended up requiring a lot of duplicated logic, simply because the lack of destructors in C required special-casing a lot of code just to clean things up properly. If this had been done in D, first of all, there wouldn't even need to be an elaborate subsystem for mapping structs to SQL: we'd just write a template-based wrapper that used compile-time introspection to automate most of the code. That, or used AA's and alias this or opDispatch to simulate the structs, which can be done in a day or two's work as opposed to 2 months. Then for the JSON-based interface, the GC would just take care of any garbage that gets generated, so no special casing would be needed. This alone would have saved hundreds of hours of development work, not to mention alleviated many subtle pointer bugs and other problems that we've had to fix over the years, which probably adds up to another hundreds of hours. So much time is wasted in working around C/C++ deficiencies and cleaning up the resulting mess, that I think that alone would have justified using D instead. I mean, we're talking about hundreds of development hours that could've been invested in actual *development* rather than mere maintenance and cleanup. Hundreds of employee hours, which come with the cost of employee benefits, associated costs, etc.. About the only good thing with the current situation is that we'll never be out of a job, because there is no end to the mess that comes from C/C++. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
