First Impressions!

[Steven Schveighoffer]

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