@RobertHarvey Yeah, and in that space before "play" - you have an extremely malleable thing in the computation, you can destructure it into parts, compose other parts onto it, it's an extremely general thing a computation. In LISP macros that's what everything is, and in Haskell that's what everything is.
@WorldEngineer "The original programmers of the day used toggle switches, relays, vacuum tubes, and hand-assembled everything without Git". Now that sounds like a teenager. "Before cars people, I don't know, rode bikes or something."
the homoiconicity means that the starting representation, the ending representation, and the code that alters them, are of the same form; This means macros can effect macros, and it gives the monadic generality that a macro's result can have a macro applied to it (like how a LINQ result is an IEnumerable which can have a LINQ function applied to it; recursively composing computations because of the uniformity)
It all has this quality of purity about it. A purity that begins to break down when you have to start dealing with the thorniness of real-world issues like CSS incompatibilities, the aesthetics of forms, and cats walking on keyboards.
@RobertHarvey IO must be done, but at least there are ways to put it behind a barrier so you can enjoy that purity in as much of your code as doesn't need to interoperate with other systems. Such as code that creates computations for interoperating. :)
@supercat: You must be referring to e.g. the ability to modify mutable elements of an immutable array in some languages, notably Java and C#. My point is that if you write your code in a way that achieves immutability (i.e. by not writing to mutable objects), then you obtain the benefits of immutability, even if you don't get the enforcement of immutability. — Robert Harvey3 mins ago