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

Functional programming is finally going mainstream

github.com

Post reply on HN
Print view View original

121–130 of 171 posts

Re: Functional programming is finally going mainstream

#121

Post by kaba0 »

kstenerud wrote: post #68

My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.

Would you mind describing what sort of platform have you experienced such? Was it actually measured that the FP part was responsible for the slow downs?

Let’s be honest, most typical software written by the industry is not the like which has a single hot loop. They do a bunch of different things, usually with small number of entries. I don’t see how FP would be a hindrance to this typical workload.

Re: Functional programming is finally going mainstream

#122

Post by kaba0 »

cageface wrote: post #33
LAC-Tech wrote: post #24

I'm not sure how I feel about this. If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up. But at the same time, I like objects. Almost all of mine are immutable. I went through a p…

The problem with state in objects is that in more complex systems you often need to change a bunch of related state at one time. When it's all bound up in individual objects that manage their own state this becomes very complicated.

Depends on the problem. Sometimes the locality of every state inside the function you write is beneficial, other times it makes it much easier to just not care about the state of a given thing, and let the encapsulation do its job. I just want to use it as per its contract.

Re: Functional programming is finally going mainstream

#123

Post by ncmncm »

benrbray wrote: post #120
ncmncm wrote: post #86

Earlier quoted context omitted.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

Can you give any examples of useful non-terminating programs? It seems to me all useful programs are terminating (or, we truncate some non-terminating procedure by some convergence criteria). The question is only whether we have the logical tools to prove termination at compile time.

Programs running in microcontrollers routinely do not terminate; they run as long as there is power. Even many ordinary programs run until they are killed.

You seem to confuse algorithms, which by definition must terminate, with programs, which do whatever the hell you like (and sometimes things you don't).

Re: Functional programming is finally going mainstream

#124

Post by ncmncm »

tadfisher wrote: post #109
ncmncm wrote: post #96

Earlier quoted context omitted.

That you can code certain solutions in a non-Turing-complete language is of identically null benefit.

Aside from being able to prove that the solution halts, you mean? You get a lot of side benefits as well with a halting program, such as provable limits in time and space for the totality of the program instead of just the functional core bits.

Maybe you are unable to prove properties of programs you have coded in Turing-complete languages. Many of us do, though. Routinely.

Quick, does this program terminate:

  int main() {}
? Can't prove it?

Re: Functional programming is finally going mainstream

#125

Post by ParetoOptimal »

kstenerud wrote: post #68

My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.

That's because step 4 is really:

> 4. Spend a lot of time ripping out FP components i'm less familiar with improving the performance of and replacing them with imperative code I have years of experience improving the performance of.

The cause of mist if these kinds of things will be dominated by familiarity for a long time.

Re: Functional programming is finally going mainstream

#127

Post by peanut_worm »

wrnr wrote: post #22

Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})

If you used line breaks I don’t see how thats any less readable than a block of procedural code.

Re: Functional programming is finally going mainstream

#128

Post by ParetoOptimal »

gnulinux wrote: post #45
anon_d wrote: post #18

Earlier quoted context omitted.

Functional programming doesn't actually compete with imperative programming. In practice, functional programming is a way of organizing imperative programs. Kind of like how OO is a way of organizing imperative programs. Almost all applications written in Haskell use the IO monad quite a bit, for example. Large Haskell projects generally use a lot of C libraries, and sometimes even directly include C code for perform…

I think part of the problem is no implementation has an exciting story about writing the "shell" part in a different language. I love love love writing purely functional code. Probably my favorite thing to do. But what a lot people who also like functional programming are missing is writing imperative code in functional languages almost invariably sucks. At the end of the day we all have to write the "shell" part of…

> At the end of the day we all have to write the "shell" part of our Haskell programs, and my programs always end up in a horrific mess of IO, State and other monads.

You can very successfully keep nearly all IO at the edges and do the heavy lifting in pure functions if you make it a goal.

Re: Functional programming is finally going mainstream

#129

Post by ParetoOptimal »

light_hue_1 wrote: post #78
GuB-42 wrote: post #16

Earlier quoted context omitted.

The biggest problem I have with functional programming is debugging. On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf. O…

> On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf. I think you're doing something wrong. Because your experience should…

> In functional programming you understand code without context. Everything is local. There's nothing to trace.

The problem is people don't trust it's really local even though it is.

Re: Functional programming is finally going mainstream

#130

Post by ParetoOptimal »

wrnr wrote: post #22

Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})

If you added line breaks I wouldn't be sure if you were arguing for or against functional programming.
Post reply on HN