Live data from Hacker News

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

youtube.com

111–120 of 417 posts

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

#111
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 I do not think this is true outside your domain. Amazon uses Java, C++ and Perl. At the time I was there majority of the website code was in Perl. Amazon one of the biggest companies on the planet.

Amazon needed to create AWS to be able to run all that perl performantly (joke).

Actually, a lot of programming language improvements have come from trying to make lisp performant.

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

#112
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…

Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.

There are really many places in code where you really don't care about performance that much. And in that case conciseness/expressiveness/correctness can be extremely valuable.

Also there are different aspects to performance, and when (for example) it comes to latency, a platform like Erlang/BEAM makes it particularly easy to get low latency in certain contexts without thinking about implementation much. In Haskell you can accomplish similar things with green threads. It will probably need more clock cycles for a given action than a tuned C implementation but that's not always what matters, and the code will probably be cleaner.

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

#113

Earlier quoted context omitted.

Python is perfectly fine for glueing together functionality that deals with high latency systems, like a data pipeline that executes queries that are running for minutes. It does not matter from the performance point of view if this code is in Forth or Python, but it matters from the point of view how long does it take to implement and how many engineering hours need to go into it. This is why Python is a good option…

I would not advertise Python as a language with good IDE support nor package management. I fight with both of these regularly. Also, Python is reasonably suited for gluing together other high performance systems, but not everything in the world is glue code, and as soon as you need to do something O(n) on your dataset, you’re either paying an enormous performance penalty or you’re not writing that bit in Python. Peop…

>> I would not advertise Python as a language with good IDE support nor package management.

VS Code, VIM works for me. Conda or PIP also. Not sure what is missing for you.

>> but not everything in the world is glue code

I never claimed that.

>> and as soon as you need to do something O(n) on your dataset, you’re either paying an enormous performance penalty or you’re not writing that bit in Python

Depends what you need to do.

My entire comment was about that details matter and you can't just blindly pick a language because of out of the box performance.

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

#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 must be passed to each module action from the outside. If state has to be passed to each module action from the outside, then this necessarily means that the outside logic needs to be aware of which state is associated with which action of which child module. If higher level modules need to be aware of all the relationships between the logic and state of all lower level (child) modules, that is called 'leaky abstraction' and is a clear violation of encapsulation.

Encapsulation (AKA 'blackboxing') is a very important concept in software development. Large complex programs need to have replaceable parts and this requires encapsulation. The goal is to minimize the complexity of the contact areas between different components; the simpler the contact areas, the more interchangeable the components will be. It's like Lego blocks; all the different shapes connect to each other using the same simple interface; this gives you maximum composability.

Real world software applications need to manage and process complex state and the best way to achieve this is by dividing the state into simple fragments and allowing each fragment to be collocated with the logic that is responsible for mutating it.

If you design your programs such that your modules have clear separation of concerns, then figuring out which module is responsible for which state should be a trivial matter.

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

#116
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…

Baking a cake is like being a compiler and a processor for recipe instructions. Of course it seems awkward from the perspective of a human baker because before you can process/bake you have to "compile" the expression to procedural steps. The computer does that without complaint.

This may illustrate that humans aren't good compilers of functional code, or in particular that humans aren't good at parsing poorly formatted functional code (again, computer parsers don't care about formatting). But I don't think it indicates that functional code isn't good for reading and writing, even for the same humans.

I also don't think this recipe resembles FP. Where are the functions and their arguments? There is no visible hieararchy. It is unnecessarily obtuse in the first place.

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

#117
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…

Are you suggesting that oop allows programmers to understand the assembly output?

Did you watch the video? The most popular language is JavaScript, which is only not functional but a quirk of history.

The video makes an argument for marketing being the reason.

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

#118
post #73
post #25

Earlier quoted context omitted.

might be interesting for you, Lips in production: https://tech.grammarly.com/blog/running-lisp-in-production

I used to work in a company that had part of the process written in Lisp and it was in true production. Once the (fp) guy left the company everyone else had to support that code. What a nightmare that was. No one wanted to touch it with a ten foot pole. Should we had another FP guru in our midst, that may have turned out differently. But everyone was in agreement that that part needs to be rewritten in a language tha…

Arguably, if you knew that A: there was code in Lisp and B: only one person knew how to support it, they should have either rewritten it while the one who understood it was still there, or had more people learn Lisp, or hired more people who knew Lisp. It shouldn't have been allowed to reach the point where someone quit without anyone else having a clue.

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

#119
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 laziness was the game changer here. And if you go all in with functional programming it's surprising how much baseline performance you can get with such little effort and how easy it is to scale to multiple cores and multiple hosts.

There are some things like vectorization that most functional languages I know of are hard pressed to take advantage of so we still reach out to C for those things.

However I think we're starting to learn enough about functional programming languages and how to make efficient compilers for them these days. Some interesting research that may be landing soon that has me excited would enable a completely pure program to do register and memory mutations under the hood, so to speak, in order to boost baseline performance. I don't think we're far off from seeing a dependently typed, pure, lazy functional language that can have bounded performance guarantees... and possibly be able to compile programs that don't even need run time support from a GC.

I grew up on an Amiga, and later IBM PCs, and that instinct to think about programs in terms of a program counter, registers, and memory is baked into me. It was hard to learn a completely different paradigm 18 or so years into my professional career. And to me, I think, that's the great accident that prevented FP from being the norm: several generations were simply not exposed to it early on on our personal computers. We had no idea it was out there until some of us went to university or the Internet came along. And even then... to really understand the breakthroughs FP has made requires quite a bit of learning and learning is hard. People don't like learning. I didn't. It's painful. But it's useful and worth it and I'm convinced that FP will come to be the norm if some project can manage to overcome the network effects and incumbents.

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

#120

So, I DO believe that this earnest high-level programmer is very earnest, I just don't think that he is starting with a full deck of cards. The manner in which he quickly brings up "C" and it's "killer app" being systems programming, and then jumps into the Javascript morass, it sort of suggests that he should start with first principles on how computers function. Computers are imperative devices. I don't think that…

Some of those sources are pretty daunting...
Post reply on HN