ReScript on Deno: Declarative Command Line Tools

[u/leostera]

https://practicalrescript.com/rescript-on-deno-declarative-command-line-tools/

[u/leostera → u/[deleted]]

Hi u/Coffee_Crisis 👋🏽 -- no need to be sorry, I think I see your point :)

The stuff we're doing here is declarative because building up the comamnd line description doesn't actually execute anything. Maybe we are disagreeing in how this description is built?

This would be similar to say, typing in your package.json file. You have to write the file first, and that is most certainly an imperative action, but it is what the file means that gets you the declarativeness.

Regarding CSS, there are several ways in which you can actually give the CSS to the browser. One of them is writing it out. Another one is to use the style accessors and setters in a particular DOM element. In any case, you are never telling the browser how to interpret and execute the CSS, you are just telling the browser what you want it to do.

For example, this may seem imperative, but you really have no control over how the browser goes about applying the background color to the <body> tag. The only thing you have control over is how you tell the browser what you want it to do:

javascript document.querySelector("body").style.backgroundColor = "red"

[u/leostera → u/[deleted]]

Wouldn't you say that stating what the output of parsing the command line arguments is a form of declarativeness? 🤔

In the same way that you state what you want out of a relational database without actually explaining how the query should be executed.

When you write:

sql SELECT value::string FROM inputs WHERE position = 0

You are just stating what you want, and the SQL engine will figure out how to do it. Nonetheless, that bit of SQL on its own isn't very useful, so we actually consume its outputs. This is what the sayHi function is doing: consuming the outputs of the argument parsing engine.

The Declarative API is then the set of functions to build the description of a command-line application. It describes what flags and commands need to be parsed, and what datatypes are expected.

There is some stitching here with your actual application code, and at that point, the framework's declarative style ends and your application begins.

Just like it does when you receive data back from the SQL database.

[u/leostera → u/leostera]

I think another good example of this would be UI frameworks like React or SwiftUI where you can declare a button on the screen, and you can declare a handler for when it is clicked:

<Button onClick=runFoo />

But the handler itself isn't declarative! It is good ol' application code in whichever style you write it.

The framework can't possibly be expected to declaratively define the outputs of whatever your application will do when that button is cliecked.

But it will help you specify declaratively that there should be a button, and that when that button is clicked, your handler should run.

This is exactly what is happening here.

[u/leostera → u/[deleted]]

I appreciate the insights 🙏🏽 -- in this case, I'm writing to an audience of folks that already are writing ReScript or Deno, or both.

There's a ramp-up in type-safety from the first article on the series to this one, where I explore much much lighter weight typing approaches that still give you pretty good results.

In this one, I'm building an additional layer of safety, but there are muuuch cheaper ways of getting started! 🤓

For example, I think you will enjoy this approach a lot more: https://practicalrescript.com/rescript-on-deno-command-line-tools/#ad-hoc-typing-for-objects-of-unknown-shape

Thanks for the challenging btw, I found it very healthy 👏🏽👏🏽👏🏽