> One great way to address it is by writing articles about various aspects of D and how they solve problems, like http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/   which was well received on reddit.
>
> Anyone have good ideas on topics for D articles? And anyone want to stand up and write an article?

What about a followup article about more sophisticated CTFE, maybe in combination with string mixins to generate complex code?
For example, if std.regex is evaluatable at compile time I will probably use it create some skeleton code out of an interface definition.

On 06/03/2010 08:34 PM, Adam Ruppe wrote:
> I recently rewrote a huge PHP application in D2. It isn't a completely
> fair comparison, since the PHP was written by, well to be polite, PHP
> "programmers", but the results were pretty astounding.
>
> 90% reduction in lines of code [!], 200% improvement in speed under
> heavy load (only 50% improvement under light load, still good, but not
> as good), and the code is actually maintainable! Also, the original
> took about a year for the first team to write. My D rewrite took 6
> weeks. Oh yeah, and the PHP is riddled with security holes. Not so
> much with the D.
>
> The best part about the speed is that it is just running as plain old
> CGI and my code does a lot of inefficient looping through XML. I could
> probably double the speed again by improving that.
>
>
> I might be able to write this into an article, but what I've done so
> far is just showed it off to other coders in some private messages on
> forums. A complication in publically showing it off is it is closed
> source though. The speed advantage isn't apparent until the code
> actually does something; PHP is much faster for hello world, but gets
> spanked when it comes to the actual work.

I think this is the best way to approach writing, and I strongly encourage you to just plow through whatever IP issues there are and go for it. (In my experience, nobody will come after you for writing an article that doesn't outright give the code away.) I'm repeating myself, but writing a good piece should at best start with a desire to share something you genuinely believe is interesting (as opposed to starting with a desire for developing an article and consequently looking for a topic idea). You seem to be right on the money.

In related news... For what it's worth, I plan to write about memory-isolated containers (those that can use malloc/free for their allocation strategy without being unsafe). I believe there are a number of fine points to be made and that such containers solve an important class of problems. InformIT.com considers the idea interesting and commissioned me to write that article.

I've also read again today this piece by Oleg Kiselyov:

http://okmij.org/ftp/papers/LL3-collections-enumerators.txt

Oleg is pretty awesome and makes great points, but I think also missed a few. The abstract is a bit difficult to get into (and I haven't understood his enumerator inversion trick without using continuations). I have a pretty good retort in my mind, but that would take quite a long time to write.


Andrei

Andrei Alexandrescu wrote:
> On 06/03/2010 08:34 PM, Adam Ruppe wrote:
>> I recently rewrote a huge PHP application in D2. It isn't a completely
>> fair comparison, since the PHP was written by, well to be polite, PHP
>> "programmers", but the results were pretty astounding.
>>
>> 90% reduction in lines of code [!], 200% improvement in speed under
>> heavy load (only 50% improvement under light load, still good, but not
>> as good), and the code is actually maintainable! Also, the original
>> took about a year for the first team to write. My D rewrite took 6
>> weeks. Oh yeah, and the PHP is riddled with security holes. Not so
>> much with the D.
>>
>> The best part about the speed is that it is just running as plain old
>> CGI and my code does a lot of inefficient looping through XML. I could
>> probably double the speed again by improving that.
>>
>>
>> I might be able to write this into an article, but what I've done so
>> far is just showed it off to other coders in some private messages on
>> forums. A complication in publically showing it off is it is closed
>> source though. The speed advantage isn't apparent until the code
>> actually does something; PHP is much faster for hello world, but gets
>> spanked when it comes to the actual work.
> 
> I think this is the best way to approach writing, and I strongly encourage you to just plow through whatever IP issues there are and go for it. (In my experience, nobody will come after you for writing an article that doesn't outright give the code away.) I'm repeating myself, but writing a good piece should at best start with a desire to share something you genuinely believe is interesting (as opposed to starting with a desire for developing an article and consequently looking for a topic idea). You seem to be right on the money.

I agree with Andrei - write the article!


> In related news... For what it's worth, I plan to write about memory-isolated containers (those that can use malloc/free for their allocation strategy without being unsafe). I believe there are a number of fine points to be made and that such containers solve an important class of problems. InformIT.com considers the idea interesting and commissioned me to write that article.

This is exactly what I'm talking about.

Walter Bright wrote:
> I agree with Andrei - write the article!

The most popular blog entry I wrote for DDJ, was the one on converting assembler code to C, based on my ongoing trenchwork actually doing it with optlink. People like articles about real world meat & potatoes language work. So I think your PHP => D experience would make for most interesting reading.

Walter Bright wrote:
> 
> Anyone have good ideas on topics for D articles?
> 

Yes, I think the relevant themes are:

1. High, comparable to C performance, unlike C# or Java, preserving features from such competitor languages.
2. D does not require the programmer to use only one particular paradigm, at the option of imperative, object oriented, and metaprogramming; does not require significant change of syntax, helps migrating to D quickly from C/C++, while significantly increasing productivity; direct linking with C libraries; direct access to the native OS interface.

I also should mention, these need improvement in D:

1. Concurrency support and optimization for multicore/multiprocessor/GPGPU systems.
2. Better toolchain support.

The first two inspired me to try the D.
The second two should inspire the others.


-- 
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com

On 2010-06-04 01:58:03 +0200, Walter Bright said:

> D is an extremely powerful language, but when I read complaints and sighs about other languages, few seem to know that these problems are solved with D. Essentially, we have a marketing problem.
> 
> One great way to address it is by writing articles about various aspects of D and how they solve problems, like http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/   which was well received on reddit.
> 
> Anyone have good ideas on topics for D articles? And anyone want to stand up and write an article?
> 
> They don't have to be comprehensive articles (though of course those are better), even blog entries will do.

I will write a blog article how I used D to write an extension DLL for the Rebol-3 language. I used the C stuff and ported it over in a couple of hours.

Being now able to use D on the compile side give totally new possibilities.

On the other hand those articles should focus on those complaints and sighs topics from other languages and show how elegant D can solve it. To keep the link.

-- 
Robert M. Münch
http://www.robertmuench.de

Walter Bright wrote:

> Walter Bright wrote:
>> I agree with Andrei - write the article!
> 
> The most popular blog entry I wrote for DDJ, was the one on converting assembler code to C, based on my ongoing trenchwork actually doing it with optlink. People like articles about real world meat & potatoes language work. So I think your PHP => D experience would make for most interesting reading.

A post-mortem style article or blog is nice, reading about the whole experience of the development process is often interesting. I remember one such an article at gamedev.net about D which was highly appreciated, while normally gamedev.net has a very critical crowd. Showing off cool features generally only works on people already convinced or in the know, for critics it usually evokes a 'so what' response.

More questions and answers on stackoverflow might help too. I will try to make more use of that myself.

Robert Clipsham wrote:

> On 04/06/10 00:58, Walter Bright wrote:
>> D is an extremely powerful language, but when I read complaints and sighs about other languages, few seem to know that these problems are solved with D. Essentially, we have a marketing problem.
>>
>> One great way to address it is by writing articles about various aspects
>> of D and how they solve problems, like
>> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>> which was well received on reddit.
>>
>> Anyone have good ideas on topics for D articles? And anyone want to stand up and write an article?
>>
>> They don't have to be comprehensive articles (though of course those are better), even blog entries will do.
> 
> Given some ideas I'm happy to write an article or two. I guess the best thing to write articles on are the problems D solves which other languages have, or how D makes something easier to do - we'd need to pick out some specific areas though.
> 
> Robert

I would be interested in contract programming. Taking a small example app and illustrating how to add pre- and postconditions, invariants, contract inheritance and perhaps notrow and pure. Or start with the contracts as advocated by the Eiffel method. Perhaps do the same with .NET 4.0 contracts and compare the results.

On 6/3/2010 9:34 PM, Adam Ruppe wrote:
> I recently rewrote a huge PHP application in D2. It isn't a completely
> fair comparison, since the PHP was written by, well to be polite, PHP
> "programmers", but the results were pretty astounding.
>
> 90% reduction in lines of code [!], 200% improvement in speed under
> heavy load (only 50% improvement under light load, still good, but not
> as good), and the code is actually maintainable! Also, the original
> took about a year for the first team to write. My D rewrite took 6
> weeks. Oh yeah, and the PHP is riddled with security holes. Not so
> much with the D.
>
> The best part about the speed is that it is just running as plain old
> CGI and my code does a lot of inefficient looping through XML. I could
> probably double the speed again by improving that.
>
>
> I might be able to write this into an article, but what I've done so
> far is just showed it off to other coders in some private messages on
> forums. A complication in publically showing it off is it is closed
> source though. The speed advantage isn't apparent until the code
> actually does something; PHP is much faster for hello world, but gets
> spanked when it comes to the actual work.

I've spent years in both D and PHP, and most of my php code is a little shorter than what the equivalent would be in D, mostly due to an enormous standard library.  Now D is much better designed and much faster, but most php programs are trash because the language attracts so many noobs.  I've spent a lot of time rewriting PHP apps in PHP that ended up being 10% of the length of the original.

I prefer D to PHP, but writing a web app in D would take me much longer due to the lack of web-oriented libraries.  However, the speedup you got with D is a good angle to push.

On 6/4/10, Eric Poggel <dnewsgroup@yage3d.net> wrote:
> I prefer D to PHP, but writing a web app in D would take me much longer due to the lack of web-oriented libraries.

What kind of stuff would you need? I admit I did spend several weekends doing prep work on libraries before proposing it to the client - had to write mysql, cgi, http get and post, my xml code, and some helper functions to extend std.json before I was confident enough in having the libraries to propose it, but now I have that, and can share if it sounds useful.

The only place where library lacking has hit me so far is interfacing with Facebook. For that part of the app, I still use PHP. I'd like to port it eventually, implementing oauth and such in a nice, generic way, but I haven't gotten around to it yet... still, the vast majority of what I need I can do now in plain D.