Re: [Boost-build] Son of b2 - suggestions

Subject: Re: [Boost-build] Son of b2 - suggestions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-11-02 07:27:49

> -----Original Message-----
> From: Steven Watanabe [mailto:watanabesj_at_[hidden]]
> Sent: 31 October 2016 16:41
> To: Boost.Build developer's and user's list
> Subject: Re: [Boost-build] Son of b2 - suggestions
> 
> AMDG
> 
> On 10/31/2016 10:18 AM, Robert Ramey wrote:
> > On 10/31/16 5:05 AM, Klemens Morgenstern wrote:
> >> Imho b2 failed because the documentation is not nearly detailed enough,
> >> the language is strange and building extensions is painful. Not as
> >> painful as using CMake, that's why I'm doing it, but it still feels like
> >> masochism. The real limit of b2 is constituted by it still using jam,
> >> and all other (except for the documentation) come from that.
> >
> > Oh - no problem - just enhance the documentation and problem solved.
> >
> > Of course this is not going to do it.  The problem is what if one writes
> > a program which requires pages and pages of arcane documentation to
> > describe it, you've done something wrong and need to step back an see
> > what it is.  That "something wrong" is usually that the "language" has
> > no rime or reason - it's a grab bag of features each with it's own
> > syntax, which are coupled together in unexpected ways.
> >
> 
>   The Jam language itself is actually extremely simple.
> The complete yacc grammar is less than 200 lines
> of code.  (337 lines including all whitespace,
> comments, and scaffolding.)  The documentation
> here is pretty complete as well:
> http://www.boost.org/build/doc/html/jam/language.html

Well that's good for the language writer and keen user, but I feel that the main problem for most users is that bjam syntax is just
not *intuitive*. (Some aspects like the use of layout as keywords is positively counter-intuitive and trips up most users - Paul
Dirac might have said it was "Not even Daft").

Now you will probably ask why *this language* needs to be intuitive.  Well I think that it is because most users are not really
going to write in it, they are just going to read it to understand what is happening, and perhaps tweak a little.  And they only get
to tangle with it when things are already dysfunctional. The last thing they want is yet another ***** language.

If you main users are doing C-ish stuff (and that includes C++, Java, .net .. Python and FORTRAN even) then it should *look like* a
C-ish procedural language, even if it isn't.  It should minimise what you need to 'Just Know', or RTFM to find out.

HTH

Paul