[cryptonector]

> I think you can say that at the boundaries, applications aren't anything.

I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially).

That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily tested).

[dragonwriter]

> I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially).

Well, side-effecting, yes, because that's literally how we define boundaries.

Sequentially? Not so much; concurrency (whether asynchrony or true parallelism) is important largely because simple sequential behavior doesn't capture what happens naturally at the boundaries well. (I suppose on an individual boundary, defined in the right way, there is likely to be a sequencing constraint, but not in aggregate across the boundaries of the system.)

[cryptonector]

You can parallelize as much as you want, but remember, you can't go faster than the slowest serial code. There will be some serial code. Again, I'm talking about order of steps in processing events that themselves may not arrive in any particular order.

[jerf]

"I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially)."

You may be able to; I can't. I have a number of incoming event streams that are not necessarily ordered.

Now, like I said, you don't implement all code everywhere for all possible missteps, so you may have specific apps that get away with assuming orderedness. But it is not a general thing you can rely on.

[cryptonector]

> I have a number of incoming event streams that are not necessarily ordered.

That doesn't make the application not-procedural. If it's having side effects, it's procedural in a sense.

Order, here, is not about inbound event order, but about ordered steps in processing any one event.

[dragonwriter]

> That doesn't make the application not-procedural. If it's having side effects, it's procedural in a sense.

“Procedural” is a structural paradigm; unstructured imperative code (old-school BASIC) has side effects but is not procedural in any sense (it is part of the broader category of imperative languages.) Also, “procedural” (or “imperative” or “functional”) is an attribute of programming languages, not applications/systems: Haskell is a pure functional programming languages, in which evaluating functions has no side effects, but it can define systems that have effects.

[cryptonector]

Perhaps I should have written "imperative" rather than "procedural", except no one really writes imperative non-procedural code now.

> Also, “procedural” (or “imperative” or “functional”) is an attribute of programming languages, not applications/systems:

It can be an attribute of programs regardless of language. It is possible to write functional-style code in C and procedural code in Haskell (just do everything in the IO monad!).

> Haskell is a pure functional programming languages, in which evaluating functions has no side effects, but it can define systems that have effects.

That's a bit of a fiction. Pure functions are pure, yes, but you can have impure functions -- Haskell is only interesting because you can have impure functions (otherwise every Haskell program would compile down into a constant), and what's really interesting about Haskell is the ideas that have evolved in its community about how to deal with impure functions.

[dragonwriter]

> Pure functions are pure, yes, but you can have impure functions

Not in Haskell, you can't.

> Haskell is only interesting because you can have impure functions

No, it's interesting because it provides a way of representing series of effectful operations that are distinct from its functions, which are pure.

> otherwise every Haskell program would compile down into a constant

Every program in any language that is compiled compiles down to a constant (which is, itself, usually a program, often an imperative one in a native or virtual machine language); but in Haskell, each program is (in the model of the language, not merely what they compile to) normally a constant, non-function expression, most commonly of type IO ().

It's true that values of type IO a are isomorphic to “impure nullary functions returning a” in a language which has impure functions, but they aren't functions in Haskell, and can't be called from functions, they can only be operated on as values within the language.

[cryptonector]

Haskell's effectful operations are functions. Oh sure, not in the mathematical sense unless you model them as functions from World -> World.

> Every program in any language that is compiled compiles down to a constant ...

Sigh, yes, the compiled program is constant, but you know what I meant: a constant value, such as a number, that the program is expected to output. Let's not be this pedantic.

[munk-a]

Things might be sequential at the boundaries or they might not. A lot of hardware interacting applications are forced to handle concurrent and out of order inputs that are expected to be processed in a particular order.

Really, since the boundary is where we push all the awful stuff - that boundary (depending on the application) can be any sort of terrible.