Here we are at the end of this series. I was hoping we’d get a public beta of JAI before the end of the year and I could end this by experimenting with a new language, but it looks like that didn’t pan out.<\/p>\n
This last vexation isn’t remotely the most serious problem, but it’s the one that annoys me the mostOr maybe it’s second, after header files.<\/span>.<\/p>\n Of all the things that suck the joy out of writing code, I think that managing project files is pretty high on the list. This is sort of linked to the problem where integrating libraries in C++ is a madhouse and a chore<\/a>. If using someone else’s code was easier, then the headaches of setting up project files would be less of an issue. But these two problems exacerbate each other and force you to spend time putting all the files in the right places and referring to them in the right order.<\/p>\n In any case, this means there’s an annoying amount of sorting and accounting the programmer has to do in order to get everything working right, all of which is complicated by the archaic C system of header files. It’s not that these problems are too difficult. If you can write code to do memory management then these tasks shouldn’t be challenging for you. The problem is that these sorts of busywork tasks are something that – in a sane world – would be offloaded to the computer. (Assuming they needed to be done at all.) Computers are very good at large-scale sorting problems, and our programmer has way more important stuff they could be thinking about.<\/p>\n You need some way to tell the compiler (or your development tools) what files are part of your project. C compilers are terminal programsThis just means that they run in a text-based context like a DOS window.<\/span> and they don’t automatically know what files they need to be compiling or where to find the various libraries you’re using.\u00a0 There are a lot of options for compiling. Is this the debug version? What character set are we using? What libraries do we need to pull in? Is this 32 or 64 bit? What sorts of optimizations should the compiler apply to your code?<\/p>\n In the old days the programmer would have to type a bunch of inscrutable crap into the terminal window. For example, this is what you’d have to type into DOS to compile a modern program:<\/p>\n D:\\Projects\\Source\\BugHunt\\Debug\\BugHunt.exe\" \/MANIFEST \/NXCOMPAT \/PDB:\"D:\\Projects\\Source\\BugHunt\\Debug\\BugHunt.pdb\" \/DYNAMICBASE \"kernel32.lib\" \"user32.lib\" \"gdi32.lib\" \"winspool.lib\" \"comdlg32.lib\" \"advapi32.lib\" \"shell32.lib\" \"ole32.lib\" \"oleaut32.lib\" \"uuid.lib\" \"odbc32.lib\" \"odbccp32.lib\" \/DEBUG \/MACHINE:X86 \/INCREMENTAL \/PGD:\"D:\\Projects\\Source\\BugHunt\\Debug\\BugHunt.pgd\" \/SUBSYSTEM:WINDOWS \/MANIFESTUAC:\"level='asInvoker' uiAccess='false'\" \/ManifestFile:\"Debug\\BugHunt.exe.intermediate.manifest\" \/ERRORREPORT:PROMPT \/NOLOGO \/LIBPATH:\"E:\\SDK\\boost_1_55_0\\stage\\lib\" \/LIBPATH:\"F:\\SDK\\gl\\lib\\\" \/TLBID:1<\/tt><\/p>\n Nobody actually does<\/b> this, of course. The IDE<\/a> handles it for us. I’m just trying to show that behind that sleek interface is an architecture that dates back to the 1970s.<\/p>\n Very few programmers pay attention to this stuff. We set all the compile options using a friendly interface and let the development environment figure out what esoteric options are needed to get the compiler to do what we want.<\/p>\n If you’re programming on Windows then you’re probably using Visual Studio and you’ll do things one way, but if you’re on Linux you’ll do things a different way. The language is supposedly platform-independent, but the system that holds the project together isn’t. Like header files, this is understandable due to the age of the language. It’s not that the language was designed poorly, it’s just that it was designed a very long time ago for machines that are very different from what we use today.<\/p>\n So we have our C++ code, then we have some project file that’s not part of the C++ language but is needed so the editor knows what files we want to compile, and we’ve got these huge command-line arguments that nobody understandsStatistically speaking, anyway.<\/span>. Which means that your project requires 3 different sets of information in 3 different formats:<\/p>\n If you’re using Visual Studio, then the last two items are stored in the proprietary project file. Just to keep things interesting, Microsoft likes to fiddle with the format of the project files from one version to the next, creating a one-way conversion to the latest edition of Visual Studio. Which means that if one person upgrades, everyone on the project needs to upgrade. This also means its a pain in the ass for other projects – like Linux programmers – to make use of this file. This should all sound familiar to people who remember Microsoft Word and its ever-changing .docx format.<\/p>\n For years the structure of Visual Studio projects was basically folk knowledge. There wasn’t any official documentation. It wasn’t something you could learn in college. It was this whole body of specialized knowledge that you were just expected to know somehow. If you had a problem communicating with the compiler, you had to post on a forum somewhere and hope someone else out there had already fallen into this trap, found their way out, and posted their escape route to the internet. In the early aughts, I lost a lot of time to weird little mysteries when trying to do special builds or deal with oddly structured libraries. I don’t run into those problems anymore, but I don’t know if it’s because Visual Studio got better or because my work is simpler.<\/p>\n In any case, the answer seems obvious: Don’t use Microsoft’s tools. That should keep you out of trouble, right?<\/p>\n However, the tools are otherwise really good. They’re also very common in the games industry where so much of the development process takes place on Windows machines. Based on the GDC talks I’ve watched, Visual Studio seems to be pretty standard in AAA development.<\/p>\n None of this is the fault of the language, of course. But it’s still a dumb headache that developers have to deal with. It might even be a contributing factor to why Linux gaming is still in such sad shape. Moving your project off of Visual Studio and getting it to compile on Linux has got to be a huge pain in the ass.<\/p>\n As I’ve said before, my experience with modern languages is pretty limited. Still, every language I’ve tried has been better than the C family when it comes to project files.<\/p>\n Like I keep saying, I don’t want this series to sound like a commercial for Jai. The language isn’t out yet, it’s all unproven, I haven’t used it, etc etc. Having said that, I really like the way Jai supposedly handles project files. In Jai, all three kinds of data – source code, compile options, and included files – are expressed in the same file. Essentially, your source code is<\/b> the project file, and the compile options are specified in your code. You communicate with the compiler using the same language you’re writing the program in.<\/p>\n You invoke the compiler by pointing it at a single file. Something like this:<\/p>\n jai main.jai<\/p>\n This calls the compiler and tells it to compile the file main.jai. That file will tell the compiler what other files are part of the project, where they are, and what compile options we want to use. The compiler will then process all of the files in one go, building up a complete understanding of all the functions. You don’t need to make header files to tell it how to find things, because it can just figure it out on its own.<\/p>\n This means that compiling the program will be exactly the same on Windows, Linux, Mac, or wherever else you’re trying to work.<\/p>\n I love this idea so much. Your project structure isn’t hidden in a bunch of specialized files that are tied to your development environment. They’re something the programmer can read and understand. <\/p>\n This is the kind of convenience that you usually only get in higher-level languages. The assumption is usually that if you want an easy compile, then you must also want garbage collection, copious error checking, and lots of other convenience features that hinder your ability to write really fast code. If you want direct memory management and freewheeling data access, then you must also want a really fiddly and obtuse system for compiling it.<\/p>\n Along those lines, Jai offers another feature that’s usually associated with higher-level languages…<\/p>\n Introspection is a pretty strange concept, but it involves a program being aware of the code used to generate it. Let’s return to our old friend the space marine:<\/p>\n That’s the class definition. That block of code describes a SpaceMarine, what its fields are called, and what kinds of data they store. If you want to use a SpaceMarine and maybe give him some bullets, you would create an instance of it in code like so:<\/p>\n When we’re looking at the code we can clearly see the name of the class (SpaceMarine) and the name of the variable (shepard) and we can see what all the internal parts of a SpaceMarine are called. The important thing to remember is that the compiler can see this, but not the compiled program.<\/p>\n Remember that once a program is compiled, it gets turned into stuff like this:<\/p>\n The various commands boil down to mechanical instructions like “Move program execution to this instruction. Now copy stuff from this memory address to that other one. Now take the value in this address, add some number onto it, and copy it back to the first location. Now move execution to this other memory address and do whatever instructions are stored there.” It’s all numbers. There’s no way for the program to know that the stuff stored in memory address 1D4573 was originally a variable called “shepard”. All of those handy human-readable names are lost\u00a0 when the program is compiled.<\/p>\n But!<\/p>\n It is<\/b> possible to retain that information. Doing things this way costs extra memory and processor cycles, so not all languages support it. This sort of thing is called introspection.<\/p>\n Actually, sometimes it’s called reflection<\/b>.<\/p>\n Actually, sometimes it’s called RTTI<\/a> for “Run Time Type Information”, but only in C++C++ author Bjarne Stroustrup did not include run-time type information in the original version of his language, because he thought this mechanism was often misused. This is a really strange reason, given how the rest of C++ lacks anything in the realm of safety features. Like, he was willing to include buzzsaws in his language in the form of memory pointers, but he thought the paring knife of RTTI was too risky? I don’t know. He’s the author of one of the most successful languages on the planet and all I’ve made is this silly blog, but it sounds funny to me.<\/span>. Sort of. RTTI isn’t really the same thing, but it is related. It’s complicated.<\/p>\n I’m not going to try and untangle these terms, since people seem to disagree on their frequently-overlapping definitions. For now let’s just stick to talking about introspection and ignore the other two terms. We can poke our head into that wasp nest someday in the future if we’re feeling brave and there’s something to be gained in the effort.<\/p>\n I never have a use for introspection when making production code, but I’ve found it immensely useful for debugging tools and meta-analysis. The classic command console in the old Quake and Half-Life games is a great example of using introspection. The user can type in text, and the program can use that text to manipulate or display variables while the program is running.<\/p>\n There are many other uses for introspection, but they don’t usually crop up on my projects.<\/p>\n At any rate, introspection is generally associated with higher level languages like C# and Java. C++ doesn’t do introspection at all. Neither does Rust. D language seems to partly support it, but I think I’d need to know the language myself to follow the conversation<\/a>.<\/p>\n
\nDisclaimer: This is one of those rare instances where Linux seems to be more user-friendly and turnkey than WindowsDespite the efforts of Microsoft to “idiot-proof” their OS, there are surprisingly a lot of these.<\/span>. It’s been years since I did any programming on Linux, but I remember using a package manager that could find the required files, download them, and put them in the right place. There seem to be some basic rules about how to share source files. On Windows, this entire process is done manually and there doesn’t seem to be a coherent set of rules. Every Windows-based library has its own logic regarding how the files should be structured on your hard drive and how they should be added to your project.<\/p>\nVexation #7: Fiddling With Project Files is Not Programming<\/h3>\n
\n
We Can Do Better. I Think.<\/h3>\n
Introspection<\/h3>\n
class SpaceMarine\r\n{\r\n bool dead;\r\n char[8] name;\r\n Vector3 position;\r\n float stubble;\r\n short bullets;\r\n short kills;\r\n int dead_wives;\r\n int hitpoints; \/\/Don't forget the hitpoints this time, Shamus\r\n bool cigar;\r\n int mana; \/\/I really think the designers need to get on the same page here.\r\n};<\/pre>\n\r\n\/\/Please don't give me a hard time about encapsulation. I'm trying to illustrate something here.\r\n\/\/I'm not going to ship this code, I promise.\r\nSpaceMarine shepard;\r\nshepard.bullets = 10;\r\n<\/pre>\n
\r\nmov eax,4\r\nmov ebx,1\r\nint 80h\r\n\r\nmov eax,1\r\nmov ebx,0\r\nint 80h\r\n<\/pre>\n