D vs C++11

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Nov 3 12:36:47 PDT 2012


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


More information about the Digitalmars-d mailing list