www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Where will D be in 2015 in the programming language ecosphere?

reply Justin Johansson <no spam.com> writes:
Me thinks this both a polite question and a question due of realistic 
answers.

How doth thou respond?
Jun 19 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:

 Me thinks this both a polite question and a question due of realistic 
 answers.
 
 How doth thou respond?


It will be the dominant programming language of choice.
Jun 19 2010
next sibling parent "Mike James" <foo bar.com> writes:
I detect a hint of bias ;-)

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hviuvj$1476$1 digitalmars.com...

 Justin Johansson wrote:

 Me thinks this both a polite question and a question due of realistic 
 answers.

 How doth thou respond?


 It will be the dominant programming language of choice.
Jun 19 2010
prev sibling parent Justin Johansson <no spam.com> writes:
Walter Bright wrote:

 Justin Johansson wrote:

 Me thinks this both a polite question and a question due of realistic 
 answers.

 How doth thou respond?


 
 It will be the dominant programming language of choice.


Wow, thanks, that's a real affirmative answer :-)

Is it likely that it will be D2 (with bugs sorted out) or have moved on 
to say a D3?  In other words, is D2 more-or-less around where people can 
  expect the language to stabilize?
Jun 19 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Justin Johansson (no spam.com)'s article

 Me thinks this both a polite question and a question due of realistic
 answers.
 How doth thou respond?


My brutally honest but not overly pessimistic view is that D will become fairly
popular in "high-level" systems programming and scientific and game programming,
but will fail to make substantial inroads into "low-level" systems programming
or
most application programming.

I define high-level systems programming as anything that's not an application
but
isn't a kernel, device driver or severely resource-limited embedded system. 
This
can include GUI toolkits, database systems, network infrastructure code,
libraries, etc.  For the lower-level systems programming case, the requirement
for
a runtime (even if it's a fairly lightweight one) and the lack of fine control
over things like binary size (due to templates, etc.) will limit usefulness. 
Yes,
these problems can be worked around, but doing so requires sticking to so much
of
a C-like subset that you may as well just use C.

At the application level, there are simply too many "good enough" languages that


On the other hand, there's really no **good** language to do high level systems
programming or performance-critical application programming in.  C++ is just too

but
they don't allow direct access to hardware and system-native APIs.  They also
don't allow you to resort to the kinds of dirty tricks that you could in D to
squeeze that last bit of performance out of your code.  For example, good luck
writing an inner loop in assembler (it's done in Phobos), writing a custom
memory
allocator (I've done this, to good effect), or reinterpreting floating point
numbers as integers and then bit twiddling them to sort them faster using
integer
instructions (I've actually done this, too, and it gave me a ~20% speedup in
some
code).
Jun 19 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:hvjno9$2oq3$1 digitalmars.com...

 == Quote from Justin Johansson (no spam.com)'s article

 Me thinks this both a polite question and a question due of realistic
 answers.
 How doth thou respond?


 My brutally honest but not overly pessimistic view is that D will become 
 fairly
 popular in "high-level" systems programming and scientific and game 
 programming,
 but will fail to make substantial inroads into "low-level" systems 
 programming or
 most application programming.


I think that sounds like a fairly reasonable analysis.


 For the lower-level systems programming case, the requirement for
 a runtime (even if it's a fairly lightweight one) and the lack of fine 
 control
 over things like binary size (due to templates, etc.) will limit 
 usefulness.  Yes,
 these problems can be worked around, but doing so requires sticking to so 
 much of
 a C-like subset that you may as well just use C.


(Way) Back when I was a C/C++ programmer, I found D's module system alone to 
be worth abandoning C/C++. Everything else was icing on the cake. And there 
are other things that would also be an improvement for these developers: 
better alternatives to preprocessor macros, underscores in numeric literals, 
improved const/immutable system. So, while I agree that many of them would 
need to use a limited C-ish subset of D, I do think it would still be 
worthwhile for many of them to switch. But of course, as for how many of 
them will actually agree, I'm not sure.

Also, I predict Bjarne Stroustrup will become even more absurdly defensive 
of C++'s anachronisms and cruft than he already seems to be ;)
Jun 19 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Also, I predict Bjarne Stroustrup will become even more absurdly defensive 
 of C++'s anachronisms and cruft than he already seems to be ;)


I think you're selling Bjarne short. He's well aware of the issues with C++ and 
from what I know he's been remarkably even handed about them.
Jun 19 2010
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hvk1vp$cdr$1 digitalmars.com...

 Nick Sabalausky wrote:

 Also, I predict Bjarne Stroustrup will become even more absurdly 
 defensive of C++'s anachronisms and cruft than he already seems to be ;)


 I think you're selling Bjarne short. He's well aware of the issues with 
 C++ and from what I know he's been remarkably even handed about them.


Hmm, I had been hearing some things that seemed to indicate the contrary. 
But I guess I wouldn't really know either way.
Jun 19 2010
prev sibling parent reply BCS <none anon.com> writes:
Hello dsimcha,


 For
 the lower-level systems programming case, the requirement for a
 runtime (even if it's a fairly lightweight one) and the lack of fine
 control over things like binary size (due to templates, etc.) will
 limit usefulness.  Yes, these problems can be worked around, but doing
 so requires sticking to so much of a C-like subset that you may as
 well just use C.


Maybe someone should make a DMD-EE ("embedded edition") with a truly minimal 
runtime and library along with a compiler patched to support it (e.g. no 
GC, no AA's, no hidden memory allocations, no new/delete, D-ified versions 
of the c std lib). The DMD patch shouldn't be to hard, the runtime would 
mostly amount to dropping stuff and the lib would mostly just copy some stuff 
from phobos and wrapping, porting or binding (depending on what's more
reasonable) 
stuff from C.

I'd offer to do it but I have almost no experience in any of those.


-- 
... <IXOYE><
Jun 19 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Hello dsimcha,
 

 For
 the lower-level systems programming case, the requirement for a
 runtime (even if it's a fairly lightweight one) and the lack of fine
 control over things like binary size (due to templates, etc.) will
 limit usefulness.  Yes, these problems can be worked around, but doing
 so requires sticking to so much of a C-like subset that you may as
 well just use C.


 
 Maybe someone should make a DMD-EE ("embedded edition") with a truly 
 minimal runtime and library along with a compiler patched to support it 
 (e.g. no GC, no AA's, no hidden memory allocations, no new/delete, 
 D-ified versions of the c std lib). The DMD patch shouldn't be to hard, 
 the runtime would mostly amount to dropping stuff and the lib would 
 mostly just copy some stuff from phobos and wrapping, porting or binding 
 (depending on what's more reasonable) stuff from C.
 
 I'd offer to do it but I have almost no experience in any of those.



There's not a whole lot of point to do this, other than checking a box, because 
embedded systems developers have no problem doing this themselves (create a 
custom runtime library).
Jun 20 2010
parent reply BCS <none anon.com> writes:
Hello Walter,


 BCS wrote:
 

 Hello dsimcha,
 

 For
 the lower-level systems programming case, the requirement for a
 runtime (even if it's a fairly lightweight one) and the lack of fine
 control over things like binary size (due to templates, etc.) will
 limit usefulness.  Yes, these problems can be worked around, but
 doing
 so requires sticking to so much of a C-like subset that you may as
 well just use C.


 Maybe someone should make a DMD-EE ("embedded edition") with a truly
 minimal runtime and library along with a compiler patched to support
 it (e.g. no GC, no AA's, no hidden memory allocations, no new/delete,
 D-ified versions of the c std lib). The DMD patch shouldn't be to
 hard, the runtime would mostly amount to dropping stuff and the lib
 would mostly just copy some stuff from phobos and wrapping, porting
 or binding (depending on what's more reasonable) stuff from C.
 
 I'd offer to do it but I have almost no experience in any of those.
 


 There's not a whole lot of point to do this, other than checking a
 box, because embedded systems developers have no problem doing this
 themselves (create a custom runtime library).
 


It would lower the barrier to entry. While not to important once someone 
has chosen D, I would think it would be much more important when they are 
just considering it.

-- 
... <IXOYE><
Jun 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff154f88ccde5b99a63396 news.digitalmars.com...

 Hello Walter,


 BCS wrote:


 Maybe someone should make a DMD-EE ("embedded edition") with a truly
 minimal runtime and library along with a compiler patched to support
 it (e.g. no GC, no AA's, no hidden memory allocations, no new/delete,
 D-ified versions of the c std lib). The DMD patch shouldn't be to
 hard, the runtime would mostly amount to dropping stuff and the lib
 would mostly just copy some stuff from phobos and wrapping, porting
 or binding (depending on what's more reasonable) stuff from C.

 I'd offer to do it but I have almost no experience in any of those.


 There's not a whole lot of point to do this, other than checking a
 box, because embedded systems developers have no problem doing this
 themselves (create a custom runtime library).


 It would lower the barrier to entry. While not to important once someone 
 has chosen D, I would think it would be much more important when they are 
 just considering it.


Exactly. D is enormously better than C for many such things, but C/C++ have 
so much inertia in all the fields C/C++ are used that regardless of how much 
better D is, barrier to entry and overcoming C/C++'s inertia is still going 
to be a significant issue for D. We want it to be as easy as possible for 
potential D users in any field appropriate for D to try it out. Then they 
can customize it further if they really need to, but the real issue is 
getting them to decide to use it in the first place, and I'd be very 
surprised if a lot of them would be willing to do *all* of the necessary 
adjustments merely to test drive it. Plus, there's embedded homebrew too, 
and the homebrewers aren't likely to have a lot of time to do the necessary 
adjustments.
Jun 20 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 Then they 
 can customize it further if they really need to, but the real issue is 
 getting them to decide to use it in the first place, and I'd be very 
 surprised if a lot of them would be willing to do *all* of the necessary 
 adjustments merely to test drive it.


A Dlite (please, not named D--) can be fun :-)

Bye,
bearophile
Jun 20 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hvif8o$i2$1 digitalmars.com...

 Me thinks this both a polite question and a question due of realistic 
 answers.

 How doth thou respond?


More or less what dsimcha said, but with the additional footnote that 
continued improvements to the D scene combined with "C++: 'Duke Nukem 
Forever' Edition" (erm, I mean "C++0x"...uh wait, 
no..."C++1x"...allegedly...hmm, no I think I was right the first time...) 
will finally start creating a fair amount of disgruntled C++-defectors who 
will land on the shores of D. Many of them will be people who had been 
"keeping an eye on D" for a number of years.
Jun 19 2010
prev sibling parent "Rory McGuire" <rmcguire neonova.co.za> writes:
On Sat, 19 Jun 2010 15:04:21 +0200, Justin Johansson <no spam.com> wrote:


 Me thinks this both a polite question and a question due of realistic  
 answers.

 How doth thou respond?



Not sure, but what I do think is:

If D ran on ARM it would be a favorite for mobile devices, often programs  

People then have to port to C/C++ to get their app running smoothly again.

Javascript programmers could very likely pick up D as their compiled  
language of choice because it allows them to program
in a similar way (closures, maps, delegates).

PHP programmers could also pick up D, again because it allows them to  
program in a similar way (mixing functional and OOP, maps, strings, ...).

Both javascript and PHP developers are abundant, which is partly why  
Facebook use PHP so much.
Jun 21 2010