Functional programming and declarative programming

My thoughts about what "declarative programming" really is, and where functional programming stands in relation to declarative programming.

Outline:

Functional programming is interesting, but in a weird way
- FP is (almost) engineering
- Other programming paradigms are (almost) artisanship
A definition of declarative programming:
- A language for problem requirements, understandable to people
- The same language is mechanically translated into code
- The only known “silver bullet” of programming
Declarative programming must be domain-specific (DSL)
- We get a productivity boost as long as we avoid the pitfalls
Implementing DSLs is a “killer app” for functional programming
- FP is declarative for working with recursive data structures, such as labeled trees
- Requires learning some programming language theory

[simonlanglois]

Nice talk! I have some thoughts...

Under the functional paradigm, programs are made of declarations (x :: type) and definitions (x = term).
Declarative programming, in my mind, is "executable specification" where you only have to write the required type, and the machine automatically checks the proposition (i.e. Propositions as Types), implements an algorithm, finds an element of a set, etc.

A DSL can offer 100% automation over its domain of specifications. Implementing a spec in general is on a best-effort basis.

When I was investigating Category Theory, I found that 90% of the code I wrote was at the level of types. Usually, an implementation was constrained to be unique, so that code (that I wrote manually) could be safely ignored once it compiled; all the relevant information was in the declaration.
In my day job, things are rarely so clean, but the principle is still useful. And I can put that extra effort where it matters, for reliability, etc.

[georgecoldwell]

This was a very informative talk. I really like that it gave a clear definition of the term "declarative", that I find is often defined so abstractly, that it loses any meaning. "you tell the computer what you want done, not how to do it" is nice, but almost meaningless to someone new to programming. Kudos for that!

One slight mistake I'd like to point out it's that at 45:50, in JavaScript, much like in Java, functions can't really return references, at least not overwritable ones. f() would always produce a 0, regardless of what other modules do. I like to think about the `=` operator as "rebinding". `x = y` binds a different object to the name `x`, not modifying the previous one. `x.y = z` binds whatever's in `x`'s property `y` to an object `z`, effectively modifying `x`, but once again leaving whatever `x`'s `y` was before untouched. The example is good enough for the demonstration of a principle, just this particular case is not true and some might dismiss the whole idea because of that.

Thanks for a very interesting point of view!

[AlexToth-xb]

I like your work. You provide a unique point of view and you dig into details. Yet on the second example of slide 8 at about 25:00 I disagree. I would read 10 and 20 as labels (I was not trained on Fortran). Also regarding zero I guess it is 1 as in the formula minus one.