lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Warning - long posting ahead.

steve donovan wrote:

Well, now I have some incentive.  There are lots of useful little
functions (which can be used by other projects) which need a few
friendly lines of comment each.  And any program which (ab)uses
globals so much must be particularly careful...

Some suggestions/questions: have you considered to put (some) identifiers in a "namespace"? At least those that make sense: I find the "declarative" syntax c.program{'hello'} very nice and readable, but probably Lake.copyfile('a','b') would be better than simply copyfile('a','b'). I think it would increase readability in more complex lakefiles, where stock Lua facilities could be used more extensively.
Moreover it would be better when using Lake as a Lua library.
I *love* this idea of using Lake both as a build framework and a Lua library, but as you say below, it is a big "beast" so maybe it could be split in different submodules:

require 'lake' -- the framework, as it is now
require 'lakelib' -- general utility functions
require 'lakefoo' -- whatever etc.

Some other point: would you consider renaming some functions for readability's sake? Or it is too late in the development process?

I think that a slightly more verbose style could help in readability, especially those pople with little 'makefiles' or C/C++ experience.

For example "CC" means "C-compiler" only for somebody. Maybe being more explicit could help more people read Lakefiles (and customize them): "C_COMPILER" (or something like this) would be better (and reduce conflicts with user-chosen identifiers, CC is far too short and cryptic).

Same rationale for (eg.):

MSVC --> USE_MSVC_COMPILER or USING_MSVC_COMPILER (sorry, didn't have time to investigate further the usage)

I know this could be a bit painful for writing things on the command line, but in bigger lakefiles, maybe cross-platform/cross-language/cross-system/cross-team/cross-task (hope Lake gets there :-) ), it could be much more readable.

I think that key for Lake success and widespread adoption is to appeal to a wider audience: who knows? Game scripters for WoW wanting to postprocess some game data? Scientists using Lake to drive a pipeline of programs in different languages to process a stream of data off-line? Web-developers wanting to convert hi-res images to low-res thumbnails?

This could also foster a more widespread knowledge of Lua!

Is very intriguing to think Lake to become (with time) what you seem to envision with:

"There is probably a compact and elegant dependency-driven programming framework hiding inside Lake, in the same way that the proverbial thin person lives inside the fat couch potato."

To achieve that I think that a less "system-programmer-centric/I-know-all-compiler-flags-by-heart" approach is needed, otherwise it could only become a better 'make' (not a little goal by itself, but why limit oneself... :-) )

Lake is biased towards C/C++.  I've looked at the issue of doing
Java-style compilations and what Lake needs is a few generalizations
so that different tools can be easily integrated and made available as

I have a dream: one day we will ditch both 'make' and 'ant' in one blow :-)
I hope 'Lake' could make that day closer! :-))

Ant is actually well designed - pity about the XML. I agree with Guido
van Rossum that XML should not be written by people.

I was too hasty indeed, and not clear enough. I think Ant's facilities are quite good, but for me there are two drawback:

1.syntax (I agree XML is a pain for humans!)

2.(worse, to me) too little focus on imperative facilities. I think humans are more naturally inclined to think imperatively. Declarative syntax is not always the best thing: yes, some tasks are elegantly expressed in a declarative way, but others are utterly unreadable (especially for people with no high-level math background: try to explain recursion to non-programmers/non-scientists and see!!! :-) )

A well and carefully balanced mix of both syntax styles is the best way to go (_you_ choose how to express things according to the problem at hand and according even to the people who are going to read the code).

That's also why Lake looks very interesting to me (and smooth integration with Lua especially)!

Thank you very much for your efforts!

-- Lorenzo