www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Advocacy (Was: Who here actually uses D?)

reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/2 Robert Clipsham <robert octarineparrot.com>:

 Unfortunately, it's impossible to create such a system without people being
 paid to work on dmd and the runtime - people will fix the bugs they want to,
 you can't make them fix anything. Obviously you can influence what gets
 fixed, not to a huge extent though. Ideally the voting system would outline
 what needs the most effort, but people don't idle on bugzilla enough for it
 to work so well. I wonder if changing the 'vote' button to a 'like' button
 would make any difference, if facebook's any indication, people like to like
 things ;p


Personally, I think the community is a key focus area. D cannot
survive without a thriving community, both in the "core projects"
(language design, compilers, stdlibs, druntime etc.), and in
applications (especially highly visible killer-apps). I think it's
absolutely critical to work on advocating the language, especially I
feel D is currently missing "killer-apps" demonstrating why learning D
is worthwhile.

Let's be honest, coming into the market of C-style imperative
languages in the second half of this past decade isn't exactly easy.

the convenience-minded. The only complaint I ever hear in that
landscape, is that C/C++ is just too much hazzle to work with, and

so regarding RAM consumption.

Of course most users don't care, but the few passionate developers
feeling this, THEY are the audience D appeals to. I think it's
important to intentionally target them in advocacy. D cannot succeed
in doing everything. It certainly cannot compete with Ada on writing
secure stable code, and it cannot compete with C in low-level
programming simply due to the sheer established mass. The one area
where there is currently an unexploited opportunity is in the corner
between productive yet efficient, and this is where D shines, which
most developers currently do not know.

On a side-note (and I'm clearly biased here so I hardly even take
myself very seriously), I think the non-windows os:es, especially
Linux, should also be an intentional focus-area. It is VERY difficult
to compete with .NET on Windows, and somehow I don't think we'll find
most of the efficiency-focused audience there, but if D can
demonstrate it's usefulness in key systems components in Linux, it's
likely to attract more curious right-minded developers. I'm not sure
exactly how to realize this, but there may be two opportunities in
quickly providing a lightwheight attractive desktop environment for
the upcoming Wayland system, as well as someone finally writing a
disk-indexing system that doesn't eat all your disk-bandwidth and ram
during the first week.

In any case, I think it's also very important to remember developers
should only make up a small part of a good community, even a software
development community. We need webdesigners, advocates, testers,
people doing bugzilla maintenance, documentation experts, writers,
artists, and just about anyone who can spare a couple of hours of the
week since they want more efficient software (even if they don't know
how to do it themselves). Just discovering
http://d-programming-language.org/ with much nicer presentation of the
docs I've already seen, raised my motivation for D just as much as any
random dozen solved bugs from bugzilla.

Attracting people to D is IMHO MUCH more important than any particular
bug or especially new feature. If I got my wish, I would very much
like to see some of the core devs allocating 75% of their time of for
the next months on not doing core work, but ONLY doing things to
attract new developers; I.E.
 * Try to get D into the Debian Language Shootout Again?
 * A simple web-server beating apache performance (maybe even nginx?)
would be a reasonable goal, which would make great headlines, and in
short time.  If you can also show it's source-code is comprehensible
to any medium-skilled Java dev, you've probably got yourself many new
prospective developers.
 * Follow up new developers with top-notch support for the more
promising ones to make sure they don't bounce back out.
 * Brush up the documentation aimed at beginners, and try to get a few
articles and tutorials published (at least slashdotted)
Given these above, which to my knowledge isn't done as of now, I think
it's not unreasonable to expect a sizable growth in both active
community and external visibility.

Now, time for me to go to bed. (It's 06:00 here) when I wake up later
today, I'm hoping to have the list full of further ideas, suggestions
and thoughts on how to grow the community, except for implementing
D3/4/5 100% bugfree. :)
Jan 01 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 I'm afraid that's baloney, as I pointed out in the other thread.


What you have said was about application code. It's not true for kernel code,
where you need strict control on what, how, and if the compiler performs
certain optimizations.



 I think that is a serious misinterpretation of the complaint. The complaint
was 
 actually that the high level abstractions that one can choose to use in C++
can 
 be impenetrable in what they do. In D, if you want low level control, write
low 
 level code. It's that simple.


This is true for C++ too. But he doesn't want high level abstractions in kernel
code. So he has not much use for C++ and D too. But he wants more static
analysis.



 Typed assembler is a waste of effort in a language like D, as you only need a 
 few drops of assembler here and there.


This talk says:
http://www.linuxjournal.com/article/7272

The problem is that being the kernel has to do a lot of things that break
typechecking. Which you see more in the kernel than in a lot of other programs.
You end up having a lot of inline assembly which is obviously completely
opaque.<


In the Nucleus of the experimental operating system Verve I have seen a good
amount of assembly code. They are able to use so much assembly because it's not
normal assembly, it's typed its assertions are often verified statically. So
it's not completely opaque.

In the D runtime I have counted 2100 lines of asm just for the array operations
implementation, (that's unfinished still). asm code is uncommon in application
programs, but it's clearly more than few drops.



 Those languages are failures at what they propose to do; they need years and 
 perhaps decades to fulfill that.



http://research.microsoft.com/en-us/projects/contracts/

But this page says something interesting:
http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx


Code Contracts Premium Edition: This version installs only if you have one of
the following: Visual Studio 2008 Team System, Visual Studio 2010 Premium
Edition, or Visual Studio 2010 Ultimate Edition. It includes the static checker
in addition to all of the features in the Code Contracts Standard Edition.<


It means that if today you have better versions of Visual Studio, then you have
a static checker for contracts. I have not used them yet, I will try to try
them. As you see Microsoft is pushing some of its research in the Real World
today.

And regardless the usefulness of Verve today, they contain some quite
interesting ideas. I'm not just an engineer, I like ideas too. Shutting the
brain closed is stupid.

Bye,
bearophile
Jan 03 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
"Code Contracts Premium Edition"

That's just hillarious. What's next, will the customers be forced to
buy a dozen pointers in a bundle? If you try using more than 10
pointers in your app you'll get a pop-up saying you're can't do that
in the trial version, upgrade now!. LOL!
Jan 03 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
"Limited offer: Increase your stack size, for only 49.99$!"
Jan 03 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 03.01.2011 16:19, Andrej Mitrovic wrote:

 "Limited offer: Increase your stack size, for only 49.99$!"


LOL, BTW vendors should also like it:  reselling already sold hardware 
to developers  :)

-- 
Dmitry Olshansky
Jan 03 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 It means that if today you have better versions of Visual Studio, then you
 have a static checker for contracts. I have not used them yet, I will try to
 try them. As you see Microsoft is pushing some of its research in the Real
 World today.


And as I pointed out to you, their contract support is *fundamentally* broken.
Furthermore, their static checker for contracts only works in *trivial* cases, 
as I also showed to you. This is not a technology that is ready for real world
use.



 And regardless the usefulness of Verve today, they contain some quite
 interesting ideas. I'm not just an engineer, I like ideas too. Shutting the
 brain closed is stupid.


Interesting ideas is not the same thing as usable/better for kernel dev. 
Interesting ideas are a dime a dozen. Getting them to work in a professionally 
useful tool is an entirely different matter.
Jan 03 2011