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

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

youtube.com

Post reply on HN
Print view View original

241–250 of 417 posts

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

#241

Post by jcelerier »

js8 wrote: post #142
_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…

> FP will always occupy a niche because of where it sits in the abstraction hierarchy At some point in history, people stopped worrying about not understanding compilers, how they allocate registers and handle loops and do low-level optimizations. The compilers (and languages like C or C++) became good enough (or even better than humans in many cases) in optimizing code. The same happened with managed memory and data…

> At some point in history, people stopped worrying

Did they ? Because I keep seeing people around me who want to get into FPGA programming because they aren't getting enough juice from their computers. Sure, if you're making $businessapp you don't care but there is a large segment of people who really really really really want things to go faster, with no limits - content creation, games, finance... hell, I'd sell a rib for a compiler that goes a few times faster :-)

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

#242

Post by dsego »

6gvONxR4sf7o wrote: post #159
_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…

Just wait until this guy has to use something like SQL or Spark. They will always occupy a niche for exactly these reasons. Turns out it's a pretty big niche though. So big in fact, that maybe we shouldn't call it a niche. Python's ecosystem is built on this premise. Let some other language (C) do the fast stuff and leverage that for your applications. It's not a niche language, even though you don't have direct cont…

re python and scripting, afaik used to be known as "glue languages". not sure how true it is anymore.

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

#243

Post by [deleted] »

agoodpr838 wrote: post #227
_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…

Sure for hardware, real time, embedded use cases (and probably others), makes sense. Does it matter for data analysis and most web apps, infra as code, etc? Which data scientists do you know fetishize how Python is laying out memory? OOP is a hot mess. Yes, I know, you’re all very well versed in how to use it “right”, but the concept enables a mess. It’s the C of coding paradigms when it would be great to have a para…

[deleted]

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

#244

Post by nybble41 »

cryptica wrote: post #165
stickfigure wrote: post #146

Earlier quoted context omitted.

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

Do you have a more concrete example? So far as I can see there is no reason why functional programming would require a parent component to know anything about how its child components interact with the state. The tight coupling you are describing sounds completely foreign to me as a Haskell programmer.

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

#245

Post by gowld »

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…

Brilliant. Haskell was standing outside the door not until it was good enoguh to be an industry standard, but until industry standards dropped so low that it became competitive!

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

#246

Post by gowld »

fennecfoxen wrote: post #144
dooglius wrote: post #121

Earlier quoted context omitted.

> See Knight Capital for a good example as to why Not really, that was about incompatible versions of software talking to each other, which would not really fall under what is meant by "correctness".

While Knight Capital's problem was caused by incompatible versions of the software talking to each other, one of the reasons that happened was the deployment of the code was not correct. The SEC notes: > “During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no…

How does OCaml prevent you from deploying working code that you didn't want to run?

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

#247

Post by gowld »

lewisjoe wrote: post #6

Richard Gabriel’s famous essay “Worse is better” ( https://www.jwz.org/doc/worse-is-better.html ) is an interesting perspective on why Lisp lost to C. In a way, the same arguments (simplicity vs consistency vs correctness vs completeness) can be made for why functional programming lost to OOP. But those philosophical perspectives aside, personally I find my brain works very much like a Turing Machine, when dealing wi…

OOP is nothing like a Turing Machine.

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

#248

Post by johnisgood »

Jtsummers wrote: post #239
johnisgood wrote: post #230

Earlier quoted context omitted.

Speaking of correctness and performance, was Ada/SPARK ever considered before you guys picked OCaml? Hypothetically, would you consider Ada/SPARK now, especially that SPARK has safe pointers and whatnot?

SPARK was barely making waves when they selected OCaml. OCaml was much more established by that time.

Fair enough. Then they should probably just focus on the second question. :)

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

#249

Post by gowld »

pas wrote: post #49
mbrock wrote: post #39

Earlier quoted context omitted.

I actually don't know of any functional programming languages that don't have syntactic and semantic support for writing step-by-step algorithms.

Could you elaborate on this a bit? Basically calling a functions form an other is how a step-by-step algorithm would work in FP, no? And pattern match on what comes in, and return an immutable copy. For example you can put functions in a list, and push a datastructure through them, like a pipeline. edit: https://probablydance.com/2016/02/27/functional-programming-...

You miscounted the number of negatives in the comment you replied to.

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

#250

Post by hootbootscoot »

hootbootscoot wrote: post #240
eli_gottlieb wrote: post #223

Earlier quoted context omitted.

>End of the day, the computer is an imperative device, and your training helps you understand that. Well... it's complicated. A CPU is imperative. An ALU is functional. A GPU is vectorized functional.

end of the day, some poor schmuck has to get up and DO something...lol

I suppose that since one is still only talking about the external interface to any given hw execution unit (gpu, alu, fpu) one could always present it in whatever format was useful or trendy.

But I'll contend that it's much more productive to basically wrap low-level functionality as modules that higher-level languages could compose. One could then optimize individual modules.

The mechanism of composition should lay it out as desired in memory for best efficiency, and hence the probably need for a layout step, presuming precompiled modules. (it could use 'ld', for example) i'm not sure how you would optimize memory layout for black-boxes, but perhaps some standard interface..

Most people here are doing this already without knowing it, if you look into the dependencies of your higher level programming tools and kit.

End of the day OOP is a code-organization technique. FP is too. They are both useful. We still have complexity. Some poster above needing actor models etc, depends upon the scale I suppose. If one is considering a distributed healthcare application, or is one trying to get audio/video not to glitch etc.

Post reply on HN