[Haskell-cafe] Why functional programming matters
Simon Peyton-Jones
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_functional_programming.3F
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.
Thanks!
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Maxime Henrion
> 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 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.
Maxime
Henning Thielemann
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_functional_programming.3F
>
> 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
Michał Pałka
> 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.
Cheers,
Michał
Zsolt Dollenstein
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.
Cheers,
Zsolt
Stephan Friedrichs
> [...]
>
> 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.
Let me know, if you're interested in details.
>
> [...]
>
Hope this helps
Stephan
[1] 4 students: 2 experienced Haskell users and two newbies
[2] a practical course where a non-trivial software project has to be
planned, implemented and documented
[3] http://sep07.mroot.net/documentation/draft-strauss-p2p-chat-09.txt
[4] Complete repository available at:
http://sep07.mroot.net:81/cgi-bin/darcsweb.cgi?r=SEP%202007%20-%20Ad-Hoc-Chatsystem;a=summary
[5] http://sep07.mroot.net/snapshots/Barracuda-1.0.2.tar.bz2
--
Früher hieß es ja: Ich denke, also bin ich.
Heute weiß man: Es geht auch so.
- Dieter Nuhr
Don Stewart
> Simon Peyton-Jones wrote:
> >[...]
> >
> >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.
Wow!
Looks like lots of great code in there,
http://sep07.mroot.net/documentation/barracuda/
Text.ParserCombinators.Parsec.XML
Codec.Encryption.PKCS1
Network.GnuTLS
Data.Heap
Will we see this packaged for hackage.haskell.org soon?
Some of those modules look very reusable.
-- Don
Ryan Dickie
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.
--
Ryan Dickie
Tim Chevalier
> 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
Don Stewart
> On 1/23/08, Peter Hercek <phe...@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
>
>
> > (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 :)
-- Don
CAya
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.
(9) Hey, most controversial proposed Java 7 features are FP motivated:
http://tech.puredanger.com/java7#typeinference
http://tech.puredanger.com/java7#closures
and tail call optimization somewhere,
not to mention enriching the module system away from the simple public/
protected/private/default package (directory-based) system.
I am going to talk about Scala, a practical OO + FP language which is
on the rise (runs on the JVM): http://www.javaworld.com/podcasts/jtech/2007/120607jtech007.html
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 :-)
Wish me luck!
Carlos
Thomas Schilling
> catamorphism:
> > On 1/23/08, Peter Hercek <phe...@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.
Then there is concurrency of course ...
Michael Vanier
"C isn't hard; programming in C is hard. On the other hand: Haskell is hard,
but programming in Haskell is easy."
Mike
Peter Hercek
> On 1/23/08, Peter Hercek <phe...@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
>
>
>> (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.
Peter.
Maarten Hazewinkel
On 24 Jan 2008, at 10:45, Peter Hercek wrote:
> * 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.
Maarten
Sebastian Sylvan
> 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
Isaac Dupree
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
Lutz Donnerhacke
> 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.
Derek Elkins
>
> 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.
Robin Green
Derek Elkins <derek.a...@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
Yaakov Nemoy
> 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.
-Yaakov
John Lato
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.
Don Stewart
> 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
Achim Schneider
> 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.
Paul Johnson
> 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.
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;
while (iterator.hasNext()) {
item = iterator.getNext();
if (item.updateTime > latestTimeSoFar) {
latestTimeSoFar = item.updateTime;
latestFooSoFar = item;
}
}
return latestFooSoFar;
}
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.
Paul.
ChrisK
> Don Stewart <do...@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?
>
Well... ghc still has a single-threaded garbage collector, so all the "par"
threads must stop for garbage collection. So scaling to the level of a cluster
would be significantly sub-linear.
--
Chris
Mattias Bengtsson
[snip]
> // Get the Foo that was most recently updated.
> Foo latestUpdate (Iterator <Foo> iterator) {
> }
>
> 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.
To have a fair comparison you'd have to use some typeclass (Foldable
would be right?) that supports different types of collections.
> import Data.Foldable as F
>
> latestUpdate :: Foldable a => [a] -> a
> latestUpdate = F.maximumBy (comparing updateTime)
But yeah your point is very very valid. I've programmed some Java in my
days and while i wouldn't call myself an expert i don't see any
immediate "unawkward" abstractions that can be performed in the java
code.
If you have all Foo's implement a method "getProperty(String)" that
takes a String and returns the property of that class instance you
_could_ implement the static method (correct java-lingo?)
maximumBy(String s) that is roughly like this:
class MyClass {
public static Foo maximumBy (Iterator <Foo> iterator, String s) {
long max = 0;
Foo maxFoo = Null;
while (iterator.hasNext()) {
item = iterator.getNext();
if (item.getProperty(s).compareTo(max)) {
max = item.updateTime;
maxFoo = item;
}
}
return maxFoo;
}
}
and then
Foo latestUpdate (Iterator <Foo> i) {
return MyClass.maximumBy(i,"latestUpdate");
}
Totally untested code ofcourse...
The awkward part obviously comes from the fact that properties aren't
functions that you can pass to the maximumBy-method.
Anyhow, Haskell's nice Polymorphism is surely a good argument for it
(but not for functional programming per se right?)
Mattias
Achim Schneider
> Achim Schneider wrote:
> > Don Stewart <do...@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?
> >
>
> Well... ghc still has a single-threaded garbage collector, so all the
> "par" threads must stop for garbage collection. So scaling to the
> level of a cluster would be significantly sub-linear.
>
"By the time you learnt how to write proper Haskell, that's most likely
implemented in an arcane one-liner using par."
--
/me aleady drank a bootle of vin and suggests that you don't answer
seriously if you want to get non-abstroose anwererse.
Evan Laforge
> 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.
Java's just wordy like that. In python you'd say max(foos, key=lambda
x: x.update_time). Python / perl / ruby / smalltalk have had first
class functions forever, so those are basically already in the
mainstream. They may impress a java or C programmer who's never seen
a dynamic language. It might reassure a python programmer that static
typing doesn't preclude using closures and doesn't mean c++ or java
style huge long declarations.
So you probably need some other examples to convince python
programmers that their language didn't just cherry pick all the great
ideas and that there are none left.
> Well... ghc still has a single-threaded garbage collector, so all the
> "par" threads must stop for garbage collection. So scaling to the
> level of a cluster would be significantly sub-linear.
A real time incremental gc would be really cool. Some people claim
they exist, but which languages have one?
Jan-Willem Maessen
On Jan 24, 2008, at 6:04 PM, Evan Laforge wrote:
>>
>> Well... ghc still has a single-threaded garbage collector, so all the
>> "par" threads must stop for garbage collection. So scaling to the
>> level of a cluster would be significantly sub-linear.
>
> A real time incremental gc would be really cool. Some people claim
> they exist, but which languages have one?
Define "real time". I'll note that, after all the mud that's been
slung at Java, you've been able to get low-pause-time parallel GC in
Java for years and years, and can get "real time" GC for various of
your favorite definitions of that term if you're willing to look a
little.
Relatively few other language implementations can claim the same.
Writing a decent parallel GC (eg, faster than the tuned sequential GC
it's replacing on 2 or more CPUs) is hard. Sounds like GHC is nearly
there, though. GC implementors dream of systems where read barriers
are nearly free. Better still, everything that's been learned about
and published in Java-land carries across to Haskell (though the
tradeoffs in eg mutation behavior are often different).
-Jan-Willem Maessen
Evan Laforge
> > they exist, but which languages have one?
>
> Define "real time". I'll note that, after all the mud that's been
> slung at Java, you've been able to get low-pause-time parallel GC in
> Java for years and years, and can get "real time" GC for various of
> your favorite definitions of that term if you're willing to look a
> little.
I'd personally settle for soft real time, like "very rarely takes more
than n ms in a single gc run" so that if you are calculating samples
or something chances of getting a dropout are low. I think most
people would be happy there. So Java sounds like it would do for me
there. Unfortunately it has all the rest of that language attached to
it :)
Conal Elliott
> [...]
> 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. [...]
GUIs can be expressed in a *much* more direct and modular way in functional
programming than imperative programming. See
http://haskell.org/haskellwiki/TV and
http://haskell.org/haskellwiki/Phooeyfor examples. No inversion of
control is necessary. And not just for GUIs,
but for reactive systems in general. See
http://haskell.org/haskellwiki/Reactive and http://haskell.org/yampa/ .
I'd cite easy & modular GUIs as a strong advantage of functional
programming.
Just to be clear, I mean really *functional* programming, not imperative
programming in Haskell (IO).
- Conal
Jonathan Cast
>> 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.
>
> Java's just wordy like that. In python you'd say max(foos, key=lambda
> x: x.update_time). Python / perl / ruby / smalltalk have had first
> class functions forever, so those are basically already in the
> mainstream.
But, while Python/Perl/Ruby/Smalltalk may have borrowed such
techniques already, the syntax still conspires against them. If the
audience knows one or more of these languages, I would suggest
finding its syntactic infelicities and contrasting with Haskell
(Haskell's syntax is its strongest point, IMHO).
jcc
ChrisK
> 1. Small examples of actual code.
I particularly like the lazy way of counting change example (also works for
picking items off a menu).
The code below show 3 approaches :
a function for computing the coins used in each way as a verbose list
a function for computing just the total number of ways
a simply Monoid that does both at once, which a pretty summary display
And it has a short but user friendly main function that drives it.
The method used is simple. It considers each value of coin in turn, this loop
is done by the foldr. The value being folded is a list where the index into the
list is an amount for which change is being made; the value at that list index
is the list or count of the ways to make that amount using the coins considered
so far.
These exploit laziness since the returned lists are infinite and since 'result'
is defined recursively for each different value of coin.
The example of defining a Monoid is a clear abstraction or generalization of the
first two functions.
> -- This demonstrates a way to find every eay to make change for a
> -- given total using a set of coins.
> --
> -- By Chris Kuklewicz, Public Domain
> import System.Environment(getArgs)
> import Control.Exception as E(catch)
> import Control.Monad(when)
> import Data.List(group)
> import Data.Monoid(Monoid(mempty,mappend))
>
> computeListOfWays :: [Int] -> [[[Int]]]
> computeListOfWays coins = foldr includeValue noValues coins
> where noValues = [] : repeat []
> includeValue value oldResult =
> let (unchangedResult,changedResult) = splitAt value oldResult
> result = unchangedResult ++
> zipWith (++) changedResult (map addCoin result)
> addCoin = map (value:)
> in result
>
> computeCountOfWays :: [Int] -> [Integer]
> computeCountOfWays coins = foldr includeValue noValues coins
> where noValues = 1 : repeat 0
> includeValue value oldResult =
> let (unchangedResult,changedResult) = splitAt value oldResult
> result = unchangedResult ++
> zipWith (+) changedResult result
> in result
>
> computeWays :: [Int] -> [Ways]
> computeWays coins = foldr includeValue noValues coins
> where noValues = Ways [[]] 1 : repeat mempty
> includeValue value oldResult =
> let (unchangedResult,changedResult) = splitAt value oldResult
> result = unchangedResult ++
> zipWith mappend changedResult (map addCoin result)
> addCoin (Ways list count) = Ways (map (value:) list) count
> in result
>
> data Ways = Ways [[Int]] Integer
>
> instance Monoid Ways where
> mempty = Ways [] 0
> mappend (Ways list1 count1) (Ways list2 count2) = Ways (list1++list2) (count1+count2)
>
> instance Show Ways where
> show (Ways list count) = unlines (map summary list) ++ "Count of Ways = " ++ show count ++ "\n"
> where summary = show . map (\sub -> (length sub,head sub)) . group
>
>
> coins_US :: [Int]
> coins_US = [1,5,10,25,50]
>
> coins_UK :: [Int]
> coins_UK = [1,2,5,10,20,50]
>
> main = do
> args <- getArgs
> case args of
> [] -> error "Pass a number of cents for which to count ways of making change"
> [x] -> do n <- E.catch (readIO x) (const (error "The argument passed needs to be a number"))
> when (n<0) (error "The argument passed needs to be a non-negative number")
> print (computeWays coins_US !! n)
> _ -> error "Too many parameters, need just one number"
Michael Reid
> 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.
>
I'm quite new to Haskell as well and I must echo this sentiment. The
mainstream has somewhat realized that its a waste of time to tell the
compiler the type of _everything_. Learning Haskell has completely
reversed my feeling that static typing is an old outdated idea. The
power of Haskell's type system makes it feel like you are programming in
a dynamic language to some degree, yet all of it is type-checked, and
that is just *really* cool.
Honestly, when I first started reading a Haskell tutorial I was
convinced that it was an runtime-typed language like Python. When the
tutorial moved on to explain that it is statically typed I could barely
believe it.
The second thing I might want to highlight is the power of monads and
other techniques like arrows and FRP.
Granted, these are not easy concepts to impart in a talk, but I think
they were really an important discovery in FP as they deal with the
"problem" of IO in such a beautifully orthogonal way. Following on that,
more advanced structures like arrows and how all of this can contribute
to really powerful DSLs I think is a pretty big selling point.
Actually, come to think of it, one great way to show off the language is
to show off the power of some of the libraries that have been written.
For example, show how easily a parser can be created w/ Parsec; or show
an example of FRP w/ Yampa. These examples will likely tantalize the
programmers in the audience to want to learn more.
Good luck!
/mike.
Stefan Kersten
>> Well... ghc still has a single-threaded garbage collector, so all the
>> "par" threads must stop for garbage collection. So scaling to the
>> level of a cluster would be significantly sub-linear.
>
> A real time incremental gc would be really cool. Some people claim
> they exist, but which languages have one?
james mccartney's supercollider [1] has a non-copying incremental
collector based on [2], though not a parallel one.
btw, is an implementation of the incremental collector described in
[3] available somewhere? are there any plans to incorporate it into
future ghc versions?
<sk>
[1] http://supercollider.sourceforge.net
[2] P. R. Wilson and M. S. Johnstone. Real-time non-copying garbage
collection. In ACM OOPSLA Wsorkshop on Memory Management and Garbage
Collection, 1993.
[3] A. M. Cheadle, A. J. Field, S. Marlow, S. L. P. Jones, and R. L.
While. Exploring the barrier to entry: incremental generational
garbage collection for haskell. In ISMM ’04: Proceedings of the 4th
international symposium on Memory management, pages 163–174, New
York, NY, USA, 2004. ACM.
TG
really impressed me are :
* higher-order functions and function composition. There are a lot of
claims about how OOP allows code reusability and refactoring, but it
is simply incredible to see how easy it is to play "Lego" with your FP
code.
* strict typing, which forces you to conceive and code properly.
Andrew Cheadle
>> A real time incremental gc would be really cool. Some people claim
>> they exist, but which languages have one?
>
> james mccartney's supercollider [1] has a non-copying incremental
> collector based on [2], though not a parallel one.
>
> btw, is an implementation of the incremental collector described in
> [3] available somewhere? are there any plans to incorporate it into
> future ghc versions?
>
> <sk>
>
> [1] http://supercollider.sourceforge.net
> [2] P. R. Wilson and M. S. Johnstone. Real-time non-copying garbage
> collection. In ACM OOPSLA Wsorkshop on Memory Management and Garbage
> Collection, 1993.
> [3] A. M. Cheadle, A. J. Field, S. Marlow, S. L. P. Jones, and R. L.
> While. Exploring the barrier to entry: incremental generational
> garbage collection for haskell. In ISMM ’04: Proceedings of the 4th
> international symposium on Memory management, pages 163–174, New York,
> NY, USA, 2004. ACM.
The collector in [3] isn't in a production version of GHC for several
reasons, mainly because I finished it prior to significant reworking of
GHC's backend (C-- target etc), and while finishing my PhD I couldn't
devote the time to keeping it current - it is a massive engineering
task! Furthermore, the scheduling of work-based increments are
problematic and I only made a preliminary start with time-based
collection. That said:
Our current work here at Imperial has focussed on implementing exactly
what we did for GHC in Java, targetting the Jikes RVM, and we've made
alot of progress (*shameless plug*, check out our paper at VEE 2008: /A
Method Specialisation and Virtualised Execution Environment for Java).
/With this work nearing completion my attention is turning back to GHC
but with particular focus on concurrency, and multi-core / parallel
collection and the STM world... I haven't ruled out the collector being
incremental too, so I wouldn't be surprised if I resurrect this code
base... Of course, these things take time and I have other commitments...
I know Simon has been working on parallel collection and I would expect
this to be more generally useful than a single-threaded incremental
collector, so I'll leave it to him to say how that's coming on...
Cheers
Andy
//
--
*********************************************************************
* Andrew Cheadle email: a.ch...@doc.ic.ac.uk *
* Department of Computing http://www.doc.ic.ac.uk/~amc4/ *
* Imperial College London *
*********************************************************************
Ryszard Szopa
> 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?
(I am sorry if the following has been already posted before or is
considered trivia; I got here through Reddit and just quickly skimmed
through the conversation, not finding.)
Jane Street Capital (a Wall Street trading company) has been using
OCaml quite extensively and seem to be happy about it. At first they
used OCaml only for quantitative research software, but in 2005 they
switched to OCaml as their primary development language. You can read
an article by Yaron Minsky describing Jane Street's experience w/ fp
in a recent issue of the Monad Reader [1].
HTH,
-- Richard
[1] http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf
Dan Licata
See also
A parallel, real-time garbage collector
Perry Cheng and Guy Blelloch
PLDI 2001
This was implemented in the TILT compiler for SML (which, to be fair, is
more of a research vehicle than a programmer-friendly implementation).
-Dan
Adam Jones
administration scripting on Windows, and enjoyed the extra
productivity it afforded me so much I'm back in school studying the
subject. So far I've had some serious learning ADD, which is my excuse
for not having much in the way of projects to demonstrate anything.
I'm still new to Haskell, but one point I'd like to contribute is that
comparing code in a language someone knows well to your Haskell code
is tricky business. I'd say it is safe to guess that many of the
people here have a better grasp of idiomatic Haskell than they do
idiomatic Java. If your comparison assumes code that your typical
$language programmer thinks is flawed then you might as well give up
there. They will come up with a hazy idea of the value of Haskell at
best and an impression that the Haskell community is trying to advance
itself through duplicity at worst. These notions stick with people for
a long time, long after they've forgotten what prompted the idea in
the first place.
One route, obviously, is to look for skilled programmers in $language
in the Haskell community and ask them to double check your samples.
I'm sure this would work well, and avoids bogging down the
presentation since you already have code.
Another is to write and work with the code during the presentation.
Have the audience edit your Java code for some simple task. Put
together a shell script that compiles the code and gives you non-
comment line counts. Earn their trust in your example by having them
create it, people won't cry foul if the example they had a hand in
making is a poor representation of $language.
Then, when that is all built up, switch to Haskell. Write the same
code there. If you're looking at a static language audience, play with
the code in ghci instead of manually testing it in a main function. If
you're talking to dynamic language people, play with the code in ghci
so they know they still can. Do the same non-comment line count trick
and make a calculatedly offhand remark about the number difference.
I think that would be a convincing presentation. You're taking the
best that a group of people can do in their language and single-
handedly writing the same thing in your language faster and more
easily. Pack in as many features as will reasonably fit, then spend
the rest of your time presenting other features. You're trading a lot
of time that could be used for other things, but I think watching the
process unfold as experts in each language solve the same problem and
comparing the two is a great way to demonstrate a lot of the benefits
of Haskell.
-Adam
Paul Johnson
>
> Java's just wordy like that. In python you'd say max(foos, key=lambda
> x: x.update_time).
specified: senior technical people and managers. Most of these people
have heard of Python and Ruby, but see them as "scripting" languages
that are not suitable for Real Work. Most of the ones I have met seem
to regard a static type system and compilation to native code as
prerequisites for "real" programming languages (although Java has
greatly weakened the second prejudice).
More importantly, these people have not read "Beating the Averages".
They see the programming language market as a Keynsian Beauty Contest,
in which the judges get rewarded for voting for the most popular
candidate. Therefore the trick to winning the contest is not persuading
the judges that you are the most beautiful, but that you are the one
that most of the other judges are going to vote for. Paradoxically this
is best done by emphasising your similarity with what they already
know. The message is "I'm just like her, only better".
In the case of Haskell ways to do this would include:
* Outline (single Powerpoint slide) a mapping between UML class
diagrams and Haskell data and class types. Mention that Haskell
classes and data types correspond roughly to Java interface and
implementation classes respectively.
* Emphasise that Haskell *is* statically type checked, its just that
type inference means you don't have to declare the type of every
single thing. Repeat this point three or four times during the
talk to make sure it sticks.
* Mention the covariance type hole in Java and say that Haskell
doesn't have it. In Haskell "static type system" means what it says.
* Hackage does what Doxygen and Javadoc do. The ones who know about
automatic documentation will get a warm fuzzy feeling. The ones
who don't will find it interesting. Also mention Hunit. Mention
QuickCheck in passing, but don't dwell on it because its not what
they know.
* Mention that there is an Eclipse plug-in for Haskell.
* Talk at length about the Haskell library and package mechanisms.
Large projects often have multi-version configuration management
issues, so talk about how library versions can be selected at
compile time by a configuration file.
* Talk about the FFI interface. Most of these people have big
important monoliths of legacy code that they don't like to talk
about in public.
* Trying to dereference "null" is a significant source of bugs, so
explain that null references are impossible in Haskell. If you
have "x :: Foo" then "x" can never be null; it *has* to refer to a
Foo object. If we want a possible null value then we say "Maybe
Foo" to signal this, and type safety means you have to account for
possible "Nothing" values.
* Say "computers are cheap but programmers are expensive" whenever
explaining a correctness or productivity feature.
The best way to demonstrate the innate productivity improvement in
Haskell is using numbers. Haskell projects to re-implement existing
code routinely report 4-fold or better code reduction. The 1993 paper
on Ada vs Awk vs C++ vs Haskell... is still good ammunition, as are the
GetOpts implementations in C and Haskell.
A lot of this is to demonstrate that the normal development
infrastructure is actually available. This is another thing that these
people expect to see in a "real" language. Its not that this is
important for productivity, its just stuff you have to have to be
considered a "real" language.
Maybe I should write a "Real Programming Languages Eat Lots of Quiche"
piece.
Paul.
Paul Johnson
> On 1/26/08, Paul Johnson <pa...@cogito.org.uk> wrote:
>
>> * Say "computers are cheap but programmers are expensive" whenever
>> explaining a correctness or productivity feature.
>>
>
>
Even in low-income nations, its only false in the short term. If you
have skilled programmers with computers and Internet connections then
their wages inflate to the world norm. IIRC India is seeing 20%/year
wage inflation for comp-sci graduates. And thats without the impact of
H1-B and related programmes around the world.
Tim Chevalier
> > This is true only if talking to people in high-income nations.
> >
> Even in low-income nations, its only false in the short term. If you
> have skilled programmers with computers and Internet connections then
> their wages inflate to the world norm. IIRC India is seeing 20%/year
> wage inflation for comp-sci graduates. And thats without the impact of
> H1-B and related programmes around the world.
>
It's true that India seems to be going in that direction, but
personally I don't feel I have the background or temerity to suggest
that it will definitely happen for the rest of the world.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"We're born, we live for a brief instant, and we die. Technology is
not changing it much, if at all."--Steve Jobs
jerzy.kar...@info.unicaen.fr
>> > This is true only if talking to people in high-income nations.
>> >
>> Even in low-income nations, its only false in the short term. If you
>> have skilled programmers with computers and Internet connections then
>> their wages inflate to the world norm. IIRC India is seeing 20%/year
>> wage inflation...
> It's true that India seems to be going in that direction, but
> personally I don't feel I have the background or temerity to suggest
> that it will definitely happen for the rest of the world.
The issue is less related to the actual income, but to the global politics,
sometimes doctrinal. Not always the "invisible hand" of market may easily
change things, and if a given nation/country has historical strong views
on the "power of the people", the evolution is different than at your place.
India doesn't seem to boast that they are numerous and powerful. Chinese
do... We shall see.
You may perhaps remember (which you won't, because you are too young) the
glorious times when computers became a reality even in Soviet Union. They
had at that time plenty of really good mathematicians. But the totalitarian
view of the science, plus the nationalistic proudness, made them (the rulers
not the scientists...) think and say that with so many good people, there
is no need to develop the programming automated tools.
They neglected the programming languages. Russia and their satellites became
a kind of desert here not only because of economical problems...
Jerzy Karczmarczuk
Dipankar Ray
Jerzy,
this is a very interesting point you bring up, from my perspective.
I should point out that certain US-trained mathematicans (myself included)
are actually quite jealous of the Russian math education system - they
produce mathematicians who tend to be excellent in depth and breadth, who
are both great computationally and in terms of facility with abstract
formalism. Kontsevich, Drinfel'd, Gromov, Givental, Beilinson, the whole
Gelfan'd school - these people are incredible on all fronts.
When I was an undergrad math major in the US, there was a clear culture of
valueing proofs over computation. Integrals were sneered at; the more
abstract the argument, the more representative of "true mathematics" it
surely must be.
Now that I'm older I recognize that this is a special case of the
teenager's way of declaring himself special: "I'm *better* than those
idiot physicists who are so trivial as to care about integrals". Could be
a recent convert to jazz talking about rock, or whatever.
Anyway, no we're older, and we realize that it would have helped our math
understanding out quite a bit had we learned more physics, engineering,
etc. Or had we learned 19th century mathematics well. The Russian program
seems to do this, actually (at least for the sample set of kids that make
it to the US).
What you're telling me below is that part of this emphasis on old-world
mathematics might have come from an arrogance/bias against computers?
Interesting - I'll have to think about this.
I've often heard from my Eastern European colleagues that they learned
almost nothing about computer science back home...
Artem V. Andreev
Not wishing to refute your general point, I can only note that U.S.S.R did
have its own school of computer science in general, and of developing
programming language implementations in particular.
There were Fortran and Algol compilers, there is Refal, after all,
which is a purely Soviet invention (and which, for that matter,
is still being taught in several Russian universities).
So in this particular respect you are definitely wrong.
--
S. Y. A(R). A.
Stefan Monnier
>> explaining a correctness or productivity feature.
Is it? Maybe you're right.
But historically, computers have been available at all kinds of price
ranges, so people chose the price point that fit them. So, for the last
15 years or so already computers have been chosen (in the wealthy
countries) to be cheaper than programmers.
Is there any reason to think that the same forces aren't at play in
lower-income nations? After all, cheap (typically second hand)
computers are easy to come by.
Stefan
jerzy.kar...@info.unicaen.fr
> I should point out that certain US-trained mathematicans (myself included)
> are actually quite jealous of the Russian math education system - they
> produce mathematicians who tend to be excellent...
> Anyway, no we're older, and we realize that it would have helped our math
> understanding out quite a bit had we learned more physics, engineering,
> etc. Or had we learned 19th century mathematics well. The Russian program
> seems to do this, actually (at least for the sample set of kids that make
> it to the US).
>
> What you're telling me below is that part of this emphasis on old-world
> mathematics might have come from an arrogance/bias against computers?
> Interesting - I'll have to think about this.
>
> I've often heard from my Eastern European colleagues that they learned
> almost nothing about computer science back home...
===
Well, I have the impression, at least I intended to say just the reverse
(not the opposite), that the arrogance/bias against computers has been
partly "justified" by a very good level in math. The decision makers
confounded the math science with the domain of computation...
[[Let's skip the ideological war against cybernetics as the reactionary
pseudo-science which would enslave the proletarian class. End of '50,
beginning of '60 this was already completely anecdotical, although some
bitter aftertaste persisted...]]
The stagnation in the development of automatics followed the same pattern.
"We have good, brave people. Who needs 'em robots"...
It is an *established fact* that some part of casualties during the struggle
to confine Tchernobyl could have been avoided, if the authorities thought
more about replacing humans with machines. But not only the authorities,
folks themselves rushed to help, and safety measures were not respected as
they should have been if a more "liberal" doctrine, with calculation of risk
"à l'Américaine", prevailed.
And, PLEASE, Artem V. Andreev, before you say plainly again that I am
"definitely wrong". I didn't invent what I say, and I hope nobody can accuse
me of any inimical thoughts against Russians.
You say:
> Not wishing to refute your general point, I can only note that U.S.S.R did
> have its own school of computer science in general, and of developing
> programming language implementations in particular.
> There were Fortran and Algol compilers, there is Refal, after all,
> which is a purely Soviet invention (and which, for that matter,
> is still being taught in several Russian universities).
> So in this particular respect you are definitely wrong.
Please compare the size of the country, the achievements in military
equipment, cosmic exploration, etc., with what we could have seen in the
development of software... An Algol compiler has even been built in my
Poland, much smaller and miserable. Nothing to be proud of.
My goodness, Refal... You mean the Turchin stuff? OK, OK... Nice guy,
*really*. Nice idea. And no consequences...
Nothing bad can I say, because I know a tiny bit about the related
stuff. The language Snobol (Griswold et al.), was also based on Markov
algorithms (and some centuries ago I wrote a small textbook on Snobol,
I planned to teach at that time in Poland. I knew that Refal existed, and...
I couldn't learn anything more).
I wonder how much could do Markov himself (1903 - 1979),
- his: "Theory of Algorithms" was published by the American Mathematical
Society Translations in 1960, - if he lived in a more open society, which
could *better* exploit the potential of these people.
Do you think that I haven't heard about A.P. Yershov? ACM still cites him,
his papers on the system ALPHA (JACM 1966), programming of arith. ops.
(CACM 1958), etc. Some other names deserve mentioning as well. But what the
system did, cannot be defended. This "School of computer science" gave some
theory to the humanity. But no, or almost no software, sorry. I *sincerely*
hope that it changed now.
Tim Chevalier
> >> * Say "computers are cheap but programmers are expensive" whenever
> >> explaining a correctness or productivity feature.
> > This is true only if talking to people in high-income nations.
>
> Is it? Maybe you're right.
>
Yes -- consider the OLPC project (and its competitors). In some
developing nations, $200 for a laptop is still a *lot* to pay (the
laptop I'm typing this on cost $1400, purchased on a government grant,
and that purchase was treated as nothing.) Labor is a lot cheaper in
those places. And there's not much in the way of big government
funding (whether for universities or companies) to pay for any of it.
> But historically, computers have been available at all kinds of price
> ranges, so people chose the price point that fit them. So, for the last
> 15 years or so already computers have been chosen (in the wealthy
> countries) to be cheaper than programmers.
>
> Is there any reason to think that the same forces aren't at play in
> lower-income nations? After all, cheap (typically second hand)
> computers are easy to come by.
Not with the same amount of computing power that computers that run
modern application tend to have; a lot of places don't even have
reliable *electricity* (so in that case, lots of people and limited
machines could be *good*, if the machines aren't working all the
time), etc. I don't really know enough to give a more complete answer
to your question. But my original point is that saying labor is always
expensive and hardware is always cheap by comparison is a culturally
biased statement, at least right now, on January 26, 2008.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"I eat too much / I laugh too long / I like too much of you when I'm
gone." -- Ani DiFranco
Artem V. Andreev
> And, PLEASE, Artem V. Andreev, before you say plainly again that I am
> "definitely wrong". I didn't invent what I say, and I hope nobody can accuse
> me of any inimical thoughts against Russians.
I had not the slightest intention to accuse you of anything. Nor did I want to
defend how U.S.S.R treated scientists and all that. But I really wonder where
you get it from that in U.S.S.R computer science was treated in any way *differently*
from any other branches of science? Hardware engineering -- yep, that was a kind of
disaster. Which of course cannot but have absolutely negative impact on programming
as well as theoretical computer science.
But I have never heard that U.S.S.R authorities banned any kind of software development as such,
on the ground that there were enough mathematicians around...
> Do you think that I haven't heard about A.P. Yershov? ACM still cites him,
> his papers on the system ALPHA (JACM 1966), programming of arith. ops.
> (CACM 1958), etc. Some other names deserve mentioning as well. But what the
> system did, cannot be defended. This "School of computer science" gave some
> theory to the humanity. But no, or almost no software, sorry.
That's of course true. But that does not mean that no software were being developped;
that only means the software did not cross the borders...
--
S. Y. A(R). A.
Isaac Dupree
> The
> power of Haskell's type system makes it feel like you are programming in
> a dynamic language to some degree, yet all of it is type-checked, and
> that is just *really* cool.
to some degree, (in current Haskell compilers), it *is* more like a
dynamic than a static language: except when optimized away, values of
all types are represented by a pointer to their actual value. (this
helps with parametric polymorphism and laziness (take :: Int -> [a] ->
[a]).) (at least this is a difference compared to C++)
~Isaac
Derek Elkins
> Michael Reid wrote:
> > The
> > power of Haskell's type system makes it feel like you are programming in
> > a dynamic language to some degree, yet all of it is type-checked, and
> > that is just *really* cool.
>
> to some degree, (in current Haskell compilers), it *is* more like a
> dynamic than a static language: except when optimized away, values of
> all types are represented by a pointer to their actual value. (this
> helps with parametric polymorphism and laziness (take :: Int -> [a] ->
> [a]).) (at least this is a difference compared to C++)
Boxing is orthogonal to dynamic/static. You can have boxing in
statically typed languages, e.g. Haskell, Java, C# and you can have
unboxed values in dynamically typed languages.
Isaac Dupree
> On Sat, 2008-01-26 at 20:49 -0500, Isaac Dupree wrote:
>> Michael Reid wrote:
>>> The
>>> power of Haskell's type system makes it feel like you are programming in
>>> a dynamic language to some degree, yet all of it is type-checked, and
>>> that is just *really* cool.
>> to some degree, (in current Haskell compilers), it *is* more like a
>> dynamic than a static language: except when optimized away, values of
>> all types are represented by a pointer to their actual value. (this
>> helps with parametric polymorphism and laziness (take :: Int -> [a] ->
>> [a]).) (at least this is a difference compared to C++)
>
> Boxing is orthogonal to dynamic/static. You can have boxing in
> statically typed languages, e.g. Haskell, Java, C#
yes I know, although we are talking about communicating to people who
don't necessarily know as much as we do.
> and you can have
> unboxed values in dynamically typed languages.
really? Sure that's possible as an optimization, but I thought that to
explicitly specify that would require a known static type. Or perhaps
the bit-"tagging" by which some Scheme implementations are able to hold
small integers without a pointer (IIRC)?
~Isaac
Derek Elkins
> 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":
>
>
> 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_functional_programming.3F
>
> 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?
>
>
> 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.
This recent blog entry about PLT Scheme may be useful:
http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-and-set-cdr.html
Bulat Ziganshin
Saturday, January 26, 2008, 11:03:30 PM, you wrote:
>>> * Say "computers are cheap but programmers are expensive" whenever
>>> explaining a correctness or productivity feature.
>> This is true only if talking to people in high-income nations.
> Even in low-income nations, its only false in the short term. If you
> have skilled programmers with computers and Internet connections then
> their wages inflate to the world norm. IIRC India is seeing 20%/year
> wage inflation for comp-sci graduates.
they know English. and Internet/modern computers are not so easily
available in poor countries. try for example to find programmers from
Uzbekistan on the net :D
--
Best regards,
Bulat mailto:Bulat.Z...@gmail.com
Bulat Ziganshin
Sunday, January 27, 2008, 12:16:38 AM, you wrote:
> Anyway, no we're older, and we realize that it would have helped our math
> understanding out quite a bit had we learned more physics, engineering,
> etc. Or had we learned 19th century mathematics well. The Russian program
> seems to do this, actually (at least for the sample set of kids that make
> it to the US).
oh, yes, they are really still study 19th century physics, but not
because of great mind, but due to age of university professors. i've
studied at Moscow University in 89-91 and department of computer
languages still studied Lisp at those times (!). a few months ago i
have a conversation with today student and they still learn Lisp (!!!).
it seems that they will switch to more modern FP languages no earlier
that this concrete professor, head of PL department, which in 60s done
interesting AI research, will dead, or at least go to the pension
--
Best regards,
Bulat mailto:Bulat.Z...@gmail.com
_______________________________________________
Bulat Ziganshin
Sunday, January 27, 2008, 1:14:46 AM, you wrote:
> But historically, computers have been available at all kinds of price
> ranges, so people chose the price point that fit them. So, for the last
> 15 years or so already computers have been chosen (in the wealthy
> countries) to be cheaper than programmers.
> Is there any reason to think that the same forces aren't at play in
> lower-income nations? After all, cheap (typically second hand)
> computers are easy to come by.
what you mean by cheap computer? one which can't run modern software
at all, smth like first IBM PC? :) in poor countries there is not
just second-hand computers because local sources doesn't exist (in
order to have 100k of second-hand computers people should buy the same
100k new computers a few years ago), and global import of second-hand
computers is non-existant
--
Best regards,
Bulat mailto:Bulat.Z...@gmail.com
_______________________________________________
Bulat Ziganshin
Sunday, January 27, 2008, 1:48:07 AM, you wrote:
>> I've often heard from my Eastern European colleagues that they learned
>> almost nothing about computer science back home...
> ===
> Well, I have the impression, at least I intended to say just the reverse
> (not the opposite), that the arrogance/bias against computers has been
> partly "justified" by a very good level in math. The decision makers
> confounded the math science with the domain of computation...
i don't think that there were any decisions. Soviet system is just system
of government monopolies where each monopoly "works" in the way that
is more comfortable for its bureaucrats rather than "users". it's true
for factories, communal services, shops, anything. at the beginning of
computer era, computational mathematics was the only computer
application and our CS started in these fields, like american's one.
but then new applications arrived, and western CS was switched to
service them, while here professors continued to teach that they know
better, push the math into the programs of other institutes and so on.
it's no problem for Soviet system that institute prepares specialists
for non-existing applications - they should learn yourself. so we just
have system of "science for science" without any practical outcome,
and contents of this science dictated by professors who was actual 50
years ago
--
Best regards,
Bulat mailto:Bulat.Z...@gmail.com
_______________________________________________
Alex Young
> Derek Elkins wrote:
>> and you can have
>> unboxed values in dynamically typed languages.
>
> really? Sure that's possible as an optimization, but I thought that to
> explicitly specify that would require a known static type. Or perhaps
> the bit-"tagging" by which some Scheme implementations are able to hold
> small integers without a pointer (IIRC)?
a single machine word), bools and nil are unboxed, distinguished from
boxed types by the lowest 2 bits. That's undistinguishable at runtime,
though - everything Just Works as though they're ordinary objects,
including flipping integer class to Bignum (which is boxed) as necessary.
--
Alex
Hans van Thiel
> Hello Dipankar,
>
> Sunday, January 27, 2008, 12:16:38 AM, you wrote:
>
> > Anyway, no we're older, and we realize that it would have helped our math
> > understanding out quite a bit had we learned more physics, engineering,
> > etc. Or had we learned 19th century mathematics well. The Russian program
> > seems to do this, actually (at least for the sample set of kids that make
> > it to the US).
>
> oh, yes, they are really still study 19th century physics, but not
> because of great mind, but due to age of university professors. i've
> studied at Moscow University in 89-91 and department of computer
> languages still studied Lisp at those times (!). a few months ago i
> have a conversation with today student and they still learn Lisp (!!!).
> it seems that they will switch to more modern FP languages no earlier
> that this concrete professor, head of PL department, which in 60s done
> interesting AI research, will dead, or at least go to the pension
>
company for a short while in 1999 and they had two Russian software
engineers there, one from St. Petersburg and one from Wladiwostok, both
female and under 25 years of age. They programmed in C and were highly
respected by their managers and colleagues! So, there are at least
counterexamples :-)
Regards,
Hans van Thiel
Victor Nazarov
> oh, yes, they are really still study 19th century physics, but not
> because of great mind, but due to age of university professors. i've
> studied at Moscow University in 89-91 and department of computer
> languages still studied Lisp at those times (!). a few months ago i
> have a conversation with today student and they still learn Lisp (!!!).
> it seems that they will switch to more modern FP languages no earlier
> that this concrete professor, head of PL department, which in 60s done
> interesting AI research, will dead, or at least go to the pension
>
due to Paul Graham.
What I really want to mention is that the philosophy of education in
Russia consider "modern" irrelevant. "Modern" changes really fast and
it is not any better to teach something modern then outdated, except
if you are going to create some ballast of Java programmers who will
prevent progress and preserve market stability, i. e. really be
outdated. What university try to do is teach you how to swim really
good, so you'll have a better chances to find out where to swim. I
mean they teach you to learn, not anything else. Everything else is
just a pretty bonus.
--
vir
http://vir.comtv.ru/
Brian Sniffen
> a few months ago i
> have a conversation with today student and they still learn Lisp (!!!).
> it seems that they will switch to more modern FP languages no earlier
> that this concrete professor, head of PL department, which in 60s done
> interesting AI research, will dead, or at least go to the pension
I dunno. Sussman and Abelson are not getting any younger, and neither
is Felleisen, but others have taken up that torch. So far, those who
waited for Lisp to die out have spent a long time waiting. It has not
been a winning bet.
-Brian
--
Brian T. Sniffen
b...@alum.mit.edu or brian....@gmail.com
http://www.evenmere.org/~bts
Don Stewart
> On Jan 27, 2008 3:49 AM, Bulat Ziganshin <bulat.z...@gmail.com> wrote:
> > a few months ago i
> > have a conversation with today student and they still learn Lisp (!!!).
> > it seems that they will switch to more modern FP languages no earlier
> > that this concrete professor, head of PL department, which in 60s done
> > interesting AI research, will dead, or at least go to the pension
>
> I dunno. Sussman and Abelson are not getting any younger, and neither
> is Felleisen, but others have taken up that torch. So far, those who
> waited for Lisp to die out have spent a long time waiting. It has not
> been a winning bet.
>
And just as PLT Scheme announces they're moving to immutable, pure lists
http://lambda-the-ultimate.org/node/2631
They'll be getting a type system soon, at this rate ;)
-- Don
Lennart Augustsson
Derek Elkins
> brian.sniffen:
> > On Jan 27, 2008 3:49 AM, Bulat Ziganshin <bulat.z...@gmail.com> wrote:
> > > a few months ago i
> > > have a conversation with today student and they still learn Lisp (!!!).
> > > it seems that they will switch to more modern FP languages no earlier
> > > that this concrete professor, head of PL department, which in 60s done
> > > interesting AI research, will dead, or at least go to the pension
> >
> > I dunno. Sussman and Abelson are not getting any younger, and neither
> > is Felleisen, but others have taken up that torch. So far, those who
> > waited for Lisp to die out have spent a long time waiting. It has not
> > been a winning bet.
> >
>
> And just as PLT Scheme announces they're moving to immutable, pure lists
> http://lambda-the-ultimate.org/node/2631
>
> They'll be getting a type system soon, at this rate ;)
Well we have: "The Design and Implementation of Typed Scheme" very
recently http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf This is
something in the "soft typing" tradition (and uses PLT Scheme as the
vehicle.)
I believe PLT Scheme already supports a HM typed version of Scheme
though primarily for pedagogical purposes if I remember correctly.
It is however, unlikely that Scheme will ever be statically typed "by
default."
Lennart Augustsson
scripting language to a language to write real systems you need static
types.
Derek Elkins
> On Jan 27, 2008 3:49 AM, Bulat Ziganshin <bulat.z...@gmail.com> wrote:
> > a few months ago i
> > have a conversation with today student and they still learn Lisp (!!!).
> > it seems that they will switch to more modern FP languages no earlier
> > that this concrete professor, head of PL department, which in 60s done
> > interesting AI research, will dead, or at least go to the pension
>
> I dunno. Sussman and Abelson are not getting any younger, and neither
> is Felleisen, but others have taken up that torch. So far, those who
> waited for Lisp to die out have spent a long time waiting. It has not
> been a winning bet.
No language that was ever "popular" has ever died as far as I can tell.
Dipankar Ray
Hello Jerzy and Bulat,
Thanks for your perspectives. Bulat, I can understand that you find it
shocking that the folks at Moscow University still study Lisp, but I
wouldn't be so quick to condemn them for being dinosaurs. After all, they
just stopped teaching the SICP course (using Scheme) at MIT, and I don't
believe that they replaced it with an intro to CS course that uses (say)
Haskell or ML! Nor has Berkeley, far as I know.
..ok, I looked, the MIT intro course is now taught in python. I'll let
you decide if that's a step up from scheme.
Which brings us back to the topic of the original thread - Simon's request
for perspectives. The wonderfulness of advances in type theory these past
20 years, which are appreciated so readily here - they don't seem to have
achieved universal acceptance in industry or in academia.
What I mean by this is that if I look at the CS programs at Berkeley, MIT,
CMU, I don't see a huge emphasis on PL. Looking now at the MIT
opencourseware offerings in EECS, I see no undergrad course that suggests
that you'd learn anything about modern type theory.
Of course we know here of success stories involving modern fp languages.
But there is no haskell or ml book that has had close to the influence of
K&R's C book. One might argue that adoption on that scale is not the goal
of the haskell community (was it Kernighan, Ritchie, or Thompson's goal? I
think not), but still, it's weird to me that:
1) we're clearly on to something, but still
2) many smart people who are interested walk away frustrated (not so easy
to learn (is the hardness necessary? perhaps?), relative to K&R, for
example).
3) most of the canonical US universities for CS (MIT, Berkeley, Stanford,
CMU, etc) basically don't teach haskell or ML, or even talk much about it,
relative to how much they talk about, say, Java.
It's one thing that companies don't move forward; yet another thing that
Universities don't either. Why is that? Why, in 2008, is Java taught more
than Haskell?
Bulat Ziganshin
Sunday, January 27, 2008, 5:02:57 PM, you wrote:
>> studied at Moscow University in 89-91 and department of computer
>> languages still studied Lisp at those times (!). a few months ago i
>>
> This reminds me, I worked at a Dutch telecomm software production
> company for a short while in 1999 and they had two Russian software
> engineers there, one from St. Petersburg and one from Wladiwostok, both
> female and under 25 years of age. They programmed in C and were highly
> respected by their managers and colleagues! So, there are at least
> counterexamples :-)
no. you should asked them HOW they learned programming and i'm pretty
sure (knowing too much about our universities and institutes) that
they were just a self-learned - like myself. generally speaking, our
higher education now just starting to teach students "new" Java
technologies - you can imagine how old is knowledge they get there.
actually, all the good russian programmers i ever seen are
self-learned
--
Best regards,
Bulat mailto:Bulat.Z...@gmail.com
_______________________________________________
jerzy.kar...@info.unicaen.fr
//Discussion about Lisp in Russia, some people not getting younger, Scheme
with types, and other bedlam//
> No language that was ever "popular" has ever died as far as I can tell.
This is one of the persistent "truths" which has to be carefully
interpreted. Languages mutate and give offsprings, bearing sometimes the
same name. The original Fortran is undoubtly dead and buried. Long live
Fortran!
In some cases people defend this thesis with sophism. Algol is dead. No
sense in disputing it. So what? It simply was never "popular enough"...
Since the Nature abhorrs vacuum, all niches tend to become non-empty, and
for any language, there will be some guys who will play with it. Snobol
is alive, APL as well. Perhaps even Simula.
When can we say that it is *really* dead? How many users? Languages are
"alive" when people who used them are alive, and we didn't have had time
enough to kill all of them, patriarchs... Look, Simon Peyton Jones was
born more or less simultaneously with Fortran. And he is not so terribly
old, is he? (Weeeeelll, perhaps for some of you, but not for me.)
Anyway, a language, as any other conceptual structure, can be
stored and communicated. You may kill all the "working instances", and
rekindle it later. It such a way it is difficult to kill a religion, or
a political doctrine. But it may die, become useless/unused temporarily.
So, you never really know...
Jerzy Karczmarczuk
Dan Licata
> What I mean by this is that if I look at the CS programs at Berkeley, MIT,
> CMU, I don't see a huge emphasis on PL. Looking now at the MIT
> opencourseware offerings in EECS, I see no undergrad course that suggests
> that you'd learn anything about modern type theory.
>
> CMU, etc) basically don't teach haskell or ML, or even talk much about it,
> relative to how much they talk about, say, Java.
Not to dispute your general point, but CMU is an exception to this rule.
There's a course, taught in SML, on basic functional programming,
continuations, laziness, etc:
http://www.cs.cmu.edu/~me/212/
This course is required for all CS majors and occurs fairly early in the
sequence (freshman spring or sophomore fall).
We also have a fairly hardcore introduction to type systems and
operational semantics:
http://www.cs.cmu.edu/~rwh/courses/ppl/
and a course on constructive logic:
http://www.andrew.cmu.edu/course/15-317/
These electives are taken by ~30-40 students each, so I'd guess that
somewhere between a third and a half of the undergrads go through one of
them.
And then there are electives, either mostly undergrad, like this course
in typed compilation:
http://www.cs.cmu.edu/~crary/hotc/
or mostly grad, like this course on logic programming (but there are
always at least a handful of undergrads in the room):
http://www.cs.cmu.edu/~fp/courses/lp/
And then there are two grad-level PL distribution-requirement courses
(one on type systems, one on denotational semantics), which usually have
a few interested undergrads. And many undergrads get involved in PL
research as well.
Maybe the real question is why so few universities have large groups of
PL faculty to teach these courses? =)
-Dan
Tim Chevalier
>
> Hello Jerzy and Bulat,
>
> Thanks for your perspectives. Bulat, I can understand that you find it
> shocking that the folks at Moscow University still study Lisp, but I
> wouldn't be so quick to condemn them for being dinosaurs. After all, they
> just stopped teaching the SICP course (using Scheme) at MIT, and I don't
> believe that they replaced it with an intro to CS course that uses (say)
> Haskell or ML! Nor has Berkeley, far as I know.
>
Correct -- CS 61A at Berkeley (the 6.001 analogue there) is still
taught in Scheme, and I suspect that anyone who wants to change that
will have to pry the course out of Brian Harvey's cold, dead hands.
> What I mean by this is that if I look at the CS programs at Berkeley, MIT,
> CMU, I don't see a huge emphasis on PL. Looking now at the MIT
> opencourseware offerings in EECS, I see no undergrad course that suggests
> that you'd learn anything about modern type theory.
As a former graduate student instructor for the undergrad compiler
class at Berkeley, I can confirm that this statement is mostly but not
quite true for Berkeley. (As Dan Licata pointed out, CMU is an
exception here; I get the feeling MIT is more like Berkeley than MIT
in this respect.) The compiler class there (CS 164) is required for
all CS majors, and depending who's teaching it in a given semester,
students might well get to see formal presentations of both static and
dynamic semantics for a simple object-oriented language (at least the
the time when I taught a section of the class, though I see that right
now their target language is Python.) Granted, students have the
option of either Java or C++ for the implementation languages, which
is less than ideal.
>
> Of course we know here of success stories involving modern fp languages.
> But there is no haskell or ml book that has had close to the influence of
> K&R's C book. One might argue that adoption on that scale is not the goal
> of the haskell community (was it Kernighan, Ritchie, or Thompson's goal? I
> think not), but still, it's weird to me that:
>
At least based on my own experience and that of my peers, I think
people from my generation who got interested in FP languages mostly
got turned on by a particular teacher who was really into it, rather
than by a particular book.
> 1) we're clearly on to something, but still
>
> 2) many smart people who are interested walk away frustrated (not so easy
> to learn (is the hardness necessary? perhaps?), relative to K&R, for
> example).
>
For #2, note my comment above about teachers. It's always easier and
more motivating to learn when you have someone a little more
experienced to guide and encourage you. But for FP, there are fewer
people around to do the teaching, thus more people get discouraged. I
feel like I'm saying something tautological here, though: if nobody
teaches, nobody can learn.
For some reason or another, I think being self-taught when it comes to
FP is hard in a way that being self-taught when it comes to
programming in general isn't -- perhaps it's for the same reason that
being a self-taught mathematician is hard, though some people pull it
off. Personally I think I'm pretty self-motivated, and am self-taught
in a lot of other areas, but I don't think I ever would have learned
Haskell on my own. So what does that say about programmers as a whole?
> 3) most of the canonical US universities for CS (MIT, Berkeley, Stanford,
> CMU, etc) basically don't teach haskell or ML, or even talk much about it,
> relative to how much they talk about, say, Java.
>
> It's one thing that companies don't move forward; yet another thing that
> Universities don't either. Why is that? Why, in 2008, is Java taught more
> than Haskell?
>
There's really only one reason for this: at least in the United
States, universities are becoming more and more like businesses, and
faculty feel they have to give students what they want in order to
"compete". Computer science undergrads, as a whole, want to learn Java
or C++ "so they can learn something that'll be useful and help them
get a job." The faculty know this is ridiculous, but a lot of them
buckle under anyway because they need to boost their enrollments. The
notion of the university as a place where students pay faculty members
so that they might benefit from the vaster experience and judgment of
the faculty -- which means deferring certain decisions to those who
are wiser than you -- seems to be going out the window along with
paper registration cards.
Moreover: At Berkeley, the faculty didn't teach Haskell or ML because
they didn't believe in Haskell or ML. If you personally don't think
that a language is ever going to be adopted -- if you think that it's
elegant but will never be practical -- it's going to be hard for you
to sell it to a 300-person hall full of undergrads, most of whom are
likely to start checking email the moment you say something that bores
them.
Disclaimer: This entire message consists of my personal opinions and
does not represent the opinions of anybody else, and probably won't
represent my opinions either in another day or two.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"don't you understand / in the day to day / in the face to face / i
have to act just as strong as i can / just to preserve a place where i
can be who i am" -- Ani DiFranco
Dipankar Ray
thanks for the correction - very informative! that'll teach me to just go
to the opencourseware site at MIT only...
Henning Thielemann
On Sun, 27 Jan 2008, Bulat Ziganshin wrote:
> Hello Hans,
>
> Sunday, January 27, 2008, 5:02:57 PM, you wrote:
>
> > This reminds me, I worked at a Dutch telecomm software production
> > company for a short while in 1999 and they had two Russian software
> > engineers there, one from St. Petersburg and one from Wladiwostok, both
> > female and under 25 years of age. They programmed in C and were highly
> > respected by their managers and colleagues! So, there are at least
> > counterexamples :-)
>
> no. you should asked them HOW they learned programming and i'm pretty
> sure (knowing too much about our universities and institutes) that
> they were just a self-learned - like myself. generally speaking, our
> higher education now just starting to teach students "new" Java
> technologies - you can imagine how old is knowledge they get there.
> actually, all the good russian programmers i ever seen are
> self-learned
Many things I need today for math and computer science I have acquired in
an auto-didactic way. These are usually the things I can remember most
easily. Isn't it a good education system if it allows, or supports, or
encourages or forces you to learn this way? :-)
Henning Thielemann
On Sun, 27 Jan 2008, Tim Chevalier wrote:
> On 1/27/08, Dipankar Ray <dipa...@jfet.net> wrote:
> >
> > 3) most of the canonical US universities for CS (MIT, Berkeley, Stanford,
> > CMU, etc) basically don't teach haskell or ML, or even talk much about it,
> > relative to how much they talk about, say, Java.
> >
> > It's one thing that companies don't move forward; yet another thing that
> > Universities don't either. Why is that? Why, in 2008, is Java taught more
> > than Haskell?
> >
>
> There's really only one reason for this: at least in the United
> States, universities are becoming more and more like businesses, and
> faculty feel they have to give students what they want in order to
> "compete". Computer science undergrads, as a whole, want to learn Java
> or C++ "so they can learn something that'll be useful and help them
> get a job."
Same here in Germany. Universities become controlled by industry leaders
(see "Hochschulfreiheitsgesetz") thanks to Bertelsmann et.al., and
universities are considered as producers of programmers for industry. With
this reasoning we offered an introduction to C for math students.
Jan-Willem Maessen
On Jan 27, 2008, at 11:05 PM, Dipankar Ray wrote:
>
> thanks for the correction - very informative! that'll teach me to
> just go to the opencourseware site at MIT only...
On that note, I'll point out that many (roughly half?) the
undergraduate CS majors at MIT do a 5 year combined bachelor's /
master's program. Many of them take the graduate programming
languages course (6.821), which has good coverage of semantics and
type inference.
That said, there's a good deal of skepticism about functional
programming among many MIT faculty members just as there is at
Berkeley. If you want to hear an entertaining story some day, ask me
in person about my Ph.D. thesis defense.
-Jan-Willem Maessen
CAya
> *really*. Nice idea. And no consequences...
Just put "supercompilation" in google and tell me if there are no
consequences or no research on this.
Some papers explore the relationship between Interpretation/
Compilation even further
"From Standard To Non-Standard Semantics By Semantics
Modifiers" (http://citeseer.ist.psu.edu/508136.html)
cheers
Carlos
naas...@gmail.com
> [...]
>
> 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.
> [...]
> 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.
I think most developers can relate to this, as both Java and .NET are
now pushing "generics" aka parametric polymorphism. Pointing out how
powerful polymorphism is outside of collections might be useful too.
I'll also second the Maybe/Option type, but generalize it to
"algebraic datatypes" + pattern matching + exhaustiveness checking.
As for other features of note, I wrote a post dissecting more advanced
language features awhile ago:
http://higherlogics.blogspot.com/2007/10/on-importance-of-purity.html
It has some flaws, but I think there are some important points. The
resulting LTU discussion was lively as well:
http://lambda-the-ultimate.org/node/2510
Sandro
Stephan Friedrichs
> stephan.friedrichs:
>> [...]
>>
>> We [1] implemented an ad-hoc chat system in Haskell in the SEP [2] at
>> the TU-Braunschweig.
>
> Wow!
>
> Looks like lots of great code in there,
>
> http://sep07.mroot.net/documentation/barracuda/
>
> Text.ParserCombinators.Parsec.XML
> Codec.Encryption.PKCS1
> Network.GnuTLS
> Data.Heap
>
> Will we see this packaged for hackage.haskell.org soon?
> Some of those modules look very reusable.
I just uploaded a generalised heap (min-, max- and custom-heaps)
implementation:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.1
Feedback would be appreciated :)
//Stephan
--
Früher hieß es ja: Ich denke, also bin ich.
Heute weiß man: Es geht auch so.
- Dieter Nuhr
apfelmus
> I just uploaded a generalised heap (min-, max- and custom-heaps)
> implementation:
>
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.1
>
> Feedback would be appreciated :)
Feedback: I think the HeapPolicy thing is too non-standard. The
canonical way would be to use a MinHeap and let the Ord instance handle
everything. A MaxHeap can then be obtained via a different Ord instance
newtype Ord a => Reverse a = Reverse { unReverse :: a }
instance Ord a => Ord (Reverse a) where
compare = comparing unReverse
This newtype should be in Data.Ord, of course. Being
minimum/maximum-agnostic seems like a noble goal but turns out not to be
that good. To see why, I'd like to report the first documentation bug:
will a custom heap's head be the minimum or the maximum with respect
to a custom heapCompare ? (ok, the docs for head indicate minimum,
but the docs for HeapPolicy should say so, too.)
Simply setting
type MaxHeap a = MinHeap (Reverse a)
is inferior to a "native" MaxHeap since we'd have to pack/unpack the
Reverse all the time. But a type class for heaps - which should be
present anyway - can solve that problem:
class Heap h where
empty :: h a
insert :: Ord a => a -> h a -> h a
viewHead :: Ord a => h a -> Maybe (a, h a)
fromAscList :: Ord a => [a] -> h a
toAscList :: Ord a => h a -> [a]
null :: Ord a => h a -> Bool
null = isNothing . viewHead
singleton :: Ord a => a -> h a
singleton = flip insert empty
head :: Ord a => h a -> a
head = fst . fromJust . viewHead
deleteHead :: Ord a => h a -> h a
deleteHead = maybe empty snd . viewHead
... etc.
instance Heap MinHeap where ...
newtype MaxHeap a = M (MinHeap (Reverse a))
instance Heap MaxHeap where ...
The union and unions functions are probably best not put in this
class but implemented via separate Monoid instances.
In conclusion: the ordering policy stuff should not be part of
Data.Heap, this is a job for Data.Ord.
In particular, Data.Ord might contain something like
newtype OrdBy p a = OrdBy { unOrdBy :: a }
class OrdPolicy p a where ...
instance OrdPolicy p a => Ord (OrdBy p a) where ...
which can then be used to implement heaps with such different orderings
in one go:
newtype OrdPolicy p a => HeapP p a = HeapP (MinHeap (OrdBy p a))
instance Heap (HeapP p) where ...
Regards,
apfelmus