Why isn't Haskell mainstream?---A newbie's view
Ryo Furue
First of all, I've chosen this subject to be provocative not to be
offensive. I post this because I sincerely wish Haskell would be
mainstream and because I think a newbie's view may be of help.
I'm a newbie, who is very much interested in functional programming
and is about to try out Haskell. I'm much experienced in programming
in imperative languages including C++, Fortran, Perl, Ruby, and
Bourne shell. I've read a couple of online introductory materials on
Haskell and come to like it very much.
To me, the problem of Haskell is the presentation. The tutorials I've
read first talk about Haskell's elegance and power by showing examples
such as the binary tree, function composition, and list manipulation.
I'm quite impressed with the elegance and power of Haskell. *BUT*,
when I try to write a program in Haskell for my real job, I get
stuck. I don't know how to open a file, read a line, extract
blank-separated fields from the line, pattern-match each field,
and produce output to another file. I don't know how to access the
command line options from within the program. I don't know how to
write to the screen and get the user's input from the terminal.
I don't know how to read a binary file, treat each byte separately,
and-ing, or-ing, and not-ing the bit pattern. I don't know what
library is available for regular expressions, mathematics (sin,
exp, value of pi, random numbers, etc.), networking, file and
directory manipulation, ... It's not normal for me not to know how to
write to the standard output after reading three online tutorials!
You would say, buy a textbook. Right. But, the reviews of textbooks
at http://www.haskell.org/ doesn't indicate which book to buy to find
out those things. On the contrary, I've got an impression that those
books exclusively talk about the academic side of the language, except
for Paul Hudak's book, which I'm not sure is what I'm looking for
because I'm not interested in multimedia. (I've ordered that book
anyway, without any other option...)
I know such things as opening a file are not the point of Haskell, but
without such components, you can't write a working program. So, in my
opinion, such mandatory parts should be taught first. Then, the pupil
would learn the core Haskell by writing working programs.
In short, Haskell is presented as academic. In my humble opinion,
examples should be shown for everyday programs. If you don't see what
I'm talking about, I recommend you read the Perl book ("Programming Perl"
by Larry Wall, et al., O'Reilly) or the Ruby pickaxe book
("Programming Ruby: A Pragmatic Programmer's Guide" by D. Thomas &
A. Hunt, Addison-Wesley).
Ryo
Benjamin Ylvisaker
furu...@ccsr.u-tokyo.ac.jp (Ryo Furue) wrote:
> In short, Haskell is presented as academic. In my humble opinion,
> examples should be shown for everyday programs. If you don't see
> what I'm talking about, I recommend you read the Perl book
> ("Programming Perl" by Larry Wall, et al., O'Reilly) or the Ruby
> pickaxe book ("Programming Ruby: A Pragmatic Programmer's Guide" by
> D. Thomas & A. Hunt, Addison-Wesley).
Another example of what I believe you are talking about, a little
closer to home:
http://web.access.net.au/felixadv/files/output/book/
Benjamin
Michel Schinz
[...]
> In short, Haskell is presented as academic. In my humble opinion,
> examples should be shown for everyday programs.
You might be interested in reading Simon Peyton Jones' article
"Tackling the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell" which talks
precisely about that kind of stuff. It's available there:
http://www.research.microsoft.com/Users/simonpj/Papers/marktoberdorf/
That said, I agree with your main point.
Michel.
Peter G. Hancock
On part of your complaint, there are two schools of thought about
teaching "IO" in Haskell. One is to treat it as an advanced topic,
right at the end. To my mind this is insane. The other is to teach
it right from the word go, but without ramming monads down the young
innocents' throats (till later). There are precious few teachers in
this school. One (the only) textbook along these lines is the one by
Paul Hudak you mention, called "The Haskell School of Expression". I
have however heard it described as "too difficult".
My (uncharitable) suspicion is that the reason IO is treated as an
"advanced" topic is that the academics don't understand it themselves.
As for where to find the interesting libraries, the first thing to
suggest is to read about the standard libraries on the Haskell
web-page
http://haskell.org/definition/.
Not everything interesting is there, but there are some pointers at
http://haskell.org/libraries/. And then there's google.
I'm afraid it's not really on a plate.
Peter Hancock
Kirsten Chevalier
> To me, the problem of Haskell is the presentation. The tutorials I've
> read first talk about Haskell's elegance and power by showing examples
> such as the binary tree, function composition, and list manipulation.
> I'm quite impressed with the elegance and power of Haskell. *BUT*,
> when I try to write a program in Haskell for my real job, I get
> stuck. I don't know how to open a file, read a line, extract
> blank-separated fields from the line, pattern-match each field,
> and produce output to another file. I don't know how to access the
> command line options from within the program. I don't know how to
> write to the screen and get the user's input from the terminal.
> I don't know how to read a binary file, treat each byte separately,
> and-ing, or-ing, and not-ing the bit pattern. I don't know what
> library is available for regular expressions, mathematics (sin,
> exp, value of pi, random numbers, etc.), networking, file and
> directory manipulation, ... It's not normal for me not to know how to
> write to the standard output after reading three online tutorials!
RTFM. All of this information is available at <http://www.haskell.org/ghc/>,
assuming you are using GHC -- the reason why it's not in textbooks is that
it's mostly implementation-specific. Besides, it doesn't have much to do
with the essentials of Haskell, except perhaps for the basic idea of
monadic I/O, which is IMO poorly presented in all the Haskell books I've seen
-- but you can learn that easily enough by looking at some example code.
--
Kirsten Chevalier * Often in error, never in doubt
"I'm getting further from the things I thought I knew, but I'm getting closer
to the truth."--Trout Fishing in America
http://www.cs.berkeley.edu/~krc/
Ketil Malde
I'll let others discuss the philosophical part, and just answer your
specific (if rhetoric) questions, for the benefit of future
generations googling for answers:
> I'm quite impressed with the elegance and power of Haskell. *BUT*,
> when I try to write a program in Haskell for my real job, I get
> stuck.
> I don't know how to open a file,
This is IO, you need to use the IO monad. Do NOT at this point try to
grok what a monad is, or why this is one, just accept it as a fact.
Then, structure your programs' main functions as:
module Main where
:
main :: IO ()
main = do
<var> <- <action>
let <var> = <expression>
<action>
:
Where <action> is an IO action, and <expression>s are pure.
Specifically you can do:
main = do
cs <- readFile "myFile" -- the contents of myFile is in cs
:
> read a line,
main = do
cs <- readFile "myFile"
let ls = lines cs -- ls is a list of lines (strings)
> extract blank-separated fields from the line,
main = do
cs <- readFile "myFile"
let ls = lines cs
let ws = words (head cs) -- list of words in the first line
> pattern-match each field,
Not quite sure what you want. Given a function (predicate) p, e.g
p :: String -> Bool
p (x:xs) = (x == 'a')
You can easily do:
main = do
cs <- readFile "myFile"
let ls = lines cs
let ws = words (head ls)
let as = filter p ws -- words starting with a
> and produce output to another file.
writeFile "myOtherFile" (unwords as)
> I don't know how to access the command line options from within the
> program.
import System
:
main = do
args <- getArgs
cs <- readFile (args!!0)
let ls = lines cs
let ws = words (head ls)
let as = filter p ws -- words starting with a
writeFile (args!!1) (unwords as)
> I don't know how to
> write to the screen [..] user's input [..] read a binary file [..]
> and-ing, or-ing, and not-ing the bit pattern [..]
> regular expressions, mathematics [..] networking, file and
> directory manipulation, ...
I'm going to leave these, since they are either more vaguely defined,
have many different possible solutions, or are easy to look up in the
documentation. What I included above should suffice to get you
started, I think.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
sL
is not fully developped and commented (no offense intended).
sL
Tim Sweeney
for mainstream tasks like file I/O, networking, and user interface
programming because Haskell isn't a good language for doing these
kinds of things. It's far easier to perform such tasks in imperative
object-oriented languages like C++, Java, C#, and Python, so that's
what people do. In Haskell, you have to resort to monads which lead
to explicit plumbing of state that is far more difficult to understand
than the sequential imperative model.
Most of the example code for Haskell deals with sorting, searching,
functional parsers, lambda evaluators, and other similar functional
recursive algorithms because Haskell is a great language for doing
that sort of thing, clearly more natural than mainstream languages
like C++ and Java.
So programmers flock to mainstream languages for performing primarily
mainstream tasks, and to functional-recursive languages for performing
primarily functional-recursive tasks, and the example code for all of
these languages just tends to reflect what the languages are best at.
gr...@cs.uwa.edu.au
: To be realistic, there isn't lots of example code available in Haskell
: for mainstream tasks like file I/O, networking, and user interface
: programming because Haskell isn't a good language for doing these
: kinds of things.
If only there were a better one. :(
: It's far easier to perform such tasks in imperative object-oriented
: languages like C++, Java, C#, and Python, so that's what people do.
: In Haskell, you have to resort to monads which lead to explicit
: plumbing of state
I find that the implicit handling of state tends to create method-call
and inheritance spaghetti junctions (particularly when calling one or
more sequence/state-dependant libraries) that make sequencing things
much harder in those languages than in Haskell, which is a serious
problem when they tend to force sequence/state-dependence onto parts
of the code that have no reason to be subjected to it.
: In Haskell, you have to resort to monads which lead to explicit
: plumbing of state that is far more difficult to understand than
: the sequential imperative model.
Is it? Or is it just because we tend to explain it in type-theoretical
terms? What if we had a compiler option that would require all
functions of IO type to have names beginning with "io", and told
beginning programmers that IO functions had to use do,<-,return,
and non-IO functions couldn't call IO functions directly? Would they
find it any harder to learn to _use_ monadic IO than they do to learn
to do IO in (say) Java? Of course, to use the full power that makes
Haskell superior to Java, they will eventually have to learn the type
system, and of course they will develop bad habits if they don't have
the fear of monads making them avoid the use of IO types wherever
possible, but will they learn the _practise_ of doing IO in Haskell
as easily as they learn it in another language, however hard it
might be to explain the theory behind it to a beginner?
: So programmers flock to mainstream languages for performing primarily
: mainstream tasks, and to functional-recursive languages for performing
: primarily functional-recursive tasks, and the example code for all of
: these languages just tends to reflect what the languages are best at.
Or does it reflect the sort of people who are using the languages,
(computer scientists vs. random programmers) or does it indeed reflect
the fact that performing a complex IO-related task seems like a big
achievement to a C++ programmer, while a Haskell programmer thinks it
is a piece of cake and too trivial to have the scope to show off the
power of a language?
-Greg
Adrian Hey
> It's far easier to perform such tasks in imperative
> object-oriented languages like C++, Java, C#, and Python, so that's
> what people do. In Haskell, you have to resort to monads which lead
> to explicit plumbing of state that is far more difficult to understand
> than the sequential imperative model.
Hmm..I don't know if many Haskellers would agree with that.
My experience is that even imperative programming in Haskell far
less painful than imperative programming in C or C++ (never
used Java). You've still got all the benefits of lightweight
syntax, not having to declare variables, static type security,
garbage collection (OK, Java has that), first class functions,
first class mutable variables (IORefs) if you need them..
> Most of the example code for Haskell deals with sorting, searching,
> functional parsers, lambda evaluators, and other similar functional
> recursive algorithms because Haskell is a great language for doing
> that sort of thing, clearly more natural than mainstream languages
> like C++ and Java.
Yep, but I would assert that it's more natural than mainstream
imperative languages for IO too.
Regards
--
Adrian Hey
Christian Szegedy
> To be realistic, there isn't lots of example code available in Haskell
> for mainstream tasks like file I/O, networking, and user interface
> programming because Haskell isn't a good language for doing these
> kinds of things. It's far easier to perform such tasks in imperative
> object-oriented languages like C++, Java, C#, and Python, so that's
> what people do. In Haskell, you have to resort to monads which lead
> to explicit plumbing of state that is far more difficult to understand
> than the sequential imperative model.
>
I think Haskell has very nive and very understandable support for all
these stuff. In fact, Haskell excells at e.g. parsing a files.
I don't just mean more advanced parser generators and librararies,
but you have a very simple but powerful tools for everyday use.
E.g., you can easily derive input and output functions for user
defined datatypes with one single function without additional work.
I have not seen this great feature in any other language yet.
I agree very much with Ryo that Haskells lacks a a newby oriented
introduction and nice reference. The Haskell Programmer would
really need a comprehensive reference a la Ruby's Pickaxe book.
Nick Kovaliov
TS> example code available in Haskell
TS> for mainstream tasks like file I/O,
TS> networking, and user interface programming
Give me, please, some links to this code ?
For example, some realization of SMTP client ?
Bye, WBR !
Jerzy Karczmarczuk
are you really attached to the idea of
Eine Sprache, eine Kirche, ein Fahrzeug?
Recently I've heard about a new contraption called F16, or
The Fighting Falcon. It would be very nice if this could be
a mainstream vehicle, and some people suggest that it is MUCH
better than anything else around. Easy to use, ergonomic, full
of semantic power, and relatively easy to maintain.
Unfortunately, it is - from my humble perspective - rather
useless.
I would like for example to jump into my F16, and go to the
nearest boulangerie to buy a baguette (I am Polish, but I am
not ready to boycott French baguettes yet). But, no, I can't.
I am still using my old bicycle, since the startup of F16 is
too long, and my wife protests.
I wanted to go on holidays with all my family, including my
mother, but I couldn't squeeze 5 persons in my F16, so I had
to use my old decaying Seat Toledo. Perhaps if the instruction
were written in a less academic style, and explain in a humane
way how to do it, e.g., how to reuse the space occupied by
some bombs and to attach my mother instead, I would be more
happy.
I discovered then that going fishing in a F16 is very difficult,
it simply won't float as I would like to see it, and anyway
all the fish run away from it.
And it makes a hell of noise...
And, even if the basic version is free, nobody can guarantee that
tomorrow Microsoft doesn't order to stop its distribution...
===
To finish once and for good with that myth that F16 *should* be
the mainstream vehicle. Sorry, but it has been designed with
some particular purpose. Many vehicles are universal, they can
move on sand or shoot some [..censored..], but that are not so
well designed to produce Web pages. English is extremely versatile,
but if there are social reasons to communicate in Afghana, Farsi
or Aramaic, then it is easier to learn that language than try
to convert some millions people to English (of course, the ideal
solution is intermediate. You don't learn anything, and you choose
some - just a theoretical model, nothing to do with the reality -
well, you choose some former thief condemned to 22 years of prison
for criminal bankrupcy, but who can be programmed in English and
can convert to Hassemblah'er your programs, and you make out of him
a hero who who will rule those English unspeaking people on your
behalf).
Jerzy Karczmarczuk
Caen, France
Sebastian Sylvan
> To be realistic, there isn't lots of example code available in Haskell
> for mainstream tasks like file I/O, networking, and user interface
> programming because Haskell isn't a good language for doing these
> kinds of things.
Hmm. I would agree to some extent. But I think the reason for most people
not writing these tutorials is because IO usually isn't a very large part
of any program, and it really isn't much more elegant in Haskell (you have
to do it with the IO monad, which basically is just an imperative language
right? So one might reason like "the point of Haskell isn't the imperative
aspects, so I'll leave those alone"). I'm in the process of writing
tutorials in Haskell right now, so I'll try to keep this in mind.
> In Haskell, you have to resort to monads which lead
> to explicit plumbing of state that is far more difficult to understand
> than the sequential imperative model.
>
Isn't the point of monads that you get away from explicit plumbing? That
you can hide all the data within the monad?
I'm not a Haskell guru by any means, but that's how I've understood it.
> Most of the example code for Haskell deals with sorting, <snip>
You mean the famous (and maybe over-used) 3-line quicksort example =)
--
----------------------------------------
| Sebastian Sylvan |
| ICQ: 44640862 |
| Tel: 073-6818655 / 031-812 817 |
| |
| |
| Hard Work Often Pays Off After Time |
| But Laziness Always Pays Off Now! |
----------------------------------------
Mark Carroll
Ketil Malde <ket...@ii.uib.no> wrote:
>furu...@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
(snip)
>> pattern-match each field,
>
>Not quite sure what you want. Given a function (predicate) p, e.g
GHC's Text.Regex.* may be worth mentioning too, and the existence of
nice parsers like Happy and Parsec.
-- Mark
Ryo Furue
you provided with!
Benjamin Ylvisaker <benj...@alumni.cmu.edu> wrote in message news:<20030408101225.2...@alumni.cmu.edu>...
> On 8 Apr 2003 06:49:33 -0700
> furu...@ccsr.u-tokyo.ac.jp (Ryo Furue) wrote:
>
> > In short, Haskell is presented as academic. In my humble opinion,
> > examples should be shown for everyday programs. If you don't see
> > what I'm talking about, I recommend you read the Perl book
> > [...] or the Ruby pickaxe book [...].
>
> Another example of what I believe you are talking about, a little
> closer to home:
>
> http://web.access.net.au/felixadv/files/output/book/
Yes, that's very close. In fact, some time ago I happened to begin to
read that article and found that the material was almost what I was
looking for. Unfortunately (for me), it's about SML, a language I
somehow didn't fall (or haven't fallen) in love with, by reading some
online introductory materials. And I have for mysterious reasons
fallen in love with Haskell.... For one thing, Haskell looks cleaner
to me than ML.
A person emailed and reminded me that Haskell is still young. He
guessed that the language would be more popular in, say, five years.
I really hope so.
By the way, Hudak's book arrived today. Looks good. I have a great
hope to enjoy programming in Haskell.
Ryo
Kirsten Chevalier
> To be realistic, there isn't lots of example code available in Haskell
> for mainstream tasks like file I/O, networking, and user interface
> programming because Haskell isn't a good language for doing these
> kinds of things. It's far easier to perform such tasks in imperative
> object-oriented languages like C++, Java, C#, and Python, so that's
> what people do. In Haskell, you have to resort to monads which lead
> to explicit plumbing of state that is far more difficult to understand
> than the sequential imperative model.
I strongly disagree (not that there isn't a lot of example code, which
is obviously true, at least if you compare to more mainstream languages),
but the reasons why. There is nothing difficult about monads -- it's
just that they are usually explained in terms of mathematics that is
interesting, but that you don't need to know about as a programmer just
to get the job done. The only reason not to use Haskell to do file I/O,
networking, or UI programming is performance (and possibily lack of
libraries in the last case). If you think otherwise, perhaps you haven't
tried it. (At the last POPL, Simon Peyton Jones was seen wearing a
sweatshirt that read, "Haskell: the world's finest imperative language.")
The main reason people use C++ rather than Haskell is the same reason people
use Windows rather than Linux: it's all they've heard of and they don't
know the reasons to use something else.
Joan Estes
> I'm a newbie, who is very much interested in functional programming
> and is about to try out Haskell.
> To me, the problem of Haskell is the presentation. The tutorials I've
> read first talk about Haskell's elegance and power by showing examples
> such as the binary tree, function composition, and list manipulation.
> I'm quite impressed with the elegance and power of Haskell. *BUT*,
> when I try to write a program in Haskell for my real job, I get
> stuck. I don't know how to open a file...
I find Haskell extremely interesting also. But I'm not using it
because I don't know how to do certain things that are elementary in
other languages:
1) Polymorphically extend a product type (record) with additional
fields. This is elementary in OO languages, extremely useful for
writing modular and maintainable programs, and I see no reason
why I should do without it in a functional language. In fact, it
does exist in Hugs in the form of TREX and in O'Hugs (O'Haskell),
but I need to use ghc for its speed.
2) Extend a sum type (algebraic datatype) with new constructors
without having to wrap it in a bogus constructor and explicitly
lift all functions defined on the original type to the new type.
Once again, this exists in pieces - O'Haskell has it and it seems
that it could be simulated in ghc with "deriving".
Personally, I will wait until Haskell has both (1) and (2) before
using it. Frustrating, because do think Haskell is quite beautiful.
J. Estes.
Miles Egan
> Tim Sweeney <t...@epicgames.com> wrote:
>: To be realistic, there isn't lots of example code available in Haskell
>: for mainstream tasks like file I/O, networking, and user interface
>: programming because Haskell isn't a good language for doing these
>: kinds of things.
>
> If only there were a better one. :(
>
>: It's far easier to perform such tasks in imperative object-oriented
>: languages like C++, Java, C#, and Python, so that's what people do.
>: In Haskell, you have to resort to monads which lead to explicit
>: plumbing of state
>
> I find that the implicit handling of state tends to create method-call
> and inheritance spaghetti junctions (particularly when calling one or
> more sequence/state-dependant libraries) that make sequencing things
> much harder in those languages than in Haskell, which is a serious
> problem when they tend to force sequence/state-dependence onto parts
> of the code that have no reason to be subjected to it.
In several years of reading I've observed two general kinds of threads
on comp.lang.functional:
1. Threads making extravagant claims for the superiority of functional
programming for just about any kind of task.
2. Threads lamenting the lack of interest in functional languages in
the mainstream.
The only way the programming world at large is going to take any
notice of fpls is for fpl advocates to prove their claims by writing
significant real-world applications in fpls and demonstrating how much
easier it is than doing it in more traditional languages. The burden
of proof is on the advocates. People will quibble about the
definition of real-world applications but I think you know what I
mean.
Personally, I'm growing suspicious of languages that proceed from
theory into practice instead of the other way around.
--
miles egan
mi...@rddac.com
reverse the domain name to find me
OpenPGP/GPG Key 0x01F53D51 @ wwwkeys.us.pgp.net
gr...@cs.uwa.edu.au
: I find Haskell extremely interesting also. But I'm not using it
: because I don't know how to do certain things that are elementary in
: other languages:
: 1) Polymorphically extend a product type (record) with additional fields.
: without having to wrap it in a bogus constructor and explicitly
: lift all functions defined on the original type to the new type.
I've written a fair bit of Haskell code without ever wanting to do
these things, so I suspect that a large part of the reason why these
facilities are not there is that it allow a different (better?) ways
of doing things that prevent you needing these features. I wonder if
there is some related feature, or element of style, that hasn't yet
found its way into your arsenal. Perhaps you could give us example
of a situation in which you feel a need for these capabilities?
-Greg
Ahn Ki-yung
> On 9 Apr 2003, Tim Sweeney wrote:
>
>>To be realistic, there isn't lots of example code available in Haskell
>>for mainstream tasks like file I/O, networking, and user interface
>>programming because Haskell isn't a good language for doing these
>>kinds of things.
>
> Hmm. I would agree to some extent. But I think the reason for most people
> not writing these tutorials is because IO usually isn't a very large part
> of any program, and it really isn't much more elegant in Haskell (you have
> to do it with the IO monad, which basically is just an imperative language
> right? So one might reason like "the point of Haskell isn't the imperative
> aspects, so I'll leave those alone"). I'm in the process of writing
> tutorials in Haskell right now, so I'll try to keep this in mind.
IO is important when you consider performance, since IO
can be a bottleneck. e.g. is extremely important for a
file system or DBMS when and how to sync the data from
cache to a file or any kind of physical structure.
gr...@cs.uwa.edu.au
: The only way the programming world at large is going to take any
: notice of fpls is for fpl advocates to prove their claims by writing
: significant real-world applications in fpls and demonstrating how much
: easier it is than doing it in more traditional languages.
Well, feel free to commission such an application. :)
: The burden of proof is on the advocates.
This is true, although at least fpls are starting from a clean sheet,
while so many competing non-fpls have already been proven failures
at building significant real-world applications.
: Personally, I'm growing suspicious of languages that proceed from
: theory into practice instead of the other way around.
I think it's wise to be suspicious of any language. Perhaps even more
so if the language has proceeded from practice to theory, since those
have had such a dismal record to date.
-Greg
Ivan Boldyrev
haskell.org and google.com are your best friends :)
--
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
Jerzy Karczmarczuk
> Miles Egan,[ who ] wrote:
> : Personally, I'm growing suspicious of languages that proceed from
> : theory into practice instead of the other way around.
>
> I think it's wise to be suspicious of any language. Perhaps even more
> so if the language has proceeded from practice to theory, since those
> have had such a dismal record to date.
Perhaps it would be useful to underline some facts.
1. Haskell *did not* proceed "from a theory". As Hudak points out in his
Comp. Surv. article, functional languages *badly needed* some unification.
We had already Miranda, Hope, the full plethora of Lisps, etc.
2. Its evolution was incremental, not aprioric. TREX, or other OO features,
constructor classes, etc. - some things migrated from Gofer on an experi-
mental basis, other, as the monadic IO, *crystallized* through a long
process during which other models have been discussed.
3. All that, and some polymorphic goodies rouse into existence, because it
was realized that THERE IS A GOOD THEORY behind. The evolution, not the
initial concept followed the theory (of types, etc.).
There is quite a mileage ahead. Some concepts in category theory might/
should be implemented. People still - apparently --- ((IMVVVHO)) don't
know what to do with Richard Kieburtz's comonads, really fabulous
headaches...
So, what's the idea of accusing Haskell to be a language which came into from
the cold theory? Even Lisp, so deeply anchored within the lambda model of
calculus was not really a "theoretical product". Good languages, on the other
hand, *should* have some theory behind. Not everything survives. Snobol was
"based" (in the vague sense suggested above) on Markov algorithms, or "program-
med grammars" if you prefer. Its pattern sub-language was really very elegant,
but it lost against other programming tools and languages, much more brutal.
(Actually, it has been partially sacrified by its own father, when Griswold
manufactured Icon...)
Miles Egan issued the following statement about the "superiority" of Haskell,
commented by Greg:
> : The burden of proof is on the advocates.
>
> This is true, although at least fpls are starting from a clean sheet,
> while so many competing non-fpls have already been proven failures
> at building significant real-world applications.
I disagree conceptually (although I won't use my Kalashnikov against, anyway
I don't have one). The "burden of proof", or anything related, is
1. A wrong term. This is not a trial, there is nothing to prove. This is an
exchange of opinions. In USA (in Europe this is less popular) *ANY*
product manufacturer claims that his product is "the best in the world",
and so what?
Well, it enhances a particular atmosphere within a society, a behaviour
which promotes a lot of talking, and ranking everything. People are lost
in the richness of the world, and pay a lot in order to have the illusion
that they *know* what is "best". Haskellians should avoid falling in this
trap.
2. Haskell has no vendors until now. People who are busy developing it should
never became commercials (even if they are employed by a huge profit
company whose name I have forgotten). They might be preachers, and they
might radiate their wisdom around, this may *convince* some young people in
quest for a good developing tool in some contexts. I think that most of us
would agree with the supposition that Haskell is really good for very
intelligent, and receptive people (*).
When somebody says "prove me that this language is better than others by solving
my typical problems", I send him mentally to Limbo. The only question I would
like to pose would be "how many languages did you try?". I suspect that the
average answer is around 1.5.
Jerzy Karczmarczuk
(*) ... so, between us, that's why I like this game. I hope that by using
Haskell I *become* more intelligent...
Adrian Hey
> Personally, I'm growing suspicious of languages that proceed from
> theory into practice instead of the other way around.
Why is that? Are you refering to Haskell's theoretical purity
and the (alleged) "difficulty" of monadic IO. Are you implying
that the practicality of Haskell has been compromised in some futile
quest for theoretical ideals? I've been using Haskell for a few years
now and have not found that so, quite the contary in fact. Those
languages which have compromised on theory (or never were based on
any theory) are harder to understand and use IMO.
Personally, I'm quite suspicious of languages that proceed from
practice into theory, but I'm even more suspicious of languages that
do not proceed into theory at all.
Regards
--
Adrian Hey
Christian Szegedy
> 2) Extend a sum type (algebraic datatype) with new constructors
> without having to wrap it in a bogus constructor and explicitly
> lift all functions defined on the original type to the new type.
> Once again, this exists in pieces - O'Haskell has it and it seems
> that it could be simulated in ghc with "deriving".
Altough your first request (about products) is quite
legitimate, I think, this is a bit problematic, since it compromises
type checking a bit. It is not impossible, as the typing of OCaml
shows (OCaml allows for arbitrarily extendable open variants), but
also in OCaml it makes programs using this feature harder to debug,
less extensively checked. The type system is gets more complicated
and the type checking will not reveal bugs which are revealed in
the conservative setting. So, I am not convinced that it's a good
idea at all.
Of course a type system somewhere in the middle:
not completely open but extendible variants seems to be a good
choice.
However I would be interested in how you simulate this effect
by the "deriving" feature of Haskell.
Best Regards, Christian
Ulf Wiger
> : The burden of proof is on the advocates.
>
> This is true, although at least fpls are starting from a
> clean sheet, while so many competing non-fpls have already
> been proven failures at building significant real-world
> applications.
Irrelevant.
"Quod licet Jovi non licet Bovi".
What does it mean? "That which is allowed Jove is not
allowed cows". As a kid of 6 (when I first learned this
phrase -- don't ask why), I didn't know what it meant,
but having fought a few battles where I represented the
minority opinion, I've come to understand it.
"An unpleasant but eternal truth", according to Jung.
Or to quote the great philosopher Tess from the movie
"Working Girl": "You can bend the rules plenty when
you are at the top, but not while you're trying to
get there." (I think this is the Staten Island version
of the above Roman phrase)
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
Joan Estes
> I've written a fair bit of Haskell code without ever wanting to do
> these things, so I suspect that a large part of the reason why these
> facilities are not there is that it allow a different (better?) ways
> of doing things that prevent you needing these features. I wonder if
> there is some related feature, or element of style, that hasn't yet
> found its way into your arsenal. Perhaps you could give us example
> of a situation in which you feel a need for these capabilities?
>
Let's say I am writing a graphics framework. I would like to give the
core code to different groups of developers to extend and customize
for different applications, but for good maintainability reasons I do
_not_ want them to touch the core code. As a newbie, to me the
obvious way of representing an event would be as follows (taken from
SOE):
data Event
= Key { char :: Char , isDown :: Bool }
| Button { pt :: Point, isLeft, isDown :: Bool }
| MouseMove { pt :: Point }
| Close
I have a number of functions that do pattern matching on Events.
However, I did not anticipate that group A would need the additional
functionality:
| Resize
while group B wants to support an additional field in the existing
"Button" constructor:
Button { pt :: Point, isLeft, isDown, doubleClicked :: Bool }
I do not want to add this functionality to the core framework, yet I
would like
1) my core functions to work on the extended data
without the customizers having to
write code to wrap or dispatch all 500 of them.
2) the extensions to be possible without touching the core framework.
Is there an idiom in Haskell that would allow this kind of thing? I
know how to do (and have done) this kind of thing in an OO language.
If I can figure out a way to do it in Haskell without fighting the
language, I'll use Haskell in a second.
Regards
J. Estes
Miles Egan
> gregm disccussion with -
> 1. Haskell *did not* proceed "from a theory". As Hudak points out in his
> Comp. Surv. article, functional languages *badly needed* some unification.
> We had already Miranda, Hope, the full plethora of Lisps, etc.
Let me be more precise. Advocates of functional languages, especially
lazy languages, want to make the very bold claim that a language that
imposes an abstraction radically divergent from the execution model of
the underlying hardware and also strongly at odds with most
programmers' notions of state preceeds a revolution in programming
productivity. This may, in fact, be the case but it's up to the fpl
folks to demonstrate that it is. Otherwise, they share space with all
the other language designers that tout theoretical advantages with no
evidence to back up their claims. Witness Eiffel, Sather, Icon, Self
etc.
> When somebody says "prove me that this language is better than others by solving
> my typical problems", I send him mentally to Limbo. The only question I would
> like to pose would be "how many languages did you try?". I suspect that the
> average answer is around 1.5.
> (*) ... so, between us, that's why I like this game. I hope that by using
> Haskell I *become* more intelligent...
This is exactly the kind of arrogance and elitism that arouses
suspicion in the working programmer investigating fpls. It's pretty
clear that theoretical purity is more important that practical
usefullness. Developing a high quality word processor in C++ requires
just as much "intelligence" and design discipline as mastering monads
does. When someone responds to a legitimate request for a
demonstration of the advantages of any new and unproven technology as
dismissively as this I send *him* to limbo.
Miles Egan
> gr...@cs.uwa.edu.au writes:
>
>> : The burden of proof is on the advocates.
>>
>> This is true, although at least fpls are starting from a
>> clean sheet, while so many competing non-fpls have already
>> been proven failures at building significant real-world
>> applications.
>
> Irrelevant.
>
> "Quod licet Jovi non licet Bovi".
>
> What does it mean? "That which is allowed Jove is not
> allowed cows". As a kid of 6 (when I first learned this
> phrase -- don't ask why), I didn't know what it meant,
> but having fought a few battles where I represented the
> minority opinion, I've come to understand it.
> "An unpleasant but eternal truth", according to Jung.
Precisely. And how again have mainstream languages been "proven
failures" at building significant real-world apps? Quite the
contrary, they're the only languages in which it's been conclusively
proven that it's even *possible* to build them. We're acutely aware
of their disadvantages because we've pushed them to such extremes.
Who knows what lies in wait for the first team that tries to build the
next Mozilla in an fpl? What kind of a showstopper could OCaml's lack
of support for mutually recursive types become? How intractable could
non-deterministic memory usage in Hasell be? The devil is in the
details on projects of that size.
The Erlang people have demonstrated that a functional language
designed with a particular application domain in mind does have real
advantages over the alternatives. My hat is off to them. Even there
it's not entirely clear how much advantage they derive from a
domain-specific design and how much from the functional style.
Adrian Hey
>
> 1) my core functions to work on the extended data
> without the customizers having to
> write code to wrap or dispatch all 500 of them.
> 2) the extensions to be possible without touching the core framework.
>
> Is there an idiom in Haskell that would allow this kind of thing?
At present I don't think so (other than the rather awkward things you've
suggested). But I believe there's some WIP for an experimental extension
to ghc for a better system of extensible records which should address the
extra fields problem directly.
I think the extra constructor in an algebraic data type is still a tricky
one. I generally try to avoid exporting the constructors of a data type
unless I'm reasonably certain their definition set in concrete. So all
the functions that do pattern matching on that type are necessarily
confined to a single module (I.E. All other modules see the type as
abstract data type). I think a better records or first class modules
system would make something resembling an OO style more feasible (an
object type is essentially a record type unless I'm missing something,
though in an FPL this probably wouldn't be used in quite the same way
as in a typical imperative OOPL as there is no mutable state that needs
encapsulating in a traditional "object").
But I'm not to sure of the details of exactly what's proposed. As usual,
the proof of the pudding will be in the eating, so we'll have to wait.
I think the ghc folk are taking their time over this to try to make the
system as flexible as possible without leaving a broken type system.
Regards
--
Adrian Hey
Aaron Denney
> The only way the programming world at large is going to take any
> notice of fpls is for fpl advocates to prove their claims by writing
> significant real-world applications in fpls and demonstrating how much
> easier it is than doing it in more traditional languages. The burden
> of proof is on the advocates. People will quibble about the
> definition of real-world applications but I think you know what I
> mean.
Is a compiler a real-world application?
http://www.haskell.org/ghc/
Is a web-server a real-world application?
http://www.haskell.org/~simonmar/bib.html
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
Is a chat-client a real-world application?
http://repetae.net/~john/computer/ginsu/
Is a distributed revision-control system a real-world application?
http://abridgegame.org/darcs/
Then there is also the list of projects at the caml pages:
http://caml.inria.fr/users_programs-eng.html
Including the very-handy unison file synchronization tool,
and the HEVEA LaTeX to HTML translator, which I have seen used on
many webpages.
The people that wrote these certainly believed that using Haskell or
OCaml was easier than the other tools available.
--
Aaron Denney
-><-
Markus Mottl
> Who knows what lies in wait for the first team that tries to build the
> next Mozilla in an fpl? What kind of a showstopper could OCaml's lack
> of support for mutually recursive types become?
OCaml certainly has mutually recursive types:
type t = T of u
and u = U of t
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus mar...@oefai.at
Lauri Alanko
> What kind of a showstopper could OCaml's lack of support for mutually
> recursive types become?
Ocaml does support mutually recursive types:
type node = { mutable left : tree;
mutable value : int;
mutable right : tree }
and tree = Node of node | Empty
I take it you mean something else?
Lauri Alanko
l...@iki.fi
Miles Egan
I was referring to the problem with mutually dependent modules. It
used to be a problem to compile such modules.
Perhaps it's not longer an issue?
Daniel Ortmann
> Miles Egan <mi...@rddac.com> wrote:
> > Who knows what lies in wait for the first team that tries to build
> > the next Mozilla in an fpl?
I don't know about clients, but I seem to recall a web SERVER written in
haskell. If memory serves, it was run for one week, used 3.5MB ram and
performed about 75% as well as apache.
> > What kind of a showstopper could
> > OCaml's lack of support for mutually recursive types become?
> OCaml certainly has mutually recursive types:
>
> type t = T of u
> and u = U of t
--
Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
work: Daniel....@lsil.com / 507.535.3861 / 6.3861 int / 8012.3861 gdds
home: ort...@isl.net / 507.288.7732, 2414 30Av NW #D, Rochester MN 55901
0x4E71
wrote:
>I don't know about clients, but I seem to recall a web SERVER written in
>haskell. If memory serves, it was run for one week, used 3.5MB ram and
>performed about 75% as well as apache.
I think I remember a server with such specs too, but I thought it was
written Erlang...
-Luigi
Claus Reinke
> = Key { char :: Char , isDown :: Bool }
> | Button { pt :: Point, isLeft, isDown :: Bool }
> | MouseMove { pt :: Point }
> | Close
>..[how to convert this into an extensible application framework?]..
For examples of extensible frameworks, see
Monad Transformers and Modular Interpreters
Sheng Liang, Paul Hudak, and Mark P. Jones, In Conference Record
of POPL'95: 22nd ACM SIGPLAN-SIGACT Symposium on Principles
of Programming Languages, San Francisco, CA, January 1995.
http://www.cse.ogi.edu/~mpj/pubs/modinterp.html
Two-Level Types and Parameterized Modules. With Emir Pasalic.
Expanded version of Generic Unification via Two-Level Types and
Parameterized Modules, with new examples. Submitted to the JFP
Special Issue on Programming Pearls.
http://www.cse.ogi.edu/~sheard/papers/JfpPearl.ps
Hth,
Claus
Taavi Talvik
: On 10 Apr 2003 16:00:14 -0500, Daniel Ortmann <dort...@lsil.com>
: wrote:
Yes, there is web server written in Erlang. You can find it at yaws.hyber.org.
However, performance compared to apache was more like 7500% with apache:)
Look at comparision at http://www.sics.se/~joe/apachevsyaws.html
best regards,
taavi
--
Disclaimer : I heard it on the internet
0x4E71
wrote:
>However, performance compared to apache was more like 7500% with apache:)
Yaws! =)
>Look at comparision at http://www.sics.se/~joe/apachevsyaws.html
Thank you.
-Luigi
ol...@pobox.com
Type classes, for example.
data Point = Point {x:: Int, y:: Int} deriving (Eq,Show)
data CoreEvent
= Key { char :: Char , isDown :: Bool }
| Button { pt :: Point, isLeft, isDown :: Bool }
| MouseMove { pt :: Point }
| Close
class EVENT a where
get_core_event:: a -> CoreEvent
instance EVENT CoreEvent where
get_core_event = id
-- My core framework
core_dispatch:: (EVENT a) => a -> (a,String)
core_dispatch ev = (ev,dispatch ev) where
dispatch ev = case get_core_event ev of
Close -> "Close it!"
MouseMove pt -> "Moved to " ++ (show pt)
Button pt left down -> "Click " ++ (show (pt,left,down))
Key char down -> "Key " ++ (show (char,down))
-- Developer A
data DevAEvent = Resize | ACore CoreEvent
instance EVENT DevAEvent where
get_core_event (ACore x) = x
deva_issue:: CoreEvent -> DevAEvent
deva_issue ev@(Button pt left down)
-- check if the resize button is clicked
= if pt == Point{x=0, y=1} && left && down then Resize
else ACore ev
deva_issue x = ACore x
deva_dispatch (Resize) = "Resize!"
deva_dispatch (ACore core) = snd $ core_dispatch core
testa = map (deva_dispatch . deva_issue)
[Key 'a' True, Button (Point 0 0) True True,
MouseMove (Point 0 1),
Button (Point 0 1) True True, Close]
-- Developer B
-- In this example, we prefixed the names of the fields in NewButtonEvent
-- by the letter 'b'. In real life, the NewButtonEvent would be in a different
-- module, so we can rely on the module system to disambiguate between
-- the fields of CoreEvent and the fields of the NewButtonEvent.
-- No prefixing would be needed then
data DevBEvent
= NewButtonEvent {bpt :: Point, bisLeft, bisDown, bisDoubleClick :: Bool}
| Core CoreEvent
instance EVENT DevBEvent where
get_core_event (Core ev) = ev
get_core_event ev@(NewButtonEvent pt isleft isdown _)
= Button pt isleft isdown
-- Perhaps you can get DrIFT to generate the EVENT instances such as
-- above automatically.
-- So you only need to say "data MyEvent = ... deriving EVENT"
ol...@pobox.com
> deva_dispatch (Resize) = "Resize!"
> deva_dispatch (ACore core) = snd $ core_dispatch core
Although it works, it is more illustrative to write it as
deva_dispatch (Resize) = "Resize!"
deva_dispatch ev = snd $ core_dispatch ev
We can apply core_dispatch to any event structure, provided it is
"coercible" to a CoreEvent (in other words, it is in the EVENT class).
An extension developer needs to program the necessary coercion
transformation only once, in the instance declaration "instance EVENT
mydata where ...". After
that, he can apply core_dispatch or other similar core function
to mydata directly, without any fuss.
The core event module does not need to be modified at all. In fact,
the core
module doesn't have to be available in the source form.
Alan Baljeu
> >
> > What does it mean? "That which is allowed Jove is not
> > allowed cows". As a kid of 6 (when I first learned this
> > phrase -- don't ask why), I didn't know what it meant,
> > but having fought a few battles where I represented the
> > minority opinion, I've come to understand it.
> > "An unpleasant but eternal truth", according to Jung.
Sorry, I can't figure out the English translation, either.
By Jove, you mean Jupiter, Zeus, right? What's that got
to do with cows, and why is the sentence so ungrammatical
seeming?
Alan
Miles Egan
> Is a compiler a real-world application?
> http://www.haskell.org/ghc/
Compilers do seem to be one area where fpls do have some clear
advantages.
> Is a web-server a real-world application?
> http://www.haskell.org/~simonmar/bib.html
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
I've written my own web server in less than 200 lines of OCaml. It's
not going to displace apache anytime soon.
> Is a chat-client a real-world application?
> http://repetae.net/~john/computer/ginsu/
It's quite plain, isn't it? Certainly not nearly at the level of even
any of the common free chat clients. I can't imagine it would be
difficult to write this in C.
> Is a distributed revision-control system a real-world application?
> http://abridgegame.org/darcs/
Looks interesting, but barely a threat to cvs and not obviously
superior to other one-man-show vc systems written in c or even awk/sh
(aegis/arch). Certainly not even on the radar of the typical perforce
user. Can I easily build a GTK2 gui on top of this like subversion?
Does it support ldap group based access controls?
> Then there is also the list of projects at the caml pages:
> http://caml.inria.fr/users_programs-eng.html
Last revised 1998. Almost all of these are toys. I've been following
ocaml development since then and there hasn't been much to add.
> Including the very-handy unison file synchronization tool,
> and the HEVEA LaTeX to HTML translator, which I have seen used on
> many webpages.
Unison seems cool but it's pretty clear that such tools can be written
without extraordary difficulty in C (rsync). HEVEA is cool but then
again it's basically a compiler.
> The people that wrote these certainly believed that using Haskell or
> OCaml was easier than the other tools available.
Not only are all of these pretty marginal examples but even if I were
to accept them as "real-world" applications they just don't compare to
their competitors. Remember - it's not enough to prove that it's
*possible* to write applications in fpls, it's necessary to prove that
it's *much* easier. Until people can produce applications that are
demonstrably superior to existing real world production apps or are
truly comparable and much easier to develop, public skepticism is
sadly justified.
Aaron Denney
> > Is a web-server a real-world application?
> > http://www.haskell.org/~simonmar/bib.html
> > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
>
> I've written my own web server in less than 200 lines of OCaml. It's
> not going to displace apache anytime soon.
Of course not. One man working on a project, and soon doing something else
vs the work of hundreds. And there is always the network effect -- it's
beneficial to use popular programs, because they have more resources to
draw upon when one needs help configuring or debugging, etc.
> > Is a chat-client a real-world application?
> > http://repetae.net/~john/computer/ginsu/
>
> It's quite plain, isn't it? Certainly not nearly at the level of even
> any of the common free chat clients. I can't imagine it would be
> difficult to write this in C.
Fairly plain, in interface, yes -- it uses ncurses. It has a really
nice way of composing filters to select a subset of traffic though.
(This is made more useful by the structure of the underlying chat
system, gale, which encourages the use of hierarchical categorizations,
something like netnews, but much more fluid. Gale is written in C,
plus the Boehm conservative garbage collector. Only the "standard"
command-line client is written C.) I can assure you that it would
take far longer to write this in C.
> > Is a distributed revision-control system a real-world application?
> > http://abridgegame.org/darcs/
>
> Looks interesting, but barely a threat to cvs and not obviously
> superior to other one-man-show vc systems written in c or even awk/sh
> (aegis/arch).
I've actually used aegis, and it is indeed more polished than darcs.
Darcs looks like it will get a lot correct that CVS gets wrong. But
compare 1 man on the order of 1 year spare time with the amount of time
it's taken CVS to get to its current state.
> Certainly not even on the radar of the typical perforce user.
I use perforce at work. I can imagine switching to darcs once it
matures.
> Can I easily build a GTK2 gui on top of this like subversion?
Depends on what you mean by "easily". Each of the subfunctions is
implemented as a record; it probably wouldn't be that hard to slap
a GUI on top -- haskell bindings for GTK do exist, and glade
support is planned. I'm not familiar with the GUI for subversion.
> Does it support ldap group based access controls?
Nope. Applying signed PGP patches via an e-mail server is planned.
I think combining this with ldap controlled access to an auto-signer
would work well enough.
> > Then there is also the list of projects at the caml pages:
> > http://caml.inria.fr/users_programs-eng.html
>
> Last revised 1998. Almost all of these are toys. I've been following
> ocaml development since then and there hasn't been much to add.
Created 1998. Last revised December, 2002. I'll admit that I was
hoping for more to show up on that list.
> Unison seems cool but it's pretty clear that such tools can be written
> without extraordary difficulty in C (rsync).
Unison does a bit more than rsync (though it does use the rsync algorithm).
> Not only are all of these pretty marginal examples but even if I were
> to accept them as "real-world" applications they just don't compare to
> their competitors.
Some of them are quite young.
> Remember - it's not enough to prove that it's *possible* to write
> applications in fpls, it's necessary to prove that it's *much* easier.
If one wishes to displace existing languages, yes. If one just wants
to code a bit quicker, and easier, than showing that it is a bit easier
is all that's necessary.
I don't need to see Haskell and OCaml displace C++ and Java; I just need
them to get enough acceptance so I can use them at work.
Ken Moore
<mi...@rddac.com> writes
>Let me be more precise. Advocates of functional languages, especially
>lazy languages, want to make the very bold claim that a language that
>imposes an abstraction radically divergent from the execution model of
>the underlying hardware and also strongly at odds with most
>programmers' notions of state preceeds a revolution in programming
>productivity.
"Radically divergent" seems like an over-bold claim to me, since
programs in imperative languages can diverge more disastrously from the
execution model of parallel architectures than those in functional ones.
--
Ken Moore
k...@mooremusic.org.uk
Web site: http://www.mooremusic.org.uk/
I reject emails > 300k automatically: warn me beforehand if you want to send one
Adrian Hey
Being self employed I am fortunate enough not to have such problems. So
perhaps I don't fully appreciate the need for the "proof" Miles demands.
I would say if you like FPL's use them, if you don't then use something
else. Why should anybody care either way?
For my real work even C doesn't really cut it. I tend to use the best
programming language in the world for this, Analog Devices 218x assembler.
(The existance of gazillions of embedded DSP widgets implemented in this
PL is surely proof of it's superiority.)
But Haskell is almost as good. I tend to use it a lot on platforms that
don't support 218x assembler natively.
Regards
--
Adrian Hey
gr...@cs.uwa.edu.au
: Aaron Denney wrote:
:> I don't need to see Haskell and OCaml displace C++ and Java; I just need
:> them to get enough acceptance so I can use them at work.
: else. Why should anybody care either way?
We all depend on and pay for (if indirectly) programs written by other
people. We have an interest in them being written efficiently and well.
-Greg
Dmitry Malenko
> In article <slrnb9bgnt...@hork.ugcs.caltech.edu>, Aaron Denney wrote:
>> Is a compiler a real-world application?
>> http://www.haskell.org/ghc/
>
> Compilers do seem to be one area where fpls do have some clear
> advantages.
>
>> Is a web-server a real-world application?
>> http://www.haskell.org/~simonmar/bib.html
>> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
>
> I've written my own web server in less than 200 lines of OCaml. It's
> not going to displace apache anytime soon.
Can you imagine writing a web server that will displace Apache in any other
language? It's not a matter of language but of years of constant
development behind the success of Apache. And so for most of your examples.
<skipped>
It is nonsense to compare to "real-world" applications with many-year
history. UNIX is there for more than 30 years - was somebody able to write
an analogue to it?
One would instead want to develop same application in different languages
to see how much time it takes?, how many critical errors are encountered?
how difficult it is to maintain and respond to change in specifications?.
My bet is that FPLs will do much better.
For the area of prototyping you can see
http://haskell.org/papers/NSWC/jfp.ps
> Not only are all of these pretty marginal examples but even if I were
> to accept them as "real-world" applications they just don't compare to
> their competitors. Remember - it's not enough to prove that it's
> *possible* to write applications in fpls, it's necessary to prove that
> it's *much* easier. Until people can produce applications that are
> demonstrably superior to existing real world production apps or are
> truly comparable and much easier to develop, public skepticism is
> sadly justified.
Use of FPLs is often hidden from random spectators. Because they are used
there where people just do their work (science, not only computer, look at
INRIA - are they developing OCaml just for fun?) and not make claims like
"we were able to place button on the form in record time to deliver you a
best ever product".
HN
> lazy languages, want to make the very bold claim that a language that
> imposes an abstraction radically divergent from the execution model of
> the underlying hardware and also strongly at odds with most
> programmers' notions of state preceeds a revolution in programming
> productivity. This may, in fact, be the case but it's up to the fpl
> folks to demonstrate that it is. Otherwise, they share space with all
> the other language designers that tout theoretical advantages with no
> evidence to back up their claims. Witness Eiffel, Sather, Icon, Self
> etc.
Theoretical advantages? Actually, these are *factual* advantages.
For example, look at work of Ian Joyner - comparison of
Eiffel, C++ and Java. This is not "theory".
No evidence? Well, there are many companies who are using
Eiffel for very serious and complex applications. Account of one of
these experiences can be found in this message, below.
There is a successful, commercial game written in Eiffel (Strategic Command:
http://www.furysoftware.com/.
Links to experiences with Eiffel can be found here:
http://www.ooad.org/cetus/oo_eiffel.html
==============================================
Who's using Eiffel
My name is Loryn Jenkins. I'm the CTO of Standard Transactions
(http://standardtransactions.com). My company provides individuals,
companies, and affinity groups the ability to make instant
international payments. We currently serve customers in over 120
countries in the world, on every continent other than Antarctica.
Our customers can
* manage their money worldwide using International tax strategies
* live in one country and pay bills in another
* send money home regularly and not break the bank
* carry cash in their pocket without risk, even while on vacation
We are servicing our customers from the British Virgin Islands (where
we host our world-wide headquarters), Bahamas, United States
(http://www.standardtransactionsusa.com), Australia
(http://www.standardtransactions.com.au) and Canada
(http://www.standardtransactionscanada.com). Our technical staff are
located in British Virgin Islands, three states of the United States
of America, Belarus, and Australia.
Our service allows people to purchase digital cash, in a number of
digital currencies:
* Standard Reserve Gold Grams (SR-AUG)
* Standard Reserve United States Dollars (SR-USD)
* Standard Reserve Canadian Dollars (SR-CAD)
* Standard Reserve Australian Dollars (SR-AUD)).
Each digital currency is backed by its respective national currency or
gold.
Once customers own digital cash in the system, they can instantly pay
people and companies no matter where they are located in the world.
Companies can accept payment from individuals without risk of
reversals because, with us, all payments are cash transactions.
Transactions are not reversed by Standard Transactions. So when you've
received cash, it is yours.
We enable customers to withdraw their money through any of over
600,000 MasterCard ATMs world wide. We issue MasterCard approved
Stored Value ATM cards through-out the world. Our cards are delivered
anywhere in the world within seven days of payment being received.
Eiffel is our engineering tool of choice. Code written in ISE Eiffel
powers our card ordering, shipping notification, card balance
updating, and several administration processes. We use ISE Eiffel,
EiffelCOM and EiffelStore together with Microsoft SQL Server.
We are currently re-engineering our entire transactional system using
ISE Eiffel and the Matisse object database. Eiffel is eminently suited
to distributed and group development, as the contracting formalism
allows so much design and implementation information to be
communicated so efficiently. Together with good cluster overview
documentation (and clear, complete and consistent requirement
documents), these facilities allows efficient interaction of multiple
developers in building a system.
We really enjoy EiffelStudio's integrated class diagramming; kick-butt
class, cluster and system-browsing facilities; HTML documentation;
flexible system debugging; and its integrated metrics facilities.
Using each of these facilities, it enable pin-point accuracy in
judging completeness and correctness of systems.
Our new system is being written from the ground up to account for
correctness of financial transactions (we don't use floating point
types for money!; we use a DECIMAL type specifically designed to
perform mathematical calculations without binary rounding),
internationalization of service (UNICODE strings and locale
abstractions are used throughout the system), transactional integrity,
system security, high performance (using a persistent object manager
(aka ODBMS) really helps, because we don't have map back and forwards
between disk-based relational format and object networks in main
memory), and flexibility (Matisse schemas can be updated without
interrupting system operations, reports can be run on a clean and
consistent set of data without locking and while allowing transctions
to continue).
Over and above all these advantages, the thing that really sells
Eiffel to our management is this: Once we have developed a solid class
and cluster structure, modifications to the system are rapid and
accurate. This is a fact that we have demonstrated to our management
four or five times this year, and is the reason we are re-engineering
our core systems in ISE Eiffel. The key feature here is
time-to-modification. You see, in most development environments,
things are pretty quick to develop initially, and then excruciatingly
difficult to change. We have experienced this pain numerous times with
other languages and software development methods. This is a painful
experience for a company such as ours, where we have strong visionary
leadership. Our management expect development to be able to modify,
extend and enhance the system rapidly to enable winning new business
development opportunities. ISE Eiffel and Matisse allow us to do this,
quickly and flexibly, while maintaining the overall soundness and
integrity of the core design.
Joe Armstrong
Miles Egan <mi...@rddac.com> writes:
> In article <slrnb9bgnt...@hork.ugcs.caltech.edu>, Aaron Denney wrote:
> > Is a compiler a real-world application?
> > http://www.haskell.org/ghc/
>
> Compilers do seem to be one area where fpls do have some clear
> advantages.
>
> > Is a web-server a real-world application?
> > http://www.haskell.org/~simonmar/bib.html
> > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
>
> I've written my own web server in less than 200 lines of OCaml. It's
> not going to displace apache anytime soon.
>
... I've just changed the Haskell to X and newbie to oldbie -- then
I can throw in my own two half pence ...
As a long time observer of this argument it seems that the reason
that X isn't mainstream (where X is your favorite language) has to do
with one of three reasons.
(1) X isn't (java, C++, C#, ...)
(2) X isn't good at anything
(3) X is too good
Now before you threaten to drill a hole in my skull and suck out
my brains with a straw (for point 2) let me explain:
1) X isn't Java ....
Main stream means 'me too' - it does not and has never meant 'best
super high tech'.
Main stream means "A Microsoft/IBM/SUN/..." product
When I worked for "The Big Company" (TM) - I learned that there was nothing
*wrong* with my favorite language (X' - a language somewhat similar to
X though IMHO *vastly* superior - due to it's impressive handling of
wotnots) - but that it was not Y where Y is sold by Microsoft/Sun/...
2) X isn't good at anything.
"being good at isn't good enough"
Actually
"being superb isn't good enough"
You have to do something different - something *impossible*
I was talking to a wise man and extolling the virtues of language X''
(not my language X' - or *your* language X) but a precursor to both - a
language that I considered sublime.
"He said - tell me one thing that X' is good at - I mean really
really really really really really .... can't do it in another
language good at ..."
I thought and I thought and I though and I couldn't think of
anything -- despite the fact that I thought that X'' was the bees'
knees.
"Now tell me a language that is good at something," he said.
I thought - this was easier.
- Postscript
It's the *only* way to get dots of ink onto my laser printer.
- HTML
It's the only way to write my web pages etc ....
-------
Being *better* but coming second in the race is no good - it is incredible
difficult to displace the first technology that solves a new problem.
This is one of the big problems with X (and X') - Often we can use X
or X' to solve some other problem (which has already been solved in
java , or C) with a more elegant and much better solution - This is
not enough to get people to change.
To get people to adopt a new technology you have to
1) Invent a new *thing* that people *want*
2) Make sure that language X is the *only* way to make the *thing*
3) have a lot of luck
Are their any areas where FPs might do the above? - Yes I think so.
"Go thou and invent a language for programming FPGAs ... :-)"
- This doesn't have to be sexy, smart, .. it just has to work
*reliably* then use you language to make a few chips for something
(signal processing, communications ,, you name it ...) - sell the
chips ...
My guess is that somebody who occasionally reads this group is doing
this, will they tell us? I think not :-)
3) X is too good.
Programming languages are like lightbulbs.
Their is an importer of light fittings near where I live - they sell
long life light bulbs these last 10 times longer than "shop" bulbs - I
happen to know the guy who works there:
- Why can't I buy long life bulbs in Stockholm?
- Economics - the shops in town buy crap bulbs for 3 kr each from me
and sell them for 6 kr - I'll sell you this for 9 kr. and it will last
ten times as long - work it out.
<< I have been explicitly told by a high up manager in "Another Big
Company" - and just in case you were wonder it's not "The Big
Company (TM)" - and the language was X'''' (not X or X') that using X''''
"wasn't an option" - since we would sell far fewer consulting hours" >>
----------------------------------------------------------------------
The only little ray of hope are all the small companies and
individuals who do choose to bet their $'s on the X's and X'''s -
these are small companies that use what they thing are the *best
technologies* to solve problems.
These companies have a significant commercial advantage over "Big
Companies" - but of course, they cannot market or sell their stuff on
a global scale just because they are small.
Hopefully they get bought up by a big company that will actually use
the technology and then market it on a large scale.
This has happened.
/Joe
Ulf Wiger
My personal translation was "What is OK for Jupiter is
not necessarily OK for the Ox", but then I decided to
just copy and paste a translation from a text found via
google (since I don't know Latin). Don't ask me what
relationship Romans saw between Jupiter and oxen.
I'm sure it made sense at the time.
I a project using a niche technology fails, the failure
may threaten the existence of that niche technology, even
if it did not contribute to the failure. Guilt by association.
You will not get the chance to explain what the real causes
of failure were. If you're an upstart, the same rules
don't apply as for mainstream technologies.
Torben Ægidius Mogensen
> Being *better* but coming second in the race is no good - it is incredible
> difficult to displace the first technology that solves a new problem.
>
> This is one of the big problems with X (and X') - Often we can use X
> or X' to solve some other problem (which has already been solved in
> java , or C) with a more elegant and much better solution - This is
> not enough to get people to change.
>
> To get people to adopt a new technology you have to
>
> 1) Invent a new *thing* that people *want*
> 2) Make sure that language X is the *only* way to make the *thing*
> 3) have a lot of luck
Point 2 is in some sense impossible to achieve, since all
Turing-complete languages are equivalent, and you can't make a
language that is stronger than that. So, (as in your examples with
PostScript and HTML) you have to tie the language to a product and use
that language to control the product. Which means that you
effectively say that the only new languages that people will adopt are
domain-specific control languages.
> Are their any areas where FPs might do the above? - Yes I think so.
>
> "Go thou and invent a language for programming FPGAs ... :-)"
Has been done. VHDL comes to mind?
But these examples show a potential niche for new languages: Use them
as a front-end to established control-langauges. Examples:
1) Nobody (well, nearly nobody) programs directly in PostScript.
Most use either a higher-level markup languages (LaTeX etc.) or
non-language tools (Word etc.). These languages and tools do not
offer capabilities that PostScript doen't (often they even
restrict these). But they allow results in an easier or more
portable manner (i.e., you can print your document on a
non-PostScript printer).
2) Several tools that produce HTML from more convenient/portable
formats (e.g. LaTeX or Word) exist.
3) You can make a declarative frontend to VHDL, allowing you to
program FPGA's or design chips in an easier and less error-prone
way. Sheeran's and Klassen's Lava is a step in this direction.
Torben
Joe Armstrong
> If a project using a niche technology fails, the failure
> may threaten the existence of that niche technology, even
> if it did not contribute to the failure. Guilt by association.
> You will not get the chance to explain what the real causes
> of failure were. If you're an upstart, the same rules
> don't apply as for mainstream technologies.
>
If it's a mainstream project and it fails then they assume it failed
because not enough "resources" were allocated to the project - then
you get promoted ...
/Joe
Andreas Eder
> My personal translation was "What is OK for Jupiter is
> not necessarily OK for the Ox", but then I decided to
> just copy and paste a translation from a text found via
> google (since I don't know Latin). Don't ask me what
> relationship Romans saw between Jupiter and oxen.
> I'm sure it made sense at the time.
The oxen were victims that were immolated in worship of Jupiter. That
is the connection between them.
'Andreas
--
Wherever I lay my .emacs, thereć„€ my $HOME.
Nick Name
Ulf Wiger <ulf....@CUT-ericsson.com> wrote:
> Don't ask me what
> relationship Romans saw between Jupiter and oxen.
"Jupiter" was the god of gods in the ancient Rome :)
Maybe that meant "what the boss thinks is not necessarily clear for the
workers".
Vincenzo
Jerzy Karczmarczuk
> Jerzy Karczmarczuk wrote:
...
>>When somebody says "prove me that this language is better than others by solving
>>my typical problems", I send him mentally to Limbo. The only question I would
>>like to pose would be "how many languages did you try?". I suspect that the
>>average answer is around 1.5.
>>(*) ... so, between us, that's why I like this game. I hope that by using
>> Haskell I *become* more intelligent...
>
>
> This is exactly the kind of arrogance and elitism that arouses
> suspicion in the working programmer investigating fpls.
Aha.
So, if somebody wants to be more intelligent, it means that he is arrogant.
Or elitist. Or both. How nice, I will have to revise my English vocabulary.
Or perhaps this is just arrogance, and elitism is when somebody refuses to
play private games of others "tell me how to solve MY problems, or I declare
that your language is worthless".
> When someone responds to a legitimate request for a
> demonstration of the advantages of any new and unproven technology as
> dismissively as this I send *him* to limbo.
So why bother to answer my posting? Just to sneer at me, to show how clever
you are? Please, be coherent. Do whatever you wish, but you are not our judge
and this is not a trial of functional languages. But recheck *your* vocabulary
please, as well, verify what does it mean a "new and unproven technology" in
the incriminated context. The lambda calculus is (rather probably) older than
you. Kleisli triples are quite venerable as well.
I believe that you tried already twice to throw some dirt on the lazy approach
to programming, saying something about non-naturalness, "abstra-theoriticity"
of that methodology, etc. You are free to reason as you wish. But perhaps you
should acknowledge - just in order to open a bit your spirit, that computation
models are quite rich, and a bit different from the "hard world".
* Lazy techniques permit to represent *statically* some processes and facilitate
to reason about them. Co-recursion is a useful tool. Of course, this is not
for everybody, but the "naturalness" of this approach is simply a function of
teaching.
* In several concrete cases, lazy segment provides a way of solving in an easy
way some cross-defined constraints or equations. Again, what *may be* natural
for us, cows, may be an abomination for you, Jupiter, but this is *your*
problem.
Be careful, anyway. There are still plenty of cows around, and Jupiters became
very rare...
J. Karczmarczuk
Ken Rose
I'd guess that there's a bit of wordplay going on. [JB]ovi.
- ken
Joe English
> Until people can produce applications that are
>demonstrably superior to existing real world production apps or are
>truly comparable and much easier to develop, public skepticism is
>sadly justified.
Let me describe the most recent time I used Haskell
in a real-world setting:
In our software system (written mostly in C and Fortran),
there was a naively-coded routine which was initially
"fast enough", but as people started using it on larger problems
it got slower and slower. Thanks to ever-faster hardware,
this routine was able to keep up with growing problem sizes
for many years, but eventually the O(N^2) complexity
combined with larger inputs outpaced advances in hardware
and it became "too slow", then "painfully slow", and finally
"unusably slow" in a matter of months.
So I tracked down the offending routine -- about a screenful
of C code -- and translated it into four lines of Haskell so
I could better understand what it was doing. (I was actually
the one who wrote the routine in the first place, but had
forgotten how it worked by this time :-)
Then I transformed the 4-line Haskell program step-by-step
into an equivalent algorithm that was more efficient. Finally,
I translated this back into C (about 1 1/2 screensful this time)
and replaced the original routine.
With half a day's work, the code went from "unusably slow"
to "more than fast enough".
Now there's not a single line of Haskell code in the final
product, so you may remain justifiably skeptical about
the utility of FPLs. As for me, I'm sold.
--Joe English
Garry Hodgson
> In our software system (written mostly in C and Fortran),
> there was a naively-coded routine which was initially
> "fast enough", but as people started using it on larger problems
> it got slower and slower.
...
> So I tracked down the offending routine -- about a screenful
> of C code -- and translated it into four lines of Haskell
...
> Then I transformed the 4-line Haskell program step-by-step
> into an equivalent algorithm that was more efficient. Finally,
> I translated this back into C (about 1 1/2 screensful this time)
> and replaced the original routine.
that's really interesting to me, as i recently had a similar experience.
in my case, it was new code, for a relatively simple task, but i was getting
myself all confused and bogged down in the imperative plumbing. so i started
from scratch, and rewrote it in FP style. almost trivial. worked perfectly on
small tests, but since it was in python it wasn't tail recursive, and would die on
large cases. but since it was now well understood, translating it back to
imperative was easy, and it's now working happily.
i'm a relative newcomer to FP, and don't often get a chance to use it
at work. but i like the effect it has on how i think about problems, and i
find it increasingly irritating to use the languages that my real projects
require (java. ugh.). some day...
----
Garry Hodgson, Senior Hacker, AT&T Labs
Have you any idea why they're lying to you?
To your faces!
- Paul Kantner
Lauri Alanko
> So I tracked down the offending routine -- about a screenful
> of C code -- and translated it into four lines of Haskell so
> I could better understand what it was doing. (I was actually
> the one who wrote the routine in the first place, but had
> forgotten how it worked by this time :-)
>
> Then I transformed the 4-line Haskell program step-by-step
> into an equivalent algorithm that was more efficient. Finally,
> I translated this back into C (about 1 1/2 screensful this time)
> and replaced the original routine.
Is it possible for you to show this code? A concrete example would
convince people better than a general description, and even those of us
who don't need convincing would probably find it interesting.
Lauri Alanko
l...@iki.fi
Claus Reinke
>
> "Go thou and invent a language for programming FPGAs ... :-)"
>
> - This doesn't have to be sexy, smart, .. it just has to work
> *reliably* then use you language to make a few chips for something
> (signal processing, communications ,, you name it ...) - sell the
> chips ...
>
> My guess is that somebody who occasionally reads this group is doing
> this, will they tell us? I think not :-)
[here is your friendly functional link robot, who reads this group less and
less often, and is always surprised to find one thread there for sure..]
as with most interesting uses of fpls, one has to know where to look?-)
don't look here (secret, shhhh:-):
http://haskell.cs.yale.edu/communities/05-2002/html/report.html#sect6.2.1
http://haskell.cs.yale.edu/communities/11-2002/html/report.html#sect6.2.3
some of us have given up on trying to convince mainstreamed people -
no matter how many examples you show them, they won't be convinced
unless they find themselves using our secret tools; meanwhile, we can
keep busy using them..
Cheers,
Claus
Claus Reinke
>
> don't look here (secret, shhhh:-):
> http://haskell.cs.yale.edu/communities/05-2002/html/report.html#sect6.2.1
> http://haskell.cs.yale.edu/communities/11-2002/html/report.html#sect6.2.3
how inconsiderate of me.. lest people who want to stick to their opinions
accidentally stumble across uses of fp in the real world (which can't be,
as we all know; never mind those persistent rumours about alleged
telecoms languages), they should also carefully avoid visiting these sites:
http://www.agere.com/enterprise_metro_access/network_processors.html
especially
http://www.agere.com/metro_regional_transport/docs/PB02014.pdf
http://www.bluespec.org/
http://www.sandburst.com/
and especially
http://csg.lcs.mit.edu/IAPBlue/workshop/Augustsson-designer.pdf
any rumours that working hardware was demonstrated in relation with
supposedly academic workshops will meet with vehement non-denial!
sigh, it is really getting difficult keeping all those sites secret, and this
is just in a small number of related application areas...
let us just hope that our secrets won't leak out to the ..mainstream!
Cheers,
Claus
Adrian Hey
> jeng...@flightlab.com (Joe English) wrote:
> [an intersting anecdote]
[another intersting anecdote]
These stories remind me of the day I invented FP, or so I thought at the
time:-).
About 15 years ago I was trying to understand some PASCAL code and prove
that it had certain properties that wouldn't cause the program to crash.
But despite complete adherance to the then prevailing doctrine of
"structured programming" it still seemed like an incomprehensible mess
of nested loops and assignment statements. I found that by keeping track
of all the variables any particular entry point was dependent on and all
those it modified, I could transform the code into recursive function
definitions and then apply simple inductive reasoning.
But there were other striking things about this, like..
* It would be far easier to parallelise code in this form.
* The same technique worked just as well if applied to
"spaghetti" code. This confirmed my suspicion that
in reality structured programming contributed squat
to program reliability. For imperative languages
spaghetti is best. (At least that way you get tail
call optimisation for free:-)
* The program in functional form was far shorter
and simpler that the original PASCAL. So I thought
why not write the code this way in the first place
and decided I was going to write a compiler for this
new language (a project I never finished BTW).
A little while later I was browsing the computer shelves at my local
book shop and came across a book called "The Implementation of Functional
Programming Languages" by Simon Peyton-Jones et Al. The title seemed like
it might be relevant to my pet project so I opened it up. It was relevant
of course, and also introduced new (to me) stuff about lambda calculus,
partial application, lazy evaluation, parametric polymorphism..
..and I've been hooked ever since. (Though I was a bit disappointed to
discover that my big new idea wasn't so big or new after all.)
To me it seems so obvious that FP is the right way to go it is a little
depressing that 15 years on so many folk in the world still doubt this,
or more likely just don't know what an FPL is. (They think they do, but
they don't.) Maybe the best FP advocates can hope for is that there are
enough sufficiently independent minded folk in the world to have their
own epiphany and maintain a viable user base.
^^^^^^^^
(Got that word from the IBM ad. BTW, it's quite appropriate IMO :-)
Regards
--
Adrian Hey
ALIEN
Pascal is the first language that i was taught.
I was introduced to haskell and fp last October and...i hated it!
But let's put some things first in order. Pascal is (or was) a programming
language that had been used mostly to teach principles of programming and
to be easy to understand and to program. If you find it messy just because
it can have lengthy code then you've got a point. It's not modular.
But you can't teach someone to program in C without teaching him to program
in an easier language.
Nowdays most universities don't teach procedural structured programming.
They teach Object oriented programming instead. Languages like C++ and java
are more modular,portable and versatile and good to describe entities.
C and C++ compilers also have to follow some ansi standards. In fp there
many languages but how about standards?
The thing is that there is not such thing as "best programming language" or
"best programming paradigm". Each language is better than others in some
taks. Fp laanguages are good for semantics. But when it comes to real world
applications you need C and C++ because solving problems with these
languages is easier and more efficient with the sense of performance.
In haskell there is no "while" or "for". In terms of mathematics as
described by l-calculous or algorithmic theory, recursion works as fine. My
debate with recursion is that it creates a stack of temporary results and
stores all the tempory results of all the steps that have been taken until
the end condition is met. If you consider this from the operating system's
point of view then the os must reserve lots of memory to do a task. In a
while structure only the temporary results of the current step are used and
the requirment for resources is far lesser. For security reasons the
operating system has a stack variable. In unix every user has a value in
that stack variable that he can't exceed. That is, if he writes or uses a
program that will use a lot of recursion then this barier will triger a
kill to his program. Every time you meet "segmentation fault" or "core
dumped" errors it's that thing. This mechanism has been devised to protect
users from a single user that occupies to many shared computer resources.
Another reason that haskell isn't mainstream is that there is already tons
od documentation, literature and applications written by other languages.
Parallelism is a big word. It may seem easier to write parallel code in fp
but today there are many ways to achieve parallelism. Try socket
programming and clustering for example. Try making sockets in fp.
You can't also do fork().
the only argument that i can accept against C and C++ is that they give too
much power to the programer to make everything, even dumb mistakes. the
pointers become messy when it comes to debug a program and lead into
errors. But they nevertheless useful because they save resources.
well does these arguments satisfy your question?
Aaron Denney
> Theoretical advantages? Actually, these are *factual* advantages.
> For example, look at work of Ian Joyner - comparison of
> Eiffel, C++ and Java. This is not "theory".
>
> No evidence? Well, there are many companies who are using
> Eiffel for very serious and complex applications. Account of one of
> these experiences can be found in this message, below.
There is the slight problem that Eiffel has a hole in the typesystem
you can drive a bus through. (Covariance of argument types under
inheritance -- it's fixed in Sather. It's a pity that Sather is looking
more and more moribund.)
Darius
message news:<b7ajfr$77d$1...@news.ox.ac.uk>...
> Pascal is the first language that i was taught.
> I was introduced to haskell and fp last October and...i hated it!
> But let's put some things first in order. Pascal is (or was) a programming
> language that had been used mostly to teach principles of programming and
> to be easy to understand and to program. If you find it messy just because
> it can have lengthy code then you've got a point. It's not modular.
> But you can't teach someone to program in C without teaching him to program
> in an easier language.
> Nowdays most universities don't teach procedural structured programming.
> They teach Object oriented programming instead. Languages like C++ and java
> are more modular,portable and versatile and good to describe entities.
> C and C++ compilers also have to follow some ansi standards. In fp there
> many languages but how about standards?
Standards conformant C and C++ compilers follow ISO standards that
define the language. There are certainly standards for FP languages
or else they wouldn't languages. Haskell is standardised by The
Haskell Report and I believe both Scheme and Common Lisp have ISO
standards. I don't think Java has an ISO standard instead it's
controlled by Sun. I don't get what you are trying to get at; Haskell
isn't a decent language because it doesn't follow the C standard?
> The thing is that there is not such thing as "best programming language" or
> "best programming paradigm". Each language is better than others in some
> taks. Fp laanguages are good for semantics. But when it comes to real world
> applications you need C and C++ because solving problems with these
> languages is easier and more efficient with the sense of performance.
> In haskell there is no "while" or "for". In terms of mathematics as
> described by l-calculous or algorithmic theory, recursion works as fine. My
> debate with recursion is that it creates a stack of temporary results and
> stores all the tempory results of all the steps that have been taken until
> the end condition is met. If you consider this from the operating system's
> point of view then the os must reserve lots of memory to do a task. In a
> while structure only the temporary results of the current step are used and
> the requirment for resources is far lesser. For security reasons the
> operating system has a stack variable. In unix every user has a value in
> that stack variable that he can't exceed. That is, if he writes or uses a
> program that will use a lot of recursion then this barier will triger a
> kill to his program. Every time you meet "segmentation fault" or "core
> dumped" errors it's that thing. This mechanism has been devised to protect
> users from a single user that occupies to many shared computer resources.
Jesus, you are misinformed. Any language that claims to be FP will
certainly be expected to perform tail call optimization. In fact, a
standard compliant Scheme implemetation is REQUIRED to perform tail
call optimization. Anytime you use recursion to implement say a
for-loop you'll likely get almost exactly the same asm output as a C
compiler, it certainly will run in constant stack space, and further
it's quite common for FP languages to use a heap-based stack so you
still wouldn't get a OS stack overflow. Anytime recursion DID build
up a stack of temporaries, equivalent C code would also need to build
a stack of temporaries.
> Another reason that haskell isn't mainstream is that there is already tons
> od documentation, literature and applications written by other languages.
> Parallelism is a big word. It may seem easier to write parallel code in fp
> but today there are many ways to achieve parallelism. Try socket
> programming and clustering for example. Try making sockets in fp.
> You can't also do fork().
fork() isn't ISO C. Assuming non-standard features then you can use
fork in C. fork isn't Standard Haskell, assuming non-standard
features then you can use fork (see Concurrent Haskell). (The same
argument can be made with sockets). However, fork isn't all that
great for _parallel_ processing as opposed to _concurrent_ processing,
Parallel Haskell is aimed at that, I haven't seen similar features in
C. Finally, Haskell has a de facto, and when Haskell II is
standardized, de jure, FFI. So you could always call the non-standard
C fork via the standard FFI.
> the only argument that i can accept against C and C++ is that they give too
> much power to the programer to make everything, even dumb mistakes. the
> pointers become messy when it comes to debug a program and lead into
> errors. But they nevertheless useful because they save resources.
The standard response to that is that developer time costs many times
more than faster hardware. If speed is absolutely critical then, by
all means, use assembly. The only argument that I can accept against
assembly is that it gives too much power to the programmer to make
everything, even dumb mistakes. The pointers become messy when it
comes to debug a program and lead into errors. But it is nevertheless
useful because it saves resources. (also this suggests that fast
erroroneous code is better than slower correct code)
> well does these arguments satisfy your question?
Not mine. It seems obvious that you haven't critically looked into FP
at all.
Lauri Alanko
> Haskell is standardised by The Haskell Report and I believe both
> Scheme and Common Lisp have ISO standards.
Scheme has an old, now out-of-date IEEE standard, but no ISO standard
to my knowledge (DSSSL has one, though). RnRS, the prevailing Scheme
standard series, is not backed by any official body.
> However, fork isn't all that great for _parallel_ processing as
> opposed to _concurrent_ processing, Parallel Haskell is aimed at
> that, I haven't seen similar features in C.
How about CILK <http://supertech.lcs.mit.edu/cilk/>?
Lauri Alanko
l...@iki.fi
Adrian Hey
> I was introduced to haskell and fp last October and...i hated it!
That's a pity. Might I ask how long you spent trying to learn it and were
you working on your own or did you have a mentor to help you if you got
stuck?
> They teach Object oriented programming instead. Languages like C++ and
> java are more modular,portable and versatile and good to describe
> entities. C and C++ compilers also have to follow some ansi standards. In
> fp there many languages but how about standards?
The S in SML stands for "standard", though I forget where that standard
comes from now (some New Jersey outfit). For Haskell there's the
Haskell 98 standard, though I think all implementations go beyond this.
The de-facto standard in practice seems to be ghc at the moment.
> The thing is that there is not such thing as "best programming language"
> or "best programming paradigm".
I would certainly agree that for special purposes you will always be able
to design a language better suited to that niche than any general purpose
language. But to me the concept of a "pure function" is universal and any
language that does not allow users to define and use such a thing seems
impoverished, whatever niche it's aimed at (even if it's niche is something
as specialised as designing knitting patterns for example).
<MHO>
I also don't like it when I see FP refered to as a "paradigm" because
it implies it has no more significant status than other paradigms (like
OO). I would call FP a "formalism", the distinction between these two
in my mind being something like this..
"Paradigm" = The way people like to think it works.
"Formalism" = The way it really works.
The FP formalism supports the functional paradigm natively, but can
also support other paradigms too (as O'Haskell does). The object
paradigm is one many folk seem to like (and who am I to say they're wrong),
but where's the formalism?
Some people (Luca Cardelli being one I'm aware of) have attempted to give
OOPL's a more useful formalism. I don't understand the details, but if
smart people like that decide to spend their time doing this then maybe
there is something useful in OO after all.
</MHO>
> Each language is better than others in
> some taks. Fp laanguages are good for semantics. But when it comes to real
> world applications you need C and C++ because solving problems with these
> languages is easier
You gotta be kidding..
> and more efficient with the sense of performance.
Well that's debatable, and indeed is debated regularly so I won't start
again. I just want to say it ain't necessarily so.
> In haskell there is no "while" or "for". In terms of mathematics as
> described by l-calculous or algorithmic theory, recursion works as fine.
> My debate with recursion is that it creates a stack of temporary results
> and stores all the tempory results of all the steps that have been taken
> until the end condition is met.
Not so. In a language like C (or C++ or Java) you're correct. Any form
of recursive procedure call will use more stack space than a loop.
But it's not true of any decent implementation of an FPL.
Consider the ubiquitous factorial example..
In Haskell I could define
factorial 0 = 1
factorial n = n*(factorial (n-1))
You could do something similar in C. Both the C and Haskell versions
will use O(n) stack space.
Alternatively, in Haskell I could write
factorial = loop 1 where
loop accum 0 = accum
loop accum n = loop (n*accum) (n-1)
This is also recursive, and a C version of this will use O(n) stack space.
But the Haskell version will only use constant stack space. That's because
this version is tail recursive, and the compiler will eliminate the
tail procedure call. Effectively it replaces a CALL with a JUMP, so
what you end up with is a loop.
So you can write loops in an FPL. This is generally regarded as a more
awkward programming style, but it's certainly no more awkward than the
C,C++ or PASCAL alternatives IMHO. The tail recursive style is also
more flexible than traditional structured loops. You can use it to
write functional spaghetti if you like. PASCAL (and to a lesser extent C)
has been designed to make spaghetti programming difficult (for no good
reason that I can see:-).
> Try socket programming and clustering for example. Try making sockets in
> fp. You can't also do fork().
To be honest I haven't tried socket programming (in any language) because
that's not my job, but I think plenty of others have done this in Haskell
(written web servers and similar apps). As for fork() if it's the thing I
think you're talking about (forking a new thread), you certainly can
do this in Haskell. It's called forkIO. (Though it's not part of the
Haskell 98 standard IIRC.)
> But they nevertheless useful because they save resources.
I don't think you should be so certain about that. Multi-threading
in C using typical OS threads uses far more resources than Haskell
or Erlang threads for example. But in some ways your right I think.
C is widely used in resource constrained embedded applications
because it doesn't need a heavyweight run time system with garbage
collected heaps etc..like (current implementations of) Haskell do.
But there are other experimental FPL implemenatations which try to
address this issue too, like "ML Kit".
> well does these arguments satisfy your question?
Afraid not. You'll probably hate me for saying this, but if anything
they tend to confirm my suspicion that a lot of folk don't know enough
about FPL's to know why they don't want to use them. Sorry :-)
That said, I don't want to accuse everybody who choses not to use current
FPL's of being ignorant. It is possible to understand FPL's perfectly well
and still decide not to use them (or at least their current incarnations).
I don't program 218x DSP's in Haskell (yet).
Regards
--
Adrian Hey
Adrian Hey
> Jesus, you are misinformed. Any language that claims to be FP will
> certainly be expected to perform tail call optimization.
Go easy on the guy :-) It's a common enough misunderstaning which ALIEN
probably shares millions of other programmers.
Regards
--
Adrian Hey
Joel Hansell
>ALIEN wrote:
>
>> I was introduced to haskell and fp last October and...i hated it!
<snip>
>> Try socket programming and clustering for example. Try making sockets in
>> fp. You can't also do fork().
>
>To be honest I haven't tried socket programming (in any language) because
>that's not my job, but I think plenty of others have done this in Haskell
>(written web servers and similar apps).
You both might want to check out the Network.Socket library. From the
documentation at http://haskell.cs.yale.edu/ghc/ :
"The Network.Socket module is for when you want full control over
sockets. Essentially the entire C socket API is exposed through
this module; in general the operations follow the behaviour of the C
functions of the same name (consult your favourite Unix networking
book). A higher level interface to networking operations is provided
through the module Network."
Writing a webserver is actually part of the course in Advanced
Functional Programming (held by Koen Claessen) here at
Chalmers/Gothenburg Uni).
--
Joel Hansell | Reverse the name of my university to reply.
Old C programmers never die. They're just cast into void.
Mark Carroll
Adrian Hey <ah...@NoSpicedHam.iee.org> wrote:
>ALIEN wrote:
>
>> I was introduced to haskell and fp last October and...i hated it!
>
>That's a pity. Might I ask how long you spent trying to learn it and were
>you working on your own or did you have a mentor to help you if you got
>stuck?
I certainly found it hard-going my first time. Same with OOP, though.
Now I think both are great.
>> They teach Object oriented programming instead. Languages like C++ and
>> java are more modular,portable and versatile and good to describe
>> entities. C and C++ compilers also have to follow some ansi standards. In
>> fp there many languages but how about standards?
I have certainly had a much easier time with FP standards than ones
for, say, C++ and Java. See, for example, Simon Peyton Jones' "Haskell
98 Language and Libraries: The Revised Report" (ISBN 9993495115), or
ANSI/INCITS X3.226-1994 for Common Lisp if you'd count it as an FPL,
or "The Definition of Standard ML - Revised" (ISBN 0262631814). C++ is
quite well documented, but TBH I've found the Java definition lacking
in both good, precise writing and how much it still leaves open to VM
implementers. I have to produce very portable Java bytecode
professionally, and it's a complete pain in comparison with things
like Modula-3 (which, admittedly, was a quite well-defined imperative
OOPL).
(snip)
>This is also recursive, and a C version of this will use O(n) stack space.
I don't know how good it is now, but the gcc folks do seem to have
been working on and thinking about tail recursion optimisation a lot
lately. Mind you, GHC with all optimisation turned on can do scarily
comparably to gcc, although character IO probably still isn't great.
(snip)
>So you can write loops in an FPL. This is generally regarded as a more
>awkward programming style, but it's certainly no more awkward than the
>C,C++ or PASCAL alternatives IMHO. The tail recursive style is also
I certainly haven't missed while and for loops at all. Being able to
write [m..n], use unfoldr, etc. does a lot for me.
(snip)
>> Try socket programming and clustering for example. Try making sockets in
>> fp. You can't also do fork().
>
>To be honest I haven't tried socket programming (in any language) because
>that's not my job, but I think plenty of others have done this in Haskell
>(written web servers and similar apps). As for fork() if it's the thing I
Absolutely. If you couldn't do such basic system tasks, FPs would be
really useless.
(snip)
>That said, I don't want to accuse everybody who choses not to use current
>FPL's of being ignorant. It is possible to understand FPL's perfectly well
>and still decide not to use them (or at least their current incarnations).
>I don't program 218x DSP's in Haskell (yet).
One theory I have for why some great things aren't more widely adopted
is that it may be only after a substantial investment of effort that
the benefits really become apparent. I think this was one of
Modula-3's problems, actually - if you didn't have te write a large,
complex program then you wouldn't see as much benefit. Similarly for
Haskell - it takes a fair bit of hard thinking to really get into
currying, monads, etc., even if they seem easy, natural and useful
when you finally "get it", especially if you're already used to
imperative techniques that want to tug you in a different direction.
-- Mark
C. P. Weidling
> Garry Hodgson wrote:
> > jeng...@flightlab.com (Joe English) wrote:
> > [an intersting anecdote]
> [another intersting anecdote]
>
...<snip>...
> To me it seems so obvious that FP is the right way to go it is a little
> depressing that 15 years on so many folk in the world still doubt this,
> or more likely just don't know what an FPL is. (They think they do, but
> they don't.) Maybe the best FP advocates can hope for is that there are
> enough sufficiently independent minded folk in the world to have their
> own epiphany and maintain a viable user base.
> ^^^^^^^^
When I was young, the word used was 'revelation'. It still kind of
surprises me how you never see any have a revelation anymore, but rather
they have an epiphany.
> (Got that word from the IBM ad. BTW, it's quite appropriate IMO :-)
...<snip>...
Here's a website that discusses what makes a language popular. Maybe
it can shed some light for those wondering about Haskell. It doesn't
mention functional languages per se, but the author seems to be an old
time LISPer:
http://www.paulgraham.com/popular.html
--
Replace ragwind.localdomain with rahul for my real email address
Adrian Hey
>> To me it seems so obvious that FP is the right way to go it is a little
>> depressing that 15 years on so many folk in the world still doubt this,
>> or more likely just don't know what an FPL is. (They think they do, but
>> they don't.) Maybe the best FP advocates can hope for is that there are
>> enough sufficiently independent minded folk in the world to have their
>> own epiphany and maintain a viable user base.
>> ^^^^^^^^
> When I was young, the word used was 'revelation'. It still kind of
> surprises me how you never see any have a revelation anymore, but rather
> they have an epiphany.
Nah, the moment I realised the essential nature of things was definitely
an epiphany. Picking up Simon Peyton-Jones book was a mere revelation :-)
Regards
--
Adrian Hey
ALIEN
> ALIEN <alient...@yahoo.gr> wrote (a lot of misinformed nonsense) in
> message news:<b7ajfr$77d$1...@news.ox.ac.uk>...
>
>
>> Another reason that haskell isn't mainstream is that there is already
>> tons od documentation, literature and applications written by other
>> languages. Parallelism is a big word. It may seem easier to write
>> parallel code in fp but today there are many ways to achieve parallelism.
>> Try socket programming and clustering for example. Try making sockets in
>> fp. You can't also do fork().
>
i used fork() because it's the most important system call in the operating
system. C has been invented to invent unix.
> fork() isn't ISO C. Assuming non-standard features then you can use
> fork in C. fork isn't Standard Haskell, assuming non-standard
> features then you can use fork (see Concurrent Haskell). (The same
> argument can be made with sockets). However, fork isn't all that
> great for _parallel_ processing as opposed to _concurrent_ processing,
> Parallel Haskell is aimed at that, I haven't seen similar features in
> C. Finally, Haskell has a de facto, and when Haskell II is
> standardized, de jure, FFI. So you could always call the non-standard
> C fork via the standard FFI.
Well that depends on what kind of parallelism are we talking about. If you
think about concurrent parallelism and writing parallel application that
will run on a SINGLE machine that has MANY processors and a SHARED memory
then you must think about what kind of applications you have to write and
run on such a machine. If its mathematical and numerical related problems
then there is already fortran. But i believe that if you try such thing as
parallel haskell then it may be easier to use CSP for formal verification.
On the other hand if you don't have things like shared memories and
concurrent machines but you've got instead many scatered loosely connected
computer resources that are not concurrent then what?
Examples of this is the clustered computing and "grid" like computing where
you distribute chunks of the problem to over many computers in order to
harness their unused computer cycles. Example of this is the set@home.
The issue with this is that you may have computers with different
configurations and with unknown performance. You don't know even whether
the user will use them and when you'll get results.
In beowulf on the other hand you may have clusters that each one doesn't
have the same processor. The inventor of Beowulf had in 1996 only 5 pentium
pro machines and some other slower pentium and 486 machines. But he used
them using telnet protocol (hence the need for sockets) to do the
interprocess message parsing. Think also about the supercomputers. Can you
have a parallel computer such as the earth simulator with a shared memory
and cuncerrent processing to a great extent?
Parallel haskell should work only on machines that have like 24-32
processors inside and a shared memory. Of course you can say that you can
use clustering for them but then again you are gonna need sockets and some
network programming.C is there for you.
Darius
> Darius wrote:
>
> > ALIEN <alient...@yahoo.gr> wrote (a lot of misinformed nonsense) in
> > message news:<b7ajfr$77d$1...@news.ox.ac.uk>...
> >
>
> >
> >> Another reason that haskell isn't mainstream is that there is already
> >> tons od documentation, literature and applications written by other
> >> languages. Parallelism is a big word. It may seem easier to write
> >> parallel code in fp but today there are many ways to achieve parallelism.
> >> Try socket programming and clustering for example. Try making sockets in
> >> fp. You can't also do fork().
> >
>
>
> i used fork() because it's the most important system call in the operating
> system. C has been invented to invent unix.
What are you responding to here?
Did you read what I wrote? I'll go backwards...
"C is there for you." If C is there for you then C is there for
Haskell via the FFI.
"you are going to need sockets and network programming." I already
said Haskell supports this. And no, I'd imagine you typically DON'T
need networking and sockets to be APPARENT when you are writing a
parallel application. Ideally, short of the compiler figuring out
what's best, you'd like to merely annotate what parts in your program
should run in parallel and then, if necessary, in some configuration
file specify over which network to parallise and the compiler/runtime
system will handle the networking. That way you don't have to change
your code to use shared memory multiprocessing or distributed
multiprocessing.
"[the rest of the paragraph]" Why do you think Parallel Haskell
doesn't work for any of these setups? It supports shared memory,
distributed memory, and networked multiprocessing. Also, I notice now
that there is Distributed Haskell which combines Parallel and
Concurrent Haskell which allows a smooth clean integration of explicit
and implicit parallelism and concurrency.
Finally, one thing I don't understand is that you say you hated
Haskell when you were introduced to it, yet not one of the issues
you've listed seems to me like the kind of thing, even if they were
true, that would decide between liking and disliking a language,
especially if by "introduced" you mean you took a class on it. If they
were true, and the issues were important to your application domain,
it may be a reason to dismiss the language for you, but not to hate
it. So, what's the real reason you hate Haskell?
ALIEN
>
> Miles Egan <mi...@rddac.com> writes:
>
>> In article <slrnb9bgnt...@hork.ugcs.caltech.edu>, Aaron Denney
>> wrote:
>> > Is a compiler a real-world application?
>> > http://www.haskell.org/ghc/
>>
>> Compilers do seem to be one area where fpls do have some clear
>> advantages.
>>
>> > Is a web-server a real-world application?
>> > http://www.haskell.org/~simonmar/bib.html
>> > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/
>>
>> I've written my own web server in less than 200 lines of OCaml. It's
>> not going to displace apache anytime soon.
>>
>
> ... I've just changed the Haskell to X and newbie to oldbie -- then
> I can throw in my own two half pence ...
>
> As a long time observer of this argument it seems that the reason
> that X isn't mainstream (where X is your favorite language) has to do
> with one of three reasons.
>
> (1) X isn't (java, C++, C#, ...)
>
> (2) X isn't good at anything
>
> (3) X is too good
>
> Now before you threaten to drill a hole in my skull and suck out
> my brains with a straw (for point 2) let me explain:
>
> 1) X isn't Java ....
>
> Main stream means 'me too' - it does not and has never meant 'best
> super high tech'.
>
> Main stream means "A Microsoft/IBM/SUN/..." product
>
> When I worked for "The Big Company" (TM) - I learned that there was
> nothing
> *wrong* with my favorite language (X' - a language somewhat similar to
> X though IMHO *vastly* superior - due to it's impressive handling of
> wotnots) - but that it was not Y where Y is sold by Microsoft/Sun/...
well i use gcc! it's released under gpl. Does this belong to any company?
there is also gnu version of java.
Is Unix or Linux "mainstream" according your criteria?
No then why IBM,HP,SUN support it and contribute to it?
And if you want a comercial solution think also about Borland.
>
> 2) X isn't good at anything.
>
> "being good at isn't good enough"
>
> Actually
>
> "being superb isn't good enough"
>
> You have to do something different - something *impossible*
>
> I was talking to a wise man and extolling the virtues of language X''
> (not my language X' - or *your* language X) but a precursor to both - a
> language that I considered sublime.
>
> "He said - tell me one thing that X' is good at - I mean really
> really really really really really .... can't do it in another
> language good at ..."
>
> I thought and I thought and I though and I couldn't think of
> anything -- despite the fact that I thought that X'' was the bees'
> knees.
well C is the fastest programming language. It achieves performance because
the compiled code is optimised to work as close as to machine language as
possible. If clock cycle optimisation matters then C is the only solution.
>
> "Now tell me a language that is good at something," he said.
>
> I thought - this was easier.
>
> - Postscript
>
> It's the *only* way to get dots of ink onto my laser printer.
>
> - HTML
>
> It's the only way to write my web pages etc ....
>
> -------
>
> Being *better* but coming second in the race is no good - it is
> incredible
> difficult to displace the first technology that solves a new problem.
>
> This is one of the big problems with X (and X') - Often we can use X
> or X' to solve some other problem (which has already been solved in
> java , or C) with a more elegant and much better solution - This is
> not enough to get people to change.
>
> To get people to adopt a new technology you have to
>
> 1) Invent a new *thing* that people *want*
> 2) Make sure that language X is the *only* way to make the *thing*
> 3) have a lot of luck
>
> Are their any areas where FPs might do the above? - Yes I think so.
>
> "Go thou and invent a language for programming FPGAs ... :-)"
>
> - This doesn't have to be sexy, smart, .. it just has to work
> *reliably* then use you language to make a few chips for something
> (signal processing, communications ,, you name it ...) - sell the
> chips ...
>
> My guess is that somebody who occasionally reads this group is doing
> this, will they tell us? I think not :-)
>
Verilog and VHDL are already out there and there IEEE standards for them.
Commercial implementations of these languages besides the simulator, they
can translate the Verilog/VHDL code into C++.
--
Linux rulz
Imagination is Domination
Gate 7 Olympiacos
Powered by SuSE
ALIEN
> In short, Haskell is presented as academic. In my humble opinion,
> examples should be shown for everyday programs. If you don't see what
> I'm talking about, I recommend you read the Perl book ("Programming Perl"
> by Larry Wall, et al., O'Reilly) or the Ruby pickaxe book
> ("Programming Ruby: A Pragmatic Programmer's Guide" by D. Thomas &
> A. Hunt, Addison-Wesley).
>
> Ryo
i just searched in amazon for haskell and c related books. 19 results for
haskell and 6500 for c (it includes c++, c# all the commercial
implementations of them and some java related content).
That literature of documentatios is a good enough reason.
Darius
> > In short, Haskell is presented as academic. In my humble opinion,
> > examples should be shown for everyday programs. If you don't see what
> > I'm talking about, I recommend you read the Perl book ("Programming Perl"
> > by Larry Wall, et al., O'Reilly) or the Ruby pickaxe book
> > ("Programming Ruby: A Pragmatic Programmer's Guide" by D. Thomas &
> > A. Hunt, Addison-Wesley).
> >
> > Ryo
>
> i just searched in amazon for haskell and c related books. 19 results for
> haskell and 6500 for c (it includes c++, c# all the commercial
> implementations of them and some java related content).
> That literature of documentatios is a good enough reason.
A) You are right, it covers four languages. 'C++ language' returns
only ~1300 results, still including C# and .NET C++ (and probably Java
and C too).
B) What's your point? You've only supported the thesis of the thread.
That Haskell isn't a mainstream language (and that C++ is). [The
choice of this post to respond too is also puzzling.]
You don't write lots of books to make a language mainstream (though,
if you follow Paul Graham, you need at least one good one, but it
likely won't begin life as a book), a lot of books get written about
mainstream languages. No one yet has claimed Haskell is mainstream.
Jerzy Karczmarczuk
> well C is the fastest programming language. It achieves performance because
> the compiled code is optimised to work as close as to machine language as
> possible. If clock cycle optimisation matters then C is the only solution.
Sir, are you sure that you *wanted* to be *here*?
The "C" zone is the second next corridor, at your right. Yes, yes, this wide
gate plenty of colours, and those vending machines nearby. But be careful,
there is plenty of people inside, they are usually in a hurry, they run over
you, and nobody ever says: 'oh, I am sorry...'. And then you might find it
difficult to find a pharmacy with something to put on your wounded knee...
> Linux rulz
> Imagination is Domination
Oh, yes, ehm. ehm. This is why all those functional troglodytes are so
jealous of imaginative Cmasters.
Jerzy Karczmarczuk
Caen, France
Markus Mottl
> Is Unix or Linux "mainstream" according your criteria?
> No then why IBM,HP,SUN support it and contribute to it?
Because it was hyped by the media and thus became an interesting vehicle
of marketing?
Btw., if you belong to those people who think that something is only
worthwhile considering if it is supported by big companies, you might
be surprised about the following:
http://research.microsoft.com/research/ppt/#projects
Really strange that even huge $$-companies seem to let their research
staff work on languages with a formal basis like Haskell...
> well C is the fastest programming language.
There are no fast languages, only fast computers and good compilers.
> It achieves performance because the compiled code is optimised to work
> as close as to machine language as possible.
That's what all native code compilers do. And some FPL-compilers produce
pretty darn good code...
> If clock cycle optimisation matters then C is the only solution.
If clock cycle optimisation matters, then Assembly is the only solution.
--
Markus Mottl http://www.oefai.at/~markus mar...@oefai.at
Dirk Thierbach
> There is the slight problem that Eiffel has a hole in the typesystem
> you can drive a bus through.
The "hole" can be fixed by global dataflow analysis -- which is indeed
what the Eiffel compiler does, so it is statically typesafe. The
drawback is of course that you need more work to do in the static
analysis, so you loose the simplicity and composability of a "nice"
type system.
> (Covariance of argument types under inheritance -- it's fixed in
> Sather. It's a pity that Sather is looking more and more moribund.)
I wouldn't call that a "fix". It's more natural from the point of view
of a type system, but, as Bertrand Meyers argues correctly, it doesn't
capture the way you normally want to use inheritance in OOLs.
So IMHO what is needed is another approach (both in the language and
the types) to express the properties you want it to have, while keeping
both simplicity and modularity.
- Dirk
Neelakantan Krishnaswami
> Aaron Denney <wno...@ugcs.caltech.edu> wrote:
> >
> > (Covariance of argument types under inheritance -- it's fixed in
> > Sather. It's a pity that Sather is looking more and more moribund.)
>
> I wouldn't call that a "fix". It's more natural from the point of
> view of a type system, but, as Bertrand Meyers argues correctly, it
> doesn't capture the way you normally want to use inheritance in
> OOLs.
The right solution to this is multiple dispatch, not to break the
subtyping rule for functions!
--
Neel Krishnaswami
ne...@alum.mit.edu
Sebastian Sylvan
> i just searched in amazon for haskell and c related books. 19 results for
> haskell and 6500 for c (it includes c++, c# all the commercial
> implementations of them and some java related content).
> That literature of documentatios is a good enough reason.
I'm sorry, but that's the most ridiculous statement I've ever heard. Do
you mean to say that you can attribute ANY property of a languge based on
how many books there are about it? C has more books because it's older,
and more widely used. Not because it's more standardized, or a better
language or ANYTHING.
Availability of books has nothing to do with the properties of the
language.
--
----------------------------------------
| Sebastian Sylvan |
| ICQ: 44640862 |
| Tel: 073-6818655 / 031-812 817 |
| |
| |
| Hard Work Often Pays Off After Time |
| But Laziness Always Pays Off Now! |
----------------------------------------
Andreas Eder
> i just searched in amazon for haskell and c related books. 19 results for
> haskell and 6500 for c (it includes c++, c# all the commercial
> implementations of them and some java related content).
> That literature of documentatios is a good enough reason.
This is so, because you need that many books on C, C++ et al. Haskell
on the other hand is so easy to comprehend, that there is no need for
a plethora of books. There just is no nedd for a 'Haskell for Dummies'
book.
'Andreas
--
Wherever I lay my .emacs, thereć„€ my $HOME.
Simon Helsen
While I don't think that the number of books on a language makes any
qualifying statement about the language, I disagree that Haskell is all
that simple. Besides, Paul Hudak's book on multi-media programming in
Haskell could well have been called 'Haskell for Dummies'.
I think everybody in this newsgroup will agree that more widespread
support for Haskell, including libraries and development platforms, would
help popularize the language. Despite the exceptional usage of Haskell in
rare industrial projects, Haskell remains an academic beast and the
current Haskell community is not going to change that, despite
MS-Research's effort to work on Haskell technology. A pitty, no doubt
about that.
Simon
Aaron Denney
> Aaron Denney <wno...@ugcs.caltech.edu> wrote:
>> There is the slight problem that Eiffel has a hole in the typesystem
>> you can drive a bus through.
>
> The "hole" can be fixed by global dataflow analysis -- which is indeed
> what the Eiffel compiler does, so it is statically typesafe. The
> drawback is of course that you need more work to do in the static
> analysis, so you loose the simplicity and composability of a "nice"
> type system.
s/fixed/patched/
How does global dataflow analysis work with seperate compilation?
> I wouldn't call that a "fix". It's more natural from the point of view
> of a type system, but, as Bertrand Meyers argues correctly, it doesn't
> capture the way you normally want to use inheritance in OOLs.
Normally, I just want to use interfaces, and it works fine there.
I don't like tying two classes closely enough together that they need
to be co-derived from and only work with each other.
> So IMHO what is needed is another approach (both in the language and
> the types) to express the properties you want it to have, while keeping
> both simplicity and modularity.
Neelakantan Krishnaswami elsethread suggests multiple dispatch.
I'm not sure I completely agree, but I think it's better than
than the current Eiffel situation.
Something like the multiple parameter typeclass extension to Haskell
is more what I favor.
Dirk Thierbach
I don't see how multiple dispatch can help here. Maybe you could
give an example?
That said, there seem to be different opinions about the "right"
solution. I haven't seen any "solutions" so far that would convince me.
- Dirk
John Atwood
>jeng...@flightlab.com (Joe English) quoth:
>> So I tracked down the offending routine -- about a screenful
>> of C code -- and translated it into four lines of Haskell so
>> I could better understand what it was doing. (I was actually
>> the one who wrote the routine in the first place, but had
>> forgotten how it worked by this time :-)
>>
>> Then I transformed the 4-line Haskell program step-by-step
>> into an equivalent algorithm that was more efficient. Finally,
>> I translated this back into C (about 1 1/2 screensful this time)
>> and replaced the original routine.
>
>Is it possible for you to show this code? A concrete example would
>convince people better than a general description, and even those of us
>who don't need convincing would probably find it interesting.
I hope will be able to elaborate; a couple of other examples of "calculating efficient programs":
Expression Refinement: Deriving Bresenham's Algorithm (1994) Alexander Bunkenburg
http://citeseer.nj.nec.com/bunkenburg94expression.html
J. Gibbons and O. de Moor. Bridging the algorithm gap: a linear-time functional program for paragraph formatting. Science of Computer Programming, Vol. 35, No.
1, September 1999.
http://web.comlab.ox.ac.uk/oucl/work/oege.de.moor/pubs.htm
John Atwood
Shae Matijs Erisson
> I don't think you should be so certain about that. Multi-threading
> in C using typical OS threads uses far more resources than Haskell
> or Erlang threads for example. But in some ways your right I think.
> C is widely used in resource constrained embedded applications
> because it doesn't need a heavyweight run time system with garbage
> collected heaps etc..like (current implementations of) Haskell do.
> But there are other experimental FPL implemenatations which try to
> address this issue too, like "ML Kit".
> That said, I don't want to accuse everybody who choses not to use current
> FPL's of being ignorant. It is possible to understand FPL's perfectly well
> and still decide not to use them (or at least their current incarnations).
> I don't program 218x DSP's in Haskell (yet).
Someone mentioned a port of the NHC98 runtime to PalmOS.
http://www.haskell.org/pipermail/haskell/2003-March/011428.html
I can barely wait.
--
Shae Matijs Erisson - 2 days older than RFC0226
#haskell on irc.freenode.net - We Put the Funk in Funktion
10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)
ALIEN
> On Mon, 14 Apr 2003, ALIEN wrote:
>> i just searched in amazon for haskell and c related books. 19 results for
>> haskell and 6500 for c (it includes c++, c# all the commercial
>> implementations of them and some java related content).
>> That literature of documentatios is a good enough reason.
>
> I'm sorry, but that's the most ridiculous statement I've ever heard. Do
> you mean to say that you can attribute ANY property of a languge based on
> how many books there are about it? C has more books because it's older,
> and more widely used. Not because it's more standardized, or a better
> language or ANYTHING.
>
> Availability of books has nothing to do with the properties of the
> language.
well it does have to do with the volume of documentation my friend and
clearly there is a huge volume of documentation around these languages. How
do you expect from a language to become mainstream without supportive
documentation from publishers and writers?
as far as the older c# returns 132 results and java 1237 results.
ALIEN
> ALIEN <alient...@yahoo.gr> wrote:
>> Is Unix or Linux "mainstream" according your criteria?
>> No then why IBM,HP,SUN support it and contribute to it?
>
> Because it was hyped by the media and thus became an interesting vehicle
> of marketing?
>
actually they do it because they can sell products, like servers cheaper and
because it costs nothing to build their software to run over opensource
platforms.
> Btw., if you belong to those people who think that something is only
> worthwhile considering if it is supported by big companies, you might
> be surprised about the following:
>
> http://research.microsoft.com/research/ppt/#projects
>
> Really strange that even huge $$-companies seem to let their research
> staff work on languages with a formal basis like Haskell...
>
well if microsoft supports haskell then they'd better make a visual haskell
That will make the language do something useful.
>> well C is the fastest programming language.
>
> There are no fast languages, only fast computers and good compilers.
>
>> It achieves performance because the compiled code is optimised to work
>> as close as to machine language as possible.
>
> That's what all native code compilers do. And some FPL-compilers produce
> pretty darn good code...
>
>> If clock cycle optimisation matters then C is the only solution.
>
> If clock cycle optimisation matters, then Assembly is the only solution.
>
actually C is that good. applications that are written in c perform faster
because of that reason. Assembly is a good solution indeed. C is better
than any other high level languages in producing fast code.
Sebastian Sylvan
> well if microsoft supports haskell then they'd better make a visual haskell
> That will make the language do something useful.
I urge all other reader of this statement: Please, don't feed the troll.
> actually C is that good. applications that are written in c perform faster
> because of that reason.
Applications written in C perform better because C is basically just
assembler with some extra syntactic sugar. You can take a look at a
function in C and pretty much predict exactly how the resulting code will
look. In other words: C is faster because it's desperatly low-level (as
far as high level languages go).
If you really need speed (for some critical function) then why not write
it in assembly and get TOTAL control? If you don't need speed (which you
most likely don't, for most of your code) then why not write it in a
higher-level langauge that enables you to be more productive?
Sebastian Sylvan
Yes, but like I said, it has nothing to do with the properties of a
language.
If language X is more popular, then more authors will write books about
it. X is not popular because more authors write books about it.
C is mainstream, so naturally there are many more books on C than Haskell.
That does not mean that C is better than Haskell in any way.
George Russell
> actually C is that good. applications that are written in c perform faster
> because of that reason. Assembly is a good solution indeed. C is better
> than any other high level languages in producing fast code.
Actually this is simply not true. Toddle over to sci.math.num-analysis
and you'll find many people who will claim that FORTRAN is faster than C
for numerical applications. There are various technical reasons for
this which I won't bore you with. C9X addresses some of them.
I think SISAL, which is a functional language, would probably beat both
of them if it were properly supported.
Ulf Wiger
> > well C is the fastest programming language.
>
> There are no fast languages, only fast computers and
> good compilers.
Execution speed of an application depends on so many factors.
A language that yields blazingly fast code for one
application may not even give you enough support to arrive at
a working application in another domain; a language that
seems very slow in some aspects may provide stellar
performance in others.
Let a Porsche 911 and e.g. a Mack CH602 race 400 yards.
The Porsche will win. Now put a 5 ton load on each(*), and
let them race again. Most likely, you'll find that "fast"
is a relative term, and also domain-specific.
/Uffe
(*) Not sure how this is done on a 911... It has 130
liters of baggage room, and a trailer hook doesn't seem
to be an option -- assuming that it matters, that we don't
break the rear axle or burn the transmission.
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
Adrian Hey
> While I don't think that the number of books on a language makes any
> qualifying statement about the language, I disagree that Haskell is all
> that simple.
Yes, I think it's wrong to assume Haskell is so simple that good teaching
material isn't needed.
> Besides, Paul Hudak's book on multi-media programming in
> Haskell could well have been called 'Haskell for Dummies'.
Oh dear, better keep quiet about that book then. We don't want any dummies
thinking they can use our favourite language. Nosireee.
I say let's keep Haskell a dummy free zone.
VIVA lambda calculus
VIVA referential transparency
VIVA existential type quantification
VIVA rank-N polymorphism
VIVA monadic IO
These features should suffice for now. If it ever looks like Haskell is
becoming mainstream, I'm sure it will be possible to incorporate some
suitably obfuscated new theory to scare them off :-)
Regards
--
Adrian Hey
Galen Menzel
> On Tue, 15 Apr 2003, ALIEN wrote:
>
>
> Applications written in C perform better because C is basically just
> assembler with some extra syntactic sugar. You can take a look at a
> function in C and pretty much predict exactly how the resulting code will
> look. In other words: C is faster because it's desperatly low-level (as
> far as high level languages go).
>
> If you really need speed (for some critical function) then why not write
> it in assembly and get TOTAL control? If you don't need speed (which you
> most likely don't, for most of your code) then why not write it in a
> higher-level langauge that enables you to be more productive?
>
Come on, now. Do you really want to say that there's no middle-ground
between high-level languages and assembly? Let's not be silly; C has
its place. Don't forget why UNIX was ported to so many architectures so
quickly -- it was (re)written in C and not assembly. C provides a
needed level of abstraction and portability from the hardware, while
staying low-level enough to do things you just can't do in Haskell, like
memory management.
That said, I think C is *far* overused these days, and people's
estimates of C's gain in speed are often unjustified and almost always
untested. I'd use C for embedded systems programming, OS stuff, and not
much else. I love Haskell and Scheme, but you have to admit that there
are times when they're not called for -- and not just when it's time to
break out the assembler.
galen
Simon Helsen
>> Besides, Paul Hudak's book on multi-media programming in
>> Haskell could well have been called 'Haskell for Dummies'.
>
>Oh dear, better keep quiet about that book then. We don't want any dummies
>thinking they can use our favourite language. Nosireee.
I know you're being sarcastic about it, but I did not intend to make
Hudak's book look negative. I think it is a wonderful attempt to attract
CS101 students - who for the most part think they have conquered the world
with Java, VB or C++ already - to a new paradigm such as FP. In
particular, it throws away the mith that Monads are 'difficult' or
'incomprehensible'. In fact, the book starts using monads from the very
beginning without even mentioning the word monad (well, I have to check -
it is possible that he mentions the name in a footnote of course).
But whatever the noble attempts to write such books, it remains an uphill
battle, not just for Haskell (ML, Scheme, Erlang, Caml, name it).
Programming languages are not used because of technical superiority (you
don't have to be functional to see this, look at Smalltalk for one).
History has proven that technical superiority at best 'does not matter'.
If you're a cynic, you might argue that it is even a disadvantage...
>I say let's keep Haskell a dummy free zone.
> VIVA lambda calculus
> VIVA referential transparency
> VIVA existential type quantification
> VIVA rank-N polymorphism
> VIVA monadic IO
>
>These features should suffice for now. If it ever looks like Haskell is
>becoming mainstream, I'm sure it will be possible to incorporate some
>suitably obfuscated new theory to scare them off :-)
multi-parameter type classes are 'essential' for any serious Haskell
programming, of course ;-)
Regards,
Simon
Dirk Thierbach
> In article <p57qm-...@ID-7776.user.dfncis.de>, Dirk Thierbach wrote:
>> Aaron Denney <wno...@ugcs.caltech.edu> wrote:
>>> There is the slight problem that Eiffel has a hole in the typesystem
>>> you can drive a bus through.
>> The "hole" can be fixed by global dataflow analysis -- which is indeed
>> what the Eiffel compiler does, so it is statically typesafe. The
>> drawback is of course that you need more work to do in the static
>> analysis, so you loose the simplicity and composability of a "nice"
>> type system.
> s/fixed/patched/
Whatever you like to call it.
> How does global dataflow analysis work with seperate compilation?
By keeping the intermediate results of the analysis, per file. At
least that's the impression I got when I last looked at the compiler,
which was years ago.
Yes, it's ugly, but it doesn't deserve the "hole you can drive a bus
through" qualification.
> Normally, I just want to use interfaces, and it works fine there.
> I don't like tying two classes closely enough together that they need
> to be co-derived from and only work with each other.
But it happens often enough. If you can avoid it, you might be lucky :-)
> Neelakantan Krishnaswami elsethread suggests multiple dispatch.
> I'm not sure I completely agree, but I think it's better than
> than the current Eiffel situation.
To me it all that looks like attempts to find the right way to treat
it. Depending on your taste, you may prefer one or the other, but
none of it has the "problem solved" feeling.
> Something like the multiple parameter typeclass extension to Haskell
> is more what I favor.
I'd like something along this line, too, but multiple parameter typeclasses
by themselves are not enough, either.
- Dirk