[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: CMake and Lua
- From: "Eric Tetz" <erictetz@...>
- Date: Thu, 14 Feb 2008 15:48:19 -0800
On Thu, Feb 14, 2008 at 4:53 PM, Eric Tetz <erictetz@gmail.com> wrote:
> Why would they need to? They don't have to solve general purpose
> programming problems, only their tool's problems.
The paragraph I was responding to:
"We did all have it out recently that some kind of scoping is
required, that having everything as a global variable is not enough
anymore. That's in CMake CVS and people are shaking the bugs out of
it. CMake 2.6 will have function calls with scope available, so that
you don't have to use plain macros if you don't want to. Kitware's
attitude is that they will continue to improve the language as
needed."
That just reminded me of Stallman's article, about the lessons learned
with Emacs: (to paraphrase) "[Tool X Script] should be a real
programming language, designed for writing and maintaining substantial
programs. Because people will want to do that! [Tool X scripts] are
often large, complex programs in their own right, and the people who
write them deserve the same facilities that other programmers rely
on."
So I'm not suggesting CMake should switch to Lua, or even than it
should have been created with Lua. I was just making the *general*
observation that tool builders should think twice before creating
their own language, however minimal their needs of the moment are,
because users will inevitably ask more of it than the author
originally intended. Hopefully we can agree on that, given that it's
Lua's entire reason for existence. It's the reason you might use a
language as powerful as Lua merely as a configuration language: future
proofing, so you don't end up 7 years into development still sweating
your language design.
Cheers,
Eric
- References:
- CMake and Lua, Ken Martin
- Re: CMake and Lua, Brandon Van Every
- Re: CMake and Lua, KHMan
- Re: CMake and Lua, Brandon Van Every
- Re: CMake and Lua, E. Wing
- Re: CMake and Lua, Brandon Van Every
- Re: CMake and Lua, Eric Tetz
- Re: CMake and Lua, Brandon Van Every
- Re: CMake and Lua, Eric Tetz
- Re: CMake and Lua, Jean-Claude Wippler