On 11/27/17 10:01 PM, A Guy With an Opinion wrote:
Hi,
Hi Guy, welcome, and I wanted to say I was saying "me too" while reading
much of your post. I worked on a C# based client/server for about 5
years, and the biggest thing I agree with you on is the generic
programming. I was also using D at the time, and using generics felt
like eating a superbly under-baked cake.
A few points:
- Some of the errors from DMD are a little strange. I don't want to crap
on this too much, because for the most part it's fine. However
occasionally it throws errors I still can't really work out why THAT is
the error it gave me. Some of you may have saw my question in the
"Learn" forum about not knowing to use static in an embedded class, but
the error was the following:
Error: 'this' is only defined in non-static member functions
Yes, this is simply a bad error message. Many of our bad error messages
come from something called "lowering", where one piece of code is
converted to another piece of code, and then the error message happens
on the converted code. So essentially you are getting errors on code you
didn't write!
They are more difficult to fix, since we can't change the real error
message (it applies to real code as well), and the code that generated
the lowered code is decoupled from the error. I think this is one of
those cases.
I'd say the errors so far are above some of the cryptic stuff C++ can
throw at you (however, I haven't delved that deeply into D templates
yet, so don't hold me to this yet), but in terms of quality I'd put it
somewhere between C# and C++ in quality. With C# being the ideal.
Once you use templates a lot, the error messages explode in cryptology
:) But generally, you can get the gist of your errors if you can
decipher half-way the mangling.
- ...however, where are all of the collections? No Queue? No Stack? No
HashTable? I've read that it's not a big focus because some of the built
in stuff *can* behave like those things. The C# project I'm porting
utilizes queues and a specifically C#'s Dictionary<> quite a bit, so I'm
not looking forward to having to hand roll my own or use something that
aren't fundamentally them. This is definitely the biggest negative I've
come across. I want a queue, not something that *can* behave as a queue.
I definitely expected more from a language that is this old.
I haven't touched this in years, but it should still work pretty well
(if you try it and it doesn't compile for some reason, please submit an
issue there): https://github.com/schveiguy/dcollections
It has more of a Java/C# feel than other libraries, including an
interface hierarchy.
That being said, Queue is just so easy to implement given a linked list,
I never bothered :)
+ Unit tests. Finally built in unit tests. Enough said here. If the lack
of collections was the biggest negative, this is the biggest positive. I
would like to enable them at build time if possible though.
+1000
About the running of unit tests at build time, many people version their
main function like this:
version(unittest) void main() {}
else
int main(string[] args) // real declaration
{ ... }
This way, when you build with -unittest, you only run unit tests, and
exit immediately. So enabling them at build time is quite easy.
- Attributes. I had another post in the Learn forum about attributes
which was unfortunate. At first I was excited because it seems like on
the surface it would help me write better code, but it gets a little
tedious and tiresome to have to remember to decorate code with them. It
seems like most of them should have been the defaults. I would have
preferred if the compiler helped me and reminded me. I asked if there
was a way to enforce them globally, which I guess there is, but I guess
there's also not a way to turn some of them off afterwards. A bit
unfortunate. But at least I can see some solutions to this.
If you are using more templates (and I use them the more I write D
code), you will not have this problem. Templates infer almost all
attributes.
- Immutable. I'm not sure I fully understand it. On the surface it
seemed like const but transitive. I tried having a method return an
immutable value, but when I used it in my unit test I got some weird
errors about objects not being able to return immutable (I forget the
exact error...apologies). I refactored to use const, and it all worked
as I expected, but I don't get why the immutable didn't work. I was
returning a value type, so I don't see why passing in
assert(object.errorCount == 0) would have triggered errors. But it did.
This is likely because of Adam's suggestion -- you were incorrectly
declaring a function that returned an immutable like this:
immutable T foo();
Where the immutable *doesn't* apply to the return value, but to the
function itself. immutable applied to a function is really applying
immutable to the 'this' reference.
+ Templates seem powerful. I've only fiddled thus far, but I don't think
I've quite comprehended their usefulness yet. It will probably take me
some time to figure out how to wield them effectively. One thing I
accidentally stumbled upon that I liked was that I could simulate
inheritance in structs with them, by using the mixin keyword. That was
cool, and I'm not even sure if that is what they were really meant to
enable.
Templates and generative programming is what hooks you on D. You will be
spoiled when you work on other languages :)
-Steve
