Quite an interesting series of articles :)
The Unix.waitpid failing because the author ported the python code, and did not realise that the python version did something nice which avoided one of the types of bugs.
Quite a number of the bugs appear to be because of things that the python code did nicely without the author realising it.
This shows how the comparison between a second system, and the first system is not really fair. This is because much of the code is already tested in the first system. It also seems to suggest that prototyping in a language like python as a first system is a great way to improve the quality of the second system. Finish it first quickly, and then improve the quality.
It also shows the danger of not using the protective parts of the first system in the second system. For example, the advanced integers in python avoided some bugs for the author, which manifested in the second system. The python integers automatically handle overflow, whereas the OCaml ones are 31bit on 32bit systems.
OCaml uses non-deterministic garbage collection, whereas python mostly uses reference counting (in CPython). This is another case where the first system was safer in one aspect.
Perhaps OCaml could consider taking on some of these features from python to improve safety.
Glue code when libraries are wrapped is another area where these bugs seem to happen. Some of the GTK bugs, and system call bugs are ones caused by badly wrapped functions. With more stable and well tested wrapped code, the smaller the likelihood of bugs there will be. Whilst automating wrapper generation might stop some bugs, I am not convinced, after having used buggy automatically generated wrappers many times where the manually written ones are far superior.
The post also proves that a number of bugs were not caught by testing or static type checking. This makes me wonder if the author has 100% unit test coverage or not? Some of the bugs should have been caught by unit testing, and others could only have been caught by functional testing. Some of the platform bugs could have been caught with continuous integration testing on those platforms.
The Unix.waitpid failing because the author ported the python code, and did not realise that the python version did something nice which avoided one of the types of bugs.
Quite a number of the bugs appear to be because of things that the python code did nicely without the author realising it.
This shows how the comparison between a second system, and the first system is not really fair. This is because much of the code is already tested in the first system. It also seems to suggest that prototyping in a language like python as a first system is a great way to improve the quality of the second system. Finish it first quickly, and then improve the quality.
It also shows the danger of not using the protective parts of the first system in the second system. For example, the advanced integers in python avoided some bugs for the author, which manifested in the second system. The python integers automatically handle overflow, whereas the OCaml ones are 31bit on 32bit systems.
OCaml uses non-deterministic garbage collection, whereas python mostly uses reference counting (in CPython). This is another case where the first system was safer in one aspect.
Perhaps OCaml could consider taking on some of these features from python to improve safety.
Glue code when libraries are wrapped is another area where these bugs seem to happen. Some of the GTK bugs, and system call bugs are ones caused by badly wrapped functions. With more stable and well tested wrapped code, the smaller the likelihood of bugs there will be. Whilst automating wrapper generation might stop some bugs, I am not convinced, after having used buggy automatically generated wrappers many times where the manually written ones are far superior.
The post also proves that a number of bugs were not caught by testing or static type checking. This makes me wonder if the author has 100% unit test coverage or not? Some of the bugs should have been caught by unit testing, and others could only have been caught by functional testing. Some of the platform bugs could have been caught with continuous integration testing on those platforms.