Comment by DannoHung | Hacker News Reader

Comment by DannoHung | Hacker News Reader

Parent Full thread

The biggest problem with C is not the language C, for it is a small and mostly simple language with a few warts (I'm looking at you, pointer syntax), it is the ecosystem into which you are thrust when you first use it.

That is, the ecosystem of, "What can I include without dicking around with compiler and linker settings, which I do not care to learn very well because I am just starting?", and the ecosystem of, "Why are all these standard libraries full of functions that all the documentation tells me not to use?", and most importantly, the ecosystem of, "Oh, this looks like a nice library that would make my life easy, (and later), wait, why isn't my program working on this other machine? I copied the binary over? Wait, what's this about a missing so? Oh, that's the library I installed, wait, how do I put it the same directory? Oh my god so many configuration settings! Wait, why can it still not find the library? It's right there now! What's LD_LIBRARY_PATH? LD_LIBRARY_PATH is bad? Why doesn't -R work? Oh, that's only for Solaris? What's the equivalent for friggin' Linux?! Ah, rpath, wait... it's trying to find the ABSOLUTE path? UGGARRHGHGHAAHHHH! Okay, finally, $ORIGIN... now let me just put that in the make file like they said I should.... AHGHGHGHGHGHGHHHHHHHHHHHHHHH!!!!!!!"

Which is to say, the ecosystem of fucking ratholes that have built up over 40 years of poor tool design that cannot be corrected now due to historical precedent.

> The biggest problem with C is not the language C, for it is a small and mostly simple language with a few warts (I'm looking at you, pointer syntax), it is the ecosystem into which you are thrust when you first use it.

The language C is a big problem for beginners, though. Pointer syntax is not just a tricky optional feature, it's necessary for a number of common tasks including defining functions and passing parameters. The type system is also important, not intuitive and rarely taught effectively. Countless times I read or was told that the syntax for referencing arrays was the same as referencing a pointer in memory, but nobody ever bothered to clarify or reinforce the idea that arrays are still a distinct static type.

Pointers and types are fundamentals and anyone who was lucky enough to learn them early on might not understand how hard it can be to figure this stuff out on your own and how difficult it is to actually use C before you do.

"It's not the language, honey, it's the runtime." (apologies to Indiana Jones)

"It's not the despair, Laura. I can handle the despair. It's the hope I can't stand." (No apologies at all to John Cleese or to anybody else.)

C++ has the same issues.

To add another example, binary only distributions (e.g. some commercial software) bring their dependencies with them, meaning that you have to use roughly the same environment (compiler version, stl) to use them.

Libraries work a lot better in VM languages.

It doesn't take a VM language or an interpreted lanugage to get libraries working well. Take a look at Haskell's Cabal system and Hackage package library. It works pretty good and doesn't use a VM.

With C and C++, you'll have to use your operating system's package management to get all the important libraries (or build them by hand from Git sources, etc), then have a build system that configures the build environment and searches for all the libraries and other dependencies. It's not as nice as using a dedicated tool for this, like Gem and Bundler in Ruby but usually you get the job done - unless you work on Windows and don't have a package manager.

> Oh my god so many configuration settings!

There are many alternatives for you that offer 1click build/deployment.

There are so many, in fact, that choosing one becomes a confusing array of choices in itself.

Use cmake, no fuck this, try JAM. WTF? Why not simple Makefiles, better yet manually written projects for XCODE, VCPROJ.... Oh fuck no.... At the end of the day you wrote something to get your shit out. Simple as that :)

Just google for "msvcrt_win2000.obj" and see the madness (yes, it's about using MSVCRT.DLL instead of later MSVC libs, and still get your shit working on 2000 or XP). I did that just last few hours :)

If you statically link, will it only run on the latest platform? I don't believe I've ever shipped an app that dynamically linked to the MSVCRT.

It can, and that's what I did. But I decided to experiment, and there is some little benefit - less memory usage, and supposedly malloc() from one place can be freed() by another (or I think so). A lot of Microsoft products are still linking to it. At work we don't care and link to whatever latest MSVC provides, but for certain products to write plugins we have to use the exact same Visual Studio version (for example Autodesk Maya or MotionBuilder).

There are way too many subtle details (and more complicated with Windows's manifests, side by side assemblies and crap like that).

Hah! Exactly.

There is one that I can recommend, for the record, at least for C++:

Qt's QMake.

QMake can be quite helpful. Unfortunately, it may not be a good long-term choice:

http://labs.qt.nokia.com/2009/10/14/to-make-or-not-to-make-q...

http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/00...

The last project I tried that used qmake missed dependencies on generated files, and therefore needed make clean fairly often.

It's sad, but the best user experiences I've had were either hand-coded makefiles, or autotools (ick).

Reply on news.ycombinator.com