Announcement

Collapse
No announcement yet.

GCC 5 Is Compiling Faster, But Still Falls Short Of Clang

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

  • #61
    Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.

    Comment


    • #62
      Originally posted by curaga View Post
      Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.
      I haven't used Go in anger. I only played with D, but so far I like it a lot.

      Comment


      • #63
        Originally posted by -MacNuke- View Post
        So GCC is useless for development... But really... GCC is not THAT much faster than clang. Just a litte if you compile for one CPU...
        I don't deny. I am aware Clang/LLVM has some advantages over GCC.

        Comment


        • #64
          Originally posted by curaga View Post
          Go certainly compiles fast, but that evens out in developer convenience because writing it is a PITA. Imagine writing C++ where the compiler would only let it build if you used the GNU indent style.
          Go doesn't care about the indent style. You may be thinking about some of the requirements it has because it doesn't use semicolons to end statements. It does need to know where the line ends and for that it requires that braces, commas, quotes, etc, be in the correct positions. This is no different than Python, but unlike Python you can indent however you want and use tabs or spaces in any combination.

          Go does have an official indent style and if you run "go fmt" it will rewrite your code into the official style. I appreciate this because it ends forever any arguments about where to put the braces and how many spaces code should have. Just run "go fmt" and the argument is over.

          Comment


          • #65
            I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

            Incidentally, that is also why I hate Python.

            Comment


            • #66
              Originally posted by curaga View Post
              I count "where to put the brace" as part of indent style, though maybe I should have said "GNU coding style" instead. Any language where the FAQ and interviews clearly show the designers' attitude to be "because fuck you, that's why" is a bad language. Compare with Stroustrup: "I felt I don't have the right to force my views on the developers". That right there is a huge, huge difference.

              Incidentally, that is also why I hate Python.
              I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

              Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

              Forcing one convention in a development language might be limiting for each individual but it's better for the community.

              Comment


              • #67
                Originally posted by Michael_S View Post
                I completely disagree. The awesome thing about Python's syntax rules is that it makes reading almost anybody's Python a simple thing to do.

                Look at Perl and C++. Both are awesome languages. Both have tons of features. Both can do an incredible amount of things. Both can be written in clean, clear, easy-to-read ways. But to work professionally with Perl or C++, you have to be prepared to deal with outrageous abuses of Perl's implicit variables and syntax quirks and insane uses of the C++ preprocessor and a hundred other combinations of bizarre code.

                Forcing one convention in a development language might be limiting for each individual but it's better for the community.
                you can force your views on your project or organization. language has nothing to do with it.

                Comment


                • #68
                  Originally posted by pal666 View Post
                  you can force your views on your project or organization. language has nothing to do with it.
                  Someone can force their views on their project or organization. They can't force their views on the entire ecosystem. That's fine when you write your entire stack in-house, but as soon as you pull in third party code you still have a problem.

                  With Go and Python, you can grab open source code from anywhere and use snippets, hook into libraries, and so forth with the same idioms you'll have in your in-house or in-project code. And if your project is open source, other people in the same ecosystem can grab it and use it just as easily. I'd say that's essential reason that Python, which by most metrics is a pretty unremarkable language, is so popular.

                  Even the Perl community has come to recognize the value of having a smaller number of coding coventions: the complete language redesign for Perl6 - which admittedly may never get off the ground - abandons the famous Perl TIMTOWTDI motto ("There Is More Than One Way To Do It") because of this exact problem with Perl 5. Now again, Perl6 does not, as far as I know, have a full implementation or much adoption. But I think that's due to other problems, not the move towards fewer syntactic oddities than Perl 5.

                  Comment

                  Working...
                  X