4 ms·

> but there's definitely something to be said for staying completely w/in the language The C Pre Processor is defined in the ISO C standard. In order for any i

> but there's definitely something to be said for staying completely w/in the language The C Pre Processor is defined in the ISO C standard. In order for any implementation to call it self a normative conforming C implementation I has to include a pre processor to spec. The Pre Processor is part of the ISO C language. > auto-formatting, rename refactor, source introspection tools All of those things are had quite easily with C. Either as IDE/Editor features or with separate tools such as Clang Complete, Valgrind and many others.

dilap 11y ago
spent a long time w/ c and c++, never found tools anywhere near as good as what i've got now for go. maybe/probably not impossible, but a lot harder in practice. i have no personal experience, but people that seem to know what they're talking about say a big reason is the preprocessor makes life a lot harder. (and other stuff too, of course, like not having build semantics built into the language, and, for c++, just insane complexity in general.) obviously the preprocessor is well-defined and standardized, but it still: operates on a totally different semantic level. it really is like two entirely different languages pasted together.
- generic_user 11y ago
  Would you mind listing a few tools you use with go? I do not have much exposure to go but from what I have seen there is a nice set of introspection libraries. are you talking about tools that use these? A final note, real time semantic checking of multiple expansion macros has been solved for quite a few years now and is in most IDE's and even in Vim and Emacs. Semantic analysis is done in the comelier, LLVM/Clang lib has given rise to a substantial set of tools that are now quite widely used and solve most of the problems. And I believe C++17 with concepts is also going to have a dramatic effect on complexity and readability of template error messages.
  - dilap 11y ago
    these days my only c use is via obj-c in xcode, so i may well be unaware of the state of the art for straight c or straight c++ / other tools. xcode's refactorings and jump-to-defn (presumably powered by clang?) are still very flaky for me. for go, i use: goimports -- which is gofmt (which is awesome) + auto-adding/removing imports (just a heuristic so not always right, but usually right and quite handy) godef -- for jumping to definitions gorename -- for rename refactorings. i have not once gotten this to break code. oracle -- for showing other things about code, like 'which types implement this interface?'. as far as i can tell, it hasn't lied to me yet. i use emacs as my editor, which integrates easily w/ all of the above tools. i'm not sure what libraries power the tools above, but i think it's true that packages like go/types do the heavy lifting and make them relatively easy to write.

dilap 11y ago

spent a long time w/ c and c++, never found tools anywhere near as good as what i've got now for go. maybe/probably not impossible, but a lot harder in practice. i have no personal experience, but people that seem to know what they're talking about say a big reason is the preprocessor makes life a lot harder. (and other stuff too, of course, like not having build semantics built into the language, and, for c++, just insane complexity in general.) obviously the preprocessor is well-defined and standardized, but it still: operates on a totally different semantic level. it really is like two entirely different languages pasted together.

generic_user 11y ago
Would you mind listing a few tools you use with go? I do not have much exposure to go but from what I have seen there is a nice set of introspection libraries. are you talking about tools that use these? A final note, real time semantic checking of multiple expansion macros has been solved for quite a few years now and is in most IDE's and even in Vim and Emacs. Semantic analysis is done in the comelier, LLVM/Clang lib has given rise to a substantial set of tools that are now quite widely used and solve most of the problems. And I believe C++17 with concepts is also going to have a dramatic effect on complexity and readability of template error messages.
- dilap 11y ago
  these days my only c use is via obj-c in xcode, so i may well be unaware of the state of the art for straight c or straight c++ / other tools. xcode's refactorings and jump-to-defn (presumably powered by clang?) are still very flaky for me. for go, i use: goimports -- which is gofmt (which is awesome) + auto-adding/removing imports (just a heuristic so not always right, but usually right and quite handy) godef -- for jumping to definitions gorename -- for rename refactorings. i have not once gotten this to break code. oracle -- for showing other things about code, like 'which types implement this interface?'. as far as i can tell, it hasn't lied to me yet. i use emacs as my editor, which integrates easily w/ all of the above tools. i'm not sure what libraries power the tools above, but i think it's true that packages like go/types do the heavy lifting and make them relatively easy to write.