Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

An interesting talk anyway.

Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

An interesting talk anyway.

What type of memory management features would you want to add that aren't already available in C++? Their method for allowing you to go in and control the memory system seems fairly extensive to me already...

I am with you 100% about not wanting to have another language though... there really needs to be huge gains before I would consider putting my project on an island where developers had to learn a new language before contributing!

Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

An interesting talk anyway.

What type of memory management features would you want to add that aren't already available in C++? Their method for allowing you to go in and control the memory system seems fairly extensive to me already...

I am with you 100% about not wanting to have another language though... there really needs to be huge gains before I would consider putting my project on an island where developers had to learn a new language before contributing!

I don't personally see the need for any. I think we can do whatever we want with libraries. I just guess I'm trying to understand where the guy is coming from, and I can see his point that debugging and error output and so on might be improved if some of this stuff was integrated into the language. I'm just trying to be nice since he wrote Braid :)

I actually found most of his examples pretty strawman. His statement that he knew a load of professionals that would rather have:

Vec3 *p;

int count;

rather than

std::vector<Vec3> p;

makes me question the people he is working with more than question C++'s design.

I didn't even like Braid... but I'll take Vec3 *p; over stdlib any day. C is a great OLD language and C++ is just plain fugly... it's basically a corrupted old religion that says: write these meaningless words/symbols and good things will happen. A new language could be really nice. Easier to learn than a particular C++ coding style too. Fact is, every sizable project is an island.

I'm not planning to use Jon Blow's language.. it sounds too much like C++. I'm rolling my own : )

If that fails, well, there's always C++... because if you can't have everything you want, you might as well use something popular.

He places a particular emphasis on "the joy of programming", which I think is so important. Yeah, C and C++ can do all these things, but they do them in silly, unstable, outdated ways. I absolutely would jump to a new language if for no other reason than to eliminate #include and the rest of the prepocessor. It is an absolute win/win -- no more forward declarations, and compile times go way down.

I think we'll be forever trapped by compatibility with C (too much existing useful software), but we can make progress in a new direction with a language designed for the 21st century.

i think i depends on where one's productivity issues are.

for Blow, he seems to want help tracking memory errors.

for me, its all about speeding up code entry. reducing the time and effort involved for me to core dump ready to compile code from my brain to the editor.

i once started down the path of making my own language and compiler, but decided it was a lot of work.

i figured out that a macro processor that uses a shorthand syntax that translates to c++ code was the best way to go.

now i have my own custom language (Cscript), and all the power of c++, debugger, profiler, lint, compiler optimizations, etc.

being a macro processor you can freely mix c++ and Cscript commands in a single file. so you can start with legacy c++ code, and add Cscript code as you learn Cscript. and you can always fall back to c++ syntax for anything Cscript doesn't support directly. so the learning curve is very shallow.

and yes, the joy of programming with such a tool vs c++ is unbelivable.

FYI, i'm thinking of releasing Cscript to the dev community for free.