dr0wsy

Zoom is primarily an enterprise product. They have chosen to have some form off verification to lower the amount of abuse on their platform.

If you want privacy you simply have to choose another product or service.

You aren't entitled to use their service without paying for it.

Thanks for the explanation! An example to check if I understood you correctly.

  `func1(r, s)` is a function that sends a request `r` to a given server `s`. It returns a status code from the server.

How does that sound? It feels more like a spec than "doing math".

> I highly recommend that book I linked in the article: "Introduction to Graph Theory" By: Trudeau

I'll check it out! Does the book cover all the relevant parts you mentioned before?

Btw, it seems you don't link the book in the article. At least I couldn't find it when looked now.

> That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch.

Thanks! You don't happen to have some learning resources for modelling programs as state machines? I can't find anything when I search.

> You don't need to know category theory. You just need to understand a few things that came from it, like `Maybe`, which is the most obviously useful and trivially easy monad. Just forget about the fact that it's a monad and any general rules about monads and just learn how to use `Maybe`.

I didn't convey my question clearly. What I'm wondering is how I should express programs, or part of them, using mathematical notation when I don't see them being mathematical in nature to begin with?

An example:

  def hello(name):
      if (name == "Bob"):
          print("Hello, " + name)
      else:
          print("Hello, World!")

How could I express this easily using mathematical notation?

It just feels weird that to convey this simple program on paper both I and the person I try to communicate with needs to have a grounding in category theory.

Hope you're able to understand my question. :)

Thanks for the article and discussion that sprang up around it!

The question I'm trying to ask is how I should express (part of) programs on paper using math when I don't see how they are related to math.

Example: How could I easily express a function that takes a string as input and outputs the string capitalized using math notation?

I understand that the problem you solve in the post should probably be put on paper first before you began writing any code.

My problem is to express programs in math when "calculate" isn't part of the problem description, like it is in the example in the blog post.

Edit: Changed example question.

> So if you want your programming to reap the benefits of (others', mostly) mathematical reasoning--use a functional language that is all about expressing the ways in which things compose!

I do prefer using functional language over imperative ones, but I don't understand that is connected to model software on paper?

> IO is modelled pretty well through monads. As are many other things, like nondeterministic processes, exceptions, state, etc.

Isn't there any easier way to describe I/O than with category theory? I understand that it's _possible_ to model IO with monads, but how would I communicate it with colleagues that doesn't have a background in category theory (or myself for that matter)?

Part of the benefits with modelling a program on paper should be to make communication easier. And to require people you communicate with to have knowledge in category theory to understand your design fells silly.

I probably misinterpret you, so could you please give a more detailed explanation or example?

How do I express my models of programs on paper that doesn't easily translate into math? I understand that the part of programs there you have a formula on beforehand (e.g., convert between Celsius and Fahrenheit) is easily expressed in a mathematical formula before implementing it. However, how should I express I/O?

Often when I have a problem that isn't easily expressed in mathematical notation (albeit to my limited knowledge of math), I usually got a good idea of how I could express it in code.

When I write pseudo code it often feels like I already have the code in my mind before I describe in plain English. That feels like a waste of time. So pseudo code doesn't feel like a great tool to express models of my programs.