Hello everyone! This is my first post in these forums.
D is an interesting language (basically a saner C++, which is a nice prospect because I've used C++ working in the game industry in the past) and I've been considering using it and may still do so.
However, there is a very basic debugging feature that I've always thought all programming languages should have (because it is so useful and yet also trivial to implement and inherently harmless) but which a surprisingly large number of languages don't support:
Specifically, I want a way to create a print command that behaves like @show
from Julia lang or dump
from (if my memory is correct) Nim.
Basically, I want there to be a way to print both an expression and its value but to only have to write the expression once (which also aids refactoring). Such a feature is extremely useful for faster print-based debugging.
Thus, instead of having to write something like this:
writeln("1 + 2 == ", 1 + 2);
I want to just be able to write this:
show!(1 + 2)
... and here is the closest I've been able to get in D, after roughly a dozen attempts:
import std.stdio;
void show(alias expr)()
{
writeln(expr.stringof, " == ", expr);
//https://ddili.org/ders/d.en/templates_more.html
//says that `alias` allows "any expression" but in
//reality the expression gets evaluated and hence
//information about what it really was is lost.
}
void main()
{
show!(1 + 2);
//I want this to print "1 + 2 == 3",
//but instead it prints "3 == 3"
const x = 1 + 2;
show!(x);
//This at least prints "x == 3" though.
}
See the comments in the above code for info on what it does versus what I want it to do.
Usually I prefer assert
whenever I actually know what the values of something are, but there are many cases where I don't know what the values are and want to see easily.
This feature is a great litmus test for how expressive a language actually is. Indeed, it is one of the best simple litmus tests for programming language design that I've found. It is trivial yet speaks volumes of the thought that has gone into the design of any language.
Even $5 solar-powered desktop calculators often leave the expression of what you write still visible after you've computed it, yet many programming languages don't even provide a way of eliminating this extremely common form of redundancy and require duplicated typing in strings repeatedly.
One would think that more programming languages would account for this when you consider that much of the whole purpose of programming languages is enabling the user to get computed values evaluated and displayed as easily and pragmatically as possible... yet so many languages can't even do the above despite it being one of the most obvious ergonomic factors one could ever have for anything that is used for computation. That is why the absence of it in any language annoys me so much. The lack of it is an absurdity, essentially, if you think about it from first principles and user experience.
On the other hand, I am aware that macros make control flow harder to follow, but to counter that: String-generating macros that aid debugging are an inherently harmless subset of macros. They only make it easier to debug and display diagnostics. There's nothing about the show
macro (or similar passive-information constructs) conceptually that harms comprehensibility of code.
I've for years thought it would be nice to have a language that lacks the more extreme macros but still has the ability to implement things like the show
macro.
Is D such a language? Is there any way to implement what I want (as above)?
The frustration with trying to get this working makes me consider just using Nim instead, which has extremely flexible macros and can do this easily.
I personally believe that all languages should have this, even if they have to make a one-time exception to allow just the show
macro but not other macros.
Why should merely displaying the correspondence between expressions and their outputs be hard or impossible in so many languages? Think about it. It is bizarre that it is so often absent.
If D can't do this currently then I suggest that it be made to be capable of it. This kind of macro is not like other macros. Debugging and diagnostic pragmatism doesn't confound program logic, unlike how esoteric macros often do.
Anyway, thank you for reading and sorry for my verbosity. This is one of my biggest pet peeves regarding programming language design.