Re: Lake

[Lorenzo Donati <lorenzodonatibz@...>]

Warning - long posting ahead.

steve donovan wrote:
[snip]
> 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.):

CXX  --> CPP_COMPILER or CPP_COMPILER_PATH
FC  -->  FORTRAN_COMPILER
WINDOWS  --> PLAT_IS_MSWINDOWS
DLL_EXT  --> SHARED_LIB_EXT
EXE_EXT  --> EXECUTABLE_EXT
LUA_INCLUDE  --> LUA_INCLUDE_DIR
LUA_LIB --> LUA_LIB_PATH
STRICT  --> STRICT_COMPILATION
DIRSEP --> DIR_SEPARATOR
NODEPS --> NO_AUTO_DEPENDENCY
DEBUG  --> DEBUG_BUILD
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
> modules.

> > 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