Why Isn't Functional Programming the Norm? [video] • Hacker News Board

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

#231

Post by hootbootscoot » Thu, Oct 17, 2019, 8:25 PM UTC

socksy wrote: post #185

hootbootscoot wrote: post #168

Earlier quoted context omitted.

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." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

nope. end of the day there is a linear sequence of instructions being executed by any given part of the hardware.|

OO and FP are just higher-level ways of organizing source code that gets reduced to a linear sequence of instructions for any given hardware execution unit.

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

#232

Post by hootbootscoot » Thu, Oct 17, 2019, 8:27 PM UTC

socksy wrote: post #185

hootbootscoot wrote: post #168

Earlier quoted context omitted.

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." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

hardware is imperative at it's lowest level. sure, hey you can even say that the instructions are declarative if you are speaking of the perspective of the ALU with regards to stuff you send to an FPU, for example...

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

#233

Post by ychen306 » Thu, Oct 17, 2019, 8:28 PM UTC

flowerlad wrote: post #183

Functional programming is not new, it has been around for many decades. The reason it didn't catch on is because it doesn't map very well to how our brain works. Human brains are object oriented, so OOP is very easy to grasp. The real question is, why are people now taking a second look at functional programming. And the answer is Moore's law. Moore's law is coming to and end, and CPUs are not getting faster. Instead…

> Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.

This is not true.

Many algorithms are intrinsically imperative (e.g., quicksort). You can represent it using some monads in Haskell to hide this, but in the end your code is still imperative; and if you want to parallelize it, you still have to think about synchronization.

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

#234

Post by johnisgood » Thu, Oct 17, 2019, 8:29 PM UTC

flowerlad wrote: post #183

Functional programming is not new, it has been around for many decades. The reason it didn't catch on is because it doesn't map very well to how our brain works. Human brains are object oriented, so OOP is very easy to grasp. The real question is, why are people now taking a second look at functional programming. And the answer is Moore's law. Moore's law is coming to and end, and CPUs are not getting faster. Instead…

Why would you need functional programming for that? Ada has extremely easy-to-use language constructs for concurrency.

Just to dive into Ada/SPARK: https://docs.adacore.com/spark2014-docs/html/ug/en/source/co...

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

#235

Post by hootbootscoot » Thu, Oct 17, 2019, 8:31 PM UTC

socksy wrote: post #185

hootbootscoot wrote: post #168

Earlier quoted context omitted.

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." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

gpu just means lots of cores. the cores are composed of execution units too.

even the most exotic architecure you can think of is imperative (systolic arrays, or transport triggered architecture or...whatever)

there are instructions and they are imperative.

I can vaguely rememeber some recent iterative AI of some kind who had to produce a functioning circuit to do XYZ, and the final netlist that it produced for the FPGA was so full of latches, taking advantage of weird timing skew in the FPGA fabric and stuff, and no engineer could understand the netlist as sensical, but the circuit worked... I suppose when there's that level of non-imperative design, you can truly call it both declarative, and magic.

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

#236

Post by nybble41 » Thu, Oct 17, 2019, 8:33 PM UTC

falcolas wrote: post #187

6gvONxR4sf7o wrote: post #179

Earlier quoted context omitted.

Okay, so first of all this is an excellent joke. But it's not that great of an analogy. This quote chooses one of many FP syntaxes. It's cherry picking. It uses "a = b where c = d." That's equivalent to "let c = d in a = b." Let will allow you to write things like: let cake_ingredients = [butter, white sugar, sugar] batter = cream(ingredients=cake_ingredients, dish=large_bowl, condition=LIGHT_AND_FLUFFY) prepped_pans…

Perhaps it's the analogy leaking, but in baking, order of operations matters, and some operations must be done in parallel (pre-heating, based on initial oven state) to produce a good end product.

Yes, and this is one of the areas where functional programming really shines. An imperative program is defined as a series of ordered steps and the compiler can't (in general) reorder steps to optimize use of resources because the steps could have arbitrary side-effects.[1] The FP version is essentially a dependency graph which constrains the order of operations without mandating a specific final order. The pre-heated oven is needed for baking but not for the batter, so these parts can automatically be evaluated in parallel just by enabling the multithreaded runtime.[2]

[1] Certain primitive operations can be reordered but that depends on the compiler having access to the entire program. A call to a shared library function is an effective optimization barrier for any access to non-local data due to potential side effects.

[2] For the purpose of this example I'm assuming the unused `oven` variable was meant to be passed in to the `bake` function.

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

#237

Post by jcelerier » Thu, Oct 17, 2019, 8:34 PM UTC

yogthos wrote: post #208

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.

Here's a talk on making real world commercial games with Clojure on top of Unity. https://www.youtube.com/watch?v=LbS45w_aSCU

come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps

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

#238

Post by hootbootscoot » Thu, Oct 17, 2019, 8:36 PM UTC

eli_gottlieb wrote: post #223

hootbootscoot wrote: post #168

Earlier quoted context omitted.

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.

true, well that's complicated too, as that ALU likely runs microcode or has a lookup table, but presuming boolean hardware logic underlaying it somewhere, THAT level is declarative, not sure about what functional composition is involved here, but declarative programming of boolean hardware where the actual imperative activity is occurring.

maybe the physics is imperative too lol

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

#239

Post by Jtsummers » Thu, Oct 17, 2019, 8:36 PM UTC

johnisgood wrote: post #230

throwaway87537 wrote: post #77

Earlier quoted context omitted.

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?

SPARK was barely making waves when they selected OCaml. OCaml was much more established by that time.

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

#240

Post by hootbootscoot » Thu, Oct 17, 2019, 8:37 PM UTC

eli_gottlieb wrote: post #223

hootbootscoot wrote: post #168

Earlier quoted context omitted.

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.

end of the day, some poor schmuck has to get up and DO something...lol