[CMake] Re: CMake script vs. Lua

[Brandon Van Every]

On Dec 14, 2007 4:55 PM, Rodolfo Schulz de Lima <rodolfo at rodsoft.org> wrote:
> Brandon Van Every escreveu:
>
> > I'm not willing to concede the clarity.  As I just wrote, "backwards
> > compatibility" is an issue to solve, not a dealbreaker.  As for labor,
> > there's already a quorum of people interested in the issue, and CMake
> > forks have been threatened before.  I'd like to see people identify
>
> When I meant *fork* I didn't mean to threaten anyone.

That's fine; I don't want to put words in your mouth.  But recently,
someone did threaten a fork.  They had an energetic mission statement
about improving the language.  My response was, that's great, but what
resources do you have to put behind it?  His response was admittedly,
not many, and mine was well, then nobody's gonna follow you.  I'd like
to see the "renegade improvements" energy ploughed back into the CMake
community somehow, because Kitware is still clearly "the winning team"
that people are going to follow.  Most of my concerns about nicety of
language are strategic, not tactical.  I just don't want people to
pooh-pooh the numerous complaints that developers make about the
language.  Strategically, it's too important and recurrent to ignore.

There's a whole 'nother tack that one could take about this stuff.
That the language is good enough; it's the documentation which lacks.
And that furthermore, tutorial technologies could be more impressive.
I wonder what it would take to devise a shell that teaches you the
language as you attempt to program it?  Or is something of an expert
system regarding common CMake mistakes?  The idea: perhaps the
language is not the strategic problem.  It's new developers bitching
and moaning about the language that's the strategic problem.  So how
many ways are there to reduce bitching and moaning?  Exotic tutorial
technologies and help systems might be an answer to that.

> Now, to argue the problem of
> 'backwards compatibility', first we have to decide if changing to Lua is
> really needed.

I agree.  In fact, I think we also have to decide if Lua is the
correct strategic answer for whatever the "needs" are.  In our last
round of debate, Lua came up as the winner due to licensing and
embedding issues.  But strategically, looking at a 5..10 year planning
horizon, would CMake be much better off to attach itself to Python or
Ruby's coattails?  Tactically though, Ken proved that bolting Lua onto
CMake is quite doable.

I think we have to go explore the other build systems and find out
what they do better.  I don't think we've really done that.  I don't
think that kind of information has been brought to the debate.

> At first, I'd like to
> change because I know Lua and is not cryptic (as, for instance, jam is
> for me). But that don't suffice.

I think the marketing benefits of Lua are pretty clear.  Python or
Ruby would be even better.  Both are more of a PITA to embed though.
Python's license is pretty clean, it just requires comments on what
you changed.  Ruby has an obnoxious Perl-style "Artistic License."  It
would force CMake to ship with the original Ruby, if CMake were to
modify Ruby in any way.

The problem is, when I talk to most open source developers about
marketing imperatives, it falls on deaf ears.  The idea of growth in
order to make lotsa money doesn't inherently appeal to them.  In the
Windows commercial world I could make an argument like, "this choice
of language will give all the Suits a warm squishy feeling.  The
language is perceived as a safe choice.  If we use their perceived
Best Practices, CMake will take over the world and we'll all become
rich and famous."  That kind of argument would be taken seriously.  It
might come close to ending *all* argument as far as strategic course
of action.  But when I make this kind of argument to non-business
oriented techies, they make vampire cross fingers at me.  They want
success to flow from either a technical meritocracy or egalitarian
open source principles.  Making money "the Microsoft way" is something
they hate, and they often lack the concept of "fighting fire with
fire."

I don't think Kitware is guilty of this.  I just think their business
pragmatism is focused too much on short-term needs (or lack of need),
rather than long-term world conquest.  My perspective is different.
CMake has the stuff to be "world class."  To achieve it, it just needs
some bolt-ons that are common in the big bucks computer industry.  I
make more money if CMake is more popular.  I don't have to keep
ditching my skillset, i.e. learn other build systems, if I can
convince the world to use *my* preferred build system.  That's more
profitable for me personally, to be a guru of "the best" build system,
rather than the lackey of countless Dilbert decisions about many
sundry build systems.

Let's put it this way.  If Google bought the CMake side of Kitware's
business, they'd document it, bolt Python on it, and call it good.  I
say "What would Google do?" rather than "What would Microsoft do?"
because the latter is the wrong role model for open source.  Microsoft
would make us script everything in C#.  :-)

> > I agree that Kitware hasn't been persuaded of the value of using a 3rd
> > party open source language.  But why should we stop investigating at
> > their say-so?
>
> Sure, we can do whatever we want, EXCEPT trying to push Lua into CMake.
> I don't think it's fair with kitware because they're supporting an open
> source project, donating their work time to something that everyone can
> have profit, the least we can do is respect their position.

"Fair?"  [Warning: long soapbox alert!]

Kitware ain't in this for religious zealotry, they're in it because
the open source business model works for them.  If I thought I could
make lotsa money setting up a Mercurial repository, mirroring CMake
sources, modifying them to embed Python, Ruby, or Lua capabilities,
supporting that, and hawking my contractor services based on that, I
would.  And I might!  But my mission first and foremost is to make and
sell games.  This build system stuff is merely something I've
unwittingly gotten good at, because there are so many bad open source
builds out there.  Lately, build systems are paying my bills, not my
game stuff.

My point is, I'm merely balancing my financial self-interest.  So is
Kitware.  That's what MIT/BSD style open source development is all
about, as far as I'm concerned.  If you want everything to be "fair"
in some kind of communist, never step on anyone else's toes sense, you
probably belong in the "Free Software" GPL/LGPL crowd.  Even in that
arena, the split between GNU Emacs and XEmacs is famous.  Perhaps it's
precisely because people were trying too much to be "fair," instead of
having scope to pursue their own personal profit incentives, that the
split occurred.  I see MIT/BSD development as a federation of
developers trying to make money in their own various ways.

I give plenty to the CMake community: bug reports, the occasional
documentation fix, testing, and tons of help to newbies.  I've
certainly "paid for" what I get from CMake, in the open source sense
of quid pro quo.  I don't need a GPL/LGPL shackle to force me to do
it, either.  I don't help people solely to help people, I also do it
to (1) keep my own skills in shape, (2) advertize that I do indeed
have those skills, if people want to pay me for them.  I think people
who want to make money have plenty of reasons to pool resources,
without being contractually obligated to provide various things.

One thing that my current project has taught me, is that there's money
in transforming huge legacy build systems.  I'm just irked that I'm
using a substandard technology to do it: straight CMake regular
expressions.  I keep thinking there's gotta be a better way to do
this, there has to be more to the world than regular expressions.  But
I don't have time to figure it out right now, I have to finish my
current project.  After that, well then I can do R&D on what "better"
language transformation technology would mean.  And you know what?  If
I find some really compelling answer, I'm not going to think about
what's "fair" to CMake.  I'm going to think, "I've found a way to make
converting CMake script to Lua script a trivial proposition.  It's
worth money."  Then I'll just go make money.  I mean, come on, "we
have to support CMake script forever"... what's one more build system
conversion?  Converting build systems is clearly where the money is,
so just devise a better conversion technology and convert them
already.

A backgrounder on where this heresy is coming from: I was involved
with the so-called "Functional Programming" community for several
years.  I probably had the wrong reasons to be interested in it, but
in the course of pursuing it, I learned about metaprogramming and
program text transformation.  Oddly, nothing in the FP community or
game development made me into a metaprogrammer.  Converting build
systems did.  I'm currently at the fairly primitive stage of just
using regular expressions for everything.  I know that more is
possible.  So why not keep going?  Why do choices like CMake script,
Lua, Python, or Ruby have to be a big deal?  A metaprogrammer doesn't
get stuck in one syntax, a metaprogrammer can do whatever the heck he
wants.  Regular expressions are an insufficient transformation
paradigm, however.  I need something better.

Transforming back into "ordinary marketing land," where nobody knows
how to do anything except in the language they already know, the
choice of language strikes me as a marketing choice.  Serious
academics deride things like Python and Ruby, because they have
contributed absolutely nothing to the understanding of programming
languages.  They are syntactic sugar, and as far as the language
academics are concerned, their authors are rank amateurs.  Of course,
more pragmatic people will point out the value of industrial
implementations, marketing, community adherence, lotsa libraries, etc.
 The academics bemoan that the language with the most libraries wins.
:-)

Perhaps along with metaprogramming needs to go "metaeducation."  That
is, getting someone who knows Scripting Language #1 to learn Pretty
Similar Scripting Language #2, without a lot of bitching and moaning.
Exotic expert system tutorials as you program, etc.  I wonder if
there's money in that?


Cheers,
Brandon Van Every