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

221–230 of 417 posts

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

#221

Post by nobleach »

TomMarius wrote: post #59
onion2k wrote: post #2

JavaScript isn't a functional language itself, but you can use a functional library like lodash/fp ( https://github.com/lodash/lodash/wiki/FP-Guide ) on top of it to get all that lovely functional goodness in your frontend and node code. Using lodash/fp has made my frontend state management code a lot nicer, and I'm really only just starting out with it.

There is excellent TypeScript lib called fp-ts

I love everything except the docs. The docs rarely show practical usage. Most functions are just type definitions. This is a MAJOR blocker to anyone that might not have a mathematical background. I find this issue quite a bit with the FP world though. The old joke, "as soon as you understand monads, you instantly become unable to explain them" sort of holds true here. How would I know what I should use? You just have to know.

Just this morning, I had to resort to Stack Overflow for using an Either... a concept I thought I well understood. Turns out, the way I've done it in Scala might not be the norm.

Many programmers coming to this library are coming from JavaScript, so expecting them to understand some (or many) of these things, might not be the right approach. The author has gone to some great lengths to blog about the foundations of FP... so this might help a bit. I just wish the docs were fleshed out with more examples. (the repo is open sources.... I could put up or shut up here)

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

#222

Post by [deleted] »

chowells wrote: post #155
classified wrote: post #88

Earlier quoted context omitted.

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.

I absolutely can say that about Haskell. You have to actually learn the language, but it doesn't do anything unpredictable.

[deleted]

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

#223

Post by eli_gottlieb »

hootbootscoot wrote: post #168
agentultra wrote: post #119

Earlier quoted context omitted.

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

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

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

#224

Post by tom_mellior »

gpderetta wrote: post #184
tom_mellior wrote: post #96

Earlier quoted context omitted.

The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201 ) are not problems you will have in OCaml. Yes, OCaml has garbage collection. It's a very efficient GC…

My understanding is that OCaml is a decent imperative language when required and that's one reason why it can perform well. My usual issue with the 'you can avoid the GC by not allocating' claims in any language, is how much of the language is still usable? Which features of the language allocate under the hood? Can I use lambdas? pattern matching? list compression or whatever nice collection is available in the lang…

> Can I use lambdas?

Not ones that capture anything from the environment. I'm not sure about ones that don't, but I imagine you can use them.

> pattern matching?

Yes.

> list compression

List comprehensions, you mean? They don't exist in OCaml, but if they did, they would have to allocate a result list. So no.

> for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?

I don't think so, maybe someone else can chime in. But more importantly, this is a one-in-a-million use case that is a far cry from "functional programming is always bloated and slow and unpredictable". GC is well-understood, advanced, and comfortably fast enough for most applications. And for other cases, if you really need that hot innermost part, write it in C and call that from OCaml if you're paranoid about it.

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

#226

Post by jolux »

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

Jane Street does a fair bit of high-performance OCaml...

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

#227

Post by agoodpr838 »

_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 paradigm that pushes towards Rust, and reduces the chance for hot messes from the start.

Most of this work is organizing run of the mill business information. Why it works from a math perspective is more universally applicable and interesting anyway.

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

#228

Post by keymone »

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

> core part demands efficiency

what about development efficiency? maintenance efficiency? developer onboarding efficiency? there are many efficiencies companies care about.

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

#229

Post by nybble41 »

cr0sh wrote: post #180
blain_the_train wrote: post #117

Earlier quoted context omitted.

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.

The fun, and funny, and maybe (probably) even terrible, thing about javascript is that while it -is- functional, and (IIRC) always has been, historically it wasn't originally used that way! Only relatively recently have programmers embraced its functional aspects; prior to that it was mostly used as a procedural language. Then people started to used functional aspects of it to "shoehorn" it into allowing a quasi-OOP…

> Oh - and why not pass a function in and return one back

The "function" in "functional programming" is a reference to mathematical functions. Mathematical functions do not have side effects, and consequently are referentially transparent (the result doesn't depend on the evaluation order or on how many times the function is evaluated). Code with side effects is not a function in the mathematical sense, it's a procedure. The defining characteristic of functional programming is the absence of side effects. That isn't something you can just tack on to an imperative (or "multi-paradigm") language. No matter how many cosmetic features you borrow from functional languages, like closures and pattern-matching and list comprehensions, you still have the side-effects inherent in the support for imperative code, which means your program is not referentially transparent.

Haskell manages to apply the functional paradigm to real-world programs by essentially dividing itself into two languages. One has no formal syntax and is defined entirely by data structures (IO actions). This IO language is an imperative language with mutable variables (IORefs) and various other side-effects. The formal Haskell syntax concerns itself only with pure functional code and has no side effects. IO actions are composed by applying a pure function to the result of one IO action to compute the next action. Consequently, most of a Haskell program consists of pure code, and side-effects are clearly delineated and encapsulated inside IO data types at the interface between the Haskell code and the outside world.

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

#230

Post by johnisgood »

throwaway87537 wrote: post #77
typon wrote: post #68

Earlier quoted context omitted.

Jane Street wrote a compiler that converts Ocaml to Verilog which they run on FPGAs. The OCaml you write in that case is pretty different than what you write for CPUs.

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.

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?
Post reply on HN