[CMake] Re: CMake script vs. Lua

[Brandon Van Every]

BTW it wouldn't offend me personally if you don't want to respond any
more to this *right now*.  You seem harried about other work you feel
you need to get done.  I do think "Lua boosters" need to "fan out" to
other build communities and develop more compelling arguments for why
expressive, standard languages matter.

On Dec 15, 2007 12:41 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> When compared to perl/python for text manipulation
> processing CMake is a poor choice.

That's only because CMake has a somewhat backwards regex engine.  I
don't know what other magic you think Perl, Python, or Ruby perform.
A modern regex is a modern regex.  The addition of PCRE to CMake
script would make it a much more capable text processing language.  I
don't believe in weird $_ variables for text processing.  Neither does
Python: regexes aren't core syntax, they're a library same as CMake.
Lately I believe in

  string(REGEX REPLACE
    "${regex}"
    "${replace}"
    output "${input}")

because that way, all major concerns of the somewhat complex operation
are on their own line.  If I check such a regex into source control,
then later on, I can make changes against specific lines.  Like, the
regex was bugged, but the replace was fine.  Also, frankly, my regex
and replace strings get so long that they usually need their own
lines.  Regular expression programming becomes very dense very
quickly.  It's not about having a fancy "text processing" language,
it's about having a good regex engine. The regex string is the real
program.

> http://en.wikipedia.org/wiki/Creeping_featurism

"Featuritis, creeping featurism, or the spoonerism feeping creaturism
is a term used to describe software which over-emphasizes new features
to the detriment of other design goals, such as simplicity,
compactness, stability, or bug reduction."

Using a 3rd party language promotes bug reduction, as hordes of other
people are banging on the language to make it bug free.  Python, Ruby,
and Lua are all fairly simple languages; that's part of why they're
popular.  They're all more stable than CMake script.  Having a choice
between CMake script and a 3rd party language would introduce some
instability in CMake for a time, but I see that as transitional.  Are
they compact?  Lua is, by any definition.  Embedding Python or Ruby
does have some bloat issues, but their popularity should be considered
as a tradeoff.  I'd look at how Python and Ruby are doing in the
embedded marketplace before passing judgment on bloat issues.

> http://en.wikipedia.org/wiki/Scope_creep
>
> Scope creep is a more accurate term for what is going on with trying to
> make the CMake language a competitor to perl/python.

Well, Ken already showed us a 90% acceptable Lua implementation, so
it's hard to take budgetary considerations seriously.  At least, not
to the extent of gloom and doom, if there are other positive things to
be gained.  You want CMake business in general to grow, right?  You're
willing to allocate resources towards strategic growth, right?  So to
me the question is whether they're lavish or modest layouts.  Ken's
work indicates modesty.

> As to why I regret starting this thread, I think it is a waste of my
> time. Most likely 3 or 4 bugs from the CMake bug tracker were not closed
> because I have been reading/writing emails on this thread.  As someone
> pointed out there are plenty of bugs in the tracker to fix!

Eh, you are also staunchly opposed to moving away from your language
baby.  You're the person who would take the most convincing.  I'm
impressed that you at least listen and respond to people's arguments
on the matter.  It shows that there *might* be an argument that
convinces you, but that we haven't made it yet.  You might think that
keeping your head down in the bug tracker is the most important thing
you could possibly be doing for CMake.  I don't agree.  I think being
responsive to the CMake community, particularly newcomers who are
uncertain *why* they should be saddled with CMake's various quirks, is
equally important.  I don't measure value by number of bugs fixed, I
measure it by number of users gained.  You may think you're wasting
time, but you are not: you are simply applying your time to a
different aspect of CMake's success.  CMake really wouldn't be
anywhere if we all didn't "feel the love" from you.  :-)

> Adding a whole new language would not help the build process at all,

That's what you say.  We really need the input of other build system
communities.  And, I think we "Lua boosters" have an obligation to
present that input convincingly.  We have not so far.

> It would fork the project if we
> did not support the CMake language forever.

Ok, so you want to ignore the possibility automatic translation.
Sorry, I won't let you.  :-)  "Forever" is a strong word.  Where will
CMake be in 10 years' time?  Will it be the de facto industry standard
build tool?  Or will it be an also-ran, eclipsed by other products
that invested in standard languages and automatic migration
technologies?

>  It would be classic CMake,
> and lua CMake or something like that.  Some projects would move over and
> others would keep using the old stuff.  Less of the bugs and build
> features would get implemented.

It's the same core engine regardless of the language on top of it, so
your gloom and doom is unwarranted.  I agree that you'd have less and
less incentive to improve CMake script.  I view that as sane.  Python,
Ruby, and Lua are already complete, mature languages.  They don't need
much improvement.  I'd like to remove Lua's need for quotes in certain
contexts and provide a ${table} synonym for unpack(table).

> There are plenty of important build
> features that need to be added to CMake that have nothing to do with
> language.  Those would get put on the back burner.

Again, gloom and doom about piles and piles of work, when Ken has
already demonstrated a 90% working Lua.  Sure it'll take resources,
any choice does.  But *all* the resources?  Or a lion's share of the
resources?  It's not convincing.

> And, it would all be
> done for what?  So, the language was more elegant?

So the language is more useful, more standard, more popular, more
documented, and more bug free.  I don't think we've proven the
usefulness though.

> There are some vocal
> complainers about the language, but I suspect there is a silent majority
> that really don't care,

CMake is a self-selecting community.  Those that really care, leave.
I'd like to know where they went, and what competing products they're
working on.

> and are just happy to have the software build
> correctly the first time they build it.  (I could have fixed at least
> one but instead of writing this email.... :)  ).

Short-term vs. long-term gain is a fundamental tradeoff of business.
I do agree, nobody has demonstrated anything that should be making
your alarm bells go off right this second.  You just put functions and
scope into CMake CVS and the community hasn't even tried those out
yet.  But hopefully I've painted a picture of how competitors could
stomp all over you in 5 years' time.  Or how you could stomp all over
them.


Cheers,
Brandon Van Every