←back to thread

389 points kurinikku | 1 comments | | HN request time: 0.216s | source
Show context
asah ◴[] No.42166440[source]
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!)

replies(4): >>42166621 #>>42168544 #>>42168689 #>>42169746 #
1. lmm ◴[] No.42169746[source]
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.