On Wednesday, 26 July 2017 at 19:27:06 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 26 July 2017 at 18:58:31 UTC, kinke wrote:
>> People need to eventually understand that all the energy wasted for complaining about D/the community/whatever would be so much more valuable if put into contributions.
>
> Value is relative. So, if you don't use a tool in production why would you derive more value value from "improving" on the tool rather than analysing it to figure out why/why-not/how/how-not etc? Gaining insight might actually be more valuable…

Well, D now have a Improvement Proposal system (DIP), the actual visibility of this process can surely improve

I recommend looking at Tcl's TIP system, for inspiration

In my opinion an Improvement Proposal system is a lot better than a roadmap, because you can very clearly see, what the community is talking about, which improvements have implementations, which are just ideas, which are approved which are not, some IP entries takes years to implement

I think as the DIP system matures, it will help D a lot

And dont worry about D, its been around for 16-17 years now, it may never be as big as Python, Ruby or Go

But what is more important that it continues to be developed and improved and ... used

Many languages have small communities and will continue to .. such as Haskell, Idris, OCaml, F#, Clojure, Lisp , Elm  ..

As long as D have a solid, bug free implementation, you have nothing to worry about .. and it doesnt have to be your only language .. honestly it should, now one language should be your only language, I would argue any developer can master 3 to 5 languages at any time ... try to pick ones that dont overlap much

Python, SQl, R, .. D, Dart

On Wednesday, 26 July 2017 at 19:56:01 UTC, Ali wrote:
> .. honestly it should, now one language should be your only language,


DIP 9000, we need a real forum software,
the above is a typo it should read

"honestly it should not
no one language should be your only language"

On Wednesday, 26 July 2017 at 19:56:01 UTC, Ali wrote:
> And dont worry about D, its been around for 16-17 years now, it may never be as big as Python, Ruby or Go
>
> But what is more important that it continues to be developed and improved and ... used

I don't think anyone that don't use D in production worry about it. I simply don't think that many programming languages have any intrinsic value so it doesn't make a whole lot of sense telling people to "improve" on it if they haven't even adopted it (in production).

For some simply understanding the landscape and nature of the evolution of open sourced programming languages (Rust, D etc) have more value than the languages themselves. So yeah, not sticking to any single language makes a lot of sense, they are just tools, means to an end, not goals in themselves and none of the current day languages are worthy of cultist behaviour…

On Wednesday, 26 July 2017 at 20:23:25 UTC, Ola Fosheim Grøstad wrote:
> so it doesn't make a whole lot of sense telling people to "improve" on it if they haven't even adopted it (in production).

My point was improving vs. complaining. Both take some analysis to figure out an issue, but then some people step up and try to help improving things and some just let out their frustration, wondering why noone has been working on that particular oh-so-obvious thing, and possibly drop out, like all the like-minded guys before them.

On Wednesday, 26 July 2017 at 22:18:37 UTC, kinke wrote:
> My point was improving vs. complaining. Both take some analysis to figure out an issue, but then some people step up and try to help improving things and some just let out their frustration, wondering why noone has been working on that particular oh-so-obvious thing, and possibly drop out, like all the like-minded guys before them.

Yeah, providing details about what failed so that others can improve on it if they want to is of course a sensible thing to do, but I think most of such "complaints" could be avoided by being up-front explicit about what a tool does well and what it doesn't do well.

If I use a product and it breaks in an unexpected way I assume that not only that part is broken but that a lot of other parts are broken as well, i.e. I would assume it was alpha quality. And then the provider would be better off by marking it as such.

On Wednesday, 26 July 2017 at 15:55:14 UTC, Wulfklaue wrote:
> On Wednesday, 26 July 2017 at 06:40:22 UTC, Bienlein wrote:
>> D is the most feature rich language I know of. Maybe only Scala comes close, but Scala can be at times an unreadable mess as the designers of the language valued mixing functional and OO higher than readability. D, on the contrary, has a very clean design througout.
>>
>> But you are right. D is missing some unique selling point like ease of concurrency using Communicating Sequential Processes in Go or memory safety in Rust without a GC. This is because D does not have a business model, but seems to be seen as a playground for building the greatest language ever. I fear this will not change. Topics of people arguing that D needs a business case pop up regularly here and are every time mostly or also completely ignored. It does not look like this will change, because the main drivers of the language never drop a comment in those discussions.
>
> I noticed the issues for me is going beyond just the language. Its also productivity.
>
> Not going to hide that i switched to Pascal. There are some features that are needed in my case, where pascal has been kicking D's behind in my personal opinion.
>
> One of those has been frankly community support. Lets say there is a issue in D and one posts about it here. If your lucky, in a few hours there is a response. Then the response can be categorized as:
>
> * Friendly / Useful / Solve issue
> * Useless off-topic responds that does not answer the question but focuses on a complaint and ignores the issue.
> * Semi-aggressive answer that indeed solves the issue but one feels "intimidated"
>
> I have for a long time have a love / hate relationship with D. And the negative feels have  always stemmed from the strange community.
>
> Its not just the Pascal community where i feel better, even in the Rust / Go community people feel like the have more patience or are less judgmental.

I think I understand what you mean. You have to take into account that D is a pure spare time effort. As such it is an incredible language. The Go dev team has at least 5 people working on it full time and have a big big company behind it. Now compare D to Go and you can see how enormous the achievements of the D people are given their endowment situation to the one of the Go team.

To me D is a great language and tool to create things in my spare time. It is also a great toll for university people that work on some research stuff. Developing commercial things with D is a different thing. You can still do this, but then you need to be aware that D cannot have the same rigour as some tool with a big company or a big industry behind it.

On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
> Yes, D's compile-time regex are still the fastest in the world.
>  I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core:
>
> http://benchmarksgame.alioth.debian.org/u64q/regexredux.html
> https://github.com/joakim-noah/regex-bench
>
> D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile.  Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM.

Do you plan to implement a version for the fastest benchmark "n-body" (http://benchmarksgame.alioth.debian.org/u64q/nbody.html) as well?

Adding D to the performance comparison of https://github.com/derekmolloy/exploringBB/tree/master/chp05/performance (companion code to the book "Exploring BeagleBone - Tools and Techniques For Building With Embedded Linux") could be good promotion in the embedded domain (where performance, Linux compatibility and code maintainability matters).

On Saturday, 2 September 2017 at 14:49:30 UTC, thinwybk wrote:
> On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
>> Yes, D's compile-time regex are still the fastest in the world.
>>  I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core:
>>
>> http://benchmarksgame.alioth.debian.org/u64q/regexredux.html
>> https://github.com/joakim-noah/regex-bench
>>
>> D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile.  Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM.
>
> Do you plan to implement a version for the fastest benchmark "n-body" (http://benchmarksgame.alioth.debian.org/u64q/nbody.html) as well?

No, the goal is to demonstrate the nice, super-speedy regex engine in the D standard library by using that same benchmark that Dmitry exhibited years ago, to show D still does really well at regex.  It's not to try and compete across all those benchmarks, which D used to dominate at one time.

I did wonder how D does on that n-body benchmark now, so I built and ran the fastest C++ version, #8, on my single-core linux/x64 VPS.  Here's the source link for each benchmark, the compiler version, and the command I used to build it:

C++:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gpp&id=8

clang/llvm 4.0.1

clang -O3 -std=c++11 nbody.cpp -lm -onbody-cpp

D:
https://bitbucket.org/qznc/d-shootout/raw/898f7f3b3c5d55680229113e973ef95ece6f711a/progs/nbody/nbody.d

ldc 1.4 beta1, llvm 4.0.1

ldc2 -O3 nbody.d

The D version averages 2.5 seconds, the C++ version 6 seconds, which means D would likely still be at the top of that n-body ranking today.

> Adding D to the performance comparison of https://github.com/derekmolloy/exploringBB/tree/master/chp05/performance (companion code to the book "Exploring BeagleBone - Tools and Techniques For Building With Embedded Linux") could be good promotion in the embedded domain (where performance, Linux compatibility and code maintainability matters).

Hmm, I have not used an ARM board in years, my Pandaboard is in storage far away. By including Android/ARM in the regex blog post, hopefully some people will realize D is a good option there.

On Saturday, 2 September 2017 at 15:41:54 UTC, Joakim wrote:
> On Saturday, 2 September 2017 at 14:49:30 UTC, thinwybk wrote:
>> On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
>>> Yes, D's compile-time regex are still the fastest in the world.
>>>  I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core:
>>>
>>> http://benchmarksgame.alioth.debian.org/u64q/regexredux.html
>>> https://github.com/joakim-noah/regex-bench
>>>
>>> D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile.  Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM.
>>
>> Do you plan to implement a version for the fastest benchmark "n-body" (http://benchmarksgame.alioth.debian.org/u64q/nbody.html) as well?
>
> No, the goal is to demonstrate the nice, super-speedy regex engine in the D standard library by using that same benchmark that Dmitry exhibited years ago, to show D still does really well at regex.  It's not to try and compete across all those benchmarks, which D used to dominate at one time.
>
> I did wonder how D does on that n-body benchmark now, so I built and ran the fastest C++ version, #8, on my single-core linux/x64 VPS.  Here's the source link for each benchmark, the compiler version, and the command I used to build it:
>
> C++:
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gpp&id=8
>
> clang/llvm 4.0.1
>
> clang -O3 -std=c++11 nbody.cpp -lm -onbody-cpp
>
> D:
> https://bitbucket.org/qznc/d-shootout/raw/898f7f3b3c5d55680229113e973ef95ece6f711a/progs/nbody/nbody.d
>
> ldc 1.4 beta1, llvm 4.0.1
>
> ldc2 -O3 nbody.d
>
> The D version averages 2.5 seconds, the C++ version 6 seconds, which means D would likely still be at the top of that n-body ranking today.

Sorry, I assumed the D version worked fine and didn't bother to check the output, turns out it needs two foreach loops changed in advance(dt).  Specifically, "Body i" should be changed to "ref Body i" in both foreach statements, so the data is actually updated. ;)

After that change, the C++ version wins by a little, 6 seconds vs. 6.5 seconds for the D translation.  I see that the C++ version directly invokes SIMD intrinsics, so perhaps that's to be expected.

On Saturday, 2 September 2017 at 17:00:46 UTC, Joakim wrote:
> Sorry, I assumed the D version worked fine and didn't bother to check the output, turns out it needs two foreach loops changed in advance(dt).  Specifically, "Body i" should be changed to "ref Body i" in both foreach statements, so the data is actually updated. ;)
>
> After that change, the C++ version wins by a little, 6 seconds vs. 6.5 seconds for the D translation.  I see that the C++ version directly invokes SIMD intrinsics, so perhaps that's to be expected.

W.r.t. to the impact of the languages on code base maintainability, etc. I would consider D the better choice either way :)

(However the domain you are acting in is guiding a decision for or against a programming language to a great extend: available frameworks, development tools, etc.)