buc.ci is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.

This server runs the snac software and there is no automatic sign-up process.

Admin email
abucci@bucci.onl
Admin account
@abucci@buc.ci

Search results for tag #sideeffects

1 ★ 3 ↺
Anthony boosted

[?]Anthony ยป 🌐
@abucci@buc.ci

Heads up: there's body shaming and ableism in what follows. [SENSITIVE CONTENT]John Backus titled his 1977 Turing Award lecture to the ACM Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs. Section 1 is titled:
1. Conventional Programming Languages: Fat and Flabby
In the abstract, he states:
Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word-at-a-time style of programming inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions
and later
For twenty years programming languages have been steadily progressing toward their present condition of obesity
doubling down on the body shaming and ableism. He clarifies later in the lecture that what he means by "von Neumann programming language" is one with assignment statements and manipulation of variables. Applicative (i.e. functional) languages are what he means to contrast with these stateful languages.

Several figures of that time, including Peter Landin of "the next 700 programming languages" fame, were unashamedly in love with the lambda calculus and the prospect that it could usher in a full algebraization of computer programming. Backus is interesting because here in a high-profile lecture he's explicitly referring to issues of state as making programming languages "fat" and "flabby". I suspect many of his peers felt similarly even if they weren't using such nakedly ableist metaphors.


    1 ★ 0 ↺

    [?]Anthony ยป 🌐
    @abucci@buc.ci

    I came across another functional programming article about strategies for "managing side effects".

    For the uninitiated, what are typically called side effects include:

    • Input/output (to the screen, to/from a disk drive, to a printer, to/from the internet, etc.)
    • Relatedly, interaction (with the mouse, with the keyboard)
    • Statefulness ("remembering" data in RAM)
    • Parallelism (doing more than one thing at a time) and asynchrony (doing things out of order)
    In other words, what writing on functional programming refers to as a side effect is typically what a program is for. Without these "side" effects, the program would be a complicated way to make your CPU warmer. Without "side" effects, you would have no way to impact what the program is doing: not through the keyboard or mouse, not through the contents of files, not through values in the computer's memory. Nor would you have the ability to observe what the computer is doing: not on the screen, not in logs or other files, not by observing the computer's memory. You would have no way to interrupt the program, either, since doing that would require asychrony.

    In what sense, then, are they "side"? And what on earth is being "managed"? Isn't that what we mean by "programming"?


      about this site - powered by snac/2.86