Untitled attachment

Notices where this attachment appears

1. Embed this notice
   ⚪ the lynne creacher (lynnesbian@fedi.lynnesbian.space)'s status on Wednesday, 13-Nov-2024 06:54:16 JST ⚪ the lynne creacher

   we often talk about designing programming languages to guide the programmer into the "pit of success": it should be easy to stumble upon the ideal behaviour. it obviously follows that it should be as difficult as possible to implement bad behaviour.

   an "ivory tower" language is so named because it gives the programmer a lovely tower to sit inside instead of having to interact with the disgusting (or, in FP terminology, "impure") outside world.

   it is known that causing any form of externally observable behaviour - console logging, writing to a file, causing the self-driving car to apply its brakes when a pedestrian is in front of it, flashing an LED (FP term: "IO") is impure. therefore, it is the moral imperative of any modern language to make it as difficult as possible.

   the ideal program takes no inputs and produces no outputs. you should not be able to observe any changes made to the impure world after running the code. the code is executed, a series of abstract tasks are performed, and it exits. we need not know what it "did". a program written in a functional language (or the modern replacement, rust) is de facto correct - we know just by compiling it that it will do the right thing. even executing it is an unneeded indulgence.

   ideally, code would not run on such a grotesque device as a "personal computer" at all - the ideal program is one that is described to you, and you "run" it by considering its behaviour.

   the day that haskell finally eliminates the undesirable side effect of causing bits in RAM to flip and your CPU's temperature to increase is the day programming as a field reaches its completion.