FP and Python
Jordan Henderson
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
> 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
> 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
> 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
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
James Hague <jam...@volition-inc.com> wrote:
>>Perl has also been described as being similar to Lisp.
>
>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
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...
>
> 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
> Markus Mottl wrote:
>>What concerns type systems (btw., what is a "formal" type system - are
>>there informal ones?):
> 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
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
: 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".
:>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
> % 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
- * 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
> 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
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
> 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
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
> 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
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
> 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
> 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
>> 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.
>>
>> 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
> 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
> 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
>> 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
> James Hague <jam...@volition-inc.com> wrote:
>
> You probably mean something less safe than polymorphic variants. Here an
> example of how they work:
>
>
> 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
>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
>>* 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
>>
>
>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'.
>
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
>
> 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
> - 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
[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
>>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
>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
>>> 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
>>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
> 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
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
>> 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>
>
> 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
> 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
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
>>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
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
>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
>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
> 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
> 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
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
<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.
>
> 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
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
> 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).
> >
> > 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
>>> 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
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
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
wrote:
>
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
> 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
> 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
>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
> 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
> 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
> 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 - and he's working for the "evil empire" right
now... ;-)
See: http://www.luca.demon.co.uk
Yes, he has quite some nice papers online. Unfortunately, his rather old
paper on ML2000 seems to be the most recent one on this topic...
graham
> 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.
This will never happen for the simple reason that the people who develop
functional languages are researchers and researchers are paid and promoted
to develop "new and wonderful" things, rather than simply honing existing
things.
graham
graham
> 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.
>
> 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.
I disagree. First the real world doesn't want libraries that give you
"simple" mail, FTP, whatever clients. They want *fully featured* mail, FTP,
whatever clients. The real world is sick of prototypes X's being written
in functional languages, they want fully featured X's. That is the reality!
To make these kinds of libraries takes years of work, most of it boring and
non-research in nature.
graham
graham
<grah...@telocity.com>
>> 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.
Writing compilers for FPLs is a niche but not a very small one with no
potential for expansion outside of itself.
> 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.
But writing mainstream applications is not just about using the right
language. It's about getting funding, getting trained programmers, etc.
So you cannot compare underfunded (in all areas of resources including
humans) functional lanuages with other well funded languages like C
and VB. The idea of chosing a good niche is that it allows you to focus
your resources and should allow the supposed technical edge of a
functional language to overcome the resource edge of bigger players.
This niche strategy is often used by hardware manufacturers.
K.J. Seefried at ksee...@digitalmojo.com wrote on 8/13/00 1:36 AM:
<grah...@telocity.com>
>> 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.
Sure Lisp dominates, but the niche is too small/specialised for it to
give you the bounce you need to get outside the niche.
K.J. Seefried at ksee...@digitalmojo.com wrote on 8/13/00 1:36 AM:
> 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. :-)
Sorry but I personally don't want to write such a thing. I also know very
little about the area. Is there really that much of a market?
K.J. Seefried at ksee...@digitalmojo.com wrote on 8/13/00 1:36 AM:
<grah...@telocity.com>
>> 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.
The problem here is that Ericcson are not trying to dominate the telecoms
niche, rather they are just using Erlang for their own products (and that's
fair enough of course). But that doesn't give much momentum for making
Erlang more widely used.
graham
Nick Williams
graham <grah...@telocity.com> wrote:
>The problem here is that Ericcson are not trying to dominate
>the telecoms niche, rather they are just using Erlang for their
>own products (and that's fair enough of course). But that
>doesn't give much momentum for making Erlang more widely used.
An area where I feel functional programming could do very well
is that of safety critical systems; formal methods and
mathematical proofs of program correctness are becoming accepted
as practical within that community, and functional programming
has many obvious advantages in that regard.
I'm joining a high integrity/safety critical software
engineering firm this year, and I'm thinking about starting a
part-time PhD on the idea of functional languages as applied to
that domain.
Functional programming has a number of pretty big wins over
imperative programming when it comes to proof, as well as being
more expressive whilst still remaining within the domain of the
provable (anyone who has tried proving the semantics of pointer
algorithms will know what I'm talking about here). On the down
side, there are usually quite hard constraints either in time or
space, so susceptability to static analysis would be important.
That, itself, probably connotes a call-by-value semantics,
restriction or absence of higher-order types, and a restriction
to tail recursions ... Memory management is also interesting,
but the work on regions in ML-like languages looks good from
that perspective.
Cheers,
Nick.
--
[ Nick Williams ]
[ MSc Computation Mobile - 07957-138179 ]
[ New College, Oxford http://www.new.ox.ac.uk/~nick/ ]
graham
> An area where I feel functional programming could do very well
> is that of safety critical systems; formal methods and
> mathematical proofs of program correctness are becoming accepted
> as practical within that community, and functional programming
> has many obvious advantages in that regard.
I am sure that functional languages are great for safety critical
systems, but I really wonder if that's a niche that functional
language teams should go after. You see the issue is not whether
a functional language would be good for safety critical programming.
The issue is rather that when you dominate this niche can you
translate that dominance into people being interested in using
your language outside it's niche. In that respect I don't think
safety critical systems is a good niche. I don't think it will
give you that bounce into other areas.
graham
Hartmann Schaffer
Hal Daume III <h...@cmu.edu> writes:
> ...
> 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
fp development still is very much research int programming paradigms.
e.g. haskell is trying to finf out how far you can go with a purely
functional approach, while the ml languages have escapes to imperative
and oo programming built in (note: this is somewhat oversimplistic).
based on that you can't just "chose one language and stick to it.
> ...
--
Hartmann Schaffer
Hartmann Schaffer
graham <grah...@telocity.com> writes:
> 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
>> style doesn't suit you, there are 50 other books with a different
>> educational style to choose from.
>
> 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).
otoh, two of the top introductory books (sicp and cousineu's book) are
done using functional languages (scheme and caml).
> 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.
>
> ...
--
Hartmann Schaffer
Albert Y. C. Lai
> 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? I hope it
is not along the line of "we do not understand continuation (hell we
do not understand recursion or higher-order function, period), so we
forbid anyone who understands it from using it".
Hartmann Schaffer
K.J. Seefried <ksee...@digitalmojo.com> writes:
> ...
> Q: What takes a language from academia to mainstream acceptance?
>
> 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
basic at was the first (and for a while the only) not assembler
language (i hesitate to call it a higher level language, esp. the
early versions) available on micros, and for quite a while the only
one. it was also cheap.
pascal was published with the compiler sources, and the language was
adapted to easy portability after a university in belfast ported it
from a cdc600 to an icl1900. shortly therafter the language
definition was changed slightly to get rid of features that turned out
to be strictly cdc6000 specific. it was also small enough to be
ported to small machines, so cheap implementations were available soon
after introductions of the pc
C was developed out of bcpl by stripping the latter down so you coud
get the compiler working on a very small machine (i think it was a
pfp7 with 8k memory). again, compilers became available for small
machines that were pretty cheap.
in each case, the compilers were a considerable improvement over what
was available befor (assembler << casic << pascal MM c)
the problems fp (even though cheap implementations are available now)
is that for many programmers (more importantly: managers) it is not
obvious that they give you such a tremendous productivity gain given
the now there are generations of programmers trained in imperative
languages, used to them and their development environment
environments, and often not prepared to learn a new paradigm (basic,
pascal, and C basically let you continue in the assmbler way of
programming, only more conveniently)
--
Hartmann Schaffer
UhU...@spamrahul.net
> In article <B5BB655B.8875%grah...@telocity.com>,
> graham <grah...@telocity.com> writes:
> > 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).
>
> otoh, two of the top introductory books (sicp and cousineu's book) are
> done using functional languages (scheme and caml).
>
...<snip>...
I resisted the temptation to add to this big thread because I doubt that my
experience is typical, but OK, I represent another data point so here goes.
I started learning programming a long time ago, FORTRAN on a PDP-8 in 1966,
and I hated it and didn't really understand what was going on. Actually,
after that class (which was actually about numerical methods not programming)
I shied away from computers for a long time. But after a stint in the Navy
I found myself taking a class in digital hardware, learning about
JK flip flops NAND gates and so on and, incidentally, some assembly language,
and that made everything click into place for me! I could understand the
imperative languages of the day (C, Algol, Pascal...) because I knew what
was really going on.
However, now I'm trying to learn Haskell from "The Haskell School of
Expression" (some of you may have noticed my questions here.) And I feel
like my knowledge of how a computer really works just doesn't help. I've
started peeking into the code for hugs to get an idea and I placed an order
for the out of print book "Implementing Functional Languages" by Simon
Peyton-Jones on Amazon (so far no word on finding a copy). I also picked
up a book on Lambda-Calculus that I happened to spot on the shelf at
Borders Books, "Lambda Calculi A Guide for Computer Scientists" by
Chris Hankin and penetrated maybe a 4th or a 3rd of the way into it and
that has given me some insight into whats going on. It seems the
fundamental principle of Lambda Calculus is substitution and that's what
Haskell seems to be doing, I know that's oversimplified but if it's flat
out wrong someone please correct me.
Anyway, for some of us, this may be the hard part of getting comfortable
with functional languages. My 2 cents.
----- Remove "UhUh" and "Spam" to get my real email address ---------
K.J. Seefried
wrote:
>
>But writing mainstream applications is not just about using the right
>language. It's about getting funding, getting trained programmers, etc.
>So you cannot compare underfunded (in all areas of resources including
>humans) functional lanuages with other well funded languages like C
>and VB.
>
I agree.
>
>The idea of chosing a good niche is that it allows you to focus
>your resources and should allow the supposed technical edge of a
>functional language to overcome the resource edge of bigger players.
>This niche strategy is often used by hardware manufacturers.
>
I see your point. It certainly has been an effective strategy in the
hardware world. MIPS and ARM would be long extinct if not for the
embedded systems arena.
>
>K.J. Seefried at ksee...@digitalmojo.com wrote on 8/13/00 1:36 AM:
<Security apps discussion deleted>
>
>Sorry but I personally don't want to write such a thing. I also know very
>little about the area. Is there really that much of a market?
>
The market for security services alone will be over US$14 billion by
2003, according to the research done for our buisiness plan. Don't
recall the number for product off-hand, but one would assume it's
along the same magantude.
As a percentage of the market, content control and intrusion detection
are major segments. I think my examples, if produced, could
sell...:-).
>K.J. Seefried at ksee...@digitalmojo.com wrote on 8/13/00 1:36 AM:
<Erlang discussion deleted>
>
>The problem here is that Ericcson are not trying to dominate the telecoms
>niche, rather they are just using Erlang for their own products (and that's
>fair enough of course). But that doesn't give much momentum for making
>Erlang more widely used.
>
But it's a terribly impressive story to tell. It has all the right
buzzwords to really turn heads, and it clearly places FPLs outside of
the academic environment and into the world of "Real Work".
Markus Mottl
> I disagree. First the real world doesn't want libraries that give you
> "simple" mail, FTP, whatever clients. They want *fully featured* mail, FTP,
> whatever clients. The real world is sick of prototypes X's being written
> in functional languages, they want fully featured X's. That is the reality!
> To make these kinds of libraries takes years of work, most of it boring and
> non-research in nature.
When I said "simple", I didn't mean that the mail client should be featureless,
but easy to use...
Yes, I agree that such things can require an aweful lot of (mostly boring) work
and may take quite some time to mature.
Craig Brozefsky
> I learned Lisp and ML from net tutorials. It was painful, and I still
> generally feel clueless flailing around in these languages.
For lisp:
Ansi Common Lisp by Paul Graham
On Lisp by Paul Graham
"Common Lisp, the Language 2nd Edition"
by Guy Steele (for reference use)
For ML:
ML For the Working Programmer by Larry Paulson
--
Craig Brozefsky <cr...@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
Daniel C. Wang
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
{stuff deleted}
> 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...
If I had a hord of hackers behind, me I'd take what's outlined in Cardelli's
proposal and throw away all the not-obviously good ideas from it... (most
notably the pervasive use of subtyping... which just raises way too many
issues and complicates the langauge while not obviously buying you all that
much... ) and just implement that subset... then start to experiment with
adding new fetaures... there needs to be a testbed to shake out the design
there's too much "looks good on paper" design in the ML2000 draft.. last I
look...
Here's the short list of things I'd like to see in a "ML2000 lite" based on
the last ML 2000 draft
1. Cleaner easier to parse syntax
2. Better support for explicit type annotations
3. Higher order functors and explicit/principal signatures for every module
4. Concurrency (I'm willing to give up on this)
5. Extensible types ("exttype")
6. Non-generative datatypes
7. Support for Laziness
8. Unlike the proposal, make "trapping arithmetic" the default
(provide non-trapping arithmetic as a library)
9. Drop the same set of misfeatures in ML as it is
i.e. polymorphic equality, imperative type variables,
infix declarations, abstype
Notice I'm leaving out structural subtyping... but "exttypes" gives me by
name substyping which is "less powerful" but also interacts better with the
rest of the type system, and I'll bet gives you the "right form of
subtyping" 90% of the time.
All the times, I've ever wanted subtyping "by name subtyping" was good
enough for me.
As for objects with exttypes, I can code up objects without too much
problem, the other object features in the draft seem nice, but they are all
untested...
Markus Mottl
> An area where I feel functional programming could do very well
> is that of safety critical systems; formal methods and
> mathematical proofs of program correctness are becoming accepted
> as practical within that community, and functional programming
> has many obvious advantages in that regard.
Indeed - languages with a strong formal background (logic and functional
ones) are unbeatable in this respect. Using LambdaProlog for program
transformations currently, I just find it wonderful to have a system that
not only solves the problem, but whose (short) declarative code *is* the
proof! I could impossibly imagine doing anything similar in imperative
languages, not even when I invest ten times more effort.
> I'm joining a high integrity/safety critical software
> engineering firm this year, and I'm thinking about starting a
> part-time PhD on the idea of functional languages as applied to
> that domain.
Good idea!
> Functional programming has a number of pretty big wins over
> imperative programming when it comes to proof, as well as being
> more expressive whilst still remaining within the domain of the
> provable (anyone who has tried proving the semantics of pointer
> algorithms will know what I'm talking about here).
Can this be done at all? ;-)
> On the down side, there are usually quite hard constraints either in
> time or space, so susceptability to static analysis would be important.
It's surely more difficult in lazy languages to also reason about such
aspects. On the other hand, strict languages are more difficult to treat
if you want to e.g. preserve termination behaviour during transformations.
> That, itself, probably connotes a call-by-value semantics,
> restriction or absence of higher-order types, and a restriction
> to tail recursions ... Memory management is also interesting,
> but the work on regions in ML-like languages looks good from
> that perspective.
Sounds like my current project... ;-)
Well, higher-order types make it more difficult to specify a denotational
semantics that is adequate to the operational one, but if I remember
correctly, this problem mainly hits lazy languages.
However, it may be extremely difficult to infer termination behaviour in a
higher-order setting (passing around possibly non-terminating functions).
A lazy, pure language is (nearly) uneffected by such considerations.
What concerns code transformations and tail-recursiveness: it seems that
some very nice transformations destroy the latter, achieving it again may
not always be so easy. So unfortunately there are tradeoffs sometimes.
Markus Mottl
> It seems the fundamental principle of Lambda Calculus is substitution and
> that's what Haskell seems to be doing, I know that's oversimplified but if
> it's flat out wrong someone please correct me.
This is more or less what functional programming is (or should) be about...
Haskell is surely among the languages which get as close to the ideal as can be
implemented.
> Anyway, for some of us, this may be the hard part of getting comfortable
> with functional languages. My 2 cents.
I was surprised to hear from you that you actually tried learning
functional languages by looking at the *implementation* of the
interpreters/compilers!? - A rather unusual way to approach this topic...
But it clearly shows that programming paradigms really shape the way
people think. It is not surprising then that people find it difficult to
switch to functional programming - not everybody has the experience to
learn about new technologies by looking at their implementation...
Daniel C. Wang
UhU...@Spamrahul.net writes:
{stuff deleted}
> It seems the
> fundamental principle of Lambda Calculus is substitution and that's what
> Haskell seems to be doing, I know that's oversimplified but if it's flat
> out wrong someone please correct me.
Nope you just nailed it on the head... at some level the core of any FPL is
just substitution. What's really, cool is that if you look at assembly code
the right way you discover underneath it all it's just the lambda calculus
too! Mathematics is just fancy symbol pushing in the end... :) So is
programming ...
Daniel C. Wang
graham <grah...@telocity.com> writes:
{stuff deleted}
> I am sure that functional languages are great for safety critical
> systems, but I really wonder if that's a niche that functional
> language teams should go after. You see the issue is not whether
> a functional language would be good for safety critical programming.
> The issue is rather that when you dominate this niche can you
> translate that dominance into people being interested in using
> your language outside it's niche. In that respect I don't think
> safety critical systems is a good niche. I don't think it will
I'd just like to see an FPL or FPL like language suitable for writting
Linux/XFree86 device drivers... this is a "safety critical" programming area
that can quiet easily expand out into other areas..... because you can win
the mindshare of many Linux hackers........
Seriously, to get optimal web performance some of the current linux hackers
are building the web server into the kernel. This kind of application is
just screaming for a safe systems programming language.. people will pay
money for fast *reliable* web servers.
*Fast* is easy if you are willing to throw away traditional OS abstractions
boundaries, which is the only way to really get big performance wins. But
the OS abstraction boundaries are the only thing that lets you build stable
large scale systems. Language enforcement of these abstraction boundaries is
much more efficent and flexible, and really the only way to build a
screemingly fast webserver that doesn't crash because of programmer bugs...
Nick Williams
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
>> Functional programming has a number of pretty big wins over
>> imperative programming when it comes to proof, as well as being
>> more expressive whilst still remaining within the domain of the
>> provable (anyone who has tried proving the semantics of pointer
>> algorithms will know what I'm talking about here).
>Can this be done at all? ;-)
Allegedly :-) ... Richard Bird taught a lecture course with some
ideas on this; use of an abstraction function to link the ADT to
a more concrete representation, and then using a Morgan-style
refinement calculus to give rise to an implementation.
>What concerns code transformations and tail-recursiveness: it
>seems that some very nice transformations destroy the latter,
>achieving it again may not always be so easy. So unfortunately
>there are tradeoffs sometimes.
Yes; if you can tell me a method of doing general recursion in
statically bounded stack space, I would be most interested :-)
Christopher Browne
>UhU...@spamrahul.net wrote:
>> It seems the fundamental principle of Lambda Calculus is substitution and
>> that's what Haskell seems to be doing, I know that's oversimplified but if
>> it's flat out wrong someone please correct me.
>
>Haskell is surely among the languages which get as close to the ideal as can be
>implemented.
>
>> Anyway, for some of us, this may be the hard part of getting comfortable
>> with functional languages. My 2 cents.
>
>I was surprised to hear from you that you actually tried learning
>functional languages by looking at the *implementation* of the
>interpreters/compilers!? - A rather unusual way to approach this topic...
>
>But it clearly shows that programming paradigms really shape the way
>people think. It is not surprising then that people find it difficult to
>switch to functional programming - not everybody has the experience to
>learn about new technologies by looking at their implementation...
That is one part of the way I try to understand computer systems; I
expect to have some sort of "model" of what is going on underneath.
That doesn't necessarily mean always needing to _completely_ understand
_all_ the details, but knowing what's underneath _is_ of some value
in knowing what to expect of the system's behaviour.
That is one of the things that is valuable about such system approaches
as:
a) Open Source, where the merit of it is in that you get access
to the source code;
b) Unix, where implementation details are historically quite
visible.
c) Source-available systems. I work with the SAP R/3 system; on
occasion, it is quite a useful thing that I have access to the
source code.
I do not normally use that knowledge to actually _modify_ these systems,
nor, virtually all the time, to do perverse things with them. What I
_do_ commonly do is to use that understanding of how they work to make
more intelligent use of the systems.
And I feel somewhat uncomfortable when I don't know what a system is
doing, underneath, as it means not understanding how to use it well.
--
aa...@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/linux.html>
DOS: n., A small annoying boot virus that causes random spontaneous
system crashes, usually just before saving a massive project. Easily
cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS.
-- from David Vicker's .plan
Daniel C. Wang
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> UhU...@spamrahul.net wrote:
> > It seems the fundamental principle of Lambda Calculus is substitution and
> > that's what Haskell seems to be doing, I know that's oversimplified but if
> > it's flat out wrong someone please correct me.
>
> This is more or less what functional programming is (or should) be about...
> Haskell is surely among the languages which get as close to the ideal as can be
> implemented.
>
> > Anyway, for some of us, this may be the hard part of getting comfortable
> > with functional languages. My 2 cents.
>
> I was surprised to hear from you that you actually tried learning
> functional languages by looking at the *implementation* of the
> interpreters/compilers!? - A rather unusual way to approach this topic...
if you think of an interpreter as an operational semantics for the
language this is a very natural thing to do.. :) Compilers of course provide
a denotational semantics by providing a mapping between the source language
into "the domain of machine semantics".
Of course, it's usually makes more sense to explain operational and
denotational semantics as interpreters and compilers then the reverse,
because most people learn about interpreters and compilers before any notion
of "semantics". At least in my experience going through the CS programs in
the US.
I learned quite a lot about FPL by just thinking about "how would this look
like in C". C has the advantaged that most experienced hackers understand
this semantic model of computation quite well. These days, I reduce
everything to a typed lambda calculus of some sort.. but it took a few year
for the FP brainwashing to be complete!
> But it clearly shows that programming paradigms really shape the way
> people think. It is not surprising then that people find it difficult to
> switch to functional programming - not everybody has the experience to
> learn about new technologies by looking at their implementation...
Even fewer have the time to really study the details of programming langauge
semantics and discover that "programming paradigms" are at best "useful
patterns of programming" and that there are quite a lot of useful
"paradigms" .....
Markus Mottl
> Here's the short list of things I'd like to see in a "ML2000 lite" based on
> the last ML 2000 draft
> 1. Cleaner easier to parse syntax
Well, it should first of all be easy to "parse" (vulgo: read) for humans... ;-)
> 2. Better support for explicit type annotations
Hm, I think you mean something like "mandatory types", similar to Haskell?
Which would allow you to use polymorphic recursion, for example?
> 3. Higher order functors and explicit/principal signatures for every module
SML/NJ already implements them, as does OCaml. Somebody (Claudio Russo)
has come up with a completely new way to use modules, which would also
allow you to have safe "dynamic" ones. I haven't read the details of his
thesis, but his supervisor (Don Sannella) said that it is a very clean
approach. Could be interesting...
> 4. Concurrency (I'm willing to give up on this)
I also don't need it often: it's not something I'd want to have as builtin
language feature, but if the implementation and libraries support it, I
won't mind...
> 5. Extensible types ("exttype")
I don't know much about the theory of extensible types. I guess it
includes polymorphic variants in OCaml? You can also extend types there,
even extend function definitions incrementally (and in a type safe way).
They probably also encompass records.
> 6. Non-generative datatypes
What do you mean by non-generative datatypes?
> 7. Support for Laziness
Syntactic? Hm, I don't know: I do not need it so often. For most purposes,
"streams" in OCaml and the good old "Lazy"-module were sufficient to me
(and I didn't use them often, either).
> 8. Unlike the proposal, make "trapping arithmetic" the default
> (provide non-trapping arithmetic as a library)
> 9. Drop the same set of misfeatures in ML as it is
> i.e. polymorphic equality, imperative type variables,
> infix declarations, abstype
What do you want to have in place of polymorphic equality? How do you type
potentially "dangerous" values (with imperative aspects)?
I find infix declarations confusing, too (and they make parsing more
difficult): the OCaml way of having "patterns" for operators that have a
specific fixity is much more practical. "abstype" does also not exist in
OCaml...
graham
> graham <grah...@telocity.com> wrote:
>> I disagree. First the real world doesn't want libraries that give you
>> "simple" mail, FTP, whatever clients. They want *fully featured* mail, FTP,
>> whatever clients. The real world is sick of prototypes X's being written
>> in functional languages, they want fully featured X's. That is the reality!
>> To make these kinds of libraries takes years of work, most of it boring and
>> non-research in nature.
>
> When I said "simple", I didn't mean that the mail client should be
> featureless, but easy to use...
>
> Yes, I agree that such things can require an aweful lot of (mostly boring)
> work and may take quite some time to mature.
Aren't you trying to have your cake and eat it too Markus? In your original
post you said that it would only take a few programmers a small amount of
time to create "simple" mail, FTP, etc servers. Now you are saying that
to make real mail, FTP etc servers it takes an awful lot of work. Which is
it?
graham
Markus Mottl
>>What concerns code transformations and tail-recursiveness: it
>>seems that some very nice transformations destroy the latter,
>>achieving it again may not always be so easy. So unfortunately
>>there are tradeoffs sometimes.
> Yes; if you can tell me a method of doing general recursion in
> statically bounded stack space, I would be most interested :-)
I was rather thinking of the problem that there is an inefficient,
tail-recursive function, but transforming it to a more efficient one
destroys tail-recursiveness. This seems to hit most approaches that build
on the "fold/unfold"-strategy of transformation.
Intuitively, it should be possible to fuse two tail-recursive functions to
one tail-recursive function again. But unless you restrict yourself to
certain classes of functions (catamorphisms), you may not necessarily
preserve this property.
E.g.:
optimize: sum (rev_map succ lst)
definitions:
let rec sum_aux acc = function
| [] -> acc
| h::t -> sum_aux (acc + h) t
let sum = sum_aux 0
let rec rev_map f acc = function
| [] -> acc
| h::t -> rev_map f (f h :: acc) t
let succ n = n + 1
transforming this to:
let rec trans_res = function
| [] -> 0
| h::t -> (h + 1) :: trans_res t
is not good enough.
Although these transformation preserve termination behaviour in the
theoretic sense, they don't do this practically: if stack space is
exhausted earlier in the transformed program, you have a problem...
Neel Krishnaswami
> 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.
Neel
UhU...@spamrahul.net
> UhU...@Spamrahul.net writes:
> {stuff deleted}
> > It seems the
> > fundamental principle of Lambda Calculus is substitution and that's what
> > Haskell seems to be doing, I know that's oversimplified but if it's flat
> > out wrong someone please correct me.
>
> Nope you just nailed it on the head... at some level the core of any FPL is
> just substitution. What's really, cool is that if you look at assembly code
> the right way you discover underneath it all it's just the lambda calculus
> too! Mathematics is just fancy symbol pushing in the end... :) So is
> programming ...
Well, when I'm reading this book on Haskell, I'm sure that they've removed
the ambiguities, but it seems tougher to do, more subtle somehow or off
the main habit of thinking for most of us. Even in classical lambda
calculus they seem to have had a struggle. That book on Lambda Calculus
I read mentions three approaches to substitution for instance, the
Classical Approach, Variable Convention, and de Bruijn Notation. When I'm
trying to follow Haskell, I have to be very careful, very absolute like
that gravedigger Hamlet met up with. More so it seems than with plain old
assembler or C. However, I look back at earlier chapters and the stuff is
much clearer so presumably with time I'll make my way through and improve
my overall skills in the process.
Again, I don't know how 'typical' my experience is.
-------Remove "UhUh" and "Spam" to get my real email address---------
Markus Mottl
> Aren't you trying to have your cake and eat it too Markus? In your original
> post you said that it would only take a few programmers a small amount of
> time to create "simple" mail, FTP, etc servers. Now you are saying that
> to make real mail, FTP etc servers it takes an awful lot of work. Which is
> it?
Well, the cake is probably to have a "few programmers" - if you are alone,
it *is* lots of work... ;-)
That's also one of the problems, I think: it's too difficult to get enough
people together to do such projects. "Lone wulf" programmers probably lose
interest half-way through. And there are just not enough people, and those
that are there want to hack away on more interesting things...
If it helped the spread of FPLs, I could imagine sacrificing myself (oh,
what pain!) to work on a "simple mail client" library for, hm, two weeks
full-time? - If you get together only 5 people, this would be 10
programmer weeks: if all of the 5 people know what they are doing, it
should be possible to come up with a fairly serious first release after
this time. Though, I have to admit, maybe I am just underestimating the
complexity of mail handling, but I think it is mostly implementing what
the RFCs tell you.
Nothing has to be "perfect". If the interfaces are well-designed, you can
extend them easily later. This is happening in the mainstream languages
all the time, too.
Markus Mottl
> language this is a very natural thing to do.. :)
Hm, I think I prefer a nice structural operational semantics over
low-level C-code... ;-)
> Of course, it's usually makes more sense to explain operational and
> denotational semantics as interpreters and compilers then the reverse,
> because most people learn about interpreters and compilers before any notion
> of "semantics". At least in my experience going through the CS programs in
> the US.
This is probably generally the case: formal semantics is considered either
"difficult" or "not relevant" for BSc courses and therefore mostly moved
to MSc courses ("heavy" ones even to PhD ones).
graham
> If it helped the spread of FPLs, I could imagine sacrificing myself (oh,
> what pain!) to work on a "simple mail client" library for, hm, two weeks
> full-time? - If you get together only 5 people, this would be 10
> programmer weeks: if all of the 5 people know what they are doing, it
> should be possible to come up with a fairly serious first release after
> this time. Though, I have to admit, maybe I am just underestimating the
> complexity of mail handling, but I think it is mostly implementing what
> the RFCs tell you.
I think you are under-estimating the overheads in team projects. 5
programmers at 2 weeks each does not make for 10 weeks of programming.
Moreover for a mail client your estimates may be correct, but for
most other kinds of software it will take a lot more time than a few
programmers working for a few weeks.
graham
Daniel C. Wang
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
> > Here's the short list of things I'd like to see in a "ML2000 lite" based on
> > the last ML 2000 draft
>
> > 1. Cleaner easier to parse syntax
>
> Well, it should first of all be easy to "parse" (vulgo: read) for humans... ;-)
>
> > 2. Better support for explicit type annotations
>
> Hm, I think you mean something like "mandatory types", similar to Haskell?
> Which would allow you to use polymorphic recursion, for example?
Yes. as well as better error reporting!
> > 3. Higher order functors and explicit/principal signatures for every module
>
> SML/NJ already implements them, as does OCaml. Somebody (Claudio Russo)
> has come up with a completely new way to use modules, which would also
> allow you to have safe "dynamic" ones. I haven't read the details of his
> thesis, but his supervisor (Don Sannella) said that it is a very clean
> approach. Could be interesting...
>
The issue of principal signature is a bit more subtle... at least for
SML.. I haven't gotten my head around the OCaml module system... so maybe
it's a non-issue...
> > 4. Concurrency (I'm willing to give up on this)
>
> I also don't need it often: it's not something I'd want to have as builtin
> language feature, but if the implementation and libraries support it, I
> won't mind...
>
> > 5. Extensible types ("exttype")
>
> I don't know much about the theory of extensible types. I guess it
> includes polymorphic variants in OCaml? You can also extend types there,
> even extend function definitions incrementally (and in a type safe way).
> They probably also encompass records.
Yes.. very much like polymoprhic variants...
> > 6. Non-generative datatypes
>
> What do you mean by non-generative datatypes?
In SML
functor F () =
struct
datatype foo = Foo
end
structure G = F ()
structure H = F ()
the types G.foo and H.foo are different types...
>
> > 7. Support for Laziness
>
> Syntactic? Hm, I don't know: I do not need it so often. For most purposes,
> "streams" in OCaml and the good old "Lazy"-module were sufficient to me
> (and I didn't use them often, either).
We must have laziness to steal the thunder from the Haskell crowd.. and so
we can give laziness assignment to students using our new in and improved
version. :)
> > 9. Drop the same set of misfeatures in ML as it is
> > i.e. polymorphic equality, imperative type variables,
> > infix declarations, abstype
>
> What do you want to have in place of polymorphic equality? How do you type
> potentially "dangerous" values (with imperative aspects)?
I'm happy to require users pass equality functions around..
fun member eq x (y::ys) =
if eq(x,y) then true
else member eq ys
if this really is a pain... one can think about adding Haskell style type
classes which are basically the same... but really which type of signature
would you like to see...
(* life without eq type *)
val member: (('a * 'a) -> bool) -> 'a -> 'a list -> bool
(* life with eqtypes *)
val member: ''a -> ''a list -> bool (* ''a = equality type *)
(* life with type classes *)
val member: Eq 'a => 'a -> 'a list -> bool
OCaml still has several notion of "eqness" which makes me kind of cringe
i.e. "object" and "value" equality like Scheme's (eq? x y) and (equal? x y)
which I find disturbing...(but that's just me... :))
Daniel C. Wang
ne...@brick.cswv.com (Neel Krishnaswami) writes:
{stuff deleted}
> And then change id_ref to some function of less general type later.
> That makes a reasonable amount of sense. However, this logic seems
> to mean that you can't even do something like this:
>
> val list_ref = ref [];
>
> without risking the same type error. Nullary type constructors of all
> parametric data types would share the same problem, too. This seems
> more restrictive than the idiomatic equivalent in the dynamically
> typed languages I've used. I dunno what this means.
This is only a issue if you try to use list_ref as a polymorphic *value*
consider all of the three cases below.. only the last doesn't type check...
fun f g l =
let val lref = ref l
in List.foldl g [] (!lref)
end;
let fun g (x,xs) = x::xs
val lref = ref [1]
in List.foldl g [] (!lref)
end;
(fn () =>
let fun g (x,xs) = x::xs
val lref = ref []
in List.foldl g [] (!lref)
end);
let fun g (x,xs) = x::xs
val lref = ref []
in List.foldl g [] (!lref)
end;
This is a subtle issue...
Wright (LISP and Symbolic Computation 95) Simple Imperative Polymorphism
http://www.cs.rice.edu/CS/PLT/Publications/lasc95-w.ps.gz
Contains a good explanation of the issues and some practical experience with
the "value restriction" it's easy to read... too... :) (or at least it's
easy for me to read now.. after I understand the issue myself.. )
Neel Krishnaswami
> 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).
Yes, I just double-checked and found that OCaml gives a warning too.
> 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).
So IOW someone could write something like this (in standard ML):
fun id x = x;
val id_ref = ref id;
fun copy lst = map !id_ref lst;
And then change id_ref to some function of less general type later.
That makes a reasonable amount of sense. However, this logic seems
to mean that you can't even do something like this:
val list_ref = ref [];
without risking the same type error. Nullary type constructors of all
parametric data types would share the same problem, too. This seems
more restrictive than the idiomatic equivalent in the dynamically
typed languages I've used. I dunno what this means.
> > 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 don't think I agree with this, because if it were true then you
would only need one type system for every language. More concretely,
I don't see how you can do things like allow the user to make objects
transparently persistent (a real use of the CLOS MOP) -without- a
metaobject protocol of some kind.
Neel
Peter Sestoft
> > 3. Higher order functors and explicit/principal signatures for every module
>
> SML/NJ already implements them, as does OCaml. Somebody (Claudio Russo)
> has come up with a completely new way to use modules, which would also
> allow you to have safe "dynamic" ones. I haven't read the details of his
> thesis, but his supervisor (Don Sannella) said that it is a very clean
> approach. Could be interesting...
Claudio has implemented most of his thesis constructions (a superset
of SML'97 Modules) in Moscow ML 2.00, so you can experiment with them.
Get it at
http://www.dina.kvl.dk/~sestoft/mosml.html
Peter
Per Bothner
> Per Bothner's kawa (a Scheme interpreter above the JVM) implements a limited
> continuation model with full support for call/cc coming shortly.
Note that "shortly" is a quote from me!
However, I have gotten the feeling that enough people need/want
full call/cc that I've bumped up its priority, and have recently done
some preliminary work in this area. So sometime before the end of
the calendar year is looking likelier than it used to ...
A side benefit of implementing full call/cc is that it should be
possible to implement a debugger in "pure Java", without any VM-specific
debugging hooks.
--
--Per Bothner
p...@bothner.com http://www.bothner.com/~per/
Ketil Z Malde
> 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.
Yes and no. I think most programmers in industry are too used to
programming as programming a *machine*: First do this, then do that.
And consequently, too little used to thinking in an abstract,
mathematical sense. Saying that you can treat a function as a value
just gets you blank stares, a function is just a convenient way to
group and name a bunch of useful instructions, just like a variable is
just naming a memory location.
Garbage collection, currying and typing isn't difficult to understand
(enough to use, that is), it's scary because the machine you instruct
no longer seems as simple.
Python and Perl is popular, since they let you keep that way of
thinking.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
thomas...@bluetail.com
K.J. Seefried <ksee...@digitalmojo.com> writes:
> Erlang? Very interesting language, but who uses it save Ericsson?
There's an Erlang Users Conference coming up.
The speakers come from Cellpoint, one2one, an unnamed
telecommunications company, and a number of academics. I've seen
people from Telia as well (one of them won the User Award last year
for a call center project), but curiously none from Nokia. At least
none tagged as such :) There are half a dozen companies of various
sizes providing consulting services as well, see http://www.erlang.se .
Erlang has taken a beach head in the telecoms world.
In the internet server world, there's Bluetail so far; our partners
have at least voiced their interest in the technology. "The coolest
thing to come around for years", as someone put it. Well, at least
when you're in the business of writing infrastructure :)
Also, Erlang is easy to learn. The standard course takes four days to
make an ordinary C++ programmer write a simple POTS. (I've held the
course, and it works.) Thus, it's fairly easy to extend the programmer
base.
Some things are lacking: a better development environment, probably,
and some second-source of support for Erlang users -- but mainly an
O'Reilly book describing how to use OTP effectively. (And so we neatly
come back on topic :)
Thomas
--
Thomas Lindgren thomas...@bluetail.com
Bluetail AB http://www.bluetail.com
"The need of a constantly expanding market for its products chases the
bourgeoisie over the entire surface of the globe. It must nestle
everywhere, settle everywhere, establish connections everywhere."
-- Communist Manifesto
thomas...@bluetail.com
Peter Hancock <p...@dcs.ed.ac.uk> writes:
> One often hears "7x24x365"; is it a joke? Or just another indication
> that people aren't paying much attention to what they are saying?
The standard telecoms reliability measure is "five nines": 99.999%
uptime. That translates to five minutes downtime per year. Or, one
hour per ten years of operation. There is lots of specialized hardware
in this area, e.g., the 5ESS, or AXE, or the ASICs that sit around
on line cards or in switching fabrics. Or the chassis solutions used
so that you can pull out a line card without frying the switch :-)
(There are applications requiring six nines, by the way, though I
don't know of any requiring seven.)
Basically, to provide five nines, you need to have a spare ready to
take over operations very quickly, and never stop to upgrade software
or hardware, or reboot to recover leaked memory, or run fsck to
reboot, or the equivalent. Also, you have to handle power outages. (I
thought Greg Pfister's book, In Search of Clusters, was a good intro.)
Erlang provides one piece of this puzzle, and also has the well-known
FP advantages of shorter code, etc. Part of the agility advantage
comes, in my opinion, from the fact that it is domain specific: it
provides language constructs for the commonly needed stuff that is
hard to get right and that easily becomes a mess of different, poorly
interacting solutions (mutual exclusion, timers, distribution, fault
management, ...).
thomas...@bluetail.com
ni...@thelonious.new.ox.ac.uk (Nick Williams) writes:
> An area where I feel functional programming could do very well
> is that of safety critical systems; formal methods and
> mathematical proofs of program correctness are becoming accepted
> as practical within that community, and functional programming
> has many obvious advantages in that regard.
Yeah, good point. Though the verification part often has a lot of
concurrency in it.
Take a look at Lars Pareto's and John Hughes's work at Chalmers. Very
interesting. Also, Carlstedt R&T (http://www.crt.se) have done and may
still be doing some work in that area.
Basically, the most recent Swedish fighter jet, JAS Gripen,
("griffin") was supposed to use a new fault-tolerant processor
programmed in a functional/logic language, and developed by
Carlstedts. This project was cancelled, due to hardware troubles. The
guys who worked on the language are still there, however. (The JAS now
runs ADA, I believe.)
If any Carlstedt guys are listening, feel free to correct my
misconceptions :)
Markus Mottl
> So IOW someone could write something like this (in standard ML):
> fun id x = x;
> val id_ref = ref id;
> fun copy lst = map !id_ref lst;
> And then change id_ref to some function of less general type later.
> That makes a reasonable amount of sense. However, this logic seems
> to mean that you can't even do something like this:
> val list_ref = ref [];
Right, this, too, cannot be generalized.
> without risking the same type error. Nullary type constructors of all
> parametric data types would share the same problem, too. This seems
> more restrictive than the idiomatic equivalent in the dynamically
> typed languages I've used. I dunno what this means.
But note that you can do the following:
let list_ref () = ref []
"Lifting" expressions always works.
If this is not "good enough" for you, then you can use the module system
and functors to use non-parametric types instead. Then there cannot be any
generalization problem anymore.
>> 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 don't think I agree with this, because if it were true then you
> would only need one type system for every language. More concretely,
> I don't see how you can do things like allow the user to make objects
> transparently persistent (a real use of the CLOS MOP) -without- a
> metaobject protocol of some kind.
I hardly ever use OO (I haven't for at least a year) - and I'm happy about
this! But anyway, if you explain me, for what you need the feature you ask
for, maybe I could tell you how this would be solved in ML.
Markus Mottl
> I think you are under-estimating the overheads in team projects. 5
> programmers at 2 weeks each does not make for 10 weeks of programming.
This was just a fast guess, the "two weeks" per programmer already
containing potential coordination costs. Of course, such things usually
don't scale linearly.
> Moreover for a mail client your estimates may be correct, but for
> most other kinds of software it will take a lot more time than a few
> programmers working for a few weeks.
Taking a look at existing libraries in Perl, I could well imagine a team
replicating the behaviour of most of them in a similar amount of time.
Maybe even less if you just translate the code instead of going for a
"cleaner" solution...
Markus Mottl
>> Hm, I think you mean something like "mandatory types", similar to Haskell?
>> Which would allow you to use polymorphic recursion, for example?
> Yes. as well as better error reporting!
Type restrictions in ML already improve this. However, since they are not
mandatory, you won't get at the full power of polymorphism.
> The issue of principal signature is a bit more subtle... at least for
> SML.. I haven't gotten my head around the OCaml module system... so maybe
> it's a non-issue...
The OCaml-module system is based on "translucent sums". Having asked our
lecturer about them, he said that he considers Claudio's approach cleaner
and more general. I don't have the knowledge to judge this, because I
haven't read the thesis yet, but when I'll have a bit more time, I'll
surely take a look.
>> > 6. Non-generative datatypes
>>
>> What do you mean by non-generative datatypes?
> In SML
> functor F () =
> struct
> datatype foo = Foo
> end
> structure G = F ()
> structure H = F ()
> the types G.foo and H.foo are different types...
Ah, ok, I see - wasn't sure about the terminology...
> We must have laziness to steal the thunder from the Haskell crowd.. and so
> we can give laziness assignment to students using our new in and improved
> version. :)
They'll all envy us! ;-)
If you are intending something similar to the notation used in Okasaki's
book, it might be worth considering.
> I'm happy to require users pass equality functions around..
Ahem, *all* kinds of equalities? - I don't know whether people will like a
language that is "cleaner", but tedious to use. You'd have to define a
comparison function for *all* your user-defined datastructures! And you'd
probably forget about infix equality then...
> if this really is a pain... one can think about adding Haskell style type
> classes which are basically the same... but really which type of signature
> would you like to see...
But this means adding overloading to the language! This makes the type
system *much* more complex, both to implement and to use.
> OCaml still has several notion of "eqness" which makes me kind of cringe
> i.e. "object" and "value" equality like Scheme's (eq? x y) and (equal? x y)
> which I find disturbing...(but that's just me... :))
I think the way in which OCaml handles equality is reasonable (it gets
away without SML's "eqtypes"):
Equality "=" is polymorphic and can handle all data (except for functions
and cyclic data, unless the function/data happens to be physically
identical). If you want to define your own equality, you are free to do so
(e.g. by parameterizing modules over ordered elements). If you want to
know whether two values are actually physically the same, use "==". The
latter can come quite handy for improving sharing of datastructures in
memory.
I am quite content with the way this works - I don't see any need for
changing it.
Markus Mottl
> Claudio has implemented most of his thesis constructions (a superset
> of SML'97 Modules) in Moscow ML 2.00, so you can experiment with them.
Ah, thanks for the hint! Although I had read that he has implemented the
module system, I didn't know that he really implemented the superset, not
just the "compatible" part.