www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why Phobos is cool

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
Phobos sometimes gets a bad name around these parts, but actually it's
pretty cool (in spite of well-known warts).  One of the cool things
about it is the batteries-included philosophy that used to be its
guiding principle.  Over the course of my usage of D, the following have
stood out as being particularly convenient when I needed it:

1) std.bigint: one time, I was working on a quadratic irrational
arithmetic module, and pretty quickly discovered that numerical overflow
was a problem that cropped up pretty often.  Or rather, I was seeing
what I *thought* was caused by arithmetic overflow, and wanted to be
sure.  Solution?  Easy: templatize the coefficient type, import
std.bigint, and within several minutes, I have a working implementation
that can support arbitrarily large coefficients -- with which I not only
confirmed that the observed problems were caused by arithmetic overflow,
but also obtained a working solution simultaneously.  Win!

2) std.numeric.poly: another time, I had to work with evaluating a bunch
of polynomials, and specifically, with evaluating their roots quickly
and accurately.  I could roll my own, poorly, and get results that may
or may not be highly-skewed by accumulated errors... or I could use
std.numeric.poly to get a reliable evaluation of the polynomial, and,
better yet, use std.numeric.findRoot to compute roots with the
confidence that the value I get will have as small an error as is
possible within the constraints of built-in hardware floats. Plus, this
saved me tons of development and debugging time to roll my own solution.
Win!

3) Just today, I needed to implement a fast Fourier transform. Not
expecting this to be in Phobos, I was glancing over various algorithms
to decide which one suited my use case best and is easy enough to
implement quickly. And then I discovered std.numeric.Fft, already done
and nicely-packaged and ready to use.  Total win!!

Seriously, D + Phobos is cool beans.  Yes it's not perfect -- the
language has its fair share of dark corners, WATs, and Phobos has its
share of poorly-designed APIs and outdated modules.  But seriously, a
lot of what's currently there is pretty darned cool, and we shouldn't
let all the bad stuff cloud our appreciation of just how cool it already
is.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Jun 24 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 1) std.bigint: one time, I was working on a quadratic 
 irrational arithmetic module, and pretty quickly discovered 
 that numerical overflow was a problem that cropped up pretty 
 often.  Or rather, I was seeing what I *thought* was caused by 
 arithmetic overflow, and wanted to be sure.  Solution?  Easy: 
 templatize the coefficient type, import std.bigint, and within 
 several minutes, I have a working implementation that can 
 support arbitrarily large coefficients -- with which I not only 
 confirmed that the observed problems were caused by arithmetic 
 overflow, but also obtained a working solution simultaneously.  
 Win!

 2) std.numeric.poly: another time, I had to work with 
 evaluating a bunch of polynomials, and specifically, with 
 evaluating their roots quickly and accurately.  I could roll my 
 own, poorly, and get results that may or may not be 
 highly-skewed by accumulated errors... or I could use 
 std.numeric.poly to get a reliable evaluation of the 
 polynomial, and, better yet, use std.numeric.findRoot to 
 compute roots with the confidence that the value I get will 
 have as small an error as is possible within the constraints of 
 built-in hardware floats. Plus, this saved me tons of 
 development and debugging time to roll my own solution. Win!

 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!

 Seriously, D + Phobos is cool beans.  Yes it's not perfect -- 
 the language has its fair share of dark corners, WATs, and 
 Phobos has its share of poorly-designed APIs and outdated 
 modules.  But seriously, a lot of what's currently there is 
 pretty darned cool, and we shouldn't let all the bad stuff 
 cloud our appreciation of just how cool it already is.


 T
I suggest checking http://mir-algorithm.libmir.org/. Ilya has been doing a truly amazing job at both developing, maintaining and optimizing this library. Also he has put a hard focus on memory allocators, nogc and betterC (for exposing libmir to C and C++ users and also for scripting languages like Python or Julia). AFAIK his work has been sponsored by Symmetry, so I suppose libmir gets a lot of internal use there. Meanwhile, if you look at std.numeric, for past several years, basically all contributions but a few have been just around basic stuff like code style, imports and fixing a few compile errors in generic code. Phobos is dead. There haven't been any new modules since ~2016. Actually the last one (IIRC) was std.experimental.ndslice, which Ilya contributed and then removed (1-2 releases after) from Phobos to start libmir. Since std.experimental.allocator was added to Phobos circa 2015, there hasn't been a single Phobos or Druntime module using it (ndslice and checkedint don't count). Many packages on code.dlang.org enthusiastically embraced std.experimental.allocator only to get burned a few dmd releases after as Phobos doesn't follow SemVer. The solution? Many of the most popular OSS D apps libraries (I can only comment on those) transitioned to using the Dub fork: https://github.com/dlang-community/stdx-allocator. How does it help? Well, OSS D libraries can't control the compiler that their users are using. For example, vibe.d tries to support the last 5 major versions of dmd/ldc, and Dub the last 15+ major versions. This means they can't depend on std.experimental.* as there's no telling what kind changes can happen for such a large timespan. Instead they can stick a particular version of https://code.dlang.org/packages/stdx-allocator in their dub.{json,sdl} file and be sure that it won't suddenly break their code. The sooner we realize this and start collectively working on improving Dub and code.dlang.org, the better. Yes, Dub is not a great build tool. And so what? Most great build tools were not so great in their infancy. I doubt Scons was much better in 1999. If people continue avoiding Dub for whatever reason it won't get better by itself. There's no reason why Dub can't expose a lower-level DSL for precise target dependency graph building. It's just a matter of people making a sustained effort in contributing one. The Rust community has realized that a slim standard library + a solid package manager is the way to go. Rust is also backed by Mozilla. And so what? I seriously doubt that more than 5-10% of all of the 42k packages on https://crates.io/ were created by Mozilla employees. Instead the core Rust team realized that they can't build everything by themselves, and focused on helping the community scale by putting a concentrated effort on Cargo (their version of Dub).
Jun 24 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:
 The sooner we realize this and start collectively working on 
 improving Dub and code.dlang.org, the better.
FYI for anyone interested, this has been a topic of discussion at the past two quarterly foundation meetings. We have outlined a path forward, but we just need to secure funding. We're currently awaiting news on that front. Whether the news is good or bad, I'll be able to announce the plans shortly after I hear it. If it's bad news, we'll likely have to seed the initiative with the HR fund and depend on the community to keep it going long-term until we get an alternative solution. I'm hopeful it won't come to that.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 09:08:37 UTC, Mike Parker wrote:
 On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
 [ZombineDev] wrote:
 The sooner we realize this and start collectively working on 
 improving Dub and code.dlang.org, the better.
FYI for anyone interested, this has been a topic of discussion at the past two quarterly foundation meetings. We have outlined a path forward, but we just need to secure funding. We're currently awaiting news on that front. Whether the news is good or bad, I'll be able to announce the plans shortly after I hear it. If it's bad news, we'll likely have to seed the initiative with the HR fund and depend on the community to keep it going long-term until we get an alternative solution. I'm hopeful it won't come to that.
Thank you for the update Mike, I appreciate it. I think even the fact that this has been the topic of discussion for the those meetings is a good news in itself! I haven't been able to contribute to D in the past 1-2 years as I would like to, but before that, at some point, I was in the top 3 people in terms of number of pull request code reviews, so back then I had very good visibility of the how things were going. I'm currently the CTO of a small startup, and needless to say, I'd very much like our team to use D for more things, but the biggest blockers for us is that the competition (Rust, Go, TypeScript) has much better developed ecosystem. Strangely for many, IDE support is not important for us. (And especially given D's metaprogramming capabilities, I haven't had high expectations anyway :D) Most of the libraries that we need will never be part of Phobos. If the third-party library & package ecossytem doesn't catch up with Rust or Nim, using D is just not going to be practical for the core of our business.
Jun 25 2020
prev sibling next sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:
 Since std.experimental.allocator was added to Phobos circa 
 2015, there hasn't been a single Phobos or Druntime module 
 using it (ndslice and checkedint don't count). Many packages on 
 code.dlang.org enthusiastically embraced 
 std.experimental.allocator only to get burned a few dmd 
 releases after as Phobos doesn't follow SemVer. The solution? 
 Many of the most popular OSS D apps libraries (I can only 
 comment on those) transitioned to using the Dub fork: 
 https://github.com/dlang-community/stdx-allocator. How does it 
 help? Well, OSS D libraries can't control the compiler that 
 their users are using. For example, vibe.d tries to support the 
 last 5 major versions of dmd/ldc, and Dub the last 15+ major 
 versions. This means they can't depend on std.experimental.* as 
 there's no telling what kind changes can happen for such a 
 large timespan. Instead they can stick a particular version of 
 https://code.dlang.org/packages/stdx-allocator in their 
 dub.{json,sdl} file and be sure that it won't suddenly break 
 their code.
This gets brought up quite often. Breaking changes doesn't seem to be a concern. I'm not even talking about the DIP changes that are going to cause breaking changes. There's just compiler changes that break codes for almost every new release. There doesn't even need to be a big change, just slowing down the releases would help. So there's less versions you have to deal with to support a longer term of time.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 11:09:04 UTC, Avrina wrote:
 This gets brought up quite often. Breaking changes doesn't seem 
 to be a concern. I'm not even talking about the DIP changes 
 that are going to cause breaking changes. There's just compiler 
 changes that break codes for almost every new release. There 
 doesn't even need to be a big change, just slowing down the 
 releases would help. So there's less versions you have to deal 
 with to support a longer term of time.
Breaking changes are not a problem. As someone who was very involved in pull request reviews in the past, I can definitely say that outside of std.experimental, for the past few years we have been relatively rigorous (compared to say 5 years ago), and almost every breaking change that we were aware has first gone through a deprecation process. So breaking changes are not a problem by themselves. The problem is how they're delivered. The problem is that Phobos is distributed as part of each compiler release. You can't keep using an older version of Phobos if you need the new platform support of say LDC 1.22.0. And vice versa, if you need a new Phobos function, but there's a compiler bug preventing you from upgrading you're again stuck between a rock and a hard place. And what frustrates me the most is that this is an already solved problem technically, it's just that the community doesn't want to reach consensus on using and investing in improving Dub. Today, in all of our projects at work, the version of TypeScript that we used is managed by SemVer. The version of all our dependencies is also managed by SemVer. If I want to use the latest language features of TypeScript, I'm not afraid to upgrade it, as each of my dependencies can use whatever TS version they want (again following SemVer), and so on.
Jun 25 2020
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
 [...]
I suggest checking http://mir-algorithm.libmir.org/. Ilya has been doing a truly amazing job at both developing, maintaining and optimizing this library. Also he has put a hard focus on memory allocators, nogc and betterC (for exposing libmir to C and C++ users and also for scripting languages like Python or Julia). AFAIK his work has been sponsored by Symmetry, so I suppose libmir gets a lot of internal use there. [...]
I know that we are quite few on this side, but IMHO a well shaped standard library has advantages over a sparse ecosystem of independent library ... Anyway, if we can, we try to stick with Phobos, as long as we don't have a particular problem to solve that needs an external library: recent example, Martin std.io or SumType instead of std.variant ...
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi wrote:
 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...
Who says that this is a binary choice? And also, the way you fraise it it's obvious that say Flutter is better choice than React as everything is very tightly integrated and you could build your whole app without reaching for third-party code. Also, it's obvious that in terms of trust, it's better to rely on the diligence of the upsteam development team, than random strangers from the internet. But what if 90% of the code my team needs has no place in Phobos? We already have to rely heavily on third-party packages. Yes there are a lot of risks and we try to be careful, but we have no other choice. We could spend years reiventing the wheel (high-quality code that already exists in other languages), or we could focus on delivering products to our users based on the already existing ecosystem in other languages. Well, a choice would exist if we had an unlimited budget, but given that we're not as lucky, we can only use other languages for our projects currently. Technically, phobos is actually already on Dub (https://code.dlang.org/packages/phobos), so in the future nothing could prevent you to continue using it, but you would just get it from there and not from the compiler distribution archive. It's the same code, made by the same people, just with a different distribution model. The way I see things is that we as a community need to focus on a vetted, well shaped collection of libraries. We need to have process where third-party libraries are able to gain broader support and join dlang-community. Also we need dlang-community to have a healthy number of people who actually maintain the code. We need the leadership to realize that investing just in dmd, druntime and phobos is necessary, but very insufficient. W&A need to stop pretending that Dub doesn't exist. I feel that unless we embrace using code.dlang.org as method of distribution of everything that's currently part of the compiler archive, Dub's limitations will never be addressed and from that the broader community will suffer.
 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an external 
 library: recent example, Martin std.io or SumType instead of 
 std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
Jun 25 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:
 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just with 
 a different distribution model.
Aside: it seems like Dub is not properly picking up the tagged releases, and only has '~master' and '~stable' available. Fixing this would make using Phobos via dub a much more attractive proposition.
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:14:21 UTC, Paul Backus wrote:
 On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
 [ZombineDev] wrote:
 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just 
 with a different distribution model.
Aside: it seems like Dub is not properly picking up the tagged releases, and only has '~master' and '~stable' available. Fixing this would make using Phobos via dub a much more attractive proposition.
I agree, this would at least allow people pick an exact version. (Of course, given that Phobos doesn't follow SemVer, every minor release (2.xx.0) could introduce a breaking change - a symbol being removed after the 2 year deprecation period.) But still, the next major problem to solve is actually ensuring that each Phobos release works with several different compiler releases, which as far as I can see is not going to happen anytime soon.
Jun 25 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 16:23:11 UTC, Petar Kirov 
[ZombineDev] wrote:
 [snip]

 I agree, this would at least allow people pick an exact 
 version. (Of course, given that Phobos doesn't follow SemVer, 
 every minor release (2.xx.0) could introduce a breaking change 
 - a symbol being removed after the 2 year deprecation period.)

 But still, the next major problem to solve is actually ensuring 
 that each Phobos release works with several different compiler 
 releases, which as far as I can see is not going to happen 
 anytime soon.
File bugzilla issue?
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 17:11:58 UTC, jmh530 wrote:
 On Thursday, 25 June 2020 at 16:23:11 UTC, Petar Kirov 
 [ZombineDev] wrote:
 [snip]

 I agree, this would at least allow people pick an exact 
 version. (Of course, given that Phobos doesn't follow SemVer, 
 every minor release (2.xx.0) could introduce a breaking change 
 - a symbol being removed after the 2 year deprecation period.)

 But still, the next major problem to solve is actually 
 ensuring that each Phobos release works with several different 
 compiler releases, which as far as I can see is not going to 
 happen anytime soon.
File bugzilla issue?
https://github.com/dlang/projects would be more appropriate, so if other people see value in this, I hope they will post there (I'm running out of time to continue this long topic atm).
Jun 25 2020
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 18:25:47 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Thursday, 25 June 2020 at 17:11:58 UTC, jmh530 wrote:
 [snip]

 File bugzilla issue?
https://github.com/dlang/projects would be more appropriate, so if other people see value in this, I hope they will post there (I'm running out of time to continue this long topic atm).
I filed one here https://issues.dlang.org/show_bug.cgi?id=20977 anyone is free to improve it and add to projects.
Jun 25 2020
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi 
 wrote:
 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...
Who says that this is a binary choice? And also, the way you fraise it it's obvious that say Flutter is better choice than React as everything is very tightly integrated and you could build your whole app without reaching for third-party code. Also, it's obvious that in terms of trust, it's better to rely on the diligence of the upsteam development team, than random strangers from the internet. But what if 90% of the code my team needs has no place in Phobos? We already have to rely heavily on third-party packages. Yes there are a lot of risks and we try to be careful, but we have no other choice. We could spend years reiventing the wheel (high-quality code that already exists in other languages), or we could focus on delivering products to our users based on the already existing ecosystem in other languages. Well, a choice would exist if we had an unlimited budget, but given that we're not as lucky, we can only use other languages for our projects currently. Technically, phobos is actually already on Dub (https://code.dlang.org/packages/phobos), so in the future nothing could prevent you to continue using it, but you would just get it from there and not from the compiler distribution archive. It's the same code, made by the same people, just with a different distribution model. The way I see things is that we as a community need to focus on a vetted, well shaped collection of libraries. We need to have process where third-party libraries are able to gain broader support and join dlang-community. Also we need dlang-community to have a healthy number of people who actually maintain the code. We need the leadership to realize that investing just in dmd, druntime and phobos is necessary, but very insufficient. W&A need to stop pretending that Dub doesn't exist. I feel that unless we embrace using code.dlang.org as method of distribution of everything that's currently part of the compiler archive, Dub's limitations will never be addressed and from that the broader community will suffer.
I understand your point of view and what you are trying to say. In my opinion it's a chicken and egg problem, IMHO. My question is: why 90% of the code you need is not in Phobos, and why is Phobos stagnating? In the just released beta of DMD, there are zero Phobos references in the changelog ...
 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
It's not only a problem of trust, it's a problem of integration and maintenance also: for example, some days ago I tried to use Martin and Steven std.io with std.concurrency, and I faced a wall of problems related to non copiable struct, variants, reference counting implementation, and so on ... I know that there're advantages in flexibility, but there are costs also, for example, not everyone scouting for DLang as a candidate for a task has your (great!) experience in managing all the sort of problems that arises when trying to combine different packages, or has the experience (or the time?) to choose the "golden" one. Anyway, you are right, it's not a binary choice. /P
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:33:18 UTC, Paolo Invernizzi wrote:
 [snip]

 I understand your point of view and what you are trying to say. 
 In my opinion it's a chicken and egg problem, IMHO.
Yes, that's a fair assessment.
 My question is: why 90% of the code you need is not in Phobos,
I can go in more detail later, but let's just say that Phobos is a generic library aiming to solve general use-cases of most/all language users. In many domains, such as mine that's less than 5% of what I need, the rest is really domain-specific. And obviously there are more domain-specific libraries in other more popular languages. Also, Phobos is very poor in terms of general application-level programming. Unlike e.g. Node.js or Flutter, it's neither sufficient for frontend (web/mobile/desktop) nor backend programming.
 and why is Phobos stagnating?
Several related reasons from the top of my head: 1. People are simply not interested in contributing (anymore). A few hypothetical examples (I/me == random contributor): 1.a. As an individual developer I write code for fun, so I don't find value in going through the difficult (as it should be) process of proposing my code for std and passing through code reviews. 1.b. As an organization, we like to contribute to the community, and publishing on GitHub/GitLab/etc. + code.dlang.org is mutually beneficial: Other community members or companies can find value in what we do and can reports bugs and contribute improvements. However, contributing to Phobos takes just too long and also limits the potential number of contributors. Also we don't control the code anymore. So in general it's hard to justify from a business point of view. 1.c. (I guess that would be a fair approximation of the ndslice case): I'm a highly motivated individual who wants to contribute a foundational piece to the standard library, the positive effects of which would permeate throughout the ecosystem. Few problems: - I want to support older/newer GDC/LDC versions (a few years ago that wasn't at all possible for upstream phobos) - It's a nice start, but actually the reason I made this contribution is so I can advance in my domain (e.g. scientific computing, fintech, whatever), so now I need to to write domain specific libraries. Well actually, to support those libraries I need to make changes to the API. Well I can't do that easily anymore as I don't own the code and breaking changes are not well supported in Phobos (no SemVer). I also want betterC support, so I need to vendor (fork and rewrite) parts of druntime. The changes are good enough for me, but they can't be accepted upstream. And so my library now has non-Phobos dependencies, and so obviously it can't be part of Phobos. 1.d. I work on a security-sensitive library (e.g. crypto). I need to follow a responsible security vulnerability disclosure policy. Also when I have fixed the issue, and the changes are audited, I need to push a new release ASAP. A new compiler release (even point/bugfix one) typically has a latency of at least 1 month. It can contain also other unrelated breaking changes. 2. Failure to cultivate and *****retain***** community talent. By community talent I mean contributors who are *not* paid. E.g. Dicebot, JinShil, berni, Kenji, Joakim, and so on. Yeah, each case has its specifics, but if people with contributions of their caliber were to leave my company, I would be seriously worried and losing sleep (and selling stonks :D) For example, not until recently (let's say 2017/2018), if a newcomer were to look at this page: https://github.com/dlang/dmd/graphs/contributors they would conclude that dmd was Kenji and Walter's project (and not Walter + contributors), as Kenji had substantially bigger number of commits than Walter at that point of time.
 In the just released beta of DMD, there are zero Phobos 
 references in the changelog ...
Well, this varies with each release, but outside of bug fixes, refactoring or otherwise improvements to existing code and addition of fundamental vocabulary types (e.g. SumType), what exactly do you expect to see? Can you list exactly what kinds of contributions would you expect to see from non-paid volunteers? And I don't mean to say "non-paid" in a bad way regarding DLF. I mean that people who work for free are usually even more self-motivated then paid contributors. Why would anyone want to put new modules in Phobos, where they can develop them much faster in the open? Also, contributing to the compiler and runtime has a much higher value than Phobos, especially given how easy and beneficial in many cases it is to replace Phobos with a code.dlang.org package. Additionally, most of the code in dmd/druntime is internal and it's much easier to change than Phobos, which for the most part is comprised of public functions. In the compiler and the runtime you can make huge changes without breaking backwards compatibility at all.
 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
It's not only a problem of trust, it's a problem of integration and maintenance also: for example, some days ago I tried to use Martin and Steven std.io with std.concurrency, and I faced a wall of problems related to non copiable struct, variants, reference counting implementation, and so on ...
By trust, I also meant compatibility and general dependability. For example, in the frontend world, even though Redux and React are developed by different teams (there's overlap but still), I feel like an illuminati apocalypse would be a more likely event than Redux somehow breaking React.js compatibility or vice versa :D In the case of Steven and Martin's libraries, they're both pretty cool guys, whom I've met and chatted with at DConf, so I trust them as people, but they're both pretty busy these days (just my casual observation from GitHub and the forums), so I can't "trust" these libraries for critical stuff, as they don't have a high enough number of contributors who could take the lead in case Martin or Steven are not there. I really hope we can improve as a community in this regard.
 I know that there're advantages in flexibility, but there are 
 costs also, for example, not everyone scouting for DLang as a 
 candidate for a task has your (great!) experience in managing 
 all the sort of problems that arises when trying to combine 
 different packages, or has the experience (or the time?) to 
 choose the "golden" one.

 Anyway, you are right, it's not a binary choice.

 /P
Yeah, flexibility almost always brings complexity (e.g. generic code can be easy to write, but sometimes it can be complex to debug). Really, what I mean is that we need to create a carefully curated collection of packages that work together and are maintained by a good number of qualified people. That's kind of the idea of dlang-community, but with a single large project like DCD in it (and its dependencies), it kind of twists the balance of contributions towards DCD. There's also the vibe-d and libmir organizations. However, we lack a broader collaboration and cooperation between them.
 managing all the sort of problems that arises when trying to 
 combine different packages
P.S. That is actually full-time job in the npm world :D But it actually makes a lot of sense from business point of view. Nowadays, no company, no matter how huge could build in-house all that already exists (and is of high-quality) in the open-source world. It's cheaper to spend one week choosing 1 library from 100+ then spending a few months to create another one that solves the same problem. Especially if your in-house developers need to move on a different project and then no one could maintain your in-house creation. ---- These are all really difficult problems to solve, but solving them can potentially create the biggest value of the community. Just like the Nodejs codebase represents <<<< 0.01% of the code of the whole npmjs ecosystem, the D language spec, dmd, druntime, phobos and the tools are absolutely foundational and critical, but would still represent a small fraction of the total value that our community can create. We now need to focus on scaling the bigger part of the pie.
Jun 25 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:
 The way I see things is that we as a community need to focus on a 
 vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able to gain 
 broader support and join dlang-community. Also we need dlang-community 
 to have a healthy number of people who actually maintain the code.
 We need the leadership to realize that investing just in dmd, druntime 
 and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that unless 
 we embrace using code.dlang.org as method of distribution of everything 
 that's currently part of the compiler archive, Dub's limitations will 
 never be addressed and from that the broader community will suffer.
(By the way just to clarify "A" in "W&A" would stand for Atila. I'm commenting as just one in the community.) I'm a bit confused by this argument. So there is the compiler and standard library, and then there's a community-supported library, which includes a copy of the standard library under an improved versioning schema. It's all legal and encouraged by the generous licensing of the compiler and standard library, both of which Walter and I fought hard in the past to obtain and maintain. Dub is the perfect place where community leadership can set the tone and organized things as they need to without heavy-handed intervention from above. Several people have criticized "the leadership" for not doing things the way they wanted, so it seems perplexing that leadership intervention is now asked for. What's that nonsense with "pretending dub doesn't exist"? So now they need to take ownership of the community-driven dub as well? Isn't that a bit too much work for a handful of folks in the best of times? Is money that's been asked for? We don't have enough to do competitive hiring. I don't think Bjarne or Herb have ever been accused of not contributing to Boost (which they didn't), or asked to invest in it. Boost has been a community-led effort which has had a great influence on C++ development - with the participation of volunteers, not the formal standards committee.
 Anyway, if we can, we try to stick with Phobos, as long as we don't 
 have a particular problem to solve that needs an external library: 
 recent example, Martin std.io or SumType instead of std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
This is and will always be the case, and it's normal. A standard library can't implement all special purpose libraries, or even a significant fraction. A community-led library is a great thing.
Jun 25 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 16:25:01 UTC, Andrei Alexandrescu 
wrote:
 On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:
 The way I see things is that we as a community need to focus 
 on a vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able 
 to gain broader support and join dlang-community. Also we need 
 dlang-community to have a healthy number of people who 
 actually maintain the code.
 We need the leadership to realize that investing just in dmd, 
 druntime and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel 
 that unless we embrace using code.dlang.org as method of 
 distribution of everything that's currently part of the 
 compiler archive, Dub's limitations will never be addressed 
 and from that the broader community will suffer.
(By the way just to clarify "A" in "W&A" would stand for Atila. I'm commenting as just one in the community.)
Hi Andrei, well, I meant Walter and you during 2015-2019, though just to be clear, I neither wish, nor it was my intension to turn this discussion into a personal attack. My goal is to stress how important it is to focus on helping the community grow and scale in a healthy way. Focusing just on the language spec and implementation is missing the bigger picture, IMO. But since you decided to address specifically this point, I'll try to elaborate more: I don't recall you or Walter getting involved with the development of dub or the dub-registry in any significant manner. I remember that you criticized the addition of SDLang as an alternative to JSON package description format, but that's it. I feel there is a very big disconnect between you and the community. One on hand, I think that Dub and code.dlang.org are one of the biggest assets of the community. On the other hand, it seems to me that you're not interested in Dub at all. It's just another community project that "they"'re free to do whatever they want it. For example, my impression (though I'd be happy to be wrong), is that you have never actually tried using Dub for any project of significant size, or such depending on a significant proportion of code that you don't maintain. On the other side, take as an example any company that needs to bring a D web project quickly to market. The first thing they'll likely reach for is dub + vibe-d + mysql-native + some js frontend framework - basically 100% third-party code for that team. Since (as far as I'm aware) you haven't invested much time in projects like this, I'd guess that it would be hard for you to fully appreciate the necessity, challenges, and benefits of using a package manager like Dub. Which is why, to me it seems that Dub is not very high on your radar of important things to improve for to D succeed. Different people having different priorities is absolutely normal but on the other hand, if hypothetically most people using D type `dub` in their terminal say 99% of their time compared to 1% for `dmd`, perhaps it's not unreasonable for the community to expect the leadership to take a Dub's issues in a proportional manner. Or at least the community would find it strange that the keywords code.dlang.org or Dub were not mentioned even once in the vision documents, e.g. https://wiki.dlang.org/Vision/2018H1. Yeah, "tooling" is mentioned, but honestly, that too unspecific to be actionable. On a related topic, "mobile" and "wasm" also not mentioned, which areas where D in theory could do very well, and its direct competitors are rapidly gaining market share.
 I'm a bit confused by this argument. So there is the compiler 
 and standard library, and then there's a community-supported 
 library, which includes a copy of the standard library under an 
 improved versioning schema. It's all legal and encouraged by 
 the generous licensing of the compiler and standard library, 
 both of which Walter and I fought hard in the past to obtain 
 and maintain.
Okay... though I don't see why you need to point this out. Yes, getting dmd fully Boost-licensed was a great achievement, and I and the rest of community are all grateful for that, though we're currently discussing about Phobos. I have never used a language which doesn't have an open-source and permissively-licensed standard-library.
 Dub is the perfect place where community leadership can set the 
 tone and organized things as they need to without heavy-handed 
 intervention from above. Several people have criticized "the 
 leadership" for not doing things the way they wanted, so it 
 seems perplexing that leadership intervention is now asked for. 
 What's that nonsense with "pretending dub doesn't exist"? So 
 now they need to take ownership of the community-driven dub as 
 well? Isn't that a bit too much work for a handful of folks in 
 the best of times?

 Is money that's been asked for? We don't have enough to do 
 competitive hiring.
No, money is not what's been asked for. For me, the most straightforward way to look at things is as if the DLF doesn't exist and there's no money on the table in the first place. (Also funding can only reward future contritions, so in a sense, it's not fair to past contributions.) So what's left (in this way of looking at things) is just individuals motivated for whatever non-financial reasons (at least not direct ones) who are working to improve D. It follows that motivated, talented people who effectively collaborate and cooperate are the primary asset of the community. The job of the "community leadership" would then be to attract, cultivate, and **retain** community talent and endorse collaboration. If funding is not an asset, then the only remaining leverage is good community management.
 I don't think Bjarne or Herb have ever been accused of not 
 contributing to Boost (which they didn't), or asked to invest 
 in it. Boost has been a community-led effort which has had a 
 great influence on C++ development - with the participation of 
 volunteers, not the formal standards committee.
We can only compare D to C++ on technical merits. The size of their community is just in a very different scale to ours. For example, I work in a startup where everyone needs to wear many hats and handle a very diverse set of responsibilities. We have more projects than people. Previously, I've worked at Fortune Top 10 software company with 20k+ employees. Needless to say, the scale is very different. Instead, we should compare D to language communities developed in the past 10-15 years. I suggest you look around and see how each one is doing and what were the different steps they took. I can assure you that probably all of their leaders at some points have been accused of not paying enough attention to this or that thing important to some part of the community. That's normal. Leading a small community or organization is very different than leading a big one.
 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
This is and will always be the case, and it's normal. A standard library can't implement all special purpose libraries, or even a significant fraction. A community-led library is a great thing.
I agree completely. I was not trying to argue the other way around. I think Phobos needs to be slimmer (e.g. throw away curl, odbc and other nonsense). For example, the only languages that have good built-in networking/HTTP libraries are the ones where this has been an explicit goal of the maintainers. Right now we don't have sufficient Phobos maintainers with the experience and interest in building a GUI framework, so nothing like this should even be attempted to be added to Phobos. A library should only try to do what its maintainers are good at. In the case of Phobos that would be generic code like algorithms, ranges, allocators, containers, typecons, meta programming, process, path and file manipulation and basic IO. Everything else should be removed. I'm glad that https://dlang.org/phobos/std_xml is finally going away, as probably only Jonathan has real experience of building an XML library (hence dxml). Though that should have happened much sooner.
Jun 25 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/25/20 5:51 PM, Petar Kirov [ZombineDev] wrote:
 I don't recall you or Walter getting involved with the development of 
 dub or the dub-registry in any significant manner. I remember that you 
 criticized the addition of SDLang as an alternative to JSON package 
 description format, but that's it.
 
 I feel there is a very big disconnect between you and the community. One 
 on hand, I think that Dub and code.dlang.org are one of the biggest 
 assets of the community. On the other hand, it seems to me that you're 
 not interested in Dub at all. It's just another community project that 
 "they"'re free to do whatever they want it.
 For example, my impression (though I'd be happy to be wrong), is that 
 you have never actually tried using Dub for any project of significant 
 size, or such depending on a significant proportion of code that you 
 don't maintain. On the other side, take as an example any company that 
 needs to bring a D web project quickly to market. The first thing 
 they'll likely reach for is dub + vibe-d + mysql-native + some js 
 frontend framework - basically 100% third-party code for that team. 
 Since (as far as I'm aware) you haven't invested much time in projects 
 like this, I'd guess that it would be hard for you to fully appreciate 
 the necessity, challenges, and benefits of using a package manager like 
 Dub. Which is why, to me it seems that Dub is not very high on your 
 radar of important things to improve for to D succeed.
 
 Different people having different priorities is absolutely normal but on 
 the other hand, if hypothetically most people using D type `dub` in 
 their terminal say 99% of their time compared to 1% for `dmd`, perhaps 
 it's not unreasonable for the community to expect the leadership to take 
 a Dub's issues in a proportional manner. Or at least the community would 
 find it strange that the keywords code.dlang.org or Dub were not 
 mentioned even once in the vision documents, e.g. 
 https://wiki.dlang.org/Vision/2018H1. Yeah, "tooling" is mentioned, but 
 honestly, that too unspecific to be actionable. On a related topic, 
 "mobile" and "wasm" also not mentioned, which areas where D in theory 
 could do very well, and its direct competitors are rapidly gaining 
 market share.
Cool cool cool. (Kind of funny you frame lack of involvement in dub as something to be ashamed of, like having cheated. I'll level with you: I'm just a casual dub user.) So as far as I understand the argument goes "Whatever you've worked on, that was missing the point because you should have worked on dub instead, which was way more important." From a very simple teleological viewpoint, you're entirely right: if D isn't mainstream, clearly there is something we didn't do right. As such, all paths not taken are very attractive. What if we put all that effort in dub? Or an IDE? Or a killer application written in D? No shortage of paths not taken. You seem to believe that dub is the most important, but over the years there have been many ideas from many people about what is the most important. From where you stand dub would be the thing to focus on, but for years Walter and I have been fighting huge quality problems that now seem to be forgotten. Those would preclude any application work. dmd was be unable to compile anything beyond the most trivial examples of its own flagship features - for years! And when it got it right, phobos got something wrong. It does seem the presence of a package manager is a contributor to success. Some languages swear by it (Python/pip, Rust/cargo, Haskell/cabal). Yet some others are successful without an official one (Java, C, C++, PHP); and yet others aren't doing well in spite of having a good one (Perl/cpan). So it's not quite the foregone conclusion. Other people would say that an IDE is the thing, and I have been repeatedly asked to work on one. I'm sure those asking were as convinced about the importance of an IDE, as you are about the importance of dub. The simple fact is I'm not an expert in package management or IDEs. I could probably learn how to do it, but it's unlikely he result would be anywhere close to world-class. In the meantime, I did think I could do a decent job at writing a standard library and helping with the language definition and there was an obvious necessity for those, too. The main problem with the argument "why didn't you work more on X, when clearly X would have made the D language more successful than working on your core expertise Y" is... there's something wrong with it. Whatever the problem is, the solution can't be let's have fewer people do more work. It doesn't scale.
 Instead, we should compare D to language communities developed in the 
 past 10-15 years. I suggest you look around and see how each one is 
 doing and what were the different steps they took. I can assure you that 
 probably all of their leaders at some points have been accused of not 
 paying enough attention to this or that thing important to some part of 
 the community. That's normal. Leading a small community or organization 
 is very different than leading a big one.
Yes, that's a good point. It is self-evident to me that I have not been a good leader, which is part of why I bowed out. All the paths not taken; surely one of them must have been better. I totally agree we didn't find the right sauce (how could I disagree? D doesn't have a million users). I think something endemic to our community is a certain thorniness, in most likelihood caused by its leadership (it always starts from the leadership) and slow mainstream adoption. Never in my life have I thrown so much work at such an unending pit of hostility. Years and years of my life, and some of my best work ever. Hundreds of thousands of lines written. Many more reviewed, to be fought tooth and nail by people whom I was just trying to help improve. The contrast is fascinating, because many companies are ready to pay handily for the very same thing, and the C++ community has always been happy with much less significant work. I was never able to explain this all to myself. But clearly there's something wrong about it. We seem to be dealing in some counterfeit expertise currency. To this day, many moons after I stepped aside, there's no week going by without somebody in this forum putting the poop on something I've done, or teaching me how I should have done it. We could use more kindness around here. Look at the title of this thread. "Why Phobos is cool." Someone found something he liked in Phobos. I knew as soon as I saw the title a poopfest was going to inevitably follow. Let the man have his day.
Jun 25 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:
 On 6/25/20 5:51 PM, Petar Kirov [ZombineDev] wrote:
 I don't recall you or Walter getting involved with the 
 development of dub or the dub-registry in any significant 
 manner. I remember that you criticized the addition of SDLang 
 as an alternative to JSON package description format, but 
 that's it.
 
 I feel there is a very big disconnect between you and the 
 community. One on hand, I think that Dub and code.dlang.org 
 are one of the biggest assets of the community. On the other 
 hand, it seems to me that you're not interested in Dub at all. 
 It's just another community project that "they"'re free to do 
 whatever they want it.
 For example, my impression (though I'd be happy to be wrong), 
 is that you have never actually tried using Dub for any 
 project of significant size, or such depending on a 
 significant proportion of code that you don't maintain. On the 
 other side, take as an example any company that needs to bring 
 a D web project quickly to market. The first thing they'll 
 likely reach for is dub + vibe-d + mysql-native + some js 
 frontend framework - basically 100% third-party code for that 
 team. Since (as far as I'm aware) you haven't invested much 
 time in projects like this, I'd guess that it would be hard 
 for you to fully appreciate the necessity, challenges, and 
 benefits of using a package manager like Dub. Which is why, to 
 me it seems that Dub is not very high on your radar of 
 important things to improve for to D succeed.
 
 Different people having different priorities is absolutely 
 normal but on the other hand, if hypothetically most people 
 using D type `dub` in their terminal say 99% of their time 
 compared to 1% for `dmd`, perhaps it's not unreasonable for 
 the community to expect the leadership to take a Dub's issues 
 in a proportional manner. Or at least the community would find 
 it strange that the keywords code.dlang.org or Dub were not 
 mentioned even once in the vision documents, e.g. 
 https://wiki.dlang.org/Vision/2018H1. Yeah, "tooling" is 
 mentioned, but honestly, that too unspecific to be actionable. 
 On a related topic, "mobile" and "wasm" also not mentioned, 
 which areas where D in theory could do very well, and its 
 direct competitors are rapidly gaining market share.
Cool cool cool. (Kind of funny you frame lack of involvement in dub as something to be ashamed of, like having cheated. I'll level with you: I'm just a casual dub user.) So as far as I understand the argument goes "Whatever you've worked on, that was missing the point because you should have worked on dub instead, which was way more important."
I would say its not about the MOST, it doesn't always have to be the most but one could say without any direct mention of Dub or mobile, dub especially, it calls into question how that document is compiled. For example is there a community wide survey or anything to see which issues are most desired to be tackled. It doesn't have to be all but at least help get a couple these addressed. Especially dub.
From a very simple
 teleological viewpoint, you're entirely right: if D isn't 
 mainstream,
Right now its about getting D to improve for users. Not potential users per se. Phobos is great for what it doesn't but what it doesn't, dub needs to be a stronghold.
clearly there is something we didn't do right. As
 such, all paths not taken are very attractive. What if we put 
 all that effort in dub? Or an IDE? Or a killer application 
 written in D? No shortage of paths not taken. You seem to 
 believe that dub is the most important, but over the years 
 there have been many ideas from many people about what is the 
 most important.

 From where you stand dub would be the thing to focus on, but 
 for years Walter and I have been fighting huge quality problems 
 that now seem to be forgotten. Those would preclude any 
 application work. dmd was be unable to compile anything beyond 
 the most trivial examples of its own flagship features - for 
 years! And when it got it right, phobos got something wrong.

 It does seem the presence of a package manager is a contributor 
 to success. Some languages swear by it (Python/pip, Rust/cargo, 
 Haskell/cabal). Yet some others are successful without an 
 official one (Java, C, C++, PHP); and yet others aren't doing 
 well in spite of having a good one (Perl/cpan). So it's not 
 quite the foregone conclusion.
All those languages succeeded, because they found themselves in a advantageous point in time. So people could put up with it despite its shortfalls. This could mean it was also immediately interesting to many people (contributors) and companies at that time. Do you really think any new language now can succeed without a package repository?
 Other people would say that an IDE is the thing, and I have 
 been repeatedly asked to work on one. I'm sure those asking 
 were as convinced about the importance of an IDE, as you are 
 about the importance of dub.

 The simple fact is I'm not an expert in package management or 
 IDEs.
There's already efforts. It just need support. Again, not always financially. > I could probably learn how to do it, but it's unlikely he
 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.

 The main problem with the argument "why didn't you work more on 
 X, when clearly X would have made the D language more 
 successful than working on your core expertise Y" is... there's 
 something wrong with it. Whatever the problem is, the solution 
 can't be let's have fewer people do more work. It doesn't scale.

 Instead, we should compare D to language communities developed 
 in the past 10-15 years. I suggest you look around and see how 
 each one is doing and what were the different steps they took. 
 I can assure you that probably all of their leaders at some 
 points have been accused of not paying enough attention to 
 this or that thing important to some part of the community. 
 That's normal. Leading a small community or organization is 
 very different than leading a big one.
Yes, that's a good point. It is self-evident to me that I have not been a good leader, which is part of why I bowed out. All the paths not taken; surely one of them must have been better. I totally agree we didn't find the right sauce (how could I disagree? D doesn't have a million users). I think something endemic to our community is a certain thorniness, in most likelihood caused by its leadership (it always starts from the leadership) and slow mainstream adoption. Never in my life have I thrown so much work at such an unending pit of hostility. Years and years of my life, and some of my best work ever. Hundreds of thousands of lines written. Many more reviewed, to be fought tooth and nail by people whom I was just trying to help improve. The contrast is fascinating, because many companies are ready to pay handily for the very same thing, and the C++ community has always been happy with much less significant work. I was never able to explain this all to myself.
You've been a great inspiration. I would often skip other Dconf videos just to see what you'll present.
But clearly there's something wrong about it. We seem
 to be dealing in some counterfeit expertise currency.
Ok now I also feel bad myself. And I can speak for myself now. I'm probably sure I'm biased and greedy, probably. For example if we had some of these issues solved, I'd probably be complaining about something else I need.
 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.
"There's languages people don't use and those others complain." However agree we need to control how we air out our complaints so it doesn't become a personal attack. And part of it is being a leader on a project is again more than compilers and technically hard core fixes. It also includes managing people and marshalling together talents and empowering efforts. We've also seen people give up DIPs completely because they hit this wall. Communication, communication, people management. We're humans first. If you don't air out opinions on matters, the void will definitely be filled. It's not always about Walter do it, or Andrei fo it, or Atila do it. It's about marshalling people together to take responsibility of other things you just can't do. Its existing efforts everywhere. Again how will you as a CEO promote products of your company you don't use yourself or haven't got a gist of.
 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.
Ha ha. Yeah you're right we've ruined the thread. Sorry. Why Phobos is cool." it is. Phobos
Jun 26 2020
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:
 Never in my life have I thrown so much work at such an unending 
 pit of hostility. Years and years of my life, and some of my 
 best work ever. Hundreds of thousands of lines written. Many 
 more reviewed, to be fought tooth and nail by people whom I was 
 just trying to help improve. The contrast is fascinating, 
 because many companies are ready to pay handily for the very 
 same thing, and the C++ community has always been happy with 
 much less significant work. I was never able to explain this 
 all to myself. But clearly there's something wrong about it. We 
 seem to be dealing in some counterfeit expertise currency.

 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.
Let me try and compensate by saying Thank You, which I think has not been said enough. The day you announced that you quit your job at Facebook to work on D 100% was like Elon Musk announcing they would build a network of super chargers: it gave a huge confidence boost. Just WOW. So thank you, and I’m glad to see an increased involvement from you again recently. — Bastiaan.
Jun 26 2020
next sibling parent mate <aiueo aiueo.aiueo> writes:
On Friday, 26 June 2020 at 09:23:46 UTC, Bastiaan Veelo wrote:
 On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
 wrote:
 Never in my life have I thrown so much work at such an 
 unending pit of hostility. Years and years of my life, and 
 some of my best work ever. Hundreds of thousands of lines 
 written. Many more reviewed, to be fought tooth and nail by 
 people whom I was just trying to help improve. The contrast is 
 fascinating, because many companies are ready to pay handily 
 for the very same thing, and the C++ community has always been 
 happy with much less significant work. I was never able to 
 explain this all to myself. But clearly there's something 
 wrong about it. We seem to be dealing in some counterfeit 
 expertise currency.

 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.
Let me try and compensate by saying Thank You, which I think has not been said enough. The day you announced that you quit your job at Facebook to work on D 100% was like Elon Musk announcing they would build a network of super chargers: it gave a huge confidence boost. Just WOW. So thank you, and I’m glad to see an increased involvement from you again recently. — Bastiaan.
Same feelings here. Thank you Andrei.
Jun 26 2020
prev sibling next sibling parent Arjan <arjan ask.me.to> writes:
On Friday, 26 June 2020 at 09:23:46 UTC, Bastiaan Veelo wrote:
 On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
 wrote:
 [...]
Let me try and compensate by saying Thank You, which I think has not been said enough. The day you announced that you quit your job at Facebook to work on D 100% was like Elon Musk announcing they would build a network of super chargers: it gave a huge confidence boost. Just WOW. So thank you, and I’m glad to see an increased involvement from you again recently. — Bastiaan.
This! +1000 Thanks you very much!
Jun 26 2020
prev sibling parent reply Clarice <cl ar.ice> writes:
This is grossly off-topic.
Jun 26 2020
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 27 June 2020 at 01:08:22 UTC, Clarice wrote:
 This is grossly off-topic.
Andrei has been instrumental in the development of Phobos, and he deserves a lot of credit for why Phobos is cool (the title of this thread). Thanking him for that is not grossly off-topic, unlike this answer. — Bastiaan.
Jun 27 2020
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Saturday, 27 June 2020 at 22:32:04 UTC, Bastiaan Veelo wrote:
 On Saturday, 27 June 2020 at 01:08:22 UTC, Clarice wrote:
 This is grossly off-topic.
Andrei has been instrumental in the development of Phobos, and he deserves a lot of credit for why Phobos is cool (the title of this thread). Thanking him for that is not grossly off-topic, unlike this answer. — Bastiaan.
I think there is a bit of miscommunication here. I'm reasonably sure of my understanding, so I'll speak on Clarice's behalf: he was responding to a post by Seb that appears to have since been removed (most likely due to it's off-topicness). Jordan
Jun 27 2020
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 27 June 2020 at 23:30:25 UTC, Jordan Wilson wrote:
 I think there is a bit of miscommunication here. I'm reasonably 
 sure of my understanding, so I'll speak on Clarice's behalf: he 
 was responding to a post by Seb that appears to have since been 
 removed (most likely due to it's off-topicness).

 Jordan
Ah, thanks for clearing that up. The tone as it appeared to me didn’t match Clarice’s earlier posts, so it really made me raise my eye brows. All good. — Bastiaan.
Jun 28 2020
prev sibling next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:
 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.
+1 Kindness is powerful. I think we the community is prompt to point out the few mistakes while ignoring the stream of good decision the D leadership made along the years. One of those being a "big" Phobos that has lured many teams towards D. Considering the package explosion in "thin" stdlib languages, it was a clear win.
Jun 26 2020
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:

 The simple fact is I'm not an expert in package management or 
 IDEs. I could probably learn how to do it, but it's unlikely he 
 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.
We all know the concept of comparative advantage. It definitely wouldn't make sense for you or Walter to work on a package manager or IDE. I concluded long ago that the lack of a productive community was holding D back from achieving what other languages have.
 Yes, that's a good point. It is self-evident to me that I have 
 not been a good leader
I don't agree on this point. Imperfect but ultimately we ended up with a really good language and implementation that works well for many of us. I am very thankful for all the effort you put into the language.
Jun 26 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:
 Cool cool cool. (Kind of funny you frame lack of involvement in 
 dub as something to be ashamed of, like having cheated. I'll 
 level with you: I'm just a casual dub user.) So as far as I 
 understand the argument goes "Whatever you've worked on, that 
 was missing the point because you should have worked on dub 
 instead, which was way more important." From a very simple 
 teleological viewpoint, you're entirely right: if D isn't 
 mainstream, clearly there is something we didn't do right. As 
 such, all paths not taken are very attractive. What if we put 
 all that effort in dub? Or an IDE? Or a killer application 
 written in D? No shortage of paths not taken. You seem to 
 believe that dub is the most important, but over the years 
 there have been many ideas from many people about what is the 
 most important.

 From where you stand dub would be the thing to focus on, but 
 for years Walter and I have been fighting huge quality problems 
 that now seem to be forgotten. Those would preclude any 
 application work. dmd was be unable to compile anything beyond 
 the most trivial examples of its own flagship features - for 
 years! And when it got it right, phobos got something wrong.

 It does seem the presence of a package manager is a contributor 
 to success. Some languages swear by it (Python/pip, Rust/cargo, 
 Haskell/cabal). Yet some others are successful without an 
 official one (Java, C, C++, PHP); and yet others aren't doing 
 well in spite of having a good one (Perl/cpan). So it's not 
 quite the foregone conclusion. Other people would say that an 
 IDE is the thing, and I have been repeatedly asked to work on 
 one. I'm sure those asking were as convinced about the 
 importance of an IDE, as you are about the importance of dub.
But you do realize that Java does have package managers (even if there's no official one)? And IDEs are important. It'd be enough to have a plugin for IntelliJ or Eclipse.
 The simple fact is I'm not an expert in package management or 
 IDEs. I could probably learn how to do it, but it's unlikely he 
 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.
Nobody expects YOU to write a package manager, and you know that. You should keep on working on the library and stuff like that because you are very good at it, so you are. And here lies the problem, I think. You only see this particular aspect while your average John Doe needs a package manager. Think about the average development process. You write code in order to ship a product. You need 3rd party libraries. This should not be an issue or a hack. The average dev just wants to write good, stable code and ship the program, and do it fast if there are bug fixes.
 The main problem with the argument "why didn't you work more on 
 X, when clearly X would have made the D language more 
 successful than working on your core expertise Y" is... there's 
 something wrong with it. Whatever the problem is, the solution 
 can't be let's have fewer people do more work. It doesn't scale.
The job of the DLF would be to identify the priorities (as boring as they may seem) and coordinate how you go about it and hire, yes hire, programmers who work on one of the priorities.
 Instead, we should compare D to language communities developed 
 in the past 10-15 years. I suggest you look around and see how 
 each one is doing and what were the different steps they took. 
 I can assure you that probably all of their leaders at some 
 points have been accused of not paying enough attention to 
 this or that thing important to some part of the community. 
 That's normal. Leading a small community or organization is 
 very different than leading a big one.
Yes, that's a good point. It is self-evident to me that I have not been a good leader, which is part of why I bowed out.
Once you are a leader you have to stop developing and start coordinating things. If you try to do both you'll fail. I said this years ago. You love PLs and programming too much to be a leader, you want to write good code (so does Walter). You should never have become a leader in the first place. You'd need someone like Steve Jobs who has a vision and the energy to push his cause.
 All the paths not taken; surely one of them must have been 
 better. I totally agree we didn't find the right sauce (how 
 could I disagree? D doesn't have a million users). I think 
 something endemic to our community is a certain thorniness, in 
 most likelihood caused by its leadership (it always starts from 
 the leadership) and slow mainstream adoption. Never in my life 
 have I thrown so much work at such an unending pit of 
 hostility. Years and years of my life, and some of my best work 
 ever. Hundreds of thousands of lines written. Many more 
 reviewed, to be fought tooth and nail by people whom I was just 
 trying to help improve. The contrast is fascinating, because 
 many companies are ready to pay handily for the very same 
 thing, and the C++ community has always been happy with much 
 less significant work. I was never able to explain this all to 
 myself. But clearly there's something wrong about it. We seem 
 to be dealing in some counterfeit expertise currency.
There were clear suggestions nobody in the leadership picked up on. Simple things like stability, tooling. The leadership just bulldozers on even if people shout "Noooooo!". The problem of the D leadership is that they like programming and hacking too much and you're experimenting with code at the expense of your users. Do you know how it feels when you're code doesn't compile anymore from one version to the next and you have to spend hours to fix and test it while your users want this and that new feature? A PL is more than just code and CS theory. It's a complicated, delicate social network, jobs and end users depend on it, it's embedded in a competitive fast moving economy. And you have neglected this aspect over the years. Instead you concentrated on code and CS theory. You were blind to socioeconomic aspects of D. You are a very good engineer, top of the league. (I still sometimes think of your approach when I write code.) But you are not a leader. A man has to know his limitations.
 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.
Because D attracts the non-mainstream crowd that is more critical and demanding, and they feel they are closer to the leadership (familiarity), rightly or wrongly so. And if you stick your head out you have to live with fair and unfair criticism alike. You cannot say "Look at my allocators! Am I not a cool programmer!" and then ignore issues you consider "minor issues" (ARM, dub, autodecode) that are very important to the actual users. And then you break code for users because of some fancy CS thing you always wanted to implement. Of course people get angry sometimes.
 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.
Well, the post was a bit, how should I say, well, FFT is in the standard lib, great.
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:
 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I said 
 this years ago. You love PLs and programming too much to be a 
 leader, you want to write good code (so does Walter). You 
 should never have become a leader in the first place. You'd 
 need someone like Steve Jobs who has a vision and the energy to 
 push his cause.
This raises the question: where can D community to find such a person? There is an opportunity for someone with strong communication and organizational skills to do a great service for the D community by stepping up and filling this leadership vacuum. So far, no one has done so. Perhaps this is because we do not have a "Steve Jobs" in our midst--or perhaps we do, and they simply lack confidence that their contribution would be valued and rewarded. It is worth thinking about what might be done to encourage such a person to volunteer, and what obstacles might currently be standing in their way.
Jun 26 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:
 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. So 
 far, no one has done so. Perhaps this is because we do not have 
 a "Steve Jobs" in our midst--or perhaps we do, and they simply 
 lack confidence that their contribution would be valued and 
 rewarded.

 It is worth thinking about what might be done to encourage such 
 a person to volunteer, and what obstacles might currently be 
 standing in their way.
I don't know, but the D community consists mainly of programming enthusiasts. That's why they put up a lot if sub-optimal hack-y stuff. D needs some sort of Steve Jobs who says "I want it to be a great experience for users".
Jun 26 2020
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 16:27:52 UTC, Chris wrote:
 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:
 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. 
 So far, no one has done so. Perhaps this is because we do not 
 have a "Steve Jobs" in our midst--or perhaps we do, and they 
 simply lack confidence that their contribution would be valued 
 and rewarded.

 It is worth thinking about what might be done to encourage 
 such a person to volunteer, and what obstacles might currently 
 be standing in their way.
I don't know, but the D community consists mainly of programming enthusiasts. That's why they put up a lot if sub-optimal hack-y stuff. D needs some sort of Steve Jobs who says "I want it to be a great experience for users".
I think there are plenty of people willing to contribute to improving D's UX, but without any kind of coordination or agreement on an overall plan, it is difficult for individuals to motivate themselves to take the first step. This is why I stress "communication and organizational skills." IMHO both the desire and the capability are already there, but everyone is pointed in different directions.
Jun 26 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.
I'm not sure what it means to talk about a Steve Jobs in the context of an open source project. He hired many of the top people, paid very high salaries, and shouted at them until he had a product he wanted to use. It's easy to be a visionary leader if you have billions of dollars to implement your vision.
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:
 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.
I'm not sure what it means to talk about a Steve Jobs in the context of an open source project. He hired many of the top people, paid very high salaries, and shouted at them until he had a product he wanted to use. It's easy to be a visionary leader if you have billions of dollars to implement your vision.
I was using "Steve Jobs" to mean the kind of person Chris referred to in this quote:
 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.
Feel free to mentally replace it with "a talented leader," if you find Steve Jobs himself objectionable.
Jun 26 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 26, 2020 at 04:56:20PM +0000, Paul Backus via Digitalmars-d wrote:
 On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:
[...]
 I'm not sure what it means to talk about a Steve Jobs in the context
 of an open source project. He hired many of the top people, paid
 very high salaries, and shouted at them until he had a product he
 wanted to use.  It's easy to be a visionary leader if you have
 billions of dollars to implement your vision.
I was using "Steve Jobs" to mean the kind of person Chris referred to in this quote:
 You'd need someone like Steve Jobs who has a vision and the energy
 to push his cause.
Feel free to mentally replace it with "a talented leader," if you find Steve Jobs himself objectionable.
You're missing the point, which is the Steve Jobs had billions of dollars at his disposal and could (and undoubtedly did) use it to pay people to implement his vision, whereas Walter does not have billions of dollars at his disposal and cannot motivate volunteers to do what he wants with money. Had Steve Jobs *not* been in the position to hire people with billions of dollars, perhaps a lot less might have come of his vision. T -- Heads I win, tails you lose.
Jun 26 2020
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 16:56:20 UTC, Paul Backus wrote:
 On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:
 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.
I'm not sure what it means to talk about a Steve Jobs in the context of an open source project. He hired many of the top people, paid very high salaries, and shouted at them until he had a product he wanted to use. It's easy to be a visionary leader if you have billions of dollars to implement your vision.
I was using "Steve Jobs" to mean the kind of person Chris referred to in this quote:
 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.
Feel free to mentally replace it with "a talented leader," if you find Steve Jobs himself objectionable.
I don't find Steve Jobs objectionable, I just don't think there's anything to be gained from pretending there's an equivalent for an open source project. Maybe the closest would be Rich Hickey, and Clojure's not exactly setting the world on fire. It doesn't seem all that difficult to figure out what D needs: IDE support, a good package manager, solid libraries, and good documentation all come to mind. We need volunteers willing to do hard work and/or funding to pay people to do the hard work.
Jun 26 2020
parent Yatheendra <indra yath.io> writes:
I am a long-time lurker still debating how to dip my toes in 
BetterC, but I have read these forums, watched DConf videos and 
perused library code.

Phobos is great because the parts I looked at are the first time 
I have grokked library code, it is so well-written. Part of it is 
down to the language offering "developability", the rest is down 
to good taste I guess :-) I could understand at a high-level 
whatever was going on, before ever writing a single line of D.

The complaints cropping up all the time make the forum so bloody 
unproductive (sorry for using strong words. is it just regular 
free-riding ingrates? or some other types? why this overdose just 
on D forums!). Anyway, let me pontificate too.

Leadership, past and present: please ignore all non-contributors' 
complaints, just expect them to write up a technical bug 
report/enhancement proposal (unless you enjoy riling them up). 
You have continued to make your bleeding edge ideas openly 
available, and don't really need to respond to second-guessing by 
non-language designers. I don't know any other project of this 
size with the founders remaining involved this deeply, you have a 
lot of stamina to be replying to less-knowledgeable strangers too.

Contributor-driven forum threads have been so much more 
substantive, but their open availability is what gives a newcomer 
pause. I think it is legitimate to do that in a less discoverable 
place than the forums. Because right now, between auto-decode 
default and the complaints of contributors about process as well 
as direction, I don't know how newcomers can shake the feeling 
that this is Walter's and Andrei's long-term lab!

Contributors: you must have left C++ too far behind, you wouldn't 
deign to suggest changes in that morass. Just because this is a 
more open place with a direct line to leadership, you seem to 
want equal footing for your approaches. I don't think it is too 
much to expect that you defer to Walter's choices because he does 
have a fuller view. Contributing to his considered vision can't 
be of no ongoing benefit.

Users: please try to derate your negativity by acknowledging the 
possibility that language and library design is hard, and other 
language communities likely have all of these debates but not 
overtly publicly. By all means, look for stability but do not 
look for perfection. D is likely better than most any 
natively-compiled language, it is just that you won't hear false 
assurances of no breakage across releases - it is software made 
by few minds, and there will be the odd regression.
Jun 26 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:
 On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:
 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I said 
 this years ago. You love PLs and programming too much to be a 
 leader, you want to write good code (so does Walter). You 
 should never have become a leader in the first place. You'd 
 need someone like Steve Jobs who has a vision and the energy 
 to push his cause.
This raises the question: where can D community to find such a person? There is an opportunity for someone with strong communication and organizational skills to do a great service for the D community by stepping up and filling this leadership vacuum. So far, no one has done so. Perhaps this is because we do not have a "Steve Jobs" in our midst--or perhaps we do, and they simply lack confidence that their contribution would be valued and rewarded. It is worth thinking about what might be done to encourage such a person to volunteer, and what obstacles might currently be standing in their way.
It can be done. The problem is the mindset that those things are not important or people complaining about such stuff are unproductive idiots who have nothing to do with their life but spend all day (...in their mind) spamming the D forum, so to speak. We all get paid for writing code. But there's a tool maker and there's a tool user. A tool user can also be another person's tool user. Again its the mindset, not everyone has that level of polish and UX mind/priority. Some have never written user facing code where it has to be done is such a way regular people (in D's case the tool user) can feel comfortable to pick up. It all depends on the mindset, I don't believe it has to do with being a (hard core) programmer or anything like it. I've seen D tools well polished with good UX. Some value communication and organizational skills naturally. The basic elements you learn in some high schools or in entrepreneurship class needed to make ventures succeed and grow, in addition to other agents. In D's case, its hard to tell. Some think money is the only way to attract talents and they'll only pick that from the Steve jobs analogy. At the end of the day, its all about trying to make D better.
Jun 27 2020
parent Chris <wendlec tcd.ie> writes:
On Saturday, 27 June 2020 at 09:44:01 UTC, aberba wrote:
 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:
 On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:
 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I 
 said this years ago. You love PLs and programming too much to 
 be a leader, you want to write good code (so does Walter). 
 You should never have become a leader in the first place. 
 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.
This raises the question: where can D community to find such a person? There is an opportunity for someone with strong communication and organizational skills to do a great service for the D community by stepping up and filling this leadership vacuum. So far, no one has done so. Perhaps this is because we do not have a "Steve Jobs" in our midst--or perhaps we do, and they simply lack confidence that their contribution would be valued and rewarded. It is worth thinking about what might be done to encourage such a person to volunteer, and what obstacles might currently be standing in their way.
It can be done. The problem is the mindset that those things are not important or people complaining about such stuff are unproductive idiots who have nothing to do with their life but spend all day (...in their mind) spamming the D forum, so to speak. We all get paid for writing code. But there's a tool maker and there's a tool user. A tool user can also be another person's tool user. Again its the mindset, not everyone has that level of polish and UX mind/priority. Some have never written user facing code where it has to be done is such a way regular people (in D's case the tool user) can feel comfortable to pick up. It all depends on the mindset, I don't believe it has to do with being a (hard core) programmer or anything like it. I've seen D tools well polished with good UX. Some value communication and organizational skills naturally. The basic elements you learn in some high schools or in entrepreneurship class needed to make ventures succeed and grow, in addition to other agents. In D's case, its hard to tell. Some think money is the only way to attract talents and they'll only pick that from the Steve jobs analogy. At the end of the day, its all about trying to make D better.
Well put. I think what's missing is a general vision. There are too many "subthreads" going on. Everybody has their pet features or need just one specific thing out of D an that's that (I suppose some users / companies are happy with a subset of D and don't care about the rest that might be important to others). The problem is that the "leaders" should not actively develop as this narrows the field of vision, and if a company sponsors D but only focuses on the one aspect that is important to them, then it cannot really be a "general purpose" language. What you basically need is someone like Steve Jobs (metaphorically speaking) who sees the bigger picture and says "cut that crap" when necessary.
Jun 27 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 25/06/2020 18:25, Andrei Alexandrescu via Digitalmars-d wrote:
 On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:
 The way I see things is that we as a community need to focus on a vetted, well
shaped collection of libraries.
 We need to have process where third-party libraries are able to gain broader
support and join dlang-community. Also we need dlang-community to have a
healthy number of people who actually maintain the code.
 We need the leadership to realize that investing just in dmd, druntime and
phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that unless we
embrace using code.dlang.org as method of distribution of everything that's
currently part of the compiler archive, Dub's limitations will never be
addressed and from that the broader community will suffer.
(By the way just to clarify "A" in "W&A" would stand for Atila. I'm commenting as just one in the community.) I'm a bit confused by this argument. So there is the compiler and standard library, and then there's a community-supported library, which includes a copy of the standard library under an improved versioning schema. It's all legal and encouraged by the generous licensing of the compiler and standard library, both of which Walter and I fought hard in the past to obtain and maintain. Dub is the perfect place where community leadership can set the tone and organized things as they need to without heavy-handed intervention from above. Several people have criticized "the leadership" for not doing things the way they wanted, so it seems perplexing that leadership intervention is now asked for. What's that nonsense with "pretending dub doesn't exist"? So now they need to take ownership of the community-driven dub as well? Isn't that a bit too much work for a handful of folks in the best of times?
If I was to take some of it at face value, I'd probably turn around and say: you know what, I'm going to drop Phobos from GDC and tell people to get it from Dub instead. Apart from std.math, there are no differences between upstream and downstream copies anyway (and I could always upstream version(GNU) asm implementations for x86, RISC-V, ...). It would certainly make my life easier, would speed up both time to build compiler and run the testsuite, and no more worrying about getting the mathlib working on PPC64, or PA-RISC, or M68K, or VAX. That's now someone else's problem, and I can think of better things I could be doing with my time anyway. Would people be happy if I did this? I doubt it.
Jul 17 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/07/2020 2:14 AM, Iain Buclaw wrote:
 Apart from std.math, there are no differences between upstream and downstream
copies anyway (and I could always upstream version(GNU) asm implementations for
x86, RISC-V, ...).
 
 It would certainly make my life easier, would speed up both time to build
compiler and run the testsuite, and no more worrying about getting the mathlib
working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's
problem, and I can think of better things I could be doing with my time anyway.
 
 Would people be happy if I did this?  I doubt it.
How often does compiling Phobos as part of the testsuite catch bugs in gdc? If the answer is never, then maybe some deferring could be possible.
Jul 17 2020
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 17/07/2020 16:28, rikki cattermole via Digitalmars-d wrote:
 On 18/07/2020 2:14 AM, Iain Buclaw wrote:
 Apart from std.math, there are no differences between upstream and downstream
copies anyway (and I could always upstream version(GNU) asm implementations for
x86, RISC-V, ...).

 It would certainly make my life easier, would speed up both time to build
compiler and run the testsuite, and no more worrying about getting the mathlib
working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's
problem, and I can think of better things I could be doing with my time anyway.

 Would people be happy if I did this?  I doubt it.
How often does compiling Phobos as part of the testsuite catch bugs in gdc? If the answer is never, then maybe some deferring could be possible.
We're usually very good at finding bugs in Phobos, rather than the other way round. However, the combination of testsuite + druntime alone is not really representative of catching all issues that could happen on changes made to the code generator, and there have been a few fairly intrusive changes I've been testing in the last weeks where Phobos has proved to be a good litmus test for finding problems (especially in the changes being done to emission strategy - I can no longer ignore it due to newly added GC tests in druntime that depend on weak rather than vague linkage). Though the same "representative" argument can be made of testsuite + druntime + phobos as well, and it shouldn't be too difficult to add a test script that obtains and builds a bunch of projects (similar to dmd buildkite) as a kind of expensive testsuite run.
Jul 17 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi 
 wrote:
 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...
Who says that this is a binary choice? And also, the way you fraise it it's obvious that say Flutter is better choice than React as everything is very tightly integrated and you could build your whole app without reaching for third-party code. Also, it's obvious that in terms of trust, it's better to rely on the diligence of the upsteam development team, than random strangers from the internet. But what if 90% of the code my team needs has no place in Phobos? We already have to rely heavily on third-party packages. Yes there are a lot of risks and we try to be careful, but we have no other choice. We could spend years reiventing the wheel (high-quality code that already exists in other languages), or we could focus on delivering products to our users based on the already existing ecosystem in other languages. Well, a choice would exist if we had an unlimited budget, but given that we're not as lucky, we can only use other languages for our projects currently. Technically, phobos is actually already on Dub (https://code.dlang.org/packages/phobos), so in the future nothing could prevent you to continue using it, but you would just get it from there and not from the compiler distribution archive. It's the same code, made by the same people, just with a different distribution model. The way I see things is that we as a community need to focus on a vetted, well shaped collection of libraries. We need to have process where third-party libraries are able to gain broader support and join dlang-community. Also we need dlang-community to have a healthy number of people who actually maintain the code. We need the leadership to realize that investing just in dmd, druntime and phobos is necessary, but very insufficient. W&A need to stop pretending that Dub doesn't exist. I feel that unless we embrace using code.dlang.org as method of distribution of everything that's currently part of the compiler archive, Dub's limitations will never be addressed and from that the broader community will suffer.
 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...
See, some of the problems in Phobos already have a good solution. The problem that we need to address is the trust. The more high-quality and well-maintained libraries there are, the less cautious one would need to be before reaching to code.dlang.org.
Almost the exact reason why i use JavaScript (nodejs) for work and not D. It takes more than a nice language. When some here say they don't use Dub or they don't care about dub packages, I'm wondering what kind of software they are writing. In my line if work, it's highly dependant of availability of packages to get the job done. Encryption, networking, data manipulation, database connectors, socket, rest, cloud services, etc. Its more like glueing services and APIs together. Unless you're building compilers and softwares that don't connect to internet, then it makes sense to not be bothered by the lack of certain packages on dub. This will only happen when the community collaborates, which will only happen when there's a visible leadership push/backing. I meant D conf online has taken forever to happen and I'm not sure if community building is a thing prioritized at all. I've been policing and trying several packages on dub...some, talking to their maintainers. I want to make this happen. Its the only way. I rarely use core nodejs packages. Its like npm has got everything. Its what dub needs. Already I'm happy with quite a few dub packages. And there's huge!! room for improvement if only there's a visible official push. Its not always about money. I'm not sure why we don't even have regular online community meetups. Yeah, there's people who would rather code and feel more productive that way. That's also fine. Except there's another side about community building. DConf is a Joy to watch. Just the community interaction alone and how ideas are shared. It could happen more often. More often online.
Jun 25 2020
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/25/20 12:42 PM, aberba wrote:
 This will only happen when the community collaborates, which will only 
 happen when there's a visible leadership push/backing.
This is speculation. What is it based on? Boost was started by Beman Dawes with no backing. I know next to nothing about npm, but a look at their website www.npmjs.com suggests it's a traditional for-profit company with no ties to ECMA or other JavaScript formal leadership bodies. What concrete forms of said leadership push/backing do you envision?
Jun 25 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 25 June 2020 at 17:03:02 UTC, Andrei Alexandrescu 
wrote:
 On 6/25/20 12:42 PM, aberba wrote:
 This will only happen when the community collaborates, which 
 will only happen when there's a visible leadership 
 push/backing.
This is speculation. What is it based on? Boost was started by Beman Dawes with no backing. I know next to nothing about npm, but a look at their website www.npmjs.com suggests it's a traditional for-profit company with no ties to ECMA or other JavaScript formal leadership bodies.
First, you're making the whole point of it about npm (JavaScript) specifically, there's also Cargo (rust). JavaScript is now very big so there's multiple movements. But let's take nodejs, there's a foundation. I've watched several meetings by the core team and you can find them on YouTube. Its open and live for everyone to see.
 What concrete forms of said leadership push/backing do you 
 envision?
Again since I'm more into nodejs recently, I'll just show you their get involved page. https://nodejs.org/en/get-involved/ I want to be fair because nodejs community has grown and there's many stakeholders now...but the initial work to attract interest has to be done first. I don't have all the answers. I may not have articulated my opinions well...for sure. However the thing about community, I'm not the only person who has that view.
Jun 25 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/25/20 3:38 PM, aberba wrote:
 On Thursday, 25 June 2020 at 17:03:02 UTC, Andrei Alexandrescu wrote:
 On 6/25/20 12:42 PM, aberba wrote:
 This will only happen when the community collaborates, which will 
 only happen when there's a visible leadership push/backing.
This is speculation. What is it based on? Boost was started by Beman Dawes with no backing. I know next to nothing about npm, but a look at their website www.npmjs.com suggests it's a traditional for-profit company with no ties to ECMA or other JavaScript formal leadership bodies.
First, you're making the whole point of it about npm (JavaScript) specifically, there's also Cargo (rust).
Yah, rust is an even better example. They have talented people who are dedicated to everything related to the rust community, and doing so improves their own career and pays their bills. How would you walk and talk if your formal job, and that of a team around you, would be to serve, manage, and improve the D community? Completely different ballgame. At least with the resources we can muster for the time being, this is a war of attrition we can't sustain. It's simple. Our flamewars are similar to the poor couple fighting and giving each other the example of the Joneses and how easy everything seems to be for them.
Jun 25 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 25 June 2020 at 19:49:21 UTC, Andrei Alexandrescu 
wrote:
 Yah, rust is an even better example. They have talented people 
 who are dedicated to everything related to the rust community, 
 and doing so improves their own career and pays their bills. 
 How would you walk and talk if your formal job, and that of a 
 team around you, would be to serve, manage, and improve the D 
 community? Completely different ballgame.

 At least with the resources we can muster for the time being, 
 this is a war of attrition we can't sustain. It's simple. Our 
 flamewars are similar to the poor couple fighting and giving 
 each other the example of the Joneses and how easy everything 
 seems to be for them.
The only thing the community can do is voice their disdain with what they are unhappy with. The situation with DIP1028 is what it takes to change course of the SS Didanic. The whole community has to be riled up in protest for a change to actually happen. It's difficult to make even small changes for the better.
Jun 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2020 3:14 PM, Avrina wrote:
 The only thing the community can do is voice their disdain with what they are 
 unhappy with.
Anyone in the community can step up and appoint themself the leader of Dub. If they do a good job, the rest of the community will naturally follow.
Jun 25 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:
 On 6/25/2020 3:14 PM, Avrina wrote:
 The only thing the community can do is voice their disdain 
 with what they are unhappy with.
Anyone in the community can step up and appoint themself the leader of Dub. If they do a good job, the rest of the community will naturally follow.
I appoint myself leader of DMD. E-mail me and give me permissions to the DMD repository :).
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 13:17:13 UTC, Avrina wrote:
 On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:
 On 6/25/2020 3:14 PM, Avrina wrote:
 The only thing the community can do is voice their disdain 
 with what they are unhappy with.
Anyone in the community can step up and appoint themself the leader of Dub. If they do a good job, the rest of the community will naturally follow.
I appoint myself leader of DMD. E-mail me and give me permissions to the DMD repository :).
Genuine question: what did you hope to achieve by sending this reply? It is neither kind nor constructive, and I cannot imagine anything useful resulting from it.
Jun 26 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 13:41:28 UTC, Paul Backus wrote:
 On Friday, 26 June 2020 at 13:17:13 UTC, Avrina wrote:
 On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:
 On 6/25/2020 3:14 PM, Avrina wrote:
 The only thing the community can do is voice their disdain 
 with what they are unhappy with.
Anyone in the community can step up and appoint themself the leader of Dub. If they do a good job, the rest of the community will naturally follow.
I appoint myself leader of DMD. E-mail me and give me permissions to the DMD repository :).
Genuine question: what did you hope to achieve by sending this reply? It is neither kind nor constructive, and I cannot imagine anything useful resulting from it.
I could ask the same thing of the post I replied to.
Jun 26 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2020 9:26 AM, Avrina wrote:
 I could ask the same thing of the post I replied to.
Many D community members have stepped up at their own initiative to become the leader of various parts.
Jun 26 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 21:00:43 UTC, Walter Bright wrote:
 On 6/26/2020 9:26 AM, Avrina wrote:
 I could ask the same thing of the post I replied to.
Many D community members have stepped up at their own initiative to become the leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
Jun 27 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/27/2020 5:07 AM, Avrina wrote:
 Many D community members have stepped up at their own initiative to become the 
 leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
Rainer does the Win64 and VS support. Brad Roberts initiated, built, and ran the test servers for many years. He did bugzilla too. Iain does GDC. The LDC team is entirely self-selected. Jacob does the Objective-C support. Vladimir wrote the Dforum software (and many other indispensable tools). And on and on for nearly every part of the D system. You want something to happen? Step up and make it happen.
Jun 27 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:
 On 6/27/2020 5:07 AM, Avrina wrote:
 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
 Jacob does the Objective-C support.
He does also DWT.
Jun 28 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2020 3:26 AM, Patrick Schluter wrote:
 On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:
 Jacob does the Objective-C support.
He does also DWT.
Yes. My list does not remotely cover everyone who has stepped up to take charge and make things happen.
Jun 28 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:
 On 6/27/2020 5:07 AM, Avrina wrote:
 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
Rainer does the Win64 and VS support. Brad Roberts initiated, built, and ran the test servers for many years. He did bugzilla too. Iain does GDC. The LDC team is entirely self-selected. Jacob does the Objective-C support. Vladimir wrote the Dforum software (and many other indispensable tools). And on and on for nearly every part of the D system. You want something to happen? Step up and make it happen.
Yes, someone definitely has to be uncharged. That's always true. But what's your (DLF) role in this? Does it fall outside the vision of the foundation to participate and keep the fire burning in whatever way it can? Is there no coordination to solidify and unify all those efforts to ensure continuity? What happens when those people leave. What's the foundation doing about this?
Jun 28 2020
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:
 On 6/27/2020 5:07 AM, Avrina wrote:
 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
Rainer does the Win64 and VS support. Brad Roberts initiated, built, and ran the test servers for many years. He did bugzilla too. Iain does GDC. The LDC team is entirely self-selected. Jacob does the Objective-C support. Vladimir wrote the Dforum software (and many other indispensable tools). And on and on for nearly every part of the D system. You want something to happen? Step up and make it happen.
The point is actually that some aspects of D should be taken care of directly by the DLF to guarantee continuity and stability. What if a contributor leaves the project? What are you gonna do then? Volunteers can work on libraries or interfaces to other languages, but there are essential parts that should have guaranteed LTS from the DLF. I'd say that first class LDC integration along with cross platform support should be one of the top priorities. You cannot just sit and wait till somebody steps up or hope that nobody drops out. That's gambling. Also, if you rely on volunteers to do important work, the DLF might revise its approach to communicating with them. A lot of people have left over the way they were being treated and projects have been discontinued, and yet the DLF seems to shrug it off every time this happens instead of doing some introspection. (As a side note: it is of course ironic when members of the DLF complain about lack of support and gratitude, when they have no qualms about stonewalling enthusiastic contributors. Quelle ironie!) Anyway, chances are that ARM will decide the fate of D.
Jun 28 2020
prev sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:
 On 6/27/2020 5:07 AM, Avrina wrote:
 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.
Go ahead and list some. I already have a feeling I know what the trend is going to be like.
Rainer does the Win64 and VS support. Brad Roberts initiated, built, and ran the test servers for many years. He did bugzilla too. Iain does GDC. The LDC team is entirely self-selected. Jacob does the Objective-C support. Vladimir wrote the Dforum software (and many other indispensable tools). And on and on for nearly every part of the D system. You want something to happen? Step up and make it happen.
There's only so much "stepping up" to make something happen can do. The changes that I think need to happen won't actually be put into place, in part because a package manager that is disjoint from the rest of the development can only do so much. A forum, a server, more servers, a bug tracker, miscellaneous tools, and an IDE plugin can all operate disjointly without a significant impact (for most of the cases) on the quality of the project. Part of the root of the problem with Dub lies with DMD. So simply having control to make decisions that would potentially cause breaking changes only of Dub isn't enough. I guess you are a bit spoiled when it comes to having projects like LDC where someone did step up and took it upon themselves to create something that DMD wasn't able to provide. Not sure how well it would go, if for example they decided a DIP (like DIP1028) shouldn't be implemented and they simply strip it from LDC and reject the DIP themselves. Realistically I doubt this will happen, and that's in part because they aren't actually fully in control. You care so little about Dub that you'd let just anyone take up the reins and do whatever they want with it. Including running it into the ground. The thing about individual projects is that they don't need Dub. I use a 100 line python script that does everything I need, I'm not going to waste my time with Dub. Just as DMD doesn't use dub (except for the library version). It's simply easier to not use it. No body is going to invest in something they can do themselves for much less effort while still being able to work on their own projects instead of having to shelf them to work on a package manager. I think ultimately having past successes with having "someone step up" and do the work for you and thinking the same thing applies to and will work for Dub, is ultimately hurting Dub in the long run. Well I'm done talking about Dub, maybe I'll link this post in 5-10 years and we'll see what's come of Dub and your wait and see approach to developing it. #dub #fixdub #dub2028
Jun 28 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2020 9:13 AM, Avrina wrote:
 I guess you are a bit spoiled
Please post with professional demeanor.
Jun 28 2020
next sibling parent reply aeldemery <aeldemery.de gmail.com> writes:
On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:
 On 6/28/2020 9:13 AM, Avrina wrote:
 I guess you are a bit spoiled
Please post with professional demeanor.
Hello all, This is my first post ever although I've an eye on the forum since quite some time. I wanted to say this kind of destructive conversations is hurting the reputation of the language, deepen the feeling that the language is unsuccessful and turning newcomers off. The people behind this wonderful project deserve some gratitude and recognition. That doesn't deny the fact that it, like any human endeavor, is subjected to incongruity and discordance, nevertheless, I think there should be another respectful tone in the conversations. Thanks and have a good day.
Jun 29 2020
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 12:04 AM, aeldemery wrote:
 Hello all,
 
 This is my first post ever although I've an eye on the forum since quite some
time.
 I wanted to say this kind of destructive conversations is hurting the
reputation 
 of the language, deepen the feeling that the language is unsuccessful and 
 turning newcomers off. The people behind this wonderful project deserve some 
 gratitude and recognition.
 That doesn't deny the fact that it, like any human endeavor, is subjected to 
 incongruity and discordance, nevertheless, I think there should be another 
 respectful tone in the conversations.
 
 Thanks and have a good day.
We try pretty hard to use a light touch with the moderation, and only remove the worst of them. It's a tough line to call balancing allowing people to speak their minds while not destroying the usefulness of the forums.
Jun 29 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:
 On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:
 On 6/28/2020 9:13 AM, Avrina wrote:
 I guess you are a bit spoiled
Please post with professional demeanor.
Hello all, I wanted to say this kind of destructive conversations is hurting the reputation of the language, deepen the feeling that the language is unsuccessful and turning newcomers off.
I personally avoid insults. And its quite unfortunate some people choose those kind of words. In some cultures certain words might not sound that offensive though. But since we're dealing with an internal community and words don't reflect actual emotions, its best to be careful about choice of words.
The
 people behind this wonderful project deserve some gratitude and 
 recognition.
That MOST of us do. Not everyone it might seem air it out more though. But you know, its a common thing that people usually talk without being asked when they are rather troubled within something. Doesn't always work the same for when they're good. But that's not a good thing for a community. Does the complaints make D unsuccessful? No. (Well it might sound unsuccessful to newcomers...but that's just so for every language people actually use, its why say Apple keep releasing new product updates). The language itself is solid. I may be biased but better than any system programming language I've ever tried. An that's a problem...cus it doesn't deliver it quite complete... ecosystem wise (in my perspective). And that's it, its normal to hear people air the views on those issues. And these views are diverse...tools, GC, safe, Minimal runtime, generic, compiler, etc. Different pain points. Could be more considering majority (I guess) of D users rare write a single word here. I doesn't mean they're not bothered by certain things they'd like to be addressed. You know, I'd rather think the DLF takes these views as community feedback. Side note: code-d plugin for VS code is so good I wonder why its not been covered on say the D blog or website preferably. And that's what I'm afraid will lead many people to feel D doesn't have a great code editor support (the maintainer is doing amazing job, you'd just have to try it yourself). Same as Visual Studio itself. But you don't hear about them, and that's a problem. Of course some seasoned D devs already know this, but what about newcomers? Will this not drive them away? And that's just about VS code. There's many other efforts like it. Who will do this? A community manager primarily of course. Initially its the LEADER/DLF. Community == contributors with diverse contributions.
Jun 29 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 4:32 AM, aberba wrote:
 Side note: code-d plugin for VS code is so good I wonder why its not been 
 covered on say the D blog or website preferably.
How about writing an article about it? The D Blog even pays a modest amount to authors who get their articles published there.
Jun 29 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 23:13:57 UTC, Walter Bright wrote:
 On 6/29/2020 4:32 AM, aberba wrote:
 Side note: code-d plugin for VS code is so good I wonder why 
 its not been covered on say the D blog or website preferably.
How about writing an article about it? The D Blog even pays a modest amount to authors who get their articles published there.
Sounds like you're giving me a good idea. I've added it to my to-do list.
Jun 30 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2020 1:30 AM, aberba wrote:
 Sounds like you're giving me a good idea. I've added it to my to-do list.
Looking forward to it!
Jun 30 2020
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:
 Hello all,

 This is my first post ever although I've an eye on the forum 
 since quite some time.
 I wanted to say this kind of destructive conversations is 
 hurting the reputation of the language, deepen the feeling that 
 the language is unsuccessful and turning newcomers off. The 
 people behind this wonderful project deserve some gratitude and 
 recognition.
 ...
+1 and the strange thing is that "low" conversation was raised on a topic which the title is: "Why Phobos is cool". So instead reading about "the cool things", the topic was derailed to "the awful things", and that's pity. Unfortunately there is this dark mood on this forum lately. Matheus.
Jun 29 2020
prev sibling parent matheus <matheus gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:
 Hello all,

 This is my first post ever although I've an eye on the forum 
 since quite some time.
 I wanted to say this kind of destructive conversations is 
 hurting the reputation of the language, deepen the feeling that 
 the language is unsuccessful and turning newcomers off. The 
 people behind this wonderful project deserve some gratitude and 
 recognition.
 ...
+1 and the strange thing is that "low" conversation was raised on a topic which the title is: "Why Phobos is cool". So instead reading about "the cool things", the topic was derailed to "the awful things", and that's pity. Unfortunately there is this dark mood on this forum lately. Matheus.
Jun 29 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:
 On 6/28/2020 9:13 AM, Avrina wrote:
 I guess you are a bit spoiled
Please post with professional demeanor.
I think the actual point to take home was that you cannot expect people to step up forever and ever only because they have done so in the past. That's basically gambling. And I do hope you don't think that someone will eventually step up if his/her livelihood is at stake (ARM). Please do not use the way something is phrased as an excuse to dismiss what is being said, unless it is an outright insult like for example a swear word. Experience tells me that when somebody is nitpicking about the way something is said and is taking offence at everything, it is usually a sign that s/he has no answer.
Jun 29 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 3:55 AM, Chris wrote:
 and is taking offence at everything,
That is a complete misunderstanding of what is going on here. The targets of rude behavior are not the problem, it is the rude behavior that's the problem. It's about professional demeanor. Unprofessional posts will be deleted.
Jun 29 2020
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 29 June 2020 at 23:35:13 UTC, Walter Bright wrote:
 On 6/29/2020 3:55 AM, Chris wrote:
 and is taking offence at everything,
That is a complete misunderstanding of what is going on here. The targets of rude behavior are not the problem, it is the rude behavior that's the problem. It's about professional demeanor. Unprofessional posts will be deleted.
Personally I think that the sentence was not really rude or insulting but maybe polemical, so within the range of a passionate and heated debate, I'd say, even in a professional environment. IMO, it's neither fair nor good style to single out one sentence from a long post and dismiss the whole post because you consider the sentence to be rude or unprofessional. It may give people the impression that it's merely a strategy to avoid inconvenient questions / points. And since "professional demeanor" is a flexible term one can always change the criteria as one sees fit (another one is "unspecific" which has become a rather unspecific term too :). In this case, you could have just said something like "That's not a nice way to put it, but I get your point [answer] ...May I ask you to be a bit more careful in your choice of words the next time. We're trying to keep things strictly professional here." As for the point the poster made, there is no answer I guess, because relying on volunteers is a big gamble and only because people have stepped up in the past doesn't mean it's gonna be like that forever. Again, for the third time, you haven't addressed this point but instead talked about "professional demeanor".
Jun 30 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2020 1:33 AM, Chris wrote:
 Personally I think that the sentence was not really rude or insulting but
maybe 
 polemical, so within the range of a passionate and heated debate, I'd say,
even 
 in a professional environment.
Calling someone "spoiled" is rude and unprofessional. Period.
 IMO, it's neither fair nor good style to single out one sentence from a long 
 post and dismiss the whole post because you consider the sentence to be rude
or 
 unprofessional.
People who want their message heard need to post in a professional manner. I don't care about the opinions of rude people. I don't care to work with them, even if they are good. I am hardly alone in this - pretty much nobody in the professional world responds to rude messages.
 And since "professional demeanor" is a 
 flexible term one can always change the criteria as one sees fit (another one
is 
 "unspecific" which has become a rather unspecific term too :).
I recommend that anyone who has difficulties understanding what politeness is get a copy of Emily Post's book on business etiquette. Ill-mannered people find themselves shut out of all kinds of opportunities, and they rarely figure out why.
Jun 30 2020
next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:
 On 6/30/2020 1:33 AM, Chris wrote:
 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.
Calling someone "spoiled" is rude and unprofessional. Period.
 IMO, it's neither fair nor good style to single out one 
 sentence from a long post and dismiss the whole post because 
 you consider the sentence to be rude or unprofessional.
People who want their message heard need to post in a professional manner. I don't care about the opinions of rude people. I don't care to work with them, even if they are good. I am hardly alone in this - pretty much nobody in the professional world responds to rude messages.
 And since "professional demeanor" is a flexible term one can 
 always change the criteria as one sees fit (another one is 
 "unspecific" which has become a rather unspecific term too :).
I recommend that anyone who has difficulties understanding what politeness is get a copy of Emily Post's book on business etiquette. Ill-mannered people find themselves shut out of all kinds of opportunities, and they rarely figure out why.
Well said! This is especially applicable for healthy societies and communities. Unrelated to this, but around a month ago I was discussing with a friend of mine who is a psychiatrist on how common narcissism has become these days and is being mistaken for boldness and how leadership roles are being taken by such people and how meritocratic communities tend to expell narcists and kakistocracy communities tend to favor them, especially if it involves money. If we do not point out and stand up against their wrong doings, they would think they would think they are doing a favor. If we do, they won't realize their mistake but would assume personal grudge!
Jun 30 2020
parent reply Clarice <cl ar.ice> writes:
On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
wrote:
 On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:
 On 6/30/2020 1:33 AM, Chris wrote:
 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.
Calling someone "spoiled" is rude and unprofessional. Period.
 IMO, it's neither fair nor good style to single out one 
 sentence from a long post and dismiss the whole post because 
 you consider the sentence to be rude or unprofessional.
People who want their message heard need to post in a professional manner. I don't care about the opinions of rude people. I don't care to work with them, even if they are good. I am hardly alone in this - pretty much nobody in the professional world responds to rude messages.
 And since "professional demeanor" is a flexible term one can 
 always change the criteria as one sees fit (another one is 
 "unspecific" which has become a rather unspecific term too :).
I recommend that anyone who has difficulties understanding what politeness is get a copy of Emily Post's book on business etiquette. Ill-mannered people find themselves shut out of all kinds of opportunities, and they rarely figure out why.
Well said! This is especially applicable for healthy societies and communities. Unrelated to this, but around a month ago I was discussing with a friend of mine who is a psychiatrist on how common narcissism has become these days and is being mistaken for boldness and how leadership roles are being taken by such people and how meritocratic communities tend to expell narcists and kakistocracy communities tend to favor them, especially if it involves money. If we do not point out and stand up against their wrong doings, they would think they would think they are doing a favor. If we do, they won't realize their mistake but would assume personal grudge!
For what it's worth, while I often disagree with Chris' current phrasing and diction, he does have valid points, and I think he has good intentions too. (Frustration, like stress, may be a negative or a positive motivator!) It would probably benefit us all if leadership scheduled a video conference Q&A, or perhaps something more informal, e.g. an 'official' BeerConf, as textual discussions are more prone to faulty and uncharitable inferences. And so that this post is somewhat on-topic, I also like a beefier stdlib. I don't need an HTTP server or graphics, but containers, generic algorithms, protocols, data formats, etc. are all very welcome; Phobos satisfies a good chunk of this list.
Jun 30 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:
 On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
 wrote:
but
 containers, generic algorithms, ..., data formats,
 are all very welcome; Phobos satisfies a good chunk of this 
 list.
That's one thing I've always admired Java for. At least for containers. D has solid generic algorithms thanks to Andrei among others. Containers and common data formats (json, XML, CSV,..) I'm not sure we're there yet. However, there's solid implementations on dub (vibe.data.json, std_data_json, dxml,...) so I personally don't have trouble getting things done. But those are core things that rarely change so fit into a standard library for easy get-go.
Jul 01 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:
 On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
 wrote:
 It would probably benefit us all if leadership scheduled a 
 video conference Q&A, or perhaps something more informal, e.g. 
 an 'official' BeerConf, as textual discussions are more prone 
 to faulty and uncharitable inferences.
Couldn't agree more. Hoping for it. DLF: added to my to-do list, checked :)
Jul 01 2020
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:
 And so that this post is somewhat on-topic, I also like a 
 beefier stdlib.
I wish we had more interfaces and UDAs in there. Today for day job work, I need to do a generic serialize function that can handle std.datetime. It would be very cool if it already worked, if there was a `void serialize(ISerializer)` already there, and/or a ` serializable` attribute. The stdlib doesn't need to implement all the things, but having the interface means it would be easy to reuse all these things without writing as many special-purpose adapters.
Jul 01 2020
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/30/20 5:40 PM, Walter Bright wrote:
 On 6/30/2020 1:33 AM, Chris wrote:
 Personally I think that the sentence was not really rude or insulting 
 but maybe polemical, so within the range of a passionate and heated 
 debate, I'd say, even in a professional environment.
Calling someone "spoiled" is rude and unprofessional. Period.
I disagree with this. "spoiled" is a term to mean "harmed in character by being treated too leniently or indulgently". In that sense, the OP's point (right or wrong) was that you may have an incorrect expectation that someone will volunteer to step up because you have known nothing but people volunteering to do projects without you having to prod people into it. In that sense, this isn't a derogatory or rude term, but conveys accurately what the person is trying to say. I personally would not take offense at someone saying I'm spoiled by D because it has too many awesome features. I have a hard time dealing with other languages because D is too good. It *HAS* spoiled me. Begin even more off-topic rant: I just want to also say, we are somehow in a time where people take so much offense at everything that is said. Basically construing what is said in the worst possible light, and I feel like this doesn't help discussion at all. It derails the discussion and cancels sometimes valid opinions without addressing them. I prefer to think people are mostly just trying to convey a point, and if they do it in a rude way, it's either because I may have misunderstood them (or they aren't familiar with the alternate meaning of what they said), or because they let their emotions get the best of them (it happens to everyone). It can be just as effective to point out the offense, and remind people that we should avoid these kinds of tones, rather than refuse to discuss further (which often has the opposite effect -- escalating). So many online services are starting to cave to the slightest of offenses, and I hope this forum doesn't start doing the same. As a funny anecdote, I worked at a company which bought bagels for everyone every morning. When the delivery would come, the receptionist would email the building saying the bagels are here. One morning she misspelled bagels as beagles and added some phrase like "come and get em while their hot" or something like that. There were many obviously tongue-in-cheek or friendly ribbing responses. One person, however, responded with one word "Cannibal!" It was someone I worked with, so I asked him if he knew what cannibal meant. He said "of course, it means someone who eats cute animals." Needless to say as we were in a more sane time, he was not fired for such an offense, apologized, and we all had a good laugh about it (at his expense of course). Deescalation and humor I find are often a better response than shaming and begrudging. -Steve
Jul 01 2020
next sibling parent matheus <matheus gmail.com> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:
 On 6/30/20 5:40 PM, Walter Bright wrote:
 On 6/30/2020 1:33 AM, Chris wrote:
 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.
Calling someone "spoiled" is rude and unprofessional. Period.
I disagree with this. "spoiled" is a term to mean "harmed in character by being treated too leniently or indulgently". In that sense, the OP's point (right or wrong) was that you may have an incorrect expectation that someone will volunteer to step up because you have known nothing but people volunteering to do projects without you having to prod people into it. In that sense, this isn't a derogatory or rude term, but conveys accurately what the person is trying to say. I personally would not take offense at someone saying I'm spoiled by D because it has too many awesome features. I have a hard time dealing with other languages because D is too good. It *HAS* spoiled me.
One thing to take in count, is there are a lot a foreigners in this forum (Like myself), so one word which may sound "rude" for a native person, may be different for a non native. I think people may forget that during a discussion and I wonder if a flag showing the nationality would be helpful in these situations. Matheus.
Jul 01 2020
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:
[...]
 -Steve
I am of the same sentiment. Thank you for wording this in a de-escalating way, and for raising the spirit on these forums! — Bastiaan.
Jul 01 2020
prev sibling next sibling parent sebasg <h366l6wxik 326oo.anonbox.net> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:
 [...]
 -Steve
I'm happy to read this from a long-time member of the D ng. To be honest I got a (probably unwarranted) bad feeling yesterday when I read WB message. But this is reconforting. Thanks.
Jul 02 2020
prev sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:
 Begin even more off-topic rant:
[...]
 It can be just as effective to point out the offense, and 
 remind people that we should avoid these kinds of tones, rather 
 than refuse to discuss further (which often has the opposite 
 effect -- escalating).
Yes. Exactly. Thank you.
 Deescalation and humor I find are often a better response than 
 shaming and begrudging.

 -Steve
Again, yes. Thanks. The D forum used to be more tolerant and focus on the issues that were raised rather than on the way things were worded. Also, if you have to think carefully about every word in order to sound nice and proper and avoid offense at any cost (somebody is always offended), chances are that the real point of your message gets lost. This could be interpreted as a strategy to muffle dissent.
Jul 02 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:

 Calling someone "spoiled" is rude and unprofessional. Period.
I disagree, you know there is such a thing as context.
 People who want their message heard need to post in a 
 professional manner. I don't care about the opinions of rude 
 people. I don't care to work with them, even if they are good. 
 I am hardly alone in this - pretty much nobody in the 
 professional world responds to rude messages.
That's a bit worrying. So you are saying that you dismiss / don't care about somebody's opinion, because you don't like their style? This is what I would call unprofessional. You have to listen to everybody if they have valid points or good ideas. We're talking about technology, a product, not politics. Note aside: I think the guys who invented / developed the mouse + UI at Xerox were a bunch of "non-conformists" and they were fired (I think). Steve Jobs took them on (or offered more money? Correct me if I'm wrong, I don't know the whole story.)
 I recommend that anyone who has difficulties understanding what 
 politeness is get a copy of Emily Post's book on business 
 etiquette.
"Honesty" can be used as an excuse to hurt somebody, and "politeness" can be used as an excuse to chicken out: "Oh, that was a rude question, I don't need to answer to that. (Emily Post wouldn't have answered to that either, I'm sure.)" Now, here's something about Emily Post: "Emily Post (c. October 27, 1872 – September 25, 1960) was an American author and socialite, famous for writing about etiquette. [...] The New York Times' Dinitia Smith reports, in her review of Laura Claridge's 2008 biography of Post,[4] 'Emily was tall, pretty and spoiled.'" There it is again: "spoiled". :) I wonder is there a link between being spoiled and insisting on etiquette? Anyway, business and technology should not be guided by rules laid down by a socialite (a spoiled one at that!). And thanks be to God, it hasn't, else we wouldn't have the technologies we have. You know, over-insistence on etiquette can also be a sign of stagnation (cf. what the USA achieved vs. Europe) (https://en.wikipedia.org/wiki/Emily_Post)
 Ill-mannered people find themselves shut out of all kinds of 
 opportunities, and they rarely figure out why.
"Ill-mannered" as defined by Emily Post?
Jul 02 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 2 July 2020 at 09:29:26 UTC, Chris wrote:
 On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:

 not politics.
Note aside: I think the guys who invented / developed the mouse + UI at Xerox were a bunch of "non-conformists" and they were fired (I think). Steve Jobs took them on (or offered more money? Correct me if I'm wrong, I don't know the whole story.)
Interesting. That guy hunted for talents like crazy. I think they once used the "Think Different" pitch. Sometimes it also depends on culture. Not sure though. But here people "fight" and eat from the same bowl. But since this in an international community, it's safer to avoid certain words in certain contexts. Sometimes we're just tired and frustrated with this software thing. It's fast changing, we need to get things done and if sometimes is not working put how you think you want it, it can take a huge toll on your emotions. I try (or at least I'm trying) to l assume people have good intent and be positive biased...in a world of increasing negativity biasness.
Jul 02 2020
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 16:42:36 UTC, aberba wrote:
 Almost the exact reason why i use JavaScript (nodejs) for work 
 and not D. It takes more than a nice language. When some here 
 say they don't use Dub or they don't care about dub packages, 
 I'm wondering what kind of software they are writing.

 In my line if work, it's highly dependant of availability of 
 packages to get the job done. Encryption, networking, data 
 manipulation, database connectors, socket, rest, cloud 
 services, etc. Its more like glueing services and APIs together.

 Unless you're building compilers and softwares that don't 
 connect to internet, then it makes sense to not be bothered by 
 the lack of certain packages on dub.

 This will only happen when the community collaborates, which 
 will only happen when there's a visible leadership 
 push/backing. I meant D conf online has taken forever to happen 
 and I'm not sure if community building is a thing prioritized 
 at all.


 I've been policing and trying several packages on dub...some, 
 talking to their maintainers. I want to make this happen. Its 
 the only way.

 I rarely use core nodejs packages. Its like npm has got 
 everything. Its what dub needs. Already I'm happy with quite a 
 few dub packages. And there's huge!! room for improvement if 
 only there's a visible official push. Its not always about 
 money.

 I'm not sure why we don't even have regular online community 
 meetups. Yeah, there's people who would rather code and feel 
 more productive that way. That's also fine.

 Except there's another side about community building. DConf is 
 a Joy to watch. Just the community interaction alone and how 
 ideas are shared. It could happen more often. More often online.
I agree with everything you said. Currently, *each* member of my dev team lives in a different country and in a different time zone, so all my day is spent in online collaboration (chat, audio and video calls) so I also can't understand why there hasn't been a stronger push for this kind of communication in D. https://dlang.slack.com/ has been a great improvement in this regard from the past couple of years, but it is insufficient.
Jun 25 2020
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 25, 2020 at 04:42:36PM +0000, aberba via Digitalmars-d wrote:
[...]
 Almost the exact reason why i use JavaScript (nodejs) for work and not
 D. It takes more than a nice language. When some here say they don't
 use Dub or they don't care about dub packages, I'm wondering what kind
 of software they are writing.
Don't get me wrong, I'm not downplaying dub packages. But for my projects, it's mainly local computation and data processing and transformation. One project *is* related to publishing on a website, but it's almost entirely prerendered static pages, so virtually all of the processing is done in batch-oriented mode beforehand.
 In my line if work, it's highly dependant of availability of packages
 to get the job done. Encryption, networking, data manipulation,
 database connectors, socket, rest, cloud services, etc. Its more like
 glueing services and APIs together.
Actually, even in this area D shines, because of the ease of wrapping existing C/C++ libraries. If there's a C API for some library that provides the functionality you need, it's easy to interface with it. I've interfaced with e.g. libfreetype, X11, sqlite3, and a bunch of other libraries, and it's pretty convenient. Of course, the best is if there's an existing D binding, then it's just plug-in and go, but even where there isn't an existing binding, it's still pretty easy to declare the C prototypes on an as-needed basis (which is what I did with X11 -- translating the entire X11 headers is too much work, and most of the API I don't even need anyway, so I just declare what I need and add more as the need arises).
 Unless you're building compilers and softwares that don't connect to
 internet, then it makes sense to not be bothered by the lack of
 certain packages on dub.
It depends on what kind of software you're building, certainly. If you're writing code for today that will be obsolete in 2-5 years' time, then having a dub dependency pull in 200 dependencies is not a problem, because by the time it becomes a problem you'll already have moved on anyway. I write my code to last; so anything that increases the likelihood of future breakage is a big disincentive for me. I really do not wish to be rewriting a module that was working perfectly fine before, but broke because some obscure dependency or sub-dependency decided to change things in a way that breaks the way my code uses it. I consider that time-wasting churn. That doesn't mean I expect code to be static -- but any change has to make actual progress, as in fixing a bug or adding a new feature, or improving the quality of the code, not just change for change's sake because of external factors completely unrelated to what I'm doing.
 This will only happen when the community collaborates, which will only
 happen when there's a visible leadership push/backing.
I'm not following this logic. Why can't the community collaborate in spite of perceived lack of visible leadership push/backing? The two are not mutually exclusive. In fact, this being a volunteer-driven project, even if the leadership *does* push for community collaboration, it doesn't guarantee it will actually happen. Volunteers do whatever they want to do, not what they're told to do, after all. [...]
 I'm not sure why we don't even have regular online community meetups.
Because so far, nobody has stepped up to take charge of it. Since you feel so strongly about this, why not be the one to take charge? Set up an online meeting, post an announcement here to recruit people, and get the ball rolling. Nobody's going to stop you, and in fact, judging by what many people are saying, probably a lot of people will appreciate the effort and support you. If your effort turns out to be successful, it could even convince the BFDL(s) to officially endorse it.
 Yeah, there's people who would rather code and feel more productive
 that way.  That's also fine.
[...] Personally, I have very limited time as it is to work on my D projects, so whatever little time I have, I'd really rather devote to making progress with my code than to participate in yet another online meeting/forum/what-not (which I already have more than enough of). But that's just me, personally; I don't speak for anyone else here. And I also have no opposition to such a thing, should you decide to take it up. I might even support you in the background. And I'm sure a good number of people here will support you too, based on what people have been saying about this. So how about it? Since D is lacking in this area, here's your opportunity to fill the gap. Show us how to run the community better than we have been. We'll support you. Show us how to make things take off. T -- It's bad luck to be superstitious. -- YHL
Jun 25 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:
 The Rust community has realized that a slim standard library + 
 a solid package manager is the way to go.
The practice seems to indicate that the theory is false. The very first Rust program I built with Rust was an _example_ program for the Amethyst game engine (granted, a big endeavour). It downloaded _146_ packages and then proceeded to build them at a glacial pace. This was a really "npm" moment. In D my _full_ products have 6 packages (24 when counting sub-packages). It seems slim stdlib has enormous community implications and require inordinate amount of coordination and agreements ; it changes the whole culture.
Jun 25 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:28:27 UTC, Guillaume Piolat wrote:
 On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
 [ZombineDev] wrote:
 The Rust community has realized that a slim standard library + 
 a solid package manager is the way to go.
The practice seems to indicate that the theory is false. The very first Rust program I built with Rust was an _example_ program for the Amethyst game engine (granted, a big endeavour). It downloaded _146_ packages and then proceeded to build them at a glacial pace. This was a really "npm" moment. In D my _full_ products have 6 packages (24 when counting sub-packages). It seems slim stdlib has enormous community implications and require inordinate amount of coordination and agreements ; it changes the whole culture.
The only thing that I need to say is that our team uses npm (actually yarn) for our stack and we're doing very well :) So 146 number is pretty laughable in comparison. Running `yarn list | wc -l` on a random project of our gives me 7368 :D Whether this is a good thing is a different question altogether, but in practice, this is not an issue at all for us and for thousands of other JS/TS teams around the world. What I know is that npm and yarn handle this huge (in comparison) number very well, but I'm not so sure about Dub. For example, yarn.lock has the SHA-512 of each of my dependencies. dub.selections.json only includes the version numbers.
Jun 25 2020
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 25 June 2020 at 14:41:49 UTC, Petar Kirov 
[ZombineDev] wrote:
 So 146 number is pretty laughable in comparison. Running `yarn 
 list | wc -l` on a random project of our gives me 7368 :D
I'l assume your post isn't satire ^^ This doesn't rezally work for native since: - there is the cost of compiling this ahead of time, which isn't negligible and with a cost structure unlike Javascript (in the best case, code has to be compiled in and then stripped by linker, very slow) - native programs have many possibilities to go wrong (deadlocks, threading, memory allocations...) and that differs from project to project ; you cannot enforce any invariant with such a number of libraries. And it's a huge hurdle for "common off the shelf" libraries.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:30:18 UTC, Guillaume Piolat wrote:
 On Thursday, 25 June 2020 at 14:41:49 UTC, Petar Kirov 
 [ZombineDev] wrote:
 So 146 number is pretty laughable in comparison. Running `yarn 
 list | wc -l` on a random project of our gives me 7368 :D
I'l assume your post isn't satire ^^
Yes, it's just a real, random data point, which is pretty typical for many frontend projects nowadays :/
 This doesn't rezally work for native since:
 - there is the cost of compiling this ahead of time, which 
 isn't negligible and with a cost structure unlike Javascript 
 (in the best case, code has to be compiled in and then stripped 
 by linker, very slow)
I know, I know. We use TypeScript, so our code and many of our dependencies actually need to be compiled, before the program can be executed. For example, running a project after git clone takes between 1-10mins. (When it's more than 2-3 mins it's actually because of C/C++. Many nodejs packages are actually C/C++ code with JS bindings, which needs to be compiled on npm install, because in the npm world, typically they ship only source code and not binaries. And also because before Node didn't have a stable ABI, so if you wanted to support Node.js versions released in the past several years, you would have to ship 20 different binaries of the same library :D) But that's just the first time, because TypeScript and React.js (through webpack) have incremental compilation, so each change takes less than several seconds (in many cases less than 1 sec). By change, I mean the time to typecheck and emit JS code. Of course I'm well aware that this is not a fair comparison to pure "native" languages.
 - native programs have many possibilities to go wrong 
 (deadlocks, threading, memory allocations...) and that differs 
 from project to project ; you cannot enforce any invariant with 
 such a number of libraries. And it's a huge hurdle for "common 
 off the shelf" libraries.
A fork bomb is possible with almost all languages in practice. Every npm package has the ability to run random js code on install, which runs with the privileges of the current user. "A security nightmare" - you say, but in practice it's not that bad, given they have invested much more than us in a process of managing security vulnerabilities: https://docs.npmjs.com/reporting-a-vulnerability-in-an-npm-package https://www.npmjs.com/policies/security
Jun 25 2020
prev sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:28:27 UTC, Guillaume Piolat wrote:
 It seems slim stdlib has enormous community implications and 
 require inordinate amount of coordination and agreements ; it 
 changes the whole culture.
I just want to add that this is a *very* important point. We definitely need more collaboration and coordination in our community. Some examples: - dstep, dpp, Calypso - install.sh, dvm, digger (much broader scope, but can also do what dvm does, AFAIR), setup-dlang (only usable for GitHub actions, but actually replicates the code of install.sh and dvm to some extent). - various nogc libraries (containers, threading, etc.) - various networking libraries - etc. I guess, the most important thing that I see in other language communities that I miss in D is exactly the coordination and cooperation. Of course it's very far from perfect in all of them, but it still feels that D is falling behind. And I think that this is not a money problem, but a community and leadership problem.
Jun 25 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 25, 2020 at 06:52:05AM +0000, Petar via Digitalmars-d wrote:
[...]
 I suggest checking http://mir-algorithm.libmir.org/.
 Ilya has been doing a truly amazing job at both developing,
 maintaining and optimizing this library.
 Also he has put a hard focus on memory allocators,  nogc and betterC
 (for exposing libmir to C and C++ users and also for scripting
 languages like Python or Julia).
I'm aware of Ilya's work, and have been meaning to look it up, but haven't had the time. And also I'm working with different constraints: I primarily work with batch-oriented computations, so nogc is not really on my radar (though I do try to minimize GC use for obvious reasons), and betterC isn't really under consideration for what I need to do. So these factors in Mir don't really stand out to me as much as they may to others. [...]
 Meanwhile, if you look at std.numeric, for past several years,
 basically all contributions but a few have been just around basic
 stuff like code style, imports and fixing a few compile errors in
 generic code.
I'm not sure what this has to do with anything. If an algorithm is solidly implemented, why would there need to be a continuous stream of changes? And just because something is changing quickly, doesn't necessarily equate to higher quality.
 Phobos is dead. There haven't been any new modules since ~2016.
 Actually the last one (IIRC) was std.experimental.ndslice, which Ilya
 contributed and then removed (1-2 releases after) from Phobos to start
 libmir.
 
 Since std.experimental.allocator was added to Phobos circa 2015, there
 hasn't been a single Phobos or Druntime module using it (ndslice and
 checkedint don't count). Many packages on code.dlang.org
 enthusiastically embraced std.experimental.allocator only to get
 burned a few dmd releases after as Phobos doesn't follow SemVer.
Um... it's std.*experimental* for a reason? Why are people surprised when it changes? OTOH, though, you do have a valid point about the distribution model. Phobos is locked to compiler releases, and while that does have its advantages in some areas, it also comes with disadvantages.
 The solution? Many of the most popular OSS D apps libraries (I can
 only comment on those) transitioned to using the Dub fork:
 https://github.com/dlang-community/stdx-allocator. How does it help?
 Well, OSS D libraries can't control the compiler that their users are
 using. For example, vibe.d tries to support the last 5 major versions
 of dmd/ldc, and Dub the last 15+ major versions. This means they can't
 depend on std.experimental.* as there's no telling what kind changes
 can happen for such a large timespan. Instead they can stick a
 particular version of https://code.dlang.org/packages/stdx-allocator
 in their dub.{json,sdl} file and be sure that it won't suddenly break
 their code.
This is a good case to make for prospective new Phobos modules to start out as Dub packages, gain some real-world usage and traction, then promote to Phobos. Introducing packages directly into Phobos (via std.experimental or otherwise) has proven to be high-risk, and in some cases disastrous.
 The sooner we realize this and start collectively working on improving
 Dub and code.dlang.org, the better. Yes, Dub is not a great build
 tool. And so what? Most great build tools were not so great in their
 infancy. I doubt Scons was much better in 1999. If people continue
 avoiding Dub for whatever reason it won't get better by itself.
In 1999, SCons was not yet; there was its predecessor Cons, which has a hard-to-maintain Perl script. But the basic concepts that make it awesome were already there. This is a key point: it started out on the right principles, and even though the implementation left some things to be desired, it had the right footing and therefore had the foundation to move on to be even better. Dub, IMO, started out with the wrong principles, or should I say, different principles from what I expect a build tool to have, and therefore unless it undergoes a fundamental, breaking rewrite from ground up, I doubt it will ever reach my expectations of a build tool. There are many advantages to integrating a build tool with a package manager, I suppose, but TBH the way Dub does it is rather disappointing. IMO, a package manager ought to be distinct from a build tool, even if they do build(!) off each other. Dub is actually not bad as a package manager, but as a build tool I simply cannot vouch for it. If you were to ask me, the first step to improving Dub would be to separate the package manager from the build tool. As in, completely extricate one from another so that they are usable as independent pieces. (Note: this does not mean the user-facing driver cannot depend on both at the same time.) The next step, IMO, would be to separate the package manager code from its unfriendly user-interface and make it dub-as-a-library. That would be something I can work with.
 There's no reason why Dub can't expose a lower-level DSL for precise
 target dependency graph building. It's just a matter of people making
 a sustained effort in contributing one.
TBH, I would much rather have dub-as-a-library than to try to monkey-patch yet another hack on top of a foundation not designed to support this sort of usage.
 The Rust community has realized that a slim standard library + a solid
 package manager is the way to go.
[...] TBH, lately I've become skeptical of this approach. More than a few times, I have been bitten by (non-D) libraries I depend on (in my non-D projects) that have either become too obsolete and doesn't compile anymore, or the new version has breaking changes that cannot be easily worked around, or the network resource serving that library has mysteriously vanished into the ether, never to be found again, and also by external tools whose interfaces have changed, or worst of all, whose behaviour has subtly changed in fundamentally incompatible ways that cannot be remedied. Also lately, shared libraries that broke ABI compatibility just because I upgraded an OS package, causing half of my programs to instantly become unrunnable. As a result, I've become highly skeptical about the whole code reuse mantra. Where's the actual code reuse when it entails installing 5 different versions of the same library just because different programs (or worse, different components of the same program) depend on different versions? This is dependency hell reincarnated. What's the use of depending on external programs that vanish into the ether, or get changed in incompatible ways so that the only recourse is to keep a copy of the old code around forever? (Fortunately, I only use open source tools for this purpose; at least I keep a copy of the code around as long as it remains compilable; imagine the disaster if it was a proprietary tool that's no longer maintained, vanished into the ether, or plain just doesn't run anymore on the latest OS.) That's why I generally avoid libraries that have deep dependencies -- imagine all of the above multiplied recursively per dependent package. Truly it's dependency hell reincarnated. Instead, I look for libraries like Adam Ruppe's arsd library, where most of the code has minimal dependencies and can be used by literally just copying the danged file into your source tree, where it will always be available, and is guaranteed to be exactly the same code you last left it as and won't subtly change and break stuff because some 3rd party network resource somewhere out there in the ether decided to change it. And where calling a single lousy function does not pull in 2,345 irrelevant dependencies that slow your build time down to an unusable crawl. (And TBH, any library that requires pulling in that many recursive dependencies makes me skeptical as to the quality of its design. IMNSHO a properly-designed library ought to be as orthogonal as possible to anything else, and to focus solely on providing that special functionality that is its raison d'etre, and nothing else. It isn't as though this is C, where composability is limited and a lot of external things have to be baked into the library API just for it to be generally applicable; in D we have metaprogramming, delegates, and all of that good stuff that can be employed to eliminate all unnecessary library dependencies and provide a powerful composable API that's completely orthogonal to whatever's outside of its purview. If a library requires 234 dependencies in order to do its job, perhaps it should get a new job! :-P) T -- Живёшь только однажды.
Jun 25 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 16:20:54 UTC, H. S. Teoh wrote:
 On Thu, Jun 25, 2020 at 06:52:05AM +0000, Petar via 
 Digitalmars-d wrote: [...]
 I suggest checking http://mir-algorithm.libmir.org/.
 Ilya has been doing a truly amazing job at both developing,
 maintaining and optimizing this library.
 Also he has put a hard focus on memory allocators,  nogc and 
 betterC
 (for exposing libmir to C and C++ users and also for scripting
 languages like Python or Julia).
I'm aware of Ilya's work, and have been meaning to look it up, but haven't had the time. And also I'm working with different constraints: I primarily work with batch-oriented computations, so nogc is not really on my radar (though I do try to minimize GC use for obvious reasons), and betterC isn't really under consideration for what I need to do. So these factors in Mir don't really stand out to me as much as they may to others. [snip]
BTW, `mir` is not always and everywhere nogc. It can be mixed with GC code. For instance, the `sliced` function will use the GC to allocate a slice. However, it also has facilities for allocating malloc'ed and referenced-counted slices. However, one design goal is that it can also be used nogc.
Jun 29 2020
parent Andy Balba <pwplus7 gmail.com> writes:
On Monday, 29 June 2020 at 19:37:37 UTC, jmh530 wrote:
 On Thursday, 25 June 2020 at 16:20:54 UTC, H. S. Teoh wrote:
 [...]
BTW, `mir` is not always and everywhere nogc. It can be mixed with GC code. For instance, the `sliced` function will use the GC to allocate a slice. However, it also has facilities for allocating malloc'ed and referenced-counted slices. However, one design goal is that it can also be used nogc.
BTW IMNSHO TBH nogc everything !
Aug 10 2020
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!
What if the language you're using doesn't have FFT in its standard lib? Hm. Maybe this would be a good starting point: http://rosettacode.org/wiki/Fast_Fourier_transform Maybe in other languages there are third party libraries that handle things like FFT, well, so I have heard. Never mind.
Jun 25 2020
prev sibling next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 [...]
I don't think I'm a good enough programmer to know that Phobos is bad. import std.stdio; import std.algorithm; import std.range; import std.conv : to; and I'm a happy man! Jordan
Jun 25 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 26, 2020 at 03:02:20AM +0000, Jordan Wilson via Digitalmars-d wrote:
[...]
 I don't think I'm a good enough programmer to know that Phobos is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;
 
 and I'm a happy man!
[...] These days, if you use a recent compiler, it's even easier: import std; And off you go. :-P Only catch is, sometimes you might run into some unfortunate name conflicts within Phobos (e.g., std.file.remove vs. std.algorithm.remove). But for the most part, it's very convenient for one-off scripts. Even better yet, I've recently acquired the taste for one-line D programs using `dmd -i -run -`, and a lot of these take advantage of `import std;` for its conciseness: echo 'import std;void main(){writeln("Hello world");}' | dmd -run - echo 'import std;pragma(msg, PI);' | dmd -o- - echo 'import std;void main(){writeln([1,2,3].canFind(1));}' | dmd -run - And also, one-line tests of code in the current directory tree: echo 'import mymod;pragma(msg, typeof(mymod.someSymbol));' | dmd -i -o- - echo 'import mymod;pragma(msg, is(typeof(myFun(3.14f))));' | dmd -i -o- - echo 'import mymod;void main(){writeln(myFun(3.14f));}' | dmd -i -run - Or generate complex output for other programs using the expressive power of D code: echo 'import std;void main(){writeln(iota(0.0, 100.0).map!(x=>sin(x)).filter!(x=>x > 0.5));}' | dmd -run - | sort Maybe we should have a Most Useful One-Line D Program contest. :-P T -- People say I'm arrogant, and I'm proud of it.
Jun 25 2020
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:


 	echo 'import std;void main(){writeln("Hello world");}' | dmd 
 -run -


 	echo 'import std;pragma(msg, PI);' | dmd -o- -


 	echo 'import std;void main(){writeln([1,2,3].canFind(1));}' | 
 dmd -run -

 And also, one-line tests of code in the current directory tree:



 	echo 'import mymod;pragma(msg, typeof(mymod.someSymbol));' | 
 dmd -i -o- -


 	echo 'import mymod;pragma(msg, is(typeof(myFun(3.14f))));' | 
 dmd -i -o- -


 	echo 'import mymod;void main(){writeln(myFun(3.14f));}' | dmd 
 -i -run -

 Or generate complex output for other programs using the 
 expressive power of D code:


 	echo 'import std;void main(){writeln(iota(0.0, 
 100.0).map!(x=>sin(x)).filter!(x=>x > 0.5));}' |  dmd -run - | 
 sort


 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P


 T
I’ll make a mental bookmark of this, thanks! — Bastiaan.
Jun 26 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:

 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P
Or a blog post showing off all of this and explaining the compiler flags :-)
Jun 26 2020
parent reply tastyminerals <tastyminerals gmail.com> writes:
On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:
 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:

 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P
Or a blog post showing off all of this and explaining the compiler flags :-)
That would be great if someone could do this! I would like to learn and show off the D one-liners in the company.
Jul 08 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:
 On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:
 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:

 Maybe we should have a Most Useful One-Line D Program 
 contest. :-P
Or a blog post showing off all of this and explaining the compiler flags :-)
That would be great if someone could do this! I would like to learn and show off the D one-liners in the company.
How interested are you in making this D one-line showcasing thing happen? Been thinking, its something that needs to happen.
Jul 17 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:
 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:
 On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:
 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:

 Maybe we should have a Most Useful One-Line D Program 
 contest. :-P
Or a blog post showing off all of this and explaining the compiler flags :-)
That would be great if someone could do this! I would like to learn and show off the D one-liners in the company.
How interested are you in making this D one-line showcasing thing happen? Been thinking, its something that needs to happen.
Especially now that there's some momentum in getting the D wiki up to speed.
Jul 17 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 17, 2020 at 08:44:40PM +0000, aberba via Digitalmars-d wrote:
 On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:
 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:
[...]
 That would be great if someone could do this! I would like to
 learn and show off the D one-liners in the company.
How interested are you in making this D one-line showcasing thing happen? Been thinking, its something that needs to happen.
Especially now that there's some momentum in getting the D wiki up to speed.
Check out the scriptlike dub package. It has a bunch of stuff that makes scripting tasks easier (i.e., less verbose). If you have scriptlike installed, one-liners could potentially be even more compact. T -- Don't modify spaghetti code unless you can eat the consequences.
Jul 17 2020
parent aberba <karabutaworld gmail.com> writes:
On Friday, 17 July 2020 at 21:14:19 UTC, H. S. Teoh wrote:
 On Fri, Jul 17, 2020 at 08:44:40PM +0000, aberba via 
 Digitalmars-d wrote:
 On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:
 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals 
 wrote:
[...]
 That would be great if someone could do this! I would like 
 to learn and show off the D one-liners in the company.
How interested are you in making this D one-line showcasing thing happen? Been thinking, its something that needs to happen.
Especially now that there's some momentum in getting the D wiki up to speed.
Check out the scriptlike dub package. It has a bunch of stuff that makes scripting tasks easier (i.e., less verbose). If you have scriptlike installed, one-liners could potentially be even more compact. T
Interesting. It's very well documented too.
Jul 17 2020
prev sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:
 On Fri, Jun 26, 2020 at 03:02:20AM +0000, Jordan Wilson via 
 Digitalmars-d wrote: [...]
 [...]
[...] These days, if you use a recent compiler, it's even easier: [...]
Just now I wanted to find the max value of a column in a text file, my thinking went "Excel? It'll take ages to load...I'll just google awk or something...hang on a minute, didn't I read somewhere about D oneliners?" echo 'import std; void main() { File("emu.sift","r").byLine.map!(a => a.splitter(" ").front.to!double).maxElement.writeln; }' | dmd -run - Thanks! Jordan
Jul 06 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jul 06, 2020 at 08:47:36PM +0000, Jordan Wilson via Digitalmars-d wrote:
[...]
 Just now I wanted to find the max value of a column in a text file, my
 thinking went "Excel? It'll take ages to load...I'll just google awk
 or something...hang on a minute, didn't I read somewhere about D
 oneliners?"
 
 echo 'import std; void main() { File("emu.sift","r").byLine.map!(a =>
 a.splitter(" ").front.to!double).maxElement.writeln; }' | dmd -run -
[...] Awesome stuff!! We should collect a library of these one-liners, maybe on the wiki or something, that can serve as a useful reference. It can also be used to show off D's capabilities too. T -- "You are a very disagreeable person." "NO."
Jul 07 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:
 [...]

 Awesome stuff!!  We should collect a library of these 
 one-liners, maybe on the wiki or something, that can serve as a 
 useful reference.  It can also be used to show off D's 
 capabilities too.


 T
dmd -run code.d | dmd -
Jul 09 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:
 [...]

 Awesome stuff!!  We should collect a library of these 
 one-liners, maybe on the wiki or something, that can serve as 
 a useful reference.  It can also be used to show off D's 
 capabilities too.


 T
dmd -run code.d | dmd -
So that compiles and runs code.d and then passes the result to dmd to build?
Jul 09 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 09, 2020 at 03:58:19PM +0000, jmh530 via Digitalmars-d wrote:
 On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov [ZombineDev] wrote:
 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:
 [...]
 
 Awesome stuff!!  We should collect a library of these one-liners,
 maybe on the wiki or something, that can serve as a useful
 reference.  It can also be used to show off D's capabilities too.
 
 
 T
dmd -run code.d | dmd -
So that compiles and runs code.d and then passes the result to dmd to build?
Meaning, code.d generates D code that is run on the spot. Here's another one: the most powerful one-line D program that ever existed and will ever exist. It can do literally anything you tell it do, and best of all, it doesn't even take up that much space. In fact, it takes literally no disk space at all. All you have to do is to run the following one-liner, and type in what you want it to do as D code, and it will do it! How amazing is that??? cat | dmd -run - :-P T -- Give me some fresh salted fish, please.
Jul 09 2020
parent reply tastyminerals <tastyminerals gmail.com> writes:
On Thursday, 9 July 2020 at 16:26:09 UTC, H. S. Teoh wrote:
 On Thu, Jul 09, 2020 at 03:58:19PM +0000, jmh530 via 
 Digitalmars-d wrote:
 On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov 
 [ZombineDev] wrote:
 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:
 [...]
dmd -run code.d | dmd -
So that compiles and runs code.d and then passes the result to dmd to build?
Meaning, code.d generates D code that is run on the spot. Here's another one: the most powerful one-line D program that ever existed and will ever exist. It can do literally anything you tell it do, and best of all, it doesn't even take up that much space. In fact, it takes literally no disk space at all. All you have to do is to run the following one-liner, and type in what you want it to do as D code, and it will do it! How amazing is that??? cat | dmd -run - :-P T
Without args cat reads from stdin and outputs to stdout which dmd -run - catches. However, I typed writeln("hello D"); after the one-liner above, hit enter and nothing happened. Hit enter again, nothing.
Jul 16 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 16, 2020 at 06:41:42PM +0000, tastyminerals via Digitalmars-d wrote:
 On Thursday, 9 July 2020 at 16:26:09 UTC, H. S. Teoh wrote:
[...]
 Here's another one: the most powerful one-line D program that ever
 existed and will ever exist. It can do literally anything you tell
 it do, and best of all, it doesn't even take up that much space.  In
 fact, it takes literally no disk space at all.  All you have to do
 is to run the following one-liner, and type in what you want it to
 do as D code, and it will do it!  How amazing is that???
 
 	cat | dmd -run -
 
 :-P
 
 
 T
Without args cat reads from stdin and outputs to stdout which dmd -run - catches. However, I typed writeln("hello D"); after the one-liner above, hit enter and nothing happened. Hit enter again, nothing.
You have to end your input with ctrl-D. DMD is not a REPL so it's not going to evaluate individual input lines immediately. But anyway, this particular one is a joke that refers to one of the winning entries of the IOCCC from 1988 (see the entry by spinellis), consisting of the single line: #include "/dev/tty" It probably no longer works on modern C compilers, but the intent ought to be obvious. :-) T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Jul 16 2020
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:
 Just now I wanted to find the max value of a column in a text 
 file, my thinking went "Excel? It'll take ages to load...I'll 
 just google awk or something...hang on a minute, didn't I read 
 somewhere about D oneliners?"

 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan
IMO this still doesn't hold a candle to the awk version: awk '{ if ($1 > max) max = $1 } END { print max }' With better library functions, though, the D version could be much, much nicer. Something like: stdin.byRecord.map(r => r.fields[0]).maxElement
Jul 07 2020
next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Tuesday, 7 July 2020 at 23:38:26 UTC, Paul Backus wrote:
 On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:
 Just now I wanted to find the max value of a column in a text 
 file, my thinking went "Excel? It'll take ages to load...I'll 
 just google awk or something...hang on a minute, didn't I read 
 somewhere about D oneliners?"

 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan
IMO this still doesn't hold a candle to the awk version: awk '{ if ($1 > max) max = $1 } END { print max }' With better library functions, though, the D version could be much, much nicer. Something like: stdin.byRecord.map(r => r.fields[0]).maxElement
Oh I agree the awk version is nicer (as is your theoretical D version). But I couldn't write that off the top of my head, whereas the D version I could. Here's something I just did now that might be more relevant: echo 'import std; void main() { "bets.json".readText.parseJSON.toPrettyString.writeln; }' | dmd -run - | more I did this without looking up anything. Whereas before this echo/import std; into dmd -run trick, I would have opened up vim, and hoped that my previous command to pretty print was still in the history! (using python if I remember correctly). I *think* that writing a more slightly more verbose D one-liner without needing to reference anything might prove itself useful to me in the long run, but we shall see. Jordan
Jul 07 2020
next sibling parent reply Panke <tobias pankrath.net> writes:
On Wednesday, 8 July 2020 at 03:53:55 UTC, Jordan Wilson wrote:
 Here's something I just did now that might be more relevant:
 echo 'import std; void main() { 
 "bets.json".readText.parseJSON.toPrettyString.writeln; }' | dmd 
 -run - | more

 I did this without looking up anything. Whereas before this 
 echo/import std; into dmd -run trick, I would have opened up 
 vim, and hoped that my previous command to pretty print was 
 still in the history! (using python if I remember correctly).
 Jordan
Have a look at jq [1] and jqed. What's up with the bets? Writing a betfair bot by any chance? [1] https://stedolan.github.io/jq/
Jul 08 2020
parent Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 8 July 2020 at 07:39:03 UTC, Panke wrote:
 On Wednesday, 8 July 2020 at 03:53:55 UTC, Jordan Wilson wrote:
 Here's something I just did now that might be more relevant:
 echo 'import std; void main() { 
 "bets.json".readText.parseJSON.toPrettyString.writeln; }' | 
 dmd -run - | more

 I did this without looking up anything. Whereas before this 
 echo/import std; into dmd -run trick, I would have opened up 
 vim, and hoped that my previous command to pretty print was 
 still in the history! (using python if I remember correctly).
 Jordan
Have a look at jq [1] and jqed.
After writing the post, I recalled that several months ago I actually did install jq for that very issue of just quickly inspecting a json file, but clearly forgot all about it. I suppose it illustrates my general point...a familiar sledgehammer might be more useful than an unfamiliar hammer.
 What's up with the bets?
Haha, not a bot, but rather data gathering of NBA odds (before everything was shut down). Jordan
Jul 08 2020
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
Maybe we should add an option to rdmd that compile and run a 
string, importing std automatically? Writing one-liners would be 
as easy as
rdmd -dscript 'writeln("hello, shell");'
Jul 08 2020
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:
 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'
rdmd --eval 'writeln("hello, shell");' ``` --eval=code evaluate code as in perl -e (multiple --eval allowed) --loop assume "foreach (line; stdin.byLine()) { ... }" for eval ```
Jul 08 2020
parent Ogi <ogion.art gmail.com> writes:
On Wednesday, 8 July 2020 at 10:34:55 UTC, Dennis wrote:
 On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:
 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'
rdmd --eval 'writeln("hello, shell");' ``` --eval=code evaluate code as in perl -e (multiple --eval allowed) --loop assume "foreach (line; stdin.byLine()) { ... }" for eval ```
Whoa! rdmd is cool, too.
Jul 08 2020
prev sibling parent MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:
 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'
Try rdmd --eval='writeln("hello, shell");'
Jul 08 2020
prev sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 7 July 2020 at 23:38:26 UTC, Paul Backus wrote:
 On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:
 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan
IMO this still doesn't hold a candle to the awk version: awk '{ if ($1 > max) max = $1 } END { print max }' With better library functions, though, the D version could be much, much nicer. Something like: stdin.byRecord.map(r => r.fields[0]).maxElement
Not in one liner form readText("emu.sift").csvReader!(Tuple!(double))(' ').map!(x => x[0]).maxElement.writeln; I wanted to us https://dlang.org/phobos/std_range.html#transversal But that didn't work for a few reasons. It would be nice because this example isn't good if trying to do something with say the 25 element.
Jul 07 2020
prev sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Friday, 26 June 2020 at 03:02:20 UTC, Jordan Wilson wrote:
 I don't think I'm a good enough programmer to know that Phobos 
 is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;

 and I'm a happy man!

 Jordan
I'm a real noob as well. I'm so bad, I also import std.format.
Jun 29 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jun 29, 2020 at 12:20:23PM +0000, Robert Schadek via Digitalmars-d
wrote:
 On Friday, 26 June 2020 at 03:02:20 UTC, Jordan Wilson wrote:
 
 I don't think I'm a good enough programmer to know that Phobos is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;
 
 and I'm a happy man!
 
 Jordan
I'm a real noob as well. I'm so bad, I also import std.format.
LOL! I *always* import std.format, it's so convenient, I can't live without it! In spite of its very well-known flaws. T -- It's bad luck to be superstitious. -- YHL
Jun 29 2020
prev sibling parent tastyminerals <tastyminerals gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:
 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 1) std.bigint: one time, I was working on a quadratic 
 irrational arithmetic module, and pretty quickly discovered 
 that numerical overflow was a problem that cropped up pretty 
 often.  Or rather, I was seeing what I *thought* was caused by 
 arithmetic overflow, and wanted to be sure.  Solution?  Easy: 
 templatize the coefficient type, import std.bigint, and within 
 several minutes, I have a working implementation that can 
 support arbitrarily large coefficients -- with which I not only 
 confirmed that the observed problems were caused by arithmetic 
 overflow, but also obtained a working solution simultaneously.  
 Win!

 2) std.numeric.poly: another time, I had to work with 
 evaluating a bunch of polynomials, and specifically, with 
 evaluating their roots quickly and accurately.  I could roll my 
 own, poorly, and get results that may or may not be 
 highly-skewed by accumulated errors... or I could use 
 std.numeric.poly to get a reliable evaluation of the 
 polynomial, and, better yet, use std.numeric.findRoot to 
 compute roots with the confidence that the value I get will 
 have as small an error as is possible within the constraints of 
 built-in hardware floats. Plus, this saved me tons of 
 development and debugging time to roll my own solution. Win!

 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!

 Seriously, D + Phobos is cool beans.  Yes it's not perfect -- 
 the language has its fair share of dark corners, WATs, and 
 Phobos has its share of poorly-designed APIs and outdated 
 modules.  But seriously, a lot of what's currently there is 
 pretty darned cool, and we shouldn't let all the bad stuff 
 cloud our appreciation of just how cool it already is.


 T
I was honestly surprised to read here that Phobos gets a bad name. But I am not a D expert to judge anyway. For example, I simply can't stand Python stdlib docs and only go there when everything else fails. They are really hard to read for me for some unknown reason (design, wording or both?) and I know that I am not alone in this. But Python can get away with it, right and why's that? :) On the contrary Scala standard library is a great example of being well written and designed. Personally, I was impressed by Phobos once I started going through the docs for the first time after reading Ali's "Programming in D" book. It is actually Phobos that made me believe that D has a solid and rich standard library. I was pleasantly surprised that description of many functions contained complexity information and pragmatically explained how things work. For example, std.algorithm contains many cool things like "balancedParens" or "levenshteinDistance" (which even Python doesn't have and needs an external C++ lib to use). I like how each module is split into logical groups and how the function names are simply linguistically more precise. If there is no a function that you expect to have, you get a feeling that it is not there because it is probably a one liner in D or something that should be done with the available tools. I also like the general design and layout. It is all very readable. All that persuaded me to proceed with the language further. My only critique or rather a wish would be more code examples. Of course, I can imagine things are not all pretty for people working with D for many years and it is absolutely fine. It should be like this because there will be no challenge and therefore progress. However, from beginners view Phobos is cool.
Jul 08 2020