John Carmack's Comments On C/C++

[GreatEmerald]

Which is most practical?

How about this:

writeln("Today is January ", 15, ", ", 2013);

Or even:

printf("Today is January %d, %d\n", 15, 2013);

[nslay]

Yeap, that's what I mean. I don't see how using operators there is helping, all it does is make the code look inconsistent. Having a function that does all the stream piping for you simply makes more sense. Sure, you can use the operators for doing other things as well, but most of the time you don't need that. And the fact that it's an operator and not a function is also something I don't particularly like, especially given that it clashes with bitwise shifting operators.

I think the insertion/extraction stream operators are strangely appropriate ... maybe it's grown on me.
Here are the advantages:

• No longer need to remember type specifiers
• Can easily overload new << and >> operators for new types
• Can easily cascade them (see below)

As for cascading:

Which is most practical?

std::cout << "Today is January ," << 15 << ", " << 2013 << std::endl;

Or the equivalent

Output(Output(Output(Output(Output(std::cout, "Today is January ,"), 15), ", "), 2013), '\n');

I can't say I advocate operator overloading for most problems, but the ability to cascade them seems to warrant their use for outputting formatted text.

[stqn]

D is a niche language that's far too complex and likely never gonna get finished due to it's complexity and ever increasing number of bolt-on features.

Indeed. D v1 was good, but they just can’t stop adding stuff to D2, and now it’s even more complicated than C++.
Which is why I’m now trying Go…

[GreatEmerald]

Overall, I believe the discussion about which programming language is better and specifically spending time on discussing to which extent constants or likewise should be used or not is pointless. Most programming languages are the same and the differences are mostly, in my opinion, a question of personal preference and a lot of ego.

Not necessarily. It does come down to the developer's preferences and background, of course, but talking about it is also about giving information. Not everyone is aware of all the languages and may want to try some others out, or some might have an outdated view about one etc. So information helps.

What I actually think one of the overlooked sides of many languages is intuitivity. If you're already designing a high-level language which is meant to be used by humans, why not do it right?

Indeed. That's again one point that I like about D, it gets things done fairly intuitively. Its stdio provides writeln(), for instance - no more need to append "\n" all the time, and no more need to write substitution characters in the string, just like in Pascal, but then it also provides the more traditional functions in case you need some extra functionality. And its library is rather extensive and has structures and functions to handle things like time, CPU capabilities, regular expressions etc.

I still find it a bit odd how templates are used in D (variable.template!(type) or template!(type)(variable)), but I don't suppose there is any better way of representing those.

Having a background of UnrealScript coding, D just feels the closest thing to it. UnrealScript doesn't use the concept of pointers, for instance, and so does D if you so desire (although it's flexible and will let you use them if you want it). Both are object-oriented, both have very useful utility functions out of the box. Both use the C coding style while having Java-like high-level additions. It's just too bad that D doesn't have certain bindings in active maintenance (like Qt, DBUS, etc.), so its use is somewhat limited in that regard.

[newwen]

As I'm old school (and embedded developer) I still use C. But even with C, my coding rules ban me from using some features of the language. The thing is that C++ has many features that leave a program indecipherable, like operator overloading. Yes, it is a powerful tool, yet it is often misused and makes the code hard to understand.
Being a C programmer, I've always liked Java for it's simplicity. But then again, Java developers tend to abuse OOP paradignms just for the sake of having beautiful object model design. If I had to ask something to Java is unsafe contexts and an easier JNI, just like C# has them.
Anyway, If you write C code, you get a better glimpse of what machine code the compiler may generate.

[newwen]

Not really. The language could be fully strong-typed, but also support typeless parameters. The compiler would analyse the function, and determine the restrictions each typeless parameter required, then give compiler errors if the code tries to pass a variable which doesn't meet those restrictions. These functions would be template function, which new version being compiled out with each unique set of param types used (therefor, special restrictions would be required for key Shared Object functions). eg:

func foo(x, y:int) # 'x' is typeless, 'y' must be an int
{
    return x * y
}

func main
{
    var s = "text" # 's' is text
    var i = 0      # 'i' is an int
    var f = 0.0    # 'f' is a float

    var r = foo(s, i) # error: can't pass text as a first parameter
    var r = foo(f, i) # works: because compiler can multiply a 'int' and a 'float'
    var r = foo(i, i) # works: compiler can compile 'int' and 'int'
}

In the code above, two versions of 'foo' would be compiled out... one taking in a (float, int), and one taking in an (int, int).

As far as memory safety without garbage-collection, the language could define a distinction between a 'var' (a memory "owner" which can't be null), and a 'ref' (a memory reference, which can't "own" memory). Vars would always be deleted at the end of their scope (unless returned), or when removed from arrays, etc.. whereas References to that data would simple be set to null. example:

func main
{
    ref x : int
    ref y : num
    
    scope
    {
        var z = 0
        var w = 0.0
        
        x => z
        x = 1 # sets 'z' to 1
        
        y => w
        y = 1.0 # sets 'w' to 1.0
        
        # auto cleanup code injected here
        # In this case, the code would look like:
        # 
        #    x => null
        #    Memory.delete(z)
        #    Memory.delete(w)
        #
        # Optimization: We don't need to set 'y' to null
        # because it's not directly accessed after this scope.
        # 
        # PS. Technically, we also don't need to delete 'z' & 'w'
        # since they would be created on the stack, but I put it
        # in to illustrate what normally happens with heap vars.
    }
    
    x = 2 # error: 'x' is null
    
    var n = 2.0
    
    y => n
    y = 3.0 # sets 'n' to 3.0
    
    # auto cleanup code:
    # 
    #    Memory.delete(n)
}

There's a lot of other stuff to that, but I think it would be possible to do something like that to achieve memory safety without a GC or Ref-Counting. You'd also need a low-level 'ptr' type which wouldn't have any restrictions and require manual memory management for advanced situations, etc..

It seems you're describing Vala.

[susikala]

Overall, I believe the discussion about which programming language is better and specifically spending time on discussing to which extent constants or likewise should be used or not is pointless. Most programming languages are the same and the differences are mostly, in my opinion, a question of personal preference and a lot of ego.

What I actually think one of the overlooked sides of many languages is intuitivity. If you're already designing a high-level language which is meant to be used by humans, why not do it right? Many languages are just horribly not intuitive in really bad and broken ways and that makes them bad languages. Of course, what is intuitive to one person may be completely arbitrary to someone else and that may be the reason why some languages have made such bad decisions, but take Java for example:

Why should, when considering,
String one, two;
// User inputs two strings, both are "number"
This evolve to false?
one == two;

In which cases does it make sense to check if two String objects are the same object? In which of the countless cases where a comparison of two strings of characters is involved would you not be interested in testing for character equality? Why should I be forced to use something so ugly as one.equals(two)? That makes absolutely no sense. Of course, if you treat Strings as non-scalars, and if you define the equal operator to work the same on all objects, you could claim you're only being consistent. But is that intuitive? Would someone who learned that 5 == 5 is true ever think that the above example with the strings should evaluate to false? What is the point in deciding to hide away the arraylike/char pointer nature of a C "string" in introducing a proper String object in java, but then keeping the old garbage by forcing you to use an object method for comparison? How dumb is that?

There are similar examples in PHP for why intuitivity is so important, and why lack thereof makes a language so bad.

[Ex-Cyber]

From what I've heard, actual AAA games (which a 3-month senior project is certainly not) are so far beyond the "GC vs. manual" debate that they're practically on another planet.

[GreatEmerald]

the gc from d is not suitable for AAA games.

http://3d.benjamin-thaut.de/?p=20

That's why D has an option to turn it off.

[disgrace]

the gc from d is not suitable for AAA games.

http://3d.benjamin-thaut.de/?p=20