Why Isn't Functional Programming the Norm? [video] • Hacker News Board

Re: Why Isn't Functional Programming the Norm? [video]

#161

Post by classified » Thu, Oct 17, 2019, 3:56 PM UTC

bryanphe wrote: post #143

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user! I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCam…

I couldn't have said it better myself. Thx for those links! And, yes, the compiler's flambda variant is an exquisite delight.

Re: Why Isn't Functional Programming the Norm? [video]

#162

Post by skohan » Thu, Oct 17, 2019, 3:58 PM UTC

classified wrote: post #88

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

I regularly read the assembly output of the OCaml compiler I'm using and there are very few surprises. The mapping from source to generated assembly is quite straightforward. You couldn't say the same for Haskell, though. So it depends on which FP language you're using.

Does OCaml give you enough tools to optimize around things like CPU-cache and memory management costs? It's one thing to know what kind of assembly is going to be produced by a block of code, but it's another thing to be able to get the machine to do exactly what you want.

Re: Why Isn't Functional Programming the Norm? [video]

#163

Post by hootbootscoot » Thu, Oct 17, 2019, 3:59 PM UTC

OO is merely a style of laying out imperative code for the compiler to put into proper linear order.

End of the day there are instructions emitted in a linear fashion and other instructions running (OS?) can provide an execution context ("Hi process, here's your memory area with pretend addresses do you can think it's all yours, you go over there to Core-2 and run at Z priority.")

OO is not particularly easy to learn WRT FP, but it does have the contextual advantage of having been delivered on the back of FAST compiled languages like C++.

Java runs as fast as the big money thrown into it's VM can make it run. If the JVM were dog-slow, you would see lower adoption of it.

Ocaml as used by corps like Jane Street etc,is not directly for running application code from (or rather, the application in question does code generation.)

High level languages could be expected to adopt either code-generational or Cython-style approaches. (Chicken Scheme, for example)

C++ merely has the historical accident of bridging 2 generational worlds of computing, hence you can find C++ full-stack.

Anyone for doing DSP purely in Ruby with no C-libs?

Re: Why Isn't Functional Programming the Norm? [video]

#164

Post by journalctl » Thu, Oct 17, 2019, 4:01 PM UTC

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

Unless you’ve written a modern, optimizing C/C++ compiler, you have absolutely no idea what kind of machine code a complex program is going to spit out. It’s not 1972 anymore, and C code is no longer particularly close to the metal. It hasn’t been for some time.

Re: Why Isn't Functional Programming the Norm? [video]

#165

Post by cryptica » Thu, Oct 17, 2019, 4:02 PM UTC

stickfigure wrote: post #146

cryptica wrote: post #115

OOP was designed to prioritize encapsulation at the expense of referential transparency. Functional programming was designed to prioritize referential transparency at the expense of encapsulation. You cannot have referential transparency and encapsulation at the same time. In order to prevent mutations (which is a requirement of FP), a module cannot hold any state internally; this necessarily means that the state mus…

I don't quite follow this. You can create (very complicated) immutable objects that encapsulate their state, and provide methods that return new immutable objects with different - and still fully encapsulated - state. Vavr is a good example.

Yes you can reduce and map a large state object into a smaller and simpler object before you pass it down to a child component but the encapsulation is still leaky because the parent component needs to know the implementation details of each action of a child component in order to use them correctly (for example, the parent component needs to know how the different actions of the child relate to each other in terms of how they affect the state); it creates a large contact area between components which creates tight coupling.

The idea of blackboxing/encapsulation is that the parent component should know as little as possible about the implementation of its child components.

Re: Why Isn't Functional Programming the Norm? [video]

#166

Post by classified » Thu, Oct 17, 2019, 4:02 PM UTC

classified wrote: post #91

gpderetta wrote: post #79

Earlier quoted context omitted.

"A FORTRAN programmer can write FORTRAN in any language"

And structured programming (including, of course, FP) is for quiche eaters!

For those who don't get the allusion:

https://web.mit.edu/humor/Computers/real.programmers

Re: Why Isn't Functional Programming the Norm? [video]

#167

Post by skohan » Thu, Oct 17, 2019, 4:05 PM UTC

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

> This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

I think things like real-time graphics are the exception not the rule. Most of the software run by users these days is in the context of a browser, which is implemented many layers of abstraction away from the machine. Much of the code running servers is also still interpreted scripting languages.

Don't get me wrong, I wish a lot more software was implemented with performance in mind, because the average-case user experience for software could be so much better, but a ton of the software we use today could be replaced by FP and perform just as well or better.

Re: Why Isn't Functional Programming the Norm? [video]

#168

Post by hootbootscoot » Thu, Oct 17, 2019, 4:08 PM UTC

agentultra wrote: post #119

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

I too have been programming professionally for nearly two decades. Much longer if you consider the time I spent making door games, MUDs, and terrible games in the 90s. I think functional programming gives you powerful tools to reason about the construction of programs. Even down to the machine level it's amazing how amortized functional data structures change the way you think about algorithmic complexity. I think la…

OTOH, think of the vast hordes of new developers exposed to lot's of FP and NOT having that background in Amiga and PC and bare-metal programming that you do.

FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. Let that sink in.

End of the day, the computer is an imperative device, and your training helps you understand that.

FP is a perfectly viable high-level specification or code-generational approach, but you are aware of the leaky abstraction/blackish box underneath and how your code runs on it.

I see FP and the "infrastructure as code" movement as part and parcel to the same cool end reality goal, but I feel that our current industry weaknesses are related to hiding and running away from how our code actually executes. Across the board.

Re: Why Isn't Functional Programming the Norm? [video]

#169

Post by erik_seaberg » Thu, Oct 17, 2019, 4:12 PM UTC

verttii wrote: post #92

mikekchar wrote: post #13

Earlier quoted context omitted.

Personally, I think JS is a fine functional language. Like you say, it doesn't have a good FP style system library, but it doesn't have a good anything style system library ;-) My main complaint is that currying is awkward. One thing I have discovered, though, is that closures are relatively slow (that is, unoptimised) in most implementations. In several implementations, they can also leak memory in certain circumsta…

Personally I find functional style awkward in js. Mostly because data is not immutable, there are no functional operators (composition, application etc.) and no algebraic data types + pattern matching. But most importantly, prototypal inheritance, in other words invoking the object's own methods as if they were pure functions is what really puts me off.

Object.freeze does give you shallow immutability in javascript, though it makes setters fail without throwing.

Re: Why Isn't Functional Programming the Norm? [video]

#170

Post by Sniffnoy » Thu, Oct 17, 2019, 4:12 PM UTC

Hm, so, Feldman claims that it wasn't the OO that made C++ popular, but rather the other features added on top of it that C with Classes didn't have. But one of those features that C with Classes didn't have was virtual functions. Without that, it's not clear how OO C with Classes really is. This potentially undermines Feldman's argument, because he hasn't ruled out the possibility that virtual functions were one of the key factors in C++'s success.