Redpill me on functional programming, Sup Forums

Redpill me on functional programming, Sup Forums.

Other urls found in this thread:

colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup
en.wikipedia.org/wiki/Persistent_data_structure
wiki.haskell.org/GHC/Memory_Management
gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php
prog21.dadgum.com/23.html
en.wikipedia.org/wiki/Expression_problem
wiki.haskell.org/Functional_programming#Functional_vs_imperative_languages
twitter.com/SFWRedditGifs

currying and fundamental functional concepts are an important part of writing an efficient algorithm

Have you ever designed any software ever?

Have you ever had to extend that software to add a new function to it?

Have you realize how much of a pain that usually is?

The true virtue of FP is that following 2 fucking basic rules: use only pure functions and immutable data structures. You somehow solved the biggest issue in enterprise software development... for free.

Isolated side effects.

oh yeah? and how can you make videogames with that? OOP is KING in videogame development

Fuck off and read up on it.

A butch of Autist never get things done.

Very easily, actually.

Also, why do you assume that OOP/Functional are necessarily orthogonal?

(not the same poster)

Can you elaborate on why / how it would be easy? I'm particularly interested from a roguelikedev perspective (map generation, cells, expected enemies, console output)

The term "functional programming" has been used by many people to mean many different things. People use it as a shorthand to refer to a style of programming the de-emphasizes observable mutable state (local mutable variables are fine (depending on who you talk to)), first-class functions that close over their environment (also called closures), and pervasive use of immutable (especially persistent) data structures.

In certain languages, programming in a functional style is difficult. Take C for example (without GNU or Apple extensions). C functions are not as powerful as functions in higher level languages. (Lisp, Python, JavaScript, Haskell &c). You can convert a function to a function pointer and perform an indirect function call through a function pointer, but you can't implement the equivalent of Haskell's `flip` in a portable way. (I think. If I'm wrong about this please correct me.)

If you actually want to learn something about functional programming, though, there's no substitute for picking *a* language and messing around with it.

if you're using pure functions and immutable structures, wouldn't that be equivalent to making everything a static method in OOP?

This ?

OOP brainlets avoid it because it means their broworkers will get fired once their managers realize they are not needed

colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup

No, it's not strictly equivalent because you can't dynamically create new static methods.

Most games are focused around an event loop. A user provides some input, something internally inside of the game is modified, and the user sees some consequences to that event. We might begin our design by associating relevant pieces of information together, i.e. we have some data that is used to identify a 'user'. We can create a type that encapsulates this information. That process is totally identical to OOP.

The advantages of functional approaches lie in:
After grouping relevant pieces of data, we describe operations on the new objects. Commonly (though not necessarily), the OOP world marches along and modifies the fields that have been created. This introduces a serious problem: the state-space of the program explodes, so we don't ever really understand any configuration of the system. Our best bet to debug problems is to step-through the execution of the system, which is just hard.

The functional approach is to define operations on the data that we created that does not result in object modification. This has a profound consequence on the simplicity of the code: to understand a function, all you have to do is look at the lines that immediately surround it.

Consider a typical example:
* map-generation: this is going to require some randomness, which purists will say is not purely-functional. We shouldn't care. Rogue-like games typically have several areas of different archetypes that might have some properties (i.e. monsters, treasures, etc.) We might begin by defining area-archetypse. Then, we could write a function generate-map that specializes on the archetype parameter and returns a new map.
* events: at the most basic core, to handle an arbitrary event you use the current configuration of the game (i.e. player data, map data, etc.) and logic to create a new configuration.

This isn't that different from OOP approaches. Implicit transitions have just become explicit, and so the system is easier to reason about.

OOP neither requires nor implies mutable fields. OOP is simply:
(i) Inheritance
(ii) Polymorphism
(iii) Abstraction
(iv) Encapsulation

Typically you *can* create anonymous objects that encapsulate the behavior you want.

You start out black and on a group of five and end up white and weird.

This post gave me a boner

At that point why not just make a map/level class that inherits from a game Object class with the generator in the constructor and the data and operations internally handled to clearly encapsulate the data. And have a simple flag on all your objects that can be set so that you can easily check at some point of the game loop to delete it from the tree of game objects.

uma

>immutable data structures
isnt that pretty heavy on memory due to how immutable collection operate?

Rust is the best functional programming language, mostly because it's the only fast one.

I seriously hope you are being sarcastic

Not necessarily.

well you dont operate with one memory block
you want to modify data you have to derive form it (copy)

But you get cheaper equality checking which is great for UI stuff

also see en.wikipedia.org/wiki/Persistent_data_structure

wiki.haskell.org/GHC/Memory_Management

Most people don't realize the crazy stuff ghc can do to optimize your code thanks to purity and lazyness. I've been told you can make programs as efficient as you want if you're smart about it, but I'm not, so I can't confirm yet.

Checkout Okasaki's data structures and Bagwell's. There is a small overhead with persistent data structures, but it really isn't a huge deal.

Since the memory is immutable you only need to keep references to the data and changed the ones that were altered. So if, for example, you had a some kind of tree and another variable that simply inserted an element like this:
a = someTree
b = insert a 1

Both a and b can be seen as references to completely distinct trees, but because memory is immutable, they can safely share most all of the memory. The only memory allocated is changing the reference to whatever node the value was allocated to. Scope is also a thing so all of this data will get GC'd eventually.

oh that makes sense

delicia

Carmack actually spoke in favor of FP
gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php
James Hague tried to make simple game using FP and discussed the challenges
prog21.dadgum.com/23.html

Writing pure functions is a good rule of thumb even in imperative languages.

>But GHC is able to efficiently manage garbage collection, so it's not uncommon to produce 1gb of data per second (most part of which will be garbage collected immediately).
1GB/s (one gigabyte per second)

>You somehow solved the biggest issue in enterprise software development... for free.
Gee, guess you solved the en.wikipedia.org/wiki/Expression_problem - time to get your Turing award, I guess?
Who knew we had a top-o-the-world Computer Scientist on gee

Redpills cause brain damage.

>I've been told you can make programs as efficient as you want if you're smart about it, but I'm not, so I can't confirm yet.
What a coincidence, I've been told this bridge in Brooklyn is a once-in-a-lifetime opportunity for investment!

I'm not american, I don't get the reference. Is it good?

"If you believe that, I've got a bridge to sell you"
What you've been told is not strictly untrue - the Gigantic Hadron Collider folks can optimize the shit of plenty of code patterns.
However, it's still a language that uses, nay, forces, immutable data structures everywhere.
While Haskell/OCaml have pretty awesome GCs (immutable DSs help here), most algos that can be implemented with in-place data mutations are most likely still going to end up being more expensive on them. Not to mention how you can introduce space/time leaks it a lot of places if you're not always vigilant, or well-experienced with Haskell.

In short, consider the hype, but don't take it as gospel. Trust but verify and all that.

>OCaml have pretty awesome GCs
Also, "muh 'multi-threaded GC coming soon(tm)'"

>most algos that can be implemented with in-place data mutations are most likely still going to end up being more expensive on them
Since I'm trying to stay unbiased here, it's important to note that other algos are going to end up being faster. E.g. plenty of stuff in C++ needs to do defensive copies because it doesn't have the same immutability guarantees that the Haskell language can provide.
Horses for courses, as usual.

>const doesn't exist

Bait for sure.

Clojure and ocaml are way faster

Multi-paradigm > my paradigm is da best for everything!

This.
A reason to use D or kotlin or ocaml

>const solves all problems, peeps chucked move semantics in C++11 for no reason

Functional Programming is not a silver bullet or useless.

Use it where you can but focus on just finishing your code and having it work correctly first.

minimalism > sepples-ism

Yeah, that's why I threw out everything out of my toolbox except a single screwdriver.
It may be awkward to use it as a hammer but at least it's minimalist.

scala can offer many! great! features! such as
- incompatible minor versions, so you need to publish libs for each minor, allowing a perpetual python2/3-like clusterfuck
- slow-ass build tool (also because it needs to uncluster above fuk at least partially)
- android? hah!
- process startup times? Hah!
- fp category theory architecture astronaughting haskell refugee fags fucking up the community
- "java++" pajeets fucking up the community
- sjw CoC fags fucking up the community
- drama
- trannies
- "muh best language evar" autists

It's really great stuff, absolutely not a waste of a great OOP/FP effort (dick riding odersky here)

almost forgot
>worthy contender for "shittiest compile times" with the Reigning Rust King

>almost 2018 and people still don't realize that what matters is not the language but the programs you write using it

Nobody said you should use Scala.
Isn't Scala the FP language that doesn't have TCO? What a joke.

Haven't tried Scala but have you ever heard of Idris?

>Nobody said you should use Scala.
nigga u tarded
I use Scala, like certain parts of it. I'm not enough of a brainwashed dogmatist fanboy to deny it's got shit parts too. Trade-offs are a thing in PL reality.
>Isn't Scala the FP language that doesn't have TCO?
aight, now I no u tarded fo realz.
- hascallator does TCO
- as a bonus: chuck in a @annotation.tailrec and "the compiler will issue an error if the method cannot be optimized into a loop."
>What a joke.
In plenty of places. Less of a joke than most langs in certain others.

>Idris
yup, coworker fucked around with it IIRC
>Exponential compile time · Issue #2344 · idris-lang/Idris-dev
Aight, dependent type folks are the big league of compile times, can't deny that :V

>what matters is not the language but the programs you write using it
false dichotomy, shit aint
- 0% language, 100% what you write
- 100% language, 0% what you write
shits a mix of the two, depending on which part's retardation's handicapping you

doing big-ass compilers/parsers/AST manipulators without sum types, exhaustive patmat etc's going to be a handicap.
doing embedded shit with dependent typing phd-math-grade elegant shit's going to be a handicap.

grab a lang that's not too crippling, timebox the "choose best tool" wankery, then do the code
gotta balance lang/non-lang effort / skill development

>doing big-ass compilers/parsers/AST manipulators without sum types, exhaustive patmat etc's going to be a handicap.
>doing embedded shit with dependent typing phd-math-grade elegant shit's going to be a handicap.
oblig counterpoint, since the above was the "lang is important too" side:

doing line of business crud enterprise bean shit - switching between java/c#'s not gonna solve your business analyst / req gathering
/ expectation mgmt deficiencies

Sure, I agree.
I don't expect GHC will do all the work for me and it's impossible to get all the same performance you can get using low level stuff.

I guess I just want people to see that Haskell is not any slower than bad C/C++ code, which is most C/C++ code. Writing good, optimal code in C is just as hard as writing fast code with mutable data in Haskell.

>I guess I just want people to see that Haskell is not any slower than bad C/C++ code,
Cool, can agree it's possible in some cases
>bad C/C++ code, which is most C/C++ code
bad in which dimension?
- sec vulns? sure
- mutable spaghetti mess? often
- performance? eh, I'd argue less often, -
- especially given that expensive things are often harder to do in see/plus than in higher level langs
- or when the prog is already in a resource-constrained env
>writing good, optimal code in C is just as hard as writing fast code with mutable data in Haskell.
seems to be a bit of an overly bold statement
- depends on a lot of factors - do your optimizer and your code abstractions mesh well together? Great, then you can get that "C+gcc faster than hand-written asm" effect. No? Get bent and suffer increased code complexity to eek out those few % extra perf.
- haskell is a lot more restrictive than C/++. Great for some stuff (plenty more optimizations GHC can do), not so for others - e.g. your use case and perf envelope is outside of what the compiler/lang can achieve, but can be done by devs - custom allocators or fancier mem mgmt schemes, etc.

This, FP is not a language it's a programming style.

>false dichotomy
There is no dichotomy in the post you mentioned.

>>what matters is not the language but the programs you write using it
>either the language matters, or the programs you write using it
>either this or that
>(implied) no other option!

>There is no dichotomy in the post you mentioned.
must I spoonfeed you everything?

>FP is not a language it's a programming style
not even a well agreed-upon approach
is it
- use only functions, no object-attached methods?
- lang has first class functions?
- lang has type-checked first class functions?
- HOF?
- lang has immutable data structures?
- lang only allows immutable data structures?
- functions can be pure?
- functions can be forced to be pure at compile time?
- all functions must be pure?

not to forget:
- no global state allowed?
- no side effects allowed? (kinda overlaps w/ all functions must be pure tho)

Functional Programming is basically autism outside of a few contexts (e.g. parallelism). Autists have a hard time understanding mutable variables of the world. They loudly say "HI ETCHUBATSU" in one scenario, and they get a cautious welcome from a BBC-show host. In another instance they say again, "HI ETCHUBATSU", and the response is a mother cowering in the corner yelling, "Don't hurt me!" Yes, he had just beat up his mother in a fit of autistic rage just a few moments before. But given the same input, he expects the same output.

No, you should just shut up to avoid looking stupid.

>not even a well agreed-upon approach
That's because most people who advocate for FP don't understand what it is. FP merely is an attempt at implementing lambda calculi. Your points can all be deduced from that.

finally someone who understands these poor souls

>No, you should just shut up to avoid looking stupid.
this is totally not what someone would say when they realize how retarded the shit they wrote was

it's ok to admit your post was retarded mate, we're good people here and we'll mock you less if you do it, compared to doubling down sjw style

Hilarious.

>That's because most people who advocate for FP don't understand what it is.
yep
>FP merely is an attempt at implementing lambda calculi.
"those other explanations are wrong. Here is mine, and it's the correct one. I present no supporting arguments, because it's obvious"
>Your points can all be deduced from that.
"and here's how what you're saying actually agrees with me"

I know, got a good chuckle of that initial bait of yours. Made me post, you rascal

Literally a wikipedia search away from not making a retarded post.

>thinks that wacopedians with their autist-edit-wars are the definitive source on anything, instead of a semi-decent reference list

counter-point: wiki.haskell.org/Functional_programming#Functional_vs_imperative_languages
>Many programming languages support programming in both functional and imperative style
>ocaml: functional: yes, side effects: yes
nigga I claim all the semantics-warring tards have different definitions of FP.
You unironically appeal to Wikipedia's one and say that's the definitive definition, yet there equally (un)authoritative sources all over the place showing misaligned definitions.
you can't be this retarded

do you like curry but hate indians? then you'll love it

>language supports both IP and FP
>both as in two different things
>still thinks that supports his post
Literally subhuman.