2009/6/26 Jonathan Enders <jenders@stud.uni-frankfurt.de>
<snip>
As I don't know if any of that is of any relevance to the boost community I will leave it at that. It just seems like a big lack to me that the boost-libraries still have no means of user interaction. If there is any interest in the above I have a working sample which demonstrates what words can only poorly describe.
I think it has great relevance. One of the founding idea's behind boost was to make great libraries available as C++ was getting stomped on by neat and consistent Java functionality in its libraries. That is, in my mind at least, part of the original guiding principle from boost and Beman seemed to be to make C++ more useful / productive / elegant / habitable. Making it more interactive / script-like is an interesting idea with all the good that comes from productivity and quickness of idea to action versus the dangers of loose expressionism (loose design sinks ships;-) ). We got an internal tool here we've been ummming and ahhhing about open sourcing. We call it "bofh" as it started as a "bunch of file headers" but does cpps now too to keep is compiling fast. The idea was that we do a lot of computation in R because it is convenient and but some of our data sets are many terabytes and, thus, as some of our stats in R were tediously slow, we wanted to make C++, our favourite religion, like a scripting language. So we did a python shell that feels like R but compiles with gcc/ccache/distcc in the back ground, integrates gnuplot. We've been striving to keep the hit enter, compile and link cycle, do useful stuff _and_ put it on the screen, to less than a second to keep it comfortable. Write C++ on the command line and it gets compiled into a main and just works. The main glue to make this functional was the delegation of data to mmap'd backed file based structures. That way, when a new executable is compiled and linked, the data is already memory resident (and in a file for tomorrow) in a named variable and convenient. Do a "2 + 2<CR>" and out pops 4 just about immediately. Do a "x = random_vector(1000000)". Then a "print(x)" and out pops a R like formating of 1000000 random doubles. Do "sum(x)" and you get the sum. That's four separate executables being constructed, compiled, linked and run all at interactive speed. It gets addictive when developing. Amazingly productive for a seemingly simple idea of making C++ feel interactive. Map/reduce like functionality across the cluster is on its way. It has been quite a learning experience. We have great plans to completely tear down what we've done and rebuild it all as it has grown up ugly due to immediate needs so if there is some interest it may be worth pursuing as a separate exercise. Another two or three complete redesigns and we may get it half right. We've largely avoided boost due to the "must compile and link under a second" mantra, but we need to think more about this as we've ended up with too many macros and much plainish C in pursuit a of a pretty functional style of command line that works fast. Please send me a private email if any one is interested in doing something open source along these lines, though the big issue for us to do it as open source is we don't care too much for non-linux platforms nor portable code as we are happiest with clean looking, "only has to work on gcc standardesish code", when we can get away with it. Always better if the code is simple, readable, habitable. I find some of the boost code is unfathomable to my small mind due to the understandably quite necessary portability macro complexity foo. The world is simpler if you live on an island with a nice beach, a single well and a single language. I choose the island. --Matt Hurd matthurd@acm.org