On 7/2/16 11:27 PM, Walter Bright via Digitalmars-d wrote:
> Thanks for taking the time to write this. Let me see if I can help.
>

> This is true. I'm interested in which of these have caused you problems. Naturally, people in the forum are going to debate the edge cases, as they do in every language. It isn't necessary to use those edge cases to write very successful code, however.
>

A semi related experience is that I was using dlangui successfully on the Mac, and ported to a windows system I had and it worked no issues. However, then I tried to deploy to the 1/2 dozen windows setups we have and it segfaults in a different manner on each setup.  I'm sure it's related to dlls, initialization, and packaging but it makes for a difficult and unfavorable experience.  This is reproducible with the example programs distributed with dlangui (some crash, some run).  If the CI testers had covered a reasonable plethora of windows configurations/versions, this would have been identified.  (One can make the same argument about my development environment too.)

I then thought that maybe LDC would have been a better experience, but on windows, it comes with it's own case of worms...so I ran out of time before getting that to work either.

I've not had time to investigate the underlying cause, and when I do, I'll submit a bug report.  I desperately want better tools and think D has potential, I just needed them yesterday. ;)

On 07/03/2016 01:31 AM, Walter Bright via Digitalmars-d wrote:
> On 7/3/2016 12:21 AM, Charles Hixson via Digitalmars-d wrote:
>> I do wish that phobos included a D wrapper around SQLite,
>
> There was one recently announced.
Thanks.  I missed the announcement.
>
>
>> I'd also like to be able to depend on class finalizers being called.
>> Sometimes I wrap a class in a struct just so I can depend on the finalizer.
>
> That's the way to do it.
It works, but it's a bit of added friction when I'm coding. Especially if I need access to the internals of the class...then I need to manually mangle the names.  (I'm not implying I need to match the compiler's version of the name.)
>
>
>> The last time I checked DDoc stopped working after encountering an extern "C"
>> block in a file.
>
> I'm not aware of this. Is there a bug report filed?
I wasn't sure it was a bug.  And it may not still be present. Since I figured out the cause I've just put the C externals in a separate file.
>
>
>> DDoc could use considerable work in formatting. I'd like to be able to globally control the font attributes
>> of classes, structs, aliases, enums.
>
> DDoc relies on having a user-supplied xxx.ddoc file to provide the formatting, css, etc.
I wasn't able to figure out how to highlight classes differently from structs, etc.  I have built small .ddoc files to make custom changes, but that was for defining macros.
>
>
>> I'd like to be able to document private
>> routines or not depending on a (compiler) switch.
>
> I'm not sure what the point of that would be. Private functions shouldn't be called by anything outside of the file, and you already have the file open in the editor when working on it. But you can always submit an enhancement request for it on bugzilla.
That's not for export.  The documentation is written for me to use a month or more later.
>
>
>> Most of my needs are for run time flexibility rather than for more compile time
>> flexibility.  E.g., I'd like to be able to declare a statically sized array from
>> a parameter.
>
> You can do it more or less with alloca(). I know C99 has this feature, and some people swear by it, but I just don't think it pulls its weight.
Yes, I could manually allocate them.  But that adds a lot of resistance.  If they are too much effort, well, OK, but that's an example of the kind of thing that I want that D doesn't address.  No language does everything, and D is one of the two or three languages I consider best.  Python is another, but slow.  Vala shows promise, but it's not portable, and the development is glacial. Also it's poorly documented.  It's advantage is it's fast AND has a lot of wrapped libraries.  (But last I checked it seemed FAR from 1.0.)
>
>
>> I feel sort of guilty for "complaining" this way when I've been devoting all my
>> efforts to my own projects, but you did, essentially, invite comments.
>
> If something good can come from it, it's good.
My chances of getting any usable result from my work are *very* low.  OTOH, if I do the social payoff will be huge.  So I persevere.  Except when I get discouraged.

On Sunday, 3 July 2016 at 08:01:45 UTC, Ola Fosheim Grøstad wrote:
> even then a language like Whiley is more advanced.  Whiley has a floating type system with static typing where you can write

Typo, not «floating type system», but flow-typing:

https://en.wikipedia.org/wiki/Flow-sensitive_typing

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> Sorry, I've spend the last month trying my best to get simple shit done. At every turn there is some problem that has to be dealt with that is unrelated to my actual work.  Be it the IDE, debugging, the library, or user shared code, it is just crap. D cannot be used successfully for semi-large projects without significant man hours invested in getting everything to work.
>
> [...]

I do believe you are a die hard user of Visual Studio. These guys cannot leave outside their comfort zone. Ha ha.

+1 For stability though. Ha ha.

> Sometimes I idly wonder what would have happened if D were available in the 80's. Sort of like if you put a modern car for sale in the 1960's.

Sure, but that violates causality and means nothing. Instead, lets go into the future, which we can do(with our minds at least), and see what D is(can be) and then bring that in to the present(which is the future, because tomorrow becomes today).

I see D is the singular greatest language man has seen since 2025. No one even bothers writing or studying compilers any more because D is the bee's knee's. The reason people create something new is because the old isn't working for them. Let's make D work for everyone instead of the few anointed.

>
>> 20. I hope the D community can come together at some point and work towards a
>> common goal that will benefit humanity. It's a mini-cosmos of what is going on
>> in the world today. Everyone is in it for themselves and they don't realize the
>> big picture and how every little thing they do has an enormous impact on the
>> human species.  We aren't doing this stuff for fun, we do it to make a better
>> life for ourselves, which means we also have to do it for everyone else(because
>> we are all in it together).
>
> I think we do remarkably well considering that D is an effort by self-motivated enthusiasts, not by bored people working on it just because they're paid to.

Yes, but that is an excuse not to do better. It leads to laziness, lack of focus, disorganization, weakness, atrophy, and eventually death(it is the way of life).

You obviously spent nearly a life creating D. Do you want to see it die out like the dodo? D is your brain child and you gave it a great beginning, but I see it's mid life as pointing towards an untimely death. It's hard to create something great in the first place, but it takes more work to keep it their.

Have you read Christopher Alexander's `A Pattern Language`? It applies not only to architecture, computer programming, compilers, etc but life itself. I'd like to see D live because all the alternatives are substandard.

D needs leadership, specific goals, and an organizational structure. A plan of action to achieve these as soon as possible. If we were in a dessert without water, would we want to find water as soon as possible or take our time?

D's lackadaisical approach leads to lackadaisical results. There is an abundance of free labor trying to make it work, but it is inefficient and usually requires highly motivated and intelligent individuals to add to D.  Instead, how about a more efficient approach that maximizes leverage?

The top of the organization structure, the most intelligent, motivated, and dedicated create the goals and structures that will knowingly lead to the best results.

e.g.(just a simple off the cuff type of breakdown)

Goals:

The D language must be robust, capable of all the desirable behaviors that everyone expects such as intelligibility(readable), efficiency(no code duplication), coherently implementable(no piecemeal implementations), thoroughly documented, etc.

    The D compiler must be robust, efficient, cleanly implementable, stable, easily maintainable, extensible, expandable, usable, platform agnostic/independence(not the binary, the core design), etc.

        The D library must be stable, efficient, coherent, logical, nested/hierarchical, platform agnostic/independent. Support a variety of usages(Gui, Graphics, Games, Devices, core, systems, etc...)

        The D tools must be stable, effective, specific, organized, etc.

        The D IDE must be stable, effective, friendly, increase efficiency as best as possible for the user. It should work to increase the productivity on all levels of the D regime since the IDE is the portal in to the D world. Hence, it can include forum connections, bug reporting, organizational contribution interfacing, etc.

etc...

Everything must work together in a cohesive way. The only way this can happen is if it is design that way from the get go.

D has some/many of these things. But it is due to people with different ideas of the goal(since it hasn't been laid out). When the goal is understand, it is generally very easy for anyone to accomplish it. When it is not, don't expect the goal to be reached.

Once the goal has been well defined, it can be broken down into parts and each part tackled by individuals. A program could be written to help manage the complexities and make it efficient for users to help tackle. This might be difficult to do initially but will pay off in the long run. If designed properly it could be integrated or built in to the IDE. Everything should be modular as much as possible. Any changes at any point in the goals(design change) effects all changes further down the structure. As the structure becomes larger, the weaknesses show through and the ripples in the space time continuum can lead to a total collapse(humpty dumpty still exists, he's just in a lot of pieces and no one cares about him any more).


Regardless, I'm sure you know about all this type of stuff.  It's more about the drive to implement it. I personally would like to see a whole knew paradigm shift in programming. Something involving direct brain to computer interfacing... unfortunately I need D to get their.

...Anyways, don't take my complaints too harshly. I realize it's a work in progress. I'm trying to `inspire`(ok, maybe not the best word) you to grow some balls(or bigger balls) and lead the way. D is your child, it's ultimately up to you to make it grow in to the person(or, uh, the language/compiler tool set) that you desire it to be. If you can't do it on your own(too old and tired, lack of motivation, lack of time, etc) find the people you need to make it happen then let them do it and you can sit back and crack the whip every once in a while, while you sip on your latte.

The DeLorean won't build itself and someone has to make/find the flux capacitor if it's going to work.

Maybe go talk to Microsoft and see if they will fund you? Tell Trump you'll vote for him if he supports the D foundation!

On Sunday, 3 July 2016 at 21:23:56 UTC, D wrote:
> Have you read Christopher Alexander's `A Pattern Language`? It applies not only to architecture, computer programming, compilers, etc but life itself.

I hope not. It is an opinionated book on what they thought were good aspects of architecture. The roots was in the DIY movement where the general audience should be educated so they could design their own environment.

The equivalent in programming languages would be to post a disconnected list of programming language features and let people design their own programming languages based on what they like most.

If anything, D is there already.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> 10. Most user contributed D packages are outdated. They simply don't work anymore due to all the language changes.

This is the only point in the rant that I can agree with. I've been stung a few times by dub dependencies preventing me from building a project. It's nothing to do with the language itself though and I think complaining about it is completely wrong. Rather than moaning here you should be creating a bug report for whichever project you find problems with or even better contributing a fix.

I spend most of my time working with Java so have gotten used to having a huge amount free libs & tools because the eco-system around Java is huge. The D community is tiny by comparison so there's far less in that respect. That hasn't stopped me wanting to use D though, I can still see benefits to using it and I prefer it to Rust or Go.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> I'm sorry many of you have spent your lives working on something that won't amount to much in the real world.

A friend asked me yesterday if I feel any kind of fulfillment from my job, like in a religious "this is what I am meant to do" way.

I said "lol no, it is just a day job".

D is similar to me: it makes things easier for me, so I use it. Saves a lot of time which is a reward itself. If it doesn't work for you, meh, whatever.

On Sunday, 3 July 2016 at 17:55:05 UTC, Schrom, Brian T wrote:

> A semi related experience is that I was using dlangui successfully on the Mac, and ported to a windows system I had and it worked no issues. However, then I tried to deploy to the 1/2 dozen windows setups we have and it segfaults in a different manner on each setup.  I'm sure it's related to dlls, initialization, and packaging but it makes for a difficult and unfavorable experience.  This is reproducible with the example programs distributed with dlangui (some crash, some run).  If the CI testers had covered a reasonable plethora of windows configurations/versions, this would have been identified.  (One can make the same argument about my development environment too.)

So did you report an issue to the DLangUI bug tracker?

https://github.com/buggins/dlangui/issues

On Monday, 4 July 2016 at 00:17:20 UTC, Adam D. Ruppe wrote:
> D is similar to me: it makes things easier for me, so I use it. Saves a lot of time which is a reward itself. If it doesn't work for you, meh, whatever.

yep. D is just a tool. a great tool, way better than most tools in the similar group (for me, at least), but it's not something i will worship.

as any good engineer, i love my tools, they are making my life easier. but if i'll find some tool that makes one of my current tools obsolete, and makes me way more productive with less efforts (mental included ;-)... i'll switch in the blink of an eye. like i did with Basic->Pascal, Pascal->C, then C->D. and mind you, i had a huge codebases at least with Pascal and C. that didn't stopped me. it won't stop me from D->???, if anything.

still, there is something one should to consider: sometimes engineers defending their tools with what may look like a religious passion. and often it may be not that, but we just got tired of reading "your toolbox sux, fix it, switch to XYZ, blah-blah-blah", and explaining again and again that "we are fully aware about this, but we have reasons 'a', 'b', 'c', ... 'many' to use this toolbox. and we are working on making it better."

such chats may be fun first three or five times, but then you just skipping it, possibly writing short answers like: "bwah, another dumb pseudo-guru. please, get lost."

so please, people, stop acting like you are the ones who seeing the light of Ultimate Truth. we *know* your Truth for *ages*. write bug reports instead of rants! ;-)

i'm guilty of this myself (ranting and so on), so i've been on both sides. when i just came to D, i've immediately noticed alot of obvious things that should be fixed for good, and sometimes wrote about that in "hey, listen to me, i know what to do!" manner. but as time passed, i've seen many other posts similar to mines. if it was so obvious, D devs must be really dumb to not see that by theirselves, right? and if they are so dumb, i don't think that they can program at all, so D just can't exist! but D exists, so something is wrong in this logical chain. ;-)