August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Radu | On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:
> On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:
>> [...]
>
> Yeah right... I'm sure this is what everyone experienced.
>
> This thread has become the trollers trolling playground.
no, i used to use d1 a lot and then d2 changed everything with it promise. but it turned into skript like monster, that doesn't work very well with tons of features. d2 is unreliable, doesn't install correct, dll problem .....
no company i ever worked at, used linux. they all use vs with windows. they want to make money and not go for the experiments of some compiler freaks.
it is important that you can have a quality experience on windows with vs, be able to use dll's and have a stable compiler with predictable use; if possible be able not to use the gc, but the gc wouldn't even be hanger.
well, you are correct, i have a different opinion and experience with d2 - so i must be a troll.
anyway, radu, i wish you good luck on a larger commercial program on windows with d2.
over and out.
|
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Radu | On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote: > On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote: >> [...] > > Yeah right... I'm sure this is what everyone experienced. > > This thread has become the trollers trolling playground. Radu, when i started using this forum, one of the first questions i asked How do you used D? https://forum.dlang.org/thread/vyrjquwvwohapjnlmvvv@forum.dlang.org And the majority replied that they are using it for personal and hobby projects Who is really trolling who? |
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali | On Sunday, 26 August 2018 at 20:21:07 UTC, Ali wrote:
> On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:
>> On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:
>>> [...]
>>
>> Yeah right... I'm sure this is what everyone experienced.
>>
>> This thread has become the trollers trolling playground.
>
> Radu, when i started using this forum, one of the first questions i asked
>
> How do you used D?
> https://forum.dlang.org/thread/vyrjquwvwohapjnlmvvv@forum.dlang.org
>
> And the majority replied that they are using it for personal and hobby projects
>
> Who is really trolling who?
The experience described by OP makes one question why the hell this language still exists and still has users.
Plus that I found it extremely offensive to the people working to make Dlang better.
On your little divergent line. Not everyone answers forum polls and not everyone working on commercial projects wants or can comment on them.
I hope that at least 10% percent of the energy spent on venting on the forums can be spent on bug reports, PRs and some donations.
|
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 8/26/2018 12:34 PM, Manu wrote:
> I work at a company with a thousand engineers, all VS users, D could
> find home there if some rough edges were polished, but they
> *absolutely must be polished* before it would be taken seriously.
> It is consistently expressed that poor VS integration is an absolute
> non-starter.
I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
|
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On 8/26/2018 8:43 AM, Chris wrote: > I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do? It's not silently abandoned. It will break just about every D program out there. I have a hard time with the idea that breakage of old code is inexcusable, so let's break every old program? > But what for was it introduced at all and why wasn't it thought through properly right from the start? Because nobody thought about that issue before. A lot of things only become apparent in hindsight. |
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 26 August 2018 at 20:55:04 UTC, Walter Bright wrote: > On 8/26/2018 12:34 PM, Manu wrote: >> I work at a company with a thousand engineers, all VS users, D could >> find home there if some rough edges were polished, but they >> *absolutely must be polished* before it would be taken seriously. >> It is consistently expressed that poor VS integration is an absolute >> non-starter. > > I will tiresomely ask again, do you have a list of each and every aspect of the poor integration? Not to put words in his mouth, but: * rvalue references: see recent DIP * https://github.com/ldc-developers/ldc/issues/2800 Really a DMD issue * https://issues.dlang.org/show_bug.cgi?id=19179 probably more. |
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 8/26/2018 1:55 PM, Walter Bright wrote:
> I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
I know you don't like filing bug reports. I'll make it easy for you.
Every time someone you work with says:
"I can't use D because ..."
"I'm abandoning D because ..."
"D sux because ..."
Just append a note of it to a text file. It doesn't matter what the reason is, any information is valuable, including:
"... because Walter killed and ate my dog"
"... because my apartment contract stipulates no pets, no smokers, no D programming"
"... because I can't take D jokes anymore"
"... because Walter won't stop droning on with his boring Boeing anecdotes"
Now and then, just email me the file.
|
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
> On 8/26/2018 8:43 AM, Chris wrote:
>> I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do?
>
> It's not silently abandoned. It will break just about every D program out there. I have a hard time with the idea that breakage of old code is inexcusable, so let's break every old program?
>
Can I just throw in here that I like autodecoding and I think it's good?
If you want ranges that iterate over bytes, then just use arrays of bytes. If you want Latin1 text, use Latin1 strings. If you want Unicode, you get Unicode iteration. This seems right and proper to me. Hell I'd love if the language was *more* aggressive about validating casts to strings.
|
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sun, 26 Aug 2018 at 14:00, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 8/26/2018 12:34 PM, Manu wrote: > > I work at a company with a thousand engineers, all VS users, D could find home there if some rough edges were polished, but they *absolutely must be polished* before it would be taken seriously. It is consistently expressed that poor VS integration is an absolute non-starter. > > I will tiresomely ask again, do you have a list of each and every aspect of the poor integration? Tooling specifically? Just to be clear, when I say "poor VS integration is an absolute non-starter", I'm not necessarily saying that's where we are... I'm just saying that's a fact. Where I think we are today is at MVP, which is a hard fought victory in itself. I think we've reached the point with VS integration that people won't question it and reject it on the spot... but we have entered a place where people feel that it's lacking quality compared to the tooling they're used to. Debug experience is worlds better than it's been, by contrast it's very usable today, and you'll notice I haven't been complaining about it... but it's still imperfect. You should try using VisualD to debug DMD some time. You'll quickly discover edge cases trying to evaluate all the relevant state while stepping around. C++ RTTI is a problem (can't identify derived type in debugger), globals are a problem, TLS is a problem. The minor edge cases emerge frequently enough that they convey a sense of immaturity. I'll start taking note everything I encounter a minor debugging issue. One specific issue I frequently encounter is with scope closure. I'd really like to see the line of the closing '}' being emit as the line where all destructors are called. The workflow in C++ for example: - Place breakpoint on the line of the closing '}' for a scope. - Debugger stops at that line prior to execution of scope closing destructors, you can use step-in and enter the destructors that are scheduled to call at the end of scope. - It's very awkward to break and step through destruction paths without being able to place such breakpoints at end-of-scope. - Developers expect this, and are surprised when it "doesn't work". I added a bugzilla for this issue 6 or 7 years ago... but I can't find it. We could really use robust tools to produce a matching C++ .h file from the extern symbols in a D module, and likewise a .di file from a C/C++ header. This category of tooling has many existing instances, it's overwhelming. As far as I can tell, they're all experimental, or broken, or designed only to target a specific application (DMD), etc. I think it would be an advantage if there were *one* tool, that works, in both directions, which is advertised, recommended, and maintained by the core group. I've evaluated them all before at various points in time, but the landscape keeps shifting. Someone, please give me a prominent hyperlink to the solution that *works*, and instructions. I don't have energy to re-do comprehensive evaluations on this front, I'm spent. Agree on one, make it the official one, and then track bugs against it in bugzilla? FWIW, my recent flurry of extern(C++) related PR's on DMD are only made possible by the current state of the VS tooling. There is no way I would have taken the time to do that work if the VS tooling wasn't where it is. Those PR's are a direct result of VS tooling reaching relative maturity; they would not have happened if the VS project didn't just load and the debugger just worked. The bar for tooling is very high, and we VS developers are quite precious, and soft ;) VisualD: Installer needs to be signed alongside DMD installer. Autocomplete/Intellisense is very unreliable. I don't think it has clear visibility through enough meta constructs. Today's solutions appear ad-hoc, I suspect they could receive a lot more assistance from DMD. Go-to definition must _always_ work. Syntax highlighting only performs a fraction of what VisualAssist does. Colleagues that have been experimenting with D consistently complain that they feel colour blind. Find-all-references locate all symbol references in a project Refactoring tools (rename symbol throughout project, etc) Suggest and cleanup spurious imports (like C# tooling) Rainer has done amazing work; he's tirelessly helpful, but it feels unfair to dump this whole load onto him. I'm not sure who or how to make these things a priority for development. A robust 'intellisense' solution (MS nomenclature) in the form of a library would help everyone. It should support: * Comprehensive syntax highlighting which is *correct*, not just best-guess * Auto-complete; when I press '.' what are all valid identifiers, and no spurious entries that aren't. Current tooling misses heaps of stuff, and also tends to pollute the list with a lot of junk. * Go-to definition (ie, locate symbol) must reliably work * Refactor tools; eg, rename identifier throughout code * Suggest imports when calling functions that aren't in scope * Cleanup spurious imports People learn to lean on their tooling very heavily, and they'll feel a strong sense of loss. This puts a further burden on 'D the language' to be _that much better_ to compensate for any such sense of loss in tooling. The last few experiences I list are imperfect in C++, D can theoretically (and should) do a much better job, since scoping and language structure is better, and there's no text includes and macros. One great opportunity for my current project is that we're asking C# programmers to use C++. They *hate* C++ even more than C++ programmers. This is actually a really interesting opportunity to show them how they can write native code and not have to hate C++... but C# sets the bar for tooling very high. If we were able to respond with similarly quality tooling, we'd have a horde of C# programmers insisting we prefer D to C++ ;) There's more things than that though.. I'll dump a list of things that are on the front of my mind recently. Language: There's the namespace thing and the ref DIP. Please just add support for a non-scoped string namespace beside the existing solution. We know I can't reason this with you... just... please do it for all of us that actually use it. I'll buy you a beer. Andrei's copy-ctor, and the move-ctor DIP would be super-welcome conclusions. Copy-construction is a problem. There's a set of languages issues in this space that Andrei knows well, and they're very important. I'm finding that 'const' is a practical problem. I don't know what to do. - Conventional wisdom; "don't use const in D", doesn't work when interacting with C++, which uses const successfully and aggressively. - I use a head-const hack, which is a shim that wraps pointers and forcefully casts-away const (technically undefined behaviour; in practice, it works) - C++ people lose their mind when they see this. It would be possible to pacify them with demonstration that D's const is superior, but I don't know how to produce that evidence. - I used to buy into D's const philosophy, but I've come to conclude that C++ got it right. Radical solutions should not be off the table... ARC? What ever happened to the opAddRef/opDecRef proposal? Was it rejected? Is it canned, or is it just back on the bench? (GC is absolutely off the table for my project, I have no influence on this) On DMD: My project is 100% DLL based. DLL's must work flawlessly. For STL interaction (which I'm concluding now): - This ABI crash is blocking me: https://issues.dlang.org/show_bug.cgi?id=19179 - We need a version to detect which CRT was selected at compile time so we can emit matching data structures in our code. - MS .obj files have _ITERATOR_DEBUG_LEVEL definition emit to the object file. I think we need a pragma to emit such tokens to the object. I would make the STL modules emit the _ITERATOR_DEBUG_LEVEL as the code was generated using said pragma. - https://issues.dlang.org/show_bug.cgi?id=18999 For this project, I would ban GC, perhaps attempt using -betterC. I have little practical experience here... but reports are often unhappy. I'll find out I guess. This issue: https://issues.dlang.org/show_bug.cgi?id=18896 Less important: This emerged again recently: https://issues.dlang.org/show_bug.cgi?id=18906 Workarounds for this are problematic: https://issues.dlang.org/show_bug.cgi?id=18845 I wasn't able to conclude some mangling issues during my recent effort, they interacted awkwardly with the build/test scripts, and DMC: * https://issues.dlang.org/show_bug.cgi?id=18997 * https://issues.dlang.org/show_bug.cgi?id=18958 I don't think this is exhaustive... but they're at close reach. |
August 26, 2018 Re: Dicebot on leaving D: It is anarchy driven development in all its glory. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nicholas Wilson | On Sun, 26 Aug 2018 at 15:55, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 August 2018 at 20:55:04 UTC, Walter Bright wrote:
> > On 8/26/2018 12:34 PM, Manu wrote:
> >> I work at a company with a thousand engineers, all VS users, D
> >> could
> >> find home there if some rough edges were polished, but they
> >> *absolutely must be polished* before it would be taken
> >> seriously.
> >> It is consistently expressed that poor VS integration is an
> >> absolute
> >> non-starter.
> >
> > I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
>
> Not to put words in his mouth, but:
> * rvalue references: see recent DIP
> * https://github.com/ldc-developers/ldc/issues/2800 Really a DMD
> issue
> * https://issues.dlang.org/show_bug.cgi?id=19179
>
> probably more.
I feel like the question was about tooling specifically... but yes, all of those! ;)
|
Copyright © 1999-2021 by the D Language Foundation