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