[Gambas-user] Financial program

[Jean-Yves F. Barbier]

Doriano Blengino a écrit :
>> Don't burry Cobol too fast: for banking *only*, this year will be around
>> 5 milliards Cobol written lines (progression is an avg of 14% per year).
>>   
> This is a proof that well designed things get a long life. Ok, cobol was 
> invented exactly for that purpose - sadness is that nobody else seem to 
> care much about those good things. And money is the gas (citation from a 
> popular rock song :-)) of the world...

This isn't really true: part of my family owns a company that sell pastry
products (additives etc), their ERP run under UNIX and VT100 consoles
and is entirely written in Cobol.
Many mid to large companies use Cobol, and have problems to find programmers
interested into this language - so there are good days left for those who care.

ADA is also growing because of its very specialized variable definitions
possibilities.

...
> You was more lucky than me, because you was replied "perhaps in gambas 
> 4"; when was my turn to ask, Benoit replied "I will not implement 
> currency type in gambas". Stop. What an irony... someone who hates money 
> and financial programs (me) has to be knocked down for a request about 
> currency...

I don't like it either, but there are places to take with good programs.

> But on the side of the possible implementation in gambas, it is a really 
> hard work. I thought a little about the question, not necessarily to 
> propose changes in gambas, but to solve the problems in my application. 
> A new class, which does rounding and formatting could work. Something 
> like "dim subtotal as new currency(4,3)" would instantiate a variable 
> with three decimals, stored as a long integer. "subtotal.picture" would 
> return a string representation, "subtotal.picture(12)" would return a 
> space-leaded string of 12 characters, with the formatted number aligned 
> to the right. "subtotal.multiply()" would multiply numbers, and so on. 
> Other methods would be required to interface to databases.
> This is the OO way to implement what nando suggested. The problem is 
> that calculi would be no more expressed in the usual, plain way, but in 
> an unnatural way: "totalinvoice=amount+vat" would turn in 
> "totalinvoice.set(amount, vat). After the first look, this could be 
> something one can live with. But overloadable operators would be very 
> appreciated to improve readability and, if impossible, compiler macro at 
> least would help. You can walk around the problem as much as you want, 
> and you finish with forcing a language to do things it never was planned 
> to do. The same as complex numbers in C - you can use them, but what a 
> bore! And, in fact, python supports complex numbers natively.

This is even more complicated - ie: fr law say that precision of VAT rates
is 4 decimals, and as I said before, some items can be invoiced with a
large number of decimals.
For VAT, more than 2 decimals had never been used but could be tomorrow;
so this is an entire int2decimal processor to write (as you wrote, no more
than 2 members to multiply because of that:(

> I must experiment a little with this idea, but I suspect that new 
> classes for every textual gui element would be needed, and it is this 
> part which scares me. I wrote some new components for this, and they 
> work, but they have some quirks I don't understand well. And... I really 
> hate accounting programs...
> 
> Uhm... I just readed back the mail about the "calculi" part. The 
> "picturednumber" class could evaluate a string... so 
> "totalinvoice=amount+vat" could be written as 
> "totalinvoice.setTo("amount+vat")... double work, but double result... 
> the only problem is that the compiler can not check for the correctness 
> of the expression. Problems again.

I lost too much time with things like that and now strongly consider
to interface all calculation to Python and only keep GB as a GUI.

This shouldn't add that many things to the system: as of Linux, Python 
is a std install, as of Debian, this will only require a few packages 
to add (AND it'll solve docs templates, PDF generation and some other 
dead-ends)

Regards,
JY
-- 
Don't get even -- get odd!