Math vs Programing, What-is vs How-to
there are 2 major forces in computer science. What Is, and How To.
WHAT IS is a axiomatic description of how things are. It is math, basically. Equations, algebra.
HOW TO is step-by-step instruction. For example: algorithm. Computer language code, in general, are How To.
WHAT IS, is typically easy to understand. Because, it describes. Shows you the character. Shows you What It Is.
How To, is typically impossible to understand. The longer, the less comprehensible. For example, software source code.
The problem with What Is, is that it doesn't tell you how to. Say, you know all the science of a car. But you can't build it.
The problem with How To, is that you don't understand it. Say, you are given instructions to build car from scratch. You don't know how it works.
Automatic Translation between What Is and How To, is almost the ultimate goal of computer science. Or, one of the most fundamental topic.
Programing language docs, when well written, is What Is. It describes the language's functions and other parts, describes, the system.
Bad language docs by majority of programers, is 50% How To. Because coders don't understand their code. They just paraphrase the source code.
languages like #prolog, #coq, are What Is languages. You tell it axioms, and it answer yes/no questions.
functional language like haskell, are declarative languages at micro level. As soon as you apply a lambda, it's an instruction. Prolog would be a declarative lang.
In computer science or mathematics, there's often a tension between How To vs What Is.
for example, look at prime numbers.
prime number is usually defined in math as a number whose divisor is just 1 or itself. This is the what-is type of definition. Alternatively, prime number can be defined by sieve algorithm such that a number is prime if the sieve algorithm will show it is. We may call the algorithmic way as the How To approach.
The What IS approach often very clear and concise, and it gives us a direct sense of what a thing is. It does not, give us instructions to build it, or even know if it exists. The How To approach is rather direct, in the sense that by following directions, you can actually build the thing. However, the directions can be complicated, and does not give us a clear sense of what we are building.
For another example, let's take plane curves. Let's say, a circle. A plane curve can usually defined algebraically, as the solution of a equation. For example, a circle of radius 1 centered on origin is given by x^2+y^2=1. Or, it can be defined by so-called “parametrically”, using functions that specifies the points at a given time. e.g. {Cos[t],Sin[t]}.
also, basically ALL programing language doc are descriptive. I can only think of Wolfram Language doc being declarative. (all my tutorials, tries to be as much as declarative as possible.)
See also: Technical Writing as Symbolic Logic: Clojure Intern Symbol
math vs algorithm example: x==y==z
one example to illustrate the different nature of math vs algorithm is: x==y==z or explicit 3==3==3. In math, it's a statement. In programing, 3==3 eval to true, then true==3 is false.
more specifically, == in math is a relational operator. By that, it means, when we say
x==y, we are making a statement that x and y are related by ==. (in formal language theory, it can actually mean anything, but here we typically mean they are “equal”). In programing,
== is also called a “relational operator”. However, the concept is entirely different. Here, operator is a specific syntax of a instruction. It “evaluates” the operands to get a result.