{"id":9440,"date":"2022-03-19T11:29:30","date_gmt":"2022-03-19T16:29:30","guid":{"rendered":"https:\/\/blogs.pacasmayo.com\/felipe\/?p=9440"},"modified":"2022-03-19T12:33:41","modified_gmt":"2022-03-19T17:33:41","slug":"command-yourself-to-declare","status":"publish","type":"post","link":"https:\/\/blogs.pacasmayo.com\/felipe\/2022\/03\/19\/command-yourself-to-declare\/","title":{"rendered":"Command yourself to declare"},"content":{"rendered":"\n

Leer en Espa\u00f1ol<\/a><\/p>\n\n\n\n

Declarative<\/em> programming is a transformational trend in the industry that not only improves the programming paradigm but also enables the automation revolution.<\/p>\n\n\n\n

Imperative<\/h2>\n\n\n\n

In the opposite corner, we have imperative<\/em> programming, which means that a programmer would write the specific instructions for which actions would be performed and in which order. For example, if an application needed to copy a file the developer would call a function like this:<\/p>\n\n\n\n

\/\/ pseudo-code\ncopy_file(\/source,\/target)<\/code><\/pre>\n\n\n\n
The user of the copy_file is issuing a command, to copy the file from the source to the target, and we can assume that the intention of the caller is that the file is made available at the target location, but the intention is not 100% clear from the imperative style.  If we are implementing the imperative<\/em> copy_file command, we have to either make some assumptions or ask the caller to make their intentions clear through some extra parameters (i.e. do_not_copy_if_exists: true).<\/p>\n\n\n\n
\/\/ pseudo-code\nfunction copy_file(source, target)\n  sourceExists = file_exists(source)\n  targetFolderExists = folder_exists(target)\n  if sourceExists then\n    if no targetFolderExists then\n      create_folder(target)\n    end if\n    targetIsIdentical = compare_size_and_date(source,target)\n    if targetIsIdentical then\n      return success<\/strong> \/\/ You were told to copy, you did not copy... why success?<\/strong>\n    else\n      contents = read_file(source)\n      write_file(contents,target)\n      return success\n    end if\n  end if\n  return failure\nend function<\/code><\/pre>\n\n\n\n
This begs the question if the command needed extra arguments to clarify the intention, wouldn’t it make more sense for the user to express the intention without the command?  Welcome to the world of “declarative<\/em>” or “desired state<\/em>” programming.<\/p>\n\n\n\n
Declarative<\/h2>\n\n\n\n
Declarative<\/em> programming is NOT replacing the imperative<\/em>, procedural<\/em>[1]<\/a><\/sup> style of programming, but enhancing the interface to the users by asking their intentions instead of instructions. The declarative<\/em> model changes the paradigm and states that libraries should not provide the user with actions\/verbs, instead they should allow the requestor to assert the desired final state and let the library or tool figure out how to get there.  Of course, declarative programming is not a new thing, it has been used for decades in the data world in SQL programming, but it is making a huge rebirth in the world of automation. So, again, using pseudo-code:<\/p>\n\n\n\n
ensureFileAvailable:\n  whichFile: \/source\n  where: \/target<\/code><\/pre>\n\n\n\n
We can see three immediate benefits from this approach over the imperative style: <\/p>\n\n\n\n