vs. make. qmake. cmake. autotools. scons. 'modern' makefiles (>_> what does that even mean? Yes, I'm looking at you Google) There's a whole ecosystem of tools out there to solve this.
- There are a few rubbish IDEs, most of which support c as a second class candidate.
VS has officially abandoned C; xcode grudgingly supports it. The CDT is mediocre. There's little or no support for refactoring or doing other things on large code bases, and the majority of the time the work has to be done manually.
- Because the build system is broken, dependency management is hell
Got one library that uses scons, another using autoconf, and what to build a local dev instance of a library without installing it into the system path? Goooood luck.
This is made even worse by arcane things like rpath, which mean that dynamic libraries only work when they are in specific paths relative to the application binary (I'm looking at you OSX).
- Its a terrible collaboration platform.
Why? Because the barrier to entry is high. To submit a patch that works and doesn't break other things, doesn't introduce serious security holes or memory leaks is hard.
Astonishingly, some successful projects like SDL are actually written in C, but most C projects are not collaboration friendly.
- There are no frameworks for doing common high productivity tasks in C, only low level system operations, or vastly complicated frameworks with terrible apis (>_> GTK).
I'll just whip up a C REST service that talks to mysql and point nginx at it. Um... yeah. I'm sure there's an easy way to do that. ...perhaps...?
How about a quick UI application? We'll just use GTK, that's portable and easy. ...Or, not very easy, and vastly complicated to setup and build.
These issues aren't unique to C, but they're certainly issues.
I'm not really sure I'd happily wonder around telling people how amazing C is at everything.
I'd completely agree. I would not use C for doing any web platform work (writing a REST service as you say). I may write a webserver in C if I had tight memory constraints.
Where I see C still being very useful: embedded applications, drivers, and latency sensitive code.
When you are trying to push the most I/O possible through a network interface or disk interface, C allows extremely tight controls on memory and CPU usage. Especially if you are coding to a specific CPU for an embedded product, you can really tweak the app to perform as required (though, this may require some assembly to do what you need).
I have done low-level and mobile programming on very restricted platforms and I cannot see any reason why in the world I would use C instead of C++. Basically there is always an opportunity to use C++ if you can use C. Myths that C++ is slower are spread by people who just do not know C++ well or are not skilled/clever enough to use it.
Indeed. And there are numerous reasons why C++ code can be/is significantly faster; firstly code inlining for code that would be required to use function pointers in C (ala qsort vs std::sort), secondly, things such as expression templates for things such as Matrix libraries.
> There are no frameworks for doing common high productivity tasks in C, only low level system operations, or
> vastly complicated frameworks with terrible apis (>_> GTK).
> I'll just whip up a C REST service that talks to mysql and point nginx at it. Um... yeah. I'm sure there's
> an easy way to do that. ...perhaps...?
Search for libfcgi. It's nice and simple C library that can be used behind nginx and as the matter of fact anything that supports fcgi. In this case routes are defined on nginx. But just think a bit, it's nice little framework ;-)
For the record, I found cmake to be the best. The output is great, the convenience is awesome, the only thing that bugs me is the strange syntax, which is fine because once you set it up it gets out of your way fine.
Though it doesn't reach all the dark corners that cmake does, I found premake to be much easier to figure out and customize. All the configuration is done in Lua and you can customize the state with a normal programming language as opposed to the crazy cmake arcana you sometimes have to resort to.
To both parents: whenever I have to install and work out how to debug yet another C build system on my Mac (default build settings never work on Macs), it leaves me wanting to (and indeed going on to) rewrite entire libraries I should be just using. (notable exception: autohell seems to work, some of the time, and it even sometimes fails with an error telling me what's wrong.)
When I use python extensions (often written in C), this problem doesn't arise because distutils, and sometimes cython, handle everything.
Python isn't the best C build system, but frankly it scores better than cmake and friends for ease of use.
Oh, yeah, definitely, I wish everything was as easy as "pip install". On the other hand, I can sympathize with nothing working on macs. This is because the environment plain sucks.
All the installed tools and libraries are old as hell and rarely get updated, and it's riddled with quirks and tools that are subtly different on osx. I hear it's gotten better with Mountain Lion.
Macports is my tool of choice, but yes it's the only way to get things done! Unfortunately, plenty of scientific libraries are too obscure to be ported, leaving it to us scientists...
Interesting what you say about 10.8 - I might give it a shot then. I will be upgrading soon from snow leopard (2009 MBP) and I was going to wipe and go debian/XFCE, because of all the "new ideas" like "let's not have save as" etc, but if installing stuff is easier (and I know multitouch works) I might give it a go.
I halfway solution I'm reasonably happy with is to have a VirtualBox install of Debian on top of OSX, and install most scientific libraries there. I've considered just wiping and installing Debian as the main OS, but when I first looked the Linux driver support for my MBP wasn't great, and since then I just haven't gotten around to it. VirtualBox works fine for anything that isn't too heavy duty, and anything heavy-duty I'm running on a beefier server machine anyway.
This is a good idea. The problem I have is that I sometimes need basically all my RAM for simulations (yes, occasionally even on my laptop) and my current only has 4GB (with OS X eating up about 1.5GB on startup for "kernel tasks") so it's dangerous to run a VM with more than 2GB. New laptop will def have 8GB though, so this solution becomes viable again, thanks :)
hmm, If I can get Arch to install, I might give it a go. Ubuntu was a bit pants when I tried it for a month early last year (had installed Lion, was pants on the old machine, tried ubuntu before rolling back to SL.) Multitouch gestures for multiple desktops is a must now that I've got used to it...
By the way, I refactor C with regexps and text utils. In UNIX a pretty complicated refactoring can be done with a shell oneliner. This method actually rules. C allows that because it does not have namespaces. C is minimalistic so that it allows working with it with minimalistic tools rather comfortably.
you know that the c/c++ plugin for intellij is broken? so what are you using that is smart enough to parse and refactor c? (serious question as i've had to switch to eclipse).
There is a problem that each and every tool for semantic-aware C/C++ refactoring I have tried does not work 100% of the time (i.e. it sucks more than 0%). This happens particularly because C/C++ have header files that expand to huge source files and preprocessor macros driving the parsers nuts because the parsers of the refactoring tools are simplified for speed, and also in a typical C/C++ program there is a number of combinations of macros that can be active or non-active depending on compiler options. So in case of C it always comes out faster, easier and more reliable for me to use basic tools such as search/replace because C has very simple semantics without namespaces. I often do that even in C++ because of the mentioned reasons.
Thanks for letting me know, I try to use the macros as little as possible, but there are such things as platform-specific code, compiler differences, third-party libraries, standard libraries such as WinAPI and legacy code.
Platform-specific code is a very good use that precluded me at 1 o'clock this morning.
I tend to wrap legacy code in a C++ wrapper if I can; allowing me to code to a C++ idiomed API, rather than the choice of that particular developer. More often than not, it adds no overhead through the use of inlined functions...
- The build system is broken.
vs. make. qmake. cmake. autotools. scons. 'modern' makefiles (>_> what does that even mean? Yes, I'm looking at you Google) There's a whole ecosystem of tools out there to solve this.
- There are a few rubbish IDEs, most of which support c as a second class candidate.
VS has officially abandoned C; xcode grudgingly supports it. The CDT is mediocre. There's little or no support for refactoring or doing other things on large code bases, and the majority of the time the work has to be done manually.
- Because the build system is broken, dependency management is hell
Got one library that uses scons, another using autoconf, and what to build a local dev instance of a library without installing it into the system path? Goooood luck.
This is made even worse by arcane things like rpath, which mean that dynamic libraries only work when they are in specific paths relative to the application binary (I'm looking at you OSX).
- Its a terrible collaboration platform.
Why? Because the barrier to entry is high. To submit a patch that works and doesn't break other things, doesn't introduce serious security holes or memory leaks is hard.
Astonishingly, some successful projects like SDL are actually written in C, but most C projects are not collaboration friendly.
- There are no frameworks for doing common high productivity tasks in C, only low level system operations, or vastly complicated frameworks with terrible apis (>_> GTK).
I'll just whip up a C REST service that talks to mysql and point nginx at it. Um... yeah. I'm sure there's an easy way to do that. ...perhaps...?
How about a quick UI application? We'll just use GTK, that's portable and easy. ...Or, not very easy, and vastly complicated to setup and build.
These issues aren't unique to C, but they're certainly issues.
I'm not really sure I'd happily wonder around telling people how amazing C is at everything.
It's a tool for some jobs; definitely not all.