Functional programming thread

I'm working on my first genetic AI in newLisp.

Pretty much going to playing a modified version of rock paper scissors, but not quite. I would also say I'm not being very functional though, but more than usually.

Im not a hardcore user yet, but im certainly starting to take a liking to it.

The conceptual simplicity of immutability is a great productivity-win, as is the generally superior type systems and inference found in functional languages.

That said, a computer is fundamentally about mutating things; wether its your keyboard input buffer or the pixels on your screen. People who try to use it for everything are clearly out of their mind, in my humble opinion, but given smooth interoperability with languages better suited to that role, its quite awesome (F# ftw, obviously)

Oh yeah; im using it mainly for prototyping scientific computing type of things. Or computing them altogether, if it doesnt pay to translate the algorithm to something more performant.

On the subject of functional programming, I feel the term has a rather curious meaning. Maybe its because im not a computer scientist/linguist, but I dont really see the necessary connection between lazy computation, function composition and so on, and immutability. I think those are pretty much the pillars of what is regarded as functional programming, but each of these seem like independently useful paradigms.

I really like the pragmatic approach D takes to functional constructs; for instance, allowing local varaiables to be mutable in a function marked as pure, a type system with a useful notion of immutability, and in general providing quite seemless and elegant interop between all these paradigms. EDIT: and, I should add, a metaprogramming implementation that allows for sugary sweet lazy computation without it being a built in language constraint.

On the subject of functional programming, I feel the term has a rather curious meaning. Maybe its because im not a computer scientist/linguist, but I dont really see the necessary connection between lazy computation, function composition and so on, and immutability. I think those are pretty much the pillars of what is regarded as functional programming, but each of these seem like independently useful paradigms.

Immutability isn't so much a goal in itself, I think, as a way of ensuring referential transparency. If you can write all over the place so that the semantics of a function depend on what code was executed before it, you no longer have a function in the mathematical sense. Even Haskell allows you to mutate variables all over the place, as long as it's done locally in the ST monad (computations in which can be called from pure code) or in the IO monad. Lazy evaluation is just neat in itself and is enabled by referential transparency, but doesn't really contribute in making functions more like their mathematicla counter parts other than enabling you to express infinite concepts better.

That said, a computer is fundamentally about mutating things; wether its your keyboard input buffer or the pixels on your screen. People who try to use it for everything are clearly out of their mind, in my humble opinion, but given smooth interoperability with languages better suited to that role, its quite awesome (F# ftw, obviously)
[/quote]Are you referring primarily to performance concerns or to the clarity of code that's inherently mutable?

Immutability isn't so much a goal in itself, I think, as a way of ensuring referential transparency. If you can write all over the place so that the semantics of a function depend on what code was executed before it, you no longer have a function in the mathematical sense. Even Haskell allows you to mutate variables all over the place, as long as it's done locally in the ST monad (computations in which can be called from pure code) or in the IO monad. Lazy evaluation is just neat in itself and is enabled by referential transparency, but doesn't really contribute in making functions more like their mathematicla counter parts other than enabling you to express infinite concepts better.
[/quote]
I see your point wrt 'making things more like mathematical functions'. Indeed immutability is directly implied by that. But even if you didnt give a shit about that, referential transparency is an awesome concept all by itself, so I think its a shame it has this status of kindof a freak functional thing.

Are you referring primarily to performance concerns or to the clarity of code that's inherently mutable?
[/quote]
I dont know enough about performance concerns to comment, but it just seems conceptually borked to me. If mutating pixels in a screen buffer is exactly what I am doing and intend to be doing, then my language might as well acknowledge the fact.

But even if you didnt give a shit about that, referential transparency is an awesome concept all by itself, so I think its a shame it has this status of kindof a freak functional thing.[/quote]Definitely; immutability and referential transparency are great concepts if you want to be able to have any sort of confidence that your code is sort of correct-ish. Systematic testing of any non-trivial piece of not-referentially-transparent code would be a complete nightmare.

Are you referring primarily to performance concerns or to the clarity of code that's inherently mutable?

I dont know enough about performance concerns to comment, but it just seems conceptually borked to me. If mutating pixels in a screen buffer is exactly what I am doing and intend to be doing, then my language might as well acknowledge the fact.
[/quote]If you put it that way, then your language should just concist of a single NAND command, shouldn't it? While the computer might be mutating pixels on the screen, mutating pixels isn't what your code is conceptually doing, is it? Your code is drawing images, or even "displaying a scene" or some other high level concept, not pushing pixels for fun, so that's what your code should reflect IMO. Shaders and rendering pipelines are also very mathematical and functional-ish beasts, so graphics is a way more functional field than one would think at first glance.

Of course, if your code is actually manipulating pixels in a buffer, for example if you're writing a frame buffer graphics library or similar, then making those routines functional don't make much sense (although calculating the pixel values, in a Photoshop image filter for instance, might benefit from being made functional.) Tasks involving an explicit notion of time are also not really well suited for functional code (although the compositionality of many functional languages often enables one to easily create an embedded domain-specific language well suited for such tasks,) and low-level bit twiddling or extremely performance critical inner loops are better done in an imperative language.

If you put it that way, then your language should just concist of a single NAND command, shouldn't it? While the computer might be mutating pixels on the screen, mutating pixels isn't what your code is conceptually doing, is it? Your code is drawing images, or even "displaying a scene" or some other high level concept, not pushing pixels for fun, so that's what your code should reflect IMO. Shaders and rendering pipelines are also very mathematical and functional-ish beasts, so graphics is a way more functional field than one would think at first glance.[/quote]
Well, im not saying thats the *only* think you are doing, but one of the things you are doing. Im not arguing for *more* language restrictions in such a case, but less.


Indeed a GPU pipeline and well written CUDA code are quite functional in nature. Thrust iterators are a great example of this, and I bet stream-processing will become far more declarative in the future.

Nonetheless, I find myself fiddling with pixel buffers quite often.