On Sunday, 7 June 2020 at 00:45:37 UTC, Ali Çehreli wrote:
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.
Ok, that isn't my fault.
> 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:
You know the difference between logic and statistics? Ever heard
of measure theory?
It's a pretty poor argument to claim that "Oh, logically it is
not 100% true so it can't be true at all". I'm fine with stating
something as All if it's true 98%+ of the time when it doesn't
matter if it's 90% or 100% or anything in between.
If, for example, you had cancer almost all over your body I don't
think someone you fault you if you said all instead of almost
all. Pedanticism usually isn't a feature but a fault.
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.
Syntax highlighting is entirely different from semantic analysis.
Try getting a line number of an error a multi-line string...
> 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.
Yeah, that is definitely not the way to go... I could just throw
rocks at my computer until it works too. Just because one can do
it doesn't mean one should. In this case one is nearly forced.
Claiming that because we have the most primitive form of a
solution makes up for having a good solution is pretty primitive.
> 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.
As you said, sophisticated is quite relative. It seems you seem
to think this is a math pissing contest. Anyone that makes a
decision based on logical facts rather than statistical facts for
statistical problems is quite illogical.
> 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.
Maybe, maybe not... sounds like an excuse. Maybe they are
actually rational beings who understanding that moving to an
unpredictable and rather incompletely language is not worth the
trouble?
> No one writes large commercial apps in D.
False.
Prove it. Saying something is false is not the same as it being
false. Since you want to play hardball:
Name one commercial D app that has over 1 million in revenue and
is used by 10k people. Just one. I'll let you play your games.
Here I'm talking about an actual app that is entirely written in
D. You cannot claim an app is written in D when it just imports
some D library. Nor are we talking about ad revenue generating
software. I'm talking about something normal people use as an
application... like a word processor, painting app, web browser,
etc. Something external users use, not a internal to a company.
Just one, come on, you said it was easy!
> 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.
Now you are claiming that they don't exist. Which is it? Do they
exist or do they not exist and they don't exist for some ad hoc
theories you have?
> 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.
No, that is PRECISELY because D is inferior. You like to move the
goal posts so you can get the 10 yard 3 pointer when ever you
like.
> 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?
It's called dependencies and cohesion. It's the same reason why
free energy doesn't scale up. Do you believe in free energy? I
saw a guy run a toaster off the heat of his balls after rough sex
with an expensive hooker... maybe we can use this technology to
provide all the energy to the planet for 10M years with just one
case? After all, it's just a scale problem. Right? Not just a
scale problem but surely it must be linear... you know, y = mx +
b?
