Скачать или смотреть Is functional programming declarative?

People often say that functional programming is a "declarative paradigm". I push back against that categorization. I simply think the word is mostly meaningless.

►► Audio, Video, and Transcript available: https://lispcast.com/is-functional-pr...

►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...

Transcript

Is #functionalprogramming declarative? Hi, my name is Eric Normand. These are my thoughts on functional programming.

When people describe functional programming, one thing that comes up a lot is saying that functional programming is a declarative paradigm. To further explain what declarative means, they'll say, "It means you say what you intend to do and what you want without telling how you do it, see?"

I want this list transformed. You don't say how to do it, which is like giving a for-loop with an increment variable that you go through the loop, stop at the end of the list, etc.

Now I want to challenge this whole idea. I don't think it holds water. It might be a good, intuitive idea that FP is somehow better at expressing some problems because it's declarative. I just don't like the idea in general.

The reason I don't like it is every paradigm claims to be declarative. It can, if you take declarative as a relative term. When I do a for-loop in even something like C, that's declarative compared to assembly. In assembly, I have to use a go-to. I have to say, "How do I loop? What line of code do I jump to? What has a label? I'm going to jump to it after I do this comparison."

If you go down to something like machine code, you might even be choosing what register you're storing your increment variable in. Looping becomes a design pattern for a certain pattern of using go-tos, increment variables, and stuff like that.

The idea that you're telling it what you want and not how to do it, every paradigm or every #Functionallanguage that is better than the last, more expressive than the last can claim that.

I just think that it's like a meaningless word. Now you can say that it's a relative term that for certain constructs, let's say, a map, or a filter, or a reduce. You can say that that is more declarative than a for-loop. It's only relative. To use the term declarative in an absolute sense is meaningless. To say functional programming is a declarative paradigm.

It's just not. It doesn't mean anything because in 20 years, 30 years, there might be an improvement, a better paradigm. Someone is going to claim that that one is declarative. They're going to compare it to functional programming. They're going to say, "See, it's way more declarative than that one."

I just think we should stop using this term, at least, in an absolute way. Maybe, you can use it in a relative way. The only thing it means in a relative way is the details that I have to worry about are taken care of for me. What's the name of the index variable as I loop through this? That's gone.

That's something you have to care about in the for-loop, but you don't have to care about that when you're doing map. Just like in a for-loop, you don't have to care about what register you're storing your stuff in. That's taken care of for you by the for-loop and the compiler.

Another thing people will say is that you don't have to worry about how the map works. That you could say, "Oh, that map could be totally replaced by the compiler with a parallel implementation or some other implementation."

Now this is sometimes true, that a certain construct will somehow insert itself and maintain the semantics that it promises while somehow optimizing it.

We see this in SQL a lot. You send a SQL statement. We know that the SQL will be optimized by the database. The order that we put the joins in isn't really the order that stuff will be executed in. There's going to be an optimization step.

This, again, is simply not unique to what we would call "declarative languages." The C++ compiler, the GNU C compiler, they all have optimization steps.

#Clojure