Full stack Java, JavaScript / TypeScript

We make a Configure-Price-Quote SaaS for complex product portfolios. For example, one customer is Tetra Pak, that sells machines that build packaging (milk, juice, etc). These machines are like a two-story building with many variations, every aspect has to be well-defined and validated before it's ordered.

In our solution products can be modeled in detail with constraints, and during a sale options are chosen and validated, often visualized parametrically, pricing is done, and a quote is prepared. All based on the well-defined model.

It's a 30-year old company that started as a research startup, grew organically, and has a stable customer base. After a recent acquisition it's aiming to grow, therefore many positions are open. I started working here just a year ago, but I can say the work environment is healthy and relaxed, lots of competent people and everyone I interacted with so far have been very nice and professional.

Senior Software Developer https://careers.tacton.com/jobs/5313129-senior-software-deve...

Technical Lead https://careers.tacton.com/jobs/5591471-development-lead

Technical Frontend Architect https://careers.tacton.com/jobs/5714212-technical-frontend-a...

Technical Enterprise Architect https://careers.tacton.com/jobs/5591490-technical-enterprise...

More generally there are the theorem provers like Coq, etc., but their use cases are even more specific.

Also, the experiment method has some flaws. Problems are hand-picked out of a random subset of the full set. Why not run the full set?

Also, the point of the visitor pattern is not just pattern matching/polymorphism. Of course you could do it with polymorphism or conditionals or whatever. But the visitor pattern reduces coupling and increases cohesion. So you get a more maintainable, testable code base. Pattern matching with a candied switch doesn’t give you that.

- infinite data defined by recursive predicates

- flexible data structures (think JSON but better, called complex terms) and a way to query them (called unification algorithm)

- execution strategy fine-tuned for reasoning (called resolution algorithm). You can do this with SQL but you’d have to formalize things using set operations and it’d be very very slow.

On the other hand, SQL can query plain data very very fast.

- no proper module nor package system in the modern sense.

- in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided unification guards which tackle this to a degree.

- lack of static and strong types makes it harder to write robust code. At least some strong typing would have been nice. See Mercury as an example of this.

All being said, Prolog is amazing, has a place in the future of programming, and gives you a level-up understanding of programming when you get how the types in every OO program is a Prolog program itself.