From: Francis Hwang <sera@...>
Date: 2005-02-05T10:26:33+09:00
Subject: Re: [ANN] LXL (Like Excel) 0.1.0 - A mini-language that mimics Microsoft Excel formulas.

Huh. So you've got another example of a domain-specific language, and 
somebody else using Ruby might've chosen to use in-Ruby features to 
allow employees to write business rules. Maybe something like:

add_rule {
   notify_supervisor if @expense.office == 'HQ' and @budget.remaining < 
500
}

Which, on some aesthetic level, might be better than representing it 
with Excel's function syntax, but then maybe that's moot if your 
coworkers are familiar with Excel. It never ceases to amaze me how 
people can become power users of complex software like Excel or 
FileMaker, but some of them get quite flummoxed when they're presented 
with similar concepts expressed with different syntax. Maybe that's the 
difference between a programmer and a power user.

Anyway, not meaning to criticize your decision; I probably would've 
done the same thing in your situation. I just find it pretty 
interesting. It's almost like it might've better if your coworkers had 
been trained in Ruby to start, instead of Excel. Also makes me think 
about how Ruby could take over the world if it had products like Excel 
or FileMaker that used Ruby as their native scripting language ...

On Feb 3, 2005, at 9:55 PM, Kevin Howe wrote:

>> Pretty interesting. So why did you write this? Did you have particular
>> applications in mind? Would LXL be suitable for, say, exporting the
>> logic in an advanced Excel spreadsheet into something in Ruby?
>
>> Pretty interesting. So why did you write this? Did you have particular
>> applications in mind? Would LXL be suitable for, say, exporting the
>> logic in an advanced Excel spreadsheet into something in Ruby?
>
> Hi Francis,
>
> I developed it to allow customer-defined workflow rules for their web 
> system
> (an HR/Purchasing system). For instance, when a purchase order is 
> submitted,
> different things happen depending on:
>
> - what office is was submitted from
> - what employee submitted it
> - what permissions the employee has
> - the amount of the purchase order
> - the type of the purchase (bi-weekly/monthly, office 
> supplies/consumables)
> - etc.
>
> Rules are applied to these criteria to decide what happens next:
>
> - are they over budget by more than $1000? Deny it.
> - are they under budget by more than $500? Approve it.
> - if submitted from head office, submit to a supervisor for approval.
> - etc.
>
> These rules were hard coded at first just to get things going, but 
> these
> factors are constanly in flux so they needed to be controlled at the
> user-level. Ex: Last month those rules were fine, but this month one 
> of the
> offices needs to be able to purchase without a limit, another office 
> needs
> to be auto-approved for office supply purchases, but still limited for 
> all
> other purchases. A supervisor has gone on vacation for two weeks, and 
> for
> that period all approval requests should be sent to another supervisor
> instead. The kinds of rule-changes are constantly happenning and need 
> to be
> put into effect immediately - they can't be calling an IT person for 
> every
> change. The solution was to allow them to program these rules 
> themselves,
> using a limited but user-friendly language. Excel formulas were the 
> ideal
> choice in this case because the entire company is already intimately
> familiar with what they are and how they work. LXL provides the basic
> language, the parsing and the basic functions (math operators, 
> if/and/or
> conditionals, date/time, etc). Then you extend it with your own custom
> constant values and functions. You might have something like
> IF(AND(OFFICE="HQ",REMAINING_BUDGET<500)) for instance.
>
> That's the general idea ;)
>
> Regards,
> Kevin
>
>
>
>

Francis Hwang
http://fhwang.net/