Well, you still write code. The difference is the code is written either in ordinary Python or Java and not as mathematical equations.

For example, to do the "Some employees are qualified to do either role, but others can only be a cashier, or a restocker." constraint in the article, it would be written like this:

  def required_skill(constraint_factory: ConstraintFactory):
      return (constraint_factory.for_each(Shift)
              .filter(lambda shift: shift.required_skill not in shift.employee.skills)
              .penalize(HardSoftScore.ONE_HARD)
              .as_constraint("Missing required skill")
              )

Some examples taken from Timefold quickstarts:

- Employee scheduling (https://github.com/TimefoldAI/timefold-quickstarts/tree/stab...)

- Vehicle routing (https://github.com/TimefoldAI/timefold-quickstarts/tree/stab...)

- School timetabling (https://github.com/TimefoldAI/timefold-quickstarts/tree/stab...)

Great to see this math being made more accessible!

The Python examples seem to have a very strong Java smell. That might just be my prefer for functional styles over OOP styles though.

Let us know how we can improve! Feel free to start a discussion (https://github.com/TimefoldAI/timefold-solver/discussions) or submit an issue (https://github.com/TimefoldAI/timefold-solver-python/issues).

We aim to treat Python as a first-class citizen (while keeping it maintainable). For instance, many of the Java methods are mapped to properties on the Python classes with more Pythonic names (see `ScoreExplanation` for an example).

I suspect what gives the Java smell is probably the `SolverFactory`/`SolverConfig`, which is a lot of boilerplate code. A lot of the code can be generated, although we would need to design an API for that.

The fluent (method chaining) API might also be giving the Java smell; I don't see many fluent API being used in Python. In particular, needing to either end lines with `\` or surround the statement with brackets make long fluent chains annoying to use. This is harder to change, since there is no Pythonic alternative that I know of for method chaining.

Langchain did something overloading the | or operator in their LCEL DSL to form LLM pipelines. It feels like abusing python but it's familiar enough as a Unix syntax

Does

  constraint_factory.create_from_chain(
      ForEach(Shift)
      | Filter(lambda shift: shift.required_skill not in shift.employee.skills)
      | Penalize(HardSoftScore.ONE_HARD)
      | AsConstraint("Missing required skill")
  )

Feel more Pythonic than

  (
      constraint_factory.for_each(Shift)
      .filter(lambda shift: shift.required_skill not in shift.employee.skills)
      .penalize(HardSoftScore.ONE_HARD)
      .as_constraint("Missing required skill")
  )

?

Knapsack problems, some simple scheduling problems, even the travelling salesman problem.

Many problems in business and manufacturing fit this bill. Optimal product mix, optimal routing, choosing the best spot for a warehouse, scheduling employees, constructing an investment protfolio, coming up with a diet that fits certain criteria, etc.

I even remember a practice problem from uni where we had to optimally distribute songs on two sides of a tape album (it was an old professor), satisfying constraints such as “each side should have a ballad” and “each side has at most x minutes of running time”.

You can do this with regular coding too, but if you can easily construct a certain kind of mathematical model of your problem, you can easily solve it with linear programming.