• olvy (76/76) Apr 09 2020 I've been learning D slowly since September, and decided to do

olvy <olvy olvy.ol> writes:

I've been learning D slowly since September, and decided to do 
this year's Advent of Code in D, as an excuse to use the language 
more.

This is also the first time I've tried Advent of Code (or any 
kind of programming puzzles or contest, really), so it took me 
some time and effort.
But I've finally managed to complete all the puzzles.

My repo is here:
https://github.com/orvly/AOC2019Dlang

It's probably not the most idiomatic D code in the world, though.

I also tried solving the earlier days' puzzles online on my 
phone, while commuting to work, so the variable names can be, uh, 
somewhat terse.  I did this with using the ideone.com which works 
great on mobile.  I wrote some general comments on the pros and 
cons of it on the readme.md in my repo.

To enable me to keep solving them on my way to work, even when I 
solved them at home I also didn't use any libraries, didn't use 
dub, and in fact used rdmd exclusively. In a real-life project I 
wouldn't do this...

At home I used VS Code with the code-d extension.

As for the D Language itself, I must say I generally enjoyed 

/ C++ development, and thus D wasn't very challenging to learn, 
but I think I prefer it from a purely aesthetic viewpoint to both 
those languages.

FWIW, here are some things I liked and things I didn't:

What I liked:
- The standard libraries IMO are awesome and had everything I 
needed (except for ready-made stack and queue).
- The documentation was very nice too.  While some areas were 
lacking, especially for some of the more obscure range/containers 
algorithms, overall I was very satisfied.  It was very nice that 
the documentation was also installed locally as well, since my 
internet connection was somewhat flaky in the recent weeks.
- UFCS invocations - That's the main thing I liked from an an 
aesthetic viewpoint. The "feel" it gave me while writing it was 
very closed to the terseness I saw in functional languages like 

readability of the code.  But now, when reading my own code from 
some months before, I *was* able to figure out which function was 
a UFCS invocation and which was a property access. I'm not sure 
this would work in a larger codebase, though.  Also, the code-d 
extension to VS Code doesn't do "go to definition" on UFCS, which 
made working somewhat cumbersome.
- Templates were awesome, much easier to write than in C++.  I 
tried writing some parts of my solutions in a bit more generic 
way, and almost always it compiled on my first try, which is more 
than I could say when writing such code with C++.
- D has very nice support for functional programming "in the 

LINQ.
- It has an awesome mix of object oriented and free functions 
allowed, although I tended to use minimal object oriented and 
preferred structs to classes.
- I liked having the GC to use when applicable.
- I liked the very fast runtime performance.
- Built-in unit testing

What I (somewhat) disliked:
- Sometimes, useless compiler error messages when making a 
mistake inside a lambda function (especially when calling the 
each() function).  It looks like the actual error is detected but 
is then thrown away.

- Lack of a stack and a queue in the standard library. Yes, 
they're easy to write using dynamic arrays but that's an extra 
step I had to take. There *are* very complete advanced data 
structures in the standard library though, so that omission is 
kind of strange.

- Bad error messages when I forgot the "!" operator when calling 
templated functions that take a function (map, filter etc).  
After about 2 weeks I got used to it and started looking for the 
missing "!" in the code, but that shouldn't be the case.
- No automatic runtime checking of integer overflow. This tripped 
me up several times in Advent of Code puzzles.  There's the 
checkedint library which enables this but it doesn't use operator 
overloading which makes its use cumbersome.
- code-d doesn't go to definition when using UFCS.