> Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
> mention JCSP and GPars.

I'm not really sure whether this can be put exactly that way. On a machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green threads). Let's say each threads calculates a large fibonacci number. If the fibonacci calculation yields the processor frequently all 80.000 run seamingly in parallel and return their result almost "at the same time".

With GPars this would not work. You can only start some 2.000 Java threads on a machine with the same amount of memory. If also the fibonacci calculation in Groovy/GPars yields the processor, using GPars the first 2.000 fibonacci calculations will nevertheless crowd out the following 2.000 threads of all those 80.000 fibonacci calculations and so on. I once tried this out with both Go and Groovy/GPars.

-- Bienlein

On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote:
> In addition, further development of the ability to call D from R or Python* or Julia (or vice-versa) would also be a positive.

What do you have in mind? I no longer work much with Python so my knowledge is limited, but calling D from R or Julia should be no different from calling C from those languages, as you normally compile your C code into a shared library anyway.

I've done the R->D thing many times and in the process have worked with a big chunk of the R API. Things like allocating R data structures from a D function, adding assertions to your D code to allow for an easy exit when things don't work out, and calling functions in the R math library, among other things, are not difficult.

Characterizing the problem as "Go versus D" is framing it to D's disadvantage. Broadly speaking Go is one thing & D is many things.

The whole difficulty with D encountered by a person choosing which of (e.g.) Go and D to use lies in this difference. D as a whole is overwhelming in this situation.

D may be spoken naturally in many different ways. This is its strength. We need to make this strength accessible to outsiders. If an outsider can speak D at first in a way somewhat familiar from their previous experience, that will provide accessibility.

We may classify outsiders as coming from C, C++, Java, Python, Go and more. Make your own list.

Each kind of outsider needs to see an approximate reflection in D of the machinery of their usual means of expression and its attendant conceptual models, plus exciting possibilities to improve and extend these. This reflection must be made workable on all scales, from details of idioms and techniques up to the big picture.

An outsider needs a well developed specialized way in! One that is designed for that specific class of outsider. Given such, in the short run the D written by one class of outsider will be quite different in its use of the language to that written by another, which will be quite different again to that written by contributors to phobos.

We should accept this. They may expand their horizons within D later. The community may find ways to help such people do this, for example by gently suggesting better parts of D to use for technical parts of their purposes when they post to the forums. In the meantime they have come to D because there was a relatively efficient way for them to do that, not a bewildering collection of possibilities that deflected them to the certainties of the overly prescribed ways of (e.g.) Go.

Now consider outsiders from C, C++, Java, Python, Go.

I'll leave you to consider C, C++. The articles
  http://dlang.org/ctod.html
  http://dlang.org/cpptod.html
  http://dlang.org/pretod.html
have made a detail-oriented start with tacit assumptions about what is going on at wider scales. These languages are closely entangled with D's development, and so are special cases given better treatment. These could be expanded into an entire introduction to D for C outsiders and an entire introduction to D for C++ outsiders.

Java is not too hard especially given the design of D's classes. Java is almost a small sublanguage of D.

Python and Go are harder. But D is a system programming language with [long list of powerful abstraction facilities, many supported paradigms, "wonderfulness of D"]. And as such one may hope it is possible to arrange to program in D in Pythonesque or Goish ways. Especially if this provides a way for D to win rather than lose out to these languages, by providing an incremental way in.

The yield facility in Python can serve as a first example here. This is not a part of the D language. The Fiber class in core.thread can be made to emulate it with additional superstructure with some effort. But this is exactly the kind of effort an outsider from Python is not immediately equipped to make. Go's goroutine and its attendant machinery could be examined with a similar end in view.

What all of this suggests is that some library code may need to be written to accomodate the way into D for a class of outsiders. The administration of where such goes needs to make it simple to import with a standard D installation. And if D is too inflexible to provide something important via a library, as is possibly the case with yield, serious consideration should be given to (don't scream) adding it to the language.

In conclusion, D is not gaining the traction it deserves as a potential lingua franca. I am making the case that we need to treat it as several programming languages for the purpose of making it rapidly usable by typical outsiders. D-python, D-java, D-whatever --- facets of D.

This entails library additions, and possibly language additions. This entails a lot of writing of documentation, in effect a small book for each facet of D.

There is much to be decided about how this could be best done. I will not pursue that here. But I do believe something approximately like this is the only way for D to start to win out when someone decides whether to use (e.g.) Go or D in a new situation, or even whether to use D or stay back in Python with all of its disadvantages. The complex cliff face of D needs some overtly navigated paths for all kinds of explorers.

On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote:
> What do you have in mind? I no longer work much with Python so my knowledge is limited, but calling D from R or Julia should be no different from calling C from those languages, as you normally compile your C code into a shared library anyway.
>
> I've done the R->D thing many times and in the process have worked with a big chunk of the R API. Things like allocating R data structures from a D function, adding assertions to your D code to allow for an easy exit when things don't work out, and calling functions in the R math library, among other things, are not difficult.

(For work at least) I find myself in situations where I'm forced into using loops in R or Python. Sometimes the loops can be parallelized, but not always. Python is not good for parallelizing, and R is only good on a Linux machine (which I can't use at work). Both are bad when you really have to do a loop. Julia is better for that, but I can't get the package manager to work on my work computer because of a corporate firewall. Anyway, all the calculations I would be doing would involve matrix math/regressions/optimization, most of which could be done in C++ (so being able to call C++ libraries would go a long way).

I've looked at calling C code from R before and using Cython in Python. However, I think it's another step altogether to get an R library (like lme4) to work in a D program. I have zero idea how to go about doing that. It has seemed like a bit of a hassle for anything complex. For instance, suppose I wanted to create a loop in C that calls an R function from lme4 multiple times and then I wanted to call that C function from R. Makes my head hurt just thinking about it.

Nevertheless, I think that there would be a lot of value in writing up what you have done with R and D. That sounds very interesting.

On 3/17/15 1:50 PM, Bienlein wrote:
>
>> Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
>> mention JCSP and GPars.
>
> I'm not really sure whether this can be put exactly that way. On a
> machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green
> threads). Let's say each threads calculates a large fibonacci number. If
> the fibonacci calculation yields the processor frequently all 80.000 run
> seamingly in parallel and return their result almost "at the same time".

How many physical threads would the 80K goroutines create? -- Andrei

On Tuesday, 17 March 2015 at 22:30:37 UTC, Andrei Alexandrescu wrote:
> On 3/17/15 1:50 PM, Bienlein wrote:
>>
>>> Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
>>> mention JCSP and GPars.
>>
>> I'm not really sure whether this can be put exactly that way. On a
>> machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green
>> threads). Let's say each threads calculates a large fibonacci number. If
>> the fibonacci calculation yields the processor frequently all 80.000 run
>> seamingly in parallel and return their result almost "at the same time".
>
> How many physical threads would the 80K goroutines create? -- Andrei

The Go runtime manages this. About as many as there are CPU.

On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
> On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
>> On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
>>
>> This discussion happens often when discussing C++'s or D's `auto`. It doesn't matter what the type is, what matters is in the interface.
>>
>> As for storing it:
>>
>> auto foo = voldemort();
>>
>> Oh, you meant in a struct?
>>
>> struct Foo(T) {
>>   T thingie;
>> }
>>
>> auto foo(T)(T thingie) {
>>    return Foo!T(thingie);
>> }
>>
>> auto f = foo(voldemort());
>>
>> Atila
>
> That proves my point cost for the user just so the library designer can group his type inside the function that returns it.
>
> How many times is csvReader used vs how many times is it written. It it's 100 to 1, that's 100 times the cost to the user vs 1 x the cost to the library author.
>
> I cant help thinking it's like how when programmers first learn about design patterns they start trying to make everything they can into a ****ing singleton.

I have on a number of occasions wanted this:

struct S {
    Iota r; // ?? Would be nice, can it be done ??
}

if(something) {
    s.r = iota(10);
} else {
    s.r = iota(0, 10, 2);
}


As a new D user and relatively new to programming I've tried really hard to find a way to do this and given up. If it's possible I'd love to know!!

I did try the template approach with "function return type part of my struct type" route but it a) made my code very messy with templates everywhere even where I didn't want them and b) the compiler memory usage blew out to over 4Gb with 2.067 and I could not compile my project.

I had to take it all out again and in the end implemented my own iota with my original approach (as above). I'm not doing that again.


bye,
amber

On Tuesday, 17 March 2015 at 22:58:42 UTC, amber wrote:
>
> I had to take it all out again and in the end implemented my own iota with my original approach (as above). I'm not doing that again.
>
>
> bye,
> amber


On a side note, to implement iota I copied it from Phobos with minor changes. I was really surprised at how clean and easy to understand the code was.

I'm now perusing Phobos code and in 30mins I've picked up some great D tricks for a novice :)

bye,
amber

On 3/17/15 3:58 PM, amber wrote:
> On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
>> On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
>>> On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
>>>
>>> This discussion happens often when discussing C++'s or D's `auto`. It
>>> doesn't matter what the type is, what matters is in the interface.
>>>
>>> As for storing it:
>>>
>>> auto foo = voldemort();
>>>
>>> Oh, you meant in a struct?
>>>
>>> struct Foo(T) {
>>>   T thingie;
>>> }
>>>
>>> auto foo(T)(T thingie) {
>>>    return Foo!T(thingie);
>>> }
>>>
>>> auto f = foo(voldemort());
>>>
>>> Atila
>>
>> That proves my point cost for the user just so the library designer
>> can group his type inside the function that returns it.
>>
>> How many times is csvReader used vs how many times is it written. It
>> it's 100 to 1, that's 100 times the cost to the user vs 1 x the cost
>> to the library author.
>>
>> I cant help thinking it's like how when programmers first learn about
>> design patterns they start trying to make everything they can into a
>> ****ing singleton.
>
> I have on a number of occasions wanted this:
>
> struct S {
>      Iota r; // ?? Would be nice, can it be done ??
> }
>
> if(something) {
>      s.r = iota(10);
> } else {
>      s.r = iota(0, 10, 2);
> }

import std.range;

void main()
{
    struct S {
        typeof(iota(0, 1, 1)) r;
    }

    S s;

    if(1) {
        s.r = iota(0, 10, 1);
    } else {
        s.r = iota(0, 10, 2);
    }
}

Also: there's a learn forum.


Andrei

On Wednesday, 18 March 2015 at 00:04:26 UTC, Andrei Alexandrescu wrote:
> On 3/17/15 3:58 PM, amber wrote:
>> On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
>>> On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
>>>> On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
>>>>
>>>> This discussion happens often when discussing C++'s or D's `auto`. It
>>>> doesn't matter what the type is, what matters is in the interface.
>>>>
>>>> As for storing it:
>>>>
>>>> auto foo = voldemort();
>>>>
>>>> Oh, you meant in a struct?
>>>>
>>>> struct Foo(T) {
>>>>  T thingie;
>>>> }
>>>>
>>>> auto foo(T)(T thingie) {
>>>>   return Foo!T(thingie);
>>>> }
>>>>
>>>> auto f = foo(voldemort());
>>>>
>>>> Atila
>>>
>>> That proves my point cost for the user just so the library designer
>>> can group his type inside the function that returns it.
>>>
>>> How many times is csvReader used vs how many times is it written. It
>>> it's 100 to 1, that's 100 times the cost to the user vs 1 x the cost
>>> to the library author.
>>>
>>> I cant help thinking it's like how when programmers first learn about
>>> design patterns they start trying to make everything they can into a
>>> ****ing singleton.
>>
>> I have on a number of occasions wanted this:
>>
>> struct S {
>>     Iota r; // ?? Would be nice, can it be done ??
>> }
>>
>> if(something) {
>>     s.r = iota(10);
>> } else {
>>     s.r = iota(0, 10, 2);
>> }
>
> import std.range;
>
> void main()
> {
>     struct S {
>         typeof(iota(0, 1, 1)) r;
>     }
>
>     S s;
>
>     if(1) {
>         s.r = iota(0, 10, 1);
>     } else {
>         s.r = iota(0, 10, 2);
>     }
> }
>
> Also: there's a learn forum.
>
>
> Andrei

Thank you!

I'll move onto D.learn :-)

bye,
amber