D is almost the exact language I need...

Charles Hixson via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 3 00:21:15 PDT 2016


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



More information about the Digitalmars-d mailing list