note to self: a function's parameter types can often be inferred by examining the functions it uses. if i could strengthen this to *always*, it would be awesome.

note to self: type (and parameter) compatibility should work the same way as go interface compatibility does

as real types are applied to an algorithm, the algorithm's range of valid inputs and outputs is determined by the limitations of the types

note to self: a program can be reduced to a system of simultaneous equations each describing either a direct map or a feedback loop in state space

an excellent talk about newsqueak, precursor to the go programming language. designer rob pike discusses fundamental concepts that newsqueak (and go) is based on. pike and co have picked up where dijkstra and hoare left off.

pike doesn't analyze this effect explicitly: but the ability to decouple a program's parts into concurrent communicating processes greatly simplifies the management of the program's state space... it's not just new ways to factor code. go has features that support both functional and concurrent construction.

these principles are very important; i expect the combination will trigger a major advance in program design.

i'd also love to see more of backus' work involved, when the time comes :)

note to self: map/filter/reduce is the assembly language of fp. list comprehensions are equivalent to for loops...

note to self: current implementations of exception / error handling are generally very awkward

note to self: use a dataflow description to program i/o and error handling.
e.g., a divide by zero is viewed as *failing to return data*.
Q: do all types of resource allocation failures make sense in this model?

note to self: objects have one state variable, and then attributes in addition. there's support for setting up and tearing down each state, exactly like constructors/destructors. in degenerate case of object with single state, they're equivalent to constructor/destructor.

Backus' Can Programming Be Liberated from the von Neumann Style?

this is *great* reading. backus is brilliant.
:D :D

an impressive discovery:
"Speculatively, the Curry–Howard correspondence may be expected to lead to a substantial unification between mathematical logic and foundational computer science"

note to self: there is no looping, only mapping aka "set" operations

note to self: objects appear to be "manifolds"

note to self: an algorithm describes twists and connectivity of a state space. this defines processing that will occur if the space is embodied in a real machine and symbols placed into the space.
dijkstra -- i think we're onto something, buddy :)
...
in considering the topology of the state space, time is treated as a dimension.
the shape of the space is independent of the data that's put in it; the shape defines processing.
the connections between sub-spaces are object methods.

the first programming language i was exposed to

includes a fascinating discussion on program transformation and "the compiler of the future" (which is *still* in the future)

recommended reading: EWD198

from Dijsktra's EWD32