D is crap

Sat Jul 2 23:23:05 PDT 2016

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.