Thoughts While Reading About D

I first heard about D quite a while ago, but I never really looked into it. I stumbled upon it again today and I’m actually reading on the website right now. Some quick thoughts I wanted to jot down:

  • It’s compiled, no VM or interpreter, and supports inline assembly, pointers, etc. (could it be used in embedded systems?)
  • Doesn’t do 16-bit stuff very well (hmm, maybe not all embedded systems…)
  • No preprocessor, yay!
  • The above means, no #include, it has modules that you import.
  • Arrays know their size!
  • Arrays can be resized
  • Arrays can be associative (i.e. hash tables)
  • No forward declaration needed (from they day I learned C I’ve wondered why in the world the compiler couldn’t figure this out itself)
  • Function literals and nested functions (hence, closures). Wow.
  • Garbage collection and automatic memory allocation, but you can override it if you need to (good!)
  • Built-in synchronization
  • Direct access to C functions
  • Standard object file format

It also says it doesn’t have, “a religion, or an overriding philosophy,” yet it does seem to pick a side on the strong typing debate by advocating its better typedefs and function In and Out Parameters. It also goes on for a bit more about unit tests and “contracts” (not sure what that is even) than I figured a less philosophical language would (maybe that’s just because I’m not completely sold on those myself), saying, “if it has no unit tests and no contracts, it’s unacceptable.”

It looks promising from the marketing spiel. I’ve been secretly hoping that something a little higher-level than C++ could be used for writing firmware. Maybe D could be it. I’ll have to actually download a compiler and try it.


Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

Git Rebase Explained

'git revert' Is Not Equivalent To 'svn revert'