Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote: D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). This gets repeated over and over again, but I haven't actually seen any evidence for it. But even if it is true, I'd say it is just because they did it wrong. There never really was a D1->D2. There was just an ongoing evolution of D where one version was arbitrarily forked off and called D1. Seriously, D1.00 and D 2.00 came out at about the same time: Version D 1.001 Jan 23, 2007; 2.000 Jun 17, 2007. I remember the biggest troubles I had with D2: immutable being introduced and changing, and a bunch of little library renames and they weren't really that big of a deal and btw occurred over the next ~2ish *years*. It wasn't all at once - remember "D2" was just the evolving D. D1 was a random, arbitrary snapshot. If I were to do a D3, I'd make it opt in at the module level, and keep it so all D code can be compiled together - corresponding features added each step. For example, a "d3 module" is @safe by default. But the @safe semantics are still tehre for a "d2 module", you just annotate it elsewhere. Then there's no breakage and you can still change things.
Re: Documentation for any* dub package, any version
If you guys have bug reports or feature requests, you can put it on the github too if you like: https://github.com/adamdruppe/dpldocs/issues
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 03:57:25 UTC, barry.harris wrote: Sorry little rabbit, your are misguided in this belief. Back in day we all used C and this is the reason most "safer" languages exist today. You can write pretty safe code in C these days, without too much trouble. We have the tooling and the knowledge to make that happen.. developed over decades - and both keep getting better, because the language is not subjected to a constant and frequent release cycle. Ironically, the demands on programmers to adapt to constant change, is actually making applications less safe. - and least, that's my thesis ;-) The real problem with using C these days (in some areas), is more to do with its limited abstraction power, not its lack of safety. And also C is frowned upon (and C++ too for that matter), cause most programmers are so lazy these days, and don't want to write code - but prefer to just 'link algorithms' that someone else wrote. I include myself in this - hence my interest in D ;-) Keep those algorithms coming!
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote: D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). A D2 -> D3 transition might generate a lot of publicity if done very carefully, but more than likely it would just put the nails in the coffin for good and destroy all the momentum D has built up over the past 3 years (I feel like 2015 was a big turning point where D finally got back on peoples' radars). I've read a bit about that history, but really, sometimes you have to be agressive with change or just it won't come about. And I don't see how D2 could have come about without an agressive push for change. And it's unlikely that D would have died. Some people might have left (and probably did). But D is better because it's D2. Imagine promoting D1 to the world! D3 could be even better. (e.g. @safe by default..just for starters). And I personally think all this ongoing integration with C and C++ is not ideal. It's creating a really complex beast, that has to be maintained indefinitely... by someone. So I'd like to see D3 dump all the compatibility crap ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:34:23 UTC, psychoticRabbit wrote: On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote: btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." I'd also argue, that languages that are relatively stable, are far 'safer' than languages that constantly change. So given that the world is so focused on developing a variety of so called 'safer' languages, with ever rapid, frequent, release cycles, the world would actually be alot 'safer' if everyone went back and programmed in C ;-) Sorry little rabbit, your are misguided in this belief. Back in day we all used C and this is the reason most "safer" languages exist today.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 00:39:08 UTC, psychoticRabbit wrote: On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote: That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. ... - Jonathan M Davis Personally. I think the D1..D2 transistion was great idea. I think D2..D3 should follow the same principle. D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). A D2 -> D3 transition might generate a lot of publicity if done very carefully, but more than likely it would just put the nails in the coffin for good and destroy all the momentum D has built up over the past 3 years (I feel like 2015 was a big turning point where D finally got back on peoples' radars).
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote: btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." I'd also argue, that languages that are relatively stable, are far 'safer' than languages that constantly change. So given that the world is so focused on developing a variety of so called 'safer' languages, with ever rapid, frequent, release cycles, the world would actually be alot 'safer' if everyone went back and programmed in C ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 01:19:53 UTC, H. S. Teoh wrote: Because it has not stopped changing. To wit: K C (1978) C89 / C90 / ANSI C (1989-1990) The 1995 amendment to ANSI C (1995) C99 (1999) (Embedded C (2008)) C11 (2011) T btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." And that last update to C, in 2011, was 7 years ago.. relative stability is a sure sign that something is right. constant, regular, change is a sure sign that something is wrong. And if stability were not the preferred state towards which things evolve, then the universe would be a very different place indeed.
Re: State of D 2018 Survey
On Fri, Mar 02, 2018 at 12:57:22AM +, psychoticRabbit via Digitalmars-d-announce wrote: > On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote: > > On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via > > Digitalmars-d-announce wrote: [...] > > > On the otherhand, I wish programming languages would just stop > > > changing so often. > > [...] > > > > Change is inevitable, except from a vending machine. :-P > > > > The day a language stops changing is the day it begins to die. [...] > C will never die [...] Because it has not stopped changing. To wit: K C (1978) C89 / C90 / ANSI C (1989-1990) The 1995 amendment to ANSI C (1995) C99 (1999) (Embedded C (2008)) C11 (2011) T -- "If you're arguing, you're losing." -- Mike Thomas
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote: On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via Digitalmars-d-announce wrote: [...] On the otherhand, I wish programming languages would just stop changing so often. [...] Change is inevitable, except from a vending machine. :-P The day a language stops changing is the day it begins to die. T C will never die !!
Re: State of D 2018 Survey
On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via Digitalmars-d-announce wrote: [...] > On the otherhand, I wish programming languages would just stop > changing so often. [...] Change is inevitable, except from a vending machine. :-P The day a language stops changing is the day it begins to die. T -- Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.
Re: State of D 2018 Survey
On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote: That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. ... - Jonathan M Davis Personally. I think the D1..D2 transistion was great idea. I think D2..D3 should follow the same principle. i.e restrict breaking changes to major versions. People are always able to stay on the major branch that they need - there are no forced upgrades here - you choose which major branch works for you. The source code is all there for you, to do as you please. This is the only way to evolve - otherwise D will just become another convoluted piece of %3@f!, like C++. On the otherhand, I wish programming languages would just stop changing so often. The constant release cycles is just crazy! That's a sure sign that something is not right. And who wants to program in a langauge that is not right?? That's why I still like, still use, and typically still prefer .. C. Nobody dares change it ;-)
Re: Documentation for any* dub package, any version
On Thursday, 1 March 2018 at 11:00:15 UTC, Jonas Drewsen wrote: Would be cool if you could add support for creating docs from any dub project stored on github and not only the ones on code.dlang.org. That might be possible too. BTW I just put the server code up on github https://github.com/adamdruppe/dpldocs there's actually not that much to it right now.
Re: State of D 2018 Survey
On Thursday, March 01, 2018 13:24:29 Bill Baxter via Digitalmars-d-announce wrote: > Just don't overlook the fact that people who fill out 30 minute surveys > right away after being told about them are a self-selected group of people > who apparently have way too much time on their hands. > Which also suggests they would likely also have more free time to go chase > down and fix breaks in their legacy code caused by new compilers. It's also the case that the folks who even see this survey are likely to be a fairly small percentage of the actual user base. So, while its results may be useful, they need to be viewed with that fact in mind. That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. For instance, while we might not actually have a new operator if D were being redesigned from the ground up (Andrei has previously stated that it really should have just been a function in the standard library or runtime), that would be far too large a change with far too little benefit to be even vaguely worth it at this point. On the other hand, we _did_ change it so that switch statements don't have implicit fallthrough anymore, and that change was _very_ well received, because it caught bugs and it was a quick fix to update correct code that was then an error (it was probably also true that relatively little correct code had to be updated, but that's harder to measure). Each potential breaking change has to be weighed on its own, and the real question is how strongly we weight the pros vs the cons. We could choose to favor breaking code only when it's cleary _very_ benificial to do so, or we could choose to break code any time there's even a slight benefit to it. I think that it's pretty clear that the right choice is somewhere in between those two extremes, but it's not an easy question as to where it is. And as has been discussed before, we have folks clamoring for breaking changes and folks clamoring for nothing to ever break, and sometimes, they're exactly the same folks. :| - Jonathan M Davis
Re: State of D 2018 Survey
Ok, I have same feeling, but after trying to fill this survey with one of my colleague, I have find out that it takes "only" 15 minutes to complete. But still I thing almost everyone from our field is OK with filling surveys anyway. On Thu, Mar 1, 2018 at 10:24 PM, Bill Baxter via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Just don't overlook the fact that people who fill out 30 minute surveys > right away after being told about them are a self-selected group of people > who apparently have way too much time on their hands. > Which also suggests they would likely also have more free time to go chase > down and fix breaks in their legacy code caused by new compilers. > > --bb > > > On Thu, Mar 1, 2018 at 1:19 PM, bauss via Digitalmars-d-announce < > digitalmars-d-announce@puremagic.com> wrote: > >> On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote: >> >>> On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote: >>> On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote: > Thanks! I hope so too! > Is there some way to access the results without retaking the survey? >>> >>> Yeah the link TypeForm generates at the end is permanent: >>> >>> https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig >>> >>> though for some reason it doesn't show full-text answers (I have opened >>> a support ticket for that a while ago). >>> Anyhow, as Mike said we will look at all answers and do a summary once >>> the survey concluded. >>> >> >> Interesting results. 80% in favor for breaking changes. >> >> Maybe it's time to not care too much about making D better and leave old >> legacy stuff that stops D from evolving behind curtains. >> > >
Re: State of D 2018 Survey
On Thursday, 1 March 2018 at 21:24:29 UTC, Bill Baxter wrote: Just don't overlook the fact that people who fill out 30 minute surveys right away after being told about them are a self-selected group of people who apparently have way too much time on their hands. Which also suggests they would likely also have more free time to go chase down and fix breaks in their legacy code caused by new compilers. --bb Nothing makes the old compilers disappear. If you have working code, keep using the compiler that compiled it. New features or breaking changes. Otherwise D will stop evolving, and unlike C++, will not have tons of legacy code to force people to continue to use it.
Re: State of D 2018 Survey
Just don't overlook the fact that people who fill out 30 minute surveys right away after being told about them are a self-selected group of people who apparently have way too much time on their hands. Which also suggests they would likely also have more free time to go chase down and fix breaks in their legacy code caused by new compilers. --bb On Thu, Mar 1, 2018 at 1:19 PM, bauss via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote: > >> On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote: >> >>> On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote: >>> Thanks! I hope so too! >>> >>> Is there some way to access the results without retaking the survey? >>> >> >> Yeah the link TypeForm generates at the end is permanent: >> >> https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig >> >> though for some reason it doesn't show full-text answers (I have opened a >> support ticket for that a while ago). >> Anyhow, as Mike said we will look at all answers and do a summary once >> the survey concluded. >> > > Interesting results. 80% in favor for breaking changes. > > Maybe it's time to not care too much about making D better and leave old > legacy stuff that stops D from evolving behind curtains. >
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote: On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote: On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote: Thanks! I hope so too! Is there some way to access the results without retaking the survey? Yeah the link TypeForm generates at the end is permanent: https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig though for some reason it doesn't show full-text answers (I have opened a support ticket for that a while ago). Anyhow, as Mike said we will look at all answers and do a summary once the survey concluded. Interesting results. 80% in favor for breaking changes. Maybe it's time to not care too much about making D better and leave old legacy stuff that stops D from evolving behind curtains.
Re: State of D 2018 Survey
On Wed, 2018-02-28 at 13:41 +, Mike Parker via Digitalmars-d- announce wrote: > About a month ago, Sebastian Wilzbach sent an email out to a few > of the core D folks asking for feedback on a survey he had put > together. He thought it would be useful for the Foundation to use > in order to make decisions about where to expend development > efforts. Eventually Andrei gave his stamp of approval, the survey > questions were tweaked, and then it was ready to roll. > > Of course I would love for you to read my blog post announcing > it, but if you want to skip the prose and go straight to the good > stuff, here's the survey link: > > https://seb134.typeform.com/to/H1GTak > All the 1 to 5 scale questions have the label a over each of the five options so it is not entirely obvious what to choose. Firefox 58.0.1 on Debian Sid. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Documentation for any* dub package, any version
On Monday, 26 February 2018 at 14:59:07 UTC, Adam D. Ruppe wrote: Many of you will already know this from the other thread or from my twitter, but I just added a on-demand downloader to my dpldocs.info domain to fetch and build docs for any* dub Would be cool if you could add support for creating docs from any dub project stored on github and not only the ones on code.dlang.org. e.g. create docs for https://github.com/anton-dutov/db: http://githubdoc.dpldocs.info/anton-dutov/db/v6.0.22/db.html or something like that.
Re: An optional/maybe type with range semantics
On Wednesday, 28 February 2018 at 10:55:38 UTC, Andrei
Alexandrescu wrote:
On 2/28/18 12:54 PM, Andrei Alexandrescu wrote:
On 2/25/18 8:03 PM, aliak wrote:
Did you take a look at
https://dlang.org/library/std/range/only.html? -- Andrei
Ah, sorry I missed that you mentioned it. -- Andrei
Yeah about that... Maybe I'm looking at this in the wrong way,
but I'm not sure I understand how using only would actually work
now that I think about it. I can haz enlightenment? :o
If I wanted to write (contrived example) a function that may or
may not produce a result, with an argument that it will use if
present but can do work without (think servers, async,
incomplete/partial json data, etc).
// a - there's no Only!T, so I don't have a type to work with
// b - I need to constrain function to element type and input
range
// c - and what do i do if range has more than one value in it?
auto maybeResult(Range)(Range r)
if (isInputRange!Range && is(ElementType!Range == int))
{
enforce(r.walkLength <= 1); // should I runtime kill?
return v.map!(a => a + 1); // do I return a map of all elements?
return v.take(1).map!(a => a + 1); // do I take(1) since that's
what this function needs?
// what do I do with the rest then if I don't have the enforce
above?
}
And then calling it:
auto a = [1];
a = a.maybeResult; // nope, because you can't know what ranges
are being used inside.
// So you need to create a new var
auto b = a.maybeResult;
===
With an optional this'd be:
Optional!int maybeResult(Optional!int a) {
return a + 1;
}
auto a = some(1);
a = a.maybeResult;
Cheers,
- Ali
