First of all, thank you for taking the time to share your opinion on the article.

The quote from wikipedia is much more
sober, accurate and informative and
even more brief and punchy

I find the quote from Wikipedia quite beautifully written as well. However I think it doesn’t convey to the reader other forms of declarative programming, like that of make rules.

“This article is about declarative programming in python and intended for consumption by humans”. Assuming, I have this sentence saved in dec_article.txt I can express this as the following make rule:

dec_article.md: dec_article.txt
declarative_writer dec_article.txt

and makes it more apparent that this is
another way of abstracting away from
the bare metal, like high-level languages
abstract away from machine code.

The goal of declarative programming isn’t to abstract away from the bare-metal though. Even one of the most imperative languages C, which maps very nicely to the bare-metal, abstracts away from it. Declarative programming abstracts away from the control flow, and from imperatively stating in an instruction-by-instruction manner, how a result is to be reached.

That said, the actual article did not
make it easy for me to understand how
Python could be used, actually,
declaratively.

That’s a big failure on my side, I’ll update the article to include a comparison between the example API in the article written as it is vs the API written in a non-declarative manner, and explain the differences between them further.

It’s more that Makefiles will work out what actions to perform, and in what order, based on the the state of the filesystem and rules you provide.You can usually write rules in any order, and Make will do a topological sort to figure out what actually needs to happen based on the dependencies between steps.

SQL is also known for being a largely declarative language, and has a similar process where you describe what needs to come from where, and the SQL query parser and planner for the DB in question actually works out any of a number of plans on how to actually fetch the data. This splitting up what you want from how it’s implemented allows for after-the-fact optimizations in SQL database, such as adding indexes, without necessarily having to change the queries themselves.

I don’t think Make is as declarative as SQL, (and so has little room to able to optimize things after the fact, though you can add in rules for how to treat certain types of files), but I’d consider it to be decently declarative as-is

Thank you for your response! I read your follow up post and tried to follow it. I suspect my lack of enthusiasm for this line of explanation is that for a person unfamiliar with declarative programming (like me) the example really doesn’t tell me anything. You’ve just punted on all the logic and are using whatever the library supplies you. Also, your declarative implementation carries no state and no __init__ so I don’t see how it implements the interface either :( .

To me make and makefiles are the the most easily accessible example of a declarative style: you declare how to make the products and make figures out in what order to run the individual steps in order to make that happen.

There is a lot of hype around the word “declarative” and I thank my very rudimentary poking around of Haskell for allowing me to grasp the core concepts that are behind it: No side-effects (though that’s a fun argument for make :) ), immutability and lazy evaluation.

It’s a fun paradigm, and I like the idea, and I should try it out in a mid-size project once to see how I feel about it.

It’s a shame I couldn’t bring my points across to you, I’ll keep your experience with the article with me for next time:)

You’ve just punted on all the logic and are using whatever the library supplies you. Also, your declarative implementation carries no state and no init so I don’t see how it implements the interface either :( .

I’m very fond of puns and riddles, but you’re absolutely right to point out that they’re not necessarily the best learning-aid. I’ve hidden the low-level bluetooth logic, because it’s completely irrelevant to the point of the article. The available bluetooth functionality was to be taken as an established baseline, just like any functionality offered by the standard library, and the state wasn’t actually hidden, it’s just that there isn’t much state. The article shows the __init__() function for RapidAPI which just has one attribute:)

To me make and makefiles are the the most easily accessible example of a declarative style: you declare how to make the products and make figures out in what order to run the individual steps in order to make that happen.

I’m thinking maybe I should’ve explained a bit more about Bluetooth Low Energy? I think the reason why make is much more accessible for you, is due to your knowledge of the compilation process.

There is a lot of hype around the word “declarative” and I thank my very rudimentary poking around of Haskell for allowing me to grasp the core concepts that are behind it: No side-effects (though that’s a fun argument for make :) ), immutability and lazy evaluation.

Haskell and what you’re describing here is pure functional programming, which is only a subset of declarative programming, that adds more constraints like referential transparency (no side-effects) and immutability. Lazy evaluation is an implementation detail that can be added to even imperative languages. So make having side-effects is okay, because make isn’t a functional language.

The article shows the init() function for RapidAPI which just has one attribute:)

Ah I see. Thanks.

I’m thinking maybe I should’ve explained a bit more about Bluetooth Low Energy? I think the reason why make is much more accessible for you, is due to your knowledge of the compilation process.

I don’t think that’s it.

I don’t need to know the details of the compilation process, just that this problem is well defined as a dependency graph and a makefile does not care about (mostly) the order you declare the products. make is the tool responsible for creating the dependency graph and then walking it to figure out what needs to be done and in what order, which is the core of declarative programming - the runtime/compiler figures out the dependency graph from your variable and function declarations.

Explaining more about Bluetooth Low Energy would probably just be tangential to all this.