Formalism and rationality provide checks that whatever you are saying is coherent, but in the end what is being expressed are the ideas of a human mind, and the ideas expressed will be only as rigorous and thorough as the understanding you have about the problem you're describing.
There will also be a lot of assumptions that are not included in the formal object (the code) but which are essential to the full meaning of the concepts, and are either expressed as axioms or entirely omitted. A computer will blindly execute exactly what is being written in a program, but for the system to be used and evolved in a coherent way, it depends on the users knowing those untold assumptions that separate correct from incorrect interpretations.
There is an unexplored area for a platform to support this kind of exploratory, poorly understood and probably incomplete of wrong programs, with tooling to help the user refine a program iteratively from the first insights to a complete working state. "Live programming" and online notebooks a la Jupyter work in that direction, and spreadsheets directly support it (but are limited to a specific programming model).
So in a way, I allowed myself to be a mechanical executer through the rules of algebra/calculus I've used, and then I re-engaged my intuition to understand what is happening.
It might even be my unwillingness to accept the mechanical approach purely that poses a big hindrance to fast tracking a lot of learning in this domain I have to do. Maybe I should just shut up and calculate as they say, but it's hard.
This just makes it all the more true that learning "languages" is the best way to become smarter. "Smarter" is a weird personal word here, but I'm at a loss for a better way to put it. What am going for is: languages can be an abstract lever that allows our limited cognitive potential to build culturally, which is distinct and will definitely interact with the knowledge ladder, but in a distinct way. "Languages" here are more general than just the textual/oral/syntactic, and am not talking about Russian/Arabic/French either.
That's a sensible approach, but it works because you're executing mechanical in a well-defined problem domain, so there's an intuition attached to each term used, and you can build an overall intuition. You might as well use random mechanical transformations over an algebra and they wouldn't make any sense, just like if you attached random dictionary words forming grammatically correct sentences.
I see usage of formal languages as mathematicians and philosophers making "very precise sentences", i.e. being extremely precise with the meaning attached to each term so that it remains consistent among all the transformations of discourse (in fact, there's a formal theory of meaning which does exactly that).
But the main value of such exercise is in knowing what you want to express, not in the fact that you're being extremely precise while doing it; the latter can help you convince others of what you're saying, but they need to agree to the original axioms of your theory, otherwise they'll just be able to point very precisely where they think you are wrong.
I see no need to assign a value judgement to it, and somewhat resent doing so.
Might be good for juicing clicks by confirmation bias, but the idea is nevertheless that programming is a medium through which incomplete understanding can be refined, and eventually expressed.
Good or bad should be left to the reader to judge.
I like the idea, if only because I've philosophically approached software in terms of chewing what a program is from what it isn't.
Which, by all forms of understanding I possess, is a benefit or beneficial to the users of programming. Ergo, a good medium.
If the title were "Programming as a potential medium for expressing/refining not yet well-formed ideas", then there'd be no value judgment at all (and we probably wouldn't be having this conversation). But as it is, the title uses "poorly understood, sloppily-formulated ideas" which automatically puts a negative spin, which is in a way counter-acted in the original paper by "good medium", implying that the paper isn't actually about bad ideas and how they're propagated through code.
I think of undefined behaviour as a matter of knowing the many dark corners of C and C++. How did Haskell help?
Such an interesting character.