On 6/6/20 5:03 PM, FunkyD wrote:> On Saturday, 6 June 2020 at 09:57:36
UTC, Jan Hönig wrote:
> D is pretty good for meta-programming. For certain other things it is
> terrible.
I am glad I don't know enough about other technologies to feel that way.
> String mixins simply mix in D code. It lets you build generic D code.
> The big problem here is debugging. There is ZERO ability to properly
> debug string mixins.
"Zero" is too strong an assertion and because of the following, false:
dmd -mixin=<filename> ...
> Well, what it boils down to is writing out the
> string mixin and then debugging that.
When I compile my program and there is an issue with a string mixin,
Emacs opens the mixin file and shows me the compilation there. This is
because dmd's error include the exact line in the <filename> where my
mixin was broken. Not a shiny IDE but still pretty awesome support.
> It would be nice if D had a special D code string that the IDE could
> interpret properly.
I must be misunderstanding you but it must be an IDE limitation because
of the following:
writeln(q{
void foo() {
}
});
My IDE gives me syntax highlighting in that string, so it works somehow.
> D basically tries to resolve things after the fact so
>
> R add(T)(T a, T b)
> {
> return a + b;
> }
>
> this will attempt to + on a and b after the types are known. If they
> can't be added then an error will occur, which is usually cryptic for
> templates.
That's why we use template constraints and in some cases 'static assert'
for custom error messages.
> The issue in using D should not be made based on it's metaprogramming.
I agree. What feature to use usually emerges by itself. For example,
when an algorithm is repeated for many types, it is an opportunity for
templates.
> D, IMO, is not capable of writing sophisticated programs...
"Sophisticated" is relative but such strong assertions can be falsified
by a single counterexample. For example, Weka's product is very
sophisticated and is written in D. And there is nothing extra or missing
in D that makes it incapable in that regard.
> this is why
> you do not see any.
I think the fact that many smart programmers are hostage to other
languages is a stronger reason.
> No one writes large commercial apps in D.
False.
> There is
> not one!
False. And again, even if so, that's not because of D, but because of
humans. Can you imagine a CTO, say, in Silicon Valley to have guts to
bring D instead of C++? With C++, the CTO will never be blamed; but D,
he or she can easily be blamed upon failure. Not because of the
technologies but because of politics.
> The D ecosystems is poorly structured compared to the top
> contenders.
Agreed but that is not because D is inferior. Again, that's because
people happen to be busy with other technologies.
> D is good for small apps, utilities, etc. D can be
> integrated with other apps though but then one loses some of the meta
> capabilities(since they won't translate).
What would one technology that is good for small code not work for a
larger system? Threads, communication e.g. memory mapped files, etc. are
all there. What magical thing would happen and suddenly D won't work
beyond a certain limit? If so, is that any different from any other
language?
Ali
