Re: What are the worst parts of D?
On Mon, 06 Oct 2014 13:34:23 +0200
Martin Drašar via Digitalmars-d digitalmars-d@puremagic.com wrote:
Ok, thanks for your answers. If you get your code to publishable
state, I am sure a lot of people will be interested.
as i can't publish my current version of cmdcon, i decided to write
another one from scratch. it contains alot less of mixin() codegens,
can do everything cmdcon.d can do and has structs/classes already
working. this is the excerpt from testing code:
import cong; // our console module
@ConName(intVar00)
@ConHelp(simple int variable)
@ConDescription(this is just an int variable.\nordinary one, nothing
special.)
__gshared int v0 = 42;
__gshared string v1 = hi!;
class A {
int i = 42;
string s = hello;
this () {}
this (string v) { s = v; }
int bar () { writeln(BAR: s=, s); return 666; }
void foo (float[] ff) {}
}
__gshared A a; // yes, this can be null
void foo (int n, string s=hi, double d=0.666) {
writefln(n=%s; s=[%s]; d=%s, n, s, d);
}
struct S {
int i = 666;
string s = bye;
int sbar () { writeln(SBAR: s=, s); return 666; }
void sfoo (float[] ff) {}
}
__gshared S s;
S s1;
void main (string[] args) {
writeln(known commands:);
foreach (auto n; conGetKnownNames()) writeln( , n);
writeln(---);
a = new A();
conExecute(a bar); // virtual method call for object instance
a.s = first change;
conExecute(a bar);
a = new A(second change);
conExecute(a bar); // virtual method call for ANOTHER object
instance
foreach (auto arg; args[1..$]) {
try {
writeln(# , arg);
conExecute(arg);
} catch (Exception e) {
writeln(***ERROR: , e.msg);
}
}
}
mixin(ConRegisterAll); // register 'em all!
==
known commands:
intVar00
a
foo
v1
s
---
(autoregistration rocks!)
some sample commands and results:
# intVar00
intVar00 42 (Int)
# foo 42
n=42; s=[hi]; d=0.666
# a i
a.i 42 (Int)
# a bar
BAR: s=second change
# s sbar
SBAR: s=bye
by default `mixin(ConRegisterAll);` tries to register all suitable
public symbols. one can use @ConIgnore UDA to ignore symbol and some
other UDAs to change name, add help and so on. alas, there is no way to
get Ddoc info in compile-time (what a pity!).
you can't register pointer objects (i.e. `__gshared int *a` will not
pass). it's doable (class fields are such objects internally), but i
just don't need this.
i also found some bugs in compilers (both dmd and gdc), but aren't
ready to dustmite and report 'em yet. GDC just segfaults now, but DMD
works.
there is also bug in CDGC, which took me a whole day of useless code
motion (i forgot that i'm using DMD built with CDGC ;-).
so the base mechanics is in place, i need to debug some things and
write simple sample with eventloop and telnet.
new code includes only WTFPL'ed parts, so it probably will be WTFPLed
too.
hope to finish this until weekend.
signature.asc
Description: PGP signature
Re: What are the worst parts of D?
Dne 13.10.2014 v 23:09 ketmar via Digitalmars-d napsal(a): as i can't publish my current version of cmdcon, i decided to write another one from scratch. it contains alot less of mixin() codegens, can do everything cmdcon.d can do and has structs/classes already working. this is the excerpt from testing code: Nice! That's what I call a can-do attitude :) I just happen to have a nice place in code where it can get used. I'm looking forward for playing with it. Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: What are the worst parts of D?
On Monday, 13 October 2014 at 21:09:29 UTC, ketmar via Digitalmars-d wrote: as i can't publish my current version of cmdcon, i decided to write another one from scratch. Cool, looks like a fun module to play with! :-)
Re: What are the worst parts of D?
as i see that some peopele are eager to play with cmdcon-ng, i setup a git repo with it: http://repo.or.cz/w/cong.d.git lay your hands while it hot! the code is little messy (there are some napoleonian plans which aren't made into it), but it should work. at least with unittests and sample. enjoy, and happy hacking! signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Tue, 14 Oct 2014 00:09:17 +0300 ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: let's stop hijacking this thread. here is The Official Thread for cmdcon-ng: http://forum.dlang.org/thread/mailman.772.1413240502.9932.digitalmar...@puremagic.com signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 19:00:44 UTC, Jonathan wrote: 3) Taking a hint from the early success of Flash, add Derelict3 (or some basic OpenGL library) directly into Phobos. Despite some of the negatives (slower update cycle versus external lib), it would greatly add to D's attractiveness for new developers. I nearly left D after having a host issues putting Derelict3 into my project. If I had this issue, we may be missing out from attracting newbies looking to do gfx related work. This reminds of an idea I've been pondering over for a while now. What if there was a language, that came with a standard toolkit for the more fun stuff such as OpenGL (There could be one already and I just don't know of it). But if we take that idea and try to apply it to D, we sortof get Deimos. Problem is Deimos, is pretty disjointed and is only updated every now and then, so then as an alternative I suppose there is Derelict. However, Derelict is maintained primarily by one person it seems (he does a great job though!), but Derelict isn't a standard feature (I know Deimos isn't either) and I *personally* don't care much for it's heavy leaning on dub. +Derelict isn't always a walk in the park to get running The alternative I'm suggesting, not by any means a top priority, is give Deimos a makeover (Derelict could possibly be a big part of this) and turn it into a semi-standard feature. So you can import phobos modules to do the stuff phobos normally does, but if you feel like making a quick tool or two, you can import deimos to get Tcl/tk like you would in python, or call OpenGl, or whatever other tool you need (doesn't have to be a graphics thing). Then at compile time the compiler could just copy or build the required dll's\so's object files into the specified directory, or whatever works best. On Wednesday, 8 October 2014 at 19:47:05 UTC, Jeremy Powers via Digitalmars-d wrote: Personally I take the opposite view - I'd much prefer a strong and easily consumed third-party library ecosystem than to shove everything into Phobos. Dub is a wonderful thing for D, and needs to be so good that people use it by default. Not to initiate my biweekly not a fan of dub conversation, but just wanna say real quick: Not everyone really likes to use dub. The only thing I like about it, is using it as the build script for a library to get the .lib files and whatnot. Though I don't feel like it really adds a drastic improvement over a .d build script. However, I don't work on any open source libraries, but maybe if I did, I'd like it better then..? Not something I would have an answer to right now, soo... yea:P Aside from what I mentioned above, I'm not sure where I'd like D to be at next to be perfectly honest. Stuff like no GC or C++ integration sound cool, but for me personally they just seem like 'neat' feature, not something that I feel like would change my current workflow for better or worse. Refinement of what's already in place sounds the best if anything. So those are just some passing thoughts of a stranger.. carry on, this thread has been very interesting so far ;P
Re: What are the worst parts of D?
On Saturday, 11 October 2014 at 03:39:10 UTC, Dicebot wrote: I am not speaking about O(1) internal heap increases but O(1) GC.malloc calls Typical pattern is to encapsulate temporary buffer with the algorithm in a single class object and never release it, reusing with new incoming requests (wiping the buffer data each time). Such buffer quickly gets to the point where it is large enough to contain all algorithm temporaries for a single request and never touches GC from there. In a well-written program which follows such pattern there are close to zero temporaries and GC only manages more persistent entities like cache elements. I understand that. My argument is that the same should apply to the entire heap: After you've allocated and released a certain amount of objects via GC.malloc() and GC.free(), the heap will have grown to a size large enough that any subsequent allocations of temporary objects can be satisfied from the existing heap without triggering a collection, so that only the overhead of actual allocation and freeing should be relevant.
Re: What are the worst parts of D?
Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. disclaimer: i am rather new to D and thus have a bit of a distant view. i think the above touches an important point. One thing GO does right is that they focused on feature rich stdlib/library ecosystem even though the language was very young. i'm coming from Ruby/Python and the reason i use those languages is that they have two things: a) they are fun to use (as andrei said in the floss interview: the creators had taste). b) huge set of libs that help me to get stuff done. now i think a) is fine, but with b) i am not sure if the strategy to get full C/C++ interop will not take too long and scare those people off that are not coming from C/C++. i think D is a fantastic tool to write expressive, fast and readable code. I don't need much more language features (again, look at GO...) but a solid foundation of libs to gain competitive advantage in my daily work.
Re: What are the worst parts of D?
On Saturday, 11 October 2014 at 09:26:28 UTC, Marc Schütz wrote: I understand that. My argument is that the same should apply to the entire heap: After you've allocated and released a certain amount of objects via GC.malloc() and GC.free(), the heap will have grown to a size large enough that any subsequent allocations of temporary objects can be satisfied from the existing heap without triggering a collection, so that only the overhead of actual allocation and freeing should be relevant. But it still requires GC to check its pool state upon each request and make relevant adjustments for malloc/free combo. For something like a hundred of temporary allocations per request it accumulates into notable time (and milliseconds matter). In absence of collection it is cheap enough to not care about single malloc call on its own but still not cheap enough to ignore costs of many calls. You have interested me in doing some related benchmarks though.
Re: What are the worst parts of D?
On 09/10/14 18:41, Andrei Alexandrescu wrote: With structured outputs there are a lot more issues to address: one can think of a JSONObject as an output range with put() but that's only moving the real issues around. How would the JSONObject allocate memory internally, give it out to its own users, and dispose of it timely, all in good safety? The XML DOM module in Tango uses, if I recall correctly, a free list internally for the nodes. It will reuse the nodes, if you want to keep some information you need to copy it yourself. -- /Jacob Carlborg
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote: On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu wrote: To clarify: calling GC.free does remove the root, correct? Not before it creates one. When I mean avoid creating new GC roots I mean no GC activity at all other than extending existing chunks That's interesting. So GC.malloc followed by GC.free does actually affect things negatively? Yes and quite notably so as GC.malloc can potentially trigger collection. With concurrent GC collection is not a disaster but it still affects the latency and should be avoided. Is it just the potentially triggered collection, or is the actual allocation+deallocation too expensive? Because the effects of the former can of course be reduced greatly by tweaking the GC to not collect every time the heap needs to grow, at the cost of slightly more memory consumption. If it's the latter, that would indicate that maybe a different allocator with less overhead needs to be used. Also let's note that extending existing chunks may result in new allocations. Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup. Hmm... but shouldn't this just as well apply to the temporary allocations? After some warming up phase, the available space on the heap should be large enough that all further temporary allocations can be satisfied without growing the heap.
Re: What are the worst parts of D?
On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote: On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote: On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu wrote: I think the worst of D is summarized quite well by the following: http://forum.dlang.org/post/m15i9c$51b$1...@digitalmars.com http://forum.dlang.org/post/54374de0.6040...@digitalmars.com And that is: the focus is no longer to do the right things about D, but to make D do the right thing for some shadowy customers that don't even care enough to come here and grumble. Let's put D2 in maintenance mode and take on D3 with this nice motto, taken from here: http://forum.dlang.org/post/3af85684-7728-4165-acf9-520a240f6...@me.com why didn't work like that from the beginning?
Re: What are the worst parts of D?
Tofu Ninja: What do you think are the worst parts of D? There are several problems in D/Phobos, but I think the biggest one is the development process, that is currently toxic: http://forum.dlang.org/thread/54374de0.6040...@digitalmars.com In my opinion an Open Source language with such development problem goes nowhere, so I think this needs to be improved. There are several possible ways to improve this situation, but perhaps the may one that can work is: Walter has to delegate another slice of its authority to the community of core dmd developers. This will cause some problems, perhaps an increase in confusion and pull reversions, Walter may lose a bit of his grasp of the dmd codebase (but this can be avoided if he reads the pull requests code), but I think overall the advantages in the long term are going to be bigger than the disadvantages. Regarding the product (and not the process), the design of a principled, sound, and flexible memory ownership system is an important part of D design to work on in the following months. It's going to add some complexity to D, but this is not the kind of complexity that kills a language, because if it's well designed it's going to give easy to read compile-time errors, it's not going to limit too much the variety of things that are currently allowed in D, and it's going to statically remove a significant amount of run-time bugs that are currently easy to do in D. The complexity that causes problems is not the one that requires you to understand a part of a well designed type system: it's the pile of arbitrary special cases and special cases of special cases you see in C++. D considers safety and correctness very important points of its design, and I agree with the importance of such points. Bye, bearophile
Re: What are the worst parts of D?
On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote: Yes and quite notably so as GC.malloc can potentially trigger collection. With concurrent GC collection is not a disaster but it still affects the latency and should be avoided. Is it just the potentially triggered collection, or is the actual allocation+deallocation too expensive? collection - for sure. allocation+deallocation - maybe, I have never measured it. It is surely slower than not allocating at all though. Because the effects of the former can of course be reduced greatly by tweaking the GC to not collect every time the heap needs to grow, at the cost of slightly more memory consumption. This is likely to work better but still will be slower than our current approach because of tracking many small objects. Though of course it is just speculation until RC stuff is implemented for experiments. Also let's note that extending existing chunks may result in new allocations. Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup. Hmm... but shouldn't this just as well apply to the temporary allocations? After some warming up phase, the available space on the heap should be large enough that all further temporary allocations can be satisfied without growing the heap. I am not speaking about O(1) internal heap increases but O(1) GC.malloc calls Typical pattern is to encapsulate temporary buffer with the algorithm in a single class object and never release it, reusing with new incoming requests (wiping the buffer data each time). Such buffer quickly gets to the point where it is large enough to contain all algorithm temporaries for a single request and never touches GC from there. In a well-written program which follows such pattern there are close to zero temporaries and GC only manages more persistent entities like cache elements.
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 21:07:24 UTC, Walter Bright wrote: On 10/6/2014 11:13 AM, Dicebot wrote: Especially because you have stated that previous proposal (range-fication) which did fix the issue _for me_ is not on the table anymore. I think it's more stalled because of the setExtension controversy. How about someone starts paying attention to what Don posts? That could be an incredible start. I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented. Wow, thanks, Walter! I'm wrong pretty regularly, though. A reasonable rule of thumb is to ask Daniel Murphy, aka yebblies. If he disagrees with me, and I can't change his mind within 30 minutes, you can be certain that I'm wrong. g
Re: What are the worst parts of D?
While it would be great if there were a company devoted to such D tooling, it doesn't exist right now. It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects. If anybody in the community cared as much about these features as you, they'd have done it already. It might be unfair but it is still a massive problem. The tooling compared to what I have with say C++ and Qt is not a fun experience. The language is nicer but the difference in tooling is making the difference seem a lot smaller than it should be.
Re: What are the worst parts of D?
Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've I don't know how well DCD works with other editors, but in Emacs at least (when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. Debugging can definitely be improved on. Even with Iain's fork of gdb I end up using writeln instead because it's frequently easier. Atila
Re: What are the worst parts of D?
On 09/10/2014 10:15 pm, Atila Neves via Digitalmars-d digitalmars-d@puremagic.com wrote: Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've I don't know how well DCD works with other editors, but in Emacs at least (when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies. I haven't found a way to make use of dub yet; all my projects involve other languages too. Also, I'm a primary windows user, so I haven't tried DCD to any great length. Alexander's auto complete is getting better, but it still gets easily confused, and the refactor and navigation tools are still basically missing. I feel like it would all be much easier if dmd was a lib that tooling could make use of. It seems like a lot of redundant effort to rewrite the language parser over and over when dmd already does it perfectly... Dan Murphy seemed to think ddmd would have some focus on usage as a lib? The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. Debugging can definitely be improved on. Even with Iain's fork of gdb I end up using writeln instead because it's frequently easier. Iain's work doesn't help on windows sadly. But I think the biggest problem is the local scope doesn't seem to be properly expressed in the debug info. It's a compiler problem more than a back end problem. The step cursor is all over the shop, and local variables alias each other and confuse the debugger lots. Also I can't inspect the contents of classes.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei Yes and this is exactly why I am that concerned about recent memory management policy thread. Don has already stated it in his talks but I will repeat important points: 1) We don't try to avoid GC in any way 2) However it is critical for performance to avoid creating garbage in a form of new GC roots 3) Worst part of Phobos is not GC allocations but specifically lot of temporarily garbage allocations This is a very simple issue that will prevent us from using and contributing to majority of Phobos even when D2 port is finished. Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. This is especially dissapointing because it was a first time when declared big effort seemed to help our needs but it got abandoned after very first attempts.
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 20:07:09 UTC, Walter Bright wrote: On 10/8/2014 4:17 AM, Don wrote: As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. I love the easy wins, too. It'd be great if you'd start a thread about Top 10 Easy Wins from yours and Sociomantic's perspective. Note that I've done some work on the deprecations you've mentioned before. That can possibly be done though it will take some efforts to formalize issues from the casual chat rants. More important issue is - what will happen next? I am pretty sure many of those easy wins are not easy at all in a sense that breaking changes are needed.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 09:37:29 UTC, Danni Coy via Digitalmars-d wrote: It might be unfair but it is still a massive problem. The tooling compared to what I have with say C++ and Qt is not a fun experience. The language is nicer but the difference in tooling is making the difference seem a lot smaller than it should be. This tooling does not exist in C++ magically. It exists there because many people were willing to work on it and much more were willing to pay for it. So unless you personally are ready to do one of those things those expectations will never come true.
Re: What are the worst parts of D?
Dicebot wrote: Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote: Dicebot wrote: Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't. Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us). Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 14:47:00 UTC, Dicebot wrote: On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote: Dicebot wrote: Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. Would it be impractical to support multiple approaches through templates? There seemed to be clear use cases where supplying memory to a function was a good idea and some where it wasn't. Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us). Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing. Multiple approaches to how library functions can handle memory.
Re: What are the worst parts of D?
Manu via Digitalmars-d digitalmars-d@puremagic.com wrote in message news:mailman.559.1412859804.9932.digitalmar...@puremagic.com... Dan Murphy seemed to think ddmd would have some focus on usage as a lib? Yes, but it's a long way off.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote: Multiple approaches to how library functions can handle memory. As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.
Re: What are the worst parts of D?
On 10/9/14, 7:09 AM, Dicebot wrote: Yes and this is exactly why I am that concerned about recent memory management policy thread. Don has already stated it in his talks but I will repeat important points: 1) We don't try to avoid GC in any way 2) However it is critical for performance to avoid creating garbage in a form of new GC roots 3) Worst part of Phobos is not GC allocations but specifically lot of temporarily garbage allocations What would be a few good examples of (3)? Thanks. This is a very simple issue that will prevent us from using and contributing to majority of Phobos even when D2 port is finished. Switch to input/output ranges as API fundamentals was supposed to fix it. Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely. Walter and I have only recently achieved clarity on this. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way. I'm not sure I understand this. This is especially dissapointing because it was a first time when declared big effort seemed to help our needs but it got abandoned after very first attempts. It hasn't gotten abandoned; it's on the back burner. Lazification is a good thing to do, but won't get us closer to taking the garbage out. Andrei
Re: What are the worst parts of D?
Dicebot pub...@dicebot.lv wrote: On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote: Multiple approaches to how library functions can handle memory. As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time. To clarify: calling GC.free does remove the root, correct?
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu
wrote:
On 10/9/14, 7:09 AM, Dicebot wrote:
Yes and this is exactly why I am that concerned about recent
memory
management policy thread. Don has already stated it in his
talks but I
will repeat important points:
1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating
garbage in a
form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically
lot of
temporarily garbage allocations
What would be a few good examples of (3)? Thanks.
Infamous setExtensions
(https://github.com/D-Programming-Language/phobos/blob/master/std/path.d#L843)
immediately comes to mind. Usage of concatenation operators there
allocates a new GC root for a new string.
This is a very simple issue that will prevent us from using and
contributing to majority of Phobos even when D2 port is
finished.
Switch to input/output ranges as API fundamentals was supposed
to fix
it.
Unfortunately it doesn't. RC does. Lazy computation relies on
escaping ranges all over the place (i.e. as fields inside
structs implementing the lazy computation). If there's no way
to track those many tidbits, resources cannot be reclaimed
timely.
Are you trying to tell me programs I work with do not exist? :)
Usage of output range is simply a generalization of out array
parameter used in both Tango and our code. It is _already_ proved
to work for our cases. Usage of input ranges is less important
but it fits existing Phobos style better.
We also don't usually reclaim resources. Out application usually
work by growing constant amount of buffers to the point where
they can handle routine workload and staying there will almost 0
GC activity.
I don't understand statement about storing the ranges. The way I
have it in mind ranges are tool for algorithm composition. Once
you want to store it as a struct field you force range evaluation
via output range and store resulting allocated buffer. In user
code.
Custom management policies as you propose won't fix it at all
because garbage will still be there, simply managed in a
different way.
I'm not sure I understand this.
Typical pattern from existing D1 code:
// bad
auto foo(char[] arg)
{
return arg ~ aaa;
}
vs
// good
auto foo(char[] arg, ref char[] result)
{
result.length = arg.length +3; // won't allocate if already
has capacity
result[0 .. arg.length] = arg[];
result[arg.length .. arg.length + 3] = aaa[];
}
It doesn't matter if first snippet allocates GC root or
ref-counted root. We need the version that does not allocate new
root at all (second snippet).
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu wrote: Dicebot pub...@dicebot.lv wrote: On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote: Multiple approaches to how library functions can handle memory. As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time. To clarify: calling GC.free does remove the root, correct? Not before it creates one. When I mean avoid creating new GC roots I mean no GC activity at all other than extending existing chunks
Re: What are the worst parts of D?
On 10/9/14, 9:00 AM, Dicebot wrote: On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu wrote: Dicebot pub...@dicebot.lv wrote: On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote: Multiple approaches to how library functions can handle memory. As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time. To clarify: calling GC.free does remove the root, correct? Not before it creates one. When I mean avoid creating new GC roots I mean no GC activity at all other than extending existing chunks That's interesting. So GC.malloc followed by GC.free does actually affect things negatively? Also let's note that extending existing chunks may result in new allocations. Andrei
Re: What are the worst parts of D?
Am Thu, 09 Oct 2014 15:57:15 + schrieb Dicebot pub...@dicebot.lv: Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely. Are you trying to tell me programs I work with do not exist? :) Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Usage of input ranges is less important but it fits existing Phobos style better. We also don't usually reclaim resources. Out application usually work by growing constant amount of buffers to the point where they can handle routine workload and staying there will almost 0 GC activity. I don't understand statement about storing the ranges. The way I have it in mind ranges are tool for algorithm composition. Once you want to store it as a struct field you force range evaluation via output range and store resulting allocated buffer. In user code. I think Andrei means at some point you have to 'store the range' or create an (often dynamic) array from the range and then you still need some sort of memory management. Ultimately you still need some sort of memory management there and RC will be nice for that if you don't want to use the GC. You can also store the range to a stack buffer or use manual memory management. But ranges alone do not solve this problem and forcing everyone to do manual memory management is not a good replacement for GC, so we need the discussed RC scheme. At least this is how I understood Andrei's point.
Re: What are the worst parts of D?
On 10/9/14, 8:57 AM, Dicebot wrote: On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu wrote: Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely. Are you trying to tell me programs I work with do not exist? :) In all likelihood it's a small misunderstanding. Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Got it. Output ranges work great with unstructured/linear outputs - preallocate an array, fill it with stuff, all's nice save for the occasional reallocation when things don't fit etc. With structured outputs there are a lot more issues to address: one can think of a JSONObject as an output range with put() but that's only moving the real issues around. How would the JSONObject allocate memory internally, give it out to its own users, and dispose of it timely, all in good safety? That's why JSON tokenization is relatively easy to do lazily/with output ranges, but full-blown parsing becomes a different proposition. Andrei
Re: What are the worst parts of D?
On 10/9/14, 9:27 AM, Johannes Pfau wrote: Am Thu, 09 Oct 2014 15:57:15 + schrieb Dicebot pub...@dicebot.lv: Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely. Are you trying to tell me programs I work with do not exist? :) Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Usage of input ranges is less important but it fits existing Phobos style better. We also don't usually reclaim resources. Out application usually work by growing constant amount of buffers to the point where they can handle routine workload and staying there will almost 0 GC activity. I don't understand statement about storing the ranges. The way I have it in mind ranges are tool for algorithm composition. Once you want to store it as a struct field you force range evaluation via output range and store resulting allocated buffer. In user code. I think Andrei means at some point you have to 'store the range' or create an (often dynamic) array from the range and then you still need some sort of memory management. Ultimately you still need some sort of memory management there and RC will be nice for that if you don't want to use the GC. You can also store the range to a stack buffer or use manual memory management. But ranges alone do not solve this problem and forcing everyone to do manual memory management is not a good replacement for GC, so we need the discussed RC scheme. At least this is how I understood Andrei's point. Yes, that's accurate. Thanks! -- Andrei
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu wrote: To clarify: calling GC.free does remove the root, correct? Not before it creates one. When I mean avoid creating new GC roots I mean no GC activity at all other than extending existing chunks That's interesting. So GC.malloc followed by GC.free does actually affect things negatively? Yes and quite notably so as GC.malloc can potentially trigger collection. With concurrent GC collection is not a disaster but it still affects the latency and should be avoided. Also let's note that extending existing chunks may result in new allocations. Yes. But as those chunks never get free'd it comes to O(1) allocation count over process lifetime with most allocations happening during program startup / warmup. Don has mentioned this as one of important points during his DConf 2014 talk but it probably didn't catch as much attention as it should.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 16:41:22 UTC, Andrei Alexandrescu wrote: Usage of output range is simply a generalization of out array parameter used in both Tango and our code. It is _already_ proved to work for our cases. Got it. Output ranges work great with unstructured/linear outputs - preallocate an array, fill it with stuff, all's nice save for the occasional reallocation when things don't fit etc. With structured outputs there are a lot more issues to address: one can think of a JSONObject as an output range with put() but that's only moving the real issues around. How would the JSONObject allocate memory internally, give it out to its own users, and dispose of it timely, all in good safety? That's why JSON tokenization is relatively easy to do lazily/with output ranges, but full-blown parsing becomes a different proposition. This reminds me of our custom binary serialization utilities, intentionally designed in a way that deserialization can happen in-place using same contiguous data buffer as serialized chunk. It essentially stores all indirections in the same buffer one after other. Implementation is far from being trivial and adds certain usage restrictions but it allows for the same extremely performant linear buffer approach even with non-linear data structures. In general I am not trying to argue that range-based approach is a silver bullet though. It isn't and stuff like ref counting will be necessary at least in some domains. What I am arguing is that it won't solve _our_ issues with Phobos (contrary to previous range-based proposal) and this is the reason for being dissapointed. Twice as so because you suggested to close PR that turns setExtension into range because of your new proposal (which implies that efforts can't co-exist)
Re: What are the worst parts of D?
On 09/25/2014 02:49 PM, H. S. Teoh via Digitalmars-d wrote: Make-heads find the idea of the compiler being part of the input to a build rule strange; to me, it's common sense. Yes. This is exactly why (unless it's been reverted or regressed? I only mention that because I haven't looked lately) RDMD counts the compiler itself as a dependency. Because: $ dvm use 2.065.0 $ rdmd stuff.d [compiles] $ dvm use 2.066.0 $ rdmd stuff.d [silently *doesn't* recompile?!? Why is *that* useful?] Is *not* remotely useful behavior, basically makes no sense at all, *and* gives the programmer bad information. (Oh, it compiles fine on this new version? Great! I'm done here! Wait, why are other people reporting compile errors on the new compiler? It worked for me.)
Re: What are the worst parts of D?
On 10/9/2014 7:15 AM, Dicebot wrote: That can possibly be done though it will take some efforts to formalize issues from the casual chat rants. More important issue is - what will happen next? I am pretty sure many of those easy wins are not easy at all in a sense that breaking changes are needed. That's why I'd like to know what Don has in mind.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins.
Re: What are the worst parts of D?
On 08/10/2014 9:20 pm, Don via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. C++ might have helped us years ago, but I already solved those issues creatively. Debugging can't be solved without tooling and compiler support.
Re: What are the worst parts of D?
On 08/10/2014 11:55 pm, Manu turkey...@gmail.com wrote: On 08/10/2014 9:20 pm, Don via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. C++ might have helped us years ago, but I already solved those issues creatively. Debugging can't be solved without tooling and compiler support. Just to clarify, I'm all for nogc work; that is very important to us and I appreciate the work, but I support that I wouldn't rate it top priority. C++ is no significant value to me personally, or professionally. Game studios don't use much C++, and like I said, we already worked around those edges. I can't speak for remedy now, but I'm confident that they will *need* ldc working before the game ships. DMD codegen is just not good enough, particularly relating to float; it uses the x87! O_O
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via Digitalmars-d wrote: On 08/10/2014 9:20 pm, Don via Digitalmars-d So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. While it would be great if there were a company devoted to such D tooling, it doesn't exist right now. It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects. If anybody in the community cared as much about these features as you, they'd have done it already. I suggest you two open bugzilla issues for all these specific bugs or enhancements and put up bounties for their development. If you're not willing to do that, expecting the community to do work for you for free is just whining that is easily ignored.
Re: What are the worst parts of D?
My small list of D critiques/wishes from a pragmatic stance: 1) Replace the Stop the World GC 2) It would be great if dmd could provide a code-hinting facility, instead of relying on DCD which continually breaks for me. It would open more doors for editors to support better code completion. 3) Taking a hint from the early success of Flash, add Derelict3 (or some basic OpenGL library) directly into Phobos. Despite some of the negatives (slower update cycle versus external lib), it would greatly add to D's attractiveness for new developers. I nearly left D after having a host issues putting Derelict3 into my project. If I had this issue, we may be missing out from attracting newbies looking to do gfx related work. I'm sure this has been talked about, but I'll bring it up anyway: To focus our efforts, consider switching to ldc. Is it worth people's time to continue to optimize DMD when we can accelerate our own efforts by relying on an existing compiler? As some have pointed out, our community is spread thin over so many efforts... perhaps there are ways to consolidate that. Just my 2cents from a D hobbyist..
Re: What are the worst parts of D?
On Wed, Oct 8, 2014 at 12:00 PM, Jonathan via Digitalmars-d digitalmars-d@puremagic.com wrote: ... 3) Taking a hint from the early success of Flash, add Derelict3 (or some basic OpenGL library) directly into Phobos. Despite some of the negatives (slower update cycle versus external lib), it would greatly add to D's attractiveness for new developers. I nearly left D after having a host issues putting Derelict3 into my project. If I had this issue, we may be missing out from attracting newbies looking to do gfx related work. Personally I take the opposite view - I'd much prefer a strong and easily consumed third-party library ecosystem than to shove everything into Phobos. Dub is a wonderful thing for D, and needs to be so good that people use it by default.
Re: What are the worst parts of D?
On 10/8/2014 4:17 AM, Don wrote: As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. I love the easy wins, too. It'd be great if you'd start a thread about Top 10 Easy Wins from yours and Sociomantic's perspective. Note that I've done some work on the deprecations you've mentioned before.
Re: What are the worst parts of D?
On 10/8/14, 4:17 AM, Don wrote: On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei Exactly. C++ support is of no interest at all, and GC is something we contribute to, rather than something we expect from the community. That's awesome, thanks! Interestingly we don't even care much about libraries, we've done everything ourselves. So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. At Sociomantic, we've been successful in our industry using only the features of D1. We're restricted to using D's features from 2007!! Feature-wise, practically nothing from the last seven years has helped us! With something like C++ support, it's only going to win companies over when it is essentially complete. That means that working on it is a huge investment that doesn't start to pay for itself for a very long time. So although it's a great goal, with a huge potential payoff, I don't think that it should be consuming a whole lot of energy right now. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is special. As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment. I'd love to see us chasing the easy wins. That's of course good, but the reality is we're in a complicated trade-off space with important, urgent, easy to do, return on investment, resource allocation as axes. An example of the latter - ideally we'd put Walter on the more difficult tasks and others on the easy wins. Walter working on improving documentation might not be the best use of his time, although better documentation is an easy win. Andrei
Re: What are the worst parts of D?
On 10/6/2014 11:13 AM, Dicebot wrote: Especially because you have stated that previous proposal (range-fication) which did fix the issue _for me_ is not on the table anymore. I think it's more stalled because of the setExtension controversy. How about someone starts paying attention to what Don posts? That could be an incredible start. I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented.
Re: What are the worst parts of D?
On 09/10/2014 2:40 am, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via Digitalmars-d wrote: On 08/10/2014 9:20 pm, Don via Digitalmars-d So what do we care about? Mainly, we care about improving the core product. In general I think that in D we have always suffered from spreading ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished. And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. As someone who previously represented a business interest, I couldn't agree more. Aside from my random frustrated outbursts on a very small set of language issues, the main thing I've been banging on from day 1 is the tooling. Much has improved, but it's still a long way from 'good'. Debugging, ldc (for windows), and editor integrations (auto complete, navigation, refactoring tools) are my impersonal (and hopefully non-controversial) short list. They trump everything else I've ever complained about. The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority. While it would be great if there were a company devoted to such D tooling, it doesn't exist right now. It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects. If anybody in the community cared as much about these features as you, they'd have done it already. I suggest you two open bugzilla issues for all these specific bugs or enhancements and put up bounties for their development. If you're not willing to do that, expecting the community to do work for you for free is just whining that is easily ignored. We're just talking about what we think would best drive adoption. Businesses aren't likely to adopt a language with the understanding that they need to write it's tooling. Debugging, code competition and refactoring are all expert tasks that probably require compiler involvement. I know it's easy to say that businesses with budget should contribute more. But it's a tough proposition. Businesses will look to change language if it saves them time and money. If it's going to cost them money, and the state of tooling is likely to cost them time, then it's not a strong proposition. It's a chicken and egg problem. I'm sure business will be happy to contribute financially when it's a risk free investment; ie, when it's demonstrated that that stuff works for them.
Re: What are the worst parts of D?
On 9/25/2014 4:08 AM, Don wrote: I'd also like to see us getting rid of those warts like assert(float.nan) being true. https://issues.dlang.org/show_bug.cgi?id=13489 It has some serious issues with it - I suspect it'll cause uglier problems than it fixes. And adding a @ in front of pure, nothrow. https://issues.dlang.org/show_bug.cgi?id=13388 It has generated considerable discussion.
Re: What are the worst parts of D?
On Thursday, 9 October 2014 at 00:30:53 UTC, Walter Bright wrote: On 9/25/2014 4:08 AM, Don wrote: And adding a @ in front of pure, nothrow. https://issues.dlang.org/show_bug.cgi?id=13388 It has generated considerable discussion. Please break the language, now. --- /Paolo
Re: What are the worst parts of D?
On Wednesday, 8 October 2014 at 20:35:05 UTC, Andrei Alexandrescu wrote: On 10/8/14, 4:17 AM, Don wrote: On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote: And personally, I doubt that many companies would use D, even if with perfect C++ interop, if the toolchain stayed at the current level. That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is special. Well, when IMHO, when discussing 'strategies', pretty everything it's a speculation... C++ interlope can also be attrattive when you need to start a new project, a you need C++ libs. But, the point it's that, again, IMHO, you tend to conflate Facebook need with D need (I know I'll receive pain back for this ;-). Sociomantic is not so special at all, about not having a previous C++ codebase: I personally know plenty of cases like that. But if D don't stop thinking about new feature and never terminate the previous plans, well, my speculations is that I donno about future adopters, but for sure it's scouring actual adopters; and the for sure it's based on what we feel here in SR Labs company. That's of course good, but the reality is we're in a complicated trade-off space with important, urgent, easy to do, return on investment, resource allocation as axes. An example of the latter - ideally we'd put Walter on the more difficult tasks and others on the easy wins. Walter working on improving documentation might not be the best use of his time, although better documentation is an easy win. Well, I've read your and Walter comment on the multiple alias this PR, so good: but the point that it was the community that pushed both of you on that track, it's systematic about an attitude. And now, shields up, Ms Sulu! -- /Paolo
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic reference, but their destructor/disposer gets called. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as invalid. Later access to it shall triger an exception: invalidObject. Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes?
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote: On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that...
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic reference, but their destructor/disposer gets called. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as invalid. Later access to it shall triger an exception: invalidObject. Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes? Form that page again: I have found (dislcaimer: this is my experience, your mileage will vary) that because 90% of the time you don't need to worry about releasing a resource in C#, it is easy to forget to do a using the remaining 10%. In C++ you always need to worry about it, which makes it real easy to remember that when obtaining a resource make sure you have taken care of its release as well. (In essence, make sure it is stored in something whose destructor will free it). I have found this pattern a lot harder to follow in C# than in C++. Having said all that, there is a lot to like about .NET and C# as well. I just personally find that the whole garbage collector saves you aspect that is pitched in every intro to the language I have encountered more of a trap than a salvation.
Re: What are the worst parts of D?
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained why? as opposed to how?. Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. It feels like yet another random contribution, no different from contribution/idea of any other D user. +1 on all. I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects. +1000 --- /Paolo
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 07:44:56 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote: On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal.
Re: What are the worst parts of D?
Dne 3.10.2014 v 16:42 ketmar via Digitalmars-d napsal(a): alas, only very old and rudimentary module is available. basically, it's the core of the full-featured console, but... only the core, and not very well written. i'm planning to opensource fully working thingy with bells and whistles eventually, but can't do it right now. :-( anyway, here it is: http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d please note that this is not very well tested. i'm keeping it just for nostalgic reasons. ah, and you can ignore the license. consider that code as public domain/WTFPL. there is no struct/class support there, only variables and free functions. yet free functions supports various types of arguments and understands default agrument values. Thanks a lot. I just briefly gone through the code and I have a question about the console use: That code is able to register functions and variables with some annotations and execute them by string commands. How do you generally use it for debugging purposes? That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands? Also, how do you make your console work in multithreaded programs? Thanks, Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... What if you only had precise GC on class objects and nothing else? That believe could be done in a performant manner.
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 10:22:01 +0200 Martin Drašar via Digitalmars-d digitalmars-d@puremagic.com wrote: as i said this is the very first version of cmdcon, not the one i'm using now. i'm not able to publish the current version yet. That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands? it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later. Also, how do you make your console work in multithreaded programs? you should register only shared and global vars (and i'm really missing __trait(isGShared) here!), there is no sense to register thread locals in multithreaded program. but you can register free functions and execute 'em. that free functions should take care of threading. really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-) signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright wrote: On 9/24/2014 7:56 AM, Don wrote: For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? They do generate a warning if compiled with -w. What change in particular? I've got a nasty feeling that you misread what he wrote. Every time we say, breaking changes are good, you seem to hear breaking changes are bad! It would be helpful having a list of what breaking changes you had in mind. Perhaps it would be a good idea to have a themed update? Currently you and Andrei are busy with the C++ changes, when that is settling down maybe the community could focus on a cleaning house update. With clear update themes (which does not preclude the usual mixture of things also going on) people can air issues and get it ye or nay'd clearly. Combining the previously discussed auto-update code tool with a set of breaking changes would make sense.
Re: What are the worst parts of D?
Dne 6.10.2014 v 12:15 ketmar via Digitalmars-d napsal(a): On Mon, 06 Oct 2014 10:22:01 +0200 Martin Drašar via Digitalmars-d digitalmars-d@puremagic.com wrote: as i said this is the very first version of cmdcon, not the one i'm using now. i'm not able to publish the current version yet. That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands? it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later. Also, how do you make your console work in multithreaded programs? you should register only shared and global vars (and i'm really missing __trait(isGShared) here!), there is no sense to register thread locals in multithreaded program. but you can register free functions and execute 'em. that free functions should take care of threading. really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-) Ok, thanks for your answers. If you get your code to publishable state, I am sure a lot of people will be interested. Cheers, Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: What are the worst parts of D?
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting C++ and GC, and that's cool and all, but its also kind of meaningless because we can't read minds. Judging by the recent thread where someone (Ola?) asked what C++ support actually means and received precisely zero useful guidance, no one else does either. (This isn't to say I don't think it's important, but the scope of what you're doing right now and how it materially helps end users isn't really clear.) There was a go at properties SALT. -Wyatt
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via Digitalmars-d wrote: On Mon, 06 Oct 2014 07:44:56 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens. That's a bit unfair of you.
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 12:48:28 + Meta via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via Digitalmars-d wrote: On Mon, 06 Oct 2014 07:44:56 + Paolo Invernizzi via Digitalmars-d digitalmars-d@puremagic.com wrote: I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens. That's a bit unfair of you. that's what i see. even when people praying for breaking their code to fix some quirks in language, the answer is NO. why no? 'cause some hermit living in far outlands may wrote some code years ago and that code will break and hermit will be unhappy. unhappiness of active users doesn't matter. and about writing autofixing tool... silence is the answer. so will you accept that changes if we'll write dfix tool to automatically fixing source code? silence. play your little games, we don't care, as we don't plan to change that anyway, regardless of the tool availability. Walter once said that he is against dfix, and nothing was changed since. ah, maybe, we aren't interested... there is little motivation of doing work on dfix if it's not endorsed by leading language developers. and now for multiple alias this... as you can see this will not help c++ interop, and it will not help gc, so it can lay rotting on github. not a word, not even will not accept this or it's interesting, please keep it up-to-date while you can, we are little busy right now, but will look at it later. second-class citizens will not run away. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 10/5/14, 11:23 PM, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic reference, but their destructor/disposer gets called. It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as invalid. Later access to it shall triger an exception: invalidObject. Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes? The intermediate type between struct and class is struct. Andrei
Re: What are the worst parts of D?
On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting C++ and GC, and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: and now for multiple alias this... as you can see this will not help c++ interop, and it will not help gc, so it can lay rotting on github. not a word, not even will not accept this or it's interesting, please keep it up-to-date while you can, we are little busy right now, but will look at it later. second-class citizens will not run away. We will accept multiple alias this. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained why? as opposed to how?. Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained why? as opposed to how?. Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com --- /Paolo
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting C++ and GC, and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei Sure, the newsgroup is a great place to discuss the minutiae of specific features and figure out how they might be implemented and what design tradeoffs need to be made. I think we've shown we can disagree about the colour of any bikeshed of any shape and construction at this point! But in what venue do you feel comfortable holding the easily-accessible public record of your intent for C++ support so anyone wondering about this new mantra can get the summary of what it means for them _as an end user_ without scouring the NG and partially-piecing-it-together-but-not-really from a dozen disparate posts? To be succinct: how about an article? We're not asking for a discussion in this case so much as some frank sharing. D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? What kinds of things will this allow that were impossible before? How, specifically, do you envision that to look? Can you give example code that you would expect to work when it's done? What are the drawbacks you believe forward engineers will have to watch out for? It's okay to not have all the answers and explain that there are parts that may not make it because of various reasons. I somewhat feel that you're approaching this situation as if it that were all quite obvious. Maybe it is to you? I don't know. But I do know I'm not alone in the dark here. Please bring a lamp. -Wyatt
Re: What are the worst parts of D?
On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained why? as opposed to how?. Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com I understand the necessity for further scrutiny of that work. Even before that I owe Sönke Ludwig a review for std.data.json. There's a large list of things I need to do at work, mostly D-related, not all of which I am not at liberty to make public. On top of that I have of course other obligations to tend to. To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). Andrei
Re: What are the worst parts of D?
On 10/6/14, 7:36 AM, Wyatt wrote: To be succinct: how about an article? An article would be great once we have done something we can show. We're not asking for a discussion in this case so much as some frank sharing. Is there anything dishonest about sharing intent about the D programming language in the public forum of the D programming language? D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? We don't know yet, we're designing it - to wit, we're looking for help regarding exception interoperability. What kinds of things will this allow that were impossible before? The exact list is in the air. We're looking e.g. for the best policy on exceptions. Possible vs. impossible is btw a matter of scale, for example wrapping everything you need from C++ in C functions is possible in the small but impossible at scale. How, specifically, do you envision that to look? What is that? Can you give example code that you would expect to work when it's done? This was discussed already: we should be able to pass an std::vectorint by reference/pointer from C++ into D and use it within D directly, with no intervening marshaling. What are the drawbacks you believe forward engineers will have to watch out for? What's a forward engineer? It's okay to not have all the answers and explain that there are parts that may not make it because of various reasons. I somewhat feel that you're approaching this situation as if it that were all quite obvious. Maybe it is to you? I don't know. But I do know I'm not alone in the dark here. Please bring a lamp. It seems this is a simple misunderstanding. You're looking for a virtually finished product (article documenting how it works; analysis; design; projected impact) whereas we're very much at the beginning of all that. What's clear to me is we need better interop with C++, so I've put that up for discussion as soon as reasonable. You're asking for things that are months into the future. Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting C++ and GC, and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei Answer: On Friday, 26 September 2014 at 10:22:50 UTC, Joakim wrote: It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan. some sort of public plan of where you want the language to go. All I'm asking for is a public list of preapproved and maybe rejected features that the two of you maintain. Dfix might be on the preapproved list, ARC might be on the rejected. ;) You could also outline broad priorities like C++ support or GC improvement on such a webpage. You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle). Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction. Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up. It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit.
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The fact that its community, when faced with the question What do you think are the worst parts of D?, will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment. That being said, the second worst part of D for me is the current state of documentation, which is something that is often mentioned. I'd be happy to take part in a docs initiative where some of us sit together and talk about how we can improve the documentation of the language, collect input from outside, and then implement the changes that are found to be necessary. This would make it easier for people who don't wish to set up the entire build environment for the documentation on their side to participate in documentation adjustments by giving feedback, while a somewhat dedicated group of people then focus on making decisions reality.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 15:13:59 UTC, Nicolas F. wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The fact that its community, when faced with the question What do you think are the worst parts of D?, will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment. Heh, I think such self-criticism by the community is great, for example, I loved that I recently stumbled across this page on the wiki: http://wiki.dlang.org/Language_issues How many other languages can boast such a page of problems on their own wiki? :) Thanks to Vlad and Mike for writing it. People in this thread are emotional because they care: I don't think it's gone overboard given the real concerns they're stating. When the D community starts hiding its problems and stops critiquing its own efforts, sometimes passionately if that's what you truly feel, is when it starts going downhill.
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 15:22:17 + Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: People in this thread are emotional because they care yes. i don't think that anybody (including me ;-) wants to directly insult someone here. D is good, that's why not-so-good features are so annoying that we are writing such emotional postings. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 10/6/14, 8:35 AM, ketmar via Digitalmars-d wrote: On Mon, 06 Oct 2014 15:22:17 + Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: People in this thread are emotional because they care yes. i don't think that anybody (including me ;-) wants to directly insult someone here. I appeal to you and others to keep language and attitude in check. We all are well intended here, all we need to do is convert heat into work, which should be possible per the first and second principle of thermodynamics. All we need is some cooling :o). Andrei
Re: What are the worst parts of D?
On 10/6/14, 8:08 AM, Joakim wrote: You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle). Aye, something like that might be helpful. I'll keep it in mind. Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction. I'm not so sure that's a problem. It takes some connection to the language milieu before making a major contribution of the kind to be on a vision list. And once that connection is present, it's rather clear what the issues are. That's the case for any language. Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up. Yah, there's been some growing pains. Traffic is on the rise and unfortunately the signal to noise ratio isn't. Converting the existing passion and sentiment into workable items is a present challenge I'm thinking of ways to approach. It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit. That's sensible. Andrei
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 08:39:54 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: I appeal to you and others to keep language and attitude in check. i'm doing my best, rewriting my posts at least three times before sending. i bet noone wants to read the first variants. ;-) but this thread is a good place to show some emotions. i believe that we need such emotional ranting threads, so people can scream here and then calm down. sure it's very flammable; we must keep fire extinguishers at hand. ;-) signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:42:35 UTC, Andrei Alexandrescu wrote: On 10/5/14, 11:23 PM, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++. Yes, or that delete. And AFAIS not only C++ needs unique_ptr and shared_ptr, this ARC thing is the same in D. The intermediate type between struct and class is struct. D with classes, anyone?
Re: What are the worst parts of D?
On 10/5/14, 9:14 AM, Dicebot wrote: On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote: 1. C++ support is good for attracting companies featuring large C++ codebases to get into D for new code without disruptions. 2. Auto-decoding is blown out of proportion and a distraction at this time. 3. Ref counting is necessary again for encouraging adoption. We've framed GC as an user education matter for years. We might have even been right for the most part, but it doesn't matter. Fact is that a large potential user base will simply not consider a GC language. No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing could have been huge deal. I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release? Right now your rationales get lost in forum discussion threads and it is hard to understand what really is Next Big Thing and what is just forum argument blown out of proportion. There was a go at properties, at eliminating destructors, at rvalue references and whatever else I have forgotten by now. It all pretty much ended with do nothing outcome for one reason or the other. Let's see. We have properties, which indeed need some work done but don't seem to prevent people from getting work done. The discussion on eliminating destructors concluded with we don't want to do that for good reasons. For binding rvalues Walter has a tentative design that's due for an RFC soon. The fact that you don't seem to have a consensus with Walter on some topic (auto-decoding, yeah) doesn't help either. Language marketing is not about posting links on reddit, it is a very hard work of communicating your vision so that it is clear even to random by-passer. I think one good thing we can do is approach things in private before discussing them publicly. 2) reliable release base I think this is most important part of open-source infrastructure needed to attract more contributions and something that also belongs to the core team. I understand why Walter was so eager to delegate is but right now the truth is that once Andrew has to temporarily leave all release process has immediately stalled. And finding replacement is not easy - this task is inherently ungrateful as it implies spending time and resources on stuff you personally don't need at all. We now have Martin Nowak as the point of contact. And what if he gets busy too? :) Maybe you'll volunteer. 3) lack of field testing Too many new features get added simply because they look theoretically sound. What would those be? Consider something like `inout`. It is a very look feature to address an issue specific to D and it looked perfectly reasonable when it was introduces. And right now there are some fishy hacks about it even in Phobos (like forced inout delegates in traits) that did come from originally unexpected usage cases. It is quite likely that re-designing it from scratch based on existing field experience would have yielded better results. No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers. Policy-based design is more than one decade old, and older under other guises. Reference counting is many decades old. Both have been humongous success stories for C++. Probably I have missed the point where new proposal was added but original one was not using true policy-based design but set of enum flags instead (no way to use user-defined policy). Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment. Reference counting experience I am aware of shows that it is both successful in some cases and unapplicable for the others. But I don't know of any field experience that shows that chosing between RC and GC as a policy is a good/sufficient tool to minimize garbage creation in libraries - real issue we need to solve that original proposal does not mention at all. That's totally fine. A good design can always add a few innovation on top of known territory. In fact we've done some experimenting at Facebook with fully collected PHP (currently it's reference counted). RC is well understood as an alternative/complement of tracing. Anyhow, discussion is what the Request For Comments is good for. But please let's focus on actionable stuff. I can't act on vague doubts. No need to trust me or anyone, but at some point decisions will be made. Most decisions
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: We will accept multiple alias this. -- Andrei = IgorStepanov commented 6 days ago Please, someone, add label Needs Approval to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks. yebblies added Enhancement Needs Approval labels 6 days ago = Please grand approval there.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I did comment in this group. -- Andrei == IgorStepanov commented 17 days ago Ping === quickfur commented 14 days ago Wow. I have been waiting for this feature for a long time! Can't wait to see this merged. Ping @WalterBright ? == IgorStepanov commented 13 days ago @andralex Ping. Please comment the tests and conflict resolving semantic. === IgorStepanov commented 8 days ago @andralex ping ==
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). At least give such an explanation from time to time. Silence is the worst.
Re: What are the worst parts of D?
On 10/6/14, 9:16 AM, eles wrote: On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). At least give such an explanation from time to time. Silence is the worst. Wait, are we too active in the forums or too silent? -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 9:14 AM, eles wrote: On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: We will accept multiple alias this. -- Andrei = IgorStepanov commented 6 days ago Please, someone, add label Needs Approval to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks. yebblies added Enhancement Needs Approval labels 6 days ago = Please grand approval there. Will do, thanks. -- Andrei
Re: What are the worst parts of D?
Am 06.10.2014 10:12, schrieb eles: On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote: On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal. This abomination tends to be written by developers that don't care to learn how to use properly their tools. It is quite easy to just use using on every IDisposable resource. As for setting something to null just to let the GC know about it, a sign of premature optimization and a sign of not neither knowing how a GC works nor how to use a memory profiler. -- Paulo
Re: What are the worst parts of D?
On Mon, Oct 06, 2014 at 09:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 10/6/14, 9:16 AM, eles wrote: On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). At least give such an explanation from time to time. Silence is the worst. Wait, are we too active in the forums or too silent? -- Andrei It would be *very* nice if once in a while (say once a week, or once a month) you and/or Walter can do a little write-up about the current status of things. Say a list of top 5 projects currently being worked on, a list of the top 5 current priorities, a short blurb about progress this past week/month (which could be as simple as we've been swamped with fixing regressions, haven't been able to work on anything else, or Facebook has me on a short leash, I haven't been able to work on D, etc.). This should be in its own thread, titled something like Weekly [or monthly] status update, not buried underneath mountains of posts in one of our infamous interminable threads about some controversial topic, like to autodecode or not to autodecode. Of course, who am I to tell you what to do... but IMO a periodical high-level status update like the above would go a *long* way in dispelling complaints of lack of direction or unclear/unknown priorities. It doesn't have to be long, either. Even a 1 page (OK, OK, *half* a page), bullet-point post is good enough. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Re: What are the worst parts of D?
On 10/6/14, 9:58 AM, H. S. Teoh via Digitalmars-d wrote: It would be*very* nice if once in a while (say once a week, or once a month) you and/or Walter can do a little write-up about the current status of things. Say a list of top 5 projects currently being worked on, a list of the top 5 current priorities, a short blurb about progress this past week/month (which could be as simple as we've been swamped with fixing regressions, haven't been able to work on anything else, or Facebook has me on a short leash, I haven't been able to work on D, etc.). This should be in its own thread, titled something like Weekly [or monthly] status update, not buried underneath mountains of posts in one of our infamous interminable threads about some controversial topic, like to autodecode or not to autodecode. Of course, who am I to tell you what to do... but IMO a periodical high-level status update like the above would go a*long* way in dispelling complaints of lack of direction or unclear/unknown priorities. It doesn't have to be long, either. Even a 1 page (OK, OK, *half* a page), bullet-point post is good enough. That's a really nice idea. -- Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 15:05:31 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:36 AM, Wyatt wrote: D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? We don't know yet, we're designing it The exact list is in the air. We're looking e.g. for the best policy on exceptions. Possible vs. impossible is btw a matter of scale, for example wrapping everything you need from C++ in C functions is possible in the small but impossible at scale. Ah, I see what happened now! The way you've been pushing it, I was given to believe you had something resembling a grand vision of how you wanted C++ interoperability to work with some proposed syntax and semantics. If not something so grandiose, at least a pool of ideas written down? Or even just a mental list of things you think are important to cover? Regardless, these things ARE important to communicate clearly. This was discussed already: we should be able to pass an std::vectorint by reference/pointer from C++ into D and use it within D directly, with no intervening marshaling. Awesome, this is a start. It seems this is a simple misunderstanding. You're looking for a virtually finished product It really is a misunderstanding. Heck, I think it still is one because all we're really looking for is some inkling of what's on your agenda at a granularity finer than C++ and GC. If nothing else, a list like that gets people thinking about a feature ahead of the dedicated thread to discuss it. -Wyatt PS: Come to think of it, I may have been expecting a DIP?
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release? Because he is interested in language development direction but does not want to actively participate? It can be someone with bad early D experience wondering if anything has changed in last year. Or it can be developer from some company using D wanting to get quick overview what to expect from the language for the next year or so. For example I don't have time to follow Rust mail lists or GitHub commits but I do read blog posts of its developers regularly (including speculative ones) to see where it is heading. It is both interesting and educating and helps to spread the image among wider audience as well. The fact that you don't seem to have a consensus with Walter on some topic (auto-decoding, yeah) doesn't help either. Language marketing is not about posting links on reddit, it is a very hard work of communicating your vision so that it is clear even to random by-passer. I think one good thing we can do is approach things in private before discussing them publicly. Agreed. I don't propose to stop paying attention to forums or drop all discussions but to put a bit more efforts into popularizing resulting decisions and plans. So that someone can safely ignore some of discussions without fearing that it will surprisingly appear in next release catching one off guard. We now have Martin Nowak as the point of contact. And what if he gets busy too? :) Maybe you'll volunteer. I have already considered that and can be pretty sure this won't ever happen (at least not while this implies paying to Apple a single cent) Let's get it straight - I don't care much about D success in general. It is a nice language to use here and there, I got an awesome job because of it but this is pretty much all the scope. There is no way I will ever work on something that is not needed to me only because it is important for language success in general. This is pretty much the difference between language author / core developer and random contributor and why handling releases is safer in the hands of former. No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers. I don't mean feature itself was theoretical. I mean that it was implemented and released before it got at least some practical usage in live projects with relevant feedback and thus have missed some corner cases. Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment. Well when I have initially asked the same question (why not user-controllable policies?) you straight out rejected it. I must be very bad at wording questions :( Again: I don't have a complete design, that's why I'm asking for comments in the Request For Comments threads. Would you rather have me come up alone with a complete design and then show it to the community as a fait accompli? What part of let's do this together I need to clarify? let's do this together implies agreeing on some base to further work on. When I come and see that proposed solution does not address a problem I have at all I can't do anything but ask how is this supposed to address my problem? because that is _your_ proposal and I am not gifted with telepathy. Especially because you have stated that previous proposal (range-fication) which did fix the issue _for me_ is not on the table anymore. You risk balkanization by keeping the things as they are. We do have talks at work sometimes that simply forking the language may be a more practical approach than pushing necessary breaking changes upstream by the time D2 port is complete. Those are just talks of course and until porting is done it is all just speculations but it does indicate certain level of unhappinness. It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. Have you ever considered starting a blog about your vision of D development to communicate it better to wider audience? :) Yah, apparently there's no shortage of ideas of things I should work on. Perhaps I should do the same. Dicebot, I think you should work on making exceptions refcounted :o). As soon as it becomes a priority issue for me or
Re: What are the worst parts of D?
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. T -- Too many people have open minds but closed eyes.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times.
Re: What are the worst parts of D?
On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So C++ and GC is likely not to be high priority for them. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 12:00 PM, Dicebot wrote: On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times. He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 19:08:24 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:00 PM, Dicebot wrote: On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times. He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei And here we go again for the multiple alias this: I'm pleased to have seen that it will be merged sooner than later. Just to clarify, taking as an example our company: - TDPL is a very good training book for C++/Java minions, and turns them in, well, not-so-good-but-not-so-terrible D programmers. It solve the boss perplexity about there's basically no markets for D language programmers: how can we hire them in the future?. For the chronicle, the next lecture is the EXCELLENT D Templates: a tutorial, of Philippe Sigaud, an invaluable resource (thank Philippe for that!). - TDPL is exactly what Dicebot wrote: a plan! Having to bet on something, a CTO like me *likes* to bet on a good plan (like the A-Team!) - Being a good plan, and an ambitious one, as a company we scrutiny the efforts devoted to complete it, and that set the bar for future evaluation of the reliability of _future_ plans and proposal. As an example, the *not resolution* of the shared qualifier mess, has a costs in term of how reliable we judge other proposed improvements (I know, that may be not fare, but that's it). I'm not telling that the language must be crystallised, and I also understand that as times goes by, other priorities and good ideas may come up. As a company, we don't mind if we are discussing about ARC, GC, or C++ interop, but we care about the efforts and time placed on the _taken_ decision, especially for the _past_ plans, and we judge that care as strictly correlated to language maturity for business adoption. Just my 2c... again, no pun intended! ;-P --- /Paolo
Re: What are the worst parts of D?
On 2014-09-25 01:54:26 +, H. S. Teoh via Digitalmars-d said: On Wed, Sep 24, 2014 at 05:37:37PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 9/24/14, 4:48 PM, H. S. Teoh via Digitalmars-d wrote: You're misrepresenting my position.*In spite of their current flaws*, modern build systems like SCons and Tup already far exceed make in their basic capabilities and reliability. Fair enough, thanks. Anyhow the point is, to paraphrase Gandhi: Be the change you want to see in dlang's build system :o). -- Andrei Well, Cliff I (and whoever's interested) will see what we can do about that. Perhaps in the not-so-distant future we may have a D build tool that can serve as the go-to build tool for D projects. T Please submit PRs for dub, instead of creating a new project. Dub is a nice way of managing library packages already. I'd rather not use two different tools.
Re: What are the worst parts of D?
I am in the mood to complain today so this feels like a good moment to post a bit more extended reply here. There are three big issues that harm D development most in my opinion: 1) lack of vision TDPL was an absolutely awesome book because it expained why? as opposed to how?. Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. It feels like yet another random contribution, no different from contribution/idea of any other D user. Anarchy-driven development is pretty cool thing in general but only if there is a base, a long-term vision all other contributions are built upon. And I think it is primary responsibility of language authors to define such as clear as possible. It is very difficult task but it simply can't be delegated. 2) reliable release base I think this is most important part of open-source infrastructure needed to attract more contributions and something that also belongs to the core team. I understand why Walter was so eager to delegate is but right now the truth is that once Andrew has to temporarily leave all release process has immediately stalled. And finding replacement is not easy - this task is inherently ungrateful as it implies spending time and resources on stuff you personally don't need at all. Same applies to versioning - it got considerably better with introduction of minor version but it is still far from reasonable SemVer and cherry-picking approach still feels like madness. And current situation where dissapearance of one person has completely blocked and releases simply tells everyone D is still terribly immature. 3) lack of field testing Too many new features get added simply because they look theoretically sound. I think it is quite telling that most robust parts of D are the ones that got designed based on mistake experience of other languages (primarily C++) and most innovations tend to fall into collection of hacks stockpiled together (something same C++ is infamous for). I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects. This is closely related to SemVer topic. I'd love to see D3. And D4 soon after. And probably new prime version increase every year or two. This allows to tinker with really big changes without being concerned about how it will affect your code in next release. Don has been mentioning that Sociomantic is all for breaking the code for the greater good and I fully agree with him. But introducing such surprise solutions creates a huge risk of either sticking with imperfect design and patching it (what we have now) or changing same stuff back and forth every basic release (and _that_ is bad).
Re: What are the worst parts of D?
On 10/5/14, 7:55 AM, Dicebot wrote: 1) lack of vision The vision is to expand user base and make a compelling case for using D alongside existing code bases. There are two important aspects to that: interoperability with C++, and using D without a garbage collector. Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. 1. C++ support is good for attracting companies featuring large C++ codebases to get into D for new code without disruptions. 2. Auto-decoding is blown out of proportion and a distraction at this time. 3. Ref counting is necessary again for encouraging adoption. We've framed GC as an user education matter for years. We might have even been right for the most part, but it doesn't matter. Fact is that a large potential user base will simply not consider a GC language. It feels like yet another random contribution, no different from contribution/idea of any other D user. Anarchy-driven development is pretty cool thing in general but only if there is a base, a long-term vision all other contributions are built upon. And I think it is primary responsibility of language authors to define such as clear as possible. It is very difficult task but it simply can't be delegated. I'm all about vision. I do agree we've been less so in the past. 2) reliable release base I think this is most important part of open-source infrastructure needed to attract more contributions and something that also belongs to the core team. I understand why Walter was so eager to delegate is but right now the truth is that once Andrew has to temporarily leave all release process has immediately stalled. And finding replacement is not easy - this task is inherently ungrateful as it implies spending time and resources on stuff you personally don't need at all. We now have Martin Nowak as the point of contact. 3) lack of field testing Too many new features get added simply because they look theoretically sound. What would those be? I think it is quite telling that most robust parts of D are the ones that got designed based on mistake experience of other languages (primarily C++) and most innovations tend to fall into collection of hacks stockpiled together (something same C++ is infamous for). I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Policy-based design is more than one decade old, and older under other guises. Reference counting is many decades old. Both have been humongous success stories for C++. No need to trust me or anyone, but at some point decisions will be made. Most decisions don't make everybody happy. To influence them it suffices to argue your case properly. I hope you don't have the feeling appeal to authority is used to counter real arguments. I _do_ trust my authority over someone else's, especially when I'm on hook for the decision made. I won't ever say this is a disaster, but we did it because a guy on the forum said it'll work. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects. Feedback is great, thanks. But we can't test everything before actually doing anything. I know how PBD works and I know how RC works, both from having hacked with them for years. I know where this will go, and it's somewhere good. This is closely related to SemVer topic. I'd love to see D3. And D4 soon after. And probably new prime version increase every year or two. This allows to tinker with really big changes without being concerned about how it will affect your code in next release. Sorry, I'm not on board with this. I believe it does nothing than balkanize the community, and there's plenty of evidence from other languages (Perl, Python). Microsoft could afford to do it with C# only because they have lock-in with their user base, monopoly on tooling, and a simple transition story (give us more money). Don has been mentioning that Sociomantic is all for breaking the code for the greater good and I fully agree with him. But introducing such surprise solutions creates a huge risk of either sticking with imperfect design and patching it (what we have now) or changing same stuff back and forth every basic release (and _that_ is bad). I don't see what is surprising about my vision. It's simple and clear. C++ and GC. C++
