Everything Is Just Functions: 1 week with David Beazley and SICP

Not a fan of everything-is-a-function because it's oversimplistic and often unhelpful. Some of the issues:

- functions that don't fit in cache, RAM, disk, etc.

- functions that have explosive big-O, including N way JOINs, search/matching, etc.

- functions with side effects, including non-idempotent. Nobody thinks about side channel attacks on functions.

- non-deterministic functions, including ones that depend on date, time, duration, etc.

- functions don't fail midway, let alone gracefully.

- functions don't consume resources that affect other (cough) functions that happen to be sharing a pool of resources

- function arguments can be arbitrarily large or complex - IRL, there are limits and then you need pointers and then you need remote references to the web, disk, etc.

(tell me when to stop - I can keep going!)

Oversimplifying can be great at times. In this case, the lambda-calculus model (which is the base for this type of "everything is just a function" approach) is a great model of computation because it is so simple, while being easy to handle /reason about (compared to eg. Turing machines), which is why it is at the base of most computer logic/proof systems

Half of what you call functions in that comment, are not actually functions and in the FP world many would not call them functions. Rather they are procedures. Functions are procedures, but not all procedures are functions.

I think its the only hope for theoretical purposes.

Which is also a problem with thinking this is a helpful abstraction: apparently, not everything you need to do can be captured by functions (in that sense)!

Many of those things can be modelled as functions, they just need to actually be written that way (e.g. if you have a function that requires some resource, maybe it should require that resource! If it depends on the date/time, maybe it should depend on the date/time! If it returns a nondeterministic value, maybe it should return a nondeterministic value!). I think the functional programming approach shines partly because it forces you to take these things seriously: if you want to use e.g. implicitly shared resources, you need to model that, and "functions" that rely on implicitly shared resources are going to be explicitly distinct from actual function functions.

I'm just used to the words from Pascal. What's the definition of a procedure in the FP world?

Afaik, the definition is just "a sequence of steps/instructions". That is of course much broader than a (simple) function, which among other things for one input gives you one output, and for the same input always the same output. A procedure can do that too, but it can also give you different outputs for the same input, due to side effects.

So from that perspective functions are pure and procedures are impure?

One of the thinga I miss from my C++ days was the ability to mark functions as const, which made them fairly pure.

Being able to clearly mark which is which, but also to combine them easily, was very productive.

Yes, that is my understanding of the terminology, and how I try to use the terms (not always succeeding).