Maybe I should stop using this topic as a convenient place to rant about programming stuff?
Anyway, I was fooling around with C++ some again earlier this week trying to get a simplistic websocket server running, with the intention of writing a simple browser based game using the C++ application as the backend.
I remember way, way back when I was first learning to program how I used to wonder why people raved so much about scripting languages compared to compiled languages. I stopped wondering that a long time ago, but this sure gave me a strong reminder of that lesson.
It wasn't too long after I started working on it that I remembered why I don't code in C++ much anymore. Getting a websocket server running is not simple. It requires a lot of things that aren't directly part of C++ or its standard library. There's obvious stuff like the network layer, but less obvious stuff like needing a SHA-1 hash generator, a base64 encoder and decoder, and a dozen other things I'm forgetting. So, naturally, rather than waste time and reinvent the wheel I searched for a library to do it for me. I found a couple, and that was when I was reminded of two things:
1. I generally hate working with other people's libraries
2. Coding in C++ is too much work these days
These combine to a third point: I
really hate working with other people's C++ libraries. Quadruply so if I'm working on Windows, as I was.
Both of the libraries I found were originally written with a Linux environment in mind. Whatever, I expected as much, since apparently only the biggest open source projects care about Windows ports. I didn't have a Git client on the computer, so I downloaded the ZIP file of one and extracted it while trying to figure out how to get it to compile in Visual Studio 2013. Oh, great, it needs Boost. I haven't had good experiences with Boost in the past, even on Linux, so I was scared of that.
155 MB later, I had Boost downloaded. It took five full minutes to extract and move the many, many thousands of source files, but setting it up in VS afterward was easy enough. I tried to compile again, and... nope, I have to compile the Boost thread library for this websocket library.
Okay, fine. How do I do that? After looking it up, naturally it involved some specialized build system that had to be run from the command line, since using a VS project was apparently just too crazy. Oh, and of course, lots of the libraries fail to compile because they haven't been updated for VS 2013 yet. These are known issues from over a year ago it seems, but Boost 1.56 isn't out yet so I'm stuck with this.
Unbelievably, the thread library was one of the few to compile, so I crossed my fingers, dug through the directories, then
Googled where the heck Boost's build system dumps the libraries, and was finally able to compile my application and get it to run (after fixing some more VS 2013 related errors in the websocket library).
In the end, I realized something a little scary about the entire process: I genuinely didn't know if I should be impressed or mad that it took me 4 hours to get a purportedly cross platform and Windows supported library to compile and run.
If this was an isolated incident it wouldn't be so bad, but it was the exact same nonsense when I tried to get V8 integrated into a different application a year or so back. It took me
days to get it to compile on Windows, because it used a specialized (different!) makefile / build system that was again not ported to the current version of VS. Which was to speak nothing of the difficulty of actually using it once it compiled, since the documentation was all but nonexistent or outdated.
This is the sort of thing that makes my reflexes jump to reinventing the wheel every time I have a problem rather than relying on someone else's solution. If I have to use their code, I'll have to fight it forever to get it to work, then I'll have no idea what to do if it
doesn't work, and even if it does work it's probably not
exactly the wheel I needed. At least if I do reinvent the wheel, it's the wheel I need and one I understand.