Announcement

Collapse
No announcement yet.

John Carmack's Comments On C/C++

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • John Carmack's Comments On C/C++

    Phoronix: John Carmack's Comments On C/C++

    John Carmack, the veteran game programmer that co-founded id Software and was the lead developer on the id Tech engine and their most popular game titles, has shared some new opinions on C/C++ programming as it pertains to the id Tech game engine...

    http://www.phoronix.com/vr.php?view=MTI3NDQ

  • #2
    Hmm, I never liked C++ due to its weird style. I find C to be rather primitive, but at the very least it's consistent. I always felt that C++ was some sort of a hack glued onto C, as its syntax just doesn't fit with the rest... It has some really good features, but I can't stand this inconsistency, unfortunately. Hence why I prefer D, which is both consistent and provides all the powerful options of C++ and more. And yes, I have quite a bit of appreciation for immutable variables

    Comment


    • #3
      This is why I like D. Compared to C++/C#/Java, D gets a lot of things right. There are still some issues related to the GC, but it's moving in the right direction. I prefer C++'s multi-inheritance model to D's Java/C#-like single-inheritance+interfaces model, but I guess you can't have everything ;-)

      Comment


      • #4
        Originally posted by GreatEmerald View Post
        Hmm, I never liked C++ due to its weird style. I find C to be rather primitive, but at the very least it's consistent. I always felt that C++ was some sort of a hack glued onto C, as its syntax just doesn't fit with the rest... It has some really good features, but I can't stand this inconsistency, unfortunately. Hence why I prefer D, which is both consistent and provides all the powerful options of C++ and more. And yes, I have quite a bit of appreciation for immutable variables
        I've always viewed C++ the other way around. A language that got C glued into it for the sake of compatibility.

        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. I like D templates, because they are better and easier than C++ templates, but that's it. "static if" is a great idea.

        Comment


        • #5
          Originally posted by joe_gunner View Post
          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.
          It's already stable. They are only solving bugs and doing cleanups right now, as far as I can tell.

          Comment


          • #6
            Here is a great comment from another site about how a perfect (optimally as possible) programming language would be:

            http://forums.theregister.co.uk/foru...n_c_plus_plus/
            Posted Thursday 13th December 2012 10:48 GMT
            mutatedwombat

            The best language hasn't been written yet

            It will be expressive, efficient, and have an elegant simplicity.
            People will be able to master all its features in a week,
            while being able to easily express powerful abstractions and complex data structures.

            It will neither leak memory, nor perform garbage collection at random intervals.
            It will be automatically and transparently thread safe,
            and support inter process communication and synchronisation as part of the language.

            It will be fully deterministic, so that it can be used in real time applications,
            as well as being provably correct, for safety critical uses.

            In the meantime, just pick whatever is least damaging to your sensibilities and most suited to your purposes.

            Comment


            • #7
              Such a language is impossible. You can't get people to agree on basic things, like a typed language:

              1) One says it must be strongly typed, but others don't wanna deal with types, they'd rather sacrifice some speed and let some errors trickle past the compiler.
              2) The second one says it must be weakly typed, the first group wouldn't agree.
              3) The third one says it should have both. The first two groups say it would make the language too sophisticated and bloated. Restart the circular logic from point one.

              Comment


              • #8
                Originally posted by joe_gunner View Post

                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. I like D templates, because they are better and easier than C++ templates, but that's it. "static if" is a great idea.
                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

                Comment


                • #9
                  I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
                  This tells me he finally did figure c++ out. The STL doesn't help much with const programming due to how it deals with collections, but that can be worked around and with c++11 can be rather efficient (although requiring a separate function body). C++11 and may also break the constness rule in some cases for parameter passing as well.

                  Originally I was excited about 'D' but the more I got into it the more disappointed I became with it. Especially now with c++11 D just isn't appealing to me in the least.
                  Last edited by bnolsen; 01-14-2013, 06:48 PM.

                  Comment


                  • #10
                    What exactly got you disappointed in D? Just curious.

                    Comment


                    • #11
                      Originally posted by GreatEmerald View Post
                      Hmm, I never liked C++ due to its weird style. I find C to be rather primitive, but at the very least it's consistent. I always felt that C++ was some sort of a hack glued onto C, as its syntax just doesn't fit with the rest... It has some really good features, but I can't stand this inconsistency, unfortunately. Hence why I prefer D, which is both consistent and provides all the powerful options of C++ and more. And yes, I have quite a bit of appreciation for immutable variables
                      Can you particularise what do you mean with "syntax just doesn't fit with the rest"? I'm trying to figure out what inconsistencies they may be but I can't think of anything inconsistent in C++. In my view the C++ is very (more like absolutely) consistent but that's just my view.

                      On the other hand C is lacking much functionality (starting with namespaces...) and is still exactly equally efficient as C++ when regarding performance. (Well, if you use polymorphism you have to consider VTABLEs etc. but if you want to implement something like that in C you still have to write a code that will do the same, if it's even feasible).

                      Comment


                      • #12
                        Originally posted by mark45 View Post
                        Such a language is impossible. You can't get people to agree on basic things, like a typed language:

                        1) One says it must be strongly typed, but others don't wanna deal with types, they'd rather sacrifice some speed and let some errors trickle past the compiler.
                        2) The second one says it must be weakly typed, the first group wouldn't agree.
                        3) The third one says it should have both. The first two groups say it would make the language too sophisticated and bloated. Restart the circular logic from point one.
                        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:

                        Code:
                        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:

                        Code:
                        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..

                        Comment


                        • #13
                          Originally posted by Grawp View Post
                          Can you particularise what do you mean with "syntax just doesn't fit with the rest"? I'm trying to figure out what inconsistencies they may be but I can't think of anything inconsistent in C++. In my view the C++ is very (more like absolutely) consistent but that's just my view.
                          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.

                          Comment


                          • #14
                            Originally posted by GreatEmerald View Post
                            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.
                            It's not notation, it's a bunch of function calls with your function being of the form:
                            Code:
                            std::ostream & operator<<(std::ostream &outputStream, const Type &value) {
                               // ...
                               return outputStream;
                            }
                            No trickery here.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X