digitalmars.D - 2 types of D users, both can live together happily if we adjust
- Vic (41/41) Nov 27 2014 There are 2 users I see, those that see it as an experimental
- H. S. Teoh via Digitalmars-d (28/31) Nov 27 2014 [...]
- Vic (20/72) Nov 27 2014 I completely understand and support the DIY nature of Open Source
- Mike (7/12) Nov 27 2014 You are not leveraging all of phobos or druntime, right? What is
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (19/33) Nov 27 2014 Sound advice if you want a single feature, but this does not work
- weaselcat (1/1) Nov 27 2014 Isn't this the purpose of std.experimental?
- Mike (45/58) Nov 27 2014 Can you be more specific about the instability you are
- Vic (35/82) Nov 28 2014 I say there is very few. I have to challenge your data that
- ketmar via Digitalmars-d (19/34) Nov 28 2014 if i wanted some crippled language that has almost nothing in it, i can
- Mike (3/5) Nov 28 2014 Amen.
- H. S. Teoh via Digitalmars-d (60/66) Nov 28 2014 Yeah, it's not wise to keep upgrading the compiler, even in C/C++, since
- Mike (6/9) Nov 28 2014 Yes, the important word there is "preplanned". We still use
- Paolo Invernizzi (18/65) Nov 29 2014 Well said. I don't know any "sane" software company not being
- Vic (17/22) Nov 29 2014 Here is the problem w/ that:
- Jarrett Tierney (43/67) Dec 01 2014 I think there have been many good points here. But I'd like to
- Mike (53/76) Nov 28 2014 You can see the lists here:
- Elie Morisse (8/9) Nov 29 2014 IMHO you should be ready to debug the compiler.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (5/12) Nov 29 2014 If this is a long term strategy then this makes D unsuitable for
- Vic (4/9) Nov 29 2014 On Saturday, 29 November 2014 at 15:46:03 UTC, Ola Fosheim
- Kagamin (3/6) Dec 03 2014 Do they have concrete examples of instability and how it affected
- Joakim (7/50) Nov 28 2014 While all this may be true, why does the code base need to be
- Kagamin (3/4) Dec 03 2014 Breakages are not only caused by experiments. What breakage did
- Dejan Lekic (21/21) Dec 03 2014 Saying that there are "2 types of D users" is the same as saying
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (33/37) Dec 03 2014 Yes, I have started to replace phobos with my own library. It
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (19/22) Dec 03 2014 It is also worth noting that in most area of creativity the
- Dicebot (2/2) Dec 04 2014 It is all solved by semver and release discipline - something
There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments). The 'real project/core' is where we are ( http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable systems language. From 'real project' people, the people that are in the 'experimental platform' currently *shit* where we eat (as per my D programmers that work for me, D is big and unstable). As I see it, the issue is that D is a wide platform(not a small lang) that is hard to maintain with the size of the team. (Similar wide platforms feature wise are JRE and CLR, both w/ > 100 developers). So how many core D developers we have?(*) A more modern language like Go splits btwn stable 'core' and 'experimental feature platform', for example no need for core to have try/catch, when it can be done downstream: - http://github.com/manucorporat/try This is similar to Linux: kernel and gnu; and what I propose for D: to be split up. This would allow users of *real project* to use a core and people that want to have features could do that downstream: let a 1000 flowers bloom! If you are w/ me so far, how big/small should core be? *Small enough to be maintained by the size of the team at hand and no larger. * Something stable for us to lean on. Next, is it feasible to split? Std library has much bloat and is easy to split up into core and downstream experimental feature platform. That leave the compiler. I am not an expert, but this could be done w/ core 'compiler' and the rest in optional pre-processor. I think it can be done w/ backwards compatible (just switch GC to default off) I'll say 90% + should and must be moved to downstream projects. This allows for the famous quote: 'fearlessly peer into the gates of hell’ - all I’m saying do it downstream, let us build projects that can lean on small/simple and maintainable D core. Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split? http://tinyurl.com/q5t2eag
Nov 27 2014
On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d wrote:There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments).[...] The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place. While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums. Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens. So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively. T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Nov 27 2014
I completely understand and support the DIY nature of Open Source and it's something that should be underlined often! If we turn out to be successful, I do plan to resource out D support. But I'm running a startup and don't have the spare cycles. But I am using D, betting the company on it, programmers in my shop do D 100% of time, so I do consider myself a part of the D community. So all I can do is wish for a small and stable D lang, vs a large D experimental platform - and both are possible. If I had resources I would divide Phobos and complier/pre-compiler to support the 2 camps: people that use D on real projects and people that want to experiment as I have outlined. I do think this to be key thing for the active D community to internalize as it relates to D wide adoption or disappearing: the size of project managed as it releases to FTE (~2000 hrs/year) resources that maintain it. Manifested mostly as http://en.wikipedia.org/wiki/Feature_creep or instability (is my code wrong or is it D ) On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via Digitalmars-d wrote:On Thu, Nov 27, 2014 at 10:58:31PM +0000, Vic via Digitalmars-d wrote:There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments).[...] The thing is, based on my observations over the past few years or so I've been here, such grand plans have often been proposed (in the best of intentions, to be sure) but rarely carried out. The thing about D is that if you wish to see something happen, you just have to dig in and *do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place. While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it. The stuff that *does* happen often happens in the background where somebody actually did the hard work and wrote the code, pushed the PR's through to acceptance, contributed the hardware to improve the infrastructure, etc., often with little or no activity on the forums. Almost all of the discussions on the forums that have little or no code backing it up tend to just sputter out after everyone's energy has been exhausted, and nothing happens. So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about it (besides talking about it on the forum, that is). Remember that this is an open source project with contributions made by volunteers; telling volunteers what to do with their free time rarely works. Contributing real work, OTOH, tends to catch people's attention much more effectively. T
Nov 27 2014
On Friday, 28 November 2014 at 00:17:19 UTC, Vic wrote:So all I can do is wish for a small and stable D lang, vs a large D experimental platform - and both are possible. If I had resources I would divide Phobos and complier/pre-compiler to support the 2 camps: people that use D on real projects and people that want to experiment as I have outlined.You are not leveraging all of phobos or druntime, right? What is the minimal amount of D that you need? With that scope in mind, you may find that it would require minimal resources in time or funds to fix the issues that you are encountering. Again, without knowing what those issues are, no one can say. Mike
Nov 27 2014
On Thursday, 27 November 2014 at 23:24:59 UTC, H. S. Teoh via Digitalmars-d wrote:*do* something about it. Be the champion of whatever you propose, get on the ground and work it out, make it happen. Contribute code. Help improve the infrastructure. Be the change you wish to see take place.Sound advice if you want a single feature, but this does not work for restructuring and management. You cannot "commit" people into moving in the same direction, you need to create common ground. That takes time if there is no skilled leader to pull it through.While these forums can be quite entertaining, from my observations most of the animated discourse ultimately results in nothing -- because nobody actually got up to *do* something about it.I disagree, intelligent people pick up the arguments even though they may not like them at the time they face them. These arguments eventually move up through their brainstem if they are good at learning (I think most programmers are good at that). By iterating over the most problematic issues you get many viewpoints and a new direction might emerge over time (measured in years, not weeks). The nogc focus got in by "external" advocacy. It did take some noise, but it got in.So, if you wish to see the changes you propose, I'd say your best bet is to start *doing* something about itIn this case it actually means refactoring the compiler codebase, which will by necessity lead to a fork if this is not wanted by the main developers as it will break up their existing mental model of the program.
Nov 27 2014
On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad wrote:The nogc focus got in by "external" advocacy. It did take some noise, but it got in.It took a lot of noise and IMO rust removing their GC to force something to happen.
Nov 27 2014
Yes, that is one example of something that could be a downstream feature with alternative implementations. On Friday, 28 November 2014 at 01:29:16 UTC, weaselcat wrote:On Friday, 28 November 2014 at 00:19:49 UTC, Ola Fosheim Grøstad wrote:The nogc focus got in by "external" advocacy. It did take some noise, but it got in.It took a lot of noise and IMO rust removing their GC to force something to happen.
Nov 28 2014
On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:The 'real project/core' is where we are ( http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable systems language. From 'real project' people, the people that are in the 'experimental platform' currently *shit* where we eat (as per my D programmers that work for me, D is big and unstable).Can you be more specific about the instability you are encountering? Are you referring to the changes between releases, or problems due to bugs? And which changes/bugs have you encountered that have cause you grief?If you are w/ me so far, how big/small should core be? *Small enough to be maintained by the size of the team at hand and no larger. *As I see it, D has a lot of contributors willing to maintain and enhance it, but the barrier to entry and learning curve is quite high for anything significant. Therefore, the number of contributors that actually make a significant difference is quite small. Also, since it is a volunteer effort, there's really not much accountability. Contributors are free to make significant contributions, and then leave the D scene without anyone able to maintain their work. Contributors are also free to do partial implementations, and move onto something else without completing what they started. I think anyone wishing to leverage D for a critical project should be aware of that, and perhaps D should be more transparent about it. That doesn't mean D shouldn't be used for anything of importance, it just means that by using D we enter into an implicit contract requiring us to either be willing to become significant contributors ourselves, or be willing to partner with and fund D's development. When I first approached D, I had high expectations, and as I learned more, I also became disappointed and said a few things I this forum I wish I could take back. I misunderstood the culture of this community and how it works, and perhaps I still do. But what is more apparent now is we can't expect to rely on D if we're not willing to make significant contributions ourselves, or fund its development. And, while using D is itself a small contribution, it's not enough.Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split?I would like D core to be small as well, but for different reasons: I would like a nimble language that can be used for both the smallest and largest of machines, and let the libraries differentiate. But, I don't think it should be partitioned based on the size of D's human resources, partially because that is going to fluctuate drastically throughout time. Rather, the division should be made based on architectural and design goals. You might consider doing what other organizations have done: Allocating your D talent to fix the problems you have encountered by submitting pull requests, or open issues and place bounties on them at https://www.bountysource.com/teams/d/issues. Regardless, I'd still be interested in knowing, more specifically, what problems you're encountering. Mike
Nov 27 2014
inline: On Friday, 28 November 2014 at 05:14:31 UTC, Mike wrote:<snipAs I see it, D has a lot of contributors willing to maintain and enhance it, but the barrier to entry and learning curve is quite high for anything significant.I say there is very few. I have to challenge your data that there is a lot of contributors. Most projects list their maintainers, what is the number of FTE D maintainers? That is a loaded question of course, relative to surface area: http://dlang.org/comparison.html of sacred cows relative to FTE maintainers.Therefore, the number of contributors that actually make a significant difference is quite small. Also, since it is a volunteer effort, there's really not much accountability. Contributors are free to make significant contributions, and then leave the D scene without anyone able to maintain their work. Contributors are also free to do partial implementations, and move onto something else without completing what they started. I think anyone wishing to leverage D for a critical project should be aware of that, and perhaps D should be more transparent about it. That doesn't mean D shouldn't be used for anything of importance, it just means that by using D we enter into an implicit contract requiring us to either be willing to become significant contributors ourselves, or be willing to partner with and fund D's development.How much $ funding so I consider it? For example for regressions to be done but only for core. (none of silly things, which is a long list of GC, AssociaveArrays, demangle, annotations, higher order functions, pseudo members, transmogrify, goto, try/catch, vardic, traits, variant, sqllite, etc. I am not saying to remove them, just make them downstream like GNU does, not part of regression tested D core. If I wanted to use a big lang I'd do CLR or JRE.When I first approached D, I had high expectations, and as I learned more, I also became disappointedYes, that is the pattern. Come in, and leave. There has to be more people staying and more D shops (like my shop is pure 100% D ). The regressions are painful, and I propose a way to let people experiment and compete on rich features. My proposal is to make a small stable core that can be maintained, so that people say.and said a few things I this forum I wish I could take back. I misunderstood the culture of this community and how it works, and perhaps I still do. But what is more apparent now is we can't expect to rely on D if we're not willing to make significant contributions ourselves, or fund its development. And, while using D is itself a small contribution, it's not enough.The culture of the D contributes is 'to bravely peer into gates of hell' - as in experiment. As user of D I want it to be small, stable and maintained. I proposed a path that allows for both, w/o scaring of people that use D for real projects. If that is not so, then I missed that D is an experimental language.Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split?I would like D core to be small as well, but for different reasons: I would like a nimble language that can be used for both the smallest and largest of machines, and let the libraries differentiate. But, I don't think it should be partitioned based on the size of D's human resources, partially because that is going to fluctuate drastically throughout time. Rather, the division should be made based on architectural and design goals.You might consider doing what other organizations have done: Allocating your D talent to fix the problems you have encountered by submitting pull requests, or open issues and place bounties on them at https://www.bountysource.com/teams/d/issues. Regardless, I'd still be interested in knowing, more specifically, what problems you're encountering. MikeMy problem: I have 3 developers(still hiring more) that work for me please lets not use D, it is not stable release to release (and has a bunch of things no one needs). I told them: we are a D shop because long term I anticipate D and Walter to succeed. So I hope that maintainers consider users of D and not chase them away. Vic
Nov 28 2014
On Fri, 28 Nov 2014 20:00:35 +0000 Vic via Digitalmars-d <digitalmars-d puremagic.com> wrote:etc. I am not saying to remove them, just make them downstream=20 like GNU does, not part of regression tested D core. If I wanted=20 to use a big lang I'd do CLR or JRE.if i wanted some crippled language that has almost nothing in it, i can take any of the scripting languages out here, or some esoteric compiler. having dynamic arrays, associative arrays and strings in the language is a must for me: i don't want to reinvent the wheel each time or add some libraries for such simple things (yes, C, i'm talking about you!). and having alot of things in phobos is great too: i still don't have to download another library for levenstein distance, for example (yes, i really used that and was very happy to find it right into std.algorithm). and i really enjoyed the fact that all this is a part of the language that undergoes testing on par with basic features.you can fork and experiment as you want. my private build of DMD has more than 100KB of patches applied at build time, for example.When I first approached D, I had high expectations, and as I=20 learned more, I also became disappointed=20 Yes, that is the pattern. Come in, and leave. There has to be=20 more people staying and more D shops (like my shop is pure 100% D=20 ). The regressions are painful, and I propose a way to let people=20 experiment and compete on rich features. My proposal is to make a=20 small stable core that can be maintained, so that people say.My problem: I have 3 developers(still hiring more) that work for=20 me please lets not use D, it is not stable release to release=20 (and has a bunch of things no one needs).this has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade. even more: we have dfix now, which will help to make upgrade process alot less painfull.
Nov 28 2014
On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote:this has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade.Amen.
Nov 28 2014
On Fri, Nov 28, 2014 at 11:06:14PM +0000, Mike via Digitalmars-d wrote:On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote:Yeah, it's not wise to keep upgrading the compiler, even in C/C++, since many enterprise products tend to exhibit subtle breakages with new compilers. (You may have heard of Linus ranting about newer versions of GCC that "miscompile" the kernel, for example -- I remember back in the day, the word was that you had to use egcs to compile the kernel, otherwise if you get a kernel panic you're on your own, the devs can't (and won't) help you). The code that I work on in my day job has a lot of compiler-specific hacks, and would *certainly* become unusable if we were to build it with a non-standard compiler -- standard being what's shipped in the development environment that we are required to use for building it, which hasn't changed for the last 5 years at least (so it's definitely *not* a new compiler!). Of course, being stuck with an obsolete version of D is Not Nice, so one idea that occurs to me is to do infrequent, preplanned upgrades. For example, say you standardize on dmd 2.066 for the current product release. This means that you will *only* compile with 2.066 and nothing else, and developers are required to use only the "official" compiler version for their work. This also means that you, being the boss, decide what feature sets are / aren't allowed in your codebase. For example, glancing over Google's C++ style guide, many C++11 features are banned outright -- even though ostensibly they must have *some* value to *somebody*, otherwise they wouldn't be in the spec! So basically, you decide on the compiler version and feature set, and stick with that. Now, the product may take a long time to develop, ship, and maintain, so by the time it's in maintenance mode, it could be several years from now. By then, upstream dmd may already be at 2.074, say, but your codebase is still only 2.066. At some point, you'll want to upgrade -- but that should be done wisely. Never ever upgrade your mainline development wholesale -- if you run into problems (e.g., a language feature you depended on has changed and it's non-trivial to update the code to work around it) you don't want to find yourself in the unpleasant position of having a non-working codebase. Instead, start out a pilot branch with one or two dedicated developers who will (attempt to) build the code with the latest compiler. If you're extremely, extremely, extreeeeeemely lucky, all goes well and you can run some unittests, then some controlled field testing, then switch over. More likely, though, you'll run into some issues -- compiler bugs that got fixed and code that relied on that is now broken, etc.. So you take the time to investigate -- on the pilot branch -- how to work around it. Once everything is figured out, start investing more effort into porting the codebase over to the new compiler -- at the same time evaluating possible new feature sets to include in your list of permitted features -- while still keeping the 2.066 compiler and the original branch around. Don't ever throw out the old compiler until the older product release is no longer supported. Ideally, the new branch will coincide with the next major release of your product, which should give you some time to sort out compiler bugs (new and old), language workarounds, etc.. Once the new release is stabilized enough to be shippable, you can start deprecating the older codebase and eventually drop it. Basically, this isn't too much different from what you'd do with any other 3rd party product that you depend on -- you never just drop in a new 3rd party release with no planning and no migration path, that's just asking for trouble. You always keep the current environment running until the new one has been proven to be stable enough to use, then you switch over. T -- "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)this has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade.Amen.
Nov 28 2014
On Friday, 28 November 2014 at 23:38:40 UTC, H. S. Teoh via Digitalmars-d wrote:Of course, being stuck with an obsolete version of D is Not Nice, so one idea that occurs to me is to do infrequent, preplanned upgrades.Yes, the important word there is "preplanned". We still use Visual Studio 6.0 (1998) for some of our products. I spent the last month working in Visual Studio 2008. Mike
Nov 28 2014
On Friday, 28 November 2014 at 23:38:40 UTC, H. S. Teoh via Digitalmars-d wrote:For example, say you standardize on dmd 2.066 for the current product release. This means that you will *only* compile with 2.066 and nothing else, and developers are required to use only the "official" compiler version for their work. This also means that you, being the boss, decide what feature sets are / aren't allowed in your codebase. For example, glancing over Google's C++ style guide, many C++11 features are banned outright -- even though ostensibly they must have *some* value to *somebody*, otherwise they wouldn't be in the spec! So basically, you decide on the compiler version and feature set, and stick with that. Now, the product may take a long time to develop, ship, and maintain, so by the time it's in maintenance mode, it could be several years from now. By then, upstream dmd may already be at 2.074, say, but your codebase is still only 2.066. At some point, you'll want to upgrade -- but that should be done wisely. Never ever upgrade your mainline development wholesale -- if you run into problems (e.g., a language feature you depended on has changed and it's non-trivial to update the code to work around it) you don't want to find yourself in the unpleasant position of having a non-working codebase. Instead, start out a pilot branch with one or two dedicated developers who will (attempt to) build the code with the latest compiler. If you're extremely, extremely, extreeeeeemely lucky, all goes well and you can run some unittests, then some controlled field testing, then switch over. More likely, though, you'll run into some issues -- compiler bugs that got fixed and code that relied on that is now broken, etc.. So you take the time to investigate -- on the pilot branch -- how to work around it. Once everything is figured out, start investing more effort into porting the codebase over to the new compiler -- at the same time evaluating possible new feature sets to include in your list of permitted features -- while still keeping the 2.066 compiler and the original branch around. Don't ever throw out the old compiler until the older product release is no longer supported. Ideally, the new branch will coincide with the next major release of your product, which should give you some time to sort out compiler bugs (new and old), language workarounds, etc.. Once the new release is stabilized enough to be shippable, you can start deprecating the older codebase and eventually drop it. TWell said. I don't know any "sane" software company not being ruled by a process like that. Here in SRLabs we are sticking with what you have described, with one variation: one person (and only one), it's constantly trying to build a branches of the projects with the latest compiler, testing our internal pull requests. Many bugs are avoided, as detected by more recent compiler version, and it's very rare not being able to keep the pace with the other developers. From time to time, during the development of some product, we are so confident by the state of the "unstable" to just jump everyone to a more recent compiler version. But when the product is released, we stick with the version of the compiler used to release it, till it's end-of-life. --- Paolo
Nov 29 2014
On Friday, 28 November 2014 at 23:06:15 UTC, Mike wrote:On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote:Here is the problem w/ that: Lets stay that we use GDC (because of debugger) equivalent of D 2.066(or whatever) for ~ year. In essence, we check out of the D community. And when we come back, we find that the D community pool has not grown (due to some of the challenges we found). This means our project is not developed in an unsupported language, and we have to port. (In forums I see maintainers talking about GC in core. I think that hooks for ref. counting should be in core, but move the implementation for the average case downstream. Plus many other things. To me, as a manager, figure out what your resources to be good at it, and no more). I want to D, and the only way I see that is smaller D and the only way I see that is via a split so that the pool can grow. Cheers, Victhis has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade.Amen.
Nov 29 2014
I think there have been many good points here. But I'd like to reiterate with any language of any size, it comes down to what you use in the language. Yes there are experimental features in D that are more influx than others, but depending on those features are really up to you and your team. I think what you should do here, is look at what this D core means to you (what features you want to be core vs not) Then use that set to build the restrictions of how you code your project in D with. If you don't want to leverage the GC then design your code practices and project code around avoiding the GC and anything that uses it. To me it seems with due diligence, you can make your own "D core" by limiting what you use to just the small subset of features you trust. In the case of avoiding the GC, this requires learning what parts of phobos depend on the GC and what parts do not. I believe in some cases you can even leverage features of the D language to restrict some feature use (like enforcing the use of safe and pure). I use D at a large tech corporation for an internal tool, and I can tell you overall I have not run into too many issues with D or its standard library. Usually when I find a feature I'm not sure about (stability or otherwise) I'll create a test D program and test it myself. Depending on the results I decide whether to use it or not. I understand your points about support. When you are in a corporate environment of any size, support for your tools is a big deal. I got asked this many a time by my management when picking D for my project. The way I addressed the concern is more about focusing on quality vs quantity. Yes it would be nice to have D have a large set of contributors and maintainers, but no matter the amount of people, you have to have a good core set of contributors that are the experts. D is a perfect example of having this, with people like Walter and Andrei behind it (and many more). It is the nature of open source software, that leads it to the fragmented development model (engineers only working on the parts that interest them), but its also the project leads that pull everything together. I actually found that change and progress in the language for me inspires more faith in the language. Yes it introduces some noise in bug count and a developers workload in keeping up, but at the same time it keeps the language moving forward. Hope this helps in some way -Jarrett On Saturday, 29 November 2014 at 17:26:30 UTC, Vic wrote:On Friday, 28 November 2014 at 23:06:15 UTC, Mike wrote:On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via Digitalmars-d wrote:Here is the problem w/ that: Lets stay that we use GDC (because of debugger) equivalent of D 2.066(or whatever) for ~ year. In essence, we check out of the D community. And when we come back, we find that the D community pool has not grown (due to some of the challenges we found). This means our project is not developed in an unsupported language, and we have to port. (In forums I see maintainers talking about GC in core. I think that hooks for ref. counting should be in core, but move the implementation for the average case downstream. Plus many other things. To me, as a manager, figure out what your resources to be good at it, and no more). I want to D, and the only way I see that is smaller D and the only way I see that is via a split so that the pool can grow. Cheers, Victhis has an easy solution: just stick with the chosen D version: nobody forces anyone to upgrade.Amen.
Dec 01 2014
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:I say there is very few. I have to challenge your data that there is a lot of contributors. Most projects list their maintainers, what is the number of FTE D maintainers?You can see the lists here: https://github.com/D-Programming-Language/dlang.org/graphs/contributors https://github.com/D-Programming-Language/dmd/graphs/contributors https://github.com/D-Programming-Language/druntime/graphs/contributors https://github.com/D-Programming-Language/phobos/graphs/contributors There's not going to be a high FTE count because D is a volunteer effort with, from what I can tell, no significant financial support. This is not a secret and users should be aware of this when they choose to use D. As I said in my previous post, IMO, users should expect to either contribute programming talent or funds if they intend to use it for anything critical.How much $ funding so I consider it? For example for regressions to be done but only for core. (none of silly things, which is a long list of GC, AssociaveArrays, demangle, annotations, higher order functions, pseudo members, transmogrify, goto, try/catch, vardic, traits, variant, sqllite, etc. I am not saying to remove them, just make them downstream like GNU does, not part of regression tested D core. If I wanted to use a big lang I'd do CLR or JRE.Can't the features that you don't need just be ignored? The .Net Framework is HUGE, but that doesn't prevent me from using a very small subset of it for my work.The regressions are painful, and I propose a way to let people experiment and compete on rich features. My proposal is to make a small stable core that can be maintained, so that people say.Do you have a bugzilla issue for each of the regressions you're referring to? The regressions that I see listed here (http://wiki.dlang.org/Beta_Testing#Available_Downloads) are quite small in number, and arguably in code that is rarely employed.The culture of the D contributes is 'to bravely peer into gates of hell' - as in experiment. As user of D I want it to be small, stable and maintained. I proposed a path that allows for both, w/o scaring of people that use D for real projects. If that is not so, then I missed that D is an experimental language.I don't see D as an experimental language. "Experimental" implies it's trying features that may or may not work, and is trying to see how they pan out. From what I can tell, the vast majority of D's features are borrowed from other time-tested, proven languages, and the D specific features that I've employed have been powerful and liberating.My problem: I have 3 developers(still hiring more) that work for me please lets not use D, it is not stable release to release (and has a bunch of things no one needs).1) Not stable release-to-release? Which regressions? Please provide links to the bug reports. Without these, there's nothing actionable, and you're argument against D is questionable. Ask your developers for something specific and actionable. You may be pleasantly surprised by the helpfulness of this community...or not. 2) has a bunch of things no one needs... The things you don't need don't need to be employed. This seems to be your fundamental premise: Because D is a feature rich language with limited resources, resources are spread too thin making D unmaintainable with the resources it has. I'm not convinced. First of all, that doesn't appear to be how this effort works. There isn't a CEO setting priorities and cracking a whip over contributors' heads. Contributors largely work on those things that interest them. Second, if D were to move non-core features downstream, the contributors that work on those features will also move downstream, thinning D's core resources even further. If regressions are the problem, please file bug reports and bring them to this community's attention. You may find some helpful people willing to address them for free simply because it interests them or it was something they were meaning to get to, and just needed a little motivation. If there isn't anyone willing to address them, the problem could potentially be monetized. Mike
Nov 28 2014
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:(...)IMHO you should be ready to debug the compiler. DMD's codebase can be obscure at times (while the LDC mid-end is pretty straightforward) so the first time looking for the source of a bug may be a frustrating and time-consuming learning experience, but you'll be empowered to tackle compiler bugs without relying on volunteers to do it for you, and without stopping D from evolving.
Nov 29 2014
On Saturday, 29 November 2014 at 15:37:12 UTC, Elie Morisse wrote:IMHO you should be ready to debug the compiler. DMD's codebase can be obscure at times (while the LDC mid-end is pretty straightforward) so the first time looking for the source of a bug may be a frustrating and time-consuming learning experience, but you'll be empowered to tackle compiler bugs without relying on volunteers to do it for you, and without stopping D from evolving.If this is a long term strategy then this makes D unsuitable for contract work. You really don't want any uncertain factors when bidding on a contract since that will skew your estimates. Stability is more important than features in a commercial setting.
Nov 29 2014
On Saturday, 29 November 2014 at 15:46:03 UTC, Ola Fosheim Grøstad wrote: <snip>If this is a long term strategy then this makes D unsuitable for contract work. You really don't want any uncertain factors when bidding on a contract since that will skew your estimates. Stability is more important than features in a commercial setting.yes
Nov 29 2014
On Friday, 28 November 2014 at 20:00:36 UTC, Vic wrote:My problem: I have 3 developers(still hiring more) that work for me please lets not use D, it is not stable release to release (and has a bunch of things no one needs).Do they have concrete examples of instability and how it affected them?
Dec 03 2014
On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:There are 2 users I see, those that see it as an experimental feature platform and those that use it for real projects (and not for experiments). The 'real project/core' is where we are ( http://blog.apakau.com/2014/11/cmg-paper ) and we need a stable systems language. From 'real project' people, the people that are in the 'experimental platform' currently *shit* where we eat (as per my D programmers that work for me, D is big and unstable). As I see it, the issue is that D is a wide platform(not a small lang) that is hard to maintain with the size of the team. (Similar wide platforms feature wise are JRE and CLR, both w/ > 100 developers). So how many core D developers we have?(*) A more modern language like Go splits btwn stable 'core' and 'experimental feature platform', for example no need for core to have try/catch, when it can be done downstream: - http://github.com/manucorporat/try This is similar to Linux: kernel and gnu; and what I propose for D: to be split up. This would allow users of *real project* to use a core and people that want to have features could do that downstream: let a 1000 flowers bloom! If you are w/ me so far, how big/small should core be? *Small enough to be maintained by the size of the team at hand and no larger. * Something stable for us to lean on. Next, is it feasible to split? Std library has much bloat and is easy to split up into core and downstream experimental feature platform. That leave the compiler. I am not an expert, but this could be done w/ core 'compiler' and the rest in optional pre-processor. I think it can be done w/ backwards compatible (just switch GC to default off) I'll say 90% + should and must be moved to downstream projects. This allows for the famous quote: 'fearlessly peer into the gates of hell’ - all I’m saying do it downstream, let us build projects that can lean on small/simple and maintainable D core. Lets make D core small please. List of things that are core: char arrays. What else should be core? The key question in this tread: how small should core D be to be maintainable and stable? How can it be split? http://tinyurl.com/q5t2eagWhile all this may be true, why does the code base need to be split for you to use the core, ie can't you just stay away from new and experimental features of the language? Perhaps you don't know the age or level of stability of each feature, but it strikes me that starting a project to document that would be much easier than trying to push a split.
Nov 28 2014
On Thursday, 27 November 2014 at 22:58:33 UTC, Vic wrote:Something stable for us to lean on.Breakages are not only caused by experiments. What breakage did you encounter?
Dec 03 2014
Saying that there are "2 types of D users" is the same as saying "I see the world black and white". :) - It is far from reality. D community has lots of "groups" if you look closely. Examples: 1) OOP vs functional/declarative group. 2) system programming vs business programming group. 4) Stable D spec group vs unstable D spec group (what you call "experimental"). Etc. 5) web UI vs "native" UI (based library X where X = Qt, Gtk, FLTK, SDL etc) Finally, there is "stable D" (D1) but ironically it is not supported as far as I know. There is no D2 version that can be considered stable. - There would be, if D team was organised properly and decided to maintain a stable D2 branch that is free of "things in motion". What are alternatives? - Make the abovementioned "stable D" branch by yourself, and maintain it in-house. It is really hard to do all this in a truly open project because maintaining this stable branch is IMHO a full-time job.
Dec 03 2014
On Wednesday, 3 December 2014 at 15:52:30 UTC, Dejan Lekic wrote:What are alternatives? - Make the abovementioned "stable D" branch by yourself, and maintain it in-house.Yes, I have started to replace phobos with my own library. It will probably take a man-month to complete. The advantage is that I get my own types for integers, simd and simd friendly containers. The disadvantage is that you end up on an island… This is exactly what people have done with C++ up to now. But the real issue is the compiler. If I want to receive bugfixes I will only be able to modify the compiler on the most superficial level, which is the parser and some conditional switches in strategic location in the compiler core (e.g. turning off UFCS). That limits what you can do, but what can be done in the parser is easy to fix, less than 2 weeks of work So this is possible, but far from ideal IMO. In perspective: C++ spent ~20 years getting a reasonable standard library in place which has a more narrow scope than D's standard library and C++ had to change the language to make STL usable (and it still is annoying).It is really hard to do all this in a truly open project because maintaining this stable branch is IMHO a full-time job.I don't think maintaining a stable branch is a full time job. The maintainer will only back port bugfixes that are non-breaking (i.e. you don't back port well known bugs with well known work arounds). The real challenge is to get to a stable release in the first place, because that would probably require a 6 month feature freeze. To get a feature freeze you will have to get most people to agree on the current feature set being sufficient, which is at odds with the «please break my code» crowd. What is really needed is a list of issues with assigned priorities that has to be fixed before a feature freeze can be decided on. That will only happen if someone steps up and take a management role where issues are identified, analyzed, prioritized and followed up with a plan.
Dec 03 2014
On Wednesday, 3 December 2014 at 16:21:03 UTC, Ola Fosheim Grøstad wrote:That will only happen if someone steps up and take a management role where issues are identified, analyzed, prioritized and followed up with a plan.It is also worth noting that in most area of creativity the creators will be too involved with the design to take an "outside look", so it is might be better to have a person without an investment in the design help out. When collecting issues one should avoid evaluating the issues. This is a problem with current forum threads. One should collect all unresolved issues raised by various users first. Only after collection is finished should one analyze, and only after analysis should one evaluate. With no deadline for a stable release commercial related investment in development makes little sense. If you require a stable release to use the compiler in production you need a deadline for the next stable release. I am convinced this slows D development for no good reason, and I don't agree Open Source is special. A list of issues that needs resolution before the next stable release and a plan to go along with it could make a real difference, IMO.
Dec 03 2014
It is all solved by semver and release discipline - something language authors are strongly against.
Dec 04 2014