Programming, what is it good for?
I'm annoyed with C++. More specifically the whole build ecosystem, not the language itself (although I'm pretty annoyed with that, too).
I'm trying to make a very basic project and build it cross-platform. I've been using CMake which gets all the basic build system done, and that's handy. I'm trying to do cross-compiling in Ubuntu for both linux and Windows (using MinGW), with a separate build on my PowerPC for OSX. That works fine, so long as I use very basic C++. Try to use anything from C++0x? Sorry, build errors on OSX. Try to use Boost to make doing filesystem access in C++ not an exercise in pain? Oh, good luck doing cross-compiled builds in MinGW. I eventually got that working after about a day of fighting with it. Oh, but guess what, apparently it's not quite compatible with the version installed by default in Ubuntu, so my code won't compile on both without changes (finally sorted that out). I thought once I had the basic libraries all built (since Boost doesn't provide pre-compiled binaries like SDL does -- Thank you, SDL!) the rest would be just coding, but no. So far I've avoided any #ifdefs for platform-specific features, I've just had to be constantly testing the builds on each target system and making adjustments to the code.
And all of this was because although these days I prefer doing most of my coding in a language like Python or C#, just because of the expedience and neatness of the code, but chose C++ for this project for portability. It's really making me reconsider this decision.
Sure Python is really very portable (for some definitions of portable), but there is no (to me) acceptable method (still!) of doing proper packaging that isn't messy and/or wasteful. The other option being to expect the end user to install Python and all of the project's module dependencies, which is also unacceptable. Unfortunately the main SDL wrapper for Python, pygame has slowed development in recent years and has inconsistent support for newer Python versions, depending upon the target platform. There's also a question of speed. Python simply isn't as fast as C++ for the tight loops. So I thought as nice as it is to be able to quickly write code, in the long run it's better if it takes longer to write but runs faster and I have more control over the end packaging for distribution. Hah!
C# is theoretically portable (with mono) but the feature set always lagging behind means I'll constantly have to be targeting an older version of C#. Better to not deal with the temptation, not to mention needing to avoid all the hidden minefields of unsupported or incorrectly supported behaviour on one platform or another that will surely show up and be incredibly hard to work around.
So I'm using C++. And it's so, so very easy to write awful code in C++. Why? Because doing even the simplest most straightforward thing correctly requires pages of scaffolding code, declarations, and such, while the direct route ends up using lots of hacks, typecasting, globals, etc. The gap in effort means I can spend hours or even days setting up code that doesn't technically do anything yet, because I want to do it correctly, and can't stand ugly unreadable code. Yet with all that work it's still just framework. It's an engineering paradise, but if you want to actually accomplish something and accomplish it correctly, you're in for a lot of (what should be unnecessary) work.
I've been writing in C/C++ since I was very young. I know this language very well, but it's been some time since I've done much with it aside from creating/submitting patches for other projects. Working on something of this scale reminds me why I moved on to higher-level languages and haven't looked back with regret.
So short of doing a fullscale ScummVM-level multi-platform backend completely abstracting the entire process, which could take months to complete and provide no further progress on the actual project, I really have to reconsider what I'm doing. I like C++, I really do, but these days writing in it feels like talking to a computer system Kirk might have done battle with, rather than just accomplishing what I want. Back when I started writing C programs in the early nineties, I was writing directly to hardware. Video hardware, audio hardware, whatever, you accessed the memory locations, you poked them with bytes that would trigger things you placed in other locations. Using a language that worked on that level (and even dipping into assembly on occasion) made sense. Now it just feels out-of-place.
Which leads me to think again about the web as a platform, which I had briefly considered initially. I've been getting a lot more experience with Javascript lately, enough to know that while it's great for smaller projects, the rather "swimmy" nature of the interpreter (it's made to be very... flexible... for legacy reason) makes it pretty much the opposite of the trouble with C++, and just as bad in its own way to my mind. The silent failures and complete lack of any strictness at all make it a real pain to debug. It's a great language for prototyping and rapid development, but I fear that anything larger that takes any less effort than a fully-audited and unit-tested framework would be unreliable, and again I'm left coding a framework instead of the actual project at hand.
Of course the great things about Javascript (in the browser space, at any rate) is that you don't have to worry about all the little things like compositing, drawing, event systems, etc. and unlike some people I don't even mind the DOM. It's a little clunky sometimes but it gives one a basic data and display framework that you can use right off. But I like XML, too, so maybe I'm crazy. ;) (Although I have been becoming more enamoured of JSON of late, just because it's so gosh darned easy to parse into something immediately usable).
The other problem with the browser platform is also one of its strengths: new features are being added all the time and it's becoming more and more an effective application delivery platform. On the other hand, that means everything you code is to a moving target and no matter how much you try to be lowest-common-denominator and carefully feature-sniffing there will always be something. That's just a rule, especially relevant when the interpreter is chosen by the user and run client-side. There are just too many targets right now for something that would use any but the most basic feature set, which limits things greatly. WebGL is a nice potential for the future, but again far from universal.
So Python is nice. It's got definite versions, which you can at least count on. It has a wide-range of modules that handle modern things like *gasp* filesystems built right in. Excellent data structures and language features that treat them as first-class members; you get automatic iteration over containers instead of creating iterators on every bloody thing ever time you need to flip through them using a horrible, kludgy syntax that makes no attempt to abstract away the underlying implementation. I just wish it was possible to create acceptable distribution packages, and that it was getting as much optimization attention as Javascript has been getting lately (Unladen Swallow appears effectively dead, unfortunately).
I guess the point of all this is that no matter what language I choose it seems there are some major hurdles that although not insurmountable seem unnecessary and outdated, and are just plain tiresome. It feels like instead of addressing these issues and fixing the question of platform-agnosticism, we've tried side-stepping it with solutions like Java, Flash, and Javascript which just move it into their private worlds and end up with just as much cruft in new and just-as-awful ways.
I've been programming most of my life, and I think maybe I'm just tired of the nonsense bits.
Or maybe I'm just tired of always working alone on large projects.
Maybe all of the above.
I'm trying to make a very basic project and build it cross-platform. I've been using CMake which gets all the basic build system done, and that's handy. I'm trying to do cross-compiling in Ubuntu for both linux and Windows (using MinGW), with a separate build on my PowerPC for OSX. That works fine, so long as I use very basic C++. Try to use anything from C++0x? Sorry, build errors on OSX. Try to use Boost to make doing filesystem access in C++ not an exercise in pain? Oh, good luck doing cross-compiled builds in MinGW. I eventually got that working after about a day of fighting with it. Oh, but guess what, apparently it's not quite compatible with the version installed by default in Ubuntu, so my code won't compile on both without changes (finally sorted that out). I thought once I had the basic libraries all built (since Boost doesn't provide pre-compiled binaries like SDL does -- Thank you, SDL!) the rest would be just coding, but no. So far I've avoided any #ifdefs for platform-specific features, I've just had to be constantly testing the builds on each target system and making adjustments to the code.
And all of this was because although these days I prefer doing most of my coding in a language like Python or C#, just because of the expedience and neatness of the code, but chose C++ for this project for portability. It's really making me reconsider this decision.
Sure Python is really very portable (for some definitions of portable), but there is no (to me) acceptable method (still!) of doing proper packaging that isn't messy and/or wasteful. The other option being to expect the end user to install Python and all of the project's module dependencies, which is also unacceptable. Unfortunately the main SDL wrapper for Python, pygame has slowed development in recent years and has inconsistent support for newer Python versions, depending upon the target platform. There's also a question of speed. Python simply isn't as fast as C++ for the tight loops. So I thought as nice as it is to be able to quickly write code, in the long run it's better if it takes longer to write but runs faster and I have more control over the end packaging for distribution. Hah!
C# is theoretically portable (with mono) but the feature set always lagging behind means I'll constantly have to be targeting an older version of C#. Better to not deal with the temptation, not to mention needing to avoid all the hidden minefields of unsupported or incorrectly supported behaviour on one platform or another that will surely show up and be incredibly hard to work around.
So I'm using C++. And it's so, so very easy to write awful code in C++. Why? Because doing even the simplest most straightforward thing correctly requires pages of scaffolding code, declarations, and such, while the direct route ends up using lots of hacks, typecasting, globals, etc. The gap in effort means I can spend hours or even days setting up code that doesn't technically do anything yet, because I want to do it correctly, and can't stand ugly unreadable code. Yet with all that work it's still just framework. It's an engineering paradise, but if you want to actually accomplish something and accomplish it correctly, you're in for a lot of (what should be unnecessary) work.
I've been writing in C/C++ since I was very young. I know this language very well, but it's been some time since I've done much with it aside from creating/submitting patches for other projects. Working on something of this scale reminds me why I moved on to higher-level languages and haven't looked back with regret.
So short of doing a fullscale ScummVM-level multi-platform backend completely abstracting the entire process, which could take months to complete and provide no further progress on the actual project, I really have to reconsider what I'm doing. I like C++, I really do, but these days writing in it feels like talking to a computer system Kirk might have done battle with, rather than just accomplishing what I want. Back when I started writing C programs in the early nineties, I was writing directly to hardware. Video hardware, audio hardware, whatever, you accessed the memory locations, you poked them with bytes that would trigger things you placed in other locations. Using a language that worked on that level (and even dipping into assembly on occasion) made sense. Now it just feels out-of-place.
Which leads me to think again about the web as a platform, which I had briefly considered initially. I've been getting a lot more experience with Javascript lately, enough to know that while it's great for smaller projects, the rather "swimmy" nature of the interpreter (it's made to be very... flexible... for legacy reason) makes it pretty much the opposite of the trouble with C++, and just as bad in its own way to my mind. The silent failures and complete lack of any strictness at all make it a real pain to debug. It's a great language for prototyping and rapid development, but I fear that anything larger that takes any less effort than a fully-audited and unit-tested framework would be unreliable, and again I'm left coding a framework instead of the actual project at hand.
Of course the great things about Javascript (in the browser space, at any rate) is that you don't have to worry about all the little things like compositing, drawing, event systems, etc. and unlike some people I don't even mind the DOM. It's a little clunky sometimes but it gives one a basic data and display framework that you can use right off. But I like XML, too, so maybe I'm crazy. ;) (Although I have been becoming more enamoured of JSON of late, just because it's so gosh darned easy to parse into something immediately usable).
The other problem with the browser platform is also one of its strengths: new features are being added all the time and it's becoming more and more an effective application delivery platform. On the other hand, that means everything you code is to a moving target and no matter how much you try to be lowest-common-denominator and carefully feature-sniffing there will always be something. That's just a rule, especially relevant when the interpreter is chosen by the user and run client-side. There are just too many targets right now for something that would use any but the most basic feature set, which limits things greatly. WebGL is a nice potential for the future, but again far from universal.
So Python is nice. It's got definite versions, which you can at least count on. It has a wide-range of modules that handle modern things like *gasp* filesystems built right in. Excellent data structures and language features that treat them as first-class members; you get automatic iteration over containers instead of creating iterators on every bloody thing ever time you need to flip through them using a horrible, kludgy syntax that makes no attempt to abstract away the underlying implementation. I just wish it was possible to create acceptable distribution packages, and that it was getting as much optimization attention as Javascript has been getting lately (Unladen Swallow appears effectively dead, unfortunately).
I guess the point of all this is that no matter what language I choose it seems there are some major hurdles that although not insurmountable seem unnecessary and outdated, and are just plain tiresome. It feels like instead of addressing these issues and fixing the question of platform-agnosticism, we've tried side-stepping it with solutions like Java, Flash, and Javascript which just move it into their private worlds and end up with just as much cruft in new and just-as-awful ways.
I've been programming most of my life, and I think maybe I'm just tired of the nonsense bits.
Or maybe I'm just tired of always working alone on large projects.
Maybe all of the above.