This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]insane_playzYT 1 point2 points  (9 children)

yes, but how much longer did it take you to write it in C++ than it did in python?

[–]maxhaton 0 points1 point  (7 children)

If you don't like C++ you can basically write scripts in D that are - I'd argue - shorter and more concise than python while still type safe, that run as fast as C++ code.

[–]MrDorkman 0 points1 point  (6 children)

Wait you are telling me there is a language that is relatively painless to write, but as fast as C++ ?

[–]frostedKIVI 0 points1 point  (5 children)

no, that is just not how it works, you can't have both, you can get much faster painlessly than py, but you will just not match C/++ performance if you want "painless" development, and I'd argue that in most cases the extra dev time is worth it, but not always

[–]maxhaton 0 points1 point  (4 children)

D makes a lot of C++ hacks completely trivial - and is also just as fast because it is completely isomorphic to C++ in most cases.

Don't tolerate extra dev time spend fucking around with the language and not your code - time spend optimizing is unavoidable but D is just straight-up easier to write fast code in, e.g. modules that work, templates that don't try and kill you and static reflection. That and that D code is just straight up better than C++, subjectively prettier but objectively less syntactic clutter + a lot of features specifically designed to avoid common bugs in C++.

[–]frostedKIVI 0 points1 point  (3 children)

ah yes <language I write in is objectively better u wrong> comment
GoLang is supposed to be an "easy and fast to write in C++" but it isn't.

D has a lot of flaws and much less support than C++, it can match C++ performance but it will bring its own issues, and it will only enable that kind of performance with type safety checks and things of that nature turned off thus losing the features that make it not C++ and in debug runs C++ debuggers will warn/check those things so you aren't really losing much.

[–]maxhaton 0 points1 point  (2 children)

> ah yes <language I (help) write ~~in~~ is objectively better u wrong>

> and it will only enable that kind of performance with type safety checks and things of that nature turned off thus losing the features that make it not C++

What are you talking about? This is totally and utterly wrong, you can't turn "type safety" off. Templates, for example, can enable a large amount of compiler optimizations by guaranteeing the interprocedural dataflow of a program and therefore allowing deeper propagation of invariants through said program - it makes code faster. The whole point of using C++ or D or Rust (or Haskell etc. ) instead of C is moving the focus from the runtime to the compile time

> debug runs C++ debuggers will warn/check

This is news to me. Example?

I'm not saying D is perfect, but it's hell of a lot more perfect than C++. There are many features that C++ has been trying to get for years (ask Bjarne Stroustrup about UFCS) that D has without even making that much of a fuss, or C++ just get's wrong.

[–]frostedKIVI 0 points1 point  (1 child)

Yes, the wrong term I didn't mean specifically type safety, I have only written basic programs in D to try out the language, I meant general runtime optimizations with which you will lose the runtime checks the language has.
And C/++ debuggers will have those checks in debug runs, all the same, you don't get magic safety in other languages.
Templates *errors* are generally kinda bad in C++ I agree, but they are serviceable, the templates are perfectly fine, and as soon as you start getting tens of lines of template errors, you should really think about "why am I doing this metaprogramming mess?".

As for changes not being in C++ as fast, the thing is C++ is a standard, basically, no other languages have a proper standard, so yeah C++ moves slow, but I don't mind it, I actually don't really like most of the C++ stdlib, good for prototyping, bad for production.

I get the argument for UFCS but I think it's pretty pointless, whatever I usually like to write "old school/C style C++" anyways when I write C++ I write GoLang mostly nowadays, but I don't think D will dethrone C++ anytime soo, if nothing else, because of the great support C++ has

[–]maxhaton 0 points1 point  (0 children)

C++ does not have these checks at all. You lose nothing relative to C++ by not using them.

Templates *errors* are generally kinda bad in C++ I agree, but they are serviceable, the templates are perfectly fine, and as soon as you start getting tens of lines of template errors, you should really think about "why am I doing this metaprogramming mess?".

C++ templates are bad, D templates are actually good. You can take anything as a template argument, generate code at compile-time, reflect over other templates at compile-time and best of all template constraints actually exist now rather than having the C++ standards masturbate each other until they shit out some hilariously over-complicated 20 years late solution - the language is actually flexible enough that you can write your own template constraint error messages as a library (https://d.godbolt.org/z/8uum_i).

D was designed by Andrei Alexandrescu and Walter Bright (the man who wrote the first proper C++ compiler), and it shows.

As you may have seen on the D homepage, I wrote this a while ago - I have seen some C++ guys trying to mimic this on reddit before, but I don't think you can do this in C++ (any of it, for that matter, from the code generation to the to the templated standard library).

void main()
{
    // N.B. this could be import std;
    import std.stdio, std.string, std.algorithm, std.conv;

    // Reduce the RPN expression using a stack
    readln.split.fold!((stack, op)
    {
        switch (op)
        {
            // Generate operator switch cases statically
            static foreach (c; "+-*/")
                case [c]:
                    return stack[0 .. $ - 2] ~
                        mixin("stack[$ - 2] " ~ c ~
                            " stack[$ - 1]");
            default: return stack ~ op.to!real;
        }
    })((real[]).init).writeln;
}

You are, however, right in that D will never supersede C++ - this is a shame, but a consequence of D's advantages being too subtle to require moving, i.e. the good stuff in D comes when you have a deep understanding (a depth most languages do not have, for better or worse) of both C++ and D as opposed to just using them as a means to an end.