that’s pretty exciting! i was just this weekend looking at the oz/mozart home page, wondering if the language were dead or not (i wanted to use it for a small project, just to play with it, but concluded that it did indeed look unmaintained)
I use Mozart/Oz in projects and help keep the bitrot away from the 1.3.x and 1.4.x versions. The Mozart 2 version runs but is lacking features - distributed objects and constraints being the most notable. I feel like there needs to be a “1.5” interim release, maintained and with binaries, to show activity.
The project tends to suffer from being used as a university/research project. People do work on masters thesis to contribute a feature to it, then they disappear and that feature doesn’t get maintained, extended, made production ready, etc.
i should have known that if anyone was using it you would be :) do you have a more recent version of 1.4.x than the one in the repo, or have you been pushing all your changes?
I’ve pushed all my changes so it should build on Linux at least. I recommend using the 1.3.x branch as 1.4.x has some annoying bugs. Distributed search is broken, distribution statistics don’t work, due to a switch to a C++ based library to do object distribution and bugs didn’t get ironed out. It only matters if you plan to use those features though. I’ve backported some of the actual bug fixes from 1.4.x to 1.3.x.
Originally I wrote a bitcoin mining pool using Mozart/Oz, before transitioning it to ATS. Current usage is for deployment and management of a couple of servers. It uses the distribution features, and constraints solving, to work out what to install, uninstall, etc based on changes to configuration files. It has a user interface using the Roads web framework. It’s a toy system I built to explore ideas as an ansible alternative. I’ve done various incarnations in Prolog and Mozart/Oz.
What might interest you is some old articles on using Mozart/Oz for proving things. See “A Program Verification System Based on Oz”, “Compiling Formal Specifications to Oz Programs” and “Deriving Acceptance Tests from Goal Requirements” in Multiparadigm programming in Mozart/Oz.
I saved it for when I have Springer access. I am interested in it as a multiparadigm language as well. Did you find the constraint solving to be as good as an industrial solver integrated with a good 3GL? Or still better for performance or usability to just go with dedicated tools? I know a lot of people liked that Prolog could do some forms of parsing or solving but language made it harder to use some better methods. I figured something similar could happen with Mozart/Oz trying to do too many paradigms at once.
The constraint solver in Mozart/Oz has many interesting features, but in the end it is, IMHO, just too old to be competitive with a modern solver.
For constraint solving, I would probably use Gecode, or_tools, or Choco depending on the particular use-case one has and the technical requirements. If money is not an issue, IBM CP Optimizer seems to be very very good.
To explore a particular problem, I typically write the model in MiniZinc since it is a reasonably high level modelling language that allows me the switch between solving backends. In particular, I like that I can try out a problem with both a normal solver (such as Gecode) and a lazy clause generation solver such as Chuffed.
Of course, the particular problem might be better suited for SMT solving (using Z3), MIP solvers (CPLEX or Gurobi), or perhaps a custom algorithm.
Another thing to consider is correctness. Optimization systems such as constraint solvers are a complex pieces of software, with lots of possibilities for bugs. Off-by-one errors in particular are very common. If I were to depend on an optimization system, I would prefer one that is maintained, has been around for a while, and that has a reasonably large set of automated tests.
On related note, if you’re into CHR, I just submitted a paper that shows how they compile it to C language. MiniZinc and CHR were most interesting languages I found looking for basic info on constraint handling.
I haven’t used an industrial solver in anger - other than using Z3’s integration with ATS. But the Mozart solver seems to work well, and has features to distribute amongst multiple machines for larger problems. It has tools to visualize and explore the solution space and the ability to customize and add features to the solver in Oz. It’s a pretty old system though and I know that Mozart 2 intends to replace the Oz solver with gecode to get some newer features.
The “too many paradigms” is an issue in that it can be hard to decide how to approach a problem. Do you use OO, functional, relational, etc. So many choices that it can be paralysing.
Not that I’m aware of. Hopefully it’s buildable. The main issue is the code base is older C++ so some warnings/errors in current compilers need to be disabled. It’s also 32-bit only. Mozart 2 is 64 bit but lacks the constraints and distribution libraries.
that’s pretty exciting! i was just this weekend looking at the oz/mozart home page, wondering if the language were dead or not (i wanted to use it for a small project, just to play with it, but concluded that it did indeed look unmaintained)
I use Mozart/Oz in projects and help keep the bitrot away from the 1.3.x and 1.4.x versions. The Mozart 2 version runs but is lacking features - distributed objects and constraints being the most notable. I feel like there needs to be a “1.5” interim release, maintained and with binaries, to show activity.
The project tends to suffer from being used as a university/research project. People do work on masters thesis to contribute a feature to it, then they disappear and that feature doesn’t get maintained, extended, made production ready, etc.
That said, it’s still a great system to use.
i should have known that if anyone was using it you would be :) do you have a more recent version of 1.4.x than the one in the repo, or have you been pushing all your changes?
I’ve pushed all my changes so it should build on Linux at least. I recommend using the 1.3.x branch as 1.4.x has some annoying bugs. Distributed search is broken, distribution statistics don’t work, due to a switch to a C++ based library to do object distribution and bugs didn’t get ironed out. It only matters if you plan to use those features though. I’ve backported some of the actual bug fixes from 1.4.x to 1.3.x.
What do you use it for?
Originally I wrote a bitcoin mining pool using Mozart/Oz, before transitioning it to ATS. Current usage is for deployment and management of a couple of servers. It uses the distribution features, and constraints solving, to work out what to install, uninstall, etc based on changes to configuration files. It has a user interface using the Roads web framework. It’s a toy system I built to explore ideas as an ansible alternative. I’ve done various incarnations in Prolog and Mozart/Oz.
What might interest you is some old articles on using Mozart/Oz for proving things. See “A Program Verification System Based on Oz”, “Compiling Formal Specifications to Oz Programs” and “Deriving Acceptance Tests from Goal Requirements” in Multiparadigm programming in Mozart/Oz.
I saved it for when I have Springer access. I am interested in it as a multiparadigm language as well. Did you find the constraint solving to be as good as an industrial solver integrated with a good 3GL? Or still better for performance or usability to just go with dedicated tools? I know a lot of people liked that Prolog could do some forms of parsing or solving but language made it harder to use some better methods. I figured something similar could happen with Mozart/Oz trying to do too many paradigms at once.
The constraint solver in Mozart/Oz has many interesting features, but in the end it is, IMHO, just too old to be competitive with a modern solver.
For constraint solving, I would probably use Gecode, or_tools, or Choco depending on the particular use-case one has and the technical requirements. If money is not an issue, IBM CP Optimizer seems to be very very good.
To explore a particular problem, I typically write the model in MiniZinc since it is a reasonably high level modelling language that allows me the switch between solving backends. In particular, I like that I can try out a problem with both a normal solver (such as Gecode) and a lazy clause generation solver such as Chuffed.
Of course, the particular problem might be better suited for SMT solving (using Z3), MIP solvers (CPLEX or Gurobi), or perhaps a custom algorithm.
Another thing to consider is correctness. Optimization systems such as constraint solvers are a complex pieces of software, with lots of possibilities for bugs. Off-by-one errors in particular are very common. If I were to depend on an optimization system, I would prefer one that is maintained, has been around for a while, and that has a reasonably large set of automated tests.
Thanks for the great summary!
On related note, if you’re into CHR, I just submitted a paper that shows how they compile it to C language. MiniZinc and CHR were most interesting languages I found looking for basic info on constraint handling.
I haven’t used an industrial solver in anger - other than using Z3’s integration with ATS. But the Mozart solver seems to work well, and has features to distribute amongst multiple machines for larger problems. It has tools to visualize and explore the solution space and the ability to customize and add features to the solver in Oz. It’s a pretty old system though and I know that Mozart 2 intends to replace the Oz solver with gecode to get some newer features.
The “too many paradigms” is an issue in that it can be hard to decide how to approach a problem. Do you use OO, functional, relational, etc. So many choices that it can be paralysing.
Is there an OpenBSD port for Oz anywhere? I can attempt to compile from source, but I’m hoping there’s something easier.
Not that I’m aware of. Hopefully it’s buildable. The main issue is the code base is older C++ so some warnings/errors in current compilers need to be disabled. It’s also 32-bit only. Mozart 2 is 64 bit but lacks the constraints and distribution libraries.