3 ms·
And in a concatenative language, that would be quite literally: connect authenticate configure
by evincarofautumn 10y ago
And in a concatenative language, that would be quite literally:
connect authenticate configure
- kazagistar 10y agoHow is this better then implicit state? I have no idea what data was passed around here.
- evincarofautumn 10y agoIn typical concatenative code, a function usually has only 1–2 inputs and outputs, so it only ever uses a tiny part of the “implicit state” (typically a stack) being passed between functions. It’s not much different than configure(authenticate(connect(open()))); in a C-style language. Those functions might be returning and accepting all kinds of complex objects or tuples, but you can use purely local reasoning and just treat that expression as a pipeline of black boxes, as long as the inputs and outputs match up. Static types help a lot with this (and I’ve actually been working on a statically typed concatenative language for a while) but even basic arity checking (as in Factor) is enough to make it a very minor issue. To me, the point is not that you should avoid local variables entirely. Rather, it’s that most code doesn’t actually need local variables to be perfectly readable, because the most common dataflow patterns in regular business logic can be captured by simple composition of functions.