See also Raganwald's Why Why Functional Programming Matters Matters: http://weblog.raganwald.com/2007/03/why-why-functional-progr...
Why Functional Programming Matters (1984) [pdf]
71–80 of 145 posts
Re: Why Functional Programming Matters (1984) [pdf]
#72Earlier quoted context omitted.
> The main gate to functional languages participating in, say, the Linux kernel is NOT that they are "too slow" or that "laziness makes them too confusing". It's that the Linux kernel is written entirely around the unique weirdness and expectations of C, and only languages based on or descendant to C do well there. Sure, but the usual functional style has intrinsic issues that prevent it from being feasible for writi…
Does COGENT look functional or imperative in programming style to you? Genuine question as I don't do FP. COGENT is latest in attempts at bringing functional, verified languages into system space. A team already redid the ext2 filesystem with it. https://ts.data61.csiro.au/projects/TS/cogent.pml
COGENT takes pretty much precisely the approach I described below: it uses domain-specific structures in a functional language to encode verified imperative code. If you look at pretty much any code in the ext2 pilot (here[1] is as good as any) you'll notice that a lot of the functions called are things like destroy_Ext2DirEnt (which unless they named things poorly, takes a clear action), as well as a lot of passing around of memory addresses to functions that write them (e.g. deserialise_Ext2DirEnt2).
It's not that they wrote the logic in a fundamentally different paradigm from C, it's that they take care to give their system the information it needs to both generate C code and most of the desired proofs simultaneously. The functional language is fufilling the role of metalanguage excellently, but little of that ends up in the generated code. The one functional thing that does is pattern matching, since the C equivalent (if statements and unions) are much harder to verify (and use).
[1]: https://github.com/NICTA/cogent/blob/master/impl/ext2/cogent...
Re: Why Functional Programming Matters (1984) [pdf]
#73The top link on /r/haskell right now [1] is someone complaining that their program runs out of space due to a subtle interaction between laziness and IO. I think it's safe to say that we have tried laziness as the default and have learned that it's the wrong default, because it plays havoc with space and with IO. [1] https://www.reddit.com/r/haskell/comments/5h6emf/haskell_run...
Look, I fixed their code in so many ways: main = runConduitRes -- dealing with finite resources ( sourceFileBS "input.txt" -- read input.txt as binary data .| decodeC utf8 -- decode assuming UTF-8 .| linesC -- split into lines .| mapC parseList -- parse each line into list of text .| mapC (get 5) -- get sixth element of list .| catMaybeC -- discard lines with no sixth element .| encodeC utf8 -- encode as UTF-8 .| sin…
It seems to me that part of the problem he was having is that he didn't really understand how these methods were being implemented internally. I know that all languages inevitably have these problems but how do the amount of leaky abstractions compare in Haskell to other languages?
Re: Why Functional Programming Matters (1984) [pdf]
#74To me, this is the most important part of the text (p2, bottom): "The ways in which one can divide up the original problem dep end directly on the ways in which one can glue solutions together Therefore to increase ones ability to mo dularise a problem conceptually one must provide new kinds of glue in the programming language." Functional programming is great because it provides two (new) kinds of glue: function com…
> Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation.
Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much of it would break).
Re: Why Functional Programming Matters (1984) [pdf]
#75Earlier quoted context omitted.
> Sure, but the usual functional style has intrinsic issues that prevent it from being feasible for writing kernels in general. Not really? > A kernel (especially a microkernel) spends most of its time managing state. So does every computer program though. The idea that functional languages can't support mutation is a strangely persistent myth even in the face of multiple counter-examples AND 20 years of improvement…
My point is not that functional languages can't support mutation, I'm well aware of the whole gamut from State to F-Star, Eff, and Idris. My point is that you're going to spend almost all of your time explicitly mutating things, using whatever functional language as a "very fine imperative language." Yes, you can embed those semantics inside functional semantics, and even use the functional language to add more stati…
> My point is not that functional languages can't support mutation, I'm well aware of the whole gamut from State to F-Star, Eff, and Idris. My point is that you're going to spend almost all of your time explicitly mutating things, using whatever functional language as a "very fine imperative language."
The difference being that this "very fine imperative language" has much stronger type safety guarantees.
Maybe we can stop having ring0 buffer overflows some day when C programmer pride is sufficiently assuaged. I doubt it though... My experience with the linux kernel community is that it is a limitless void of insecurity and infighting.
> On top of that, you're not going to be able to abide the kind of allocations that functions in Haskell, OCaml, etc. can do with little provocation
OCaml does much better here (in fact, really quite amazingly well here, on part with some of the greatest common lisp distribution compilers which were stunningly good at it). But yeah, Haskell has a very poor focus on the needs of the "industry" when said industry is focused around extremely tight optimizations.
That said, I refuse to confuse a specific example of FP with a traditionally academic and research focus with the discipline as a whole. That's a dodge.
> So in the end you'll be in "Generic Stack-focused Pointer-pushing Procedural Imperative Language: The Monad".
Honest question: what's the problem with this if it offers additional safety and promotes the use of stateless functions? If it all compiles down to similar code, then it's fine. People act like monadic code is not functional, when it is in fact extremely functional code.
That's what's funny about all this: imperative programming is expressible succinctly and easily in functional languages.
Re: Why Functional Programming Matters (1984) [pdf]
#76A lot of pleas for functional programming give a long list of convincing examples that work well with functional programming. You can do this with almost any language, and this is also quite deceptional, as this is often done to convince beginners to learn another language; "look at how simple it is to program this contrived example in !". In order to be able to use a programming language or paradigm well, it is espe…
> Functional programming does not work well in programs which handle a lot of states. It does not work well in programs which have high requirements for performance or memory. It does not work well for programs which have to do low-level stuff. None of this is true. This is just the generic set of plausible-sounding but meaningless complaints people who haven't actually used FP for any of these purposes tend to repea…
Is the 'A' in ADT algebraic or abstract?
Re: Why Functional Programming Matters (1984) [pdf]
#77To me, this is the most important part of the text (p2, bottom): "The ways in which one can divide up the original problem dep end directly on the ways in which one can glue solutions together Therefore to increase ones ability to mo dularise a problem conceptually one must provide new kinds of glue in the programming language." Functional programming is great because it provides two (new) kinds of glue: function com…
> Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation. Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much…
> laziness is more the exception than the rule in today's FP languages
Exactly. I also wrote I am somewhat less enthusiastic about laziness.
So that leaves just one kind of glue as FP's contribution, which goes back to my point to the contribution being good but not sufficient.
Re: Why Functional Programming Matters (1984) [pdf]
#78Earlier quoted context omitted.
> Functional programming does not work well in programs which handle a lot of states. It does not work well in programs which have high requirements for performance or memory. It does not work well for programs which have to do low-level stuff. None of this is true. This is just the generic set of plausible-sounding but meaningless complaints people who haven't actually used FP for any of these purposes tend to repea…
Is the 'A' in ADT algebraic or abstract?
Algebraic.
Re: Why Functional Programming Matters (1984) [pdf]
#79Earlier quoted context omitted.
My point is not that functional languages can't support mutation, I'm well aware of the whole gamut from State to F-Star, Eff, and Idris. My point is that you're going to spend almost all of your time explicitly mutating things, using whatever functional language as a "very fine imperative language." Yes, you can embed those semantics inside functional semantics, and even use the functional language to add more stati…
> My point is not that functional languages can't support mutation, I'm well aware of the whole gamut from State to F-Star, Eff, and Idris. My point is that you're going to spend almost all of your time explicitly mutating things, using whatever functional language as a "very fine imperative language." The difference being that this "very fine imperative language" has much stronger type safety guarantees. Maybe we ca…
It's not a problem at all, it's exactly the direction I'd like to see things go as well. It's just that your code is still a stranger in a strange land in these cases. Your proofs will be full of the typical halmarks of functional programing, and for the stuff that is executed at runtime you'll definitely want some pattern matching, but there will be no closures or higher-order functions and limited opportunities for monads, functors, etc.
Would you consider a C program transliterated into a representation of C inside a functional language and then annotated with proofs to be "functional"? My argument is what you get if you write a true kernel (no sitting on top of a runtime written in something else) is going to look a lot like that would.
Re: Why Functional Programming Matters (1984) [pdf]
#80Earlier quoted context omitted.
Yes. You can model state easily in functional programming languages but the technique is unfamiliar to imperative programmers since it's more explicit. This is a very good thing.
More explicit? Try more convoluted. Ever try to build an event-driven FSM in Haskell? I've seen several try, including myself...the results of which have all been complexity disasters. Imperative languages in general have poor data structures for representing state (no ADTs!), but nothing is more explicit and straightforward than using mutable data or mutable containers for modeling actual mutable state. That's why l…
What's the problem with event-driven state machines in Haskell that leads to "complexity disasters"? Maybe you could show an example of a non-disastrous imperative variant, and we'll see if me or someone else can come up with a Haskell translation that isn't disastrously complex?