Reporting system - declarative

John Ralls jralls at ceridwen.us
Thu Nov 17 15:27:49 EST 2011


On Nov 17, 2011, at 10:02 AM, Donald Allen wrote:

> On Thu, Nov 17, 2011 at 1:50 AM, Derek Atkins <warlord at mit.edu> wrote:
> 
>> Donald Allen <donaldcallen at gmail.com> writes:
>> 
>>>> (cond ((> x 5) (fun a b))) ;; I won't even attempt to properly indent
>> this
>>>> in gmail
>>>> 
>>>> vs.
>>>> 
>>>> if x > 5:
>>>> 
>>> 
>>> I'm not sure how I fat-fingered this, but the message got sent
>> prematurely,
>>> destroying my credibility:-)
>>> 
>>> Anyway, you get my point -- writing that conditional in Python or C looks
>>> more natural to people and so they prefer it to Scheme/Lisp on those
>> narrow
>>> terms, forgetting what working in Scheme buys you (personally, I'm more
>>> productive in Scheme than any other language, and I've written code over
>> a
>>> long career in most of them; Python is also a strong contender in the
>>> productivity dept., but there's a lot more to learn and keep in mind than
>>> with Scheme; it's a much more complex language, even though the code
>> looks
>>> simple).
>> 
>> Um, I don't see a *HUGE* difference between:
>> 
>> if (x > 5)
>> {
>>  if-clause ...
>> }
>> else
>> {
>>  else-clause ...
>> }
>> 
>> vs:
>> 
>> (if (> x 5)
>> (if-clause)
>> (else-clause)
>> )
>> 
>> To *my* eyes they look very close (modulo the x > 5 vs. > x 5)
>> 
> 
> Yes, that's true. There *are* things in Scheme that look much like C or
> Python and 'if' is one of them, which is why I chose 'cond' and not 'if'
> for my example. But despite that overlap, I think there's enough in Scheme
> that looks weird to people used to other languages (you identified one of
> them -- infix vs. prefix in predicates and also the obvious -- use of
> prefix notation in arithmetic expressions) that they reject it on what I
> would consider much too narrow grounds, failing to carefully weigh the
> advantages against the perceived disadvantages.
> 

Which is a fine argument when discussing a language choice for developing a project with a professional team.

It's not such a good argument when the team will consist of volunteers who must be recruited from the already small pool of programmers who are willing to contribute time to open-source projects and for whom there is tremendous competition from thousands of other projects using more conventional languages.

It's an absolute non-sequiter when the language choice is for a scripting language to be used by non-programmers, particularly when the scripts are needed for such an important role as report customization. In that case, the closer the scripting language is to "natural" languages, the better.

Regards,
John Ralls




More information about the gnucash-devel mailing list