What's your favorite year end method?

Mike or Penny Novack stepbystepfarm at mtdata.com
Thu Dec 27 14:39:38 EST 2007


>>I think this is a good debate to have, but may I suggest we stand back and
>>look at the requirements before we start pushing specific solutions.
>>
>>>From my point of view, I think it would be nice if we could give much more
>>control to the end-user without resorting to programming languages at all. Of
>>course this is easier said than done, but it might be worth seeing what's
>>available in other, similar, systems and borrowing some of the better ideas.
>>
>>Of course more advanced reports will always require some programming.
>>
>>    
>>
Always a good idea to start with requirements. Especially as in this 
case it might eliminate the the "language" question.

A good programming language makes it easier for PROGRAMMERS to get it 
right, to correctly code a program to do what they intend, perhaps even 
to relieve them of knowing to code the nitty gritty routines that 
process the sorts of (abstract) data structures natural to the problem. 
But no programming language can ........

a) Tell a programmer how to approach a problem, what data structures are 
natural to the problem in front of them
.
b) Tell a NON programmer what he or she should do in order to solve a 
problem. Now don't misunderstand what I am saying here because I am not 
talking about job titles but skill sets. In other words, if given a 
"problem" you would be able to select an appropriate solution, to break 
that solution down into manageable pieces, to utilize the sorts of 
abstract data structures natural to the problem, then you ARE an 
"analyst" and if you can then correctly translate that design into an 
implementation in code, then you ARE a "programmer".

It's not language that matters much. The only thing that could possible 
teach non programmers to write custom reports would be a tutorial on 
"writing custom reports" with a great many examples each beginning with 
"here's what you want; here's how you DESIGN that" and then continuing 
with that example "and now here's how you code that design in the custom 
report language" (whatever that might be). Understand? It's only the 
"coding" part of the tutorial which depends upon the language which does 
reports. One might even break that tutorial into sections to emphasize 
that "design comes first" (say each example first does design that ends 
with "jump to page xyz to see how to code this".

Michael




More information about the gnucash-user mailing list