>> Are you saying that you're creating some kind of stand-alone variant of
>> VBA?

Unfortunately most people think the words 'Excel' and 'programming' must
equal VBA. I spent a lot on a book called Professional Excel Development
which hardly mentions Excel itself. I think however in ome circumstances
VBA functions may have to be used eg to call realistic SOAP services.
The key is to keep them as functions ie no calling and waiting. They
should look exactly like in-built functions. Also the accomplished S#
programmer only uses them as a last resort.

>> it's three metric tons of VM-like overhead

but seems to load faster than Ruby

> I believe he means that Excel is a processor for dependent formulas
> which, by virtue of update event propagation, gives you instantaneous
> value updates in all relevant places.

Succinctly put


>> Maybe you'd like working with a database management system that offers
>> some kind of stored procedures or triggered functions capabilities more.

Your remark is highly relevant. Tedd Codd deliberately designed the
relational model to eliminate the requirement to describe process. SQL
is a very powerful functional programming system. Stored procedures
however are usually...procedural.

>> Excel is to DBMSes as those old Power Wheels toys are to actual cars,
>> after all.

I suspect you can do a lot of real world 'database' processing in
Excel -just like some folks use ActiveRecord (no - don't start me off on
ORMs...). On that basis, I guess a simple web site could use a lot of
functional programming functions without resorting to DBMS facilties.

As I said earlier, one of the attractions is you have to think
differently.

-- 
Posted via http://www.ruby-forum.com/.