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

21–30 of 33 posts

Re: At the boundaries, applications aren't functional

#21

Post by mb20281 »

ezy wrote: post #11
jerf wrote: post #4

I think you can say that at the boundaries, applications aren't anything . I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell. In this case,…

Yea, I think a lot of programmers confuse the map for the territory. It's not only the data, but the program itself. Almost no one actually cares how a particular program was written or how it understands it's input and output -- we care that it works with some level of quality. How one gets that result is irrelevant in the end. It could be written directly in twisty assembly code. Do not care[1] Parts of these parad…

I think you might miss the audience here...this is talking /to/ programmers, after all - who decidedly do care about how the program is written, organized, etc.

I don't think anyone is making a "more correct" or even "more performant" argument here; maybe, a "more reliable" argument - but only by extension of "better organized, so less likely to include certain classes of bugs".

Re: At the boundaries, applications aren't functional

#22

Post by dragonwriter »

cryptonector wrote: post #18
jerf wrote: post #15

Earlier quoted context omitted.

"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 gener…

> 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.

> 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.

Re: At the boundaries, applications aren't functional

#23

Post by kadoban »

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…

If they type system (or at worst norms of the language/community) enforces it in parts of the code, that's _much_ more than a mental model.

Re: At the boundaries, applications aren't functional

#24

Post by xupybd »

To me the big difference between OO and FP is complexity management.

In OO complexity is hidden. So you don't have to deal with the complexity of the internal state of an object while using the object. It's a divide and conquer approach.

In FP complexity is constrained. Pure functions and immutable data make it easier to reason about the code. This allows you to see all the workings and not get overwhelmed.

Re: At the boundaries, applications aren't functional

#25

Post by marginalia_nu »

cryptonector wrote: post #6

> In 2011 I observed that at the boundaries, applications aren't object-oriented. For years, I've thought it a natural corollary that likewise, at the boundaries, applications aren't functional, either. On the other hand, I don't think I've explicitly made that statement before. The next and last paragraph does not then explicitly make that statement, instead ending with: > Functional programming offers an alternativ…

Theoretical arguments sound great and all, but where are the results? If OOP is such a dumpster fire and FP is so productive, where is all the FP code? Why are there so many OOP projects? It's not like FP is something we've just discovered. It's been around for decades.

Why does nobody appear to be having runaway success with it, if it is the superior paradigm?

Re: At the boundaries, applications aren't functional

#26

Post by cryptonector »

marginalia_nu wrote: post #25
cryptonector wrote: post #6

> In 2011 I observed that at the boundaries, applications aren't object-oriented. For years, I've thought it a natural corollary that likewise, at the boundaries, applications aren't functional, either. On the other hand, I don't think I've explicitly made that statement before. The next and last paragraph does not then explicitly make that statement, instead ending with: > Functional programming offers an alternativ…

Theoretical arguments sound great and all, but where are the results? If OOP is such a dumpster fire and FP is so productive, where is all the FP code? Why are there so many OOP projects? It's not like FP is something we've just discovered. It's been around for decades. Why does nobody appear to be having runaway success with it, if it is the superior paradigm?

> Why does nobody appear to be having runaway success with it, if it is the superior paradigm?

"Superior" doesn't always mean "winner".

Re: At the boundaries, applications aren't functional

#27

Post by cryptonector »

dragonwriter wrote: post #22
cryptonector wrote: post #18

Earlier quoted context omitted.

> 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.

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

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.

Re: At the boundaries, applications aren't functional

#28

Post by [deleted] »

marginalia_nu wrote: post #25
cryptonector wrote: post #6

> In 2011 I observed that at the boundaries, applications aren't object-oriented. For years, I've thought it a natural corollary that likewise, at the boundaries, applications aren't functional, either. On the other hand, I don't think I've explicitly made that statement before. The next and last paragraph does not then explicitly make that statement, instead ending with: > Functional programming offers an alternativ…

Theoretical arguments sound great and all, but where are the results? If OOP is such a dumpster fire and FP is so productive, where is all the FP code? Why are there so many OOP projects? It's not like FP is something we've just discovered. It's been around for decades. Why does nobody appear to be having runaway success with it, if it is the superior paradigm?

[deleted]

Re: At the boundaries, applications aren't functional

#29

Post by CrimsonCape »

marginalia_nu wrote: post #25
cryptonector wrote: post #6

> In 2011 I observed that at the boundaries, applications aren't object-oriented. For years, I've thought it a natural corollary that likewise, at the boundaries, applications aren't functional, either. On the other hand, I don't think I've explicitly made that statement before. The next and last paragraph does not then explicitly make that statement, instead ending with: > Functional programming offers an alternativ…

Theoretical arguments sound great and all, but where are the results? If OOP is such a dumpster fire and FP is so productive, where is all the FP code? Why are there so many OOP projects? It's not like FP is something we've just discovered. It's been around for decades. Why does nobody appear to be having runaway success with it, if it is the superior paradigm?

I think the explanation is the fundamental reality: computers are used to transform data, to store data, and to present data; FP determines that two of three reasons are impure and must be minimized.

John Carmack says that FP is a hinderance when rendering graphics, working with buffers, etc. So in respect to presenting data, UI and graphics will likely always be in an imperative lang.

Rich Hickey's (creator of Clojure) company Datomics (i.e. proprietary) uses his design for an immutable database which has only been around since 2013. He says that disk storage was so costly in the past but is now so cheap that the existing server industry is built atop this legacy of old ideas. So FP regarding storing data is likely in infancy.

Re: At the boundaries, applications aren't functional

#30

Post by dragonwriter »

cryptonector wrote: post #27
dragonwriter wrote: post #22

Earlier quoted context omitted.

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

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 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.

Post reply on HN