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

Functional Programming in C++ (2013)

web.archive.org

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Functional Programming in C++ (2013)

#41

Post by rootlocus »

brador wrote: post #6

I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.

I have a CS degree and I prefer immutable data structures and pure functions. If anything, I believe it might be the other way around, since holding a CS degree means you've had a FP course and you're more aware of the implications of multithreading, immutability and side effects. "Self taught"s are more likely to have an education from online tutorials, which are fairly shallow.

Re: Functional Programming in C++ (2013)

#42

Post by rootlocus »

nly wrote: post #33
femngi wrote: post #29

Earlier quoted context omitted.

It really irks me that the std algorithms library seems to have been designed without any consideration for usability given how much I would love to rely heavily on the generic algorithms it contains. For example consider the simple task of testing to see if an element exists in a container: if (std::find(container.begin(), container.end(), element) != container.end()) My fingers are now cramping and my eyes are cros…

Well the containers that have fast lookup (set, map and their unordered_ and multi_ counterparts), all have efficient .find() member functions. The general philosophy of the idealised STL is not to provide you with anything you can compose efficiently yourself. A 3-4 line template will will give you a terse boolean contains() method, but it won't give you any big-O guarantees, and having such a thing would encourage…

Holy cow, thank you so much for the lectures!

Re: Functional Programming in C++ (2013)

#43

Post by sago »

eli_gottlieb wrote: post #5
astazangasta wrote: post #2

I just can't get behind all of this. Sure, its great to be able to reason clearly because you can see your whole state, but its exhausting always carrying your context around like a hobo with a huge backpack full of junk. Am I mistaken?

The monad type-class operations carry the context around for you. You can just write in imperative-seeming do-notation. The difficult part is trying to combine monads.

Here's what I don't get with Monads, why I've not felt the need to create a Monad-like system in my (non Haskell) code.

The 'world' is carried on the back of one parameter, right? So if I want to run a function taking two parameters in a particular 'world', which parameter is the Monad? If both of them are, what if they disagree which world is used?

Perhaps I haven't reached the fabled epiphany of monads, but they seem to be just implicit state attached to a single value, and only a single value. I'm not sure what this implicit stuff is better than a system where you are explicitly passing the 'world' that each function needs.

Why is

roll(dieSides: Random) -> int

Clearer than

roll(random: Random, int dieSides) -> int

I get the passing of a world out of a function with a single value

getNumber() -> IO

or using the extra implicit state to represent other possible values, like

Maybe

but, using it to carry around state? That seems to me to be unnecessarily implicit.

What am I missing?

Re: Functional Programming in C++ (2013)

#44

Post by [deleted] »

rootlocus wrote: post #42
nly wrote: post #33

Earlier quoted context omitted.

Well the containers that have fast lookup (set, map and their unordered_ and multi_ counterparts), all have efficient .find() member functions. The general philosophy of the idealised STL is not to provide you with anything you can compose efficiently yourself. A 3-4 line template will will give you a terse boolean contains() method, but it won't give you any big-O guarantees, and having such a thing would encourage…

Holy cow, thank you so much for the lectures!

[deleted]

Re: Functional Programming in C++ (2013)

#45

Post by throwaway999777 »

its_me_ken_lai wrote: post #38
throwaway999777 wrote: post #16

Earlier quoted context omitted.

I thought functional programming[1] was associated with ivory tower CS researchers/enthusiasts? I guess it's been turned on its head for some reason. [1] At least the Haskell/ML kind.

The underlying concept will surface once you've had a chance to debug program states and that you realize you can't keep track of all program states. I had no idea about functional programming but soon realized that I was going for the same thing when trying my best to not keep instance variables in my objects.

You misunderstand me. I wasn't trying to diss FP but rather the naysayers who try to associate people who like FP with certain groups.

Re: Functional Programming in C++ (2013)

#46

Post by pekk »

saryant wrote: post #3
astazangasta wrote: post #2

I just can't get behind all of this. Sure, its great to be able to reason clearly because you can see your whole state, but its exhausting always carrying your context around like a hobo with a huge backpack full of junk. Am I mistaken?

Exhausting is being in this situation: object Foo { var x: Int = 0 def bar(y: Int) = x + y } And trying to figure out what bar will return at any given point.

Are you somehow not in control of how x is being changed? You seem to have said that literally any statefulness is "exhausting".

Re: Functional Programming in C++ (2013)

#47

Post by jcurbo »

astazangasta wrote: post #2

I just can't get behind all of this. Sure, its great to be able to reason clearly because you can see your whole state, but its exhausting always carrying your context around like a hobo with a huge backpack full of junk. Am I mistaken?

This isn't a strict definition, but I just think of it as turning the usual model inside out. You always have a state that you're modifying, if you're doing functional or imperative programming (or a mix). Usually you're "inside" the state, changing it via pokes and prods from within. (Think global/shared state typical of C/C++ programs) In FP you pass around a big ball of state and no modification happens outside of it (there is no global or shared state, or at least access to it is tightly controlled if it's not a pure language). The functions live 'outside' the state, so to speak. Programming this way was, to me, one of the major revelations of learning the functional style.

Re: Functional Programming in C++ (2013)

#48

Post by mlitchard »

varelse wrote: post #27
mlitchard wrote: post #25

Earlier quoted context omitted.

Here's the relationship. How can you guarantee your low-level code is correct? Here's one way. You have a language like Idris create a DSL that targets the machine you want. You can model what the set of correct programs in your domain look like, and then produce correct code. That's why functional programming in general, and dependent-type programming in particular, is useful for low-level problem domains.

That's not a problem. The application in question was a redesign of an MPI FORTRAN implementation that can produce the same outputs to within FPRE. To verify the low-level code, we just run in double-precision and make sure it matches to 1 part in 10e-9 so across 200+ daily conformance tests. Production mode runs in single-precision with 64-bit Fixed Point accumulation. And that's also been demonstrated to have numer…

It's not a problem for you, but it's a problem generally. That's why so many people are working to solve it.

Re: Functional Programming in C++ (2013)

#49

Post by currysausage »

dang wrote: post #14
vezzy-fnord wrote: post #9

This is from 2013, and the original title is "Functional Programming in C++". Moreover, Carmack never makes a statement that functional programming is the future anywhere in this article. The closest he says is "Formal systems and automated reasoning about software will be increasingly important in the future," which is a markedly different sentiment. That said, the problem of not understanding possible code states d…

Thanks re the title. Submitters: the HN guidelines explicitly ask you not to rewrite titles like this, unless they are misleading or linkbait. https://news.ycombinator.com/newsguidelines.html (Submitted title was 'John Carmack: Why functional programming is the future'.)

https://news.ycombinator.com/submit should have a link to https://news.ycombinator.com/newsguidelines.html. (Edit:) I know there is a link in the footer of every other page, but when you open the submit form in great excitement, it's easy to forget about that (as demonstrated by this submission).

Re: Functional Programming in C++ (2013)

#50

Post by gnuvince »

pekk wrote: post #46
saryant wrote: post #3

Earlier quoted context omitted.

Exhausting is being in this situation: object Foo { var x: Int = 0 def bar(y: Int) = x + y } And trying to figure out what bar will return at any given point.

Are you somehow not in control of how x is being changed? You seem to have said that literally any statefulness is "exhausting".

Anyone, anywhere could modify x, which is what makes reasoning about this code difficult. When your entire program is a collection of mutable state that can be mutated by any piece of code, understanding what's going on becomes really difficult if not impossible. One thing that people are adopting from FP is to limit what is mutable, and when possible make state explicit.
Post reply on HN