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'm sorry but it seems too much focus on enhancements while there are too many bugs and lack of tools to actually do anything useful.

I'm sorry if this hurts some of you guys feelings but it is fact that D sucks as a whole. A modern programming language should be modern, and D is not one of those languages. It is built as from cobbling together disparate parts that don't work together. The more it is used and added on to the worse it gets.

I'm sorry many of you have spent your lives working on something that won't amount to much in the real world. It was a valiant effort. Maybe it will seed new languages that will actually work and have the tooling to be useful. D itself is not a practical tool for general real world software development. I suppose it is obvious considering there is no significant use of it except by the diehards.

I hope I am wrong, but facts are facts. I would like to list these facts so potential users can be informed before the embark on a likely dead end.


1. The language is not completely well defined. While the language itself contains many nice features and what makes D appealing, too many features are cobbled together and don't completely work 100% properly. This creates very subtle bugs or problem areas that can stop one in their tracks. One can see how these things are cobbled together by observing the forms and the discussions about how to proceed in certain areas.

2. The compilation process is riddled with meaningless error messages and a simple missing ';' can launch one off to the moon to figure out it is missing. The error messages can cascade. Fix the ';' and 20 messages disappear. Usually each message is 100 characters+ when it involves templates.

Rather than just telling you what is grammatically missing, like any normal modern compiler does, you have to hunt and peck and fill your head with meaningless information.

3. The compilers are designed as if they come straight out of the 70's.  The setup is obscure, relies on assumptions that are not true, and just like the compilation process, if your unlucky you could be working for a few days just to try to get dmd to compile.

4. Object code issues, again, stuff from the 70's are still present.  Rather than fix the shit outright, knowing they are problematic, the can is kicked down the road to the unsuspecting users. The users, who generally know less about what is going on than the people who design the software. Those people who can fix the problem directly and save a lot of grief for people don't because they feel it isn't a big deal and they have more important things to do.

5. The documentation is somewhat crappy. While it is extensive and auto generated it generally is only a "template" of what a real user needs. Rather than just the function declaration, usually with nondescript template names like R, S, U, etc about half the functions are missing use cases. I realize this takes work but it could be done by the people writing the code, again, they know best, right?

6. The library is meandering in its design. Feels very convoluted at times, cobbled together rather than designed properly from the get go. Updated language features creates a cascade of library modifications. "Lets move this to this and remove that and then add this... oh, but we gotta update the docs, we'll do that tomorrow...".

7. The library uses shit for names. Ok, so strip isn't too bad but why not trim? That's what every one else uses. Ok, what about chomp? munch? squeeze? What the fuck is going on? Did the perverted Cookie Monster write this shit?
What about the infamous tr? Yeah, just cause posix said it was ok then it must
be so. I'd say we call it t instead.

I could go on and on about stuff like this but I have more important things to do, like

8. Lets use vim or emacs. I liked the 70's it was great. So great that I want to continue using the same editors because we know them well and they work... and their free!  I like coding at the pace of a turtle with minimal information because that's hard core leet style and makes my balls bigger, which my wife likes.

Oh, what about visual studio? Don't get me started! Maybe if Visual D/Mago actually worked half the time and didn't slow me down I'd use that. Xmarian? Worse!

Maybe it's time to get out of the dark ages and actually design a program that is designed for creating programs? Not just a fucking text editor that has a few helpful things that programs might use. Do we still have to code in text files? How about we just write everything in binary? Ok, sorry... getting OT.

Basically there is no great IDE for D, in fact, there is none. They are all general purpose IDE's that have been configured to compile D code. Great! Except they don't work well because they wern't designed for D. (e.g., template debugging? mixins? Error messages? Code maps? refactoring? All the stuff that more modern languages and IDE's are using is lacking for D.

9. What I do like about D is that it can compile for various platforms rather easy. Usually I do something like -m64 and run the app then it crashes. I don't know why because their was no error message. The point is that while D can "compile" for various platforms it is always an "on going process".

Because 9/10 D programmers program in linux, windows support is minimal and buggy. Since I don't use linux, because windows has a much larger market share, maybe D is great on linux. On windows though, it's a literal pain in the ass. All the time I spend trying to figure out how to get things to work properly has given me hemorrhoids. God did not design Man's ass to sit in front of a computer all day. BTW, a program can't just "work", I have clients that have a certain level of expectation, like no seg faults. Just because it works for me, or for you is not good enough. It has to work for everyone.

10. Most user contributed D packages are outdated. They simply don't work anymore due to all the language changes. Instead of culling the crap, it persists and the user has to wade through it all. It's every man for himself when it comes to D.

11. D has no proper Gui. WTF?  This isn't the 70's no matter how much you to relive peace and sex. Oh, did I hear someone say bindings? WTF?

12. D has no proper logging system. I just don't want to log a message, I want a well designed and easily manageable way to understand problems my program is experiencing. Given that D has so many latent issues, it's nice to have some way to deal with the "Big foot"(But bug that you only see when when your driving down a windy dark road in Nebraska).

13. Windows interfacing. Thanks for the bindings! The most used OS in the would with the largest commercial share only gets bindings that is actually like programming in win32. Rather than at least wrap them in a working oop design that hides away the abacus feel, we are stuck with bindings. The D community loves bindings, I have no fucking clue why. It just means more work. At least if I didn't have the bindings I wouldn't have to implement anything.

14. Gaming? It can be done, not by me or you but by geniuses who live in their basement and no one to support or nothing else to do but hash out how to get it done. But while they might share their results, don't get your hopes up and expect it to work for you.

15. Cross platform design? Maybe, Supposedly it works but I have too much trouble with windows to care about adding another layer of crap on top.

16. The community. While not worse than most others, doesn't really give a shit about the real world programmer. The elite are too busy thinking of ways to add the latest and greatest feature, thinking it will attract more buyers. The rabble rousers like myself don't actually do much. Ultimately things get done but nothing useful happens. Kinda like those jackasses that floor it with their foot on the break. A lot of smoke but pointless. D's been going how long? 10+ years?

The majority of you guys here don't realize that the average programming can't waste time creating a gui, implementing a design for the bindings you created, patching together different packages that don't work together, etc.

While there are, I'm sure, a lot of good intentions, they are meaningless when it comes to putting food on the table.  If you are going to do something, do it with gusto, not half ass. If you are going to design a package, do it right! Not something that continually requires fixing and effects every person that uses it exponentially. Every minute I spend fixing someone else's shit takes a minute away from my life. For N-1 other users that's N minutes wasted because the original creator didn't take the extra minute. Thanks for wasting all of our time. That's a factor of N. Now when we have to do that for M packages, that's M*N's people shit we have to fix. All because one person didn't want to spend one extra minute fixing their own shit. Ok, so, it might not be exponentially but it's still time that could be better spent on more important things.



17 ...


18. As you can see, I've ran out of steam. My butt hurts and I have better things to do... like delete dmd from my computer. At least that's simple and works! (I hope, maybe it will seg fault on me or I have to run some special command line switch).


19. PS. Ok, so, D isn't as terrible as I'm making it out. It's free. And as they say, you get what you pay for ;)

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).

Their is so much wasted time and life by so many people for so many useless reasons that we could have built a bridge, brick by brick, to moon and back, a dozen fold.  Humanity is an amazing species capable of unimaginable things. By extension, so is the D community. I just hope D doesn't end up like the Kardashians as it has so much more use for humanity.

00. Please get your shit together! I mean that in the best possible way!

Here is what I'm going to say and people will probably just reiterate it.

1) Report problems. Can't be fixed if we don't know it.
2) We're working on it. No really, I get it, you want to have a GUI toolkit yesterday but I don't think you understand just how expensive it is dependency wise. Its not like we only have one platform to worry about, Windows is the easiest platform of all to target here.
3) What did I said about working on it? No really, I do mean it. Adam D Ruppe is working on a replacement docs generation system[0] which is significantly better then what we currently have.
4) No one here is paid. It is truly amazing that D can do what it does do. We do our best with what we have, even if it means we must look long term instead of short term.

[0] http://dpldocs.info/experimental-docs/std.string.html

Thanks for taking the time to write this. Let me see if I can help.

On 7/2/2016 9:37 PM, D is crap wrote:
> 1. The language is not completely well defined. While the language itself
> contains many nice features and what makes D appealing, too many features are
> cobbled together and don't completely work 100% properly. This creates very
> subtle bugs or problem areas that can stop one in their tracks. One can see how
> these things are cobbled together by observing the forms and the discussions
> about how to proceed in certain areas.

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.


> 2. The compilation process is riddled with meaningless error messages and a
> simple missing ';' can launch one off to the moon to figure out it is missing.
> The error messages can cascade. Fix the ';' and 20 messages disappear.

I agree this is true for the syntax checker, but also I'm not aware of any compiler that has successfully dealt with this problem other than simply stopping after the first message.

The semantic pass is much better at having one and only one error message per actual error.

> Usually each message is 100 characters+ when it involves templates.

Again, you are right, but this is a consequence of templates being complex. The compiler tries to emit all the relevant context to enable the user to figure out the right fix.


> Rather than just telling you what is grammatically missing, like any normal
> modern compiler does, you have to hunt and peck and fill your head with
> meaningless information.

Most of the error messages out of the syntax checker are of the form "xxx expected", so if you could present an example of a bad error message I'd appreciate it so it can be improved.


> 3. The compilers are designed as if they come straight out of the 70's.  The
> setup is obscure, relies on assumptions that are not true, and just like the
> compilation process, if your unlucky you could be working for a few days just to
> try to get dmd to compile.

I'd like to help, but I need more specific information.


> 4. Object code issues, again, stuff from the 70's are still present.  Rather
> than fix the shit outright, knowing they are problematic, the can is kicked down
> the road to the unsuspecting users. The users, who generally know less about
> what is going on than the people who design the software. Those people who can
> fix the problem directly and save a lot of grief for people don't because they
> feel it isn't a big deal and they have more important things to do.

I don't understand the issue here. On Windows, it generates the Microsoft COFF object file, the same as Microsoft VC++. On the Mac, it generates Mach-O object files, the same as the Apple compilers do. On Linux/FreeBSD, it generates ELF object files, the same as gcc/clang do.

The linkers, debuggers, librarians, and other object code tools used are all the standard ones on those systems.

The D tools are designed to fit right in with the usual command line ecosystem on the particular host system, and to be immediately comfortable for those used to those systems.


> 5. The documentation is somewhat crappy. While it is extensive and auto
> generated it generally is only a "template" of what a real user needs. Rather
> than just the function declaration, usually with nondescript template names like
> R, S, U, etc about half the functions are missing use cases.

You're correct about that, and I've ranted about it often enough. If you have a specific function that has caused you particular grief, please let us know!


> 6. The library is meandering in its design. Feels very convoluted at times,
> cobbled together rather than designed properly from the get go. Updated language
> features creates a cascade of library modifications. "Lets move this to this and
> remove that and then add this... oh, but we gotta update the docs, we'll do that
> tomorrow...".

The good news is that no release is done unless the library works with it.


> 7. The library uses shit for names. Ok, so strip isn't too bad but why not trim?
> That's what every one else uses. Ok, what about chomp? munch? squeeze? What the
> fuck is going on? Did the perverted Cookie Monster write this shit?
> What about the infamous tr? Yeah, just cause posix said it was ok then it must
> be so. I'd say we call it t instead.

strip, chomp, squeeze, tr all come from existing functions in Python, Ruby and Javascript's standard libraries.


> Basically there is no great IDE for D, in fact, there is none. They are all
> general purpose IDE's that have been configured to compile D code. Great! Except
> they don't work well because they wern't designed for D. (e.g., template
> debugging? mixins? Error messages? Code maps? refactoring? All the stuff that
> more modern languages and IDE's are using is lacking for D.

You're right, there is no modern IDE for D. It's not an easy thing to deal with, however. Doing one is a major project.


> 9. What I do like about D is that it can compile for various platforms rather
> easy. Usually I do something like -m64 and run the app then it crashes. I don't
> know why because their was no error message. The point is that while D can
> "compile" for various platforms it is always an "on going process".

If the program is compiled with -g and it crashes (seg faults) you'll usually at least get a stack trace. Running it under a debugger will get you much more information.


> Because 9/10 D programmers program in linux, windows support is minimal and
> buggy. Since I don't use linux, because windows has a much larger market share,
> maybe D is great on linux. On windows though, it's a literal pain in the ass.

I actually develop dmd primarily on Windows. I'd like some specifics on how dmd for Windows is an inferior experience. One thing that the D tools and libraries are very good at is smoothly handling the differences in the file systems (case, \, /, line endings, etc.), far better than most cross-platform tools. I'm looking at you, git, for a rotten Windows experience :-)


> 10. Most user contributed D packages are outdated. They simply don't work
> anymore due to all the language changes. Instead of culling the crap, it
> persists and the user has to wade through it all. It's every man for himself
> when it comes to D.

There's been discussion of automating DUB so that it will mark packages that no longer build. I don't know what the state of that is.


> 11. D has no proper Gui. WTF?  This isn't the 70's no matter how much you to
> relive peace and sex. Oh, did I hear someone say bindings? WTF?

Many people have embarked down that road over the years, and all have failed. The problems are:
1. which GUI? nobody agrees on that
2. any GUI is simply an enormous amount of work. The realization of this is when the GUI projects fail

Bindings are the best we can do for now.


> 12. D has no proper logging system. I just don't want to log a message, I want a
> well designed and easily manageable way to understand problems my program is
> experiencing.

There was an std.logger proposed, but I don't know the state of it.


> 13. Windows interfacing. Thanks for the bindings! The most used OS in the would
> with the largest commercial share only gets bindings that is actually like
> programming in win32. Rather than at least wrap them in a working oop design
> that hides away the abacus feel, we are stuck with bindings.

Pretty much the same issue as the GUI library.


> 14. Gaming? It can be done, not by me or you but by geniuses who live in their
> basement and no one to support or nothing else to do but hash out how to get it
> done. But while they might share their results, don't get your hopes up and
> expect it to work for you.

Games are hard, any way you look at it.


> 15. Cross platform design? Maybe, Supposedly it works but I have too much
> trouble with windows to care about adding another layer of crap on top.

One thing Phobos does well is work smoothly across the supported platforms.


> 16. The community. While not worse than most others, doesn't really give a shit
> about the real world programmer. The elite are too busy thinking of ways to add
> the latest and greatest feature, thinking it will attract more buyers. The
> rabble rousers like myself don't actually do much. Ultimately things get done
> but nothing useful happens. Kinda like those jackasses that floor it with their
> foot on the break. A lot of smoke but pointless. D's been going how long? 10+
> years?

While a good point, on the other hand every language in wide use is relentlessly adopting new features (C++ just announced C++17 with quite a boatload of new stuff). It's just the way of things, otherwise we'd be stuck with a language from the 70's :-)


> 19. PS. Ok, so, D isn't as terrible as I'm making it out. It's free. And as they
> say, you get what you pay for ;)

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.


> 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.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> Basically there is no great IDE for D, in fact, there is none. They are all general purpose IDE's that have been configured to compile D code. Great! Except they don't work well because they wern't designed for D. (e.g., template debugging? mixins? Error messages? Code maps? refactoring? All the stuff that more modern languages and IDE's are using is lacking for D.
>
> 11. D has no proper Gui. WTF?  This isn't the 70's no matter how much you to relive peace and sex. Oh, did I hear someone say bindings? WTF?

I am working on a GUI framework and IDE for Dlang for a year.


BTW. There is still DlangUI

small summary of the starting post: "i am an idiot, and i can't use D. of course, you all guilty of my idiocity."

On Sunday, 3 July 2016 at 06:42:23 UTC, ketmar wrote:
> small summary of the starting post: "i am an idiot, and i can't use D. of course, you all guilty of my idiocity."

No, it is the result of beta-quality.  You see the same reaction in other languages/frameworks when they claim to be near-production ready while not having a stable state.

Here's the core problem:

1. Define a stable set of functionality.
2. Implement it.
3. Improve on it for 3-10 years without changing the functionality.
4. Obtain extensive tooling.

Developers generally underestimate how much work it is to bring something from stable to what is commonly expected from production quality tooling.

D is pretty much somewhere between (1) and (2), will most likely not reach (3) and is far away from (4).

In C++ it is somewhat different, C/old C++ is at (4), C++11 is at (3), C++14 is at (2/3), C++17 is at (1).

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.
>
> [...]

Bait

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.

Say what? I have used it for multiple big projects of my own ranging from 40000-100000 lines of code?

Neither have I ever had issues with IDE's or debugging.
I rarely uses other people's code, so can't comment on the quality of that.

However with your biased points I'm sure it's just empty rants anyway.

>
> I'm sorry but it seems too much focus on enhancements while there are too many bugs and lack of tools to actually do anything useful.
>

What bugs? What lack of tools?

"Oh look there is a bug, help" Well report the bug so it can be fixed moron.

"There is no tools" Tell what tools you need or start making them yourself.


> I'm sorry if this hurts some of you guys feelings but it is fact that D sucks as a whole. A modern programming language should be modern, and D is not one of those languages. It is built as from cobbling together disparate parts that don't work together. The more it is used and added on to the worse it gets.
>

You clearly don't follow the forum posts, D's future visions or any sort of discussions regard D's state and Phobos.


> I'm sorry many of you have spent your lives working on something that won't amount to much in the real world. It was a valiant effort. Maybe it will seed new languages that will actually work and have the tooling to be useful. D itself is not a practical tool for general real world software development. I suppose it is obvious considering there is no significant use of it except by the diehards.
>

I use it in the real world. I don't know what real world you live in, but okay?

If you're too incomprehent to use it, then so be it.

> I hope I am wrong, but facts are facts. I would like to list these facts so potential users can be informed before the embark on a likely dead end.
>

Biased opinions are not facts.

>
> 1. The language is not completely well defined. While the language itself contains many nice features and what makes D appealing, too many features are cobbled together and don't completely work 100% properly. This creates very subtle bugs or problem areas that can stop one in their tracks. One can see how these things are cobbled together by observing the forms and the discussions about how to proceed in certain areas.
>

I agree with some of this, but it's slowly becoming better.
It's a damage that takes a while to repair, but it's happening.
That's something that may come with open-source projects like this where different people, with different intentions and vissions starts working on it, without some specific guide-line (That however has been made by this point, hence why it isn't so much related anymore.)

> 2. The compilation process is riddled with meaningless error messages and a simple missing ';' can launch one off to the moon to figure out it is missing. The error messages can cascade. Fix the ';' and 20 messages disappear. Usually each message is 100 characters+ when it involves templates.
>
> Rather than just telling you what is grammatically missing, like any normal modern compiler does, you have to hunt and peck and fill your head with meaningless information.
>

Any of such examples? Otherwise this doesn't help anything.

> 3. The compilers are designed as if they come straight out of the 70's.  The setup is obscure, relies on assumptions that are not true, and just like the compilation process, if your unlucky you could be working for a few days just to try to get dmd to compile.
>

How is the setup obscure? It's a single installation, what?

I believe the issue is on your end if you spend a long time to get DMD working.

That MUST be your configurations. I have installed it on multiple machines and it has worked in first go.

> 4. Object code issues, again, stuff from the 70's are still present.  Rather than fix the shit outright, knowing they are problematic, the can is kicked down the road to the unsuspecting users. The users, who generally know less about what is going on than the people who design the software. Those people who can fix the problem directly and save a lot of grief for people don't because they feel it isn't a big deal and they have more important things to do.
>

Any examples? Else this one can be blown away too.

> 5. The documentation is somewhat crappy. While it is extensive and auto generated it generally is only a "template" of what a real user needs. Rather than just the function declaration, usually with nondescript template names like R, S, U, etc about half the functions are missing use cases. I realize this takes work but it could be done by the people writing the code, again, they know best, right?
>

Well if the documentation is crappy, go ahead and document it yourself.
It's open-source and usually documentation happens voluntary and not because someone is paid to write some formal description of the entire library.

> 6. The library is meandering in its design. Feels very convoluted at times, cobbled together rather than designed properly from the get go. Updated language features creates a cascade of library modifications. "Lets move this to this and remove that and then add this... oh, but we gotta update the docs, we'll do that tomorrow...".
>

I believe the documentations are now updated according to the source?
I could be wrong.

> 7. The library uses shit for names. Ok, so strip isn't too bad but why not trim? That's what every one else uses. Ok, what about chomp? munch? squeeze? What the fuck is going on? Did the perverted Cookie Monster write this shit?
> What about the infamous tr? Yeah, just cause posix said it was ok then it must
> be so. I'd say we call it t instead.
>

Again a biased opinion. Strip sounds better in my opnion.

> I could go on and on about stuff like this but I have more important things to do, like
>

Okay, but nobody cares.

> 8. Lets use vim or emacs. I liked the 70's it was great. So great that I want to continue using the same editors because we know them well and they work... and their free!  I like coding at the pace of a turtle with minimal information because that's hard core leet style and makes my balls bigger, which my wife likes.
>

I use Atom, what's your point with old editors?

> Oh, what about visual studio? Don't get me started! Maybe if Visual D/Mago actually worked half the time and didn't slow me down I'd use that. Xmarian? Worse!
>

I have had zero problems with Visual D and if you have one, why not report it instead of crying like a little girl?

> Maybe it's time to get out of the dark ages and actually design a program that is designed for creating programs? Not just a fucking text editor that has a few helpful things that programs might use. Do we still have to code in text files? How about we just write everything in binary? Ok, sorry... getting OT.
>

Go buy a crying cookie.

> Basically there is no great IDE for D, in fact, there is none. They are all general purpose IDE's that have been configured to compile D code. Great! Except they don't work well because they wern't designed for D. (e.g., template debugging? mixins? Error messages? Code maps? refactoring? All the stuff that more modern languages and IDE's are using is lacking for D.
>

What? https://wiki.dlang.org/IDEs

> 9. What I do like about D is that it can compile for various platforms rather easy. Usually I do something like -m64 and run the app then it crashes. I don't know why because their was no error message. The point is that while D can "compile" for various platforms it is always an "on going process".
>

You can specify compiler flags to get debug informtion, you can attempt to catch the error or you can attach a debugger.

How hard can it be?

> Because 9/10 D programmers program in linux, windows support is minimal and buggy. Since I don't use linux, because windows has a much larger market share, maybe D is great on linux. On windows though, it's a literal pain in the ass. All the time I spend trying to figure out how to get things to work properly has given me hemorrhoids. God did not design Man's ass to sit in front of a computer all day. BTW, a program can't just "work", I have clients that have a certain level of expectation, like no seg faults. Just because it works for me, or for you is not good enough. It has to work for everyone.
>

I program on Windows and Windows only. I have never had a single issue because of that and I have been programming D for roughly 4 years now, pretty much every day.

> 10. Most user contributed D packages are outdated. They simply don't work anymore due to all the language changes. Instead of culling the crap, it persists and the user has to wade through it all. It's every man for himself when it comes to D.
>

Well, instead of crying. Fix them and make them work again. Nobody is obligated to keep their projects up to date.

> 11. D has no proper Gui. WTF?  This isn't the 70's no matter how much you to relive peace and sex. Oh, did I hear someone say bindings? WTF?
>

Uhmm Dlang UI?

> 12. D has no proper logging system. I just don't want to log a message, I want a well designed and easily manageable way to understand problems my program is experiencing. Given that D has so many latent issues, it's nice to have some way to deal with the "Big foot"(But bug that you only see when when your driving down a windy dark road in Nebraska).
>

Say what? https://dlang.org/phobos/std_experimental_logger.html

There's also profiling logs, code coverage logs etc. that can be specified with compiler flags.

> 13. Windows interfacing. Thanks for the bindings! The most used OS in the would with the largest commercial share only gets bindings that is actually like programming in win32. Rather than at least wrap them in a working oop design that hides away the abacus feel, we are stuck with bindings. The D community loves bindings, I have no fucking clue why. It just means more work. At least if I didn't have the bindings I wouldn't have to implement anything.
>

If you're missing win api calls simply add them yourself and do a pull request or stop crying.

I believe there was an open-source project that had bindings to most win api calls though.

But again D is open-source and mostly worked on voluntary, so if something is missing add it.

Most people don't go adding a billion features that may or may not be used. They usually add something because they need it.

> 14. Gaming? It can be done, not by me or you but by geniuses who live in their basement and no one to support or nothing else to do but hash out how to get it done. But while they might share their results, don't get your hopes up and expect it to work for you.
>

What are you talking about?

> 15. Cross platform design? Maybe, Supposedly it works but I have too much trouble with windows to care about adding another layer of crap on top.
>

You have too much trouble with yourself. Go cry me a river, because you sound too incompetent to achieve anything even if it worked for you.

> 16. The community. While not worse than most others, doesn't really give a shit about the real world programmer. The elite are too busy thinking of ways to add the latest and greatest feature, thinking it will attract more buyers. The rabble rousers like myself don't actually do much. Ultimately things get done but nothing useful happens. Kinda like those jackasses that floor it with their foot on the break. A lot of smoke but pointless. D's been going how long? 10+ years?
>

Such a biased opinion, but how do you expect people to treat you when you're just acting like an ass?

I have never had any issues with people in the D community, in fact I have felt pretty welcomed and generally most people around here are nice.

> The majority of you guys here don't realize that the average programming can't waste time creating a gui, implementing a design for the bindings you created, patching together different packages that don't work together, etc.
>

I work 8+ hours every day, not working with D. I believe that I understand.

D is open-source and people work on it when they have time.

If you have a problem with that, then D is not the language for you.

> While there are, I'm sure, a lot of good intentions, they are meaningless when it comes to putting food on the table.  If you are going to do something, do it with gusto, not half ass. If you are going to design a package, do it right! Not something that continually requires fixing and effects every person that uses it exponentially. Every minute I spend fixing someone else's shit takes a minute away from my life. For N-1 other users that's N minutes wasted because the original creator didn't take the extra minute. Thanks for wasting all of our time. That's a factor of N. Now when we have to do that for M packages, that's M*N's people shit we have to fix. All because one person didn't want to spend one extra minute fixing their own shit. Ok, so, it might not be exponentially but it's still time that could be better spent on more important things.
>
>
>
> 17 ...
>

Blah...

>
> 18. As you can see, I've ran out of steam. My butt hurts and I have better things to do... like delete dmd from my computer. At least that's simple and works! (I hope, maybe it will seg fault on me or I have to run some special command line switch).
>

Well please don't come again.

>
> 19. PS. Ok, so, D isn't as terrible as I'm making it out. It's free. And as they say, you get what you pay for ;)
>

Most programming languages are free, the hell how does that make any sense?

D's quality is pretty good. Just because you're too idiotic to understand its semantics, doesn't mean its quality is bad.

> 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).
>
> Their is so much wasted time and life by so many people for so many useless reasons that we could have built a bridge, brick by brick, to moon and back, a dozen fold.  Humanity is an amazing species capable of unimaginable things. By extension, so is the D community. I just hope D doesn't end up like the Kardashians as it has so much more use for humanity.
>
> 00. Please get your shit together! I mean that in the best possible way!

The Kardashians? Really...

FWIW, I feel that the elaboration of the template language doesn't serve me well.  That's my use case, so I try to ignore it as much as possible, but phobos has been re-written to be much less intelligible to me.  I'm sure that many people find the inclusion of ranges into everything useful, but it rarely helps me.

I really like the way D handles unicode.  D and Vala are the two languages that seem to handle it well, and Vala isn't portable. And I really like having garbage collection, and especially the syntax that it enables.  I was just considering a hash table (associative array) in C++, and realized that I had to either allocate on the heap, or I couldn't easily do an increment of a struct variable.  (Well, I'm thinking about QHash, because walking the files of a directory path in standard C++ is unpleasant, and Qt makes both that and unicode tests [the ones I need to do] pretty simple.)  But if I allocate structs on the heap I have to make sure that everything gets released when I'm through, so I need to use an enhanced pointer construct, so....  It's a lot simpler in D.

I do wish that phobos included a D wrapper around SQLite, something object oriented.  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.

The last time I checked DDoc stopped working after encountering an extern "C" block in a file.  This is not desirable, even though one can work around it by moving all the extern routines to another 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.  I'd like to be able to document private routines or not depending on a (compiler) switch.  I frequently end up declaring things to be protected rather than private just so I can generate documentation.

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.  I do appreciate D's speed, but complex templates aren't something I ever use.   (Truth is, I was pretty well satisfied with D1, though perhaps I'm forgetting some limitations, but even then I'm pretty much sure that I felt the main limitation was a lack of well interfaced libraries.)

Too many of D's libraries seem to try to re-invent the wheel. When a library is working well and has been debugged, the best think if to create a wrapper around it.  The wrapper *does* need to adapt the library to the syntax of the language, but that's not a huge problem.  A major part of Python's success is "batteries included".

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.

On 07/02/2016 11:23 PM, Walter Bright via Digitalmars-d wrote:
> Thanks for taking the time to write this. Let me see if I can help.
>
> On 7/2/2016 9:37 PM, D is crap wrote:
>> 1. The language is not completely well defined. While the language itself
>> contains many nice features and what makes D appealing, too many features are
>> cobbled together and don't completely work 100% properly. This creates very
>> subtle bugs or problem areas that can stop one in their tracks. One can see how
>> these things are cobbled together by observing the forms and the discussions
>> about how to proceed in certain areas.
>
> 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.
>
>
>> 2. The compilation process is riddled with meaningless error messages and a
>> simple missing ';' can launch one off to the moon to figure out it is missing.
>> The error messages can cascade. Fix the ';' and 20 messages disappear.
>
> I agree this is true for the syntax checker, but also I'm not aware of any compiler that has successfully dealt with this problem other than simply stopping after the first message.
>
> The semantic pass is much better at having one and only one error message per actual error.
>
>> Usually each message is 100 characters+ when it involves templates.
>
> Again, you are right, but this is a consequence of templates being complex. The compiler tries to emit all the relevant context to enable the user to figure out the right fix.
>
>
>> Rather than just telling you what is grammatically missing, like any normal
>> modern compiler does, you have to hunt and peck and fill your head with
>> meaningless information.
>
> Most of the error messages out of the syntax checker are of the form "xxx expected", so if you could present an example of a bad error message I'd appreciate it so it can be improved.
>
>
>> 3. The compilers are designed as if they come straight out of the 70's.  The
>> setup is obscure, relies on assumptions that are not true, and just like the
>> compilation process, if your unlucky you could be working for a few days just to
>> try to get dmd to compile.
>
> I'd like to help, but I need more specific information.
>
>
>> 4. Object code issues, again, stuff from the 70's are still present.  Rather
>> than fix the shit outright, knowing they are problematic, the can is kicked down
>> the road to the unsuspecting users. The users, who generally know less about
>> what is going on than the people who design the software. Those people who can
>> fix the problem directly and save a lot of grief for people don't because they
>> feel it isn't a big deal and they have more important things to do.
>
> I don't understand the issue here. On Windows, it generates the Microsoft COFF object file, the same as Microsoft VC++. On the Mac, it generates Mach-O object files, the same as the Apple compilers do. On Linux/FreeBSD, it generates ELF object files, the same as gcc/clang do.
>
> The linkers, debuggers, librarians, and other object code tools used are all the standard ones on those systems.
>
> The D tools are designed to fit right in with the usual command line ecosystem on the particular host system, and to be immediately comfortable for those used to those systems.
>
>
>> 5. The documentation is somewhat crappy. While it is extensive and auto
>> generated it generally is only a "template" of what a real user needs. Rather
>> than just the function declaration, usually with nondescript template names like
>> R, S, U, etc about half the functions are missing use cases.
>
> You're correct about that, and I've ranted about it often enough. If you have a specific function that has caused you particular grief, please let us know!
>
>
>> 6. The library is meandering in its design. Feels very convoluted at times,
>> cobbled together rather than designed properly from the get go. Updated language
>> features creates a cascade of library modifications. "Lets move this to this and
>> remove that and then add this... oh, but we gotta update the docs, we'll do that
>> tomorrow...".
>
> The good news is that no release is done unless the library works with it.
>
>
>> 7. The library uses shit for names. Ok, so strip isn't too bad but why not trim?
>> That's what every one else uses. Ok, what about chomp? munch? squeeze? What the
>> fuck is going on? Did the perverted Cookie Monster write this shit?
>> What about the infamous tr? Yeah, just cause posix said it was ok then it must
>> be so. I'd say we call it t instead.
>
> strip, chomp, squeeze, tr all come from existing functions in Python, Ruby and Javascript's standard libraries.
>
>
>> Basically there is no great IDE for D, in fact, there is none. They are all
>> general purpose IDE's that have been configured to compile D code. Great! Except
>> they don't work well because they wern't designed for D. (e.g., template
>> debugging? mixins? Error messages? Code maps? refactoring? All the stuff that
>> more modern languages and IDE's are using is lacking for D.
>
> You're right, there is no modern IDE for D. It's not an easy thing to deal with, however. Doing one is a major project.
>
>
>> 9. What I do like about D is that it can compile for various platforms rather
>> easy. Usually I do something like -m64 and run the app then it crashes. I don't
>> know why because their was no error message. The point is that while D can
>> "compile" for various platforms it is always an "on going process".
>
> If the program is compiled with -g and it crashes (seg faults) you'll usually at least get a stack trace. Running it under a debugger will get you much more information.
>
>
>> Because 9/10 D programmers program in linux, windows support is minimal and
>> buggy. Since I don't use linux, because windows has a much larger market share,
>> maybe D is great on linux. On windows though, it's a literal pain in the ass.
>
> I actually develop dmd primarily on Windows. I'd like some specifics on how dmd for Windows is an inferior experience. One thing that the D tools and libraries are very good at is smoothly handling the differences in the file systems (case, \, /, line endings, etc.), far better than most cross-platform tools. I'm looking at you, git, for a rotten Windows experience :-)
>
>
>> 10. Most user contributed D packages are outdated. They simply don't work
>> anymore due to all the language changes. Instead of culling the crap, it
>> persists and the user has to wade through it all. It's every man for himself
>> when it comes to D.
>
> There's been discussion of automating DUB so that it will mark packages that no longer build. I don't know what the state of that is.
>
>
>> 11. D has no proper Gui. WTF?  This isn't the 70's no matter how much you to
>> relive peace and sex. Oh, did I hear someone say bindings? WTF?
>
> Many people have embarked down that road over the years, and all have failed. The problems are:
> 1. which GUI? nobody agrees on that
> 2. any GUI is simply an enormous amount of work. The realization of this is when the GUI projects fail
>
> Bindings are the best we can do for now.
>
>
>> 12. D has no proper logging system. I just don't want to log a message, I want a
>> well designed and easily manageable way to understand problems my program is
>> experiencing.
>
> There was an std.logger proposed, but I don't know the state of it.
>
>
>> 13. Windows interfacing. Thanks for the bindings! The most used OS in the would
>> with the largest commercial share only gets bindings that is actually like
>> programming in win32. Rather than at least wrap them in a working oop design
>> that hides away the abacus feel, we are stuck with bindings.
>
> Pretty much the same issue as the GUI library.
>
>
>> 14. Gaming? It can be done, not by me or you but by geniuses who live in their
>> basement and no one to support or nothing else to do but hash out how to get it
>> done. But while they might share their results, don't get your hopes up and
>> expect it to work for you.
>
> Games are hard, any way you look at it.
>
>
>> 15. Cross platform design? Maybe, Supposedly it works but I have too much
>> trouble with windows to care about adding another layer of crap on top.
>
> One thing Phobos does well is work smoothly across the supported platforms.
>
>
>> 16. The community. While not worse than most others, doesn't really give a shit
>> about the real world programmer. The elite are too busy thinking of ways to add
>> the latest and greatest feature, thinking it will attract more buyers. The
>> rabble rousers like myself don't actually do much. Ultimately things get done
>> but nothing useful happens. Kinda like those jackasses that floor it with their
>> foot on the break. A lot of smoke but pointless. D's been going how long? 10+
>> years?
>
> While a good point, on the other hand every language in wide use is relentlessly adopting new features (C++ just announced C++17 with quite a boatload of new stuff). It's just the way of things, otherwise we'd be stuck with a language from the 70's :-)
>
>
>> 19. PS. Ok, so, D isn't as terrible as I'm making it out. It's free. And as they
>> say, you get what you pay for ;)
>
> 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.
>
>
>> 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.
>
>

On Sunday, 3 July 2016 at 07:04:58 UTC, Ola Fosheim Grøstad wrote:
> 3. Improve on it for 3-10 years without changing the functionality.

if i want to use "stable language", i know where to download C89 compiler.