FP and Python

51 views
Skip to first unread message

Jordan Henderson

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
In article <399356ad...@nospam.usenet.volition.net>,
James Hague <jam...@volition-inc.com> wrote:
>In one of the prior "Why hasn't functional programming caught on?"
>discussions I presented this theory in an offhand way, but I'm
>starting to think there's much to it.
>
>Python provides many of the features that make FP languages more
>productive than, say, C:
>
>* garbage collection
>* lists & tuples
>* higher-order functions such as map and filter
>* low syntactic overhead
>* easy manipulation of complex data structures
>
>At the same time, there's no attempt to throw out or steer the user
>away from:
>
>* general hash tables
>* updatable arrays
>* side effects and updatable variables
>* OOP features
>

Without getting into a language war (but, if we are, you
started it :-)), you are, to a large extent describing
Perl above also. I'm sure one could argue about the
'low syntactic overhead' or 'easy manipulation of complex
data structures'.

Perl has also been described as being similar to Lisp.

Perl has closures (anonymous subroutines). I'm not sure
that Python does...

And, if you are trying to make the argument that functional
programming has caught on in other guises, I think you
could use Perl as an example. Perl has certainly 'caught on'.

>Some of the stickier FP concepts have been dropped:
>
>* currying
>* formal type systems and type inference
>* emphasis on recursion
>
>In a way, Python is providing a majority of the benefits of FP, but
>without the academic fussing. http://www.norvig.com/python-lisp.html
>is a good page that shows that the great similarities between Lisp and
>Python, from the point of view of a Lisp expert.
>
>In a way it seems that FP has triumphed, as many always thought it
>would, but maybe not in the way that was expected. The best of the FP
>concepts have been merged with the best of the imperative concepts.
>Thoughts?
>

I can't speak for the FP experts, not being one myself, but I believe
that those 'stickier FP concepts' that you refer to as 'academic
fussing' are _exactly_ those things that FP advocates feel are
the best things about FP languages.

Without exactly these concepts, you make reasoning about programs
much more difficult. Powerful ideas like reverse exececution
are also much more difficult in the presence of side effects.
Type inference and formal type systems are widely regarded as
one of the truly new and powerful ideas to come along in languages
in the last 20 years.

In any case, there is a language that maintains all the positive
benefits you ascribe to Python that also has currying, formal type
systems and type inference and an emphasis on recursion. That
language is Ocaml. As you can program in an imperative style
in Ocaml, giving you pretty much everything that Python has, I'd
ask you why Ocaml is not more popular.

I personally think it's a bias among working programmers against
'academic' languages. When powerful FP concepts sneak in under
the guise of a new 'scripting' language like Python, these working
programmers will accept them because they don't realize that they
are doing things in a way that is more like these 'academic'
languages they like to deride.

>James
>
>
>-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
>http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
>-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

-Jordan Henderson
jor...@greenapple.com

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
James Hague <jam...@volition-inc.com> wrote:
> Python provides many of the features that make FP languages more
> productive than, say, C:

> * garbage collection
> * lists & tuples
> * higher-order functions such as map and filter
> * low syntactic overhead
> * easy manipulation of complex data structures

These points are definitely available in most, if not all major functional
programming languages.

> At the same time, there's no attempt to throw out or steer the user away
> from:

> * general hash tables
> * updatable arrays
> * side effects and updatable variables
> * OOP features

"Throw out" is probably not justified. "Steer away" - hm, maybe, but if,
then only in the case of purely functional languages. What concerns OOP
(as generally implemented in most imperative languages), there are other
(IMHO: more advanced) ways to structure code, be it type classes in
Haskell, advanced module systems or even "cleaner" OO-implementations like
the one of OCaml.

> Some of the stickier FP concepts have been dropped:

> * currying
> * formal type systems and type inference
> * emphasis on recursion

I have never met anybody who had problems understanding currying after a
short explanation (you need not go into formal aspects of equivalences
between product and function spaces to do this).

What concerns type systems (btw., what is a "formal" type system - are
there informal ones?):

If you mean static typing, why is it that C++ is so wide-spread then? The
type system of this monster requires genius level type system experts to
see through...

And type inference: what is difficult about using it (you don't have to
know how to implement it)? From the beginning on I had the impression that
it made things easier for me. Nobody prevents you from writing type
declarations all over the place if you want to do this - but you need not
do it.

It may be the case that some people find recursion more difficult to
understand than iteration - which is, IMHO, most often a consequence of
them having been exposed to imperative programming before. Still, most
impure functional languages feature iteration constructs - so there is
nothing to argue about.

> In a way, Python is providing a majority of the benefits of FP, but
> without the academic fussing. http://www.norvig.com/python-lisp.html is
> a good page that shows that the great similarities between Lisp and
> Python, from the point of view of a Lisp expert.

Well, "majority of benefits" seems a bit far fetched: "static typing" is
definitely missing (though, some people would see this as a feature, which
I do not agree with).

> In a way it seems that FP has triumphed, as many always thought it
> would, but maybe not in the way that was expected. The best of the FP
> concepts have been merged with the best of the imperative concepts.

Can you list important features that Python has and which are missing in
e.g. OCaml? I do not find any convincing arguments that make Python any
more practical as language - rather the other way round...

Best regards,
Markus Mottl

--
Markus Mottl, mo...@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Daniel Ortmann

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:

> Can you list important features that Python has and which are missing in
> e.g. OCaml? I do not find any convincing arguments that make Python any more
> practical as language - rather the other way round...

Hi Markus,

From my own perspective O'Caml is definately more intimidating than Python.
More powerful certainly! But I will admit that I am still stumbling and
bumbling in O'Caml. :-/

Struggling with such a highly advance language *necessarily* requires a more
sophisticated user. Of course, the final solutions also become better.

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ort...@us.ibm.com / internal 8.553.6795 / external 507.253.6795
ort...@isl.net home 507.288.7732

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Daniel Ortmann <ort...@us.ibm.com> wrote:
> From my own perspective O'Caml is definately more intimidating than Python.
> More powerful certainly! But I will admit that I am still stumbling and
> bumbling in O'Caml. :-/

Using poweful concepts wisely is a matter of training. If you restrict yourself
to the "simple" concepts, you won't find this less expressive than what many
other languages can offer you.

> Struggling with such a highly advance language *necessarily* requires a more
> sophisticated user. Of course, the final solutions also become better.

I continuously find that I still keep learning new concepts in OCaml - but
*not* language-dependent ones! In fact, I think that being exposed to OCaml has
improved my programming skills generally and to a much larger extent than my
(longer!) previous experience in imperative languages.

If you want to improve your skills, there is no way around the functional (and
also logic) style of programming...

Daniel C. Wang

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
{stuff deleted}

> Can you list important features that Python has and which are missing in
> e.g. OCaml? I do not find any convincing arguments that make Python any
> more practical as language - rather the other way round...

% cd /usr/lib/python1.5/
% ls *.py

BaseHTTPServer.py dis.py multifile.py shlex.py
Bastion.py dospath.py mutex.py shutil.py
CGIHTTPServer.py dumbdbm.py netrc.py site.py
ConfigParser.py dump.py nntplib.py smtplib.py
MimeWriter.py exceptions.py ntpath.py snack.py
Queue.py fileinput.py nturl2path.py sndhdr.py
SimpleHTTPServer.py find.py os.py stat.py
SocketServer.py fnmatch.py packmail.py statcache.py
StringIO.py formatter.py pdb.py statvfs.py
UserDict.py fpformat.py pickle.py string.py
UserList.py ftplib.py pipes.py sunau.py
aifc.py getopt.py popen2.py sunaudio.py
anydbm.py getpass.py poplib.py symbol.py
asynchat.py glob.py posixfile.py telnetlib.py
asyncore.py gopherlib.py posixpath.py tempfile.py
audiodev.py grep.py pprint.py threading.py
base64.py gzip.py profile.py toaiff.py
bdb.py htmlentitydefs.py pstats.py token.py
binhex.py htmllib.py pty.py tokenize.py
bisect.py httplib.py py_compile.py traceback.py
calendar.py ihooks.py pyclbr.py tty.py
cgi.py imaplib.py quopri.py turtle.py
cmd.py imghdr.py rand.py types.py
cmp.py keyword.py random.py tzparse.py
cmpcache.py knee.py re.py urllib.py
code.py linecache.py reconvert.py urlparse.py
codeop.py locale.py regex_syntax.py user.py
colorsys.py macpath.py regsub.py util.py
commands.py macurl2path.py repr.py uu.py
compileall.py mailbox.py rexec.py wave.py
copy.py mailcap.py rfc822.py whichdb.py
copy_reg.py mhlib.py rlcompleter.py whrandom.py
dbhash.py mimetools.py sched.py xdrlib.py
dircache.py mimetypes.py sgmllib.py xmllib.py
dircmp.py mimify.py shelve.py


% cd /usr/lib/ocaml/
% ls *.mli

arg.mli format.mli longident.mli pervasives.mli str.mli
arith_status.mli gc.mli map.mli printexc.mli stream.mli
array.mli genlex.mli marshal.mli printf.mli string.mli
big_int.mli graphics.mli nat.mli queue.mli sys.mli
buffer.mli hashtbl.mli num.mli random.mli typecore.mli
callback.mli lazy.mli obj.mli ratio.mli unix.mli
char.mli lexing.mli oo.mli set.mli weak.mli
digest.mli list.mli parsetree.mli sort.mli
filename.mli location.mli parsing.mli stack.mli


You'd think the FP community would learn by now its the "libraries stupid".
Scheme has this same problem.... not because there aren't libraries but
because they aren't standard. (Or haven't been as of yet...)

Jordan Henderson

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
In article <39942d26...@nospam.usenet.volition.net>,

James Hague <jam...@volition-inc.com> wrote:
>>Perl has also been described as being similar to Lisp.
>
>Ah, but in Python you have have arbitrary nested data structures
>without any extra work. You can have nested data structres in Perl
>too, but it isn't as natural. You have to resort to references.
>Quoting Chapter 4 of the Camel book: "For both practical and
>philosophical reasons, Perl has always been biased in favor of flat,
>linear data structures."
>

Yes, yes. I ceded this point to you when I said (in article
<8n13lg$28v$1...@lisa.gemair.com>):

>>Without getting into a language war (but, if we are, you
>>started it :-)), you are, to a large extent describing
>>Perl above also. I'm sure one could argue about the

>>'low syntactic overhead' or 'easy manipulation of complex
>>data structures'.

But, for some reason, you decided to elide this and pounce on
a single point from my response that you felt you could refute.

I wasn't trying to make a point about Perl, or any other
language, for that matter. What I was trying to say was that a number
of languages have attributes that are more-or-less similar to
Functional Programming languages. Some of these are more popular,
some less. I don't know what you can draw from this.

But then, I should know better. When someone posts in
comp.lang.functional with the thesis that Python has all the
best features of FP languages without any of the 'academic
fussing' of currying, type inference or heavy reliance on
recursion, I should have recognized it as a troll and resisted
the temptation to being drawn in.

>I'm not trying to start a language war at all; it is a mistake to
>blindly cling to one language for all purposes. But it is striking
>how Python code can be similar to what you see in Lisp textbooks...and
>it is a language of rapidly growing popularity.
>

It's even more striking to me how much Common Lisp code looks similar to
what you see in Lisp textbooks.

Common Lisp has:

* general hash tables (check)
* updatable arrays (check)
* side effects and updatable variables (check)
* OOP features (check)

If you don't like those 'sticky' currying or reliance on recursion, then
don't use them. Common Lisp also has a full set of looping contructs and
a fully general exception mechanism.

So, what is your point _exactly_? That FP languages have failed to
gain acceptance because they discourage practical programming constructs
like hash tables, updateable arrays, etc.? I wonder why the FP language
designers for Ocaml and Common Lisp went to all the trouble to put them
in then?

Jordan Henderson

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
In article <r8td7jf...@chinstrap.CS.Princeton.EDU>,

Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
>
>Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>{stuff deleted}
>> Can you list important features that Python has and which are missing in
>> e.g. OCaml? I do not find any convincing arguments that make Python any
>> more practical as language - rather the other way round...
>
> [demonstration that there are more libraries available for Python than
> for Ocaml deleted]

>
>You'd think the FP community would learn by now its the "libraries stupid".
>Scheme has this same problem.... not because there aren't libraries but
>because they aren't standard. (Or haven't been as of yet...)

That is a problem, sure. But, is it the case that Python is more
popular because of the extensive libraries available, or is it the
case that there are extensive libraries available because Python is
more popular.

I believe that people are turned off by functional or logic programming
languages and don't even give them a chance and thus they don't have
nearly the number of people developing libraries.

Question: Seeing as the CPAN library for Perl dwarfs the libraries
available for Python, why is it that Python is gaining in popularity
so quickly? If the answer is that Python is a better, cleaner
language then why can't these many nice FP languages that have
all the intrinsic advantages (not including library support) also rapidly
gain in popularity?

-Jordan Henderson
jor...@greenapple.com


Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
James Hague <jam...@volition-inc.com> wrote:

> Markus Mottl wrote:
>>What concerns type systems (btw., what is a "formal" type system - are
>>there informal ones?):
> Sure. In dynamically typed languages you certainly have types, but
> you don't have to describe conglomerate data types before using them.
> That is, you don't have to say "this list will only contain numbers,
> strings, and tuples of the form (number, string)." You just put stuff
> in lists.

You probably mean something less safe than polymorphic variants. Here an
example of how they work:

let _ =
let data = [`foo 42; `text; `The "answer..."]
and handle = function
| `foo n -> print_int n
| `The str -> print_endline ("the " ^ str)
| _ -> print_string " must have been " in
List.iter handle data

Running this yields:

42 must have been the answer...

Of course you can put arbitrary variants into lists without having to
declare the type. The compiler is nice enough to infer it for you and to
verify that:

* you do not accidently pass things to functions that cannot handle them

* you do not forget to handle specific data values that might be
returned by some function

Can Python do this for you?

E.g.:

let can_handle_foo = function `foo -> 42
let _ = can_handle_foo `bar

running this will lead to:

File "bla.ml", line 2, characters 23-27:
This expression has type [> `bar] but is here used with type [< `foo]

in other terms: the function can handle "foo"s but you tried a "bar"...

> Other than the more extensive libraries available for Python, there
> aren't any. That's not my point. OCaml is a good language with a
> fantastic implementation.

This depends on your applications. Python surely has very nice libraries
for solving scripting tasks. On the other hand, I don't think that Python
has anything close to OCaml's "BigArrays" or high-performance big-integer
library.

> There's a persistent and "Why hasn't FP caught on?" undercurrent in
> the functional programming community.

Right - a rather economic and psychological question...

> My argument is that it _has_ caught on, or at least the most appealing
> features have caught on. That is, garbage collection, arbitrary lists,
> and and an interactive environment provide huge benefits to programmers,
> so they have found their way into a popular, mainstream language.

But these concepts have been present in other (non-FP) languages for long,
too, so it rather seems that people have become more reasonable - not more
"FP".

> The other items that haven't caught on--referential transparency,
> currying, provability, bulletproof type systems--are arguably less
> important than what *has* caught on, at least to a large number of
> programmers.

How many people have only heard of type inference, currying, etc.? Let's
face it: people do what industry demands and industry wants people who do
what they want. I wouldn't be surprised at all if most CS graduates have
no clue what type inference actually is...

> This isn't a swipe at any current FP languages. I find both Ocaml and
> Erlang to be very useful. It's more a pointer to benefits of FP that
> have been carried over into what is becoming a commonly used
> programming language with many success stories.

I really doubt that there was a significant impact of FP: garbage
collection is (IMHO) mandatory for large projects - at some point (even if
it happens late), people learn from their mistakes (e.g. Java).

Given that also imperative languages without builtin list support require
lists very often (using libraries), it is also not too surprising to see
people add native support to new imperative languages.

Interactive programming has been there in the imperative world for a long
time (Smalltalk...).

In short: although I'd like to hear that people have learnt one or the
other lesson from FP, I am realist enough today that most people have not
the faintest idea of what FP is. I have already heard graduates with
distinction say that "C" is probably more a functional language than C++,
because functions (?) are the main means of abstraction there.

This might be an indicator that it's not so much the researchers who fail,
but more the teachers...

Daniel C. Wang

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Here are my musings about why FP libraries suck

1. Writing and HTML parser or IMAP interface in you favorite FPL
doesn't demonstrate how useful new fancy language feature X is.

2. Too many FPLs with too many language features/implementations
makes pooling limited resources to write useful libraries a
configuration nightmare.

3. Lack a of critical mass of hackers writing libraries
for moving target languages and implementations.

4. Unwillingness to make compromises in language design to make
interfaceing with legacy C code eaiser.
(I can go into more detail here, but reference counting and other less
aggressive memory management technqiues make interfacing with C a whole
lot easier.)

5. No real way to quantify productivity/performance gains in order to
displace the established langauges such as Perl and Python. It's
amazing how much of the web be executed via slow interpreters. It makes
you wonder if compilation is worth all the trouble.

i.e. I don't care if it will make my program faster.
My Python/Perl program is fast enough.. the type system just slows
the rate at which I can program....

6. No funding to do any of 1 - 5.

7. Fixing or solving the problems in 1 - 5 doesn't help you get tenure. :)

8. FPLs aren't called "Java"(TM)

9. FPLs don't have good tutorials

10. FPLs don't solve a particular "niche problem space" other than
bootstraping compilers for FPLs... and the occasional theorem prover.


Taavi Talvik

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Jordan Henderson <jor...@lisa.gemair.com> wrote:
: In article <r8td7jf...@chinstrap.CS.Princeton.EDU>,

: Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
:>
:>Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
:>{stuff deleted}
:>> Can you list important features that Python has and which are missing in
:>> e.g. OCaml? I do not find any convincing arguments that make Python any
:>> more practical as language - rather the other way round...
:>
:>You'd think the FP community would learn by now its the "libraries stupid".
:>Scheme has this same problem.... not because there aren't libraries but
:>because they aren't standard. (Or haven't been as of yet...)

: That is a problem, sure. But, is it the case that Python is more
: popular because of the extensive libraries available, or is it the
: case that there are extensive libraries available because Python is
: more popular.

It's not libary issue, its more fancy bouncing library issue:)

Erlang has *really wonderful* libraries, but they are not visually
attractive, they are for boring and serious applications. However most of got
our first programming experience with drawing lines and circles and menus
and windows..

Just like we judge people by first impression, we judge programming languages.

best regards,
taavi
--
Real computer scientists don't program in assembler. They don't write
in anything less portable than a number two pencil.


Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
> % cd /usr/lib/python1.5/
> % ls *.py

Ahem, first of all, do you always list python files in four columns and
OCaml ones in five (naturally shorter ones)...? ;-)

Furthermore, there seem to be quite some of standard libraries missing in
your OCaml distribution (bigarray, dbm, dynlink, int32, threads, tk, ...).

Additionally, we may ask whether this comparison is really a justified
one: the OCaml Unix-library alone probably contains the functionality of
some of the Python modules (though, there may be Python libraries for
which the opposite is true - I don't know).

Now, of course, your argument raises a few questions: is it really just a
matter of having HTTP-, Mime-, Mail-, sound- (?), etc. support in the
distribution of the *standard library*??

Take a look at this:

http://caml.inria.fr/hump.html

and this:

http://www.npc.de/ocaml/linkdb

I'd say that this covers plenty of the functionality that is listed in the
Python distribution.

Maybe one problem is that people are just too lazy (or risk-averse?) to
download and install third party libraries. This would indicate that more
resources should be devised to the extension of the standard distribution.

Or maybe it is the problem that that there is currently no standard way to
incorporate third party libraries into the OCaml-system - which does not
mean that it is difficult, but it is, well, "non-standard".

I'd be very grateful if INRIA came up with rigid guidelines or, even
better, tools to support this (= social technology).

> You'd think the FP community would learn by now its the "libraries
> stupid". Scheme has this same problem.... not because there aren't
> libraries but because they aren't standard. (Or haven't been as of
> yet...)

I agree that this may be a factor. Hm, is it really so difficult or time
consuming to clear this out? Although I remember having raised the issue
on the OCaml-list a while ago, I'll try again to make others (especially
the developers) more aware of this aspect. It would be a pity if it were
just this obstacle that prevents FPLs from world domination ;-)

Edward Jason Riedy

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
And James Hague writes:
- * higher-order functions such as map and filter

Things likely (I hope) to be added soon:
* zip
* real lexical binding
* list comprehension syntax (not full pattern matching, but a start)

- Some of the stickier FP concepts have been dropped:
- * formal type systems and type inference

See the types-sig. Optional static typing is desired, but it
hasn't been fully designed. Probably will be added in the
Python 3000 reworking a few years hence.

http://www.python.org/sigs/types-sig/

Jason, wondering who will win the race to re-invent CL...

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Taavi Talvik <ta...@ns.uninet.ee> wrote:
> It's not libary issue, its more fancy bouncing library issue:)

This may well be the case...

> Erlang has *really wonderful* libraries, but they are not visually
> attractive, they are for boring and serious applications. However most of got
> our first programming experience with drawing lines and circles and menus
> and windows..

I like languages with serious libraries. Still, it is probably not the lack of
"drawing lines and circles" or "menus and windows" libraries that prevents
people from using FPLs. E.g., OCaml (the other FPLs probably have similar
support) *has* libraries for doing graphics (even portably!) and GUIs
(standard: Tk; still in beta (but already fairly advanced): GTK).

Daniel C. Wang

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Markus Mottl <mo...@miss.wu-wien.ac.at> writes:

{stuff deleted}


> Maybe one problem is that people are just too lazy (or risk-averse?) to
> download and install third party libraries. This would indicate that more
> resources should be devised to the extension of the standard distribution.

Yes... people are both lazy and risk-averse... also both Python and Perl
have mechanisms for embedding documentation of third party and standard
modules in the source code it self... this is a useful feature....


> Or maybe it is the problem that that there is currently no standard way to
> incorporate third party libraries into the OCaml-system - which does not
> mean that it is difficult, but it is, well, "non-standard".

This "non-standardness" is a real put off. There's also the configuration
management/versioning nightmare. All the "standard" stuff is ported over as
new versions of Perl and Python get released. With a third party extension
when a new release of OCaml comes out, I have not guarantee that it will
still work... or that the original author is at all interested in porting it
over to the new system..

> I'd be very grateful if INRIA came up with rigid guidelines or, even
> better, tools to support this (= social technology).

They should steal the ideas from CM (SML/NJ's compilation manager) and get
rid of the Makefiles.... (I ***hate**** Makefiles...)

> > You'd think the FP community would learn by now its the "libraries
> > stupid". Scheme has this same problem.... not because there aren't
> > libraries but because they aren't standard. (Or haven't been as of
> > yet...)
>
> I agree that this may be a factor. Hm, is it really so difficult or time
> consuming to clear this out? Although I remember having raised the issue
> on the OCaml-list a while ago, I'll try again to make others (especially
> the developers) more aware of this aspect. It would be a pity if it were
> just this obstacle that prevents FPLs from world domination ;-)

Documentation and accessible tutorials and a compelling application would be
great.. too....

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
> 1. Writing and HTML parser or IMAP interface in you favorite FPL
> doesn't demonstrate how useful new fancy language feature X is.

There are libraries for such applications around - only "non-standard". I am
getting succeedingly convinced that only the latter is the real problem.

> 2. Too many FPLs with too many language features/implementations
> makes pooling limited resources to write useful libraries a
> configuration nightmare.

This may be a problem. On the other hand, one of the reasons why FPLs are
technically so advanced may also have its origin in "competition" and
"cross-fertilization" between languages. The merger of OCaml and O'Labl seems
to be the synthesis of these two aspects... - and has made (IMHO) the resulting
language even more useful.

> 3. Lack a of critical mass of hackers writing libraries
> for moving target languages and implementations.

Please help contributing! :-)

> 4. Unwillingness to make compromises in language design to make
> interfaceing with legacy C code eaiser.
> (I can go into more detail here, but reference counting and other less
> aggressive memory management technqiues make interfacing with C a whole
> lot easier.)

Hm? - When I first interfaced OCaml and C (manually), I was very surprised that
it was so straightforward - I'd have expected many more problems (as you
probably do). Furthermore, there is a (standard!) code generator for IDL- and
COM-specifications now that make this even easier! I'd be surprised if Python
or Perl were any easier in this respect.

> 5. No real way to quantify productivity/performance gains in order to
> displace the established langauges such as Perl and Python. It's
> amazing how much of the web be executed via slow interpreters. It makes
> you wonder if compilation is worth all the trouble.

People from the Perl- and Python community often claim that they "finish" their
jobs first. However, the question is whether they do it correctly. How much
costs, do you think, are associated with maintaining these scripts? - There is
a difference between saying "It runs and does something!" and "It solves the
problem.". Anyway, it is probably difficult to really answer this question
without any thorough empirical studies.

> i.e. I don't care if it will make my program faster.
> My Python/Perl program is fast enough.. the type system just slows
> the rate at which I can program....

I agree that speed of interpreted programs may be sufficient for many tasks.
But is this an argument against *faster* solutions? Would you say "I don't want
to earn $100,000 per year - I can make a living of $20,000, too."?

> 6. No funding to do any of 1 - 5.

This may have been a reason in the past. But it seems that slowly (but surely),
commerce is getting interested, e.g. Microsoft (yes, the "evil" empire) has
already invested considerably into Haskell and is currently also supporting the
Mercury team. This is good! (Hm, or maybe they have sinister plans to fund away
the developers to have even more success with VB & Co.? ;-)

However, "funding" is ok - but what you need is *human* resources! These are,
indeed, very scarce in this field, and you can't get it just by paying enough
money (not in the short run)...

> 7. Fixing or solving the problems in 1 - 5 doesn't help you get tenure. :)

I'd say that this is a nearly non-existing aspect.

> 8. FPLs aren't called "Java"(TM)

I can't argue with that... ;-)

> 9. FPLs don't have good tutorials

You think that tutorials of other languages are really any better? This does
not correspond to my experience when I learnt FPLs - from tutorials.

> 10. FPLs don't solve a particular "niche problem space" other than
> bootstraping compilers for FPLs... and the occasional theorem prover.

This statement can be easily dismissed: there is probably no FPL around that
doesn't have "interesting" commercial or other "non-theoretical" applications
(though, the quantity may be low - because they are not used too often in
general, even less in the commercial sector).

Given that people have implemented Quake in Haskell, switching software in
Erlang and Genealogy software in OCaml, one could not say that these languages
don't have widespread applicability.

Edward Avis

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
IMHO the single most useful library for any FP would be a general
interface to Perl modules, so that people can use CPAN ('the world's
largest repository of reusable software'). Certainly the availablilty
of a library for almost anything is the biggest reason I write stuff
in Perl.

Perl's data structures - lists and hashes (associative arrays) - could
convert to Haskell fairly easily. Scalars would be a little more
difficult since they hold either a number or a string, but you could
easily define a datatype for that. I imagine that each module would
need some Haskell glue to define what types are expected for
subroutine arguments (string, number, object reference) but that
wouldn't be more than a few lines.

Okay, you lose laziness and everything is stuck in the IO monad, but
when all you want to do is fetch a Web page or write something to the
system log, those are a small price to pay.

I don't know how practical this is. Certainly it would be more
difficult than I've made it out to be. And the runtime system would
be some horrible monster (Perl is interpreted). But IMHO, interfaces
from FP to high-level imperative languages are much more important
than from FP to C (at this time). You could insert your favourite
scripting language instead of Perl, I chose it because it has more
libraries than the others.

Or maybe the answer is to CORBAify all of CPAN?

--
Ed Avis
ep...@doc.ic.ac.uk

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
> This "non-standardness" is a real put off. There's also the configuration
> management/versioning nightmare. All the "standard" stuff is ported over as
> new versions of Perl and Python get released. With a third party extension
> when a new release of OCaml comes out, I have not guarantee that it will
> still work... or that the original author is at all interested in porting it
> over to the new system..

I agree. Hopefully, the developers see this shortcoming, too.

> They should steal the ideas from CM (SML/NJ's compilation manager) and get
> rid of the Makefiles.... (I ***hate**** Makefiles...)

Well, Makefiles are messy, but good at glueing together very different tools. I
don't know how powerful CM is in this respect...

Daniel C. Wang

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Markus Mottl <mo...@miss.wu-wien.ac.at> writes:

{stuff deleted}


> This may be a problem. On the other hand, one of the reasons why FPLs are
> technically so advanced may also have its origin in "competition" and
> "cross-fertilization" between languages. The merger of OCaml and O'Labl seems
> to be the synthesis of these two aspects... - and has made (IMHO) the resulting
> language even more useful.

Agreed, but given the choices between
a.) A very useful and langauge for which it is easy to write useful
libraries in

b.) A not so useful language for which useul libraries already exist.

It will probably take less time to get work done with b.

> > 3. Lack a of critical mass of hackers writing libraries
> > for moving target languages and implementations.
>
> Please help contributing! :-)

I'm stuck in the Standard ML universe... I might switch to the OCaml world,
once they get rid of the Makefiles, and after my advisor signs my thesis. :)

>
> > 4. Unwillingness to make compromises in language design to make
> > interfaceing with legacy C code eaiser.
> > (I can go into more detail here, but reference counting and other less
> > aggressive memory management technqiues make interfacing with C a whole
> > lot easier.)
>
> Hm? - When I first interfaced OCaml and C (manually), I was very surprised that
> it was so straightforward - I'd have expected many more problems (as you
> probably do). Furthermore, there is a (standard!) code generator for IDL- and
> COM-specifications now that make this even easier! I'd be surprised if Python
> or Perl were any easier in this respect.
>

How do you manage memory across the OCaml and C worlds? (Actually, OCaml has
added some ugliness to the language to make interfacing with C
easier.. that's why "structs/records" are so "ugly") Python and Perl have
"SWIG" (http://www.swig.org/Doc1.1/HTML/Contents.html) perhaps, someone shoud
write an OCaml backend for SWIG...

> I agree that speed of interpreted programs may be sufficient for many tasks.
> But is this an argument against *faster* solutions? Would you say "I don't want
> to earn $100,000 per year - I can make a living of $20,000, too."?

Ummm... I'm a graduate student who will probably end up teaching in
academia. My roomate from college is worth six figures last time I talked
to him.... so I guess the we all know the answer to that question... :)

> However, "funding" is ok - but what you need is *human* resources! These are,
> indeed, very scarce in this field, and you can't get it just by paying enough
> money (not in the short run)...

By "funding" I mean resources of all sorts...


> > 7. Fixing or solving the problems in 1 - 5 doesn't help you get tenure. :)
>
> I'd say that this is a nearly non-existing aspect.

Not when the majority of FPL developers are academics....

FPLs haven't taken off because of marketing/economic issues.
The "economics" of FPL development encourage new radical cutting edge
language designs and discourage every day boring but useful library
building. The "cutting edge language design" part makes FPLs fun to program
with. I just wish some of the less cutting edge stuff could be turned into a
"boring" everyday language that is as least as popular and useful as
Python/Perl....

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Edward Avis <ep...@doc.ic.ac.uk> wrote:
> IMHO the single most useful library for any FP would be a general
> interface to Perl modules, so that people can use CPAN ('the world's
> largest repository of reusable software'). Certainly the availablilty
> of a library for almost anything is the biggest reason I write stuff
> in Perl.

Why should this be helpful? There is no reason for using an FPL if you only
want to do a few library calls in some scripting language (which is probably,
what suffices for most people).

In fact, you can easily use already existing scripting languages from within
FPLs by just generating code on the fly (FPLs are very adept in synthesizing
programs) and use sockets to communicate with the interpreter. No big deal...

[snip]


> But IMHO, interfaces from FP to high-level imperative languages are much more
> important than from FP to C (at this time).

The reason for interoperability with C is that there are *fast* libraries,
which are not so easily replicable, even if some modern FPL implementations
come fairly close. It may be a terrible effort to port old and mature
C-libraries (e.g. numerical ones) without introducing bugs.

Michael Schuerig

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:

> Daniel Ortmann <ort...@us.ibm.com> wrote:
> > From my own perspective O'Caml is definately more intimidating than Python.
> > More powerful certainly! But I will admit that I am still stumbling and
> > bumbling in O'Caml. :-/
>
> Using poweful concepts wisely is a matter of training.

How many well-trained software developers have you met in the software
industry?

Michael

--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/

graham

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
James Hague <jam...@volition-inc.com> wrote:
>> In one of the prior "Why hasn't functional programming caught on?"
>> discussions I presented this theory in an offhand way, but I'm
>> starting to think there's much to it.
>>
>> Python provides many of the features that make FP languages more
>> productive than, say, C:
>>
>> * garbage collection
>> * lists & tuples

Last time I checkes Python didn't have proper garbage collection
since circular references are not collected. Python also doesn't
have closures (you can fake them but they are not automatic).

graham


Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
> Agreed, but given the choices between
> a.) A very useful and langauge for which it is easy to write useful
> libraries in

> b.) A not so useful language for which useul libraries already exist.
>
> It will probably take less time to get work done with b.

A chicken-and-egg problem... - a typical example of the "network effect" that
speeds up further development of languages (libraries) that already have
wide-spread use. Maybe one should try to get the libraries elaborate enough to
have a critical mass for this effect. I think it could work...

>> Please help contributing! :-)

> I'm stuck in the Standard ML universe... I might switch to the OCaml world,
> once they get rid of the Makefiles, and after my advisor signs my thesis. :)

:)

> How do you manage memory across the OCaml and C worlds? (Actually, OCaml has
> added some ugliness to the language to make interfacing with C
> easier.. that's why "structs/records" are so "ugly") Python and Perl have
> "SWIG" (http://www.swig.org/Doc1.1/HTML/Contents.html) perhaps, someone shoud
> write an OCaml backend for SWIG...

CamlIDL is ok, I think. (It would surely not hurt to have SWIG, too...)

If you want to have an example:

---- file: Makefile ----------------------------------------------------
SOURCES = test_impl.c test.idl main.ml
RESULT = main
-include OcamlMakefile

---- file: main.ml -----------------------------------------------------
print_endline (Test.f ())

---- file: test.idl ----------------------------------------------------
[string] char * f ();

---- file: test_impl.c -------------------------------------------------
char * f () { return "This is a test!"; }

In case you use my OcamlMakefile (I know you hate Makefiles), you only need to
write 6 lines of code (including the three lines in the Makefile) to have a
complete and working example for interfacing OCaml and C. Producing byte- or
native code, for debugging or profiling (or even as library) just requires two
words on the command line. I can't imagine making it any simpler than this - so
really, interfacing C and OCaml can be done with extremely little effort.

Markus Mottl

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Michael Schuerig <schu...@acm.org> wrote:
> Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
>> Daniel Ortmann <ort...@us.ibm.com> wrote:
>> > From my own perspective O'Caml is definately more intimidating than Python.
>> > More powerful certainly! But I will admit that I am still stumbling and
>> > bumbling in O'Caml. :-/
>>
>> Using poweful concepts wisely is a matter of training.

> How many well-trained software developers have you met in the software
> industry?

Uhm, well, not too many (but some). However, I often have the impression that
it is teaching that causes this problem - not so much possible individual
shortcomings. Industry also does not have any idea how to change this. They are
probably not even aware...

Anyway, as I also said in my former article, even leaving away powerful extras
in FPLs and just keeping the core language still leaves you with a pretty
expressive language: you need not know everything for a good start.

Hartmann Schaffer

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
In article <8n1kqg$toq$5...@bird.wu-wien.ac.at>,

Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
>> 1. Writing and HTML parser or IMAP interface in you favorite FPL
>> doesn't demonstrate how useful new fancy language feature X is.
>
> There are libraries for such applications around - only "non-standard". I am
> getting succeedingly convinced that only the latter is the real problem.

it is very hard (at least for me) to think of the python and perl as
"standard". the point is that both python and perl exist in one
implementation only, so all library contributions go to that
implementation. otoh, there is a plethora of functional languages,
so there is lots of duplication of effort going into their libraries,
as well as many libraries not being universally available, i. e. a
contribution to the haskell library doesn't help anybody using ocaml,
clean, mercuru, or erlang.

i think the main reason for perl's and python's popularity is very
similar to why pascal was so popular in the 70s and early 80s:

1. cheap
2. easy to get to run in almost any environment (where you have a C
compiler)
3. solved a very widespread problem
4. pretty easy to use (in perl's case to write applications, but not,
imo, to read and maintain the code)

(btw, the order of theses points is strictly random), not that they
had any language design that made them inherently superior to existing
languages.

> ...

i also think that a big aspect of why fp languages have such a hard
time getting accepted is that most of the come with teaching material
that is rather formal (mathematical) which for some reason that is
beyond my comprehension seems to turn off quite a number of potential users.

--

Hartmann Schaffer


Neel Krishnaswami

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:

> James Hague <jam...@volition-inc.com> wrote:
>
> You probably mean something less safe than polymorphic variants. Here an
> example of how they work:
>
> [snip]

>
> Can Python do this for you?

Of course not, no more than Scheme or Lisp can do this. But then,
it won't do this, either:

neelk@brick:~ > sml
Standard ML of New Jersey, Version 110.0.6, October 31, 1999
[CM; autoload enabled]
- fun id x = x;
val id = fn : 'a -> 'a
- fun pair a b = (a,b);
val pair = fn : 'a -> 'b -> 'a * 'b
- pair id id;
stdIn:19.1-19.11 Warning: type vars not generalized because of
value restriction are instantiated to dummy types (X1,X2,...)
val it = (fn,fn) : (?.X1 -> ?.X1) * (?.X2 -> ?.X2)

Ocaml and Haskell both type this ok, but both of them still can't type
all expressions that work in dynamically-typed languages. That's just
life -- I can't statically typecheck Lisp, but I can't hack the MOP in
a statically typed language, either.


Neel

Christopher Browne

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Centuries ago, Nostradamus foresaw a time when Jordan Henderson would say:
>In article <399356ad...@nospam.usenet.volition.net>,

>James Hague <jam...@volition-inc.com> wrote:
>>In one of the prior "Why hasn't functional programming caught on?"
>>discussions I presented this theory in an offhand way, but I'm
>>starting to think there's much to it.
>>
>>Python provides many of the features that make FP languages more
>>productive than, say, C:
>>
>>* garbage collection
>>* lists & tuples
>>* higher-order functions such as map and filter
>>* low syntactic overhead
>>* easy manipulation of complex data structures

>>
>>At the same time, there's no attempt to throw out or steer the user
>>away from:
>>
>>* general hash tables
>>* updatable arrays
>>* side effects and updatable variables
>>* OOP features

>>
>
>Without getting into a language war (but, if we are, you
>started it :-)), you are, to a large extent describing
>Perl above also. I'm sure one could argue about the
>'low syntactic overhead' or 'easy manipulation of complex
>data structures'.
>
>Perl has also been described as being similar to Lisp.

The parallels to Common Lisp are likely uncomfortable from both sides.

>Perl has closures (anonymous subroutines). I'm not sure
>that Python does...

Python does, in the form of lambda forms.
<http://rts.ncst.ernet.in/python/tut/lambda.html>

def make_incrementor(n):
return lambda x, incr=n: x+incr

>And, if you are trying to make the argument that functional
>programming has caught on in other guises, I think you
>could use Perl as an example. Perl has certainly 'caught on'.
>

>>Some of the stickier FP concepts have been dropped:
>>

>>* currying


>>* formal type systems and type inference

>>* emphasis on recursion


>>
>>In a way, Python is providing a majority of the benefits of FP, but
>>without the academic fussing. http://www.norvig.com/python-lisp.html
>>is a good page that shows that the great similarities between Lisp and
>>Python, from the point of view of a Lisp expert.
>>

>>In a way it seems that FP has triumphed, as many always thought it
>>would, but maybe not in the way that was expected. The best of the FP
>>concepts have been merged with the best of the imperative concepts.

>>Thoughts?
>>
>
>I can't speak for the FP experts, not being one myself, but I believe
>that those 'stickier FP concepts' that you refer to as 'academic
>fussing' are _exactly_ those things that FP advocates feel are
>the best things about FP languages.
>
>Without exactly these concepts, you make reasoning about programs
>much more difficult. Powerful ideas like reverse exececution
>are also much more difficult in the presence of side effects.
>Type inference and formal type systems are widely regarded as
>one of the truly new and powerful ideas to come along in languages
>in the last 20 years.
>
>In any case, there is a language that maintains all the positive
>benefits you ascribe to Python that also has currying, formal type
>systems and type inference and an emphasis on recursion. That
>language is Ocaml. As you can program in an imperative style
>in Ocaml, giving you pretty much everything that Python has, I'd
>ask you why Ocaml is not more popular.
>
>I personally think it's a bias among working programmers against
>'academic' languages. When powerful FP concepts sneak in under
>the guise of a new 'scripting' language like Python, these working
>programmers will accept them because they don't realize that they
>are doing things in a way that is more like these 'academic'
>languages they like to deride.

One of the barriers to the popularity of a language is the
unavailability of good books.

Perl became particularly popular upon the widespread availability of
O'Reilly's "Programming Perl."

Python became more popular upon the availability of O'Reilly's
"Programming Python."

As luck would have it, I have, in my hand, O'Reilly's "Developpement
d'applications avec Objective CAML." It looks like a very worthy
"family member," albeit not being written in English.

If you read French, buy it! :-).
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.hex.net/~cbbrowne/languages.html>
42

Neel Krishnaswami

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Edward Jason Riedy <e...@lotus.CS.Berkeley.EDU> wrote:
>
> Jason, wondering who will win the race to re-invent CL...

Probably OCaml.

It has already grown an object system, functions with keyword
arguments, and the moral equivalent of a macro system (OCamlP4). All
on top of the nice ML-style features of pattern matching and
parameterized modules. All it needs is for the object system to sprout
multimethodsand maybe first-class continuations (or does it already
have them?) and it will have become some kind of strongly-typed
Lisp. :)


Neel

Markus Mottl

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Neel Krishnaswami <ne...@brick.cswv.com> wrote:
> - pair id id;
> stdIn:19.1-19.11 Warning: type vars not generalized because of
> value restriction are instantiated to dummy types (X1,X2,...)
> val it = (fn,fn) : (?.X1 -> ?.X1) * (?.X2 -> ?.X2)

> Ocaml and Haskell both type this ok, but both of them still can't type
> all expressions that work in dynamically-typed languages.

The upper message is just a warning - Ocaml, too, cannot generalize the type
variables (this would be unsound).

It's clear that Haskell doesn't have any problems with this, because it is
pure. The problem with generalization is that impure things like e.g.
references may cause problems as in:

let id x = x
let id_ref = ref id

If "id_ref" were fully generalized, you could put other functions into the
reference that are not as general as "id". Applying the contents (the function)
of the reference could crash your program then (-> unsound).

However, it is *very* rare that you have to handle such cases! Even in
dynamically typed languages such constructions are hardly used (because they
are potentially dangerous).

> That's just life -- I can't statically typecheck Lisp, but I can't hack the
> MOP in a statically typed language, either.

The upper thing is not a "shortcoming" (though it may be annoying): it just
prevents you from introducing serious bugs! You cannot blame the system for not
allowing potentially unsound things just to allow you a few unimportant special
cases, around which you get easily.

I agree that there are cases in which the programmer "knows what he is doing".
Even hand-written, self-modifying assembler programs can be correct. But one of
the reasons to have static typing is "Do not trust the programmer!". This may
be against our ego, but I have to admit that the compiler is well-advised to at
least not trust my programs...

Markus Mottl

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Hartmann Schaffer <hs> wrote:
[snip]

> otoh, there is a plethora of functional languages, so there is lots of
> duplication of effort going into their libraries, as well as many
> libraries not being universally available, i. e. a contribution to the
> haskell library doesn't help anybody using ocaml, clean, mercuru, or
> erlang.

I do not know how to quantify the duplication of work: it may be a problem
for languages that are relatively similar (OCaml and SML; LISP and
Scheme). Still, some languages just differ too much to merge
implementation efforts (lazy and pure vs. strict and impure).

> i think the main reason for perl's and python's popularity is very
> similar to why pascal was so popular in the 70s and early 80s:

> 1. cheap

This is also the case for nearly all functional languages around (maybe
not to 100% for Clean, which is only free for non-commercial use - what a
mistake!).

> 2. easy to get to run in almost any environment (where you have a C
> compiler)

Most FPL implementations probably cover > 95% of all environments. This
should also not be a problem. In fact, I'd say that this would rather
favor at least some FPLs (OCaml, for sure) which can also produce native
code for nearly every platform.

> 3. solved a very widespread problem

This may be a reason: functional languages were definitely not developed
(hence, used) for generating web pages and the like. Although they are
surely equally (better?) capable of this task, they probably missed to
enter the "internet game" in time. Now it is difficult to compete with
languages that already have tons of libraries around. Legacy software has
a strong momentum...

> 4. pretty easy to use (in perl's case to write applications, but not,
> imo, to read and maintain the code)

Probably due to "3" (incl. the library problem). Most people wouldn't know
how to write low-level libraries: they just want to use existing software.
This is what makes Perl "easy".

> i also think that a big aspect of why fp languages have such a hard
> time getting accepted is that most of the come with teaching material
> that is rather formal (mathematical) which for some reason that is
> beyond my comprehension seems to turn off quite a number of potential users.

FPLs have been mostly developed in academic environments. It is clear that
this leads to a different approach to documenting systems / writing
tutorials: it addresses more formal than practical issues.

I think that this situation is about to change: there are already some
books on FPLs around that address more "earthly" demands, that explain how
to do graphics and multimedia, develope client/server applications, etc.

Although the current situation is still bad IMHO, I am still confident
that it continuous improving, even if it can take a very long time.
Technological advances normally don't vanish easily...

Edward Avis

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:

>>IMHO the single most useful library for any FP would be a general
>>interface to Perl modules, so that people can use CPAN ('the world's
>>largest repository of reusable software').

>Why should this be helpful? There is no reason for using an FPL if you only


>want to do a few library calls in some scripting language (which is probably,
>what suffices for most people).

I've often written things in Perl and thought, 'I wish I could write
this in Haskell, but then I wouldn't be able to use modules X, Y, and
Z'. Maybe 'serious development' of large applications is more
important than scripting. But scripting seems to be what everybody
does these days.

>In fact, you can easily use already existing scripting languages from
>within FPLs by just generating code on the fly (FPLs are very adept
>in synthesizing programs) and use sockets to communicate with the
>interpreter. No big deal...

That sounds utterly gross, but I'll have to give it a try sometime.

>>But IMHO, interfaces from FP to high-level imperative languages are
>>much more important than from FP to C (at this time).
>
>The reason for interoperability with C is that there are *fast*
>libraries, which are not so easily replicable, even if some modern
>FPL implementations come fairly close. It may be a terrible effort to
>port old and mature C-libraries (e.g. numerical ones) without
>introducing bugs.

It's also a terrible effort to port _anything_ where an implementation
already exists. But I'm probably barking up the wrong tree suggesting
an interface from Haskell to Python, Erlang to Perl or whatever. It
would probably be better to concentrate on making libraries into CORBA
or COM components.

I guess I'm just frustrated seeing all that code there and not being
able to use it :-(

--
Ed Avis
ep...@doc.ic.ac.uk

Edward Avis

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:

>Maybe one should try to get the libraries elaborate enough to
>have a critical mass for this effect. I think it could work...

Pick a language, say Haskell for the sake of argument. What's needed
is something like Perl's CPAN (or Python's equivalent) and an easy way
to compile, install and upgrade 'modules'. This is non-trivial since
many modules will be interfaces to libraries written in C or some
other language.

Then the most important step is to stick most of these modules into
some kind of standard distribution (of hugs or whatever) and have an
online help system that lets you quickly find the one you need.

IMHO of course.

--
Ed Avis
ep...@doc.ic.ac.uk

Edward Avis

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
h...@inferno.nirvananet (Hartmann Schaffer) writes:

>>> 1. Writing and HTML parser or IMAP interface in you favorite FPL
>>> doesn't demonstrate how useful new fancy language feature X is.
>>
>>There are libraries for such applications around - only
>>"non-standard". I am getting succeedingly convinced that only the
>>latter is the real problem.
>
>it is very hard (at least for me) to think of the python and perl as
>"standard". the point is that both python and perl exist in one
>implementation only, so all library contributions go to that
>implementation.

You could consider this cheating, but for the end user the effect is
one distribution that contains (almost) everything you'll ever need,
rather than having to fetch different things from various Web pages.
I know which I prefer.

Something like CPAN to organize those things which aren't in the main
distribution is also very handy. Or to take examples outside
programming languages, TeX's CTAN, XEmacs's package system, or the
'contrib' area of Linux distributions.

>otoh, there is a plethora of functional languages,
>so there is lots of duplication of effort going into their libraries,
>as well as many libraries not being universally available, i. e. a
>contribution to the haskell library doesn't help anybody using ocaml,
>clean, mercuru, or erlang.

I wonder how hard it would be to interface some of these languages, at
least well enough to get basic libraries working, if not more whizzy
and advanced stuff?

For imperative languages you can make everything into a CORBA
component, but it seems to me that IDL is biased towards describing
imperative interfaces and doesn't work so well with laziness. (Please
correct me if I'm wrong.)



>i think the main reason for perl's and python's popularity is very
>similar to why pascal was so popular in the 70s and early 80s:
>
>1. cheap

>2. easy to get to run in almost any environment (where you have a C
> compiler)

>3. solved a very widespread problem

>4. pretty easy to use (in perl's case to write applications, but not,
> imo, to read and maintain the code)

Not so much easy to use as 'easy to start learning, and easy to keep
learning' (one of Perl's mottoes). Functional languages are usually
easy at first, but as soon as you want to do IO in Haskell you're
confronted with monads, which is a little off-putting.



>i also think that a big aspect of why fp languages have such a hard
>time getting accepted is that most of the come with teaching material
>that is rather formal (mathematical) which for some reason that is
>beyond my comprehension seems to turn off quite a number of potential
>users.

Yep. I wouldn't propose a 'Standard ML for Dummies' approach, but
material that is a little more task-oriented and assumes some
existing knowledge of programming would be helpful. I don't intend to
rant about Perl all the time, but the best books for that language
(read: published by ORA) are a good model to follow. In particular
they emphasize the standard libraries just as much as any particular
language feature - and I think we've established that solid,
wide-ranging libraries are more important than technical perfection in
the language itself.

A 'Reasonably Quick Guide to Haskell and its Libraries' plus the 'Big
Book of All the Haskell Code That's Out There and How to Use It' would
do nicely :-)

--
Ed Avis
ep...@doc.ic.ac.uk

Edward Avis

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
cbbr...@news.hex.net (Christopher Browne) writes:

>>Perl has closures (anonymous subroutines). I'm not sure
>>that Python does...
>
>Python does, in the form of lambda forms.
><http://rts.ncst.ernet.in/python/tut/lambda.html>

Not true closures since you can't create a 'bubble' of scope to access
the variables that were in scope when the closure was created.

>def make_incrementor(n):
> return lambda x, incr=n: x+incr

Yes, that's the best you can do - use default parameters. But it's
not the same.

--
Ed Avis
ep...@doc.ic.ac.uk

Markus Mottl

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Edward Avis <ep...@doc.ic.ac.uk> wrote:
> I've often written things in Perl and thought, 'I wish I could write
> this in Haskell, but then I wouldn't be able to use modules X, Y, and
> Z'. Maybe 'serious development' of large applications is more
> important than scripting. But scripting seems to be what everybody
> does these days.

It would probably be more advisable then to invest more effort into scripting
libraries. I think these are much easier to write than some complicated and
probably always incomplete language interfaces. But it's lots of work and maybe
not so fascinating...

>>In fact, you can easily use already existing scripting languages from
>>within FPLs by just generating code on the fly (FPLs are very adept
>>in synthesizing programs) and use sockets to communicate with the
>>interpreter. No big deal...

> That sounds utterly gross, but I'll have to give it a try sometime.

Indeed, when I look at Perl programs, many of them seem to call external
programs to do stuff. E.g.:

PERL:

open DATE, "date|";
$date = <DATE>;
print $date

OCAML:

let date_ic = Unix.open_process_in "date" in
let date = input_line date_ic in
print_endline date

Looks a bit more work, but it would be fairly easy to replicate the use of
"date|" or have an operator for reading from channels (<DATE>) or use "print"
instead of "print_endline", e.g.:

Use definitions like:

let perl_open name =
let last = String.length name - 1 in
if name.[last] = '|' then
Unix.open_process_in (String.sub name 0 last)
else open_in name

let (?<) = input_line
let print = print_endline

And write:

let date_ic = perl_open "date|" in
print (?< date_ic)

(though, I prefer "input_line" for maintainance reasons)

One could even go about beating Perl in obscurity and define:

let (>>) x f = f x

to do

perl_open "date|" >> input_line >> print

As can be shown, there is hardly any argument for using Perl (brevity,
whatever): one can write as short (and possibly cryptic) code in an FPL - but
at much higher safety.

> It's also a terrible effort to port _anything_ where an implementation
> already exists.

Well, surely some things are much more difficult to port correctly than others.

> But I'm probably barking up the wrong tree suggesting an interface from

> Haskell to Python, Erlang to Perl or whatever. It would probably be better


> to concentrate on making libraries into CORBA or COM components.

There are already tools for supporting this - I think most major FPL
implementations feature some. It's just that there are (still) not enough
people to use them...

Nick Williams

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
In article <xn9lmy2...@texel06.doc.ic.ac.uk>,
Edward Avis <ep...@doc.ic.ac.uk> wrote:

>Not so much easy to use as 'easy to start learning, and easy to keep
>learning' (one of Perl's mottoes). Functional languages are usually
>easy at first, but as soon as you want to do IO in Haskell you're
>confronted with monads, which is a little off-putting.

I don't actually see the use of the IO monad as particularly
offputting; contrast this with having a strong conceptual
understanding of the whys and wherefores of monads in general.

I mean, with the syntactic sugar that Haskell provides for
monads, as long as you have a reasonable grasp of the type
system, the IO monad is not hard to use.

I did a reasonable amount of functional programming with
'canned' main functions etc. before I bothered to learn about
monads. It doesn't take very much intelligence to have an
intuitive grasp of what this does:

main = do
x1 <- readLn
x2 <- readLn
putStr (show(x1)++" times "++show(x2)++" is "++show(x1*x2)++"\n")

At this point, I decided to write the same program in Java. I
don't think I can be bothered to post the result here, but it
required the use (if not comprehension) of exception handling,
class visibility modifiers, static class variables and a load of
other things.

What I'm attempting to get at is, it's not that important for a
beginning Java user who writes:

System.out.println("Hello world");

to know that System is a class in the package java.lang, which
has a static class variable called out, which is an instance of
PrintStream, defined in java.io, which has a method called
println, which is overloaded for 9 different types, one of which
is String.

Similarly, the beginning Haskell user need not know about the
category theoretical aspects of monads.

Cheers,

Nick.

--

[ Nick Williams ]
[ MSc Computation Mobile - 07957-138179 ]
[ New College, Oxford http://www.new.ox.ac.uk/~nick/ ]

graham

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Christopher Browne at cbbr...@news.hex.net wrote on 8/11/00 9:57 PM:

>> Perl has closures (anonymous subroutines). I'm not sure
>> that Python does...
>
> Python does, in the form of lambda forms.
> <http://rts.ncst.ernet.in/python/tut/lambda.html>
>
> def make_incrementor(n):
> return lambda x, incr=n: x+incr

I don't know about you but since closures aren't automatic I don't
consider it fair to say that "Python has closures". After all I
could claim that C and even assembler "have closures" since a
programmer can create them in such languages as well.

Clearly YMMV.

graham

Markus Mottl

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Nick Williams <ni...@thelonious.new.ox.ac.uk> wrote:
> At this point, I decided to write the same program in Java. I
> don't think I can be bothered to post the result here, but it
> required the use (if not comprehension) of exception handling,
> class visibility modifiers, static class variables and a load of
> other things.

Many people from the "imperative" world are biased against functional
programming for exactly this reason: they just don't see the complexity of
their languages, which is generally far beyond anything you'd find in the
functional or logic world.

The moment when I switched from C++ to FPLs was the one when I realized,
how much time a had actually invested in understanding this monster - a
complete waste, considering that I can do more things better in FPLs than
in C++, even though I had spent less than a third of the time on learning
the new paradigm.

Just recently a colleague (a programming newbie) asked me things about
Java: his questions showed pretty well that this language is *not* as easy
to learn as most people think. It took me quite a while to explain to him
what "static" member functions are. Indeed, knowing about such issues is
mandatory even for small Java-projects!

In the case of Haskell, for example, a hint like "just treat it as
mathematical equations" comes pretty close to what this language is about.
Unfortunately, people are afraid that this "maths may be difficult" - and
start learning languages that are more difficult to handle by an order of
magnitude. It would be nice if schools could teach students a positive
image of maths (helps solve problems in an elegant and understandable
way)...

Hartmann Schaffer

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
In article <xn9lmy2...@texel06.doc.ic.ac.uk>,
Edward Avis <ep...@doc.ic.ac.uk> writes:
> ...

>>it is very hard (at least for me) to think of the python and perl as
>>"standard". the point is that both python and perl exist in one
>>implementation only, so all library contributions go to that
>>implementation.
>
> You could consider this cheating, but for the end user the effect is

i didn't say anything about cheating. i was only expressing my
reservations for using the term standard for python and C libraries.
after all the purpose of standards is to establish some kind of
similarity or interoperabbility between different products.

> one distribution that contains (almost) everything you'll ever need,
> rather than having to fetch different things from various Web pages.
> I know which I prefer.

that isn't the problem i was referring to: the point is you can get a
python or perl library from anywhere, and it will work with the
language you are using, since there is only one implementation of each
(disregarding version incompatibilities and new developments like
jpython), while on the other hand you can put all libraries for
functional languages on one central site, and you won't get a haskell
library that works with ocaml or scheme or erlang.

> ...


> I wonder how hard it would be to interface some of these languages, at
> least well enough to get basic libraries working, if not more whizzy
> and advanced stuff?

not very

> ...

--

Hartmann Schaffer


Edward Avis

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
ni...@thelonious.new.ox.ac.uk (Nick Williams) writes:

>>Functional languages are usually
>>easy at first, but as soon as you want to do IO in Haskell you're
>>confronted with monads, which is a little off-putting.
>
>I don't actually see the use of the IO monad as particularly
>offputting; contrast this with having a strong conceptual
>understanding of the whys and wherefores of monads in general.

This subject has often been discussed, let me just briefly say that
the explanations I found were either too superficial and made it look
like magic (Haskell: the craft of functional programming) or too
focussed on 'monads in general' with little or no mention of their use
for IO (everything else).

I know the situation has improved since then.

--
Ed Avis
ep...@doc.ic.ac.uk

K.J. Seefried

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
On 11 Aug 2000 19:40:00 GMT, Markus Mottl <mo...@miss.wu-wien.ac.at>
wrote:

>Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
>

>There are libraries for such applications around - only "non-standard". I am
>getting succeedingly convinced that only the latter is the real problem.
>

I agree.

>
>> 3. Lack a of critical mass of hackers writing libraries
>> for moving target languages and implementations.
>
>Please help contributing! :-)
>

Chicken and Egg. How do you push the status quo to reach critical
mass?

>
>> 9. FPLs don't have good tutorials
>
>You think that tutorials of other languages are really any better?
>

Yes, absolutely. Go to a bookshelf in a good nerd bookstore (like
Engineers Bookstore @ Marietta St. @ Georgia Tech). There will be
multiple shelves of tutorials on C, C++, Java, etc., etc. Probably
20% of those books are quite useful, which yields a number of good
books. Look for a book on Lisp. There will be Steele, of course, and
maybe 3-5 others. While there are always one or two FPL tomes, ML,
Haskell, et al., are usually confined to a chapter in a comparative
languages textbook. Last time I was there, there were more Cobol
books than FPL books; there were even more Ada books than FPL books
(GaTech does a lot of DoD contracts, so maybe there is less interest
in Ada elsewhere).

I learned Lisp and ML from net tutorials. It was painful, and I still
generally feel clueless flailing around in these languages. It may be
me, or it may be that my learning doesn't mesh with the pedagogical
style of the small number of authors producing instruction in these
languages. That's the thing about learning C or C++: if one learning
style doesn't suit you, there are 50 other books with a different
educational style to choose from.

>
>This does not correspond to my experience when I learnt
>FPLs - from tutorials.
>

It does to mine.

>
>> 10. FPLs don't solve a particular "niche problem space" other than
>> bootstraping compilers for FPLs... and the occasional theorem prover.
>
>This statement can be easily dismissed: there is probably no FPL around that
>doesn't have "interesting" commercial or other "non-theoretical" applications
>(though, the quantity may be low - because they are not used too often in
>general, even less in the commercial sector).
>
>Given that people have implemented Quake in Haskell, switching software in
>Erlang and Genealogy software in OCaml, one could not say that these languages
>don't have widespread applicability.
>

Not only is the quantity low, it's vanishingly low. Quake in Haskell?
Quaint, probably relatively slow, and generally useless (esp. now that
Quake III is out!). Erlang? Very interesting language, but who uses
it save Ericsson? Genealogy in OCaml? Probably useful to someone,
but will I see it at CompUSA? A single (or small number of)
application written in a given language do not prove, as you
characterize, "widespread applicability".

I think this is really the crux of the issue. As long as nontrivial
FPL applications "are not used too often in general, even less in the
commercial sector", as you say, they will generate little interest
beyond academes and tinkerers. It's hubris to think otherwise.

I think the point of the original author is that the FPL community
isn't interested in the kinds of things that make a language
successful for the rank-and-file developer. That's not necessarily
bad. However, if the FPL community could get behind one or two
languages, push them as mainstream, integrate them with familiar
development paradigms (where possible and applicable) & educate
developers on the type of problems they are uniquely suited to solve,
they might see more activity in the "Real World".

That's my soapbox. I might be wrong.

- Ken Seefried, CTO & Founding Partner, DigitalMoJo


Suchandra Thapa

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
James Hague <jam...@volition-inc.com> wrote:
>In one of the prior "Why hasn't functional programming caught on?"
>discussions I presented this theory in an offhand way, but I'm
>starting to think there's much to it.
>
>Python provides many of the features that make FP languages more
>productive than, say, C:
>
>* garbage collection
>* lists & tuples
>* higher-order functions such as map and filter
>* low syntactic overhead
>* easy manipulation of complex data structures

Python's garbage collection is just reference counting at the moment
although later versions will replace it with a better method. As an aside,
the next version of python should add a zip operator ala Haskell and there's
a patch right now that adds continuations to python (whether this will be
in the official implemention is being debated).


--
------------------------------------------------------------------

Suchandra S. Thapa
s-t...@NOspam.uchicago.edu

------------------------------------------------------------------

K.J. Seefried

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
On 12 Aug 2000 12:21:44 +0100, Edward Avis <ep...@doc.ic.ac.uk> wrote:

>h...@inferno.nirvananet (Hartmann Schaffer) writes:
>
>>i also think that a big aspect of why fp languages have such a hard
>>time getting accepted is that most of the come with teaching material
>>that is rather formal (mathematical) which for some reason that is
>>beyond my comprehension seems to turn off quite a number of potential
>>users.
>

Not sure why this is beyond comprehension. Most programmers aren't
educated in the theoretical background required to make these
tutorials accessible. That may very well be a sin against the gods of
programming, but I find it to be true (as someone who has hired more
than my share of programmers).

>Yep. I wouldn't propose a 'Standard ML for Dummies' approach,

Well...maybe not "dummies", but "Standard ML for Programmers without a
Graduate Degree" or "Standard ML for Recovering C++ Programmers"
might not be a bad thing. Better might be "FPLs For Programming
Project Managers and Why It Will Get You Promoted".

>but material that is a little more task-oriented and assumes some
>existing knowledge of programming would be helpful.

Exactly. Non-academic. Pedestrian. Plebian. Unwashed masses and
all that.

>I don't intend to rant about Perl all the time,

Rant about Perl all day long, for some reason it's hideously
successful by many measures.

>but the best books for that language
>(read: published by ORA) are a good model to follow.

I was thinking the same thing. The O'Reilly folks are wonderful,
insightful and easy to deal with. I'm convinced that a big part of
Perls success is the excellent doco that ORA provides.

I'd love to see someone do a highly practical FPL book with ORA,
something like Practiacl Standard ML Programming on Linux, or some
such. Any takers?

>A 'Reasonably Quick Guide to Haskell and its Libraries' plus the 'Big
>Book of All the Haskell Code That's Out There and How to Use It' would
>do nicely :-)

That works, too. If anyone volunteers to write it, I'll be the first
to call Tim O'Reilly and beg him to publish it.

Markus Mottl

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
K.J. Seefried <ksee...@digitalmojo.com> wrote:
> I'd love to see someone do a highly practical FPL book with ORA,
> something like Practiacl Standard ML Programming on Linux, or some
> such. Any takers?

If you (we) are lucky, the French OCaml book (which is indeed practical -
networking, graphics, ...) will be translated to English soon, and ORA
will *maybe* (especially if many, many of you tell ORA that you cannot
live without it) publish it, too...

graham

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
K.J. Seefried at ksee...@digitalmojo.com wrote on 8/12/00 5:31 PM:

> I learned Lisp and ML from net tutorials. It was painful, and I still
> generally feel clueless flailing around in these languages. It may be
> me, or it may be that my learning doesn't mesh with the pedagogical
> style of the small number of authors producing instruction in these
> languages. That's the thing about learning C or C++: if one learning
> style doesn't suit you, there are 50 other books with a different
> educational style to choose from.

I must admit that I have to concur with KJ here. The number and quality of
books and tutorials on FPLs is dreadfully low. I know a fair bit about
functional languages -- I use them everyday, I am undertaking some fairly
major and complicated tasks in them, and I am working on a JVM
implementation of one -- and yet I still find a lot of the instructional
material on functional languages hard to read, especially when it comes
to the "big" issues of type theory (including monads).

K.J. Seefried at ksee...@digitalmojo.com wrote on 8/12/00 5:31 PM:


> I think this is really the crux of the issue. As long as nontrivial
> FPL applications "are not used too often in general, even less in the
> commercial sector", as you say, they will generate little interest
> beyond academes and tinkerers. It's hubris to think otherwise.

Again I have to concur to some degree. There are some serious applications
written in functional/semi-functional languages, for example the Erlang
work. But most of the other applications for which people are using
functional languages are compilers and theorem provers. These are surely
"non-trivial", however they are also a certain style of application
that is well suited to functional languages. Their existence does
*not* show the widespread applicability of functional languages, rather
it shows they are good for certain niche things (I do believe fpls
are widely applicable, but the current crop of applications don't
demonstrate that).

K.J. Seefried at ksee...@digitalmojo.com wrote on 8/12/00 5:31 PM:


> I think the point of the original author is that the FPL community
> isn't interested in the kinds of things that make a language
> successful for the rank-and-file developer. That's not necessarily
> bad. However, if the FPL community could get behind one or two
> languages, push them as mainstream, integrate them with familiar
> development paradigms (where possible and applicable) & educate
> developers on the type of problems they are uniquely suited to solve,
> they might see more activity in the "Real World".

BUT ... the problem is that researchers are neither funded nor promoted
based on the kind of things you outline above. They are funded to do
research, and "integration with the mainstream" is not covered under
the banner of research.

graham


Jordan Henderson

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
Markus,

Do you have a contact at ORA that we can lobby to publish the
translated work? I'd buy it in a heartbeat, but I can imagine
that an email sent to some sales address at ora.com might not
get routed correctly to the people who might actually help.

I guess I could always send email to Tim O'Reilly... :-)

In article <8n4oai$aco$1...@bird.wu-wien.ac.at>,

-Jordan Henderson
jor...@greenapple.com

graham

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
K.J. Seefried at ksee...@digitalmojo.com wrote on 8/12/00 9:49 PM:
<grah...@telocity.com>

>> BUT ... the problem is that researchers are neither funded nor promoted
>> based on the kind of things you outline above. They are funded to do
>> research, and "integration with the mainstream" is not covered under
>> the banner of research.
> Well put, and completely accurate.
>
> Q: What takes a language from academia to mainstream acceptance?

This is a difficult question. Mainly luck would be my guess. But I think
you can mitigate against the "luck" factor a little bit by chosing a niche
in which to promote your language, and then try to dominate that niche.
Once you are dominant you can spread to other areas. The problem is
chosing the niche. It must be specialised/small enough that you can
dominate it, but large enough that once you do dominate there are
enough momentum to help you expand outside the niche. Also the niche
must be buzzwordy enough to gain acceptance by those that fund research
as a legitimate area of research. Some examples:

a) theorem proving -- too small.
b) compilers -- too small.
c) scripting languages -- too big (already dominated by others).
d) AI -- dominated by Lisp, but too specialised.
e) telecoms applications -- Erlang is making a good try here, remains
to be seen if the niche is "right".

Any other suggestions?

graham


Hal Daume III

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
I've been monitoring this thread rather intently since I'm currently
hacking around at designing my own language (purely for my own interest
in languages and compilers). And I'm gonna go out on a limb here, but I
think someone will probably agree (I hope).

First off, I love FP. But I really think that there is one an only one
(albeit complicated) reason why FP hasn't caught on.

For some time, FP has pretty much been reserved to PhD students and
professors of CS, since these are the people who can see past the
"strange" syntax and see the beauty in the languages.

However, along with this, you find that many people are language
zealots. Not in the way that industry is (people refusing to use
anything other than pure C for any project), but people who think that
some language is "the language" as deemed by God, or whatever. "What?
C# doesn't have parameterized types? How can a new language not do
this?!" (of course, c# is far from fp :).)

And so you get this FP schism. Some people love SML (or OCaml) [this
would be me], some people love haskell, some people love erlang, etc.
Some people love other languages. And that's where they want to spend
their time and energy.

Hence, you have a hugely dissipated effort at the FP front (the analogy
to Sun pushing Java through everything is a very valid one). Not only
is there a lack of funding -- but there isn't even a "clear winner" in
the language race.

I would be willing to bet that if all (or most) of the FP loving
academics CHOSE a language and stuck by it, it could become as popular
as something like Java or as popular as ms would like C# to be. C# is
far from anything great (imho) but i have no doubt it will succeed
because MS will put all of it's great momentum behind the language and
MAKE it succeed.

Obviously there are other issue (mostly financial), but if people who
had their own little pet languages (myself included) concurred on a
language to work on and REALLY WORKED on it, I do believe it could
succeed.

Any thoughts?

- Hal

Brad Knotwell

unread,
Aug 12, 2000, 3:00:00 AM8/12/00
to
ne...@brick.cswv.com (Neel Krishnaswami) writes:
> Albert Y. C. Lai <tre...@vex.net> wrote:

> > sst...@midway.uchicago.edu (Suchandra Thapa) writes:
> >
> > > and there's a patch right now that adds continuations to python
> > > (whether this will be in the official implemention is being
> > > debated).
> >
> > I cannot resist but to ask why there is a debate at all.
> > Continuation has proven to be a useful and convenient tool, and
> > since there is already a patch providing it, the problem of
> > implementing it has disappeared. So what more could the con side
> > possibly say?
>
> The other main Python implementation, Jpython, runs on the JVM and
> continuations are apparently very hard to get working on it. Since
> there's a strong desire that programs remain easily portable between
> the two implementations, until a solution is found there will be
> controversy surrounding the addition of continuations to Python.

Per Bothner's kawa (a Scheme interpreter above the JVM) implements a limited
continuation model with full support for call/cc coming shortly.

> Neel

--Brad

Markus Mottl

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
K.J. Seefried <ksee...@digitalmojo.com> wrote:
>>> 9. FPLs don't have good tutorials
>>
>>You think that tutorials of other languages are really any better?

> Yes, absolutely. Go to a bookshelf in a good nerd bookstore (like
> Engineers Bookstore @ Marietta St. @ Georgia Tech).

Ah, sorry, for some reason I thought of online tutorials - some of the
FP-ones are indeed not bad at all.

> That's the thing about learning C or C++: if one learning style doesn't
> suit you, there are 50 other books with a different educational style to
> choose from.

I admit that tutorials that I find good may not necessarily be the ones
the general public likes...

> Not only is the quantity low, it's vanishingly low. Quake in Haskell?
> Quaint, probably relatively slow, and generally useless (esp. now that
> Quake III is out!). Erlang? Very interesting language, but who uses
> it save Ericsson? Genealogy in OCaml? Probably useful to someone,
> but will I see it at CompUSA? A single (or small number of)
> application written in a given language do not prove, as you
> characterize, "widespread applicability".

As I said: one can do interesting things in these languages, but nobody
does unless somebody does...

> I think the point of the original author is that the FPL community isn't
> interested in the kinds of things that make a language successful for
> the rank-and-file developer.

I'd say their focus is different. But over time, focus changes: the
"marginal utility" of (re-?)inventing the next 700 type systems won't be
so high anymore... - people will start improving other (more practical)
things. This is happening right now.

> That's not necessarily bad. However, if the FPL community could get
> behind one or two languages, push them as mainstream, integrate them
> with familiar development paradigms (where possible and applicable) &
> educate developers on the type of problems they are uniquely suited to
> solve, they might see more activity in the "Real World".

Currently, the "two" functional languages I'd like to see become
mainstream are Haskell and some kind of merger of OCaml and SML. Btw., has
anybody heard of ML2000 lately? - Cardelli's paper on it is already quite
old...

There are a few logic languages, too, which should definitely make it into
mainstream (e.g. Mercury; Oz; LambdaProlog looks very promising, too).

K.J. Seefried

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
On 13 Aug 2000 00:10:42 GMT, Markus Mottl <mo...@miss.wu-wien.ac.at>
wrote:

>K.J. Seefried <ksee...@digitalmojo.com> wrote:
>
>> I think the point of the original author is that the FPL community isn't
>> interested in the kinds of things that make a language successful for
>> the rank-and-file developer.
>
>I'd say their focus is different. But over time, focus changes: the
>"marginal utility" of (re-?)inventing the next 700 type systems won't be
>so high anymore... - people will start improving other (more practical)
>things. This is happening right now.
>

I see what you mean; I agree. Where do you see the improvements
coming these days?

In any case, the crux then becomes how does one position and advocate
FPL technology over competing technologies. It tends to fall back to
the point that I was (trying, anyway) to make, which was that the
value of FPLs need to be more accessable to more mainstream
programmers.

I'm quite sure that one day hell will be paved with C# programmers.

>
>Currently, the "two" functional languages I'd like to see become
>mainstream are Haskell and some kind of merger of OCaml and SML.
>

Interesting conjecture. I'm interested in Erlang because it has been
used in some industrial strength environments. SML makes a certain
kind of sense to me.

Have we decided if Lisp is a FPL, or at least close? Lisp can be an
awfully nice way of doing things.

>
>Btw., has anybody heard of ML2000 lately? - Cardelli's paper on it is already quite
>old...
>

Is that Lucia Cardelli of Olivetti Research Center & Modula-3 fame?
Really brilliant guy...

K.J. Seefried

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
On Sat, 12 Aug 2000 20:34:35 -0400, graham <grah...@telocity.com>
wrote:

>
>BUT ... the problem is that researchers are neither funded nor promoted
>based on the kind of things you outline above. They are funded to do
>research, and "integration with the mainstream" is not covered under
>the banner of research.
>

Well put, and completely accurate.

Q: What takes a language from academia to mainstream acceptance?

C & C++ came from a psuedo-academic environment, but had highly
practical goals. Pascal and it's kin came from academia, and where
specifically designed to teach programming. One can assume their
adoption came from familiarity. Basic, eww. Many others are strictly
business: RPG, PL/I, Cobol, Ada.

Why hasn't an FPL been deigned worthy of this status?

K.J. Seefried

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
On Sat, 12 Aug 2000 22:53:28 -0400, graham <grah...@telocity.com>
wrote:

>K.J. Seefried at ksee...@digitalmojo.com wrote on 8/12/00 9:49 PM:
>> Q: What takes a language from academia to mainstream acceptance?
>
>This is a difficult question. Mainly luck would be my guess.

Ouch. Not the answer I was hoping for.

>But I think
>you can mitigate against the "luck" factor a little bit by chosing a niche
>in which to promote your language, and then try to dominate that niche.

<Devils Advocate>

But what does one say to the nay-sayers who consider FPLs a niche in
and of itself? Remember: we are talking about the *marketing* of FPLs
as much as the espousing the virtues of them.

If these languages are as truly useful as this group portrays them to
be, then they should be able to hold their own in solving mainstream
programming problems. Prove that they are better for the average
programmer than C, Visual Basic, Delphi, etc.

</Devils Advocate>

>Also the niche
>must be buzzwordy enough to gain acceptance by those that fund research
>as a legitimate area of research.

I would concur...I might have a few suggestions for buzzwords.

>
>Some examples:
>
>a) theorem proving -- too small.
>b) compilers -- too small.
>c) scripting languages -- too big (already dominated by others).

Yup.

>d) AI -- dominated by Lisp, but too specialised.

I would say mindshare belongs to Lisp, with too few practical apps.
Any language that comes along with some really good AI-ish apps can
carve out a fair piece of the pie.

From my own experience, information security would be a great place to
use AI-ish pardigms,and break the "too specialized" mold. AI-ish log
file analysis? How about AI-ish intrusion detection systems, for
example? An AI-ish spam filter?

These are all interesting apps, poorly delt with by conventional
languages, with a huge market potential. And a subject close to my
heart...if you want to write one, please drop me a note...we would be
interested in funding it. :-)

I personally think this is an underexplored area.

>e) telecoms applications -- Erlang is making a good try here, remains
> to be seen if the niche is "right".

How could this *not* be right? Telco software is a polybillion dollar
industry that is growing more vital every day. Lesse: I'm going to
prove that my language provides fast development, vastly lower bug
count, ease of modification, high resiliency, on mission-critical
applications. 7x24x365. You add all the buzzwords I forgot.

We should be pushing Erlang and the Ericsson experience everywhere we
can, even if some dislike the language.

Peter Hancock

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
>>>>> "K" == K J Seefried <ksee...@digitalmojo.com> writes:

> Lesse: I'm going to
> prove that my language provides fast development, vastly lower bug
> count, ease of modification, high resiliency, on mission-critical
> applications. 7x24x365. You add all the buzzwords I forgot.

One often hears "7x24x365"; is it a joke? Or just another indication
that people aren't paying much attention to what they are saying?

--
Peter Hancock

Ortwin Gasper

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
graham <grah...@telocity.com> writes:


> Again I have to concur to some degree. There are some serious applications
> written in functional/semi-functional languages, for example the Erlang
> work. But most of the other applications for which people are using
> functional languages are compilers and theorem provers. These are surely
> "non-trivial", however they are also a certain style of application
> that is well suited to functional languages. Their existence does
> *not* show the widespread applicability of functional languages, rather
> it shows they are good for certain niche things (I do believe fpls
> are widely applicable, but the current crop of applications don't
> demonstrate that).

I think, there is a need for something like 'Java for FPL', an
optimizised human readable/writable target language for the backends
of FPLs with OS and GUI abstraction libraries. The main goal is
rapid development of reliable and portable applications with
acceptable performance. It doesn't matter, if the core of an application
can be written 6 times faster than in C, but the interface to the
outside world eats up this benefit.

Regards
Ortwin


Christopher Browne

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
Centuries ago, Nostradamus foresaw a time when Jordan Henderson would say:

>Do you have a contact at ORA that we can lobby to publish the
>translated work? I'd buy it in a heartbeat, but I can imagine
>that an email sent to some sales address at ora.com might not
>get routed correctly to the people who might actually help.

One component of this is to consider purchasing the French version,
if you read enough French for it to be useful. I just received a copy,
and am quite impressed with the book. Reading it in French means that I
can only absorb a few pages a day, but that's probably pretty fair...
--
cbbr...@hex.net - <http://www.ntlug.org/~cbbrowne/>
UNIX *is* user friendly. It's just selective about who its friends
are...

Markus Mottl

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
Jordan Henderson <jor...@lisa.gemair.com> wrote:
> Do you have a contact at ORA that we can lobby to publish the
> translated work? I'd buy it in a heartbeat, but I can imagine
> that an email sent to some sales address at ora.com might not
> get routed correctly to the people who might actually help.

Not any specific (personal) one: I wrote to <nu...@oreilly.com> (general
requests) once and got the reply that there are *currently* no intentions to
translate it to English. However, there is a volunteer effort happening right
now to translate the book. I don't know how long it will still take (probably
some time - the book is huge!), but if O'Reilly is pushed a bit, there might be
a good chance that they help and accept it.

In any case, it is important that people *ask* for such things! Unless ORA sees
any commercial advantage (and they are still a commerical company) in
publishing it, they will not get into the FPL book-market. They have to see
that there is demand!

> I guess I could always send email to Tim O'Reilly... :-)

The more e-mails, the better! :-)

Markus Mottl

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
Hal Daume III <h...@cmu.edu> wrote:
> I would be willing to bet that if all (or most) of the FP loving
> academics CHOSE a language and stuck by it, it could become as popular
> as something like Java or as popular as ms would like C# to be. C# is
> far from anything great (imho) but i have no doubt it will succeed
> because MS will put all of it's great momentum behind the language and
> MAKE it succeed.

> Obviously there are other issue (mostly financial), but if people who
> had their own little pet languages (myself included) concurred on a
> language to work on and REALLY WORKED on it, I do believe it could
> succeed.

It's surely not the languages that still require being "worked on":

The two major points are probably:

1) lack of libraries
2) split user base

If a handful (yes, handful would be enough) of people volunteered to implement
some of the "practical" libraries (simple mail, FTP, whatever - clients), this
would surely lead to 1) being eliminated fast.

What concerns 2): given the *huge* user base of most "practical" languages,
there doesn't seem to be any low limit to having several FPL implementations
around. However, we'd have to succeed to draw from this "resource". More
marketing (FPLs are practical) would be fine: this probably requires having
good books on it.

Markus Mottl

unread,
Aug 13, 2000, 3:00:00 AM8/13/00
to
K.J. Seefried <ksee...@digitalmojo.com> wrote:
> On 13 Aug 2000 00:10:42 GMT, Markus Mottl <mo...@miss.wu-wien.ac.at>
> wrote:
>>I'd say their focus is different. But over time, focus changes: the
>>"marginal utility" of (re-?)inventing the next 700 type systems won't be
>>so high anymore... - people will start improving other (more practical)
>>things. This is happening right now.

> I see what you mean; I agree. Where do you see the improvements
> coming these days?

If I take a look at recent additions to language implementations in terms
of libraries and maybe even features, I'd say that the direction is clear.
E.g., OCaml has very fully-fledged support for Tcl, but there is also an
already quite advanced implementation of GTK around. Or they have added
support for "Bigarrays" to manipulate very large arrays using memory
mapped files (something that some commercial companies may desperately
need). On the language side, the addition of labelled and default
arguments makes it much more useful for many practical applications.

To my knowledge, Haskell, too, has already a fair share of libraries
addressing practical problems (GUIs, etc.).

However, most libraries still address rather "serious problems". To get
FPLs going there should be more "easy stuff" around.

>>Btw., has anybody heard of ML2000 lately? - Cardelli's paper on it is already quite
>>old...

> Is that Lucia Cardelli of Olivetti Research Center & Modula-3 fame?
> Really brilliant guy...

You mean "Luca" Cardelli