[Info-vax] Programming languages, was: Re: DECUServe is a Hobbyist Chapter

[Simon Clubley]

On 2020-07-10, Arne Vajhøj <arne at vajhoej.dk> wrote:
> On 7/7/2020 8:25 AM, Simon Clubley wrote:
>> On 2020-07-06, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>> And if I were to create an accounting package from scratch, then
>>> I would seriously consider a model with some foundation in a
>>> static typed compiled language, but all the code that may
>>> require changes due to management decisions and changes in
>>> regulations in a dynamic language (like Python).
>
>> There might be an argument for supporting the easy customising of
>> front-end reporting tools, but implementing the backend in the way
>> you describe is unlikely to provide real benefits.
>
> The benefits like low LOC/FP ratio does not magically disappear
> in backend code.
>

No, but the problems to be solved in backend code are different from
those in frontend code and there are languages which have facilities
within the language to help you accurately and robustly implement the
backend code.

>> The best way to design the back end architecture is to make it as table
>> driven as possible with as little business logic embedded in the
>> actual code as possible. That can be done independently of backend
>> programming language.
>
> That is a classic approach. But it rarely works well for large systems.
>
> Configurable values that are just used as values without impacting the
> execution flow are fine.
>
> Configurable values that impacts the flow is really a form of code
> being interpreted. And that mix of interpreting code and
> "assembler style config value code" is very costly to
> maintain.
>

Have you ever tried to track changes to VAT (for example) or other
government taxes ?

Tables don't always get you all the way there, but even then, they are
a massive step towards implementing such things.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.