Re: [boost] Universal user interface based only on C++ standard libraries

Subject: Re: [boost] Universal user interface based only on C++ standard libraries
From: Matt Hurd (matthurd_at_[hidden])
Date: 2009-06-30 22:18:10

2009/6/26 Jonathan Enders <jenders_at_[hidden]>
>
> <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_at_[hidden]