Continuing the series on Scheme, this video explains the ultimate alternative – when nothing else is flexible enough, we can create our own bits of lanugage using macros.
The fancy word for what I’m talking about here is Deployment. How easy is it, once you’ve written your code, to get it running on someone else’s computer? What barriers are there to someone else using your program?
Examples of potential barriers include:
- Having to download some other program first, e.g. a runtime or some kind of dependency.
- The actual program being a huge download.
- Something mysteriously not working because of different versions of something on the person’s computer.
- The program simply not working on the operating system or machine architecture of the computer.
Anything that can be done to remove these barriers makes my life as the supporter of the program easier, and makes it more likely people will use it.
Here are some things I like:
- Java’s ability to run almost anywhere. Once you have the runtime, Java code is relatively easy to get running on many different operating systems and architectures, using almost-identical code. Other runtime-based languages are also strong here.
- Java and Python’s large built-in libraries. Both Java and Python include large amounts of functionality in their standard libraries, reducing the need to depend on third-party components.
- Python and Perl’s ability to work out of the box on most Linux systems. If you are developing for Linux, you can pretty much guarantee that an up-to-date runtime will be available, meaning no dependencies at all are needed.
- Many languages’ easy integration with Linux packaging. Most of the above barriers disappear if you can install dependencies using your operating system’s built-in package manager.
- Quickly‘s easy way to build your program into the packaging system. Things really become easy if your program itself is integrated into the packaging system.
- C and C++’s lack of dependencies. It is possible to write C and C++ programs that depend on nothing except standard runtime libraries, which are almost guaranteed to exist on most machines.
One way to handle dependencies is to package them together with your code. This is what most corporate Java software does – the specific Java runtime that is known to work is packaged with the program itself. This makes for big downloads, and defeats the concept of providing a single package for all platforms, but it does work. It also makes for huge headaches to do with licensing, and is often impossible for software producers who don’t employ legions of lawyers. It also feels bad and wrong.
When packaging and deploying software, I subscribe to the philosophy of “Find the dependencies – and eliminate them“. Until someone can click a single button and have your software running, you haven’t finished.
When you first hear about the Read-Eval-Print Loop you might well think “So what?” as I did.
What’s so great about being able to type commands interactively?
But the thing is that it creeps up on you.
Everyone already knows programming is an interactive thing – we need constant feedback to validate our ideas. Programming on paper is incredibly frustrating because you have to plough on with assumptions that are probably wrong.
It’s just so
I mean, it’s really not much hassle to create a new directory, make a new file, edit the file to contain the code you want to try, remember the right command to compile it, then run the program and see the results, is it?
Well, no, it isn’t, but it’s enough of a hassle that sometimes you don’t bother and you try it out in the code you are really working on, and if your work is like mine that means a minimum of 5 minutes to compile and link, and there you are playing foosball again when you could be getting something done.
The REPL gives you a place to try throwaway things extremely quickly, and when you’re working with something beautiful like Python it’s easy to get addicted.
So my mind started to wander and it struck me that a pale imitation of the REPL could be made for us poor C++ programmers, and it would generally serve the purposes I’ve described above.
So IGCC was born. Its name means “Interactive GCC” and it’s a read-eval-print loop for C++ (and, for most cases it will work for C too).
It uses the real GCC underneath, so you know you are running the exact code you would be (and it’s
It wraps your code in a standard C program, includes some common dependencies, and compiles it, printing the results of running them immediately. Using it looks like this:
$ ./igcc g++> int a = 5; g++> a += 2; g++> cout << a << endl; 7 g++> --a; g++> cout << a << endl; 6 g++>
Apart from all the sugar that I’d love to add, the main missing features are some kind of equivalent of the Python dir command, and code completion.
It’s not rocket science, but it might make you a little bit more interactive in your C and C++ coding, which might save you valuable foosball time.
Enjoy, improve, etc. IGCC.
Foosball image taken from http://en.wikipedia.org/wiki/File:Baby_foot_artlibre_jnl.jpg
Git is supposed to work when you upload your repository to an http server, but in reality, no-one except me seems to use it, and it’s nothing like as useful as having a proper repository that people can commit to etc.
So, here it is: http://repo.or.cz/w/gssmp.git.
There was a weird bug in my last.fm support for GSSMP, where it would crash when run from the GNOME panel, but be fine when run from a terminal.
After two bugs fixes from Charles Bailey, the problem seems to have gone away, so I’ve finally been able to make a release.
Now I have to resist the temptation to choose songs to make last.fm think I’m cool, instead of songs I actually want to listen to.
And I really need to fix the debian/Ubuntu package of lastfmsubmitd so that the client exe lastfmsubmit is included in the package. Without that, using last.fm with GSSMP is a major hassle.