John Carmack's Comments On C/C++

[Grawp]

Well, even the very basic printing to console. C is consistent in that it uses a function for that, printf(). And C++ uses the "cout" notation that looks way out of place.

Well, the printing to console does not have anything to do with the language itself! You have to understand that C++ != STL and C != libc. Let me explain:
cout is actually an object and you just call operator "<<" on it. cout is not a keyword, it's just name for a struct that someone made and the "<<" operator was just simply chosen because it looks nicer than (+,-,*...). You don't have to use the STL library. It's absolutely not mandatory or recommended. (Embedded systems don't use STL, Qt doesn't use STL...)
Anyway, these operator overloading is a beautiful thing. You can do something like complexnum3 = complexnum1 + complexnum2 and you can define what + and = do. It's like automatic calling some function complexsum(c,a,b) without any overhead over ordinary function. The cout << is just like that. You can you use printf. You can write somehting new. You can even use inline assembly like in C.

[F i L]

And for the reference, here's the D version (with an additional case and that is syntactically valid):

template foo(T, O : int) 
{
    auto foo(T x, O y)
    {
    	return x * y;
    }
}

int main()
{
    string  s = "text"; // 's' is text
    auto i = 0;      // 'i' is an int
    auto f = 0.0 ;   // 'f' is a double

    auto r = foo(s, i) ;// error: can't pass text as a first parameter
    auto r2 = foo(f, i) ;// works: because compiler can multiply a 'int' and a 'float'
    auto r3 = foo(i, i) ;// works: compiler can compile 'int' and 'int'
    auto r4 = foo(i, f) ;// error: can't pass non-int as second parameter
    return 0;
}

That D code can be even prettier:

auto foo(T)(T x, int y)
{
    return x * y;
}

void main()
{
    auto s = "text"; // 's' is text
    auto i = 0;      // 'i' is an int
    auto f = 0.0 ;   // 'f' is a double

    auto r1 = foo(s, i); // error: can't pass text as a first parameter
    auto r2 = foo(f, i); // works: because compiler can multiply a 'int' and a 'float'
    auto r3 = foo(i, i); // works: compiler can compile 'int' and 'int'
    auto r4 = foo(i, f); // error: can't pass non-int as second parameter
}

[plonoma]

The choice of the word auto as a keyword for automatically determining type is an abomination in terms of expressiveness.
The word autotype should have been used.
(Auto is just too short and ambiguous. People are going to make mistakes easier.)

Also in re factoring projects where the word auto had another meaning it's now more of a problem.
You have to define an alias to know what has been re factored and what not. (Must see the difference easily remember, can't use things that rely on keywords being different.)

[plonoma]

How about this:

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

Or even:

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

Really like the first one.
Would like to do the following:

uint intvariable = 5;
setWrite(std::cout);

writeln("sghsfmhj",12," tyjumdnjmjdsgjhpg ", 2013," pesriprtu", intvariable);
write(" pegihjesj");
writeln(123);
writeln({5}133);

Would produce the following three lines of output:

sghsfmhj12 tyjumdnjmjdsgjhpg 2013 pesriprtu5
 pegihjesj123
  133

(The {} is used for format specifying but is in front or behind the object to be converted to a string.)
Also being able to do toString();
With comma separated stuff like in the example.
Also being able to do a toStringNl();
Same as the previous function but with an endline behind it.
Being able to use the << operator here:
<<("sfsgfsf ", 45," sdrghjdsgol");

(also use of {} with multiple parameters, Example: {6,"^"} Would reserve six places and have as second parameter a filler for the empty space, also multiple {} on one, cascading to form more interesting outputs)

Short, easy readable, see what you get out of it, concise, very functional and high-level.

[log0]

The choice of the word auto as a keyword for automatically determining type is an abomination in terms of expressiveness.
The word autotype should have been used.
(Auto is just too short and ambiguous. People are going to make mistakes easier.)

Also in re factoring projects where the word auto had another meaning it's now more of a problem.
You have to define an alias to know what has been re factored and what not. (Must see the difference easily remember, can't use things that rely on keywords being different.)

You mean too short and ambigous compared to short, long, double?

And if you find it too hard to substitute auto, you might be using the wrong source code editor.

[plonoma]

It's not about how hard it is to substitute auto.
It's about how easy it can be made to figure out which auto to substitute.

[movieman]

the gc from d is not suitable for AAA games.

Garbage collection is braindead. It's supposed to prevent programmers screwing up memory allocation and deallocation, but just gives them a whole new set of ways to screw up instead while sucking up performance and RAM.

And if you're using STL in C++ you probably have to write 'new' or 'delete' about once a year.

[phred14]

As I read TFA and the comments here, a slight paraphrase comes to mind... "Those who do not understand/remember classical structured programming are doomed to reinvent it - poorly."

Back in the day, I did a pile of non-trivial code in both Pascal and Modula-2. I never did a device driver, but I did do a re-entrant interrupt handler as a DOS TSR way, way back. I interfaced to C graphics libraries, (SWIG didn't exist, back then, so I wrote .defs by hand.) both read and wrote legacy binary data of multiple types.

Both languages were criticized for "not being able to do anything useful - only writing toy software," but I had quite a bit of useful code written in both. With Modula-2 another common criticism was that it didn't have a good collection of libraries. SWIG didn't exist back then, but I think it would render that issue moot, today. Both languages were also extended to become useful, and that is a valid criticism, though much less so with Modula-2 than with Pascal.

The more common criticism against both was about "programming in a strait-jacket." But here we see Carmack voluntarily donning that strait-jacket in the name of readability and, I presume, reliability, debuggability, etc. What's more, since C/C++ don't directly have the strait-jacket features, he's working hard to get that stuff back with templates. In that same light, look at the fact that we're still seeing software bugs that Pascal/Modula-2 never would have let us make. Obviously there would still be bugs, and no doubt new categories of bugs, but we're still fighting entirely too many trivial bugs, even now.

To be fair, neither Pascal nor Modula-2 were object-oriented without heavy extensions. I did do object-oriented-style programming with Modula-2, just like it can be done with C, but it's nicer when the language helps you. There is another variant called Modula-3 that is object oriented, but I haven't played with it.

Then again, there are Oberon and Oberon-2. Those were Wirth's ventures into OO. The former was more of a teaching/experimental language, like Pascal, while the latter was meant to be practical. I hung out on the Oberon-2 Usenet group for a while. One of those "simplifications" was taking away variant records and the "packed" directive, which was my Swiss-army-knife for accessing legacy binary data. I brought this up on the list, asking how the heck I was supposed to work with legacy binary data. Their answer was to get all of those legacy applications re-coded into Oberon-2. That was about the time I quite following the language.

About that time I shifted platforms to Linux, and never really picked up doing my own compiled code since, past "./config ; make ; make install". I do mostly Python these days. (and still wish for "var" and "const", so I know exactly how things are being passed)

[bnolsen]

Syntax being easy to read, expressive and flexible seems like it's the most important thing.
(I notice that with the << it's easier to read, produces smaller code and is (less error prone?) shorter than printf.)
(The use of the %s, %d specifiers has an issue since the type specification seems to conflict with the DRY principle of software engineering. )

Ugh.. iostreams is the absolute worst part of the whole standard c++ libraries. It's slow, full of thread locks (due to locale being attached to the binary streambuf base class), bad design with "<<" (horrible for translation grammar).

I'm not a huge fan of "auto" except in very limited cases. It looks like a vehicle for generating unmaintainable/unreadable code. Someone looking at this stuff dry has not idea what datatypes are contained in those variables. I'll limit "auto" for use with those ugly iterator declarations, thank you.

[joe_gunner]

D is far easier to read and write than C++.
At beginning the language had some important bug that is the normal workflow for anything in informatic. Now the language is stable and for new code is better to start with D. Try it now

I don't think it's easier to read, templates yes, the rest no. Much of the recent code ive seen recently seems to have diverged from C syntax which to me is the most readable.