Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters".
Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming.
Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
I'm going to say some general things, of course, about purity and effects, modularity, types, testing, reasoning, parallelism and so on. But I hate general waffle, so I want to give concrete evidence, and that is what I particularly want your help with. I'm thinking of two sorts of "evidence":
1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good. One of my favourite examples is quicksort, for reasons explained here: http://haskell.org/haskellwiki/Introduction#What.27s_good_about_funct...
But I'm sure that you each have a personal favourite or two. Would you like to send them to me, along with a paragraph or two about why you found it compelling? For this purpose, a dozen lines of code or so is probably a maximum.
2. War stories from real life. eg "In company X in 2004 they rewrote their application in Haskell/Caml with result Y". Again, for my purpose I can't tell very long stories; but your message can give a bit more detail than one might actually give in a presentation. The more concrete and specific, the better. E.g. what, exactly, about using a functional language made it a win for you?
If you just reply to me, with evidence of either kind, I'll glue it together (regardless of whether I find I can use it in my talks), and put the result on a Wiki page somewhere. In both cases pointers to blog entries are fine.
Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting the Haskell mailing lists first because I think you'll give me plenty to go on; and because at least one of the talks *is* Haskell-specific. However, feel free to reply in F# or Caml if that's easier for you.
> Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters".
> Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming.
> Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
[...]
I think I qualify for this: I've been a long time C coder (and still do some), doing mostly UNIX/system stuff, most notably working on the FreeBSD kernel. I only recently (1 year, maybe one and a half) started learning Haskell so I still have fresh memories about my first feelings. One of the things that particularly impressed me was parametric polymorphism.
As a C programmer, you tend to rewrite code to deal with linked lists every time you need one, adding next pointers to some structure of yours. This kind of things get boring fast (one could also use the BSD sys/queue.h macros, but they're ugly).
So when I discovered about parametric polymorphism, and how you can have, for instance, a "length :: [a] -> Int" function working for any kind of lists, I was _very_ impressed. In a way, it is all perfectly logical to be able to have this kind of functions, since length doesn't need to know anything about what the list is holding, but it doesn't make it any less impressive for a C coder.
Still on the parametric polymorphism topic, the Maybe datatype is what impressed me next. Everyone that has done some amount of C in his life knows how boring it is to have functions returning errors to the caller. If you're lucky, your function returns a pointer and can thus return NULL in case something went wrong. If your function returns an int and -1 has no meaning, you can use that too. But if you don't, it becomes messy quickly. It's even more annoying when the standard got it wrong, for instance the dreaded atoi() function. So, when I discovered the Maybe datatype, I was like a kid opening presents at christmas :-). The extreme simplicity of the definition of the Maybe datatype is impressive in itself, its convenience is as well, and the fact that it prevents a whole class of bugs by making it (nearly) impossible to ignore the fact that the function can fail is the cherry on top.
Here are my $0.02 :-). I hope they'll be useful to you. This is mostly emotional and subjective stuff rather than technical, but I believe this is also what you're looking after.
On Wed, 23 Jan 2008, Simon Peyton-Jones wrote: > 1. Small examples of actual code. The goal here is (a) to convey a > visceral idea of what functional programming *is*, rather than just > assume the audience knows (they don't), and (b) to convey an idea of why > it might be good. One of my favourite examples is quicksort, for > reasons explained here: > http://haskell.org/haskellwiki/Introduction#What.27s_good_about_funct...
> But I'm sure that you each have a personal favourite or two. Would you > like to send them to me, along with a paragraph or two about why you > found it compelling? For this purpose, a dozen lines of code or so is > probably a maximum.
With respect to the other thread about exception handling, I can add that C++ programmers strongly disagree on whether exceptions or error return codes are the right way. Also Niklaus Wirth considered exceptions to be the reincarnation of GOTO and thus omitted them in his languages. Maybe the programmers like to hear that Haskell solves the problem the diplomatic way: Function return error codes, but the handling of error codes does not uglify the calling code. Maybe the programmers can recognize the power of the language, if you show them that Haskell does not need additional language support in order to implement classical exception handling. I have extended the article on the Wiki by a short example implementation of exceptions: http://www.haskell.org/haskellwiki/Exception _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 2008-01-23 at 13:29 +0000, Simon Peyton-Jones wrote: > 1. Small examples of actual code. The goal here is (a) to convey a > visceral idea of what functional programming *is*, rather than just > assume the audience knows (they don't), and (b) to convey an idea of > why it might be good.
Hello,
You might want to look at this article: http://www.ibm.com/developerworks/java/library/j-cb01097.html and other articles from Developer Works that deal with functional programming. They are written by programmers that work in the industry and usually have imperative background. These articles should be very useful for someone who wants to explain functional programming to newbies as they use vocabulary and examples meaningful for imperative programmers.
My personal favourite is a neat (read: efficient and mostly write-only) way to balance AVL trees which I learned at a Haskell course on my university.
This is the first implementation which comes to one's mind when playing with Trees:
> data Tree a = L | N (T a) a (T a)
Balanceness is defined in terms of a tree's height:
> height :: T a -> Int > height L = 0 > height (N l a r) = 1 + max (height l) (height r)
This gets the difference of the subtrees' heights: (Note that it could return a negative value, too.)
> skew :: T a -> Int > skew L = 0 > skew (N l a r) = (height l)-(height r)
Our tree is balanced iff the skew is at most 1 for every subtree:
> balanced :: T a -> Bool > balanced L = True > balanced t@(N l a r) > | abs (skew t) <= 1 = balanced l && balanced r > | otherwise = False
Now the interesting part. What if a tree is not balanced? Here do rotations come into the picture. There are several types of rotations which usually need some attention and are awkward to code in an imperative language. Of course one can do it in a functional language almost as awkward as in an imperative one, but the point is to use pattern matching like shown below:
> rightRot :: T a -> T a > rightRot (N (N x a y) b z) = N x a (N y b z) > rightRot a = a
This is one of the simplest cases which makes it relatively easy to read. The thing is that this is a really fast implementation achieved at almost no effort.
Also, it doesn't get harder than this:
> leftRightRot :: T a -> T a > leftRightRot (N (N x a (N y b z)) c v) = N (N x a y) b (N z c v) > leftRightRot a = a
which can also be written as:
> leftRightRot (N x a y) = rightRot (N (leftRot x) a y)
So I think this was the moment when I made up my mind to commit myself to Haskell & FP.
> 2. War stories from real life. eg "In company X in 2004 they rewrote their application in Haskell/Caml with result Y". Again, for my purpose I can't tell very long stories; but your message can give a bit more detail than one might actually give in a presentation. The more concrete and specific, the better. E.g. what, exactly, about using a functional language made it a win for you?
We [1] implemented an ad-hoc chat system in Haskell in the SEP [2] at the TU-Braunschweig.
The ad-hoc (there is no central server, every node has the same behaviour) protocol [3] (not of our making) is rather complicated, as each node on the network has to detect the neighbouring network topology in order to route messages to their destination:
A <-> B <-> C
Besides, it has to handle netsplit and -merge situations: Two separate networks might be connected by the spawning of a new node in between or split by the disappearance of the latter.
There are public and private IRC-like channels, the latter is encrypted by a symmetric cipher. Besides, there is an anonymous channel obscuring a message's origin.
On top of that we built a nice gtk2hs GUI.
The project homepage is http://sep07.mroot.net/index.html. I regret it's not in English :( - But the source code and documentation [4] are. You can build the documentation from the snapshot [5].
The interesting thing about the project is, that it provides a nice mixture of IO (network), purely functional protocol handling and related data structures and a graphical user interface (GTK). Besides, it was implemented by 3 other groups (two using Java, one using C++) as well. Comparing the results, you see that the Haskell implementation is not only more stable and provides more features, it also has about 70% less code.
> >2. War stories from real life. eg "In company X in 2004 they rewrote > >their application in Haskell/Caml with result Y". Again, for my purpose > >I can't tell very long stories; but your message can give a bit more > >detail than one might actually give in a presentation. The more concrete > >and specific, the better. E.g. what, exactly, about using a functional > >language made it a win for you?
> We [1] implemented an ad-hoc chat system in Haskell in the SEP [2] at > the TU-Braunschweig.
> Over the next few months I'm giving two or three talks to groups of *non* > functional programmers about why functional programming is interesting and > important. If you like, it's the same general goal as John Hughes's famous > paper "Why functional programming matters".
> Audience: some are technical managers, some are professional programmers; > but my base assumption is that none already know anything much about > functional programming.
> Now, I can easily rant on about the glories of functional programming, but > I'm a biased witness -- I've been doing this stuff too long. So this > message is ask your help, especially if you are someone who has a > somewhat-recent recollection of realising "wow, this fp stuff is so > cool/useful/powerful/etc".
> I'm going to say some general things, of course, about purity and effects, > modularity, types, testing, reasoning, parallelism and so on. But I hate > general waffle, so I want to give concrete evidence, and that is what I > particularly want your help with. I'm thinking of two sorts of "evidence":
> 1. Small examples of actual code. The goal here is (a) to convey a > visceral idea of what functional programming *is*, rather than just assume > the audience knows (they don't), and (b) to convey an idea of why it might > be good. One of my favourite examples is quicksort, for reasons explained > here: > http://haskell.org/haskellwiki/Introduction#What.27s_good_about_funct...
> But I'm sure that you each have a personal favourite or two. Would you > like to send them to me, along with a paragraph or two about why you found > it compelling? For this purpose, a dozen lines of code or so is probably a > maximum.
> 2. War stories from real life. eg "In company X in 2004 they rewrote > their application in Haskell/Caml with result Y". Again, for my purpose I > can't tell very long stories; but your message can give a bit more detail > than one might actually give in a presentation. The more concrete and > specific, the better. E.g. what, exactly, about using a functional > language made it a win for you?
> If you just reply to me, with evidence of either kind, I'll glue it > together (regardless of whether I find I can use it in my talks), and put > the result on a Wiki page somewhere. In both cases pointers to blog entries > are fine.
> Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting > the Haskell mailing lists first because I think you'll give me plenty to go > on; and because at least one of the talks *is* Haskell-specific. However, > feel free to reply in F# or Caml if that's easier for you.
I'm still just learning haskell but maybe as a n00b I can give you some insight into what I think is important.
I will take a guess here and say most of your audience is from the object-oriented crowd. Their software engineering practices are probably entirely based upon the idea of wrapping state up in objects and passing them around. They're probably going to want ways to leverage these techniques without dropping everything.
I personally think it is neat that non-functional languages are starting to borrow many ideas from functional languages. C# has lambda and LINQ, java might be adding closures. Scala is functional but has access to all the goodies of the java library. Python has list comprehensions. Even c++ is going to be adding lambda expressions (which are really handy for the stl algos which are functional like themselves).
Error handling and QA are very important in the real world. It might not hurt to show a few simple quick check examples and cases where errors are caught at compile time. There are probably many examples in ghc development.
On 1/23/08, Peter Hercek <pher...@gmail.com> wrote:
> Other things did not seem that great for me from the beginning. For > example: referential transparency - just enforces what you can take care > not to do yourself
..if you never make mistakes, that is.
> (e.g. in C# you just cannot be sure some function is > referentially transparent even when comment claims so - which of course > sucks because programmers are not disciplined).
But if that's the point you're trying to make, I agree that a lot of programmers seem to think they don't make mistakes, and thus might not be receptive to the siren song of referential transparency :-)
Cheers, Tim
-- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "You never have to aspire to difficulty, darling. It arrives, uninvited. Then it stays for dinner."--Sue Miller _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
> On 1/23/08, Peter Hercek <pher...@gmail.com> wrote: > > Other things did not seem that great for me from the beginning. For > > example: referential transparency - just enforces what you can take care > > not to do yourself
> ...if you never make mistakes, that is.
> > (e.g. in C# you just cannot be sure some function is > > referentially transparent even when comment claims so - which of course > > sucks because programmers are not disciplined).
> But if that's the point you're trying to make, I agree that a lot of > programmers seem to think they don't make mistakes, and thus might not > be receptive to the siren song of referential transparency :-)
Yes, we have to talk more about it making the job "faster and easier", than "safer". It's a particular kind of programmer that likes things to be safer (i.e. people on this list :), but all kinds want their job to be faster and easier :)
> Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general > goal as John Hughes's famous paper "Why functional programming matters".
At work, I volunteer to do a similar presentation for my colleagues; it's next week, mainly for Java developers like me ... it would be very modest ;-)
What I liked about (modern) FP -and the reason I volunteered- is:
(1) Typeful programming Capture errors at compile time! * In Java: String s = other.getSomething(); // say this can return null int witdh = s.length() * 10; // oops, may fail at runtime (in C would be core dumped) * Typeful programming (Haskell-like languages) data Option s = Some s | Nothing getSomething :: data : Data -> Option String and you are safe as the language forces you to check for two cases
(2) Equational reasoning (and referential transparency): modern FP programs look like equations and you can prove stuff about the code; no need to Unit test; encourage formal thinking. There is a section about this in http://clean.cs.ru.nl/contents/Clean_Book/clean_book.html which I found interesting.
(3) Parametric polymorphism in Java (called Generics) is cumbersome to use and verbose, in Haskell-like languages is just lot simpler because: a) notation is easier, and on top, b) is optional: you have type inference! This encourages typeful programming, which is good.
(4) I'm not going to mention Monads, or linear types: I simply can't explain something I still don't grasp completely. However, I noticed that Microsoft is exploring usages of linear types (AFAIK) in its Singularity OS. Just to argue that even within the imperative programming world there is something to learn from the FP-research side of things.
(5) Most Java programmers have come across the need to have utility classes with bunch of static methods. They are there, no body test them and they just work. Why? I believe most of them display FP thinking in practice.
(6) FP teaches you the discipline of keeping state to a minimum (as OO preaches in fact by saying "keep classes small"), and how to make it explicit when required. FP, particularly referential transparency, likes immutable objects.
(7) I think simple Java beans (objects with simple get and set methods, no logic, just to be used by other objects, a quite common pattern) are just poor man's ADT. ADTs in modern FP are simply lot powerful, with pattern matching and no requiring any magic reflection mechanism... is in the language.
(8) A while ago, I read that most of the famous Gang of Four's "Design patterns" simply don't make sense in a FP setting: there are no such "patterns", some are just FP built-in features. Would be nice if someone kindly elaborate on this in this list.
Any other contributions to the list above are very welcome.
In the talk I'm going to demonstrate how browsing or manipulating our configuration files in XML is lot easier using Scala (fair to say, Scala has been XML-sugared :-)
On Wed, 2008-01-23 at 15:42 -0800, Don Stewart wrote: > catamorphism: > > On 1/23/08, Peter Hercek <pher...@gmail.com> wrote: > > > Other things did not seem that great for me from the beginning. For > > > example: referential transparency - just enforces what you can take care > > > not to do yourself
> > ...if you never make mistakes, that is.
> > > (e.g. in C# you just cannot be sure some function is > > > referentially transparent even when comment claims so - which of course > > > sucks because programmers are not disciplined).
> > But if that's the point you're trying to make, I agree that a lot of > > programmers seem to think they don't make mistakes, and thus might not > > be receptive to the siren song of referential transparency :-)
> Yes, we have to talk more about it making the job "faster and easier", > than "safer". It's a particular kind of programmer that likes things to > be safer (i.e. people on this list :), but all kinds want their job > to be faster and easier :)
Be careful, though, this is only convincing against Java and C. Python, Ruby, Perl have the same argument. Compared to those, using Haskell might in fact be slower and harder--at least in the beginning. This is where Haskell's static typing enters the game and automates many of the boring and error prone tasks, like finding all the use sites of a type (just change it and let the compiler tell you). If you use 'newtype' and maybe some more advanced type checker features (MPTCs, Existentials) you can let the type-checker work for you (cf. "Lightweight Static Capabilities"). This is where Haskell could actually beat all those "dynamic" languages, which otherwise seem to be much easier to pick up for imperative programmers.
> Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters".
> Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming.
> Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
> I'm going to say some general things, of course, about purity and effects, modularity, types, testing, reasoning, parallelism and so on. But I hate general waffle, so I want to give concrete evidence, and that is what I particularly want your help with. I'm thinking of two sorts of "evidence":
> 1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good. One of my favourite examples is quicksort, for reasons explained here: http://haskell.org/haskellwiki/Introduction#What.27s_good_about_funct...
> But I'm sure that you each have a personal favourite or two. Would you like to send them to me, along with a paragraph or two about why you found it compelling? For this purpose, a dozen lines of code or so is probably a maximum.
> 2. War stories from real life. eg "In company X in 2004 they rewrote their application in Haskell/Caml with result Y". Again, for my purpose I can't tell very long stories; but your message can give a bit more detail than one might actually give in a presentation. The more concrete and specific, the better. E.g. what, exactly, about using a functional language made it a win for you?
> If you just reply to me, with evidence of either kind, I'll glue it together (regardless of whether I find I can use it in my talks), and put the result on a Wiki page somewhere. In both cases pointers to blog entries are fine.
> Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting the Haskell mailing lists first because I think you'll give me plenty to go on; and because at least one of the talks *is* Haskell-specific. However, feel free to reply in F# or Caml if that's easier for you.
Tim Chevalier wrote: > On 1/23/08, Peter Hercek <pher...@gmail.com> wrote: >> Other things did not seem that great for me from the beginning. For >> example: referential transparency - just enforces what you can take care >> not to do yourself
> ...if you never make mistakes, that is.
>> (e.g. in C# you just cannot be sure some function is >> referentially transparent even when comment claims so - which of course >> sucks because programmers are not disciplined).
> But if that's the point you're trying to make, I agree that a lot of > programmers seem to think they don't make mistakes, and thus might not > be receptive to the siren song of referential transparency :-)
What I wanted to say is that focusing on referential transparency will not appeal that much to an imperative programmer especially when he needs to overcome Haskell learning curve. What may appeal, though, are the consequences of it like: * easier to repeat test cases for bugs * easier to do automated tests (like quickcheck) since state space is not that big (provided I count automatic vars on stack/heap as state) * makes laziness to work which allow easier and efficient expression of producer - consumer type of code * easy undo (no need for memento pattern etc) * allows monads to work which adds options like built-in user logging or error recovery * better changes for compilers to find parallelize automatically * safe STM .. and probably a lot of more goodies
On the other side there are downsides like what to do instead of reactive GUIs? GUI is a big part for a lot of applications. A lot of efficient algorithms we have are state based. And again probably more.
If referential transparency by itself would be that important for imperative languages then it would be already added to IDEs* in some form like a popup menu item with name "check function purity". In some cases you could actually decide that the function is pure (especially if you would go deeper analyzing and annotating your objects with purity flags in your IDE).
* and IDEs like visual studio or eclipse are incredibly good compared to the stuff Haskell has; anyway IMHO all IDEs are not good enough - they could be much better
Anyway I'm not that qualified to discuss this (I hope this is my last post to this thread :) ). I just wanted to point out what could be a point of view of an imperative programmer based on what I remember from times I was getting more involved with functional programming. The reason I started with functional programming is sure not common - sometimes I may need to actually prove some program features.
> * safe STM > ... and probably a lot of more goodies
Especially STM would be a good point to elaborate on. Most big systems have issues around concurrency and state modification being broken. Anything that can reliably solve that problem is going to interest serious programmers.
On Jan 24, 2008 9:45 AM, Peter Hercek <pher...@gmail.com> wrote:
> A lot > of efficient algorithms we have are state based. And again probably > more.
Yes, and we can write those using the ST monad in Haskell. I think it's important to point this out, since some imperative programmers will just go "but what about if I *need* mutable state?" and probably tune out if they don't hear right away that Haskell can give it to them in a safe encapsulated form.
-- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862
fewer frustratingly unsolvable bugs down-the-road? When I have bugs in my Haskell programs (and usually I get type errors instead), I've always found them eventually and they're either a silly mistake or I realize that I misunderstood the problem I was trying to solve (it needs to be solved a different way)... which is great, being able to realize that and rewrite things! Usually not everything has to be rewritten because Haskell is pretty modular (unless used poorly :-).
* Isaac Dupree wrote: > fewer frustratingly unsolvable bugs down-the-road?
I personally like the refactoring speed. Due to pureness it's easy to refactor and that's why I can generalize more and more often. _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, 2008-01-24 at 10:45 +0100, Peter Hercek wrote: > Tim Chevalier wrote: > > On 1/23/08, Peter Hercek <pher...@gmail.com> wrote: > >> Other things did not seem that great for me from the beginning. For > >> example: referential transparency - just enforces what you can take care > >> not to do yourself
> > ...if you never make mistakes, that is.
> >> (e.g. in C# you just cannot be sure some function is > >> referentially transparent even when comment claims so - which of course > >> sucks because programmers are not disciplined).
> > But if that's the point you're trying to make, I agree that a lot of > > programmers seem to think they don't make mistakes, and thus might not > > be receptive to the siren song of referential transparency :-)
> What I wanted to say is that focusing on referential transparency > will not appeal that much to an imperative programmer especially > when he needs to overcome Haskell learning curve. What may appeal, > though, are the consequences of it like: > * easier to repeat test cases for bugs > * easier to do automated tests (like quickcheck) since state space > is not that big (provided I count automatic vars on stack/heap > as state) > * makes laziness to work which allow easier and efficient expression > of producer - consumer type of code > * easy undo (no need for memento pattern etc) > * allows monads to work which adds options like built-in user logging > or error recovery > * better changes for compilers to find parallelize automatically > * safe STM > ... and probably a lot of more goodies
> On the other side there are downsides like what to do instead of > reactive GUIs? GUI is a big part for a lot of applications. A lot > of efficient algorithms we have are state based. And again probably > more.
> If referential transparency by itself would be that important for > imperative languages then it would be already added to IDEs* in > some form like a popup menu item with name "check function purity". > In some cases you could actually decide that the function is pure > (especially if you would go deeper analyzing and annotating your > objects with purity flags in your IDE).
Doing it in the IDE would a) require much more from most IDEs and b) be almost entirely useless. Most IDEs don't even get as far as parsing the code, even the the best rarely know much about the actual semantics of the language. This would require a rather deep analysis and ultimately it is undecidable. Practically speaking, having such a feature in the IDE would be useless unless the programming style of most "imperative" programmers changed dramatically. The only functions such an analysis would say were pure are those that were rather trivial. Either way, having such a feature in the IDE doesn't really help. A purity checker in the IDE isn't going to help when the function/method is unknown, e.g. when I write a function/method that takes a function or an object. A "purity annotation" would have to be at the language level, short of doing a whole-program analysis which would be infeasible.
Derek Elkins <derek.a.elk...@gmail.com> wrote: > Doing it in the IDE would a) require much more from most IDEs and b) > be almost entirely useless. Most IDEs don't even get as far as > parsing the code, even the the best rarely know much about the actual > semantics of the language. This would require a rather deep analysis > and ultimately it is undecidable. Practically speaking, having such > a feature in the IDE would be useless unless the programming style of > most "imperative" programmers changed dramatically. The only > functions such an analysis would say were pure are those that were > rather trivial. Either way, having such a feature in the IDE doesn't > really help. A purity checker in the IDE isn't going to help when > the function/method is unknown, e.g. when I write a function/method > that takes a function or an object. A "purity annotation" would have > to be at the language level, short of doing a whole-program analysis > which would be infeasible.
Indeed - JML (Java Modelling Language) takes exactly this approach. -- Robin _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Jan 23, 2008 8:29 AM, Simon Peyton-Jones <simo...@microsoft.com> wrote:
> Friends
> Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters".
> Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming.
> Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
> I'm going to say some general things, of course, about purity and effects, modularity, types, testing, reasoning, parallelism and so on. But I hate general waffle, so I want to give concrete evidence, and that is what I particularly want your help with. I'm thinking of two sorts of "evidence":
I'm still very much a newbie, but the one thing that struck me as the best feature coming from Python is the static typing. Changing the type of a function in Python will lead to strange runtime errors that take some work to debug, whereas, when I tinker with a program in Haskell, I already know it will work once it compiles.
In addition to STM, another item that should interest serious programmers is forkIO. Lightweight threads that (unlike in Python) can use multiple cpu's. Coming from Python, I personally appreciate this. Using STM to handle concurrency issues often greatly simplifies multithreaded code. _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
> In addition to STM, another item that should interest serious > programmers is forkIO. Lightweight threads that (unlike in Python) > can use multiple cpu's. Coming from Python, I personally appreciate > this. Using STM to handle concurrency issues often greatly simplifies > multithreaded code.
And further on this, the use of `par` in pure code to make it go multicore is way beyond what most people think is possible.
Don Stewart <d...@galois.com> wrote: > jwlato: > > In addition to STM, another item that should interest serious > > programmers is forkIO. Lightweight threads that (unlike in Python) > > can use multiple cpu's. Coming from Python, I personally appreciate > > this. Using STM to handle concurrency issues often greatly > > simplifies multithreaded code.
> And further on this, the use of `par` in pure code to make it go > multicore is way beyond what most people think is possible.
I said _don't_ make me think of using par on a beowolf cluster of ps3's. Don't you guys have any scruples?
-- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.
Simon Peyton-Jones wrote: > 1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good.
Here is one I came across in the last few days. I was reviewing some code in Java, and it contained a function that looked through a list of Foo instances for the latest update. I don't actually speak Java, but it went something like this:
// Get the Foo that was most recently updated. Foo latestUpdate (Iterator <Foo> iterator) { long latestTimeSoFar = 0; Foo latestFooSoFar = Null;
This takes an iterator over some collection of Foos and finds the one with the highest value of updateTime. 9 lines of code, or 12 with the closing curly brackets.
In Haskell this is so short and obvious you probably wouldn't bother declaring it as a function, but if you did, here it is:
-- Find the Foo that was most recently updated. latestUpdate :: [Foo] -> Foo latestUpdate foos = maximumBy (comparing updateTime) foos
Of course you could always write it in point-free format, but I think that would be over-egging things.
