3 ms·
On somewhat of a tangent, consider a specification such as "sort a list of numbers". After adding a few minor details, this could be an entirely formal and unam
by extension 17y ago
On somewhat of a tangent, consider a specification such as "sort a list of numbers". After adding a few minor details, this could be an entirely formal and unambiguous specification, yet implementation would require (disregarding prior art) an informal creative process involving significant leaps of intuition.
It seems to me that a formal spec need only provide a method of verification and is therefor distinct from the solution, though it's no surprise that the distinction goes unnoticed in our industry, given the dearth of both specs and difficult algorithmic problems.
- philwelch 17y agoBut we can already turn "sort a list of numbers" into a program, although instead of "sort a list of numbers", it's called sort() and takes a list of numbers as an argument. By this standard, most programs are closer to specs than they are to solutions--a testament to the abstractions we already have.
- extension 17y agoI had gotten word that the sorting problem has been solved, hence the "disregarding prior art" part. My point, which you don't seem to be contradicting, is that a formal specification of a problem is not the same as a solution. They just seem the same because real world programming problems tend to have obvious solutions, or at least solutions that don't feel much like programming.