Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 03:17:06 UTC, Ali wrote: As a realistic short term fix, I think both Andrei and Walter, need to streamline and be more vocal about long term plans, because this is obviously a source of confusion for many, and a source for a lot of rants My summary is that D means different things to different people. D has put in the kitchen sink. It tries to please everyone which means it is a complex toolbox. One thing I have learnt by lurking in this project is how much effort goes into compiler/library development to make it great. NoGC and safe just show how hard that can be. Lots of work on corner cases. Maybe with hindsight D should have been less OOP and more FP (destructuring data anyone?), but then you lose all those who want/are used to that paradigm. I use quite a few languages. For me D is the most powerful language I have for getting performance. Artem wrote Sambamba as a student https://github.com/biod/sambamba and it is now running around the world in sequencing centers. Many many CPU hours and a resulting huge carbon foot print. The large competing C++ samtools project has been trying for 8 years to catch up with an almost unchanged student project and they are still slower in many cases. https://groups.google.com/forum/#!topic/sambamba-discussion/z1U7VBwKfgs Just saying. Much better to choose D over C++. I also work on a C++ project and I find it to be a royal pain compared to writing software in D. Note that Artem used the GC and only took GC out for critical sections in parallel code. I don't buy these complaints about GC. The complaints about breaking code I don't see that much either. Sambamba pretty much kept compiling over the years and with LDC/LLVM latest we see a 20% perfomance increase. For free (at least from our perspective). Kudos to LDC/LLVM efforts!! Very excited to see gdc pick up too. We need the GNU projects. So, do we need change? You can always try and improve process and over the last years W&A have been pushing for that. Let me state here that D is anarchy driven development in all its glory (much like the Linux kernel). I believe it is great. I think, in addition to standard packaging in Linux distros (which is coming), D could use more industry support (much like the Linux kernel). D being a performance language for software engineers I would look at the extremes of HPC and mobile to succeed. How do we wake those companies up? Especially those with large investments in C++. Those we should invite to Dconf. I remember one guy at Google telling me that every time someone would bring up "Why don't we write this in D instead?". That was 10 years ago. Google invested in Python and Go instead - but still write heaps of code in C++. Go figure.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html My summary of this discussion * D as a language have issues, issues serious enough that they cannot be fixed without introducing breaking changes, which more or less means creating a spinoff language, or languages * D as a project have issues, those cannot be fixed, because D's main attraction is Andrei and Walter are both the problem and the solution, again, no real solution unless their is a spinoff languages owned by a different group I think that a lot of the complainers, are expecting that either Andrei or Walter, will create a new version of D that is basically a new language, or that they will explicitly create a new language that have all of D good points but none of the bad I dont think that Andrei or Walter, are interested in creating a new language, I think they will keep trying to improve D incrementally As a realistic short term fix, I think both Andrei and Walter, need to streamline and be more vocal about long term plans, because this is obviously a source of confusion for many, and a source for a lot of rants
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 23:46:54 UTC, Radu wrote: I think you need to look at Dlang as what it is - still WIP and mostly *community driven*. I got used to the occasional breaking or regression, and the best I can advise is to try to report or fix them if you can. There are still lots of things to be removed/added/or fixed in the language and the standard libraries - breakage will appear, and looks that most users expect some kind of breakage. This is not good enough. Yes, D users expect "some kind of breakage" - all the time, and this is exactly the problem. In D people have put up with breakages for too long believing things will improve in the long run, and because of this it is assumed that users will put up with it forever and ever and ever. Has it never occurred to anyone that many users have got sick and tired of this? I mean, there are other languages out there and you can get things done in no time and your program will still compile next week. I say it again, D has come a long way and things were looking good, but it's going nowhere. Look at this thread. Very intelligent people, top programmers, top engineers are arguing over details, while users (of D) who are programming for other users are trying to say "Stop!". There's a huge difference between developing D and developing _in_ D.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 22:53:44 UTC, Walter Bright wrote:
On 8/25/2018 2:46 PM, David Nadlinger wrote:
At least for the transition period, I'd have attributes only
apply to the user-specified code and infer them for the actual
full constructor. (We can still print a deprecation warning if
they don't match.) —David
Inferring is not good enough, for example:
https://github.com/dlang/dmd/pull/6816#issuecomment-307972790
There the @safe constructor is calling a destructor that calls
free(). It can't be inferred as @safe.
How did you interpret "only apply to the user-specified code"? In
this example, the `@safe` in `this() @safe {}` would only apply
to `{}`.
This necessitates being careful with the error message in a case
like this
struct UnsafeDtor { @system ~this() {} }
struct Foo {
UnsafeDtor ud;
this(int a) @safe {
if (!a) throw Exception("boo");
}
}
void bar() @safe {
auto f = Foo(1);
}
as just printing "cannot call @system constructor" would be a bit
misleading. It should work without surprises otherwise, though,
and can be supplemented with deprecation warnings if the
specified "inner" and inferred "outer" attributes don't match.
—David
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
Every programmer who says this also demands new (and
breaking) features.
"Every programmer who..." Really?
You want to remove autodecoding (so do I) and that will break
just about every D program in existence. For everyone else,
it's something else that's just as important to them.
For example, Shachar wants partially constructed objects to be
partially destructed, a quite reasonable request. Ok, but
consider the breakage:
struct S {
~this() {}
}
class C {
S s;
this() nothrow {}
}
I.e. a nothrow constructor now must call a throwing destructor.
This is not some made up example, it breaks existing code:
https://github.com/dlang/dmd/pull/6816
If I fix the bug, I break existing code, and apparently a
substantial amount of existing code. What's your advice on how
to proceed with this?
Run semantic3 on the constructor independent of the requirement
to destruct already constructed objects. If the constructors is
nothrow then there is no need to have the destructors run or the
eh code at all, because no Exceptions can be thrown (an Error may
be thrown but that will kill the program). This is how I intend
to fix it after I refactor semantic3.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 22:55:05 UTC, RhyS wrote: On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote: And yet some of the heaviest users of D have said in public 'please break our code". I wonder why that could be. My answer to that is simply: Break stuff so it becomes STABLE! Remove junk and clutter. Do NOT break stuff to add more unneeded features inside a rotten carcass. Be honest, how many people will use BetterC in production! Not as some homework or sided projects with a few dozen lines. Very few and that is the issue ... That is development time that can have gone into documentation, bug fixes... I think you need to look at Dlang as what it is - still WIP and mostly *community driven*. I got used to the occasional breaking or regression, and the best I can advise is to try to report or fix them if you can. There are still lots of things to be removed/added/or fixed in the language and the standard libraries - breakage will appear, and looks that most users expect some kind of breakage. As for DasBetterC, you might underestimate the potential it has for migrating old C code fully of partially to D, or the nice thing that it enabled Webassembly targeting. But for me it is important in the way that it acted as a catalyst for people to look at the issues Dlang and Druntime had, and made them better by making them more modular. This is a win for Dlang in the long run, maybe the betterC flag will be removed at some point because the compiler and runtime will be smart enough to enable pay-as-you-go intrinsically.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:19:44 UTC, Walter Bright wrote: On 8/25/2018 6:32 AM, Timon Gehr wrote: (Or at least, not wrong. Using e.g. `void*` instead of an incompatible type would already be an improvement.) Making it void* is a reasonable idea. If/when (I really hope the latter) DIP 1011 gets in it should be extern(delegate) with `ref typeof(this)` as the first parameter.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 22:55:05 UTC, RhyS wrote: Be honest, how many people will use BetterC in production! Much, MUCH more likely than that I would ever use full D with GC in production. Really, if I want a language with a GC, D is not that good. Why wouldn't I use a JVM language (Java, Kotlin, Scala) or Go or something else? Notice how they all have precise GCs? Or maybe I'd use a functional language like OCaml or Haskell. Same deal, precise GC. The truth is that D is by design NOT a replacement for C++ when a low level systems programming language must be used. DasBetterC is close to what I'd like when I have to use C++, but not yet ideal. I'm starting to think that Rust (or, C++ 17 and beyond) will win this battle because every other language shows up with stuff I don't want.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote: And yet some of the heaviest users of D have said in public 'please break our code". I wonder why that could be. My answer to that is simply: Break stuff so it becomes STABLE! Remove junk and clutter. Do NOT break stuff to add more unneeded features inside a rotten carcass. Be honest, how many people will use BetterC in production! Not as some homework or sided projects with a few dozen lines. Very few and that is the issue ... That is development time that can have gone into documentation, bug fixes...
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/25/2018 2:46 PM, David Nadlinger wrote: On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote: If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this? At least for the transition period, I'd have attributes only apply to the user-specified code and infer them for the actual full constructor. (We can still print a deprecation warning if they don't match.) —David Inferring is not good enough, for example: https://github.com/dlang/dmd/pull/6816#issuecomment-307972790 There the @safe constructor is calling a destructor that calls free(). It can't be inferred as @safe. Sure, we can do warnings and deprecations, but the user will sooner or later have to change his code, and Chris' code from 2009 is not going to compile without changes. --- A further issue with inferring for destructors is that why do it for destructors and not other member functions? It's a good question, without obvious answers. --- The larger issue here is there is no solution where someone's ox doesn't get gored. I have to make a judgement call on what is overall best for the future of D. And the ox gets inevitably gored. Even C, probably the slowest moving major language, has these issues.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote: I got bitten by this just yesterday. Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/ Welcome to my life with D for the past 2 years. You can not rely on D as new features break old ones or create regressions. You can also not rely on its packages, because new features or changes break packages. Or packages that depend on each other break. In the end, the answer is simply, you can not rely on D. Unless you want to stick with one compiler version and write every feature yourself. Other languages also suffer from issues like this but they get fixed so fast that in general the impact is rarely noticed. With D you can be stuck waiting days or weeks! or spending hours fixing it yourself. Again and again ... So your time doing actual work is absorbed by constant fixing D issues. Some will say that contributing to a open source program is the cost to pay but when you have the choice between well established and stable languages and D... That cost very fast becomes: Lets use C/C++/Rust/Go/... And it is saying a lot when young languages like Rust and Go gave me less trouble then D. D has potential but this push for BetterC, better C++ integration, more DIPS down the pipeline... When is enough, enough! It feels like D is more some people their personal playground to push and try out new features then a actually well supported and stable language. You can play around with D at home or for small project but for long term projects, where you bank your company's future on D, you need to be crazy.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote: If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this? At least for the transition period, I'd have attributes only apply to the user-specified code and infer them for the actual full constructor. (We can still print a deprecation warning if they don't match.) —David
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote: I.e. a nothrow constructor now must call a throwing destructor. This is not some made up example, it breaks existing code: https://github.com/dlang/dmd/pull/6816 If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this? Deprecated message and allow it (nothrow and @safe\system checks) for a year or two? Guaranteed destructor call is important enough to actually bother with this IMO. Nothrow and other attribute deduction could also be a temporary option.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
Every programmer who says this also demands new (and breaking) features.
"Every programmer who..." Really?
You want to remove autodecoding (so do I) and that will break just about every D
program in existence. For everyone else, it's something else that's just as
important to them.
For example, Shachar wants partially constructed objects to be partially
destructed, a quite reasonable request. Ok, but consider the breakage:
struct S {
~this() {}
}
class C {
S s;
this() nothrow {}
}
I.e. a nothrow constructor now must call a throwing destructor. This is not some
made up example, it breaks existing code:
https://github.com/dlang/dmd/pull/6816
If I fix the bug, I break existing code, and apparently a substantial amount of
existing code. What's your advice on how to proceed with this?
Re: D is dead
On 8/25/2018 7:37 AM, Jonathan M Davis wrote: In general, any place where D was designed around the idea that something would _always_ be there (e.g. init values and default initialization) but we've then later added the ability to get around it (e.g. void initialization or @disable) has tended to not play well with everything else and has caused some fun problems. It's why that stuff isn't allowed in @safe code, and hence one should realize one is taking responsibility from the compiler for ensuring the correctness. D expects someone writing @system code to have a much greater awareness of how the language and the machine works. If you remove the blade guards from the table saw, more things can be done with it, but you'll need to take much greater care using it.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/25/2018 6:32 AM, Timon Gehr wrote: (Or at least, not wrong. Using e.g. `void*` instead of an incompatible type would already be an improvement.) Making it void* is a reasonable idea.
Re: D is dead
On 8/25/2018 6:33 AM, Shachar Shemesh wrote: If you allow a feature to be disabled, you really need to keep in mind that feature might be well and truly disabled. Disabling default initializations is not @safe, and that means taking responsibility for it not being default initialized. It's like turning off array bounds checking. Then it's up to you to ensure no buffer overflows are happening. On a pragmatic note, what you're asking for is a set of nested try blocks, one for each field with a throwing constructor, as opposed to one try block around the entire function. This is an expensive proposition in terms of performance. You'll need to weigh that very carefully against saving the default zero initialization of the struct, which is very efficient.
Re: Using a C++ class in a D associative array
On 2018-08-22 23:00, kinke wrote: It could be simpler (and slower ;)) by using `m_flags & ClassFlags.isCPPclass`. There's Objective-C classes as well, which does not seem to have an entry in TypeInfo_Class.ClassFlags. -- /Jacob Carlborg
Re: [OT] "I like writing in D" - Hans Zimmer
On Wednesday, 22 August 2018 at 22:51:58 UTC, Piotrek wrote: You may already know that from youtube. It seems D starts getting traction even among musicians: https://www.youtube.com/watch?v=yCX1Ze3OcKo&feature=youtu.be&t=64 That really put a smile on my face :D And it would be a nice example of a D advertising campaign ;) Cheers, Piotrek D is a great key, there's a number of beautiful compositions written in it. I think most notable one is D-spacito. People liked it so much they are waiting for the second version.
Suggestion: Bug fix releases (Re: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html I find Dicebot's article resonates quite strongly with me. I have been using D for hobby projects (i.e. not a lot of code) for about 3 years. During that time I found a handful of compiler bugs. An average programmer like me shouldn't be able to find bugs in the compiler so frequently. And there are other problems, like language features interact weirdly, unhelpful/misleading error messages. All of this really gives me an impression that D is an immature language. I think this is a pretty big problem, and I think it has not been given enough attention (never appeared in bold in the vision documents), probably until now. So what if, we just forget about @safe, @nogc, and stuff like that for while, do a feature freeze and try our best to fix all the bugs, and rough corners?
Re: D is dead
On Saturday, August 25, 2018 7:33:47 AM MDT Shachar Shemesh via Digitalmars-
d wrote:
> On 25/08/18 10:56, Walter Bright wrote:
> > On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
> >> No, unlike what I suggest, that doesn't work without carefully
> >> reviewing every single place you put it to see whether the constructor
> >> actually supports destructing a partially constructed object.
> >
> > All D objects are default-initialized before the constructor sees it
> > (unlike C++). A destructor should be able to handle a
> > default-initialized object.
>
> I'm not talking about a default initialized object. I'm talking about an
> object where the constructor started running, but not to completion.
>
> With that said, this statement is, I think, representative of the Lego
> problem D has. All D objects? Really? Even this one?
>
> struct A {
>int a;
>
>@disable this();
>@disable init;
>
>this(int number);
>~this();
> }
>
> If you allow a feature to be disabled, you really need to keep in mind
> that feature might be well and truly disabled.
As I understand it, it's not actually possible to disable the init value.
Even if bodies are provide for the constructor and destructor (so that they
don't give you errors), you just end up with an error like
q.d(14): Error: no identifier for declarator init
You could replace that with something like
@disable void init();
but that's only legal because declaring a member named init has never been
made illegal even though it's generally been agreed upon (by most of the
core devs anyway) that it should be. The way D is designed, there _must_ be
an init value. The closest that you can get to disabling it is the
@disable this();
line which just disables default initialiation. The init value still gets
used when constructing the object, and it can still be used explicitly.
If void initialization of member variables worked the way that some folks
think that it should - including Andrei and Walter:
https://issues.dlang.org/show_bug.cgi?id=11331
https://issues.dlang.org/show_bug.cgi?id=11817
then I think that that would definitely be an example that would fit the
point that you're trying to make (since they you have to worry about the
constructor partially setting values on top of garbage and then trying to
destroy that correctly), but at least for the moment, it doesn't actually
work. Having to worry about destructors running on void initialized objects
is a similar problem, but not quite the same, since that doesn't involve an
exception being thrown from a constructor. Regardless, even if a type is
designed such that its init value can be properly destroyed, and you don't
have to worry about void initialization, it can't be all that hard to design
it such that the destructor won't work properly if the constructor doesn't
complete properly.
What all of this makes me think of though is a similar problem that
FeepingCreature loves to bring up and complain about, which is that
invariants that consider the init value to be invalid (e.g. if the invariant
checks that a member variable is non-null) blow up in your face if the type
has a destructor, because the invariant gets run before the destructor, and
member variables that are pointers will of course be null in the init value.
And while disabling default initialization helps, it doesn't fix the problem
because of code that explicitly uses the init value. To work around this,
he's come up with some weird solution using unions that's probably going to
break on him at some point (though if I understand correctly, he's changed
std.typecons.Nullable to use it, which makes it a lot less likely that it's
going to break). But really, having an invariant that fails for the init
value is generally a recipe for disaster, much as it's easy to see why it
would be desirable for stuff like pointers.
What's worse is that once void initialization is involved, an invariant is
almost certainly going to fail, because the invariant gets called before
opAssign. And that's the number one reason that I never use invariants in
structs anymore.
In any case, all of that is really a tangent with regards to init values,
but it's definitely a sign of how some of the stuff around init values,
constructors, and destructors doesn't really play well together. And sadly,
it's really not that hard to get into a state where your destructor is going
to have serious problems if it's run. In general, any place where D was
designed around the idea that something would _always_ be there (e.g. init
values and default initialization) but we've then later added the ability to
get around it (e.g. void initialization or @disable) has tended to not play
well with everything else and has caused some fun problems.
- Jonathan M Davis
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote: On Saturday, 25 August 2018 at 10:52:04 UTC, Chris wrote: On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: There are quite a few different sorts of concerns raised on this thread and they are linked by how people feel not by logic. I have a lot of respect for Shachar technically but I personally found the way he expressed his point of view a bit odd and unlikely to be effective in achieving whatever it is his goal was, also bearing in mind he doesn't speak for Weka. It might be helpful to go through the concerns and organise them based on logical ordering because an outburst of emotion won't translate in itself into any kind of solution. You can approach things rationally, make a list of the issues, have a big discussion again. and nothing will change.
Re: D is dead
On 25/08/18 10:56, Walter Bright wrote:
On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
No, unlike what I suggest, that doesn't work without carefully
reviewing every single place you put it to see whether the constructor
actually supports destructing a partially constructed object.
All D objects are default-initialized before the constructor sees it
(unlike C++). A destructor should be able to handle a
default-initialized object.
I'm not talking about a default initialized object. I'm talking about an
object where the constructor started running, but not to completion.
With that said, this statement is, I think, representative of the Lego
problem D has. All D objects? Really? Even this one?
struct A {
int a;
@disable this();
@disable init;
this(int number);
~this();
}
If you allow a feature to be disabled, you really need to keep in mind
that feature might be well and truly disabled.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 25.08.2018 03:43, Walter Bright wrote:
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo = &SomeStruct.foo;
foo(); // runtime error, isn't actually safe uses wrong calling
convention as well
}
Not really lack of feature so much as there exists broken code. This
has been valid code for god knows how long. At some point it was
usable in @safe, but it looks you can't take an address of a member
function without "this" as well in safe anymore.
That's because it isn't safe. But being able to take the address is
important for system work.
So is taking the address of an `int` variable. The analogous point is
that the type of `&x` for `x` an `int` should be `int*` (and not e.g.
`string*`). D gets this right, and it should be equally obvious that it
should get it right for the member function pointer case. (Or at least,
not wrong. Using e.g. `void*` instead of an incompatible type would
already be an improvement.)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 12:16:06 UTC, Laeeth Isharc wrote: Nassim Taleb writes about hormesis. I'm not sure that breakage of a non-serious kind is necessarily terrible. It might be terrible for you personally - that's not for me to judge. But it has the effect of building capabilities that have value in other ways. Unless you can afford to spend a lot of time on just fixing things, even small changes are annoying. I can understand that if a change is for the better in the long run it's worth breaking code, especially if you warn users so they know what's coming. But being "afraid" of every new version is not exactly a thing that encourages you to use D. Mind you, it's not just one program you have to maintain. Usually you have libraries and modules (and third party libs) that you haven't touched for a year or so and all of a sudden they don't compile anymore. You basically have to fix everything. And then there's vibe.d that has a hard time catching up with everything (Sönke is doing a great job, btw.) So you have a service based on vibe.d and somebody asks you to implement a trivial change (say sorting). You add it, compile it with the latest version of dmd and it gives you an error "XYZ is not supported when the moon is full". So you have to go back to a compiler version that works and you cannot benefit from e.g. the latest GC optimizations of D. You basically end up with a mess of different compilers for different code until you have fixed everything (which you don't have time for all the time). If your code is older than 2 or 3 versions of dmd, you are already in trouble and given the release frequency it happens quite fast. Imagine, to fix a trivial bug or implement a simple feature you may have to stick to an outdated version of dmd or you have a ratio of 10% time spent on your own code 90% time spent on fixing what the latest release broke. Not good. I am not being emotional, as you suggest. I'm talking about my practical experience and the challenges I face when I use D. And the prevalent attitude of "It's for your own good in the long run, you may not understand it now, but you will one day once you've followed the discussions on the forum and read the new specs!" is not helpful either when you need to get a job done. In the long run this might kill off D. And I'm someone who talks about it, imagine all the frustrated users who silently leave. I have never encountered any such problems with any other language so far. Something tells me that there's something wrong with how D is managed.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo = &SomeStruct.foo;
foo(); // runtime error, isn't actually safe uses wrong
calling convention as well
}
Not really lack of feature so much as there exists broken
code. This has been valid code for god knows how long. At some
point it was usable in @safe, but it looks you can't take an
address of a member function without "this" as well in safe
anymore.
That's because it isn't safe. But being able to take the
address is important for system work.
Which is my point. Why did you link that article then? It's not
safe due to the inherent flaw of D. It shouldn't return a
function() type. This is invalid code just outright, the type
system could easily be used to prevent this kind of mistake. But
instead it relies on the user knowing about the bug in D. Hell
like someone else mentioned, if it returned a delegate that would
make more sense. But it doesn't for whatever reason. There's a
lot of little things like this in D, and from your response you
obviously don't give a flying shit about fixing it as you don't
even see it as a problem. Just disable it in @safe and anyone
that needs to write in @system will have to deal with insanity
instead of having something reasonable.
Re: Is @safe still a work-in-progress?
On Saturday, 25 August 2018 at 02:37:00 UTC, Walter Bright wrote: On 8/23/2018 5:58 PM, Chris M. wrote: Seems to be more of a warning of what issues we may face if DIP25/DIP1000 are finally implemented. It would be good to consider NLLs as well before D is committed. No point in repeating issues that have already been studied. DIP25 waqs "finally implemented" several years ago, and works well. DIP1000 was implemented as well, it works, but it didn't cover the case of returning through a ref parameter. There's no way to "thoroughly vet" them before implementing. It doesn't happen with C++, either, somebody builds an implementation and then people try it out. What about my other point then on the syntax? I think something similar to what I suggested would be a much more flexible solution and is worth considering.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 10:52:04 UTC, Chris wrote: On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming. Earlier this year I had to "unearth" old Python code from 2009 (some parts of the code were even older). And you know what? It still worked! The same goes for Java code I wrote for Java 1.5. If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose. Also, a. adding new features doesn't necessarily mean that old code has to stop working and b. the last breaking change I would've supported was to get rid of autodecode, but that was never done and now it seems too late, yet it would have been a change of utmost importance because string handling is everywhere these days. But maybe it would have been too much tedious work and no real intellectual challenge, so why bother. Other languages do bother, however. You may brush our concerns aside with a throw away comment like the one above, but I'm not the only one who doesn't consider D for serious stuff anymore. As has been said before, none of the problems are unfixable - but if your answer is indicative of the D leadership's attitude towards concerned (longtime) users, then don't be surprised that we go back to Java and other languages that offer more stability. I still have maximum respect for everything you, Andrei and the community have achieved. But please don't throw it all away now. And yet some of the heaviest users of D have said in public 'please break our code". I wonder why that could be. It's also not terribly surprising that D2 code from 2009 doesn't always compile when you consider the release date of the language. Do you think it's a bad thing that imports were fixed, for example? That broke a lot of old code. "If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose. " I don't think this is true. Have slices, arrays, associative arrays and so on broken ? On the other hand D written like C that didn't get the imports right would have broken when the module system was corrected. This is a good thing. "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming." I don't think this is true either. It doesn't fit with my own experience and it doesn't fit with the growing enterprise adoption. That may be your personal perspective, but it's really hard to put yourself in the shoes of somebody in a very different situation that you have never encountered. There's intrinsically a tradeoff between different kinds of problems. Nassim Taleb writes about hormesis. I'm not sure that breakage of a non-serious kind is necessarily terrible. It might be terrible for you personally - that's not for me to judge. But it has the effect of building capabilities that have value in other ways. There are quite a few different sorts of concerns raised on this thread and they are linked by how people feel not by logic. I have a lot of respect for Shachar technically but I personally found the way he expressed his point of view a bit odd and unlikely to be effective in achieving whatever it is his goal was, also bearing in mind he doesn't speak for Weka. It might be helpful to go through the concerns and organise them based on logical ordering because an outburst of emotion won't translate in itself into any kind of solution.
Re: Is @safe still a work-in-progress?
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote: I'm not hostile to debate. I just don't care for "this is uncharted territory, so let's do nothing" which has been going on for probably 4 years now, coincident with "scope is incomplete, D sux". I.e. lead, follow, or get out of the way :-) Document it and we will help you get it reviewed and merged. Until you do that we will stay in your way. Heck, once we understand it we may even lead, but we can't do that if we have no clue WTF its supposed to do or why the changes are being made. At the very least PRs need detailed changelog entries and preferably spec updates and revisions to the DIP1000 proposal document. Heck even a wiki page would be useful. I'm trying to make the spec page on memory safe programming the authoritative source see https://github.com/dlang/dlang.org/pull/2453
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. "Every programmer who..." Really? Sorry, but this is not an answer. The fact remains that D is in danger of becoming unusable for real world programming. Earlier this year I had to "unearth" old Python code from 2009 (some parts of the code were even older). And you know what? It still worked! The same goes for Java code I wrote for Java 1.5. If you want to achieve something similar with D you have to write code that is basically C code, i.e. you shouldn't use any of the nicer or more advanced features, because they might break with the next dmd release - which kind of defeats the purpose. Also, a. adding new features doesn't necessarily mean that old code has to stop working and b. the last breaking change I would've supported was to get rid of autodecode, but that was never done and now it seems too late, yet it would have been a change of utmost importance because string handling is everywhere these days. But maybe it would have been too much tedious work and no real intellectual challenge, so why bother. Other languages do bother, however. You may brush our concerns aside with a throw away comment like the one above, but I'm not the only one who doesn't consider D for serious stuff anymore. As has been said before, none of the problems are unfixable - but if your answer is indicative of the D leadership's attitude towards concerned (longtime) users, then don't be surprised that we go back to Java and other languages that offer more stability. I still have maximum respect for everything you, Andrei and the community have achieved. But please don't throw it all away now.
Re: Embrace the from template?
On Saturday, 25 August 2018 at 09:30:27 UTC, Jonathan M Davis wrote: On Saturday, August 25, 2018 2:02:51 AM MDT Jonathan Marler via Digitalmars- d wrote: [...] Honestly, I don't want to be doing _anything_ like from with _any_ syntax. It's not just a question of from itself being too long. It's the fact that you're having to use the import path all over the place. I don't want to be putting anything other than the actual symbol name in the function's signature. IMHO, the ideal is to be able to just put import blah; at the top and then just use whatever was in module blah without having to repeat it everywhere. On the whole, I find this whole trend of constantly having to list exactly which symbols you're importing / exactly where a symbol comes from instead of just being able to just slap an import at the top and use the symbols te be way, way too verbose and a general maintenance problem. Yes, it can make it easier to figure out where a symbol came from when reading the code, and sometimes, it can improve compilation speed, but it means having to add a ton of extra code in comparison to just importing the module once, and you have to maintain all of that, constantly tweaking import statements, because you've changed which symbols you've used. It's like a cancer except that it comes with just enough benefits that some folks keep pushing for it. from is not the entire problem, but IMHO, it's definitely the straw that breaks the camel's back. It's taking all of this specificity way too far. I don't want to have to write or read code that's constantly putting import information everywhere. Sadly, it makes C's #include mess start looking desirable in comparison. - Jonathan M Davis I can certainly understand this sentiment. I personally use both styles depending no the situation. Each has their pros and cons, it's verbosity vs specificity. At least with D I can define the `from` template in my own projects even if the core language doesn't add it. I'm just of the opinion that it's useful enough to warrant additions to the core language in some form to make it easier to use. Thanks for chiming in.
Re: Embrace the from template?
On Friday, 24 August 2018 at 10:58:29 UTC, aliak wrote: On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template. [...] Of course, if we don't want to encourage use of the `from` template then this is not what we'd want. Does anyone have any data/experience with from? All I know is my own usage so feel free to chime in with yours. One of the first things I do after a dub init is create a file called internal.d with the from template in it. My only gripe about this template is it's "autocompletion-able-ness" in IDEs and if that can be handled. [...] Assuming you use DCD, even if CTFE is not handled it would be possible to detect the signature and to do with "from" what's usually done with an import. But it needs to be in a well defined module. You can open an issue in the repository asking for this and the feature will be added once the D-runtime PR merged.
Re: Embrace the from template?
On Saturday, August 25, 2018 3:30:27 AM MDT Jonathan M Davis via Digitalmars-d wrote: > from is not the entire problem, but IMHO, it's definitely the straw that > breaks the camel's back. It's taking all of this specificity way too far. > I don't want to have to write or read code that's constantly putting > import information everywhere. Sadly, it makes C's #include mess start > looking desirable in comparison. And honestly, once you also factor in stuff like the ever-increasing number of attributes that we have to worry about for functions, D in general is getting pretty ridiculously verbose. - Jonathan M Davis
Re: Embrace the from template?
On Saturday, August 25, 2018 2:02:51 AM MDT Jonathan Marler via Digitalmars- d wrote: > So assuming we're on the same page, you mentioned that the `from` > template is too verbose. I can see this point. To measure this I > consider the least verbose syntax for achieving the semantics of > the `from` template. The semantics can be stated as "take symbol > X from module Y". The shortest syntax possible would be the > following: > > > > If we defined ':' as the special "from operator" then the > following would be equivalent: > > foo.bar:baz > from!"foo.bar".baz > > Of course, reserving a special character for such an operator > should require that the operation is common enough to warrant the > reservation of a character. Less common operators piggy back on > keywords or combinations of special characters. For example, you > could make the syntax a bit more verbose by re-using the import > keyword, i.e. > > import(foo.bar).baz > > but this example is only 1 character less than the `from` > template. In the end I don't know if these semantics warrant a > special operator. Maybe they warrant new syntax, however, the > solution that requires the least amount of justification is > adding a template to `object.d`. The overhead will be virtually > zero and only requires a few lines of code because it leverages > existing D semantics. Honestly, I don't want to be doing _anything_ like from with _any_ syntax. It's not just a question of from itself being too long. It's the fact that you're having to use the import path all over the place. I don't want to be putting anything other than the actual symbol name in the function's signature. IMHO, the ideal is to be able to just put import blah; at the top and then just use whatever was in module blah without having to repeat it everywhere. On the whole, I find this whole trend of constantly having to list exactly which symbols you're importing / exactly where a symbol comes from instead of just being able to just slap an import at the top and use the symbols te be way, way too verbose and a general maintenance problem. Yes, it can make it easier to figure out where a symbol came from when reading the code, and sometimes, it can improve compilation speed, but it means having to add a ton of extra code in comparison to just importing the module once, and you have to maintain all of that, constantly tweaking import statements, because you've changed which symbols you've used. It's like a cancer except that it comes with just enough benefits that some folks keep pushing for it. from is not the entire problem, but IMHO, it's definitely the straw that breaks the camel's back. It's taking all of this specificity way too far. I don't want to have to write or read code that's constantly putting import information everywhere. Sadly, it makes C's #include mess start looking desirable in comparison. - Jonathan M Davis
Re: [OT] "I like writing in D" - Hans Zimmer
On Wednesday, 22 August 2018 at 22:51:58 UTC, Piotrek wrote: You may already know that from youtube. It seems D starts getting traction even among musicians: https://www.youtube.com/watch?v=yCX1Ze3OcKo&feature=youtu.be&t=64 That really put a smile on my face :D And it would be a nice example of a D advertising campaign ;) Cheers, Piotrek We don't deserve Hans Zimmer
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 22:04:49 UTC, H. S. Teoh wrote: I don't know how to reconcile these two. Perhaps if we had the manpower, we could maintain older versions for long enough to allow users to gradually rewrite to work with newer compilers, while the development branch can be bolder in making breaking changes that ultimately will result in a better, cleaner language. But I doubt we have the kind of manpower it takes to maintain something like that. In theory, it should be done so that there would be a longer-term unstable and and stable major branches. Stable major branch would behave mainly like we do now: new features allowed and breaking changes also allowed, but only with proper deprectation processes. In unstable major branch, you would do breaking changes, like removing autodecoding and exception throwing on general-purpose Phobos functions. No additional features here unless they depend on the breakages, to ease transitioning between the two. Thwy would be merged like perhaps every ten versions. I'm not saying this would necessarily work, but in theory it's the only way to get rid of historical babbage without becoming a moving target.
Re: D is dead
On Saturday, 25 August 2018 at 07:56:55 UTC, Walter Bright wrote: On 8/24/2018 6:34 AM, Shachar Shemesh wrote: No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object. All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object. Then we should add a switch to inject a unittest to run a destructor on a default initialisable object. i.e. if it has a static opCall or an @disable this(); then don't otherwise do. Otherwise this is a well disguised instance of faith based programming.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 21:57:55 UTC, Meta wrote: On Friday, 24 August 2018 at 21:53:18 UTC, H. S. Teoh wrote: I think it's clear by now that most of D's woes are not really technical in nature, but managerial. Agreed. I'm not sure how to improve this situation, since I'm no manager type either. Money is the only feasible solution IMO. How many people posting on this forum would quit their job tomorrow and solely contribute to OSS and/or work on their own projects if money wasn't an issue? The majority of people don't like being told what to do, and only want to work on what they're interested in. The only way to get them to work on something they're not interested in is to pay them. As the discussion seed is a post from Mihails, I want to recall the author [1]: "Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D. What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return." What are the opinions on that, specifically on the attitude? [1] https://forum.dlang.org/post/yadddavkoopieykha...@forum.dlang.org /Paolo
Re: Embrace the from template?
On Saturday, 25 August 2018 at 08:02:51 UTC, Jonathan Marler wrote: If we defined ':' as the special "from operator" then the following would be equivalent: foo.bar:baz from!"foo.bar".baz I agree with almost everything you wrote, but I think it would have to be double :: foo.bar::baz as otherwise it would be ambiguous with labels, consider the case with a flat hierarchy. foo:baz
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo = &SomeStruct.foo;
foo(); // runtime error, isn't actually safe uses wrong
calling convention as well
}
Not really lack of feature so much as there exists broken
code. This has been valid code for god knows how long. At some
point it was usable in @safe, but it looks you can't take an
address of a member function without "this" as well in safe
anymore.
That's because it isn't safe. But being able to take the
address is important for system work.
The stupid thing is you _have_ to cast (which is unsafe) the
return type to be correct.
This could be solvable with DIP1011 to make &SomeStruct.foo
return `extern(delegate) void function(ref Foo)` although it
makes no explicit mention other than "member functions be
implicitly convertible to extern(delegate) functions".
Re: Embrace the from template?
On Saturday, 25 August 2018 at 04:25:56 UTC, Jonathan M Davis wrote: On Friday, August 24, 2018 7:03:37 PM MDT Jonathan Marler via Digitalmars-d wrote: > What uses does this actually have, I only see one example > from the article and it is an oversimplistic example that > effectively translates to either phobos being used or not > being used. All the extra bloat this template would add to > the already bloated if constraints is not welcome at all. > The potential small benefit this might add isn't worth the > unreadable mess it will turn code into. I can't help but laugh when you say "all the extra bloat this template would add..." :) Sorry, I don't mean to insult but that really gave me a laugh. I hate to be blunt, but its clear from your response that you failed to grok the original post, which makes anything else I say pointless. So I'm going to slowly back away from this one...step...step..step*stp**s*...* It actually does add more template instantiations - and therefore arguably more bloat. It's just that because it more tightly ties importing to the use of the symbol, it reduces how many symbols you import unnecessarily, which can therefore reduce the bloat. So, if the symbol is used everywhere anyway, then from just adds bloat, whereas if it really is used in a more restricted way, then it reduces compilation times. The reason that I personally hate from's guts is because of how verbose it is. I'd _much_ rather see lazy importing be added like Walter likes to bring up from time to time. It should get us the reduction in compile times without all of the verbosity. As such, I would hate to see from in a place like object.d (or honestly, anywhere in druntime or Phobos), because then it might be used in Phobos all over the place, and I simply don't want to have to deal with it. It's bad enough that we're using scoped and local imports all over the place. They do help with tying imports to what uses them (and in the case of templated code can actually result in imports only happening when they need to), but it's so painfully verbose. I'd much rather not see the situation get that much worse by from being considered best practice instead of just fixing the compiler so that it's more efficient at importing and thus avoiding all of that extra verbosity in the code. - Jonathan M Davis Would love to see lazy imports. I actually started implementing them earlier this year. Just to make sure we're on the same page, normal imports (like import foo.bar;) cannot be lazy (see my notes at https://github.com/marler8997/dlangfeatures#lazy-imports). There are 3 types of imports that can be lazy: 1. importing specific symbols: `import foo.bar : baz;` 2. static imports `static import foo.bar;` 3. alias imports: `import bar = foo.bar;` So assuming we're on the same page, you mentioned that the `from` template is too verbose. I can see this point. To measure this I consider the least verbose syntax for achieving the semantics of the `from` template. The semantics can be stated as "take symbol X from module Y". The shortest syntax possible would be the following: If we defined ':' as the special "from operator" then the following would be equivalent: foo.bar:baz from!"foo.bar".baz Of course, reserving a special character for such an operator should require that the operation is common enough to warrant the reservation of a character. Less common operators piggy back on keywords or combinations of special characters. For example, you could make the syntax a bit more verbose by re-using the import keyword, i.e. import(foo.bar).baz but this example is only 1 character less than the `from` template. In the end I don't know if these semantics warrant a special operator. Maybe they warrant new syntax, however, the solution that requires the least amount of justification is adding a template to `object.d`. The overhead will be virtually zero and only requires a few lines of code because it leverages existing D semantics. In the end, these semantics are a great addition to D that makes lazy imports much easier to accommodate. I've had good success with `from` and think D would do well to implement these semantics in the core part of the language, whether with the template or with new syntax.
Re: D is dead
On 8/24/2018 6:34 AM, Shachar Shemesh wrote: No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object. All D objects are default-initialized before the constructor sees it (unlike C++). A destructor should be able to handle a default-initialized object.
