Re: [Boost-build] naive usage of bootstrap.sh

Subject: Re: [Boost-build] naive usage of bootstrap.sh
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-10-24 12:08:20

On 10/24/16 8:03 AM, Vladimir Prus wrote:

>> a) small prototype
>> b) with it's own manual
>> c) subjected to test by naive but not dumb volunteers
>
> If you volunteer, I'll count you in.
>
>> d) who try to use the product by following the instructions in the
>> manual.
>> e) and record their experience as they go
>> f) so the developers can make something that is easy to use.
>> h) as a means to keep product design on the right track.
>>
>> Of course I think many, many programmers efforts could benefit from this
>> type of prototyping.  But I realize that many development teams feel
>> that they don't have enough time to do this.  Of course I think they're
>> wrong - but that's only my opinion.

> I think you're effectively suggesting doing usability testing for non-UI
> things, which is a good idea, but I don't know if anybody
> has ever successfully recruited volunteers to do this.

TL;DR;

That's an interesting way of putting it.  But what I think what really 
happens is:

a) developer comes up with the latest cool idea.
b) like all ideas - the initial version is pretty half baked.
c) Then - since he loves coding - he writes code
d) But he hates all the other stuff which makes a good program - writing 
the instruction manual, getting feed back from people who aren't willing 
to read his code etc.
d) So he "puts it out there" and asks for feed back.
e) The feed back he gets from other coders with whom he argues about 
what the thing actually does or should do.
f) then things sort of peter out when it gets really tedious and 
everyone moves on to something else.

This doesn't sound too good.  Still, it's better than another popular 
alternative.

a) someone comes up with the next cool idea and put's it "out there"
b) people chime in and "improve the idea".
c) a large discussion ensues related to what language it's going to be 
programmed in, all the features that this cool idea has to have.
d) some sort of concensus is reached
e) one sucker starts to code but eventually has to give up when it 
becomes apparent that the project goals are hopelessly contradictory, 
ambiguous - another dead end.

What I would like to see is

a) someone has a the new latest cool idea.
b) they make the simplest possible version which someone could find useful.
c) they write user manual to describe:
i) what it does
ii) how to use it to do what it does.
iii) what it doesn't do
d) put it out there and encourage people to use it.  In the context of 
boost build would be something that ... - I'm not sure.  But it would
i) do something useful
ii) not have any bugs
iii) be easy to figure out how to do it.

The leads me to speculate a little on b2 version - code named beaver.

a) beaver is language which specifies rules for transforming one set of 
files into some other set.  Sample applications would be:

i) generating ide files from some program source files
ii) generating exectuable or libraries from some source files.
iii) generating pdf files from source xml, or other source files

b) General principles

i) a beaver script can be composed from other beaver scripts
ii) a beaver script might be just a couple of words.  This is so that 
anything in a script can be in a command line and vice-versa
iii) there is no "hidden" information.  All understanding of what a 
script does can be discerned from reading the script.
iv) If a beaver script cannot be executed  for any reason - it aborts 
with an error message and perhaps a helpful suggestion.  Specifically, 
it does not try to "guess" or "do the right thing" or search the file 
system or anything like that.  It either works, or fails with an error 
message.  That error message should also suggest a course of action and 
it should also include something like a "stack trace" as beaver is a 
recursive language.

At this point it looks pretty much like make and Makefile.  Which raises 
the question - why not see how far one can go with Makefiles.  Now there 
are some well known issues with makefiles - principly nesting make files 
seems to be a problem - which beaver specifically encourages.  I don't 
really know about this.  Then there is the question of "beaver 
functions" which is where the trouble/fun begins.  At this point the 
scripts become too complex to understand and trace through.

It's also very possible that beaver might look a lot like b2 remade 
according to the general principles above.  In fact, I think that this 
is actually the case.  I think the problem is that the b2 language / 
implementation where developed code first rather than the way I suggest 
above.  Perhaps one might want to start with b2-lite - which starts with 
the language and just adds in the minimal to do something useful. Then 
it could re-add in functionality as needed following the above principles.

Note that I haven't talked about what language would be needed to 
implement it.  I don't think the problems of b2 are really related to 
the bjam language.  That is not to say, it's the best choice - 
especially given hindsight.  But I don't think that is the obstacle.  If 
I had nothing else to do, I'd be curious to see what would happen if I 
used C++ with a "build library" as the scripting language.  Basically, 
I've come to appreciate more and more the power/opportunity of the C++ 
type system to improve my thinking about complex problems.

It's an interesting subject - and in 50 years no one has been really 
able to crack it.  Make is still pretty good - but with projects getting 
so big and using so many other components - the job is much harder.

Sorry for the rant-like quality of this post.

Robert Ramey