![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bolsonReading about Haskell, I read that something "isn’t a real function and can return different values" (meaning something doing file input) and am struck by how steeped in a particular branch of mathy jargon this is. Common usage of "function" by 99% of programmers doesn't care about this obscure notion of a 'real function'. Strictly functional languages are a weird little world with weird little biases.
Another abstraction too far? `map` isn't "create a list with the results of applying a function to a source list", it's "given a function from type-A to type-B, return a function from list-of-A to list-of-B". This is a weird twist of interpretation, but I think I see that's how they make thinking about lazy evaluation work.
Reading through the chapter on Monads I got bored of the details of the hoops they jump through in order to pretend their computation is functional. I say pretend because after years of C programming and kernel hacking I am accustomed to and really want languages that let me know what I am doing and what is really going on inside the computer. What is really going on inside the computer has to do with instructions and registers and memory locations. The Functional abstraction is a long ways away from that. I want nice convenient ways of organizing operations I want to do in programs, and maybe it's application driven, but the Functional abstraction doesn't mesh with the data and operations I want to do. I guess I can see small domains where it would be useful, but pretty quickly I always get frustrated because memory is changing and to pretend otherwise confounds me.
If languages are application domain driven, then I think my applications and languages are data-processing and control driven - growing out of FORTRAN and numeric simulation; and LISP and functional languages are symbolic-manipulation driven and perhaps grew out of classical Artificial Intelligence.
I think one of the things that bugs me about functional programming is similar to how religions bug me, they can be pretty metaphors and poetic and sometimes handy simplifications, but at some point they're not true. I want Truth! But there's that last nettlesome bit about handy simplifications. We need those too, more and more.
There are definitely some useful techniques developed out of functional programming. Just recently based on reading a paper about Scala I figured out a nice new thing I could do in Python.
Still I keep being haunted by functional programming. I got on the wrong side of that religion at CMU. I keep hearing the programming languages theory weenies talk about how great they are. They still keep getting news buzz as something important and worth studying. They still keep being the wrong tools for my jobs. End rant.
Another abstraction too far? `map` isn't "create a list with the results of applying a function to a source list", it's "given a function from type-A to type-B, return a function from list-of-A to list-of-B". This is a weird twist of interpretation, but I think I see that's how they make thinking about lazy evaluation work.
Reading through the chapter on Monads I got bored of the details of the hoops they jump through in order to pretend their computation is functional. I say pretend because after years of C programming and kernel hacking I am accustomed to and really want languages that let me know what I am doing and what is really going on inside the computer. What is really going on inside the computer has to do with instructions and registers and memory locations. The Functional abstraction is a long ways away from that. I want nice convenient ways of organizing operations I want to do in programs, and maybe it's application driven, but the Functional abstraction doesn't mesh with the data and operations I want to do. I guess I can see small domains where it would be useful, but pretty quickly I always get frustrated because memory is changing and to pretend otherwise confounds me.
If languages are application domain driven, then I think my applications and languages are data-processing and control driven - growing out of FORTRAN and numeric simulation; and LISP and functional languages are symbolic-manipulation driven and perhaps grew out of classical Artificial Intelligence.
I think one of the things that bugs me about functional programming is similar to how religions bug me, they can be pretty metaphors and poetic and sometimes handy simplifications, but at some point they're not true. I want Truth! But there's that last nettlesome bit about handy simplifications. We need those too, more and more.
There are definitely some useful techniques developed out of functional programming. Just recently based on reading a paper about Scala I figured out a nice new thing I could do in Python.
Still I keep being haunted by functional programming. I got on the wrong side of that religion at CMU. I keep hearing the programming languages theory weenies talk about how great they are. They still keep getting news buzz as something important and worth studying. They still keep being the wrong tools for my jobs. End rant.
