On Dec 14, 2007 4:55 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
