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

351–360 of 417 posts

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

#351

Post by psychoslave »

hevi_jos wrote: post #94

Because it is not the best solution for most computer problems. Simple as that. I am a functional and OOP programmer myself. I find functional way more elegant for modeling most mathematical problems, but OOP way better at modeling real life things with states. OOP and states introduce lots of problems and complexity, but the solution is not removing states, or a series of complex mathematical entelechies. In fact "r…

>(dynamic)States exist in real life. Temperature, pressure, height, volume, brightness, weight...

It's more like, states better match our more common way to model our sense-data. It's easier to grasp for us, but it doesn't mean it's the way that will cause provide the best desirable results.

If you take the example of mass in physic, most of the time it's perfectly fine to deal with it as an first class attribute of an object. But it's not how Higgs mechanism aboard the notion.

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

#352

Post by pjmlp »

nineteen999 wrote: post #304
spamizbad wrote: post #255

Earlier quoted context omitted.

Fun fact: C used to be considered a high-level language. Now everyone talks about it being "close to metal" which to olds like me is a dead give-away the person either doesn't know C or doesn't know the "metal". Most of the stuff people think of as being the "metal" in C are, in many cases, virtual abstractions created by the operating system. Embedded development w/o dynamic memory allocation less so... but that's n…

Well it depends on what side of the kernel/userspace boundary you are talking about doesn't it. While C for userland programs may need to conform to the operating system's libc and system call interface abstractions, on the other side of the syscall boundary is C code (ie. the kernel) that is indeed very "close to the metal".

Except that C's abstract machine is closer to a PDP-11 than an modern i7/ARM are doing.

So unless you are doing PIC programming, that "close to the metal" is very far away.

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

#353

Post by jstimpfle »

grumpyprole wrote: post #192
Scarbutt wrote: post #181

Earlier quoted context omitted.

I would say "real time graphics" is one of the niches FP is not well suited for, most business software doesn't need to work at the level of the machine.

There is certainly prior art for complex games running smoothly in Haskell: https://wiki.haskell.org/Frag This particular solution used functional reactive programming, essentially a composition of signal/event processing functions/automatons.

If I remember correctly, in that thesis the author mentioned explicitly that the game didn't run very fast. If you watch the video from 2008, the in-game stats list framerates >60fps but the game itself is very laggy. Maybe there is a separate renderer thread?

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

#354

Post by pjmlp »

skohan wrote: post #162
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.

Does OCaml give you enough tools to optimize around things like CPU-cache and memory management costs? It's one thing to know what kind of assembly is going to be produced by a block of code, but it's another thing to be able to get the machine to do exactly what you want.

You can analyze Assembly code just like in any other AOT compiled language.

Have a go at in Godbolt, https://godbolt.org/

OCaml also integrates with perf on Linux,

https://ocaml.org/learn/tutorials/performance_and_profiling....

Some performance tips from an old partially archived page.

https://hackerfall.com/story/writing-performance-sensitive-o...

And if you are feeling fancy, doing some pointer style programming

https://ocaml.org/learn/tutorials/pointers.html

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

#355

Post by pjmlp »

agentultra wrote: post #119
_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…

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…

I am fully on board with you.

Learned to code in the mid-80's, Basic and Z80 FTW.

Followed up by plenty of Assembly (Amiga/PC), and systems level stuff using Turbo Basic, Turbo Pascal, C++ (MS-DOS), TP and C++ (Windows), C++ (UNIX), and many other stuff.

I was lucky enough that my early 90's university has exposed us to Prolog, Lisp, Oberon (and its descendants), Caml Light, Standard ML, Miranda.

Additionally the university library allowed me to dive into a parallel universe from programming ideas that seldom reach mainstream.

Which was great, not only did I learn that it was possible to marry systems programming with GC enabled languages, it was also possible to be quite productive with FP languages.

Unfortunately this seems to be yet another area that others only believe on its possibilities after discovering it by themselves.

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

#356

Post by asjw »

gpderetta wrote: post #175
journalctl wrote: post #164

Earlier quoted context omitted.

Unless you’ve written a modern, optimizing C/C++ compiler, you have absolutely no idea what kind of machine code a complex program is going to spit out. It’s not 1972 anymore, and C code is no longer particularly close to the metal. It hasn’t been for some time.

Never written even a simple C compiler, but I, and most c++ programmers that care about performance I think, do have a decent idea what code g++ is going to generate.

But g++ is probably better than you at producing fast code for whatever architecture you run it on.

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

#357

Post by pjmlp »

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…

> FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. Let that sink in.

Not really.

"Confessions Of A Used Programming Language Salesman, Getting the Masses Hooked on Haskell"

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....

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

#358

Post by vbarrielle »

shadowgovt wrote: post #207
tick_tock_tick wrote: post #158

Earlier quoted context omitted.

They already said they were working in games. None of what you said applies to that field.

I have a suspicion this is only semi-true. For controlling what the CPU and RAM are doing? Yes. The graphics shader, on the other hand, is a pipeline architecture with extremely tight constraints on side-effects. The fact the shader languages are procedural seems mostly accident of history or association to me than optimal utility, and the most common error I see new shader developers make is thinking that C-style sy…

Not exactly shaders, but for GPGPU stuff, futhark [0] seems to show that a functional paradigm can be very good to produce performant and readable code.

[0] https://futhark-lang.org/index.html

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

#359

Post by blub »

Supermancho wrote: post #295
chubot wrote: post #273

Earlier quoted context omitted.

Sure I get that, but I'm saying your statement about "the overall historical trend" is wrong, or at least fails to capture a large part of the truth. At some point in history, people stopped worrying about not understanding compilers This part is misleading too -- I would say there is a renaissance in compiler technology now. For the first 10 years of my career I heard little about compilers, but in the last 10, JS E…

Once parallel execution became part of every design discussion that had a performance concern, the vast majority of programmers stopped caring (and consequently talking) about compilers. Who cares if you can do 36k requests/s to my 18k if I can do 36k across 2 or 3 machines? I pass that on to the customer. Why try to hire for or wait around for an optimization trick to double performance (that will likely never be re…

You're simply used to working in environments where technical excellence doesn't exist. In such environments performance is not a big concern, but neither is quality in general...

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

#360

Post by alisiddiq »

iLemming wrote: post #334
pbreit wrote: post #290

To this newbie, procedural is ===SO=== much easier to understand.

Actually it's the other way around. For someone who is not exposed to programming at all, it is much easier to pick up a language like Clojure. This is not merely my opinion - I have seen it multiple times, with different people. Julie Moronuki who never had any exposure to programming at all and has a degree in linguistics decided to learn Haskell as her first programming language, just as an experiment. Not only sh…

I only had experience of coding in Matlab in university, and started learning Clojure in my first job. It was very intuitive.
Post reply on HN