Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

At the boundaries, applications aren't functional

blog.ploeh.dk

Post reply on HN
Print view View original

31–33 of 33 posts

Re: At the boundaries, applications aren't functional

#31

Post by cryptonector »

evocatus wrote: post #8

Correct. In more mainstream language, quoth Gary Bernhardt, "functional core, imperative shell." Functional programming is a convenient fantasy, a highly restrictive and controlled environment that allows us to make large assertions about bodies of code - "no network IO can take place here"; "your inputs will most assuredly be numbers that can be added together." It's the equivalent of assuming the cow is a sphere [0…

Pure, deterministic code is easier to test than impure, non-deterministic code. There's no test environment setup for the former. No need to setup networking, DNS, PKI, etc. No need to have containers. For the "functional code" you just furnish inputs and compare to expected outputs.

Sort of like test vectors for cryptographic functions.

You still have to be careful to test all the edge cases (assuming you can't test the full domain of each function), naturally. But the fact that the functional core doesn't need setup means the tests of it have less startup and teardown overhead and so will generally run faster (unless they take so much time that setup overhead is in the noise).

As for the "imperative shell", you may be able to mock everything w/o having to change it, though you could also set up a test environment with all the external things it needs.

Re: At the boundaries, applications aren't functional

#32

Post by cryptonector »

dragonwriter wrote: post #30
cryptonector wrote: post #27

Earlier quoted context omitted.

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…

> 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 comp…

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.

Re: At the boundaries, applications aren't functional

#33

Post by dragonwriter »

cryptonector wrote: post #32
dragonwriter wrote: post #30

Earlier quoted context omitted.

> 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 comp…

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.

> Haskell's effectful operations are functions.

No, they aren't.

> Oh sure, not in the mathematical sense unless you model them as functions from World -> World.

Also, not in the syntactical sense.

They are “functions” in that “in certain other programming languages, the closest thing to something filling the same role are called ’functions’.”

But it's rather important to the way Haskell works that they are a different thing that operate at a logically different time, than functions.

> Sigh, yes, the compiled program is constant, but you know what I meant

Yes, you meant reduction, not compilation, and you meant non-function, not just constant, but Haskell programs do reduce to non-function constants.

Post reply on HN