5 ms·

Maybe its me being thick, but I can't honestly wrap my head around what the fundamental good thing in functional programming is. When ever I work in a functiona

Maybe its me being thick, but I can't honestly wrap my head around what the fundamental good thing in functional programming is. When ever I work in a functional language I just find myself missing objects. OOP just feel more eloquent to look at personally. Struct.function(arg1, arg2, arg3); feels more atheistically pleasing to my mental model of programming then function(struct, arg1, arg2, arg3); This means more complex function definitions. While I can define multiple .close(); functions, that only operate in relation to their connection type I.E.: tcpConnection, serialConnection can each call their own close(). In FP I have to actually state either: fn close<T>(&:<T>){ if(<T>::isType(tcpConnection)){ tcpConnectionClose(<T>); }else if(<T>::isType(serialConnection)){ serialConnectionClose(<T>); }else{ //throw exception } } Or I just make primitive calls to each connection type tcpConnectionClose(*); This just doesn't stroke me the right way. It feels like bulky, over necessary coding when you take into account objects exist. I'm interested in FP, I feel it has to offer something for people to jump on it, but I just don't get it.

deadghost 12y ago
fwiw, clojure supports polymorphism. http://clojure.org/multimethods http://clojure.org/multimethods I encountered this recently but I'll try to give a (bad) explanation. You'll call `function(thing, arg1, arg2, arg3);`. Another function will run on the arguments and return a dispatch value. For example, it will check what `thing` is and return `struct`. The `struct` version of that function is then run on the args and gives you your value. In this way you can define several `close` functions based on dispatch value instead of one monolith nested if/else `close`. I'm on the opposite side of the fence, OOP has never ever appealed to me. "Why would anyone want to use this crazy mess?" kind of thing. I'm sure I can learn to appreciate it with time but it's not a native paradigm to my mind. I only have experience with lisps when it comes to functional programming but the reason I enjoy it is that it's simple. You have functions and you have data. Functions transform data to more data and the two aren't tightly bound. If you pass a function a value it will always return the same result if you pass it the same value. THE clojure video: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy (I don't think he even says the word clojure in the entire hour presentation.)
sanderjd 12y ago
Not sure what language that is supposed to be, but in all the functional languages I've used, you would specify that T implements close and write an implementation for a TcpConnection and a SerialConnection, letting the compiler figure out which one to call when and obviating the runtime exception entirely.
- innguest 12y ago
  Let me stress your point to the parent: > letting the compiler figure out which one to call when and obviating the runtime exception entirely. That is how FP eliminates a whole category of bugs. You have to have "experience", which some love to boast, to know that it's better to have an else clause there and throw an exception. If you think that's basic knowledge you'd be surprised with how little do "experienced" programmers that get paid very handsomely actually know; I've met 30-year of experience programmers that do not believe that the final-else-then-exception pattern is a good idea, because they think "crashing the program is never good". So what ends up happening is of course the program ends up crashing anyway (supposing you have passed an invalid connection in that case) but now the stack trace is potentially much deeper than it needs to be, and therefore misleading. All stack traces lose their value collectively because now we can't tell the good ones from the bad. That can make debugging harder than it needs to be. But instead in FP, because it's a fundamentally different way to program, that situation doesn't even arise in the first place, obviating a solution. In FP things are modeled differently from OO, it's not just "procedures without an object jacket". The advantage here is the compiler verifies the "object" selection for you (which "class"/type of connection) and can provide some mathematical guarantees. Those guarantees are what metonymically "eliminate bugs". So we can rely less on the programmer and more on the compiler. You know, like it's meant to be. After all we are sitting in front of a computer, so we should just let it do its thing without telling it how. Turns out autonomy in coming up with a solution is good both for the programmer and for the computer (and then again for the programmer).
  - sanderjd 12y ago
    Thanks for the interesting expansion. This technique isn't actually unique to functional programming languages, but rather languages with good type systems and compilers. It just so happens that a lot of functional programming languages have that.
innguest 12y ago
That's great if every time you said "FP" you replace it with "procedural programming" because that's what you just illustrated. FP has nothing to do with procedural programming at all, it is fundamentally different and diametrically opposed to both procedural and object oriented programming, which are then both in the same group away from FP. You should look up some tutorials on FP if you want to understand what it means in practice.

deadghost 12y ago

fwiw, clojure supports polymorphism. http://clojure.org/multimethods http://clojure.org/multimethods I encountered this recently but I'll try to give a (bad) explanation. You'll call `function(thing, arg1, arg2, arg3);`. Another function will run on the arguments and return a dispatch value. For example, it will check what `thing` is and return `struct`. The `struct` version of that function is then run on the args and gives you your value. In this way you can define several `close` functions based on dispatch value instead of one monolith nested if/else `close`. I'm on the opposite side of the fence, OOP has never ever appealed to me. "Why would anyone want to use this crazy mess?" kind of thing. I'm sure I can learn to appreciate it with time but it's not a native paradigm to my mind. I only have experience with lisps when it comes to functional programming but the reason I enjoy it is that it's simple. You have functions and you have data. Functions transform data to more data and the two aren't tightly bound. If you pass a function a value it will always return the same result if you pass it the same value. THE clojure video: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy (I don't think he even says the word clojure in the entire hour presentation.)

sanderjd 12y ago

Not sure what language that is supposed to be, but in all the functional languages I've used, you would specify that T implements close and write an implementation for a TcpConnection and a SerialConnection, letting the compiler figure out which one to call when and obviating the runtime exception entirely.

innguest 12y ago
Let me stress your point to the parent: > letting the compiler figure out which one to call when and obviating the runtime exception entirely. That is how FP eliminates a whole category of bugs. You have to have "experience", which some love to boast, to know that it's better to have an else clause there and throw an exception. If you think that's basic knowledge you'd be surprised with how little do "experienced" programmers that get paid very handsomely actually know; I've met 30-year of experience programmers that do not believe that the final-else-then-exception pattern is a good idea, because they think "crashing the program is never good". So what ends up happening is of course the program ends up crashing anyway (supposing you have passed an invalid connection in that case) but now the stack trace is potentially much deeper than it needs to be, and therefore misleading. All stack traces lose their value collectively because now we can't tell the good ones from the bad. That can make debugging harder than it needs to be. But instead in FP, because it's a fundamentally different way to program, that situation doesn't even arise in the first place, obviating a solution. In FP things are modeled differently from OO, it's not just "procedures without an object jacket". The advantage here is the compiler verifies the "object" selection for you (which "class"/type of connection) and can provide some mathematical guarantees. Those guarantees are what metonymically "eliminate bugs". So we can rely less on the programmer and more on the compiler. You know, like it's meant to be. After all we are sitting in front of a computer, so we should just let it do its thing without telling it how. Turns out autonomy in coming up with a solution is good both for the programmer and for the computer (and then again for the programmer).
- sanderjd 12y ago
  Thanks for the interesting expansion. This technique isn't actually unique to functional programming languages, but rather languages with good type systems and compilers. It just so happens that a lot of functional programming languages have that.

innguest 12y ago

That's great if every time you said "FP" you replace it with "procedural programming" because that's what you just illustrated. FP has nothing to do with procedural programming at all, it is fundamentally different and diametrically opposed to both procedural and object oriented programming, which are then both in the same group away from FP. You should look up some tutorials on FP if you want to understand what it means in practice.