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

141–150 of 417 posts

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

#141

Post by WhompingWindows »

AlexandrB wrote: post #133

This video exists in an alternate reality where marketing departments do not. Many of these languages became popular not because of some intrinsic property, but because of a strong marketing push by one or more backing companies. There was a period of time, not so long ago, where "object oriented" was basically a checkbox on language marketing copy, and if your language didn't have it you would get scoffed at.

Can you give contemporaneous examples? I'm curious if there are companies out there actively pushing their language/framework, as opposed to sort of passively posting/updating without marketing.

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

#142

Post by js8 »

_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 databases, and it will happen here, too. Compilers with FP will become good enough in translating to the machine code so that almost nobody will really care that much.

The overall historical trend of programming is more/better abstractions for humans and better automated tools to translate these abstractions into performant code.

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

#143

Post by bryanphe »

_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 OCaml / ReasonML [2] - compiled to native machine code. (And we built a UI/Application framework called Revery [3] to support it)

There were very significant, tangible improvements in performance:

- Order of magnitude improvement in startup time (time to interactive, Windows 10, warm start: from 5s -> 0.5s)

- Less memory usage (from ~180MB to The tooling for building cross-platform apps on this tech is still raw & a work-in-progress - but I believe there is much untapped potential in taking the 'React' idea and applying it to a functional, compile-to-native language like ReasonML/OCaml for building UI applications. Performance is one obvious dimension; but we also get benefits in terms of correctness - for example, compile-time validation of the 'rules of hooks'.

- [1] Onivim v1 (Electron) https://github.com/onivim/oni

- [2] Onivim v2 (ReasonML/OCaml) https://v2.onivim.io

- [3] Revery: https://www.outrunlabs.com/revery/

- [4] Flambda: https://caml.inria.fr/pub/docs/manual-ocaml/flambda.html

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

#144

Post by fennecfoxen »

dooglius wrote: post #121
throwaway87537 wrote: post #77

Earlier quoted context omitted.

Streeter here. Although I don’t work directly with the FPGA stuff, it’s still a very, very small piece of the overall pie (and new). The motivation behind using Ocaml is mainly in its correctness(!) not because it’s fast (it’s not). See Knight Capital for a good example as to why. There are great videos on YT by Yaron Minsky that explain this better than I can.

> 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 one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.

Rumor on the outside suggests that Jane St uses OCaml for things like deploying software.

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

#145

Post by tom_mellior »

verttii wrote: post #139
Symmetry wrote: post #132

Earlier quoted context omitted.

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speedin…

The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner. Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a l…

> If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.

If the compiler only forces values that would be forced anyway, there shouldn't be a problem. Which is why GHC actually does it: https://wiki.haskell.org/Performance/Strictness

Strictness analysis is good and useful... and difficult and not magic.

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

#146

Post by stickfigure »

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.

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

#147

Post by soulofmischief »

strangenessak wrote: post #19
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…

> personally I find my brain works very much like a Turing Machine Exactly this. How baking a cake in FP looks like: * A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes. * A preheated oven is an oven that has been heated to 175 degrees C. * A prepared cake is batter that has been poured into prepared pans, where ba…

> In any case the point is this: I had some straight imperative code that was doing the same thing several times. In order to make it generic I couldn’t just introduce a loop around the repeated code, but I had to completely change the control flow. There is too much puzzle solving here. In fact I didn’t solve this the first time I tried. In my first attempt I ended up with something far too complicated and then just left the code in the original form. Only after coming back to the problem a few days later did I come up with the simple solution above.

There are two kinds of people, I guess. To me, this description simply encapsulates the process of being a programmer. Boo hoo, you had to think a little bit and come back later to a hard problem in order to figure it out.

I'm sorry, but that's literally how every profession which requires engineering skills plays out. And like other professions, after you solve a problem once you don't have to solve the problem again. It's solved. The next template Gabriel writes in that flavor will not take nearly as long.

Seriously, all of these points he raises against FP are entirely contrived, and come across as the meaningless complaining of an uninspired programmer.

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

#148

Post by verttii »

verttii wrote: post #139
Symmetry wrote: post #132

Earlier quoted context omitted.

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speedin…

The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner. Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a l…

Got it thanks, good info for me!

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

#149

Post by psychoslave »

AlexandrB wrote: post #133

This video exists in an alternate reality where marketing departments do not. Many of these languages became popular not because of some intrinsic property, but because of a strong marketing push by one or more backing companies. There was a period of time, not so long ago, where "object oriented" was basically a checkbox on language marketing copy, and if your language didn't have it you would get scoffed at.

Did you actually even skimmed the video? It does speak about large cash injection on the marketing side.

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

#150

Post by pryffwyd »

u801e wrote: post #60
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…

> Apart from my code, even most of my todos are simple step-by-step instructions to achieve something. > [...] > This could be why OOP/Imperative was often preferred over FP. Though this doesn't really explain why OOP is preferred over imperative (since the former doesn't really correspond to a set of step-by-step instructions).

The latest no-OOP imperative language with any kind of market share is C. So everything that's terrible about C: unsafe manual memory, portability issues, tooling, no generics or overloading, horrible ergonomics, 2nd class functions, globals everywhere, etc, are all forever associated with imperative programming. OOP was born at the time of fixing all those problems, so those languages were a big improvement in ways that had nothing to do with OOP. Now that all the top languages are multi-paradigm, only a puritan would avoid OOP, and they'd have a tough time interacting with libraries and frameworks. So every codebase is a little wishy-washy and OOP wins by default. Imperative has no advocates left in industry or academia, so most people don't even think of it as a defensible design decision.
Post reply on HN