I always thought that using the cookbook method was an odd approach to programming. The idea is to abstract some of the difficult things to do at the low level so you can get on with the making instead of reinventing string stuff for the tenth time or whatever. This is done on grand scale with things like DirectX and OpenGL or even more intensely with something like BlitzBasic. Who wants to deal with low-level graphics programming when you could be making your games?
The main drawback of programming like that to me was that you can end up not understanding anything about the topic you used the cookbook for. It makes weird problems you inevitably encounter nearly impossible to debug. But for some things, you can’t avoid that; I certainly don’t understand how OpenGL triangle strips end up making nice objects on screen, and I never will. But now I find myself with an entire language apparently devoted to cookbook programming for nearly everything. That is, Java.
At least to me it seems like cookbook programming. You could (and people do) approach C++ the same way, for instance, by using a thing like Boost or wxWidgets (especially cross-platform). But I always found the documentation to be either so hard to understand (in the case of Boost) or so chaotic (in the case of wxWidgets) that I ended up having to really look at the examples and classes I was using and really understand them to use them anyway. Don’t believe me? Take a look at one of the coolest things in Boost: the multi-index container. Awesome piece of code, but it is hard to get the hang of. The examples don’t cover the things it is really useful for; the examples are mostly for things that other lists already do, or too simple. So you have to dive deep in the tests and the source code to find out what is going on. That’s not really cookbook-style to me; it just saves me the trouble of actually writing the code, but I still have to know what’s going on.
Well, Java may not have a multi-index going for it, but it has a ton of stuff. And the kicker is, it is basically all built in, especially if you use Eclipse (see red squiggly, hover over, import the missing bits). One of the big hurdles to Boost or any other C++ library is shoehorning it into your project and build workflows. It can be a real pain to do. Java is just…there. And Boost/wxWidgets/Poco/etc. are all missing big chunks because trying to do academic things mixed with GUI seems to be a no-no. This is compared to Java, which is a pretty complete solution.
So by having a ton of stuff, you can Google even weird problems and the solution is there. Just cut and paste, and you are cooking up a new program. This is definitely a good thing, just like Boost is; no need to reinvent the wheel. But I feel like I am missing out on the nuts and bolts of Java, which I guess is the idea. It is worrying, because I feel a bit like I am working without a net.
That is the big drawback to me so far: when something doesn’t function as expected or is just too limited. I always had the opportunity to dive into the other open source libraries if I needed to see exactly what weirdness is going on or see the lack of functionality, and often I could fix the problem and submit the bug or modification to the project for a change. Bureaucracy aside, the fix or enhancement would eventually get in, but I could patch things on my side for our next release (I only ever used licenses that allowed that for obvious reasons) and everything was good to go.
I don’t know of a parallel in Java. If something doesn’t do what I need, then I don’t have a way to add in a modification that will do it, and bugs mean you just have to wait. Today’s issue for me is how the java.awt.Color object works.
Basically, it lacks the ability to multiply the color contained therein by either a scale factor or another color. To do that you have to release the previous instance and make a new one, which in my case could mean a lot of references tossed to the garbage collector, and it is slow way to do such a simple thing for thousands of color nodes anyway. That means the object is useless for things like color shifted bitmaps or lightening/darkening the color. There is a function to brighten or darken the bitmap, but it is by a fixed factor; you can’t specify the scaling yourself.
This is a nuisance, because what I would like to do is declare my own bitmaps that are arrays of Color objects, and then write their RGBA values directly to a BufferedImage and then blit said image to the screen. Instead, I either have to use arrays of integers for my bitmaps or make my own flavor of Color and use that.
Well, I chose the second path, and for my own purposes named it FastColor. It didn’t take long to write it, but it seems inelegant. Java gives so much, but when you are out of luck the improvisation feels tacked on. You don’t have a net with Java, and I don’t know where I will go if something doesn’t exist, and I can’t find a way around it. I always had the option to rewrite things at low levels if I needed to. It makes me want to rein in my ambitions when working with Java. I suppose that working low level in C/C++ is what the JNI is for…but I usually only need to tweak something, not rewrite the whole thing!
Oh, and I made good chili this weekend. The analog type. From a real cookbook.