Post History

**Caveat**

When making a decision of such lasting impact, you should conduct your own evaluation according to the criteria that matter to you. This post does not attempt to replace such an evaluation, but perhaps highlight some things to consider, and some solutions to look at.

**Requirements**

The focus of your project is implementing a great number of business rules for a mid size financial dataset. In particular,

1. You want these rules to be **easy to maintain**
2. Since you're dealing with financial data, **correctness** is of paramount importance.
3. Since you want the option of having these rules written, or at least validated by, business people with little programming background, the language should be **easy to learn** and **easy to use correctly**

**Evaluation Criteria**

1. for maintainability
    1. ability to structure and reuse code
2. correctness
    1. test frameworks, continuous integration
    2. fixed-precision math, possibly with explicit control of rounding modes
3. easy to learn
    1. well known, widely available learning materials
    2. devoid of unnecessary complexity
4. easy to use correctly
    1. modern development environment, featuring
        1. syntax highlighting
        2. errors shown as you type
        3. code completion
        4. linting tools
        5. code style tools
    2. static typesystem to catch typos
    3. language devoid of unnecessary pitfalls that entrap newbies

**Comparision**

(in a real eval, I'd rank every solution against every requirement, but that's a bit too much work for a codidact post, so I am focusing on essentials here)

**Drools**

I have worked with Drools years ago. At the time, it offered little support for code reuse, and wasn't very good at structuring code. The development tooling was clearly inferior to a general purpose programming languages, and testing was an afterthought. Web-editor available. We replaced it with hand-written Java as soon as the customer realized they couldn't maintain the rules themselves.

**Java / C#**

Mature development tooling including static type system. Mature libraries. Established tools for testing and continuous integration. Can be a bit boiler-platey. Code easy to structure and reuse. 

Java: Fixed precision math available, but cumbersome to use.

**Python**

No comment since I have no experience with it.

**TypeScript**

Mature web-based development tooling including static type system. Decent libraries. Established tools for testing and CI. Code easy to structure and reuse. Less boiler-platey that Java; code is often more compact and readable.

**General Advice**

When evaluating a business rules language, I recommend keeping the entire software development life cycle in mind: business rules are not just written, they are also tested, versioned, deployed, documented and maintained. 

General purpose programming languages offer all that, but can be hard to get into for non-programmers.

In contrast, dedicated business rules languages are easy to get into, but offer little support to structure or maintain complex code. They are thus best suited if rules are simple, and change frequently.

Overall though, my impression is that the domain of "business rules" is not sufficiently different from general purpose programming to benefit significantly from dedicated technologies.