On Tuesday, 6 July 2021 at 20:53:12 UTC, Dylan Graham wrote:

• Arrays and Associative Arrays never need null checks. Their null state is equivalent to their empty state, so you can always safely insert elements or query their .length. In Java I commonly wrote null checks at the start of functions, I rarely need those in D.

• Template arguments can be any compile-time known value. Coming from Java, I was used to seeing types in angle brackets ArrayList<String> which would be ArrayList!string in D, but D also allows map!"a.x" or octal!10. It took a while to get accustomed with that idea, but it makes templates very useful for other things than type polymorphism.

• UFCS is not just syntactic sugar, but also enables certain generic code. E.g. an input range can define an enum empty, a variable bool empty;, or a function bool empty() {...}, and then you can access .empty on all of them. Other languages require parentheses for the function, or have the habit to capitalize constants ("EMPTY").

• This is not specific to D, but the Git Lens VS Code extension is really useful when working on dmd/phobos/druntime. It immediately shows whether the code you're looking at was unchanged for 8 years or recently edited as part of a bug fix, and often helps to clear up why the code was written when there are no comments.

On Wednesday, 7 July 2021 at 12:49:34 UTC, Paulo Pinto wrote:

Good to know.

On Tuesday, 6 July 2021 at 20:53:12 UTC, Dylan Graham wrote:

• Mixin templates
  At first it looked like some weird template wizard magic, but I now use them often. I've found them to be phenomenal in promoting code reuse in classes and structs. They're the backbone for the CAN bus implementation in my projects.

  mixin template canbusImpl(alias packetID) {
    enum id = packetID;
  
    static assert(id > 512 && id < 1024, "IDs must be between 512 and 1024!");
  
    void read(const ubyte[] bytes) {
      // read bytes from the array to set the values of the encapsulating struct
    }
    void write(ubyte[] bytes) {
      // convert the encapsulating struct into a byte array
    }
  }
  
  struct HeartbeatPacket {
    mixin canbusImpl!10;
  
    ubyte deviceID;
    ubyte status;
  }
  
  struct DeviceErrorPacket {
    mixin canbusImpl!11;
  
    ubyte deviceID;
    ushort code;
    short recoveryMethod;
  }
  
  if(canbus.incomingData.id == HeartbeatPacket.id) {
    HeartbeatPacket h;
    h.read(canbus.incomingData.bytes);
    writeln(h.deviceID ~ " has a heartbeat!");
  }
  

• UFCS
  At first I was nervous about using it (mostly because I didn't want to get it wrong then have to go back and debug it), but once I really delved into some examples with it I definitely appreciated the feature. I wish I had mentioned them in my article :(

• Dlang Tour
  Despite feeling more confident in D, I do sometimes come back to the tour to refamiliarise myself with certain concepts. It works well to pick things up quickly.

On Tuesday, 6 July 2021 at 20:53:12 UTC, Dylan Graham wrote:

1. Not everything needs to be at compile time. It's perfectly fine to have your regexes initialized at program startup instead of having a bunch of ctRegex which will add 2 minutes of compilation time.

2. immutable is a special case, not the common case. const should be your default go-to keyword for attributes.

3. Simpler code is better. D gives you the tool to be very elaborate in your solution. Sometimes it's necessary, often it's not.

The following are not D specific, but were learned while contributing:

4. If it's broken, it's usually faster to fix it yourself.

5. If you put in the work, no one will stand in your way.

On Tuesday, 6 July 2021 at 20:53:12 UTC, Dylan Graham wrote:

1. Actually learning how to write code.

Unfortunately in college, we were learned to "just follow orders of our higher ups", and often were discouraged from software optimization, with the claim that modern CPUs have many cores and stuff.

2. Learning that following a single programming paradigm isn't good.

Prior to D, we mainly learned Object Oriented languages, and learned that that's the end of all things. We learned that "Aspect Oriented Programming" also exist, but that's all.

When I started to write my own game engine, I did it in a strictly OOP sense, then, after it was unable to render more than one million pixels per seconds on my outdated PC, I decided to switch gears, and looked up a lot more things beyond what OOP could offer. First I've learned about Data-Oriented Design, which made me change so many things I immediately incremented the version number from 0.1 to 0.9 (biggest mistake). It was faster than before, so I looked even harder. I remembered a thing we learned, called SIMD, so I looked it up to utilize it for alpha-blending. I had to run a lot of circles with it, the initial assembly code I copied from the web had serious issues and otherwise everyone on the internet wanted to tell me the true gospel of OpenGL and shaders (which are nice and stuff, but couldn't do integer arithmetic easily, and not at all on older cards), then I needed to switch to using intel-intrinsics instead of using hard to maintain and seemingly easy to malfunction code.

Then I learned some functional programming. I think many of its evangelists are quite irritating and think it'll replace everything, but it has its own place. Nowadays I started to label my functions with const whether its possible, so I won't get the possibility of a getter function writing unintentional data. :) It might have leaded to LDC2 better optimizing stuff in my engine by parallelization, with lead to a few confusing, hard to debug issues, that were resolved by using synchronized.

While in many cases I had to give up the OOP parts, I managed to keep its modularity. However, sometimes I use function pointers or delegates instead of classes: similar kind of modularity, but often simpler. Using @nogc and nothrow helps a lot with performance, especially as I'm now forced to not allocate on the heap if possible. I'm at a point that with my knowledge and small team, I dared to begin to write a few simple software synths for it, which is quite fitting for a "retro-focused" game engine.