Basically, no programming language what so ever infers anything about any sort of high level intent (and no, type of expression is not a high level intent),
The phrase they (partially tongue in cheek) used was “compile time correctness checking”, i.e., the criterion of being a syntactically correct ML program is better approximation to the space of programs you may want than is the case for most other languages.
a larger proportion of the strings that fail to compile in ML are programs that exhibit high-level behavior that you don’t want?
This formulation is missing the programmer’s mind. The claim that a programming language is better in this way is that, for a given intended result, the set of strings that
a programmer would believe achieve the desired behavior,
compile*, and
do not exhibit the desired behavior
is smaller than for other languages — because there are fewer ways to write program fragments that deviate from the obvious-to-the-(reader|writer) behavior.
Is it harder to write a control program for a wind turbine that causes excessive fatigue cracking in ML as compared to any other language?
The claim is yes, given that the programmer is intending to write a program which does not cause excessive fatigue cracking.
(I’m not familiar with ML; I do not intend to advocate it here. I am attempting to explicate the general thinking behind any effort to create/advocate a better-in-this-dimension programming language.)
* for ’dynamic” languages, substitute “does not signal an error on a typical input”, i.e., is not obviously broken when trivially tested
Suppose that the programmer is unaware of the production-line issues which result in stress concentration on turbine blades and create the world such that turbines which cycle more often have larger fatigue cracks. Suppose the programmer is also unaware of the lack of production-line issues which result in larger fatigue cracks on turbines that were consistently overspeed.
The programmer is aware that both overspeed and cyclical operations will result in the growth of two different types of cracks, and that the ideal solution uses both cycling the turbine and tolerating some amount of overspeed operation.
In that case, I don’t find it reasonable that the choice of programming language should have any effect on the belief of the programmer that fatigue cracks will propagate; the only possible benefit would be making the programmer more sure that the string was a program which controls turbines. The high-level goals of the programmer aren’t often within the computer.
The phrase they (partially tongue in cheek) used was “compile time correctness checking”, i.e., the criterion of being a syntactically correct ML program is better approximation to the space of programs you may want than is the case for most other languages.
In other words, a larger proportion of the strings that fail to compile in ML are programs that exhibit high-level behavior that you don’t want?
Is it harder to write a control program for a wind turbine that causes excessive fatigue cracking in ML as compared to any other language?
This formulation is missing the programmer’s mind. The claim that a programming language is better in this way is that, for a given intended result, the set of strings that
a programmer would believe achieve the desired behavior,
compile*, and
do not exhibit the desired behavior
is smaller than for other languages — because there are fewer ways to write program fragments that deviate from the obvious-to-the-(reader|writer) behavior.
The claim is yes, given that the programmer is intending to write a program which does not cause excessive fatigue cracking.
(I’m not familiar with ML; I do not intend to advocate it here. I am attempting to explicate the general thinking behind any effort to create/advocate a better-in-this-dimension programming language.)
* for ’dynamic” languages, substitute “does not signal an error on a typical input”, i.e., is not obviously broken when trivially tested
Suppose that the programmer is unaware of the production-line issues which result in stress concentration on turbine blades and create the world such that turbines which cycle more often have larger fatigue cracks. Suppose the programmer is also unaware of the lack of production-line issues which result in larger fatigue cracks on turbines that were consistently overspeed.
The programmer is aware that both overspeed and cyclical operations will result in the growth of two different types of cracks, and that the ideal solution uses both cycling the turbine and tolerating some amount of overspeed operation.
In that case, I don’t find it reasonable that the choice of programming language should have any effect on the belief of the programmer that fatigue cracks will propagate; the only possible benefit would be making the programmer more sure that the string was a program which controls turbines. The high-level goals of the programmer aren’t often within the computer.