On Saturday, 24 June 2017 at 21:56:20 UTC, Andrei Alexandrescu wrote:
> On 6/24/17 1:11 PM, Wulfklaue wrote:
> [snip]
>
> Thanks, this is a good point. The bountysource has been tried by
> Facebook (with D and other projects) and was deemed unsuccessful. It may
> be the time for trying a new angle on bountysource though.

The issue with pure bounties is that while they may incentive people if the work vs reward is good. But unfortunately, when reading the bounties currently posted, a lot seem to be major amount of time vs little pay.

That is why Nim / Crystal simply work with collecting money to pay developers for specific bounties or pay for full time people. It does not prevent people from doing there own bounties if they want.

> We'll look into defining a page listing existing sponsors (though the majority by monies are anonymous) and a simple method to donate on the website.

As seen with Nim, Crystal, ... there are plenty of people who do not have a issue given a name or nickname. I think the current reason for a lot of anonymous donation is simply there is no real "advantage" for that person to have his/her name known.

People are competitive animals. If you see what amount of money people sometimes donate to  ( small ) youtube'rs. Sometimes thousand of dollars. All for being grateful by the person receiving the money and being the top donater.

> What other methods of payments do you have in mind?

Germany: www.sofort.com
Netherlands: www.ideal.nl
...

Those are all popular in there respected countries. At times bigger then paypal etc...

> Nevertheless we need to update that.

Might be interesting to also move the donation a bit more "visual" on the website. Its not the first time that issues regarding the website have been mentioned.

* The library still using the horrible phobos/index.html 101 page library. There is now a link to the library/index.html that is way better. But its something that most people will overlook.

* Tutorials:

I found the old:

https://www.tutorialspoint.com/d_programming/d_programming_associative_arrays.htm

A more interesting spot to actually learn D examples, then the D website /spec/class.html. It more messy and finding out about sometimes as simply as associative_arrays, only to discover that its buried somewhere.

* It might also be interesting to do a "Rust" and have Ali's D book provided as a standard free D book ( and maybe pay him something per download ). Now it already requires some searching or forum knowledge to find out the book is also available for free. Make it a prominent feature item on the website. Worth a extra blog post = free publicity again. :)

* Local language websites.

As somebody with family relations in China, i can say that there is a thriving Go community in China, where most Go related documentation got translated. Unfortunately, its a bit of "western" thinking, that everybody speaks / reads on a good level English. By not having localized language versions of major markets, D loses out on target audience. Go had the luxury that a lot of people comited time to do the translations and was rewarded with a large Go community in China. Something that most western developer do not even realize how big Go is in China. The idea that every software  developer knows (any/good ) English is sometimes a bit exaggerated. So this is again a overlooked potential focus point.

... Plenty of topics regarding the website around ;)

My biggest advice is to find or hire a community director. Somebody who's job is community management, media management, to focus resources etc. Some of the things that i mention seem to have been mentioned a lot of times before.

On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote:
>
> Just this morning I got things working on Windows. Now that all three major platforms have support, it is as reasonable to create an R package with D functions as C, C++ or Fortran. Anyone can write up a library of D functions and put a package on Bitbucket or Github. The R user doesn't even need to know which language the functions are written in.

Music to my ears! Please put something up on announce when you release it.

>
> On my agenda next are interoperability with Julia and Octave (which isn't that popular, but would make a lot of Matlab code available inside D). I honestly don't know if this will bring in new D users, but for the most part I don't care, because I'm doing it for my own research. Nonetheless, I think the potential to expand the D userbase is there.

I write less Matlab code these days than I used to, but I'm sure that would be valuable as well. There's a lot of Matlab code out there.

Maybe I am wrong but I get a feeling from posts in this thread that some people are greatly underestimating the size of some segments, like mentioning niche C++ programmers and only 0.01% percent of developers needing memory management. The games industry is growing like crazy [1][2] and after all these years C++ is still the main language for that except that today 99% of those developers have many bad things to say about it. Imagine how D adoption would jump if someone created something on par with Unity or Unreal engine, or even Cocos engine in D. And I think D is already up to that task, with biggest pain points being only cross platform support, especially for Android and iOS.

Also regarding the question whether D should be marketed as general purpose or some special purpose language I find this article [3] has it explained nicely, except that it seems to me language should be marketed as general but have strong libraries (or game engines) for specific purposes through which it should market itself as something specialized.

[1] http://kotaku.com/nearly-40-of-all-steam-games-were-released-in-2016-1789535450
[2] http://www.gamasutra.com/view/news/267645/Over_500_games_now_submitted_to_iOS_App_Store_every_day.php
[3] https://simpleprogrammer.com/2017/06/19/generalists-specialists/

On Monday, 19 June 2017 at 15:07:12 UTC, Jack Stouffer wrote:
> On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
>> The former is not a problem for D, but the latter…
>
> Disagree. One of D's biggest competitive advantages is fast compilation of fast code. If other languages become as fast or faster than DMD in compilation speed then that's a big problem.

I think the problem with this is that compilation speed being the no. 1 selling point requires people to invest in large projects in order to reap the benefits. However, if you fail to draw them in to begin with, then they're not going to commit to a large enough project to benefit enough from improved compilation speed.

On Saturday, 24 June 2017 at 23:05:58 UTC, jmh530 wrote:
> On Saturday, 24 June 2017 at 19:17:24 UTC, bachmeier wrote:
>>
>> Just this morning I got things working on Windows. Now that all three major platforms have support, it is as reasonable to create an R package with D functions as C, C++ or Fortran. Anyone can write up a library of D functions and put a package on Bitbucket or Github. The R user doesn't even need to know which language the functions are written in.
>
> Music to my ears! Please put something up on announce when you release it.

It will probably take a while to put together a formal release. In the meantime, you can test it if you want. Here's an example that works for me on 64-bit Windows (it's obviously not the only way to do this).

1. Create the D file with the functions you want to call from R. Save this in librtest.d:

import embedr.r;
mixin(createRLibrary("rtest"));

import std.math;

export extern(C) {
  Robj transform(Robj rx) {
    auto x = RVector(rx);
	double[] y = [log(x[0]), log(x[1])];
	double result = y[0] + y[1];
	return result.robj;
  }
}

2. Download embedr to that same directory https://bitbucket.org/bachmeil/embedr/raw/89797bc39030a8433839119cfcdf7de6e8d7007c/inst/embedr/r.d

3. Windows requires R.lib for compilation, so I created that by installing the MinGW pexports.exe utility.

C:\MinGW\bin\pexports.exe R.dll > R.def

Then create the .lib using Visual Studio:

"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64

4. Create librtest.dll using LDC:

"C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe" -shared -m64 librtest.d r.d -version=inline R.lib

5. Open 64-bit R, load the library, and test it out:

dyn.load("librtest.dll")
.Call("transform", c(2.0, 3.0))

Disclaimer: I don't know much about Windows development. It would be nice to have others test this out and identify problems. I would like to figure out how to make R packages with D code on Windows before doing a release.

On Sunday, 25 June 2017 at 10:50:17 UTC, Igor wrote:
> percent of developers needing memory management. The games industry is growing like crazy [1][2] and after all these years C++ is still the main language for that except that today 99% of those developers have many bad things to say about it.

I think the number of games are increasing because people now can write games in other languages than C++. Unfortunately it is my impression many of those games are the same game-engine being redressed with differently themed graphics + some tweaks.

> article [3] has it explained nicely, except that it seems to me language should be marketed as general but have strong libraries (or game engines) for specific purposes through which it should market itself as something specialized.

But you need a focus, figure out what you are good at and go with it. For which domain is your language the best option?

Decent doesn

On Monday, 26 June 2017 at 06:47:53 UTC, Ola Fosheim Grøstad wrote:
> But you need a focus, figure out what you are good at and go with it. For which domain is your language the best option?
>
> Decent doesn

(Hit tab by mistake, why would tab+space be a sensible key sequence for sending a message? Have experienced the same issue in gmail.)

Anyway,  decent doesn't cut it, you have to focus on the areas where your language can become the hands down best option.

Which is why throwing in some libraries for various domains won't work. If you don't have good integration with one of the best physics engines, then you can't really compete in the area of games in the general case.

C++, Rust, Swift and Go have some very clear areas where they are the best option if you evaluate the available options based on your project's requirement spec. Which is why they have traction.

It isn't really a question of individual language features or libraries making things possible. Those things attract individual programmers, but it doesn't directly affect the cost/feasibility analysis for a project where you evaluate options for something very specific.

Scripting-like programming is different, there you often want one flexible language that can do a little of everything, but it doesn't have to master any particular area or do it particularly well. E.g. Python.

On Monday, 26 June 2017 at 01:31:43 UTC, bachmeier wrote:
> [snip]
> 3. Windows requires R.lib for compilation, so I created that by installing the MinGW pexports.exe utility.
>
> C:\MinGW\bin\pexports.exe R.dll > R.def
>

You might make reference to cd to the folder that R.dll for x64 is in, for me it was
C:\Program Files\R\R-3.3.3\bin\x64

I also got access denied, so used administrative cmd.

RTools hadn't installed pexports, so I installed a new MinGW.

> Then create the .lib using Visual Studio:
>
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\lib.exe" /def:R.def /out:R.lib /machine:x64
>

I have Visual Studio 2017 installed, so I used
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\lib.exe" /def:R.def /out:R.lib /machine:x64

but got the error

LINK : fatal error LNK1171: unable to load mspdb140.dll (error code: 126)

So I tried to use my Visual Studio 12 (did not have 14 installed). That seemed to work.

> 4. Create librtest.dll using LDC:
>
> "C:\Users\lance\ldc64\ldc2-1.3.0-beta2-win64-msvc\bin\ldmd2.exe" -shared -m64 librtest.d r.d -version=inline R.lib

Path adjusted for my location of ldc2. Also, I had ldc2-1.3.0-beta1. Also, first you need to cd back to the original location.

Then, this caused a problem because it used my 2017 Visual Studio instead of the Visual Studio 12.0. So I gave up, for now, at this point.

I might make another effort on this after work if I have time.

On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote:

[...]

> Then, this caused a problem because it used my 2017 Visual Studio instead of the Visual Studio 12.0. So I gave up, for now, at this point.
>
> I might make another effort on this after work if I have time.

Thanks for giving it a try. I have a feeling that this is a job for Dub, SCons, or more likely, an R package that figures out this stuff. Windows development seems to have more moving parts. An R package on Linux requires adding a Makefile with one line.

On Sunday, 25 June 2017 at 17:21:06 UTC, Michael wrote:
> I think the problem with this is that compilation speed being the no. 1 selling point requires people to invest in large projects in order to reap the benefits. However, if you fail to draw them in to begin with, then they're not going to commit to a large enough project to benefit enough from improved compilation speed.

I don't know where you're getting this idea that fast compile times only help for large projects.

I reap the benefits every time I use rdmd for my scripts. I reap the benefits every time the compilation is near instant when tweaking+debugging my libraries or when unit testing my projects.