Easier to reason about by whom? Most programming models have their own calculi which are exploited by their respective verification tools. They don't, however, expose that to the developer.
> I think Haskell will be better in this regard if you are mathematically minded
I think that Haskell is better if you are mathematically minded and interested in thinking (a lot!) about abstractions. I like to keep my abstractions cognitively simple (primitive, even), and my algorithms sophisticated and powerful. I'd rather the people writing the verifier put their mathematical leanings to use on the relevant calculus, while I use mine on the algorithmic domain I'm working in.
Just like I don't require the developer using my database to be familiar with data structures and concurrency, I don't want those interested in formal verification requiring me to change my programming style to make their job easier. In fact, their job is quite the opposite: provide verification tools that are useful for the programming languages that make for a good cognitive fit, rather than design languages that make verification easier with the (possibly misplaced) hope that by some unexplained coincidence, a language designed to make a machine's reasoning easier would also do the same for a human.
Software verification is a fascinating algorithmic topic. Language design is a fascinating UI endeavour tasked -- like all UI -- with coming up with great cognitive abstractions. The two should, of course, cross-pollinate one another, but shouldn't become the same. Language designers should spend their time thinking how humans think about computation and how they interact with computers, not how to make programming models fit certain branches of math.
As I said, by those who are aware of the math concepts they are based on. Monads are I think the best example for Haskell; particularly in how they behave with respect to functions, which fits quite nicely with a categorical point of view.
> I think that Haskell is better if you are mathematically minded and interested in thinking (a lot!) about abstractions.
I'm not sure you can be mathematically minded in the pure mathematics sense (which is what Haskell draws on) without being interested in thinking a lot about abstractions. If you are more focused on concrete mathematics, then Haskell is unlikely to be your ideal language, but when people reference mathematics in regards to the language I suspect they are referring to the pure variant. In any case, I am, which is I think most of the confusion here.
> Just like I don't require the developer using my database to be familiar with data structures and concurrency, I don't want those interested in formal verification requiring me to change my programming style to make their job easier.
The only built in formal verification I can think of in Haskell is the type system. In that case, I think your analogy breaks down; I'm not sure how one can manage to program (effectively) in any language without understanding its type system. If you are referring to an external static analysis tool, then I'm not sure how you can put that on Haskell itself.
> a language designed to make a machine's reasoning easier would also do the same for a human
I believe it does for humans who come from a pure math background, in the same way programmers who know an object oriented language will find it easier to grasp another object oriented language. Moreover, it seems pretty clear that this is no a coincidence; it was the driving force behind Haskell's most fundamental design (e.g. Curry Howard) and its library (e.g. monads). So if you (as you say) are not interested in abstract mathematics, then it is no wonder you don't care for its methods.
> Language designers should spend their time thinking how humans think about computation and how they interact with computers, not how to make programming models fit certain branches of math.
Unless, of course, they are focusing on humans that are not only well versed and comfortable with certain branches of math, but prefer that mode of thinking. Haskell's unofficial motto of "avoid success at all costs" makes me think that focusing on this demographic is likely one of the language's design features, as opposed to making the best language ever for everybody. In any case, I would argue it is good for mathematicians, but not that all of the effort to move to that way of thinking is something universally useful for programmers.
Easier to reason about by whom? Most programming models have their own calculi which are exploited by their respective verification tools. They don't, however, expose that to the developer.
> I think Haskell will be better in this regard if you are mathematically minded
I think that Haskell is better if you are mathematically minded and interested in thinking (a lot!) about abstractions. I like to keep my abstractions cognitively simple (primitive, even), and my algorithms sophisticated and powerful. I'd rather the people writing the verifier put their mathematical leanings to use on the relevant calculus, while I use mine on the algorithmic domain I'm working in.
Just like I don't require the developer using my database to be familiar with data structures and concurrency, I don't want those interested in formal verification requiring me to change my programming style to make their job easier. In fact, their job is quite the opposite: provide verification tools that are useful for the programming languages that make for a good cognitive fit, rather than design languages that make verification easier with the (possibly misplaced) hope that by some unexplained coincidence, a language designed to make a machine's reasoning easier would also do the same for a human.
Software verification is a fascinating algorithmic topic. Language design is a fascinating UI endeavour tasked -- like all UI -- with coming up with great cognitive abstractions. The two should, of course, cross-pollinate one another, but shouldn't become the same. Language designers should spend their time thinking how humans think about computation and how they interact with computers, not how to make programming models fit certain branches of math.