How C accidentally locked programming into a single paradigm

[Paul Tarvydas]

...
We’re wasting brain-power inventing epicycles in order to crawl out of the corner we’ve painted ourselves into. When CPUs were wildly expensive, it made sense to waste brain-power instead of silicon power.

Now, though, we can stop doing that.
...
https://programmingsimplicity.substack.com/p/how-c-accidentally-locked-programming?r=1egdky

pt

[Mike Austin]

How do we stop doing that? A function is simply an abstraction, input => output. First class functions, closures, useful stuff.

[Paul Tarvydas]

> ... The goal isn’t to make functions unnecessary by abandoning computation. The goal is to make functions one tool among many, chosen when appropriate rather than by default. We need to remember that the function is an abstraction—and abstractions are supposed to serve us, not constrain us. ...

[The Function Trap: Why Your Favourite Abstraction Is Sabotaging Your Code](https://programmingsimplicity.substack.com/p/the-function-trap-why-your-favourite?r=1egdky)

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pilud/4b3847ec-9290-442e-81be-0eb4b8efba7bn%40googlegroups.com.

[David Barbour]

That's a well-considered response.

Though, it isn't the case that function abstractions strongly imply synchronous call-return control flow.

E.g. in languages with built-in support for lazy eval, coroutines, session types, backtracking, etc. the 'function' abstraction is far more loosely associated with control flow.

To view this discussion visit https://groups.google.com/d/msgid/pilud/659BA83A-BF79-41D8-BA44-F3B4803E38C7%40gmail.com.