David Wagner was kind enough to let me know about a paper that he and his students wrote recently:

http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf

It's a great honor and validation to be acknowledged in a paper of such quality and to see D's approach to purity not only mentioned, but in praise terms nonetheless (section 9).


Andrei

Andrei Alexandrescu wrote:
> David Wagner was kind enough to let me know about a paper that he and his students wrote recently:
> 
> http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf
> 
> It's a great honor and validation to be acknowledged in a paper of such quality and to see D's approach to purity not only mentioned, but in praise terms nonetheless (section 9).


Reddit: http://www.reddit.com/r/programming/comments/71h8z/verifiable_functional_purity_in_java/

On Mon, Sep 15, 2008 at 7:42 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> David Wagner was kind enough to let me know about a paper that he and his students wrote recently:
>
> http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf
>
> It's a great honor and validation to be acknowledged in a paper of such quality and to see D's approach to purity not only mentioned, but in praise terms nonetheless (section 9).

Congrats to all involved in the design!  Is this the first mention of D in such a peer-reviewed research publication?

--bb

Andrei Alexandrescu:
> It's a great honor and validation to be acknowledged in a paper of such quality and to see D's approach to purity not only mentioned, but in praise terms nonetheless (section 9).

It seems to contain some comments that are not a praise too:

>While this approach avoids the need to eliminate mutable state and determinism from the global scope, there is a substantial cost in expressivity as it prevents pure functions from making any use of impure functions and methods. The result is essentially of a partition of the program into imperative and purely functional portions, whereas our approach allows pure functions to make full use of the rest of the program, limited only by the references they hold.<

Anyway, in Java, Python, and few articles I have read about such topics they all talk about immutable objects and variables, I too use this term generally. Commonly used (correct) terms are important to help people quickly create clear connections between concepts and their names, so I think D2 may chose to use a more correct term "immutable" to denote that concept. There's time to change terms still, not many people are using D2 yet.

Bye,
bearophile

Bill Baxter wrote:
> On Mon, Sep 15, 2008 at 7:42 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> David Wagner was kind enough to let me know about a paper that he and his
>> students wrote recently:
>>
>> http://www.cs.berkeley.edu/~daw/papers/pure-ccs08.pdf
>>
>> It's a great honor and validation to be acknowledged in a paper of such
>> quality and to see D's approach to purity not only mentioned, but in praise
>> terms nonetheless (section 9).
> 
> Congrats to all involved in the design!  Is this the first mention of
> D in such a peer-reviewed research publication?

Yes, in fact. We've been very slow in getting stuff published about D, but that will change once I finish my PhD.

Andrei

bearophile wrote:
> Andrei Alexandrescu:
>> It's a great honor and validation to be acknowledged in a paper of
>> such quality and to see D's approach to purity not only mentioned,
>> but in praise terms nonetheless (section 9).
> 
> It seems to contain some comments that are not a praise too:
> 
>> While this approach avoids the need to eliminate mutable state and
>> determinism from the global scope, there is a substantial cost in
>> expressivity as it prevents pure functions from making any use of
>> impure functions and methods. The result is essentially of a
>> partition of the program into imperative and purely functional
>> portions, whereas our approach allows pure functions to make full
>> use of the rest of the program, limited only by the references they
>> hold.<

Any paper will mention the disadvantages of related work in the pertinent section. I'm not worried about that at all. Their system is more expressive but also considerably more complex. That's not necessarily bad, it's a different point in tradeoff space.

> Anyway, in Java, Python, and few articles I have read about such
> topics they all talk about immutable objects and variables, I too use
> this term generally. Commonly used (correct) terms are important to
> help people quickly create clear connections between concepts and
> their names, so I think D2 may chose to use a more correct term
> "immutable" to denote that concept. There's time to change terms
> still, not many people are using D2 yet.

I think that's a good point.


Andrei

On Mon, 15 Sep 2008 04:52:20 -0400, Bill Baxter <wbaxter@gmail.com> wrote:
> Congrats to all involved in the design!  Is this the first mention of
> D in such a peer-reviewed research publication?

Yes and no. It's the first time the language has been commented on (that I know of), but a year ago I had a conference poster (At AAPM) which mentioned D and this year I had a MICCAI workshop paper (http://www.cse.buffalo.edu/hpmiccai/program.html, see Towards Real-Time Radiation Therapy: GPU Accelerated Superposition/Convolution) in addition to some posters (at AAPM and ASTRO). I wouldn't be surprised if there are others that have used D in their research and have cited it.

On Mon, Sep 15, 2008 at 10:54 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Mon, 15 Sep 2008 04:52:20 -0400, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>> Congrats to all involved in the design!  Is this the first mention of D in such a peer-reviewed research publication?
>
> Yes and no. It's the first time the language has been commented on (that I
> know of),

Yeh, that's more what I meant.  Being commented on as a language by people who study such things.

> but a year ago I had a conference poster (At AAPM) which mentioned
> D and this year I had a MICCAI workshop paper
> (http://www.cse.buffalo.edu/hpmiccai/program.html, see Towards Real-Time
> Radiation Therapy: GPU Accelerated Superposition/Convolution) in addition to
> some posters (at AAPM and ASTRO).

Hey!  You gotta announce these things!

> I wouldn't be surprised if there are
> others that have used D in their research and have cited it.

Oh yeh.  Good point -- like me for instance.  :-)
I guess I should follow my own advice.
My D-using research paper:
http://doi.acm.org/10.1145/1377980.1377993
I was kinda waiting to say anything until the paper describing the
main project was published.  The NPAR paper above one was just a
little offshoot of that.  I'll be presenting the main thing as a
poster at Pacific Graphics '08 next month, but posters don't count as
"Publications" in the world of computer graphics.

--bb

Robert Jacques:
> this year I had a MICCAI workshop paper (http://www.cse.buffalo.edu/hpmiccai/program.html, see Towards Real-Time Radiation Therapy: GPU Accelerated Superposition/Convolution)

Nice, it says:

>We have adapted the superposition/convolution algorithm to the GPU using a combination of NVIDA's Compute Unified Device Architecture (CUDA) software development environment and the Digital Mars’ D programming language for our implementation.<

How have you used D with CUDA? I'd like to know a bit more technical details.
And do you know about BSGP (that I think is a step toward the future of such things)?
http://www.kunzhou.net/

Bye,
bearophile

On Mon, 15 Sep 2008 17:08:58 -0400, Bill Baxter <wbaxter@gmail.com> wrote:

> Hey!  You gotta announce these things!

Here's the post from a year ago: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=9466.