What About Functional Languages?

sdavies asks: "Functional languages like Scheme and Haskell are great! (here is a PS viewer) They give programmers new tools for elegance and abstraction. Unfortunately, to the legions of procedural programmers writing in languages like C/C++(/C#), Java, and VB, functional languages are considered obscure and impractical. What is your experience with functional languages, and what do you think is preventing them from being adopted into the mainstream?"

Comments

Re:GCC back-end

[dcs]

Actually, I meant all OSS OS . Since gcc is the only OSS compiler out there with IA64 support, and the OSS OS I know of all depend on some special gcc features anyway, ... <shrug>

I'm pretty sure most of the corporations out there writing closed source software for Linux are using gcc, because that's the only Real compiler available for Linux. That is, until Borland decides to show up.

Re:A misnomer? Not!

[dcs]

A program tells you how to reach a goal. Anything else is not a program. This is the definition by which I stand (Prolog or no Prolog :).

That you disagree with that pretty much sums up our differences.

Re:Experiences...

[beppu]

The scheme version is correct. This one doesn't compute fibonacci numbers correctly.

Re:GCC back-end

[MikeBabcock]

So I was right. You meant all software using GCC. Which has lots to do with whether its open source software or not (by inter-relationship), but doesn't have any necessary corelation.

Re:Formal correctness proofs -- YES!

[kcarnold]

If you insist that there is something wrong, you are welcome to fix whatever is necessary and post it up. It was only an example, anyway.

..."teach yourself Scheme in 21 days?"

[woggo]

One of the major problems is that almost everyone in the industry thinks imperatively, even (sadly) most "Java Programmers". That's great for writing programs in BASIC (or even C :-) ), but if you try writing in an imperative style in a functional language, it'll get ugly fast, and it won't offer any benefits over the imperative language that "you already know".


~wog

Re:Why Functional Matters

[eske]

If you think that FL is of no use look at:
http://ellemose.dina.kvl.dk/~sestoft/msp/index.msp
and
http://www.dina.kvl.dk/~sestoft/mosml.html
Here you have all you need to make a webserver (look at the links), acsses to database (postgress and MYSQL), etc.

Re:Functional Programming: its above our heads

[elflord]

Perl has garbage collection,

... limited GC, yes. But it doesn't make things substantially easier if you start implementing complex data structures. Actually, if anything it makes life harder because you can't "see" what's giong on. BTW, STL has built in hashes. I agree that perl is much better for string processing though.

I think I can say with confidence that C++ has not been adopted by many C programmers due to its complexity (and also due to the huge binaries), and ultimately I think we must presume that C++'s time has come and gone.

Hahaha ... I don't think so. What do you think all the C++ programmers were doing before they programmed C ? There has been some migration. C is not going to make C++ obsolete any time soon ( it has no OO for starters ). But then, there are some jobs for which C++ is an overkill, so I don't see C dying soon either ( besides, there's too much C lying around to get rid of. )

Functional Programming: try it in Perl!

[pb]

You can program perl as a functional language as well. The syntax might not look as "elegant" if you're used to Scheme, but anyone who hasn't used a functional language because of the parentheses might want to give it a try.

By declaring all your variables at the top of your subroutines with my, you get lexical scoping throughout your program, which is an excellent feature of Scheme. But if you don't like it, then you don't have to use it; you can try the freaky 'dynamic scoping' instead, or get burned with global variables. (trust me--in a large app, you'll probably get burned; especially if the source is in multiple files)

Since perl supports references as a first-class data type, closures are *almost* first-class data types, and you can return a reference to a subroutine. For real nested data, you can write it like this: ['abc',[1,2,[3,'b']], which again is using references, and get it all back with the Data::Dumper module, or write some code to parse it.

Also, if you don't like manipulating references, or didn't write functions to do it for you yet, list operations in perl are built-in; there's really no need to write car and cdr and cons if you're just using arrays, but it's really easy to do.

Perl is generally interpreted, and capable of doing an eval, and has features of both functional *and* procedural languages. There's More Than One Way To Do It!

A Functional Perl Example:

my $count;
$count = sub {
($_[0]) && (&$count($_[0]-1), @_);
};
print join " ",&$count(10), "\n";

Compare to Scheme:

(define descending
(lambda (n)
(cond
((zero? n) `())
(else (cons n (descending (sub1 n)))))))
(descending 10)

Okay, okay, the list formatting and declaration is a lot cleaner in scheme, (but of course I could make a perl function like define that just did an =, basically, which would be like using set! to do the same in Scheme...) but the Perl is still pretty short and to-the-point just doing it the simple way.

Also, you can make perl more expressive and pretty by doing, say, my n = $_[0]; at the beginning, or writing a simple cons function that just does return @_;...
---
pb Reply or e-mail; don't vaguely moderate.

Re:Functional Programming: try it in Perl!

[blue trane]

here's one way in java:

import java.util.Vector;
public class testcount {
public static void main( String args[] ) {
try {
Vector list = Count.down(Integer.parseInt(args[0]));
for ( int i = 0; i list.size(); i++ )
System.out.print( ((Integer)(list.elementAt(i))).toString() + " " );
} catch (Exception e) {
System.out.println("Usage: java countdown INT");
}
}
}

class Count {
private static Vector list = new Vector();
public static Vector down( int n ) {
list.addElement( new Integer( n ));
if ( n == 0 ) return list;
return down( n-1 );
}
}

Re:Functional Programming: try it in Perl!

[pb]

Ah, but Perl *does* directly support many of these features, which was my point in the first place.

I could similarly argue that Scheme is worthless because it is written in C, so everything Scheme could do could be done easier in C. But I wouldn't...

Some people are turned off by the syntax of functional languages like Scheme; since they can't get past that, it never looks 'elegant'. What I was demonstrating might convert a Perl programmer to the functional paradigm, or at least explain it somewhat. And I don't think I was really abusing the language more than it already is anyhow. :)

However, for a comparison, feel free to write a similar functional C++ program, and we can see how ugly and convoluted it is. I think my Perl program is pretty neat; actually, the subroutine is more compact than the Scheme version.
---
pb Reply or e-mail; don't vaguely moderate.

Re:Functional Programming: try it in Perl!

[pb]

I guess that does the same thing... sort of... Although it's just getting uglier. :)

Does Java support real closures?

(I guess you could fake lexical scoping with braces, as you would do it in C...)
---
pb Reply or e-mail; don't vaguely moderate.

Re:OT: Meta moderating

[Requiem]

I'm user 12000 and something, and have metamoded since the beginning. Of course, that's probably because I checked the "willing to moderate" box.

What i meant by simple

[umeshunni]

is not in terms of code-complexity but in terms of singularity of function. grep is used simply for searching thru text, wget might be a little more complex since it has to (in my network setup) [connect to proxy]->[send http request]->[recieve html] or [print error ( more likely!)]->[parse html]->[find links]->[follow them] etc. etc..
In any case, how would you handle something like this recursively ?
Or rather, can you even do network connections in any functional programming language ?

Re:What i meant by simple

[pb]

how would you handle something like this recursively ?

The same way you handle it iteratively: carefully, and one step at a time. :)

You'd probably just make separate subroutines for each step, and figure out how you'd want them to call each other. More like:

(follow (parse (request (connect))))

...assuming that each routine does error checking, can fall through if another one fails, etc., etc.

can you even do network connections in any functional programming language ?

Sure; the fact that it is functional has nothing to do with what library features it supports. Heck, externally call something or write it in Perl, if you have to. Just do it functionally. :)
---
pb Reply or e-mail; don't vaguely moderate.

Re:What i meant by simple

[curri]

On a harder problem, there is a web server (and TCP/IP stack) written in ML (SML/NJ); you can find more info here

http://foxnet.cs.cmu.edu/HomePage.html

testament

[aladd]

I've been shopping. The most usable ML package, in my opinion, is ocaml. I'm suprised I haven't seen it mentioned. Its compiler produces native code which runs at worst half the speed of similar C programs. I try to code as much as possible in ML because I enjoy it. C++ is at least ugly and can, at times, be painful.

I think people don't use Scheme and Haskell because it is hellish to develop large scale programs with them. The programs run slowly and become complex.

ML (ocaml) deals with this nicely - it doesnt force functional programming down your throat, it has a great type system, it doesnt force object oriented programming down your throat, the compilation system isnt an afterthought and it looks nice.

Two things I've noticed - if I can get something through the type checker then often it works on the first shot and if it doesnt - its because I made a real mistake - not a grammatical mistake.

And, simple ideas translate into simple code. I have spent countless hours coding C++ wrapper so other people (or me three days later) can read my code and use it - I'm getting sick of it.

Nobody uses it because, although some efforts have been made, there are no good, complete ML libraries. Writing libraries is hard. Look at STL - its an atrocity. The good fascists running the internet censorware should filter it so that the children of tomorrow wont be scarred by its bizarre and unnatural semantics. ML offers the possibility for beatiful libraries.

Also, nobody knows it. A relatively tiny fraction of the community has even heard of it. As far as I know, it is not taught in very many universities. In an industry suprisingly frightened by change, it doesnt come as a shock that nobody uses it. Too bad - (warning: religious claim follows) its better...

-----
andrew

Re:testament

[korinthe]

One of the intro cs courses at Brown University tried teaching OCaml last year (fall 99), and we TA's are trying to prevent that from happening again...
We were forced into using OCaml because a system upgrade removed MLWorks (dev envt for Standard ML) from our bag o' tools. Where the two languages intersect, things were fine... but when the Object in OCaml came up in class, the students had a hell of a time. To program a simple game like Mancala or checkers both functionally and OO, they were forced to dance around mutation by instantiating new instances of objects (with obscenely long argument lists) and assigning them to self. And as an intro to OO and Java (the second-semester material), OCaml really didn't help very much.

IMHO OCaml tries to be too many things to too many people. I'd never program anything larger than "Eliza" in it by choice, and the terrific parts of the language (strong type definition, pattern matching) are all present in SML.

Re:A couple of reasons:

[Gurlia]

Oh, BTW, I forgot to mention... when I said GUI in my above post, I don't mean just a clunky, inefficient, half-crippled excuse for a windowing interface, just for the marketing people to talk about. If you scroll down Clean's homepage (link is in my above post), you will see a 2D tiled-game implemented in Concurrent Clean. Although this is still a rather humble start, you've gotta admit that Clean has made what could be major breakthroughs in functional programming.

---

Re:they are too hard

[FigWig]

(if (is-raining? outside) (stay-home) (go-to-park) )

Just because a language is functional doesn't mean it lacks flow control!

Re:Experiences...

[Temperance]

You are better off defining factorial as tail recursive, or else you will get stack overflows with small values like 1000 (most likely). I would do something like this

(define (factorial x)
(letrec ((fact-iter (lambda (a b)
(if (<= a 1)
b
(fact-iter (- a 1) (* (- a 1) b))))))
(if (<= x 0)
1
(fact-iter x x))))

Why Functional Matters

[Tom7]

I've always thought about submitting one of these "why not functional?" or "why not ML?" ask slashdots... but I think I know the answer.

My favorite functional language is ML (standard). It isn't "purely functional" like haskell (though we often write purely functional programs); it includes imperative features like assignment and arrays and IO, which are usually useful in real programs.

I work on an ML compiler here at CMU called TILT (which I'd like to think is one of the most advanced research compilers around), so I am sort of biased. But I also know what I'm talking about...

(Incidentally, the FoxNet Web Server is written entirely in standard ML, including the network stack (with ethernet, down to the hardware device driver)!)

Anyway, back to the question. Why does functional programming matter?

Programming functionally is closer to thinking in terms of math. Lots of algorithms and data structures are expressed more beautifully in a functional style. It's almost impossible to write gross hacks if you're programming functionally (most quick hacks actually turn out looking quite beautiful). Programming functionally has some direct advantages in this vein, and I find that I write better code faster when I write functionally. (I'll admit to hating it for a semester! But once I got used to it, I don't want to go back...)

There are some awesome features of most functional languages, most notably: Parametric Polymorphism and Higher Order Functions. (more rarely, such gems as functors and higher-order continuations (aka callcc; think a typed and higher-order setjmp). These all deserve their own posts to explain their incredible benefits. You are missing out if you've never written a program using these features.

But mostly, functional programming is useful for its indirect benefits. Let me explain some of these:

- Concurrency. Writing concurrent programs in a functional language is so much more natural. It's easier to avoid certain kinds of race conditions too, since you don't update variables in a functional language. SML/NJ has an awesome concurrencly package called CML .

- A powerful static type system and type safety. It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful. Features of functional languages like garbage collection and non-updatable values make it easier to define a language with a powerful type system. (in case you're still stuck in the 60s, type safety guarantees that your program CANNOT crash at runtime. No more uninitialized pointers, using memory after it's freed, bad casts, or other plagues of C++ programming).

A powerful static type system gets you a lot:

- Debugging. It's easier to find mistakes in your program. When I program in ML, I get a list of all the type errors in my program when I compile. I can go back and fix these before I have to run my program on test cases, etc. Debugging is so much easier. It's hard to explain how incredibly useful this is compared to programming in C++. Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.

- Your programs run faster. Java has a somewhat more mature type system than C++ (it guarantees safety, for instance), but most of this is dynamic. That means all your objects are tagged, and these tags are checked frequently to make sure you're not doing anything wrong! There's no way the compiler can optimize these out; mistakes in the definition of the language (array subtyping) make tags necessary for type-safety. In ML, we don't have to tag values or check them at runtime. Yet we guarantee our programs run safely because we verify all of the types at compile-time!

- Compiler Technology Advances. Most research in programming languages and compilers these days is on languages with interesting type systems. We're seeing fewer and fewer improvements to C compilers, and lots of improvements on "advanced" programming languages. The type system allows you to make more optimizations, because the compiler has more information available to it. Some concrete examples:

Aliasing - a big problem for C/C++/Java compilers. If you've ever looked at the machine code they produce, you've seen this effect. "Why is it fetching that address again??" ... because two pointers may have pointed to the same thing, and in order to preserve the semantics of the language, redundant work is done. When you're not doing updates (functional programming), the compiler doesn't have to worry about aliasing.

Function Calls: Practically every C/C++ compiler treats functions as a black box. Languages with stronger type systems are able to optimize around function calls because much more information (types) are available.

Our TILT compiler that I mentioned earlier does something rather new: Each compilation phase transforms not only the program but its type. We keep the type information around even when we are dealing with assembly language! This enables us to perform some unprecedented optimizations.

- Machine independence. Making a type system usually means hiding away the details of the machine, and this usually means that the execution of your program is completely predictable. (Compare to C/C++ "undefined" behavior!) ML programs are extremely portable.

- Modularity. I was able to understand and start working on the (100,000 line+) TILT compiler in a matter of days rather than weeks because of ML's strong modularity features. The most interesting of these are:

Signature Ascription - This allows you to define abstract data types by naming a type and some operations on it (and their types). This is similar to header files in C (much more refined), but thanks to the type system, you can guarantee that the user can ONLY use your abstract data type the way you intended. They cannot cast, subclass, or use any other tricks to get at your datatype. (Some OO folks have solutions for this too, but they are not as elegant). This is awesome, because it helps you figure out where bugs are. I can attest that this really works; my project this summer is to change the way a very important module works... and so far, I have only experienced one observable effect of changing the representation!

Functors - This is somewhat like C++'s template system (but more refined); allowing you to write programs which operate on modules. (Ie, you give me a module which implements sets, and I'll give you back a module which implementes maps). This is very useful, and since all the work is done at compile-time, incurs no runtime cost.

- Proof-carrying code. You haven't seen this yet, but you will. What if you could download a program off the internet and run it, knowing that it won't do anything wrong? What if it wasn't subject to sandboxing (and slowdown) like Java apps? What if you didn't need to trust the source (certificats/signing)? Proof-carrying code carries a proof of its type-safety (and other safety metrics) with it; your computer verifies the proof and then runs the bare code! You can read more about this here .

Now here are some answers to the question of why not functional?

- RIGHT NOW, functional languages are slower (estimate 2x) than languages like C. Against a "modern" language like Java they fare rather well. Compiler technology is advancing and will fix this! I'd also argue that the other benefits (developer productivity, code maintainability) far outweigh the slowdown.

- Functional is weird for a lot of people. It took me at least 6 months to figure out why it was good, and I consider myself a pretty good hacker. Most people are more comfortable with imperative languages (at first...), possibly because that's usually their introduction to programming.

- There are not many commercial applications for functional programming yet (outside of Ericcson), and some people just program for money.

I would like to see the hacker types of the world pick up some new, interesting languages. Most of these languages don't have powerful marketing engines like Sun or Microsoft behind them, but hacker types are (usually) smart enough to see past that stuff!

Re:Why Functional Matters

[nhw]

Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.

This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers.

Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.

Cheers, Nick.

Re:Why Functional Matters

[Junks Jerzey]

Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.

This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers. These kinds of errors are at least as common. I'll agree that catching some errors is better than none, but the ones that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.

Re:Why Functional Matters

[BinxBolling]

This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers.

Actually, this is a perfect example of why the first stages of developing a piece of software should be to think about the types of data you're going to be handling, and building low-level code for manipulating these pieces of data in a convenient fashion that maps well to the way you think about them. In the above example, it sounds like you're doing 2-D graphics. That being the case, one of your first steps should have been to define a 'point' data type, which stores an (x, y) pair, build constructors and accessors for this type. Then, your rect procedure would take two points (or a point and a vector (which might have the same internal representation, but are conceptually different, and thus given distinct types)) rather than 4 integers, and the particular error you're describing becomes impossible.

Re:Why Functional Matters

[boloni]

Tom

Sorry, but can you substantiate your claims? I had all these claims turned on me about ten years ago in my undergrad years, and at that moment they were prophesizing the imminent major importance of functional programming languages.

But my experience shows that:
-concurrent programs are written in C/C++
-debugging Lisp/Scheme is ridiculously problematic compared with C/C++/Java. I don't know about the current status of ML.
-and the programs run slower.

And I had friends destroying their carreers by specializing themselves into Lisp Machines etc.

I am sorry, but when I see that after 30 years, the ridiculous examples of implementing Lisp in Lisp are again at vogue and are used as justification, I have a feeling that some people entered into a horrible cul de sac.

As part of the required courses for the PhD curriculum I had to revisit the functional programming. The major novelty in the course I had taken was the transformations needed to implement continuation based programming.

Sorry, but it hit me as a terrible hack: in fact I had never done anything so unnatural for performance reasons in C++. The resulting program was not elegant: it was long and completely unreadable, with the performance still being several order of magnitudes slower than a nonoptimized quick and dirty C++ program.

And all this, because some people at some moment of time did not take the effort to formalize repetition in math and they replaced it with the theory of recursion?

Sorry: but applying the same operation to all elements of a set is not recursion. Nature has rhythmic, repetitive elements: they are not recursion.

Sincerely speaking, I think that the whole insistence on functional programming is based on bad math, and misunderstanding of the phenomena the programs should computationally model, and this is the reason for the bad performance.

sincerely
Lotzi Boloni

Re:Why Functional Matters

[King Babar]

Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.

Yes, but while types are a good thing, there's a limit. No one wants to take this to the extreme, and have a type for odd integers, a type for the number of students in a class (as opposed to the number of books in a library), and so on.

Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.

So, for starters, why not have a type that represents all and only the Odd Integers? One can think of plenty of mathematical situations where functions are defined only (or alternatively) for odd numbers rather than even numbers. In a type-impoverished system, you might have to litter your program with checks like (in pseudocode) "if ((x % 2) == 0) --we're doomed!". In a typeful environment, when you construct X as an odd integer, and use only operations defined for odd integers, then X *stays* odd, dagnab it. And that can be a huge win. Or let me put it this way: if you were programming on an architecture where valid addresses are only even integers (Motorola 68000 comes to mind?), then specialized types guaranteed to be even or odd could save you from doing something naughty.

As for distinguishing the types for numbers of students vs. number of books, again, why not make the distinction if it is important for your problem? I mean, if values of those two types occur in one program, then having them around could make it impossible for you to compute something like "number of students read by each book" when you obviously really meant to do something else.

After a while, being pedantic ceases to pay off. Actually, it ceases to pay off rather quickly, I think.

I'm not as sure as you are. I've seen too much buggy C code where there could have been a type error (but there wasn't) and too much confusion when everything's a string (so convenient until it all goes wrong) to think of anal retentive type use as merely pedantic.

Re:Why Functional Matters

[Junks Jerzey]

Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.

Yes, but while types are a good thing, there's a limit. No one wants to take this to the extreme, and have a type for odd integers, a type for the number of students in a class (as opposed to the number of books in a library), and so on. After a while, being pedantic ceases to pay off. Actually, it ceases to pay off rather quickly, I think.

The typing issue is confused by all the other benefits that functional programming languages provide. While there is good reason to belive that ML and Haskell are better suited to many problems than C, it is harder to argue that ML is more productive than Erlang or pure Lisp, for example, based on static vs. dynamic typing.

Re:Why Functional Matters

[Junks Jerzey]

Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.

This is the kind of thing that scares people away from FP.

What's you're suggesting is pedantic in the extreme. In OOP, the complexity moves from raw code into the class hierarchy. That is, the code may look simple, but there's an elaborate framework that you need to understand as well. In the type of programming you're proposing, the complexity moves into the type system. Once you've painstakingly developed all the types you need, including algebraic properties and restrictions, then you've done most of the work. The resulting code may look simple, but, again, there's complexity elsewhere.

In general, it is a mistake to build up fancy mechanisms for simple tasks. In most programming, the typing is very simple. I find it easier to develop a program without regard to type, and then put the types in later. Otherwise I'm doing extra work for a prototype that may, in the end, be incorrect. Imagine if you couldn't just email a note to someone without diagramming each sentence to show that it is, in fact, grammatically correct. To a linguist, yes, maybe that is interesting, but not to everyone else. Programming is not the same as programming language theory. If it were, then no one would ever have been able to write code in C, C++, assembly, or Lisp, as those languages don't force you to specify every step of the way.

Re:Why Functional Matters

[Ungrounded Lightning]

Many of these indirect benefits are not actually characteristic of functional languages, but are easily available in imperitive languages. Some examples:

- Concurrency. Writing concurrent programs in a functional language is so much more natural. It's easier to avoid certain kinds of race conditions too, since you don't update variables in a functional language.

OOP does this well, also. There are several approaches. One method is to use "actors" (objects whose instantiation represents a thread of execution, where message-send represents an actual intertask message rather than a function call).

A major part of preventing interthread trouble is to use a style where variables are private, manipulated by accessor functions. Then you can build the concurrency control into either the accessor or the inter-object messaging.

It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful.

Actually, it's been done. A notable example is C++. A problem, though, is that classes and books on C++ tend to put their focus on the wrong parts of the language, neglect to teach the use of types as a means of encoding programmer's intent.

Features of functional languages like garbage collection and non-updatable values make it easier to define a language with a powerful type system.

Non-updatable values ("const") are readily available in C++.

Genaralized garbage collection can be built on top of it with some effort. But the language supports four distinct storage regimes for objects (static, dynamic, member, and heap), rather than a garbage-collector-based language's one.

The politically-correct method for handling heap-allocated objects in C++ is with explicit allocation and freeing, then building (or importing by inheritance) appropriate automation for particular classes' usage patterns as appropriate.

Using garbabe collection as the primary has several problems:

- It leads to a style of constructing composite objects as a web of primitive heap-allocated objects, rather than a single object. This vastly increasing the storage management overhead.

- It has unfortunate interactions with finalization (destruction), a very important semantic construct in C++'s style of OOP.

- Garbage collectors tend to work well only for particular patterns of usage - and are usually optimized for program development. This leads to variable and hard-to-characterize latencies in time-critical production applications. (C++ lets you use GC only on those classes that need it, and to use distinct garbage collection schemes for different objects, according to their needs.)

(What keeps C++ from being a nearly ideal language for practical OOP is an obscure hole in the standard: The deliberate, explicit failure to specify which overriding of a virtual member function is invoked if one is called during construction/destruction of member variables of object type. It SHOULD be the derived class' version from the first executable statement of the constructor to the last of the destructor, and base class' version otherwise.)

- Machine independence. Making a type system usually means hiding away the details of the machine, and this usually means that the execution of your program is completely predictable. (Compare to C/C++ "undefined" behavior!)

This is the result of C++ inheritance of C's ambiguous primitive data types. The standard workaround (also available in C) is to construct a small, machine dependent include file that defines a set of unambiguous types (i.e. int_16, uint_32), then use THOSE instead of the primitives elsewhere in the code.

Signature Ascription - This allows you to define abstract data types by naming a type and some operations on it (and their types). This is similar to header files in C (much more refined), but thanks to the type system, you can guarantee that the user can ONLY use your abstract data type the way you intended. They cannot cast, subclass, or use any other tricks to get at your datatype.

For defining abstract interfaces: Abstract base classes. (One or more member functions are not defined until the concrete subclass.)

To protect the guts from tampering: private member variables and private functions.

Yes, you can get around the protection. C++ explicitly gives you enough rope to hang yourself. But you have to express your INTENT to violate the protection by a particular set of casts, or you end up buried in warning messages and NOT trashing the variable.

Re:Why Functional Matters

[plumby]

You can achieve the same in C++/Java by creating a point class. But in either case, creating the (x,y) pair as (y,x) is still possible. I don't see how a language can guarantee to stop all errors. It doesn't know what you are trying to achieve. If what you were trying to do was flip the graphic by reversing x and y, then the language won't know that, and won't flag up an error if you fail to do this in you function.

Re:Why Functional Matters

[Chilli]

Nobody says that you can catch all errors with a good type system, but my experience with writing (lots of) Haskell is that a good type system can catch a lot of errors - in particular also a large number of logical errors. Personally, I would say that Haskell catches at least half (probably much more) of the errors during compilation that would lead to a core dump in a C program.

This of course implies that you make good use of the type system and choose good type abstractions and annotate all top-level functions with type signatures.

Chilli

PS: Look at my Web page, I have written a lot of Haskell code and it works very well for me.

Re:Why Functional Matters

[King Babar]

Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.

This is the kind of thing that scares people away from FP.

What's you're suggesting is pedantic in the extreme. In OOP, the complexity moves from raw code into the class hierarchy. That is, the code may look simple, but there's an elaborate framework that you need to understand as well. In the type of programming you're proposing, the complexity moves into the type system.

Uh, not in the examples *I* gave. Which you ignored, for some reason. None of the examples I gave required any complexity in the typing system. Shoot, I didn't even mention anything that would require type inference, or anything you couldn't do in OO. (Which is, of course, why I gave Cardelli as the reference: he's an OO champion, not a flunky for the flat-earth functionalists. :-))

Maybe a more charitable reading of what you said is that typeful programming could induce complexity in the type hierarchy (rather than the system itself). And I do have some sympathy for that. But one of the nice things about, e.g., Haskell, is that it performs type inference in addition to type checking, so that in many cases, I can gain a lot of the nicest benefits of strict typing for relatively little cost.

Once you've painstakingly developed all the types you need, including algebraic properties and restrictions, then you've done most of the work. The resulting code may look simple, but, again, there's complexity elsewhere.

But, of course, very few people even in functional circles program like that. You really don't have to. But even if I were to concede that programming thoughtfully takes more work, you point out for me that the resulting code may look or be simpler. If for no other reason than the fact that you have cleanly expressed and yet strongly encapsulated the assumptions you are making about the values you are manipulating. Now, if somebody comes along after you and has to modify code you wrote, yes, they will have to absorb some aspects of the design that go beyond the neat and simple functions used to express the answer. But at least they know where to look for this information.

In general, it is a mistake to build up fancy mechanisms for simple tasks. In most programming, the typing is very simple.

In general, I think people over-estimate the simplicity of programming. Indeed, if programming were so simple than we would expect to see a far larger number of accomplished programmers than we do see.

[snip]
Imagine if you couldn't just email a note to someone without diagramming each sentence to show that it is, in fact, grammatically correct.

Now this is the ironic part. Categorical grammarians (among others) have explicitly suggested that we don't have to do this to communicate because the constituents of sentences can be understood to have specific (often higher order) types, known to us all, and that the computation of meaning depends strongly on these types. In other words, we can just knock off an email to somebody in simple language precisely because we are so constrained by some kind of type system. Now, interestingly, research done on what this type system might look like by Aarne Rante suggests it *is* a doozy of a type system. (And is possibly mathematically inconsistent, to boot.)

Programming is not the same as programming language theory. If it were, then no one would ever have been able to write code in C, C++, assembly, or Lisp, as those languages don't force you to specify every step of the way.

Wow. I guess I'm really missing something here. Leaving out Lisp for a moment, the usual argument about C, C++ or assembly is just the opposite of what you say it is. The problem with many procedural languages is precisely that you have to specify every step of the way, every check for a bad value that can't be excluded by the type system, every memory allocation and de-allocation, every decision about sequencing and evaluation order and everything else. You've done all that, but you still might have missed the branch or failed condition that now causes your program to dump core.

Of course, there are reasons for doing this, the key one being execution efficiency, or what we might call inner loop thinking. The irony of this, of course, being that this kind of code is the kind most likely to have been directly transliterated from some kind of mathematical proof or formula, where typing considerations were in effect. So what the programmer did was some kind of fancy translation from a theorem to a nicely optimized block of low-level instructions that are likely to execute perfectly. Meanwhile, that programmer or some other didn't check for an error returned by the 13th fetch of data from disk, leading to a garbage result.

Re:Why Functional Matters

[BinxBolling]

You can achieve the same in C++/Java by creating a point class.

I'm well aware of that - I've done exactly what I described in C++. My point wasn't about ML (or any other functional language) vs. imperative languages, but rather, strong typing (which C++ has) vs. weak.

But in either case, creating the (x,y) pair as (y,x) is still possible. I don't see how a language can guarantee to stop all errors. It doesn't know what you are trying to achieve. If what you were trying to do was flip the graphic by reversing x and y, then the language won't know that, and won't flag up an error if you fail to do this in you function.

That's funny. I don't see where I or anyone else claimed that a language would 'stop all errors'. A technique need not stop all errors to be worthwhile. The fact that perfection is impossible is no excuse not to seek improvements.

As for your example of reversing x & y in the parameters to the point constructor: Good point, but if you've spent enough time dealing with geometry, the (x, y, z) ordering of coordinates is instinctive, and thus you're far less likely to make this mistake than to confuse (x, y, width, height) with (x, width, y, height). And if you want to 'transpose' a graphic (which is what reversing x & y would do), well, why not encapsulate that functionality into a method on your graphic class? That way you only have to get it right once, then never think about it again.

Re:Why Functional Matters

[plumby]

I'm well aware of that - I've done exactly what I described in C++. My point wasn't about ML (or any other functional language) vs. imperative languages, but rather, strong typing (which C++ has) vs. weak.

However, the entire thread(Why Functional Matters) is about the advantage of functional v non-functional. So that's probably a bit off topic.

That's funny. I don't see where I or anyone else claimed that a language would 'stop all errors'. A technique need not stop all errors to be worthwhile. The fact that perfection is impossible is no excuse not to seek improvements

What else did Tom7's "Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work. " mean then?

As for your example of reversing x & y in the parameters to the point constructor: Good point, but if you've spent enough time dealing with geometry, the (x, y, z) ordering of coordinates is instinctive, and thus you're far less likely to make this mistake than to confuse (x, y, width, height) with (x, width, y, height). And if you want to 'transpose' a graphic (which is what reversing x & y would do), well, why not encapsulate that functionality into a method on your graphic class? That way you only have to get it right once, then never think about it again

Again, none of this has to do with functional programming, or why "Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work. ". It is just "If you write your programs correctly, they just work."

Re: bad Perl? Maybe...

[Wolfkin]

Or else you never learned the language.

You're right, I've never used Perl for anything serious. OTOH, that's true with Lisp, Scheme, C, and Python, too, but those all make at least a little sense to the unlearned novice.

When I mentioned, above, that Perl seemed hard to pronounce, I wasn't kidding. It's *far* easier for me to mentally talk to myself about code in other languages, which means that I'm idly thinking about snippets of code and miscellaneous other features even while doing completely unrelated tasks. Unless I assigned specific non-name sounds to the various symbols used in Perl, it's very difficult to do that. This translates into having thought about other languages far more than Perl, so that I'm more comfortable in Python, Lisp, C, etc, even though Perl was the first one I seriously looked at and read tutorials for.

Maybe someone should come up with a pronunciation guide for Perl: How to Speak Perl, for Novices. ;)

Randall.

Claims Substantiated

[Tom7]

Sure, I'd love to! I think most of your negative experience comes from using List/Scheme (a cute but not very modern functional language). ML is a whole different world.

concurrent programs are written in C/C++

Yes, most software is written in C, C++ and Java. I was just saying that it's easier to do in ML, partly due to the functional style and type system.

-debugging Lisp/Scheme is ridiculously problematic compared with C/C++/Java. I don't know about the current status of ML.

Absolutely true. Lisp and Scheme have no type system to speak of, so they allow lots of incorrect programs to run. Debugging could be easier with a good tool (one that showed the current expression and let you step through evaluation is invaluable). But it's easiest with a strong type system like ML's. Most simple programming errors (that nonetheless take forever to find with C/C++/Java/Lisp/Scheme/...) are caught at compile-type by the static type checking. I do program a lot in ML, including big programs, and I've found that most of my debugging needs are solved by:

Typechecker (~97%)

print statements (~2%)

careful consideration of code (~1%)

... and trace elements of voodoo or grad students. ;)

I hear that there are some good debuggers for ML (Harlequin MLWorks had one, for instance), but I've honestly never needed one.

-and the programs run slower.

Lisp programs certainly do. Modern ML compilers produce real machine code and are catching up to C++. (It's possible we may surpass them, due to reasons I outlined in my earlier post!) I'd consider the speed difference not important (except as a goal for us compiler hackers!) unless you're writing Quake 4... the other features of the language more than make up for it.

The major novelty in the course I had taken was the transformations needed to implement continuation based programming.

Doing CPS conversion by hand sounds painful. But it's the most appropriate way of compiling a functional language and it gets you higher-order functions, among other things. The compiler does it for you, though, so why is that a detriment to functional languages? I happen to think it's pretty elegant, but of course that's just my taste. =)

Continuations is another very neat programming trick which isn't available in imperative languages. It's sometimes very hard to wrap your head around, but you can do some really nice stuff with them.

Sorry: but applying the same operation to all elements of a set is not recursion.

Application is not really recursive or functional (though it can be done very elegantly with recursion). But mapping an operation over a set to get a new set is certainly functional. Doing a set union is definitely recursive. Lots of data structures are recursive (balanced binary trees being the paramount example). The structure of a programming language is usually recursive, as are the operations you perform on it to parse/compile. Nature is quite recursive... remember the fractal craze of the early 90s?

I can't understand what you mean by "bad math". How can math be bad?

Re:Claims Substantiated

[boloni]

Yes, I remember the fractal craze. It sort of boiled down, isn't it? And if you think of physics and chemistry, you know that nature is not recursive and lower level structures do not repeat the higher ones.

Yes, a lot of important data structures are recursive. And obviously procedural languages do support recursion.

Now about bad math. There are an infinite number of things you can work it in math. I would say that choosing to spend your life with something like continuity properties on equations without solution is a meaningless enterprise, but that's their problem. It is certainly a valid research theme.

BUT. When you propose an axiome system to describe the world and you are teaching it as the supreme solution, you are making a claim, and if the claim is not valid, it is bad math.

Now, change and time is an important property of the real world. The functional model can not capture this property, while the procedural model can. (It does not offer a good framework to reason about it, but that's something else).

For example: the functional model can not capture the fact that an algorithm can be a series of steps, in time, to be executed in a special order and at special steps. Most intelligent agents were used in this way.

Also, variables: my body temperature is sometimes higher, sometimes lower. This is very simply captured in a variable. It is conceptually impossible to fit in the functional model (and neither in the logical programming one, btw).

Ok, you can make a hack. They are computationally complete, but that's a bit of bullshit (sorry) because the Turing machine was not intended as being a panacea of describing the universe, only a model to compute the value of certain type of functions.

Still, the Turing machine itself captures change and time better than Lisp or Prolog.

So, when I say bad math, I don't mean that the proofs are flawed. I mean that the ones who proposed the formalism were misunderstanding the problem the formalism will be used for, which is to create programs working in a world evolving in time, in the presence of user interactions and other unpredictable elements.

best wishes
Lotzi B.

BTW: Why do you think that type systems are specific to functional programming? I think that is a completely orthogonal problem to this...

Re:Claims Substantiated

[nhw]

I don't think static typing is very mathematical anyway.

You're kidding, right? Have you ever looked at the way a Hindley-Milner type inferencing system works? And noticed that the inference rules correspond almost directly to the rules of intuitionistic logic?

It's certainly a mathematical task.

Cheers, Nick.

Re:Claims Substantiated

[Tom7]

BUT. When you propose an axiom system to describe the world and you are teaching it as the supreme solution, you are making a claim, and if the claim is not valid, it is bad math.

Ok, I understand. Maybe some people try to evangelize in a way which makes it seem like they think it's the Ultimate Solution. Most researchers, though, study functional languages in an attempt to improve them, and they do it because they really believe it's a good solution. (I don't think anybody knows for sure what the "right" way to program is!) Maybe in the end we're wrong, but we've got a lot of good reasons and results to show we're probably not...

If I find a language enjoyable to program in, and I can use it to complete the tasks I need to complete.. well, what's bad about that?

As for your comments about time/state in a functional language... I think you are working under a tragic misconception. Functional languages absolutely have state and a concept of ordering (time).

How do you express your body's changing temperature? Perhaps you have a for loop which operates with an object in scope, where a field of the object represents your temperature.

In ML, you'd just have a recursive function, which takes a record (object) representing your body -- when you want to change the body temperature, you'd just pass a record with a different temperature field to the recursive call.

Of course, you need side effects for some things. ML has imperative features, including updatable cells, arrays, and IO. In any real application you'll see this stuff, but the majority of code is usually done functionally.

A purely functional language like Haskell has Monads, which are a way of encapsulating effects. This is really elegant.

BTW: Why do you think that type systems are specific to functional programming? I think that is a completely orthogonal problem to this...

Most interesting type systems are based on the same sort of math (polymorphic lambdacalculus) that functional languages are based on. Maybe I'm just reading the wrong journals, but that's what I see.

Re:Claims Substantiated

[Ian Bicking]

...I've found that most of my debugging needs are solved by:

Typechecker (~97%)

I have yet to see a difficult bug that is caught by a typechecker. Sure, typos, incorrect order of arguments, etc. These are the easy bugs, the ones that take little time to deal with in any system. The difficult bugs are ones where the program works, but works incorrectly. These are the time-suckers.

Fine-grained inspection of the system (objects and execution state) are what make for a good debugging system. gdb is okay -- certainly better than print statements and Deep Thought. Squeak still has the most pleasant and helpful debugger I've used -- in part because it was never an afterthought, being a language not created by mathematicians with fantasies of Correctness.

I don't think static typing is very mathematical anyway. Most higher math deals with things in terms of properties, not types. The analog in CS is methods. If something implements mathematical operations then it's a number, what the object actually is isn't terribly important.
--

Re:Claims Substantiated

[Estanislao Mart�nez]

Most higher math deals with things in terms of properties, not types.

Bah. There is no important distinction here. It is a perfectly standard thing to regard properties are objects of types X->t; that is, functions mapping individuals of type X to truth values.

Re:Functional Programming has a bad rap

[Scott_Marks]

Whoops, hit Submit instead of Preview before I was done. Anyway, here's most of the rest:

So, why did procedural languages win? I think it was really just a case of not adequately optimizing otu tail recursion in Pascal compilers. In the early days of the explosion of computer science, everybody learned Pascal, and if your recursion got too deep, the stack blew, so you were taught to think of recursion as an exotic technique to handle special problems. Of course, when it got around to establishing loop invariants so that iterative code could be proved correct, it was like pulling teeth, but who tried proving his programs correct, anyway?

And it probably didn't help that Edsger Dijkstra was the Goto Considered Harmful man, since everybody knew those Europeans didn't really know how to program real programs! Just look at Algol, compared to real languages like COBOL or FORTRAN for crissakes!

I guess my bottom line is that the prevalance of procedural programming over functional programming was sort of a cultural brain fart, a malignant meme which established itself as part of the global memone before anyone had a chance to fight it.

Duh - look at the processors we're using.

[Troy2000]

I don't use C/C++ because I think its the greatest language in the world - I use it because other than writing in ASM, its my best bet for speed-critical code. (I guess its only fair to mention that I'm the sort of programmer who thinks just about everything is speed-critical.) Processors of today (and tomorrow) inherently lend themselves to executing code instruction-by-instruction (step-by-step). Not functionally. In order to target a functional language to our processors, a lot of behind-our-back work has to be done - and I despise anything that does a significant amount work (in software) behind my back.

Functional languages are interesting and useful enough for me to not have a "throw them all away" attitude. But at the same time, if someone told me I should be programming in one, I'd laugh at them.

Re: Parenth's

[jacobm]

The two goals- ease of parsing and ease of programming, are not necessarily opposed to each other, and in fact they're usually complementary.

If the source code for your parser is 2 megabytes, that means that there are two megabytes worth of syntax rules that the computer needs to know to parse the language correctly- and if a programmer wants to write good code that uses all the features of the language, that programmer has to have 2 megabytes worth of syntax rules in his or her head. Even though I've been programming in C++ for a lot longer than I've been programming in Scheme, I still go to the reference manuals for C++ syntax far more frequently than I go to the manuals for Scheme syntax. (Incidentally, I once wrote a parser for a language that had the same syntax as Scheme, and it was about 300 lines long.)
--
-jacob

Re:Recursive Thinking

[Rod Blaze V]

that is a fucking nightmare

Effects

[Tom7]

Anonymous coward wonders,

"pop quiz, hotshot. If side effects aren't allowed, how do you handle minor things like... oh I don't know.... USERS????????????"

In Haskell, Monads. These are a purely functional way of dealing with effects.

In ML, we have imperative features for doing stuff like IO. You can't do the same kinds of beautiful things you can do when programming functionally, but you can still do it (and it's still typed!).

Re:Effects

[jallen02]

Haskell Monads.. and it kind of mentions the fact that even though they are purely functional (whatever the heck that means) are still written like most any imperative code.. I was looking at some code snippets where it talked about that and its true I mean.. some things are going to have an imperative look to them no matter what just due to the nature of PC hardware.. Unless you really abstract stuff... but you lose just to much control IMO


If you think education is expensive, try ignornace

Probably already been mentioned and I missed it...

[wdavies]

Well apart from all the issues raised so far, the one I haven't seen addressed is how many external modules are developed for it.

So, I code in LISP, and great it is too, if I want to write my own code...watch peoples faces as you build up a function they need in 5 minutes.

However, let's say I want to do some XML processing - There is a CL-HTTP package that has some stuff in it. But XSLT Support ? Forgerraboutit....

Meanwhile, my Java colleagues are happily getting on with fighting Java, rather than worrying about the XSLT coding.

This is my take on one of LISP's problem - and maybe perhaps its just descended from the small number of users.

But it does kill me how hard it is even to get some basic system calls to work in LISP, where as Perl they come built-in....

Cheers,
Winton

Dialects of ML

[Tom7]

O'Caml is the "french dialect" of ML. O'Caml has a number of great usability enhancements over SML, as well as Buzzword Compliance (has OO primitives).

If you ever see any hacker projects in ML, they're probably in O'Caml. I can definitely understand its appeal. If you're interested in ML because of some of the testimony here, this might be the right dialect to choose.

In academia we prefer SML because it's a bit more "pure". AFAIK, the extensions in O'Caml haven't been proven safe (though they probably are). SML is still a very usable programming language, and the SML/NJ implementation has a lot of useful add-ons (like unsafe arrays, concurrency, call/cc, C function interface, compilation manager, etc.)

Of course, in the works is ML2000, which will incorporate some of the good ideas in O'Caml, as well as adding real subtyping, run-time generative types, and concurrency primitives. ML2000 will be a seriously impressive programming language.

Re:Dialects of ML

[kalifa]

> Of course, in the works is ML2000, which will
> incorporate some of the good ideas in O'Caml,
> as well as adding real subtyping, run-time
> generative types, and concurrency primitives.
> ML2000 will be a seriously impressive
> programming language.

Good, but please, try to avoid fragmentation and NIH-type competition between ML2000 and O'Caml. It would kill both (at least, it would prevent both to meet widespread success). If ML2000 can bring reunification, then great.

As far as I'm concerned, I would tend to say that the OO primitives in O'Caml bring more than "buzzword-compliance", because the OO design is really great in O'Caml. I mean, O'Caml may be the first language where the OO primitives can be useful :-)

Functional Programming Isn't What It Used To Be

[roffe]

Lisp used to be slow and textbooks used to count at exercizes in advanced mathemathical theorem-proving, but it just isn't like that anymore.

Modern Common Lisp-based systems run fast enough (if you know what you're doing, sometimes faster) than C++, come with advanced graphical interactive environments, are not prohitiviely expensive (demo versions are often fully functional but don't support standalone applications)

Consider the lack of market share a competitive advantage: If you code in Lisp and your competitors code in C++, you have an advantage.

Common Lisp is not Lisp as one might have been used to, either.

The most recent textbooks are good enough to get started and learn.

And finally, programming Common Lisp is fun! Get started, do some programming in your spare time, get some of the recent textbooks and before you know it, you'll use Common Lisp when you can, or let ideas from Common Lisp influence your coding.

Re: Parenth's

[Rob_D_Clark]

IMO, you are missing some of what makes scheme (and lisp) great... it's elegance is it's simplicity. If you haven't noticed, a scheme program is itself a text representation of a data structure, ie a list. This is a fairly powerful concept once you get it. It also makes it really easy to write a scheme interpreter... the part about being properly tail recursive is a bit more tricky, but still dead simple compared to something like C.

Another thing to think about is scheme's macro system... a scheme macro re-writes a part of the program, but because the simple form of the program, macros are far more powerful than what you are used to from CPP. A scheme interpreter can be implemented by only implementing 5 (or 4... define and set! can be the same) built in language constructs (define, set!, lambda, if, quote), and implementing the rest as macros. Let's see you do that with the c preprocessor!

Re: Newbie question

[alleria]

I tried OCaml for a bit, but when trying to read through the manual, I believe the first thing they came up with was some kind of generic list sorting algorithm. Way beyond my comprehension -- I had no idea what exactly the algorithm did, much less how it did it.

Abstraction + Debugging

[Tom7]

Why is it important for the language to mimic the machine? I find it much easier to understand something defined in terms of rules that are written down and precise, rather than designed in terms of "however the machine does it". (Though I can understand functional programming being uncomfortable to people used to programming imperatively. It took me 6 months to figure out...)

I've written about 30,000 lines of SML code in the last two years, and I've never needed a classic debugger. The type-checker is the debugger. (There also do exist classic debuggers for SML, btw).

I do agree that toolkits are lacking, and this is a clear reason why programmers who want to get something done wouldn't use a functional language.
But lots of people hack just for fun; why not try something new, guys? (maybe you can make a needed toolkit! ;))

Scheme seems dumb in the respect that

[MicroBerto]

Why does it use all parenthesis? That's impossible to get right on the first time :)

Mike Roberto
- GAIM: MicroBerto

Re:Scheme seems dumb in the respect that

[hey!]

I see this more as an academic issue.

The thing that the academics have grasped that the mareting suits haven't is that sometimes less is more. Goto is powerful, and powerful is never bad in a marketing context but it can be very bad from a maintainability context.

On the other hand, the thing that practicing programmers understand that academics don't understand is that sometimes, less is less.

I think functional languages are cool, and people should learn them/about them in school. But there's a reason they haven't caught on for non-trivial real world applications.

And, by the way, I don't consider scheme a functional language. You can program functionally in it, and it may even tend to encourage a more functional style, but I don't think that makes it functional.

Re:Scheme seems dumb in the respect that

[civilizedINTENSITY]

Mathematica is a non-trivial real world application. Seems to me that Mu-Math was written in Mu-Simp which was a functional language.

Re:Scheme seems dumb in the respect that

[weg]

There are functional languages that don't use so much parenthesis. Try SML (e.g. SML/NJ, you'll find it on http://cm.bell-labs.com/cm/cs/what/smlnj/index.htm l )

Re:Scheme seems dumb in the respect that

[jejones]

Ummm...Scheme and Lisp in general aren't pure functional languages, so they don't have the "limitations" I presume you're thinking of--you can do assignment in them. Haskell is pure, but has a "monad" facility that lets you safely isolate the imperative portion of your code from the applicative.

OTOH, the applicative subset of C isn't very pleasant; just try "currying" a C function. The rules that permit a simple stack to keep locals around in prevents one from doing it very nicely at all.

Re:Scheme seems dumb in the respect that

[Stephan Schulz]

But there's a reason they haven't caught on for non-trivial real world applications.

Emacs

AutoCAD

I write highly performance-oriented code in C. However, in Scheme I am a lot more productive for most other issues (amd I have a lot more experience with C than with Scheme). Map, lambda, and tail recursion are very powerful tools.

Re:Scheme seems dumb in the respect that

[lamz]

Oh, wait, you made a typo. This is what you should have written:

(Why does it use all parenthesis? (That's impossible to get right on the first time :))

Seriously, though. Functional languages limit the programmer, and although it could be argued that the limitations are good, there will always be less acceptance because of the limitations. Furthermore, if you want to do functional programming in C or Java, go right ahead. Those languages aren't stopping you. But if you want to do procedural in Lisp...


Mike van Lammeren

Re:Scheme seems dumb in the respect that

[hey!]

Sure, but lisp is not a pure functional language.

Re:Scheme seems dumb in the respect that

[hey!]

Interesting -- I didn't know that. I've never been able to afford Mathematica just for the fun of frobbing around with it.

However, I don't think this invalidates my point. Even if mathematica were free, I doubt it would be used widely for general purpose programming.

Re:Dev time would take a hit.

[dvdeug]

Utopial. We've got better development languages now, no language will probably be much better than C at protable assembly, and above all:

"There is no silver bullet." - Fred Brooks

Prototyping

[nhorton]

I have used Haskell a lot but usually use Java. I find that Haskell is a bit hard to use for massive projects but for prototyping and testing ideas it is hard to beat. You can test ideas in functional languages in a couple minutes rather than hours.

Re:Prototyping

[Suslik]

An actual benchmark here. I had a Christmas puzzle that involved placing 4x4 tiles so that coloured patterns on the edges matched. Failing to do it manually, I wrote a Haskell program to solve it -- 2 hours to write, 20 seconds to run, gave all the solutions. I then developed a C program to do the same thing. About six hours to write, less than 2 seconds to run.

Haskell is cool. But, like any other language, it is only suitable for a certain class of problems. Use it outside that, and suffer.

Adrian

PS What happened to Orwell?

Re:Prototyping

[drnomad]

20 seconds to run?
Did you use hugs? You know, Haskell isn't the only functional language, So are Miranda, Amanda and Kleisly.
Miranda even is a compiler while HUGS defenitly is not

Re:Prototyping

[brucehoult]

An actual benchmark here. I had a Christmas puzzle that involved placing 4x4 tiles so that coloured patterns on the edges matched. Failing to do it manually, I wrote a Haskell program to solve it -- 2 hours to write, 20 seconds to run, gave all the solutions. I then developed a C program to do the same thing. About six hours to write, less than 2 seconds to run.

I had a similar experience about ten years ago. Visiting a friend's place they had a puzzle that sounds similar -- squares with four turtle heads or tails on them and you had to match them. The only computer they had was a Mac Plus with Turbo Pascal. 45 minutes of coding and 10 seconds of runtime later, we had all the solutions.

Using this test, Pascal is a better prototyping language than is Haskell.

Oh, and that was on an 8 MHz Mac Plus. The runtime on a modern system would be undetectable.

Bloody Larry Wall ...

[Nicolas MONNET]

You sinner ... you must have written too much perl ... REAL programmers (that is, those at MIT) love to ignore the fact that human languages are above all context-sensitive (as Perl is to some extent), as opposed to Lisp variants which have completely context-free grammars.

Re:Bloody Larry Wall ...

[Rob_D_Clark]

Hmm, I always thought the context free grammar was easier to understand... I would rather read someone else's scheme code than perl!

Re:Bloody Larry Wall ...

[one-egg]

Different people's minds work in different ways. The FP fanatics have minds that happen to be in the minority.

If your mind works one way, FP seems "simple" and "natural." If your mind works another way, FP is convoluted and hard to understand. (That happens to describe most people.) And if your mind works a third way, somewhere in the middle, FP is just another technique that is useful in the right situation and inappropriate in others.

One problem is that the minority contingent has failed to recognize that they are unusual, and in their eagerness to convert others they have overstated the benefits of FP. Yes, anybody can learn to write simple functional programs. There is even evidence to suggest that beginning programming classes are best taught in a functional language. But FP is not a panacea, any more than COBOL was.

Re:Bloody Larry Wall ...

[Nicolas MONNET]

Great Any! If you don't need something more natural than assembly code, why don't we just use assembly language?

Re:Bloody Larry Wall ...

[blue trane]

Oops. I guess you forgot that computer and natural languages serve different purposes, and that the ambiguity that context-sensitivity brings along is undesirable when you're trying to get a computer to do something? Unless you're trying to get a computer to deal with ambiguous data (hence, Fuzzy Logic).

Stop sniveling and write the damn code

[ArmorFiend]

Dude, you just gots to write the code in whatever language you want. I've been developing 3d graphics in Common Lisp for over 3 years. Sometimes its too slow, othertimes its fast enough. You just got fix the too-slow parts. Parenthesis whiners: You're not the first to think this. If you just bite the bullet and learn to use emacs, they conceptually disappear. Further, they really help: parens help you write programs that write themselves. When you get really good, they can actually help you edit your code faster. If you don't understand what (lambda (x) x) is, then for crying out loud DON'T USE IT. Instead use named functions (defun identity (x) x). Nobody ever got fired for using named functions. :) Ultimately you just have to ignore the herd mentality and the silver-bullet mentality. Go with the language that suits YOUR needs. Don't be totally close minded, but if Lisp were the silver bullet it claims to be then it would have produced more than it has by now, if you get my meaning. Personally, I favor the Common Lisp environment, the rediculously high level language features, the powerful macro facility, and yes the parenthesis.

Re:You are in a fashion industry

[umeshunni]

So does this mean that C# is going to be the next big thing ?
From what you say.. Yes!
Support ? Well with the biggest software company in the world behind them, You can be hell sure about the kind of support you get for C#. MSDN CDs filled with .chm files for C#. Hordes of MCSE's or whatever they're called 'graduating' from one training center after another armed with C# knowledge.
Preformance ? Win200x Dll's tuned to give best response times/ higher priority to programs compiled with C# ( wierd but possible! ). A C# interpreter or some sort as part of the ntoskernel ?
Tool Support ? MSDev has it all doesn't it ?
No one will get fired for buying C# as well ( if they do, M$ will hire them!)
Trained Staff ? See pt one.
Well C# seems to possess all the qualities you stated, come to think of it so does VB. so why wasn't VB the next big thing ?

-u2

Blah! Time for Assmbler!

[BWS]

I think we need to screw this whole Functional/Procedural/OOP Languages and go back to plain old Assmbler :)

add $brain, $beer, food

*G*
heheheh :)

Re:Blah! Time for Assmbler!

[mindstrm]

Assembler is still largely procedural ;)

Scheme is not the only functional language

[Tom7]

Scheme is OK, but it's pretty scarce on features compared to languages like Haskell and ML. In particular, it has no type system worth mentioning.

It's true that ML and Haskell are just as obscure (or more so), but you might find that they are powerful enough to warrant it. I do.

big plusses

[r]

here are my reasons for liking functional languages:

• elegance. abandoning side-effects is a huge step towards understandable code, and it makes math-like operations (such as applying a function over an array - cf. map) clear and easy to write.
  
• compilation. functional languages lend themselves to much better optimization than imperative languages (why? no side effects!), and it lets you do really powerful things, like full-code optimization (as opposed to standard block-based optimization). which leads us to...
  
• speed. granted, interpretation of functional languages can be pretty slow (then again, so it is with java :) ). but compilation is a different matter. ever tried to use the stalin scheme compiler? the damn thing compiles code that's faster than hand-written C!
  
• minimalism. while not necessarily a feature of all functional languages (say, lisp), minimalism is often a design goal in new fp's such as scheme. the single concept of continuations, for example, subsumes a large number of unrelated concepts from other languages, such as longjmps, try..catch loops, non-local exits, or gotos, and by doing that it makes explicit the similarities between them (and also leads to better optimizations, but i mentioned that already).
  
• expressiveness. and finally, the most visible aspect of fp - increased expressiveness. fp's make things like higher-order procedures suspiciously easy (and to think it took the whole hoopla over patterns to make the oo community realize the usefulness of higher-order procedures!). or take applications of functions over large sets of data - would you rather hand-craft loops upon loops, or just say (map fn data)?
  

any others?

Perl too

[Nicolas MONNET]

Perl can construct programs "on the fly". So can TCL, and so can (I believe?) Python. Probably not exactly with the same ease, since you must do it in ascii strings form (as in, you can't manipulate the syntax tree directly).

I however challenge your statement: "easier for the programmer to read". Human languages ARE *very* contextual. The real reason for Lisp being context free is because it is simpler to write a parser for it, and consequently, easier to make it bug free. Saying that a maze of parenthesis is easy to read is at best, hmmm, a fallacy.

Re:Perl too

[Shoeboy]

Perl can construct programs "on the fly". So can TCL, and so can (I believe?) Python. Probably not exactly with the same ease, since you must do it in ascii strings form (as in, you can't manipulate the syntax tree directly).
Um, yeah, practically any language can output code. You don't even have to use a turing complete language -- here's a T-SQL quine:
CREATE PROCEDURE print_me
AS exec(sp_helptext 'print_me')
As long as you have something like exec(), eval() or even system() you can generate and execute code on the fly.
--Shoeboy

Re:A couple of reasons:

[matrix00]

I just finished a Programming Lang. class and we worked in functional languages, specifically lambda calculus. It was very interesting, but I would take a LOT for The Public (tm) to get used to the ideas of functional languages.

Re:Dev time would take a hit.

[BinxBolling]

We've got better development languages now, no language will probably be much better than C at protable assembly, and above all:

"There is no silver bullet." - Fred Brooks

I think Brooks is probably a bit depressed at the nonsense that intellectually lazy people justify by quoting him out of context. Have you read "No Silver Bullet" recently? Do you remember what he really meant, in the line you quoted above? What he was saying in his essay was that there was no single technology that would lead to an order of magnitude improvement in programmer productivity. He sure as hell wasn't saying that better languages couldn't improve productivity. A language that doubled productivity wouldn't be a "silver bullet", by his definition. But so what? Doubling productivity is still an enormous improvement.

Mathematica is a functional language

[Claudius]

One functional programming language (and, for that matter, procedural programming language and rule-based programming language) that receives quite a bit of use today is Mathematica. While it is possible to write FORTRAN-like Mathematica code, it is rarely advantageous to do so, and functional programming is generally a more efficient way to write code in Mathematica. (Prior to executing a Mathematica statement the code is parsed into an equivalent functional form anyway, with this functional equivalent being what is what is fed to the interpreter. If one writes functionally almost all of the extra stuff going on behind the scenes that can make Mathematica dog-slow may be avoided).

(* Using built-in Table[] function *)
arr = Table[ (i^2 - 4), {i,1,10} ];
(* Procedural *)
Do[ arr[[i]] = (i^2 - 4), {i,1,10} ];
(* Functional *)
arr = #^2 - 4 & /@ Range[ 1, 10 ];
(* Rule-based *)
arr = Range[ 1, 10 ] /. {i_ -> (i^2 - 4)};

Re:Make C and Java functional

[Tom7]

The functional "if" statement is the ternary ?: operator.

I'd say C is kind of hopeless, though. I'd probably use the features if they were there just because I prefer functional programming -- but most the other nice things which come with modern functional languages couldn't work in C.

Java can be made functional with some sneaky object tricks. It's probably not worth it.

...but how do you do this is perl?

[anonymous moderator]

Isn't perl missing some of the nice higher order functions that functional languages have?

The times I use functional languages, I am trying to spend half the time programming I would in another language to solve a (usually mathematical) problem. For example...

fib = [0,1]++(zipWith (+) fib (tail fib))

is neat, obvious and readable haskell code, and I haven't seen it done so well in non-functional languages (please feel free to reply with neat versions of this in perl).

Re:...but how do you do this is perl?

[pb]

I don't know Haskell, and that doesn't look that obvious to me.

I gather that zipWith is like map, tail is a tail call to fib, and 0 and 1 are incremented or added somewhere in there; and of course I know what it's supposed to do. But the rest is lost on me at the moment. :)

However, if you can write it cleanly in Lisp or Scheme, I can probably translate it to Perl; it isn't that hard.
---
pb Reply or e-mail; don't vaguely moderate.

Re:...but how do you do this is perl?

[pb]

Well, another poster implied that it wasn't strictly a functional language feature he was using, per se...

...which is one reason why I asked him to write it in Scheme or LISP for me, the other being that I don't know Haskell. :)
---
pb Reply or e-mail; don't vaguely moderate.

Re:...but how do you do this is perl?

[jmalicki]

That's because Haskell has lazy evaluation that make it possible... ML or scheme or LISP cannot accept similar code, so it's not a matter of it being functional.

Arrogance, infighting, zealotry (sound familiar?)

[Junks Jerzey]

Arrogance. There is an annoying elitism among functional programming proponents, implying that all current Perl and Python and C++ programmers are wrong. Similarly, Linux zealots refuse to believe that multi-billion dollar corporations are being run using Windows 98 and NT.

Fragmentation and infighting. Some FP proponents insist that functional laziness is the key. Others think that laziness is unpredictable and does more harm than good. Some FP proponents insist that static typing systems are The Only Way. Others are very productive with dynamic typing and ignore the first group. Some FP proponents thing that uniqueness types or monads are the correct way to introduce the concept of state into a purely functional framework. Others don't care as much about purity, preferring to have imperative features readily available. Similarly, Linux zealots fight about distributions, text editors, and window managers.

Ignorance of what the market wants. Many FP language developers would prefer to do research on new type systems, rather than create useful libraries. Many think that language choice is more important than tool choice, as if ML would somehow be better at GUI-driven applications than Delphi. Similarly, Linux zealots think that operating system choice is more important than application choice, and many would prefer to live in a backward 1970s terminal window world without trying to understand why many people don't want to.

But what features will sheep have??

[xconfig]

How about letting us in on the features of sheep that current languages don't have?

Re:But what features will sheep have??

[Maggot75]

A sheep is the perfect companion.
It can be used for some serious loving, as any welshman will tell you, it's wool will keep you warm, and you can eat it.
You just can't beat sheep.

Other non-parentheses functional languages

[Tom7]

Haskell and ML both have very reasonable syntax. Not so many parentheses. ML's syntax is less verbose than C's, even; you don't need to end lines with semicolons, and you don't need to declare the types of variables.

Re:Employees resist as well

[John Jorsett]

I can't say what the percentage of Java jobs are web work, but the Java work I'm presently doing is a communications system for the military, and quite challenging. I blush to say what I'm charging the customer, but let's just say the compensation is more than adequate. And I know of another project going on with 20 or so programmers developing a large Java app employing network comms, database acess, and all the big-time stuff one associates with systems work. Bottom line, even if Java work were as bad as you say, I suspect most people would rather be employed Java coders if the other choice was to be an unemployed obscure-functional-language coders.

Re:Functional Programming: its above our heads

[GodSpiral]

For this reason, I think the best way to incorporate functional paradigms is to extend our imperative languages with functional features:

First class functions, tail recursion optimizations, generics, and so on.

this would leverage GUIs, debuggers, and not force everyone to shoehorn all problems into a functional solution.

Two pragmatic reasons

[DragonHawk]

Personally (and here I'm in Armchair-Professor mode, so don't take this too seriously), I see two (related) reasons why imperative languages get more use then functional ones:

1. Imperative languages more closely model the way the computer works.

2. Imperative languages more closely model the way most people think about doing things.

When people write instructions for something, they generally use an imperative, procedural format. "To build a car, follow these steps." They break things down into subroutines, and call them as needed. "For step #105, you need a door. To build a door, follow these steps."

Perhaps this is cultural, perhaps it is biological, perhaps it just depends on the person. But it does seem to be the way it is. Thinking in the imperative style is just easier for most people, and like water, people follow the path of least resistance. After that starts, network effects only reinforce things.

I see you've been 'Harperized' too. (corrected)

[Convergence]

(Professor Robert Harper is one of the creators of Standard ML, and a very neat guy. BTW, if you could feed me some info on the TILT project, I'd love to study the compiler.. TILT is where the Python LISP compiler was about 8 years ago.)

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. (~30% slower at things like matrix multiplication, bench it yourself) , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros'
A simple example is a 3-way if-then. (:less, :greater, :equal).
A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)

For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!

They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!

If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)

As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good. :)

Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as


(defun twofish-make-fun (key)
(compile nil `#'(lambda (block) (twofish-encrypt block ,key)))


This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)

There are some nice advantages to having a simple syntax. :)

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)

Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false. :) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.

In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.

These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.

(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)

Re:You are in a fashion industry

[pohl]

Around my neck of the woods, VB was the Next Big Thing for years...fortunately, Java seems to be taking that title.

Re:(Objective) Caml may be a solution

[Dag Hammerskjold]

"One could think of a new type of desktop environment . . ."

One certainly could. There is one thing wrong with Objective Caml, though: it is written in C, or at least bootstraps through C. While this is good for "interoperability", it is not so good for surveyability. System 3 Oberon is the real thing. Oberon isn't a functional language, but the latest beta of S3 Native Oberon (runs as its own OS on x86) comes with a Scheme module written by Erich Oswald. S3 with the Gadgets desktop is a complete GUI -- a strange one, in that it is completely modeless.

It is fun to install a new OS on its own partition, although you can also run a version on top of Linux -- the Oberon desktop in an X window.

From http://www.oberon.ethz.ch/native/:

"Native Oberon is written in the original Oberon language designed by Niklaus Wirth. The system is an evolution of the operating system
co-developed by Niklaus Wirth and Jürg Gutknecht and published in the book Project Oberon: The Design of an Operating System and Compiler,
Addison-Wesley, 1992. The system is completely modular and all parts of it are dynamically loaded on-demand. Persistent object and rich text
support is built into the kernel. Clickable commands embedded in "tool" texts are used as a transparent, modeless, highly customizable and
low-overhead user interface, which minimizes non-visible state information. Mouse "interclicks" enable fast text editing. An efficient multitasking
model is supported in a single-process by using short-running commands and cooperative background task handlers. The basic system is small -
it fits on one 1.44Mb installation diskette, including the compiler and TCP/IP networking. It is freely downloadable (with source code) for
non-commercial use.

An optional GUI component framework called Gadgets is available, with integrated WWW support (FTP, Telnet and HTTP on Ethernet, SLIP or
PPP). Many useful applications are available, and the system has been used to build embedded systems. Portable applications can be developed
that run on Native Oberon and the other versions of ETH Oberon hosted on other platforms, e.g., Windows, Linux (Intel x86 and PowerPC),
Solaris, etc. The LNO version of Native Oberon runs on Linux, but is binary compatible with PC Native Oberon. It was created by replacing a few
low-level modules of the system with Linux implementations. "

Re:Whatever happened to Miranda?

[John Meacham]

Haskell is pretty much a decendant from miranda, miranda was developed by a closed group of developers and i belive still is. haskell took many of the good ideas of miranda and created a basis for a publicly developed and availible language.. haskell is now THE de facto standard lazy language...

Re:Functional Programming: its above our heads

[Ars-Fartsica]

Perl does not have garbage collection, it has reference counting.

Which is used to implement garbage collection. to quote perldoc perlguts:

Perl uses an reference count-driven garbage collection mechanism. SVs, AVs, or HVs (xV for short in the following) start their life with a reference count of 1. If the reference count of an xV ever drops to 0, then it will be destroyed and its memory made available for reuse.

I can do the same thing in C++

sure, if you want to buy it from someone, install a third-party package, or roll your own. Why???

Personally I don't care what Bjarne thinks. Though C++ may have been able to provide more of a standard if it had a larger library, it most likely would have meant that no one would be standards compliant, or they'd take their own sweet time about it. When people invest time and money into their own frameworks, they've little interest in implementing "C++ Standard Network" and "C++ Standard GUI."

I don't understand your point - are you saying that it is preferrable not to have standard libraries? Do you see some value in re-implementing core functionality??

(Objective) Caml may be a solution

[kalifa]

There are tons of good reasons which can explain the failure of functional languages. Timing, installed basis, syntax familiarity, performance, fragmentation, worst-is-better (timing, again), marketing, etc...

I don't think Scheme can't change that. It has been around for 25 years now, hasn't really taken off, and is more fragmented than ever. Besides, many people are still reluctant toward this lisp-type syntax. I don't see why Haskell could change that either: it's nice, but it has a very small installed basis, which is not growing very fast. It cannot be used for system programming and big projects, and it suffers serious competition on smaller projects from fast-growing procedural "elegant" high-level languages, especially Python. Eventually, I don't see why Common Lisp should succeed now, after years of disappointments and decline.

Here's the problem: try to imagine a functionnal language, whose compilers bring performance that are far superior than Java compilers', and approximately as good as C++ compilers'. This language should be highly portable, suitable for Java-types applets, and have an object-orientation design at least as good ad Java's and CLOS. Its syntax should be more attractive than Lisp's, it should be interpreted and convenient to use and debug via a command-line interpreter just the way Python or Lisp dialects are, and in the same time, as mentioned above, compilable into a very fast executable code. It should also be able to interoperate wich C modules (and maybe others). And, besides all these qualities, it should also be much more than that, and bring other unique advantages.

Such a language exists, it is called Objective Caml. One thing only is missing, the most important one, the installed basis. So there is a need to create the ecosystem. Here's a suggestion:

One could think of a new type of desktop environment which would be based on Objective Caml. Emacs users know that Emacs is an incredibly powerful and convenient Lisp environment, which is unfortunately limited to textual tasks, due to the limitations of Emacs Lisp (at the beginning, Emacs Lisp was supposed to be used solely as a macro language for an editor, and it has gone much beyond that). Imagine an environment in the spirit of Emacs (highly integrated, fully extensible, customizable, reconfigurable and reinterpretable when you use it, etc...), but whose scope would not be limited to textual tasks, and which could actually serve as a full "multimedia-hype-buzzword-whatever" universal desktop. To put it another way, try to imagine an Emacs type environment which would cover all the functionnalities of a, say, MacOS X or Windows user environment. It this is doable, then it's in Objective Caml.

Now, I know, I have a big mouth, and I should show some code. Anyway, comments appreciated.

Re:(Objective) Caml may be a solution

[Chalst]

What is surveyability?

Re:(Objective) Caml may be a solution

[kim_rutherford]

Such a language exists, it is called Objective Caml. One thing only is missing, the most important one, the installed basis.

The other thing that is missing is a good license. The OCaml compiler currently uses the Q Public License, which means modified versions can only be distributed as patches.

(BTW. I agree that OCaml is an excellent language).

Re:(Objective) Caml may be a solution

[kalifa]

> The OCaml compiler currently uses the Q Public
> License, which means modified versions can only
> be distributed as patches.

While I usually happen to prefer the GPL for applications, I think the Q Public License is fine for a compiler and other programming libraries, and maybe better than the GPL. Code fork can have dramatic consequences for a programming language since there is a risk to break the compatibility. Honestly, I think it is legitimate that the original authors somehow "forbid" such a threat.

Distributing the modifications as patches helps to prevent a break in compatibility. One can expect the developpers of the "official" version to intergrate patches which appear to be popular.

Re:(Objective) Caml may be a solution

[RevAaron]

While it isn't FP, Squeak is a Smalltalk system which is somewhat of it's own desktop environment. Not only does it have many features of a modern GUI system, it also has many other functions which are usually part of an operating system, like multi-tasking and process management.

It has been ported to bare metal a couple of times (to an embedded Mitsubishi SH3 chip, and x86) and can stand alone like it's own OS. Also, work it being done by me to get it working via the Linux framebuffer (the current Linux/Unix version requires X), so you could easily have a version which would be it's own OS on almost any archetecture.

Squeak Smalltalk itself runs on many platforms- including, but not limited to: Mac OS (classic), Mac OS X, Linux and most other Unixes, the Acorn RiscOS, Windows 95/NT, and DOS (graphics via VESA). The Smalltalk image file is binary compatible as well.

Also, since this is about FP, there has been recent discussion of FP, Aspect Oriented Programming, MOP, and similar concepts on the Squeak mailing list now. Smalltalk also has block-syntax which is similar to lambda.

excuse my ignorance.... but

[browser_war_pow]

how are C++ and Java procedural languages? Both are designed with OOP in mind. My understanding is that C is a procedural language because it has no OO capabilities but C++ and Java are OO languages and thus NOT procedural. Could someone then explain the difference between Haskell and say... C++/Java?

Re:Formal correctness proofs.

[Animats]

Functional languages seem to lend themselves to formal correctness proofs.

Not necessarily. I once spent three years building a proof-of-correctness system for a dialect of Pascal (see "Practical Program Verification" in ACM POPL '83). The big problem is capturing the exact semantics of the language, which is not too hard for Pascal, probably possible for Java, and hopeless for C++. We did this by working on the output of the first pass of the compiler, which was a tree of psuedocode operations annotated with declaration information. Once you get down to that level, most of the ambiguity is gone. (At that level, you have operations like "pop two 16-bit operands off the stack, perform a 16-bit twos-complement add, and push the result. That's unambiguous.) Most of the material the user had to write to help the proof system was in the form of additional source statements in the Pascal program. So this is more of a language front end issue than a fundamental problem.

Moore's ACL2 is well-matched to LISP because he and Bob Boyer have an elegant formal mathematical system based on a subset of LISP (see their book "A Computational Logic". It's a truly constructive mathematics, like the Peano axioms, but machine-processable. Numbers are defined recursively, as (ZERO), (ADD1 (ZERO)), (ADD1 (ADD1 (ZERO))), etc. About four hundred theorems machine-proven theorems later, basic mathematics has been established. Very heavy going, but if you're into this stuff, it's a must-read.

It would be interesting to look at program verification again today. We have enough MIPS now. My verification runs on a thousand lines of Pascal used to tie up a VAX for 45 minutes. Today that would take about two seconds. You could work on proofs interactively. We were too early in 1982.

A good Java verifier (not that stupid thing that checks types and stacks during class loading) is quite possible. I don't think it would get much use, though. It takes too much math background to use such tools. Only a tiny fraction of today's programmers have the theory background. It's just not user-friendly.

Re:You are in a fashion industry

[jallen02]

Support ? Well with the biggest software company in the world behind them, You can be hell sure about the kind of support you get for C#.
You missed what he meant by support....

He means support for an individual program written in Haskell

He means tons of nicely written tools to work with a language

The "support" of the entire industry not just MS, yes they DO make a difference you better believe it but C# is kind of like an anomoly to his anologies.

It is a bad idea we all know it its just hard to stop it. PHB's will see it oggle over it and force people to use it based on a whim in some cases

BUTT the point is at some point sensibility takes in and languages that are usable HAVE to be used or projects just will cease to be and im sure many programmers armed with shotguns have informed management of this......

Anyways, dont underestimate the torture MS can put an industry through... THEY ARE a monopoly its been proven in court....so be wary of so easily dismissing C# but also we cant take it seriously :) just have to be ready to put it down when the time arises

Jeremy


If you think education is expensive, try ignornace

Re:Functional Languages

[jacobm]

I don't know what domain you program in, but if you write good Scheme or Lisp code, you use recursion instead of any looping construct (which, I would say, is applicable "in the real world"). True, you can indeed prove that any time you write a recursive function you could have written a loop, but if you're writing in a purely functional way the recursion will be easier to write and more legible. That is, after you get past the shock of it.
--
-jacob

OMFG A computer language that's named after me!!

[Jim Haskell]

And yes, this is my real name. I can't believe I've never heard of it!

Re:Bugs + Math

[hanwen]

Sorry to break your bubble, FP is nice, but
most Higher Mathematics (Partial Differential Equations, Number Theory, etc.) are about properties of sets that can be proved by mathematicians. It is not about properties thatcan be verified by computers.

A mathematical proof is like a LISP program. If you are clever, and the program is correct, you might be understand and be able to prove that it works. A program that analyses LISP usually cannot.

Strongly typed systems are about systems where it the type-proving algorithm is designed by a clever human, who proved that the type-checking algorithm is correct.

FWIW, people tried to formally type mathematics at the beginning of the 20th century (Bertrand Russell et. al.), and they miserably failed.

Erlang: FP in Real Life

[drxyzzy]

Pointed out above in this list - Erlang is an FP language used in serious production. The ERTS, running production telecom applications, does much of the work needed to support high availability clustering.

The language bears the hallmarks of ruthless pragmatism in its feature set. It was designed to serve a real, specific set of needs and appears to do so very well. But, it also makes you want to try it for just about any distributed app that comes along.

The FP nature of the language with very light weight processes and IPC suggests that this kind of FP may be even better suited to extreme programming and similar rapid development disciplines than OO.

I think we are about to see a resurgence of FP, with Erlang, Haskell, and Scheme at the forefront. Some better FP platform may appear on the scene in the next few years.

[OT] Re:Thank God

[PimpBot]

Lemme guess...you like Bob Harper, hunh? ;-)
--------------------------

Re:Functional Programming: its above our heads

[Rob_D_Clark]

tail recursion is a good thing.

call-with-current-continuation is a trip

Bad programmers versus bad languages

[Anonymous Coward]

Language versus language wars often seem weird to me. I mean, everyone can't be wrong! C people saying C++ is crufty, C++ say Scheme is a toy language, Scheme people saying Lisp is too big, Lisp people saying perl is ugly, perl people saying they will revoke your user privilages.....

I would say that the FP people are just as guilty of flame-baiting as the imperative language people. An earlier post about Lisp people having an "I'm smarter than you" attitude is right on -- and it's silly. Lisp people are only alienating potential users by being so haughty.

On the other hand, there is an imbalance in the argument. Since C et al is much more commonly used and taught than FPs, more FP people have real knowledge about C et al than vice versa. (That's certainly not always true.)

So I wanted to spread the word about FPs and eliminate some misconceptions about FPs, just to even out the playing field.

But first, I want to urge people to really look hard before at a language before they judge it, to make sure they're not conflating bad things about a language with bad programmers/programming. In any language you're going to find well-written programs, and extremely poorly written programs. TeX is a very pretty C program. The Collections library is a very neat Java library, and ACE is a great C++ framework for doing design patterns.

On the other hand, just about every C program I've ever written is terrible, and an utter chore to do. Does this mean C sucks? No. Would I want to write a device driver in any other language? Probably not. The only thing it means is, I'm a terrible C programmer.

I've written a web server, ray tracer, Apache module, Scheme interpreter, and tons of tiny programs in C. I've rewritten Bugzilla extensively in perl. Do I consider myself good enough at C or perl programmer yet? No. I know there are good programs in C and perl, it's just that I can't write them.

For people who have had trouble with FPs, please try, try again. There's something there, I swear. If your only introduction was a college course or a book, that's not enough to really get the flavor (unless you were blessed to go to MIT or CMU, which I was not) -- my first taste of Scheme was to write a couple of graph solving problems, and then write an interpreter in C. I thought it sucked!

Now on to the misconceptions:

Garbage Collection is slow: there are slow garbage collectors, and fast garbage collectors. "But doing malloc() yourself is always faster!" There's a paper at www.cs.princeton.edu/~appel called "Garbage collection is faster than manual deallocation." Read it.

For people who complain that Scheme et al is cumbersome and/or not powerful enough -- maybe this is more of a reflection of your experiences than the language itself. I know most universities have an extremely lame introductions to Scheme/ML/anything-that's-not-C-or-Java, with the exception of MIT and CMU. When I first learned Scheme, I had no idea why anyone would want to program in it. I ask people whose only exposure to FP's was from a single college class or book: please take another look before you are so sure you know what they're about.

For example, about recursion: in Lisp, many people use the Loop macro instead of recursion to do looping. Don't know what the loop macro is? Look it up. (It basically combines any looping construct you've ever seen, is efficient, super-expressive, and honestly a bit too powerful!)

You like C++, Java, or perl objects? Try CLOS in Lisp. It can do anything. It's designed in a way that's different than C++ or Java; but open your mind, it might be better. (See norvig.com's exposition on Design Patterns in Dynamic languages.) Most Schemes have object systems, although they're not standardized. It's a testiment to Scheme's expressiveness that you can code up an object system that's syntactically transparent to use, in a couple pages of code. Try that in C.

The Lisp macro system is insane: if you are familiar with C macros, forget everything you know. Basically, you can create new programming languages designed to solve the problem you're struggling with, in only a few lines of code. You can create syntactic constructs which are clear, concise, safe, and expressive:

(with-open-file f
do-crap-with-f)

it's pretty clear what's going on here, and also no matter what happens, when you fall out of scope, f is closed for you.

FPs are slow : so it's true it's hard to write a slow C program, but that doesn't mean you can't write a fast FP program. The language features FPs provide sometimes have a performance cost, but many times more than make up for it in ease of programming. Also modern compilers for FP languages can be even faster than C, in many cases. CMUCL's numerics are insanely great, for example.

Why do you need all these high-level features in your language? Well, I won't belabor the benefits of abstraction, but I will point out that often times people reinvent the wheel : when I wrote my C raytracer, I ended up with a pseudo object system based on function pointers and structs. It was ugly, and we should have used an object oriented language. The same thing has happened to me with functional constructs, as well : I wished I had higher order functions, etc. So my options were: write an amateurish version myself, or use a well-written implementation, built into the language.....

Do give FP's another try. To repeat an earlier sig:

If they only thing you have is a hammer, everything starts to look like a nail.

Personal preference.

[tietokone-olmi]

I don't like functional programming languages. This is mostly because the ones I've looked at (scheme, haskell) are too subtle. Yes, scheme may be a great tool for partial enlightenment, but you just can't read the stuff and understand it right away.

Some practical issues

[Straker Skunk]

As others have mentioned, there's some issues with industry support, popularity with programmers, etc. Considering FP in an open-source context, however-- where the tools are free and languages like Scheme are alive and kicking-- there are still technical issues that make for abnormally high activation energy.

(These points apply to some variants of Haskell and ML I investigated a while back. I don't remember specifics, but these were the salient observations that resulted):

For one, the compilers are incredibly complex beasts. This wouldn't be so bad, if they weren't so ambitious as to generate native binaries themselves. Myself, I'm leery of anything that generates native machine code, that doesn't use a GCC backend. Maintaining a native code generator is a lot of never-ending work (machine architectures evolve constantly) and IMHO, not using GCC for that is a lost cause, in the long term.

More significantly, if the compiler's native code generator is the only way to get a native binary, you're basically requiring users to go through a MAJOR hassle (installing a full-blown compiler) just to run your program non-interpreted, if at all.

(If you want to know what I mean, try building the CVSup program-- written in Modula3-- from scratch. I almost had to do this, on IRIX. Let me just say: was I ever *GLAD* I managed to find a precompiled binary)

That's why I'm partial to compilers that generate C code (like SmallEiffel). It makes things easier for users, while still allowing them to generate binaries fully optimized for their architectures. And it works perfectly in a source package. You put in Makefile rules to convert Haskell/ML/etc. to C, and then the usual C->O rules, and distribute both the FP sources and C sources. Users will need the FP setup if they want to hack program code, but at least they need nothing more than a C compiler to get it up and running.

On a related note, there's also the issue of run-time libraries. Requiring anything that isn't the C library, or that can't be statically linked (without making hugeass binaries) is a lost cause. Again, it's an activation-energy thing. If you can't just download a binary and run it, then you're asking your users to do too much.

So, the ideal alternate language system would have to have at least the following bullets:

• Native code generation through a GCC backend. That way, the compiler maintainers only have to track GCC, and not the three or four machine architectures they happen to have in their lab. Not to mention, I know my stuff will run on anything GCC runs on, which would be just about every computer architecture in the known universe <g>
  
• Compilation to C. Java bytecode output a plus. Natively generated code could run faster, as the FP compiler would be better suited to the language features, but the C code should come in a close second.
  
• No run-time library, or at most nothing too formidable. It *must* be statically-linkable.
  
• Execution speed on the order of C/C++ code (not a problem for many implementations)
  
• Non-ugly interface to C/C++ libraries.
  

Not many alternate language implementations have all those features. SmallEiffel was one, I recall. I think there was one for Haskell, though I never got around to checking it out...

(Disclaimer: I haven't actually gotten into FP yet. I like what I've heard of it, and I do intend to delve into it sometime. I just don't want my non-C code to be a PITA for users because of technical issues like this. If it gives them grief, it should be because they can't think functionally, not because they can't build the damn thing!)

Re:Some practical issues

[Chilli]

Check out the Glasgow Haskell Compiler. It can generate C code and that's how it is bootstrapped on new platforms. A Java backend is just in the works. The RTS is statically linked and it just got a nice interface to call C code (and call Haskell from C). It generates good code and has a sophisticated profiler to help you speed up things if need be.

And of course it is open source (with CVS and all).

Chilli

Erlang is used in production environnment

[mremond]

If you need an example of functionnal programming used in real life, you should give a look at Erlang web page:
www.erlang.org

This language is used by Ericsson as a strategic advantage in their software business.

Re:Thank God

[Tom7]

Assuming Scheme is a good taste of all functional languages, they're hard to read, hard to conceptualize, and hard to debug in my opinion.

It's not. Languages with a better syntax are easier to read, and languages with a real type system are MUCH easier to debug (Haskell and ML fit both of these). Scheme is a cute minimal language, but isn't really a taste of a modern functional language.

As for people thinking they're superior, I think you'll find this is true in every area of computing. People who use linux think they're better. People who use perl think they're better. Sometimes they're right, sometimes they're not! There's a certain frustration in trying to share something that you think is beautiful with someone else, and this often manifests itself as a superiority complex. But don't let that turn you away... it took me a semester and a half to appreciate functional programming. But now I don't want to go back!

Re:Functional Programming: its above our heads

[kinkie]

All of the above ;-)

Why I'm not using FP

[Rainy]

First a bit of background: I heard about Python once, went to their website, read the tutorial, realized that it is, indeed, a very clear and useful language and bought a Python book.

Some other time, I heard about Haskell and went to look at haskell.org. They also had a tutorial there but it wasn't nearly enough for me. The problem is either that they assume a person already knows FP, or that tutorial isn't as good as Python's or that the language itself is much harder to grasp (note that if it is, it would make sense to make the tutorial correspondingly easier).

Re:OT: Meta moderating

[linux-mp3-car-2001]

I saw this thread and decided to check it out, and now I can't moderate either, it gives me the same error about not being a user long enough. Strange part is, I metamoderated last week, so I wonder what changed now?

tedious personal anecdote

[CdotZinger]

I'm not a programmer. I'm just a guy who's not scared of his computer. A while back, I got an idea for a simple, small application that I knew no one else was going to write, because only I would have a use for it. I went looking for a language to learn. My only criteria for choosing which language were 1) Is there a free implementation of it on any of the platforms I have lying around the house (since I'm only going to write this one stupid thing)? and 2) Can I read other people's code, without knowing the language, and understand how it works and what it's doing (because I want to learn it quickly)? So I went and rounded up a few hundred k of sample code in Perl, Python, LISP, C, and a bunch more I don't remember now, because there's so damn many and they're mostly indistinguishable from each other (to me).

Not surprisingly, reading Perl and C code confused me. It was like a Pierre Guyotat book--piles of random but related half-words and clauses without verbs, punctuated automatically by Microsoft's famously moronic grammar checker. Neat, but not my bag. Python seemed a lot cleaner; I couldn't guess what the code was doing (semantically), but I could see how it was doing it (syntactically). Not bad, but still not quite it. Then I saw some LISP code and my whole brain smiled. I've since seen some obfuscated, nasty crap written in LISP, but the samples I got made perfect sense to me. And I love parentheses. What they do is obvious to anyone who's ever written a sentence. LISP works like my brain works, but better.

So I bought some books. It took weeks to root them out in the metric tons of C++ and Java books at all the stores, but I found a couple. And "development" is chugging along, slowly--not because it's difficult, but because I'm very lazy and stupid in the summertime.

The point: I have no idea. I told you it was a tedious personal anecdote.

Re:Abstraction and Debugging tools

[xconfig]

As it turns out, there *is* a class of processors that corresponds almost exactly with functional programming. Check out some of the research on dataflow architectures. Dataflow computers use a machine language that is functional! The J-Machine at MIT was a dataflow computer.

Some Applications

[Tom7]

Here is a web server and network stack written in Standard ML:

http://foxnet.cs.cmu.edu/

There are at least two very large and complicated (and good) compilers for ML, written in ML.

Yes, applications usually need to perform IO, and so you can't write them in a purely functional language. But for an application where behind-the-scenes processing is a major part of the code (a compiler, for instance), functional languages can be and are often an excellent choice.

Not too surprising they haven't caught on

[Junks Jerzey]

I've thought about this issue a good amount over the last few years. Here's my take:

1. While certain complex algorithms are much easier to express in Haskell, there are many, many times when you really just want to do something imperative. Haskell has a way of wrapping imperative operations into a functional framework, and though it may be theoretically beautiful it comes across as contrived. I think issues like this come up enough that it is easier to use an imperative language and struggle with the parts that should be written functionally, than to use a functional language and struggle with the parts that should be written imperatively.

2. The developers of functional languages are living in a theoretical world in which many topics seem very important, topics that people doing actual programming see as minor issues. Static typic systems come at the top of the list. Proof systems are another.

3. Many functional language proponents have fooled themselves into thinking that imperative programming is so low-level and dangerous as to be all but impossible. Truth is, there have been people writing complex video games in hundreds of thousands of lines of 16-bit assembly code, games that shipped on consoles and had no known bugs (examples: Donkey Kong Country, Sonic the Hedgehog 3, NBA Jam, Crusin' USA). So, yes, Haskell may let you write a Quicksort in three lines of code, but there's more to programming than that. You could equally fool yourself into thinking that cars are too dangerous to drive, because there's no safety mechanism preventing one from veering into another.

4. In all honesty, relatively few people are doing classic programming any more. Most programmers do things like database interfacing, GUI tool building using Delphi or Visual Basic (data point: 60% of all new software is written in Visual Basic), CGI scripting, etc. Not too many programmers find themselves needing to do something algorithmically tricky, like handling red-black trees or dealing with weighted graphcs.

I like functional languages for certain types of problems, but it isn't too difficult to see why they haven't caught on in a bigger way.

Re:Not too surprising they haven't caught on

[gmarceau]

Have a look at Ocaml. It has:

- all the imperative feature you needed, including those unsafe operations like unchecked array reads.

- all the tricks of functionnal programming (like higher order function, ie function composition)

- The type system is the most useful I've ever seen by far. It also catches more bugs. Think of the last 20 ClassCastException crashes, ocaml's type system would have got then at compile time. As a mater of fact, most code I write work the first time they get through the type checker. You should give it a try, it is quite a felling.

- The type system is completly unclutering since types are infered for you. Writing in ocaml feels as light as scripting (typicaly untyped languages).

- Ocaml is very fast (C-fast) Check out those banchmark results They include Python:18.906secs, Perl:12.797secs, C: 4.855secs, Ocaml:4.803secs.

Ocaml is ready for prime time. The only things it misses is some big buck company to market it.

-

Re:Not too surprising they haven't caught on

[boloni]

I am sorry, but that is a very bad benchmark. The ocaml program is 7-8 lines and it is basically doing several function calls to its standard library, implemented in C.

The C program uses a handwritten, non optimized hash table.

This benchmark effectively measures the speed of the hashtable used. All the the implementations use hashtables from libraries written in C. For
executing code, the difference between Perl and C would be much larger, btw.

This test does not tell me anything about the relative speed of the languages.

Lotzi

Re:Not too surprising they haven't caught on

[sohp]

60% of all new software is written in Visual Basic

That's quite a claim. References? By what measure? Lines of code? Useless. Number of projects started? Please. Function points? What? Back up this claim or let VB molder in the grave it deserves.

Re:Not too surprising they haven't caught on

[kalifa]

> This test does not tell me anything about the

> relative speed of the languages.

I agree. Here is another study of languages for scientific processing. O'Caml is doing pretty well (same order as C++ compilers).

And here is a more general study (but older, O'Caml has improved quite a lot since them). O'Caml is doing quite well again, except for the memory usage on one of the tests.

Re:Not too surprising they haven't caught on

[Junks Jerzey]

That's quite a claim. References? By what measure? Lines of code? Useless. Number of projects started? Please. Function points? What? Back up this claim or let VB molder in the grave it deserves.

Number of projects. I've seen this mentioned in several sources--yes, one of which was from Microsoft--but I can believe it. I should clarify that the correct statistic is "60% of all new *desktop* applications are written in Visual Basic." The majority of all software is still written for embedded systems, not desktops.

Most desktop software consists of so-called enterprise applications: database front ends, form-filling programs, time reporting programs, sales trackers, etc. Visual Basic makes sense here.

Re:Not too surprising they haven't caught on

[GodSpiral]

>>
In all honesty, relatively few people are doing classic programming any more. Most programmers do things like database interfacing, GUI tool building using Delphi or Visual Basic

I guess this is a pretty obvious point, but it explains the market share perfectly. The millions of people who need to write GUI database front ends severly outnumber the few that need to make Lexer/Parsers.

Somehow, the choice of languages to do the db programming is more bounded and focused, despite the larger market for users.

A highly moderaetd thread above dismissed Xerox PARC's effort to promote Aspect Oriented Programming, as something plain and obvious that Lisp can do. Their presentation managed to impress me though.

Corporate Research Centers take an approach that's more conducive to public acceptance of CS research. I don't really need to elaborate why, but the University approach seems only interested in impressing other academics.

give it a try!

[jetson123]

The reasons why functional languages are not more widely used are the same reasons why other "minority" languages aren't more widely used: lack of training and lack of vendor adoption. Also, the creators of functional programming languages make adoption hard by picking somewhat unusual syntactic features.

It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.

Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.

My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).

Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.

For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.

Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.

There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.

Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.

So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.

Re:give it a try!

[jrstewart]

If you're interested in Scheme and in particular MzScheme, then DrScheme is the way to go. It's a graphical editor for MzScheme with a variety of cool features. An interesting Scheme text is The Little Schemer . It teaches the functional way of thinking in a relatively painless way.

good idea!

[cpeterso]

I'm a C/C++ kinda guy, but I just finished reading "Structure and Interpretation of Computer Programs". In school, I never bothered to learn Lisp, so I decided to do it myself. I can appreciate some of the bigger ideas, but some of "cool techniques" in the SICP book felt more like cruft to get around the functional language properties. I'd love to read a functional language intro, especially one that wasn't as brain heavy as SICP.

Right Under Your Nose

[Anonymous Coward]

Has anyone ever heard of the C++ Standard Template Library? Some people love it, some people hate it, but the point is it offers many of the advantages of functional programming (fast prototyping, genericity, etc) and it is widely available. Also as C++ compilers get faster/better, they will be able to optimize programs which use STL.

Generic Java and Standard ML of New Jersey are also two packages I have used with great success (for writing compilers and interpreters). Functional languages are just great for those kind of situations, where you need to loop over different datatypes. This is in start contrast to most programming situations, where you want to split something up into abstract objects that are related (e.g. Circle isa Shape, Square isa Shape).

Generic Java
http://cm.bell-labs.com/who/wadler/gj/
Standard ML
http://cm.bell-labs.com/cm/cs/what/smlnj/index.h tml

Anyone who uses Java should check out Generic Java. Anyone using C++ should check out STL. Anyone who wants to make the world a better place can help put the smarts ingo g++ and/or GJ for optimizing programs: the main barrier to these functional languages is that the compilers for them are much more complicated. The payback is that once you put the smarts into the compiler, that's one less optimization the programmer doesn't have to make.

I know, I know, that's what compiler writers have been saying all their lives, but hey, it's true.

And for a look at the future of programming as we know it:
http://www.parc.xerox.com/csl/projects/aop/
(Still needs a lot of work, but it *will* happen)

Functional languages are alive and well, mostly in environments where merit is worth more than hype (e.g. Lucent, obviously).

On the other hand, I have to disagree about Scheme. Programming with those parentheses is murder. Scheme should be used except as a form of bytecode IMHO.

Don't forget R.

[red_crayon]

Don't forget R.

Re: unctional Languages too job-specific

[GodSpiral]

Actually, they all seem to be good at the same job, judging by the example code and libraries that come with them.

My guess as to why there are so many, is their developers could not understand or were too aggrevated with each others syntax, so they rolled their own :)

Re:Experiences...

[boloni]

Ok, so why is this more elegant than

val=1
for i=1 to x
val = val * i

?

Re:Make C and Java functional

[norton_I]

The reason why every statement doesn't return a value is because it is very inefficient -- basically it means that any value must be allowed to be undefined. modern CPUs don't have any support for this (on integers and pointers, at least. floating point has NaN), which means the "undefined" value must be recorded sepearatly and every operation has to check for it. This is ok in an interpreted language like Perl where you already have a lot of bookkeeping to do, but killer in a compiled/low run-time support language like C/C++.

Undefined values also make it harder to pick up many potential errors at compile time, which is the halmark of C++ philosophy.

Re:Commercially Relevant

[arn@lesto]

Functional languages have their place. I believe that everyone should learn lisp/scheme while doing a CS degree. The majority of programmers will never use them again, but it will change the way you think about programming for the better.

Having said that, I've worked on a number of commercial applications where an embedded scheme interpreter made prototyping of UI functionality an easy task. You expose the interfaces of the application to the FP language and off you go gluing bits and pieces together. Once you get it right, recode it in C/Java.

A good programmer should be able to work at five different levels of languages:

1. SQL - you must understand transaction based DBs to survive the client/server world.
2. Perl or Python - fast prototyping and CGI.
3. Scheme - prototyping and CAD/CAM, small and easy to embed.
4. C/Java - available everywhere and fast, but slow turn around.
5. Assembler - some times you just have to get dirty or the compiler has a bug.

Choose your favorite five and stick to them, it really doesn't matter which ones. (You should also be able to hand code HTML).

You should always aim to develop/prototype in the highest level language and then recode it when performance becomes an issue.

Forget provability - it's a nice academic goal but of little use in commercial software. Speed of development is how you'll get hired and rewarded.

--
Andrew Nicholson

RPN...

[Uberminky]

Speaking of RPN, my favorite programming language is Forth. It's basically an RPN programming language. There is no syntax. Strikes you as pretty odd at first, but the elegance is incredibly beautiful. Forth is so darned elegant it's crazy. There were guys that could write a full Forth for an 8-bit Z80 in a day. Most (at the time) were about 2k of code, while a "massive" multi-tasking Forth operating system capable of effortlessly serving 100 users simultaneously weighed in at under 20k.

But anyway I'd better throw in a comment or two to the people that will say "Forth is outdated, use a real language" (I get so tired of hearing crap like that..) To them I say, obviously you have no clue at all what Forth is. It's a language, but more importantly it's a technic. A philosophy. You can write Forth code in Java or Scheme or whatever you want. It's a mindset of elegance, speed, efficiency, and (most importantly) simplicity. There's even processors based on Forth (try designing a processor after the inner workings of Java or Scheme..). In fact one of them (the F21) costs $2 in quantity, has 7000 transistors (compared to ~5 million of a Pentium), is built on an outdated fab process, and STILL gets nearly 500 MIPS (try THAT on the Pentium), and gets power ratings fit to make the Crusoe look like a short circuit. The PostScript language is related to Forth, and that is what gives it the flexibility it has. Forth can be an operating system (as mentioned earlier), it's incredibly flexible. It's perfect for robotics and stuff like that.. OpenFirmware (or OpenBoot) is nothing more than a Forth operating system you can boot into before the monitor even warms up (usually used to load your other OS). Anyway, I could go on for pages but that's probably not welcome... ;-)

Ok sorry for the rant. ;-)

Re:You are in a fashion industry

[Crispin Cowan]

I totally agree with this comment. We even have empirical evidence to support it: Java.

Java is (IMHO) the coolest popular language around, and the most popular cool language around. Before jumping on me with your favorite language, let me explain these terms:

• coolest: supporting the most wizzy features, e.g. type safety, distributed computing. Thus the list of "cool" languages is very, very large, and would include the likes of Java, Eiffel, Haskall, Scheme, ML, Hermes (my personal favorite) and the hundreds of others that the PL community has produced.
• popular: used by so many people that you can reasonably post a job ad seeking programmers with experience in that language and expect to get responses. Thus the list of "poplular" languages is relatively short. This list is nearly inclusive (I may have left out a few):
  • C/C++
  • Pascal
  • Java
  • VB (very popular, not so cool :-)
  • PERL (very popular, coolness hotly disputed)
  • Python ("popularity" getting marginal here)

So now do the intersection of the two, and just about the only languages that are both "cool" and "popular" are Java, and maybe Python (depending on whether you believe that Python is either "cool" or "popular").

Now, how did Java get to be so popular? I argue that it has nothing to do with how "cool" Java is. Java could be every bit as sucky as VB, and still be nearly where it is today. Java became popular through the networking effect of being first to enable animated web pages. Yep, that's right: dancing pigs.

If Java had come out three months after animated GIFs instead of three months before, then no one ever would have heard of it.

Topical flamebait: Yes, functional programming languages are obscure and impractical. They may be "cool", but because they are hard to understand without a degree in mathematics, they have zero chance of ever becomming "popular". You will continuously see FP showing up in niche markets where correctness matters, no matter what the cost, (e.g. verifying CPUs such as the AMD/ACL2 case mentioned elsewhere, or the Hawk project being used to verify Intel processors) but you won't see FP enter the mass programming market.

Crispin Cowan
-----
CTO, WireX Communications, Inc.
Immunix: Free, Hardened Linux Distribution

Re:You are in a fashion industry

[zCyl]

Portability has a lot to do with the usefulness of a language in the current market. If you have well written C++ code for Windows, you can get some programmers to port it to other platforms. If you write software in a language that runs on MS operating systems, good luck, because then you'll have to completely rewrite it from scratch to sell your software in any other market.

Re:Haiku

[mrdlinux]

(define (this-is-more-elegant b e)
(cond
((> e 0)
(* b (this-is-more-elegant b (- e 1))))
(else
1)))

(this-is-more-elegant 2 8)
=> 256

float than_this(float, int);

float than_this(float b, int e) {
int i;
float sum=1;

for(i=0;i<e;i++)
sum*=b;
return sum;
}

than_this(2,8);
=> 256

(define (exp b e)
(this-doesnt-use-stack 1 b e))

(define (this-doesnt-use-stack sum b e)
(cond
((> e 0)
(this-doesnt-use-stack (* b sum) b (- e 1)))
(else
sum)))

(exp 2 8)
=> 256

Truthfully, people who think functional languages are somehow inferior to imperative languages are talking out of their ass. Functional languages can be just as powerful and just as fast as imperative languages (if not more powerful and faster!), its just that most implementations suck. Remember BASIC, and unstructured coding? When you upgraded to structured coding you did away with things like 'goto's. When you upgrade to functional programming, you toss away side effects. What are side effects? In a functional language, a function will always return the same result given the same arguments. Anything that does not has a side effect. A good example of a side effect are global variables, or in fact, assignment of any type. This is where recursion comes into play, as you noticed in the example I gave above; in order to decrement the variable, I simply called the function again with the variable decremented. There was no assignment, only initialization. My third example is the C program rewritten in Scheme. It uses tail-recursion to loop. Alas, Scheme does not push anything on the stack when tail-recursion is used, so there is no possibility of a stack overflow. Scheme can be as high level or as low level as you like, just like C, after all whats the difference between inb(0x3f8); and (inb 0x3f8) ? I will even go as far as to venture that Scheme can be optimized to the point where it is competitive with hand-coded ASM, but since most will laugh, I will leave that as speculation (for now).
As for the original complaint of the post I am replying to... Scheme is a heck-of-a-lot more nice looking than C, and a lot easier to understand once you lose the '{' and ',' craziness. Its grouped just like any old mathematics equation: with parentheses! f(x,y) and (f x y). f(g(x),y) and (f (g x) y). I find the Scheme easier to read than the math notation. Sure it uses prefix notation, but its a functional language it only makes sense! (+ 1 1), (plus 1 1), plus(1,1); whats the difference? Instead of f(g(x),h(y)) + i(x,j(x)) you have (+ (f (g x) (h y)) (i x (j x)))
Remember, everything is grouped by parentheses, so you have (g x) and (h y) and (j x), call them a b and c, then you have (f a b) and (i x c) call them d and e, and you're left with (+ d e). Of course if you've never touched algebra... well go learn it now, wouldnt want to hire a programmer who couldnt do algebra, eh?
(and i didnt even discuss lambda-functions! ack!;)

So lets fix up that Haiku:

(define (language good)
(write (bug-free-code (language 'Scheme))
(read (code 'easily)))

The ' means its a symbol, not a variable or function.

:)

Re:STL

[Tom7]

I agree with you... the STL suffers mainly because of C++'s shortcomings. (And often, compiler shortcomings respecting templates).

> Yes, the syntax might be more elegant in a
> language that was build with just generic
> programming in mind. But, there is no such
> language yet.

I would say that ML was built with generic programming in mind. Check out the basis library and some of the utility classes (like the splaytree map and set functors, etc). The syntax is very nice.

Proof-Carrying Code

[Tom7]

One cool application of this, which is likely to come back into fashion, is proof-carrying code. Here the programmer or compiler instruments his machine code with a proof that it meets some safety metrics (perhaps a list of library functions it's allowed to call, and type safety). The code can be transmitted to a client, who does not have to trust the provider. She only needs to trust the proof-verification code (which is a few pages of C). Network-distributed code now doesn't need sandboxing or certificates!

This of course is easier in languages with interesting type systems, which are usually functional. But the same ideas can be applied to traditional languages too.

More information: http://www.cs.cmu.edu/~petel/papers/ pcc/pcc.html .

Re:Myth or Fact? Bugs in the face of Static Typing

[jallen02]

LoL I have really enjoyed reading your posts..
It really reminds me of the passion people pursue Linux. Like its REALLY GREAT!!
Yet with Java its like yeah its been pushed hard on us, its an okay language I have fun hacking it.. But wow... not being sarcastic the few people who have really experienced functional programming languages seem very passionate about it.. That inspired me to dnwload hugs and play around with one.. Im not sure what the heck im doing in there but I will probably be checking it out over the next few months

So.. honestly I appreciate you just posting.. There something to be said about a idea, concept, or just anything that can inspire this kinda fire in comptuer junkies.. I think EVERYONE just needs to take note of that, something is causing it just like something causes us to all get fired up over Linux? Maybe we should all buckle down and wrap our brains around it just a little?

I mean From what I KNOW its a Major pain to really learn to write good OO code in C++.. I am JUST now getting real good after almost 3 years of hacking C++, and I just now am out of making my programs look like hackish C programs... its complex so yeah Functional may be complex but no worse than the learning curve that Ive been thru im willing to bet.. More than one person has stated it is not.


If you think education is expensive, try ignornace

Re:Functional Programming: its very powerful

[Anonymous Coward]

Therefore, you preach the dumbing down of Computer Science, Software Engineering, and the software industry as a whole. I mean, we should make things easier for programmers, as you say, regardless of the benefits functional programming languages have to offer.

Programming languages and programming paradigms are two main types of tools used by software developers. So what if a tool takes twice as long to learn how to use -- Learn to use it! As long as when you have mastered the tool, you are twice as powerful because of it.

It's far easier to learn how to walk, than it is to learn how to fly an airplane. Because of this, most average folk are not pilots. However, there are great benefits for knowing how to fly an airplane. Therefore, those who want more power learn how to fly.

Let me end this rant with my proclamation that learning a functional programming language (and learning how to use it), is not as hard as you think. I learned how to code fairly well in Haskell, and I was nothing above average as far as a software developer goes, when I started learning. The most important thing it requires is for the student to be open minded. It will seem foreign at first, and sometimes you most likely won't even see what all the hype is about. If you can stick with it in spite of all that, you will soon see the great power it has to offer: greater expressive power (less lines of code required), stronger type checking (less bugs), referential transparency (implicit distributed computing, no dead locks, no race conditions, easy proof of correctness)

Functional Programming is the next big thing.

Re:SQL - widely used functional languag

[PanDuh]

Well, SQL is a widely used functional language...

Eeeh.. I don't know about that.

SQL is actually a "declarative" language, in that you concentrate more on utilizing the available functionality to make relationships between data rather than create the actual functionality like in imperative languages.

Re:Rant: Formal correctness proofs - a misnomer.

[nickm]

I believe you are trying to reinvent Goedel's Incompleteness Theorem. Go check out a copy of "On Formally Undecidable Propositions" and curl up on the couch for a while.
--
I noticed

Re:Haiku

[Mr-Fish]

Thank God for emacs paenthesis matching.

Scheme is a toy language.

[Estanislao Mart�nez]

Due to my personal limitations though, I just couldn't see how one could develop big, useful applications with them [i.e., Scheme].

Scheme is a limiting toy language, designed to serve as the exhibit of some ideas (lexical scoping, closures, first order functions, first order continuations). It is deliberately kept as a toy language by the committee that manages it.

It does serve as a simple language that beginners can start on before moving on to Common Lisp.

Re:Arrogance, infighting, zealotry (sound familiar

[nhw]

There is an annoying elitism among functional programming proponents, implying that all current Perl and Python and C++ programmers are wrong.

I think that's strong - I prefer Philip Wadler's construction of this idea (from an ACM SIGPLAN Notices) under the title of non-reasons for the lack of general adoption of functional languages:

"They don't get it" Functional programming is beautiful, a joy to behold. Once someone understands functional programming, he or she will switch to it immediately. The masses that stick with outmoded imperative and object-oriented languages do so out of blind prejudice. They just don't get it.

He holds this up as a mistaken belief frequently held by researchers. I don't think its arrogance, I rather think it's the kind of thing demonstrated by excessively evangelical, newly converted Christians who want everyone else to 'see the light'.

Some FP proponents insist that functional laziness is the key. Others think that laziness is unpredictable and does more harm than good. [etc]

Well, this is still very much a research field. Issues like mutable state in functional languages, controlling dragging caused by excessive, uncontrolled laziness, etc. are hard - and I think it's a good thing that people are trying different approaches.

To be fair, most of the debate centres around purely functional languages, which are of significant research interest: you can quite happily write industrial strength, concurrent distributed systems with functional languages - cf. the Foxnet server discussed elsewhere on this thread, and the use of Erlang by Ericsson for the software for some of their ATM switches.

Many FP language developers would prefer to do research on new type systems, rather than create useful libraries. Many think that language choice is more important than tool choice, as if ML would somehow be better at GUI-driven applications than Delphi.

Most FP language developers are not software developers, stricto sensu: they are computer science researchers! It is 'what they do', to do research on things like type systems. It seems a little unfair to criticise them for this. I have honestly never seen the 'language choice more important than tool choice' attitude in the functional programming community: people may have strong views (academically) about whether strict or lazy semantics are to be preferred, but they are not so blindly partisan as you paint them.

In sum, the fact is that functional programming is (in most cases) on the cutting edge of programming language research; as such, there are bound to be academic debates about the merit of one approach or another.

Cheers, Nick.

Re:Abstraction and Debugging tools

[Estanislao Mart�nez]

Or, a similar question, is there any theoretical limit to how efficient an interpreted language such as Haskell can be on the architectures of today?

Another poster already pointed out that there are Haskell compilers. Anyway, the type system in languages like ML or Haskell was designed specifically to guarentee catching all type errors at compile time.

You need to think separately about languages and implementations. The speed of a program does not depend in the language at all, but in the implementation of the language.

"Perl ~ human languages": Bullshit.

[Estanislao Mart�nez]

and perl through a more "human" language structure.

I'm sick and tired of this "Perl is like human languages" bullshit. I've never seen anyone give any substance behind this vacuous catchphrase, and quite a few convincing putdowns of it.

Perl is just another programming language, a rather unremarkable one, that happens to be popular, have text-processing primitives built in, a huge set of contributed libraries, and one of the most horrendous designs ever.

Gimme a break

[Ars-Fartsica]

This is splitting hairs. Tell me once, just once, in detail, how perl's supposedly oh-so dreadful garbage-collection has negatively impacted you at all.

Re:Gimme a break

[Ars-Fartsica]

A good garbage collector should not allow a program to leak memory. 'Reference counting' permits memory leaks: If you have two objects, A, and B, each of which references the other (but neither of which is referenced by anything else), neither will ever get free'd.

Unless you're running perl on a wristwatch, you'll never miss those thirty bytes.

This is a corner case. If you aren't using perl because of these corner cases (and by the way, any garbage collector has corner cases), then you're a complete moron.

Re:Experiences...

[Temperance]

The Scheme version doesn't use any side effects.

Re:Claims Substantiated - on type systems

[boloni]

Hm. My professor on "programming languages" (Jens Palsberg - I think he is a relative authority in type systems) managed to convince me that they are important, although I still tend to think that they are much overvalued in that peculiar type of journals.

In consequence, I don't know why the type of math used to infer types have any relationship to the language. I don't really believe in mixed language coding, and anyhow, type systems are not really working across different languages. So the conclusion is that:

-you are subordinating your representation of the world to the type system

-you are loosing power of representation and performance to have better compile time type checking

-etc.

So I really welcome type checking, but in that case the type checker algorithm should adapt itself to the language, not the other way around.

I think, that there is an unwelcome effect of the academic specialization: the ones who are researching type checking are not doing anything else, so they are creating a sort of closed universe of their own. In the meanwhile the compile time analysis of GCC is pretty bad...

Lotzi

Re:How about SAS?

[Eric Wayte]

I believe that SAS stands for Statistical Application for the Sciences. Its syntax is based on PL/I and for the longest time, SAS was written in PL/I.

Just because a language contains functions doesn't make it functional.

Structural languages are not used because....

[Paladeen]

....there is no sample code, few books that teach it, they're not hyped, not recommended by anyone except yourself.

Re:Structural languages are not used because....

[weg]

I'd say, that VDM-SL is semantically specified, too (using denotational semantics), but it is more a specification language, although code generators for C++ and Java exist (http://www.ifad.dk).

Re:Structural languages are not used because....

[mistral]

Haskell has CGI and animation libraries, as well as a system for writing music. There are foreign library interfaces and highly optimizing compilers, database interfaces and graph visualizers.
Libraries and Tools in Haskell
Haskell in Practice
Here are some books and papers about how to program in Haskell and functional languages in general.
I particularly recommend Hudak's book; Paul himself is a very clear teacher and lecturer, as is Zhong Shao, who does research in ML (Standard ML of NJ). I think SML is the only functional language around whose semantics are completely specified.
Follow these links and learn about Erlang (in massive production use at Ericsson), high level abstraction through functions defined via structural induction over datatypes, monads, layered functionality used to build parsers (via parser combinators), and a type theory for object-oriented programming.

Great, and used for real work!

[unny]

Ericsson uses a (free!) functional language Erlang (www.erlang.org) to program their switches, which is not really a simple thing. And they always "brag" on how productive their people are with it. So: go functional!

I hate it.. But I have no choice.

[Anonymous Coward]

I hate it, but I have no choice but to agree.. I'm a fresh graduate and although I'm still most familiar with C++, I most prefer programming in LISP. I lament that I won't find a job in it, but I truly do love the language. It would be so nice if LISP was where Java is now.. It's got the speed. (hell! One paper had it at 50% faster than C++!) It's efficient, it's interactive and flexible.. It's also losing and destined to lose.

Rant: Formal correctness proofs - a misnomer.

[Ungrounded Lightning]

I maintain that a correctness proof of a program - in the ordinary meaning of the words - is not possible. Consider:

What behavior is "correct" depends on the job to be done. (For instance: A perfectly correct implementation of "grep" is utterly broken if what you wanted was an implementation of "finger" or "gcc".)

Assume you had a perfect formal correctness proving tool or methodology. You must specify what it means for the program to be correct, in a formal language accessable to the tool/methodology.

This is exactly the process of writing a program. Did you write that program correctly? Prove it!

This is NOT to say that what are called "formal correctness proofs", or "correctness-proving tools", are useless. Quite the contrary - they're extremely valuable. They're just misnamed.

What these tools do is automate the comparison of two distinct descriptions of a portion (possibly all) of a design's behavior.

This is very important, because the only effective ways known to find and eliminate the bugs in a design amount to expressing it twice, in distinct forms that use distinct modes of thinking, and compare the two.

In the classic "manual" (though often machine assisted) approach to software development, the two expressions are the canonical specification documentation (the "spec" or "bible") and the source code. The spec is optimized for human readability, while the source code is optimized for processing by compilation tools.

In a large project they will be written by different people. In a small project the differences in language tends to create enough of a different mindset in a single person that they tend toward non-overlapping bug sets. In a very small project the "spec" may be the program comments. A good programmer comments well, not just to make things clear to others later, or to keep them clear to himself later, but to deliberately create this second mindset, reducing the chance for undiscovered bugs.

The source code does NOT strictly fall out of the spec. Instead the two co-evolve as the project procedes. The debugging/QA/verification process detects "bugs" which are defined as differences between the spec (or its non-canonical derivitaves) and the executable derived from the source code. The bugs are fixed either in the source code or the spec. A spec bug may be an ambiguity, an internal inconsistency, an ommission (including deliberate ommissions to allow flexibility to implementors, later filled in with the choice made), an error deriving non-canonical documents (such as comments or user documentation) from the spec, a misfeature, missing feature, unnecessary/difficult feature, or an adequate design choice that is later replaced by something considerably better discovered during implementation. A source bug is any program behavior that doesn't match the spec in a way that doesn't expose a spec bug.

What the so-called formal correctness proof tools can do is automate various aspects of the comparison. Once properly configured they can do, with machine-level reliability and speed, many of the same things that software QA people do. (For instance: Identify "edge" and "corner cases", determine that the behivor is right at and near the edge/corner, and generate inductive proofs that the behavior will be correct throughout the parameter ranges.) And once the tools themselves are debugged, they can do more of it, with less chance of error, than can be done by human effort. This also allows them to perform classes of testing that would be impractical without them, because of the manpower and time costs, because the complexity of the test would lead to errors and thus to missed bugs and bogus bug reports, or because they perform a class of test that is just not a good fit for a human mind.

Finally, formal tools provide additional specification languages, distinct from the implementation language, leading both to clarity of thought and a distinct mindset in the creation of the second expression of the program's behavior, and thus to less overlap of the bug set in the two expressions.

Scheme

[Anonymous Coward]

The first CS course I took was in Scheme ("to teach you the algorithmic way of thinking") and that functional crap almost made me to switch my major subject to mathematics. "What? I can't use variables? You must be kidding!"

Re:Scheme

[acidrain]

Amen. I still belive the prof who made us learn scheme was a sadist. To quote him "people can actually learn anything as thier first language, with about the same amount of dificulty. This stuf just seems hard because it's not the way you are used to thinking." Bah. The most important aspect of a lanugauge is it's readability. Scheme gives me "bent toothpick syndrome."

Re:Scheme

[Another MacHack]

Just so we're clear, you didn't like scheme because it was "too functional" and you didn't get to use mutable variables, so you almost became a -math- major instead?

Pike (Was: Functional Programming: try it in Perl)

[kinkie]

Pike (recently discussed on /. offers many cute features on this:
- functions are first-level variables. They can be (and are quite often) shuffled around
- it supportsclosures
- it has anonymous (lambda) functions
- tail-recursion optimizations
- automatic memory management, via both refcounts and garbage collector
for more stuff check the previous discussion.

This does NOT make Pike a functional language by all means. It's just that it allows people to write functionally those tasks where it helps to do so.

If it wasn't for Scheme...

[morzel]

... I'd still be praising the person that invented the goto statement :-)

Seriously: I've been coding from when I was 11 years old, and throughout school the biggest change in my coding style came with switching from BASIC to Turbo Pascal. Besides having procedures and functions, nothing really changed in getting the things to work.
When we started using scheme in CS, a whole new world opened up: for the first time in years, I put more time in algorithms than I did in code.

It's too bad that - in spite of the beauty of the code - there really aren't that much applications of scheme and the likes. Without scheme, I would have probably missed the point of OO completely.

Okay... I'll do the stupid things first, then you shy people follow.

Re:they are too hard

[RedGuard]

LOL!
go_to_the_park is_it_raining = if is_it_raining then "Yes" else "No"
(go_to_the_park in Haskell)

Re:OT: Meta moderating

[Axe]

170000 range? Man, people poured in like hot grits in yyour pants lately.. :)

Re:Experiences...

[boloni]

As far as I know from Heisenberg, everything in the world has some side effects.

In fact, engineering can be defined as clever application of side effects. The fire is a clever application of the side effects of a chemical reaction.

But in the sense we are speaking here, a factorial function in C does not have any side effects, and is perfectly parallelizable and distributable.

Lotzi

Re: Newbie question

[milesegan]

The online documentation is admittedly a bit sparse, but there's also a b ook, which, although ambitious, works as an introduction. It uses an older dialect of OCaml, Caml Light (these guys have a sense of humor too), but is still useful for learning OCaml. What we really need is a Learning OCaml, although I'm not sure what the animal would be since the camel is already spoken for.

Believe it or not, there is an O'Reilly Book, but it's only in French right now. There's been a lot of discussion on the OCaml mailing list about an English translation, but you're out of luck for now if you can't read French.

Re:Make C and Java functional

[sillysally]

I don't buy the efficiency arguement, but if you think it's that important, add a compiler directive to allow undefined return values from functions, or use void. I'm not totally rigid about it, I just want the user to have the tools to accomplish functional programming. Specifically hat I was referring to was giving "if" and "while" return values which is something a user can't do on her own. Compilers could easily check to see if they were used and toss them out if not.

SQL - widely used functional languag

[DevTopics]

Well, SQL is a widely used functional language (4GL, a fourth generation language). Most people have a hard time to grasp the use of a non-procedural language: just think about it how long it took to get object-orientated languages to be applied widely. And even now, most languages that you find in programs are still 3GL. And even if you will see a program advertised as written in C++: most of the time this is written in C, but compiled with a C++ compiler. Which hardly counts as object-orientated. We are so used to program in 3GL that it will take us a long time to make full use of other concepts. This is even true for SQL: most people tend to program cursors where a shift to 4GL would be a lot better. It will just take time...

Re:SQL - widely used functional languag

[tofupup]

SQL is a declarative language not functional

Re:SQL - widely used functional languag

[SpanishInquisition]

No it's not. Check your facts before posting.

Re:SQL - widely used functional languag

[alienmole]

First off, pet peeve. . .orientated is *not* a word.

Merriam-Webster's Collegiate Dictionary disagrees with you - see their definition of orientate, which dates from 1849.

Although it's true that "object-oriented" is the more common phrase, "orientated" does get used some outside the U.S., I've noticed.

Re:SQL - widely used functional languag

[fm6]

SQL may be an imperative language, but not all imperative languages are functional.

Also, "Fourth-generation language" is one of those trendy buzzterms that started out as 90% hype, and finally degenerated into meaninglessness. Are you still waiting for imperative languages to supersede procedural languages? Don't you get bored? And doesn't it bother you that every IDE that comes with a database engine proudly calls itself a 4GL?

Re:SQL - widely used functional languag

[FigWig]

SQL is a descriptive language - you describe what results you want, but you don't say how to arrive at the answer. I believe it has more in common to PROLOG than to a functional language.

Recursive Thinking

[jjr]

Alot of people can not used to thinking recursivly. Since there are other "free form" languages out there they don't bother to learn it. That is why it these languages are not used as much as they should be.

Re:Recursive Thinking

[Black Parrot]

> Alot of people can not used to thinking recursivly.

All the more reason to use them to teach programming, IMO.

--

Re:Recursive Thinking

[avandesande]

see the next message

Then you have read bad Perl

[tilly]

Or else you never learned the language.

The "funny symbols" define a miniature grammar. Learn that grammar and it gives you guidelines about how to think about hashes etc. (Guidelines such as what you should name them.) Next use strict to stop pointing your gun footwards. Warnings exist for a reason. Turn them on as well. Finally avoid default variables except where they are necessary.

Now follow basic sane programming guidelines and Perl is perfectly readable.

It gets a lot better when you start using it like it was meant to be used. For instance the language is a list-oriented language for a reason. There are a lot of constructs that are syntactic sugar. Use them wisely. Note that map() and grep() give you all of the power of a pipeline without the problems of parsing and reparsing text, use them.

Now learn perldoc, use package namespaces, use Exporter, start taking advantage of the flexibility to make the style suit you...

Perl gives you rope. Yes. But don't judge the limits of the language by people who commit maintainability suicide...

Cheers,
Ben

Comments on Date and Darwen

[Baldrson]

SQL is not even strongly relational; see Darwen and Date's Foundation for Object/Relational Databases: The Third Manifesto.

While I agree SQL leaves a lot to be desired, Date and Darwen have some fundamental problems of their own. Here are some comments on Date and Darwen composed by Tom Etter and myself during a Relation Arithmetic research subproject at Hewlett-Packard's E-Speak project:

* Date and Darwen: All logical differences are big differences ... and all non-logical differences are small differences.

Comment: This is wrong. All differences are logical differences. All big differences are rational differences. Rationality requires more than logic - it requires a sense of proportion. One of the chief aims of our new relational model is to bring a sense of proportion into the querying of data.

Their message here is perhaps better expressed in their discussion of conceptual integrity (p. 8), where they speak of the need to rigidly adhere to "a coherent mental model" at the foundational level, to which we say amen.

* Date and Darwin: The first logical difference we want to discuss is between model and implementation, which we define thus. A model is an abstract, self-contained logical definition of ... the abstract machine with which the users interact. An implementation of a model is the physical realization on a real computer system of the components of that model. Comment: In this quote we witness the great tragedy of the computer industry:

Ignorance of the complimentary roles of man and machine exposed by the computational intractability of relational systems.

This quote is all the more poignant because Date and Darwin are authorities in relational systems.

Instead of a hard definition of "the abstract machine" as the "model" with which "the users interact", an man/machine partnership interaction of humans and machines is needed in which both all are rational about their limits and ask the others for assistance. This partnership ranges continuously from the start of the software process through the execution of workflow to the solution of immediate problems. The interaction starts when humans specify their intention with intractable queries. The machines detects intractability and queryies humans other actors for increasingly specific predicates until reaching tractable problem specifications.

Actors are rational about their limits when know when to count on the actions of others and when not to. Counting is fundamental to accountability. It is this notion of counting that we introduce at the foundation of our relational system.

Codd's SQL was a "fourth generation programming language" which was envisioned to dramatically reduce the distinction between users and programmers. Too much cynicism has been attached to this vision. While leaving much to be desired, SQL was a giant leap forward in the computer industry because it was a small step toward a relational paradigm of man/machine interaction.

Further Comment: We see the need to distinguish three levels here rather than the two levels of model and implementation. Our fundamental level is what we'll call relational structure. We'll turn to this in detail shortly, but suffice to say here that it is essentially self-contained. Next is the level of predication, which encompasses relational algebra and predicate calculus. Unlike the structural level, the level of predication is not self-contained but spans the gap from structure to implementation and connects the two. It is tied to structure through logic and becomes increasingly concerned with the practicalities of language and the needs of the user as it approaches the physical computer. The third level is of course that of the physical computer itself, which is the "realization" of this middle level.

Where, then, is Date and Darwen's relational model in this scheme? It certainly involves the structural level, but it also includes a good deal of predication. The authors call their model a "self-contained logical definition of the abstract machine with which the users interact." We believe that it is better not to think of this abstract machine as self-contained, since its proper design has a lot to do with who is using it for what. We do share their desire for "conceptual integrity", but we believe this is better directed toward the level of structure.

* Date and Darwin: The question of what data types are allowed IS COMPLETELY ORTHOGONAL to the relational model (Appendix G p. 439).

Comment: This is a very revealing statement, and points straight at what we mean by relational structure. Here is the key definition:

The shape of a relation is defined as that about a relation which remains unchanged when we replace its values one-for-one by other values.

A one-for-one substitution of values will be called a similarity substitution, and if R' can be obtained from R by a similarity substitution, we say that R' is similar to R. The shape of a relation can be formally defined as its similarity class. Thus the structural level is about entities called relational shapes, or simply shapes for short.

Cells in a relation table with the same value will be called congruent (later we'll extend congruence to sets of cells). Another way to define a shape is as a table for which we are given a congruence relation on the cells rather than an assignment of values. Clearly there is only one such table for each similarity class (we are ignoring the row and column orders in the tables - see below).

The concept of shape comes from Russell and Whitehead's Principia Mathematica (1912), though they used the term relation number instead of shape. They had planned to write a fourth book of Principia devoted what they called relation arithmetic, whose point of departure was Cantor's arithmetic of ordinals. Russell had a vision of relation-arithmetic as a powerful tool that would enable us to deal with every kind of structure, including the structure of the empirical world:

"I think relation-arithmetic important, not only as an interesting generalization, but because it supplies a symbolic technique required for dealing with structure. It has seemed to me that those who are not familiar with mathematical logic find great difficulty in understanding what is meant by 'structure', and, owing to this difficulty, are apt to go astray in attempting to understand the empirical world. For this reason, if for no other, I am sorry that the theory of relation-arithmetic has been largely unnoticed." Bertrand Russell [ref.]

Relation arithmetic didn't get very far, however, and in retrospect it's easy to see why. The problem is that the most important combining operators for relations, such as Cartesian product and join, are not invariant under similarity. That is, if A is similar to A' and B is similar to B', it does not follow that the Cartesian product or join of A and B is similar to the Cartesian product or join of A' and B' [ref.1, section --]. To put it more simply, shapes don't combine into shapes. We'll return to this point.

* Date and Darwin: RM PROSCRIPTION 3: NO DUPLICATE TUPLES (p. 173)

How may words in the sentence "First come first served"? Four if you count duplicates, three if you don't. Duplicates arise in relation tables when you project onto certain columns, ignoring the rest. In the sentence above we must have two occurrences of "first", since the two reach out into the context in different ways. The same is true of duplicate rows, which reach out into the other columns in different ways.

It is crucial to count duplicate rows when we need to know if several (projected) parts of a table are independent. To see why this is so, we must carefully distinguish between two meanings of independence. Let P and Q be two projections. Then:

Logical independence: Every pair of distinct rows in the P and Q is a distinct row of PQ, and there are no other distinct rows in PQ.

Independence in place: Every pair of rows in P and Q is a row of PQ, and there are no other rows in PQ.

Clearly the first does not imply the second. The duplicate row counts in PQ provide a numerical profile of how P and Q are correlated, and indeed it's possible for P and Q to be almost perfectly correlated despite being logically independent. Conversely, they can be independent for all practical purposes despite being logically dependent. In the real world there are occasions when logical differences are very small differences and non-logical differences very big differences.

Etter and Bowery: RM PRESCRIPTION 3: YES! DUPLICATE TUPLES. In practice duplicate tuples are represented by a count associated with every distinct row.

* Date and Darwin: RM PROSCRIPTION 1: NO ATTRIBUTE ORDERING (p. 171)

* Date and Darwin: RM PROSCRIPTION 3: NO TUPLE ORDERING (p. 172)

Comment: We agree.

* Date and Darwin: RM PROSCRIPTION 10: RELATIONS. A relation consists of a header and a body, where the header is the set of column names.

Comment: Names, including column names, belong to the level of predication, and for now we are considering the structural level. However, the role of column names can be filled at the structural level by key rows, or more generally, by sets of rows the constitute keys. We believe it is better to do as much as possible at the structural level, if for no other reason than that computers operate on structure.

Nice

[Tom7]

An admirable attitude!

Unfortunately it tends to take a long time to appreciate functional languages. I've been planning to put together a "fun introduction" for hackers that might make it easier... this slashdot article has re-inspired me to do just that. =)

Good luck with Hugs!

Re:Nice

[jallen02]

Thanks, I understand the concept is hard to wrap ones mind around in a single session or anything but making some keynotes and just showing some of the general slcikness/cool points to a functional language with some well written code would still be really cool, like some really common routines such as the quicksort comparison I found, but some more in depth stuff would be awesome..

Really from what I have read im interested enough to start figuring out a functional language.. problem is a lot of these examples are written by research type people and the examples tend to assume you have a lot of knowledge :) anyways I appreciate some of the well informed posts ive seen running around here... This was a facet of programming I almost ever looked at in this light before ;) Thaanks


If you think education is expensive, try ignornace

Re:Gnome and Scheme

[rjh3]

The "why" question is well answered by the elk pages. Scheme's functionality is a marvelous match to the needs of extension languages.
- The compiler/interpreter is of modest size.
- The performance is very good (for an interpreter)
- The language is known, well defined, and complete.
But is has the problems of
- having lots of irritating silly parentheses.
- being considered weird.

I know that when I needed a programmable control language for a network tester we looked at the alternatives of TCL, Perl, and Scheme. (This was some years ago, when Perl integration was very hard and Python nearly an unknown.) The implementation cost of integrating Scheme was about 20% that of the other two, and with Scheme we got the immediate support for the kind of complex nested data structures that we needed. With the other two, the test script implementers would have had to write all that.

But, the learning curve for LISP is much too high. What the testers really want (and now have) is a pretty GUI interface.

Re:WHAT!!!

[bgalehouse]

I was once desperate for an expression based if or case statement in SQL (like the ?: construct in c/c++/java). While the specific DB we were using might have had such support, the experienced sql persons and documentation that I referenced didn't yeild and answer.

I think that sort of says it all. If aren't putting conditionals into expressions, you aren't doing functional programming. Almost by definition.

I ended up doing the conversion through a temp table. This is roughly similar. But not really the same.

quicksort in Haskell

[bharlan]

Here is a quicksort in Haskell from http://www.haskell.org/aboutHaskell.html:
qsort []= []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
where
elts_lt_x= [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]

Functional languages work recursively, but they make your mind work inductively . If you can handle going from n to n+1, then you can handle any depth of recursion.

Re:The masses can't handle FP

[timmyd]

an example would be if you were writing a function that calculated the product of the list. perhaps a normal scheme recursivly multiply all the elements together. however you could use call/cc so if you have a zero in a big list of numbers, you can pull out early. see this part of a tutorial for details.

And the language you are thinking of is:

[Estanislao Mart�nez]

For this reason, I think the best way to incorporate functional paradigms is to extend our imperative languages with functional features:

There is nothing incompatible with having both things in a language. Try Common Lisp, it embraces both models fully.

Type safety.

[Ungrounded Lightning]

I have to take a position distinct from both of those above.

[] once your programs typecheck, they Just Work

This is a myth.

I agree with the second poster on this point. But...

[the errors] that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.

Strong type checking in imperitive languages (particularly OO langues such as C++, but to a lesser extent non-OO languages such as ANSI C) is often criticized as being too restrictive and too complex. But in my direct experience, complaints that type-checking was too restrictive or onerous were mostly made by software "cowboys", whose code tended to be horribly bug-ridden. (I trust the second poster doesn't fall into that category.)

What strong type checking does is provide toolset support for catching design and implementation errors characterized by mismatched interfaces. When combined with a good OOP-style type declaration system you can express your intent clearly to the compiler - and to yourself and the other members of the project. The key to making it your friend is to understand it and use it in that way: Take a few moments to express the intended uses of your variables via types.

Mismatched operands are a symptom of lack of clarity of thought about what is going on at the interface. That lack of clarity leads to much more subtle bugs than just exchanging operands - bugs you can hunt for for days if they're not pointed out, but which jump out at you as soon as a compiler complains.

A good type system, properly used, doesn't normally get in your way. And in those rare cases where it does some languages (such as C++) give you a mechanism (such as cast to void or pointer-to-void, recast to alternative type) to explicitly override it, while expressing your intent to do so.

While my experience is primarily with imperitive languages, I suspect the same is true of functional languages - providing the type safety doesn't get in the way of code reuse (as it did to a small extent in C++ before templates, though this could be easily worked around with macros).

Re:Type safety.

[Ungrounded Lightning]

Types are in a class system. You have your most generic polymorphic types and then the set of values can be restricted as much as the programmer needs. I can't explain it exactly, but I think it is this that prevents the need for them weird hacks you described.

Sounds to me like the sort of type safety C++ provides.

Types may be basic, enums, agregates (structs) or classes. Classes can have arbitrary characteristics - including classes that look, act, and are stored like variables of the basic types but with arbitrarily limited ranges. Class types can be arranged in a forest of inheritance trees. Arguments of a type at a particular node in the inheritance tree allow passing of objects of that type or any descended from it. A class can be defined in a way to prevent further subclassing.

Sound like the same sort of thing to you?

Re:Type safety.

[extrasolar]

While my experience is primarily with imperitive languages, I suspect the same is true of functional languages - providing the type safety doesn't get in the way of code reuse (as it did to a small extent in C++ before templates, though this could be easily worked around with macros).

I am definitely not any kind of expert in functional languages, but I have been studying them for a while now. You see, the types in functional languages, at least Haskell, are quite different from what you would experience in C or Pascal. Types are in a class system. You have your most generic polymorphic types and then the set of values can be restricted as much as the programmer needs. I can't explain it exactly, but I think it is this that prevents the need for them weird hacks you described.

Re:Type safety.

[Tom7]

C++'s type system is really nothing to speak of compared to ML's.

C++ does not have type safety, at all, because you can cast. You can free or use memory you've already freed.

C++ does not have (fully) abstract data types because you can always cast if you know the representation.

In fact, C++'s static system (templates in specific) is pretty screwed up, because you can write programs which "compile forever"!

Some of the same mechanisms are available through careful programming, but there's nothing like the guarantees (with proofs) that come with a type system like ML's.

Re:Experiences...

[Tony-A]

A C function can return a pointer to a previously existing function. What it cannot do is to _create_ a function and return a reference to it.
One critical difference is that a functional language will allow a program to be written top-down.

CTY uses Scheme

[bskerr]

Interestingly, all the computer science classes at the Center for Talented Youth (CTY), a Johns Hopkins-based summer academic program with a self-descriptive name, are taught in Scheme. They had at one time used Pascal, but chose Scheme over C++. Needless to say, the classes stretch the students' minds---even those with years of programming experience.

Interesting enough...

[CroxWire]

Functional languages have a natural hiearchy; basically after you finish one block of code you know right away what needs to be done. However, OO languages for the inexperienced usually leaves them wondering which avenue to take, which objects to consider in their project, but with time, this difficulty disappears. This raises an interesting question, which is better for beginners to learn? I started programming in 5th grade so you know my answer (There were no OO languages when I grew up). But back to the issue at hand. You can't totally throw one form out completely, for not every program should be solved in OO manner. I don't think OO can be a pancea, and who else could I possibly use to support this claim, yes, Bjarne Stroustrup, he siad "... OOD/OOP is my favorite way of approaching design and programming. It just isn't the right style for every program and for every detail of a program. Some good abstractions are best represented outside class hierarchies. Trying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs." So with that said, there will continue to be a place for both styles, so there will also be a place for both languages.

Going to another point of dead languages. To claim that one is dead, like ADA, like Fortran, like Pascal is to totally miss the point, we built off of these languages, they have transformed into alot of things we use to today. For example, look at the similarities of ADA, Modula-2, Pascal, and Delphi Do you see any similarities of basic, and Fortran?

IMHO

Re:Bugs + Math

[Tom7]

What bubble are you trying to break? Yes, we don't make programs to prove that our type systems are safe, but why does that matter? It's still proofs, carried out in a mathematical formalism.

I just didn't get it.

[Kris Warkentin]

I took a course in Scheme and did alright - coding small things to do simple stuff is not that bad. Due to my personal limitations though, I just couldn't see how one could develop big, useful applications with them. I'm not saying that it couldn't be done but that years of procedural programming seems to have hardened my brain. For whatever reason, I just had trouble wrapping my head around it.

I've heard that functional languages are easier to learn for someone who has never programmed before. I think, however, that for people who have written a lot of procedural code, it's very difficult to get used to. Perhaps that's why: not enough people START with functional languages and, once you know procedural (or OOP), there's very little reason to switch since you can do most everything you need to. I guess you just choose your poison: Turing or Church.....

Re:I just didn't get it.

[logicnazi]

Actually I have programmed both in functional lnguages (common lisp) and procedural ones. Right now I am working on a reasonable sized project in common lisp and I find it *much* easier.

I find in procedural languages it is far easier to mess up in the architecture. You would get to writing some procedure and find it needed access to variable it couldn't get access to or needed to mostly reimplement code that had been rewritten elsewhere but not in a reusable fashion.

In Lisp the encouragement is to write all the small utilities first (and certainly not on data structures which fuck you up b/c they make you concentrate on large scale layout first) and this makes it much easier to build a large project because by the time you have to write the higher level functions you have a very good idea exactly what is going on (as you already wrote the lower level functions).

Secondly (partially in response to the next post) I find it generally easier to debug. In a procedural language you have to go through line by line always to find an error b/c you have large complicated functions. Usually my function bodies in lisp are much sorter consisting mostly of calls to other functions. As such a simple trace or bactrace will be far more helpful than 20 minutes stepping through code.

Defining infix operators.

[Ungrounded Lightning]

you might want to try ML, since it's the only language I know of which lets you declare your own infix operators. (C++ only lets you overload, not declare new ones)

I mourn the death of "MAD".

Re:Defining infix operators.

[ArrayMac]

>...ML, since it's the only language I know of which lets you declare your own infix operators.
...thus you don't know APL.

{def}r{is}a plus b
[1] r{is}a+b
{def}

3 plus 4
7

and you don't know J:

plus =: +
3 plus 4
7

Abstraction and Debugging tools

[umeshunni]

I feel one of the main reason why functional programming languages are not being used quite often and extensively ( other than the fact that they are not being supported by big corporations unlike C++ (C# ?) and Java ) is the high level of abstraction that operate at.
Procedural languages like C/C++ and Java conform to existing hardware and assembly programming concept by providing methodologies and keywords that can be directly mapped to assembly equivalents such as function calls, return values, memory allocation etc. On the other hand, functional languages do not provide such an easily mappable or understandable paradigm.
Debugging Functional languages can be quite messy and of course i don't know of any good debugging utilities for languages like (S)ML that are purely function in approach.
Lack of toolkits might be another reason but then i am not too sure about what GUI toolkits Haskell has.

Re:Abstraction and Debugging tools

[BeeJay]

Is there any reason (theoretical or otherwise) for the lack of a processor/architecture which more closely corresponds to the functional way of programming?

Well, a computer works in a very imperative fashion - just look at it: the disk arm moves, things are written to disk (destructive update), the RAM has a **state**. It is all state and actions, and there's nothing to do about that. In the end, the world is imperative in its nature.

My conclusion is that every (re)implementation of the digital computer will only give a constant speedup for functional programs. That constant might be high, and is worth going for.
The way of supporting functional programs in a CPU would probably be to have hardware support for some of the common operations at the low level of the implementation of the "runtime machine" that runs the program. Such operations could be handling closures (thunks), hardware support for garbage collection (maybe implicit ref-counting).

So the answer is yes and no: You cannot implement a "functional computer", since any (real world) computer is implemented on top of (real world) physics, but you could have CPU instructions/architecture better suited for execution of functional programs (speedup by a large factor).

Re:Abstraction and Debugging tools

[mill]

Manuel Chakravarty is already working on bindings to gtk+ ( http://www.cse.unsw.edu.au/~chak/haskell/gtk/ ).

/mill

Re:Abstraction and Debugging tools

[Petter Remen]

Is there any reason (theoretical or otherwise) for the lack of a processor/architecture which more closely corresponds to the functional way of programming?
Or, a similar question, is there any theoretical limit to how efficient an interpreted language such as Haskell can be on the architectures of today?
And on debugging: It may be hard to debug functional code, but it is atleast easier to mathematically prove that they work in the first place :-)

Re:Abstraction and Debugging tools

[wik]

The flipside is that if you're willing to put more time into abstracting and kneeding (as I like to call it) the functionality of your project, the time actually spent coding and debugging can be lowered significantly (in my experience, the total time from start to finish is about the same, but I am generally more confident and sure that the project is finished if I spent time thinking about it). This applies to any language, not just functional languages (where code without forethought probably won't even compile in SML)

Also, I found that when I was writing SML (only in a college course), I really didn't need a debugger. When I was really stuck, sometimes a little string printing function was useful, but beyond that it was much easier (and more revealing to stand back for a few minutes and look at what was really going on). And of course, SML has the wonderful property that if it compiles without warnings, it will practically never crash (though it may never stop recursing, either :) ).

In my mind, programs written in functional languages have a natural modularity to them. You don't find a lot of speghetti code or unneeded work. I still find myself using C++ and Java in the real world, because a 50MB runtime library is rather heafty. I'd also have trouble finding coworkers who could tolarate the language. :)

Re:Abstraction and Debugging tools

[umeshunni]

I agree with about the development time for function programs being less due the absence of debugging. But isn't this true only for very small simple programs. Sure you can code a working Tower of Hanoi or n-Queens simulation in SML in no time ( that's what we did in college while learning SML ). But how long would it take you to 'abstract and kneed' an MS Word or Netscape or even a simple utility like grep or wget using SML ? I can't even imagine doing such event-driven or input-specific programs in a functional language ( but of course i code only in C/C++/Java/asm )
-u2

Re:Abstraction and Debugging tools

[wik]

As far as user interfaces go, I wouldn't want to write them in SML, either! :)

I wouldn't call grep or wget simple (see the documentation if that's at all unclear!). I don't believe that those two in particular would be terribly bad, though. Performance would probably be really crummy, but I could imagine that some of the more mundane uses of wget (recusively mirroring a website) would come naturally to a functional language.

On the other hand, I think the user interface or presentation of a program should be well-separated from it's data structures or, more towards the dollars sign, its business logic. Why can't the application tier of an e-commerice site be SML-based? With the appropriate connectors (CORBA-based or otherwise) to databases and either a slew of HTML-generating code or some other connector to JSPs, I could see it happening. Would it catch on? I don't know. Java has positioned itself to work well like this. An event-driven program would probably crawl in SML, there are graphical toolkits for it, but I have never used them. If SML is used for the innards, however, it could be much more manageable.

Re:Abstraction and Debugging tools

[umeshunni]

The current Von Neumann archetecture and the stored program concept seems to favor jumping around in code and manipulating memory bits that forms the base for procedural program. all other paradigms as essentially emulated on this archetecture making them inherently inefficient due to the conversion/emulation overhead.
Another reason is the inherent typeless nature of memory devices that introduces overhead whenever the type of a data needs to be checked or its 'implied' value ( as opposed to its binary value ) found.
Maybe, if we had a memory system where the bits were also 'typed' it might favor another programming paradigm.

-u2
>> In case you think everything i said in my post is wrong... You might be right

Re:Abstraction and Debugging tools

[mremond]

Debugging Functional languages can be quite messy and of course i don't know of any good debugging utilities for languages like (S)ML that are purely function in approach.

I think this is not true.

You should give a try to the Erlang functionnal language.
Their debugger is really amazing.
Really useable and even really useful as a learning tool.

Check:
http://www.erlang.org/

haskell is great!

[Anonymous Coward]

like all languages, functionals ones are good for certain kinds of jobs and not so good for others. Performance and low level hacking are problematic for function languages. They excell as research tools though. I hope that advanced typing systems with monads, functors ... will trickle down to the OO-world. BTW, simon peyton jones (haskell guru) and some colleagues has some interesting research going about a machine independent assembly language to replace C (http://www.cminusminus.org/)!

Scheme

[smoondog]

Using scheme isn't the best solution for a lot of things. I think its biggest hinderance is its obscurity, nobody but serious hacks and cs majors knows anything about it. Anything I write in scheme, I have to deal with, cause no one else can. For my purposes it really doesn't do anything a lot of other languages can do just as well. And other people can hack at my c or python code.

-- Moondog

Classes and Modules should be orthagonal

[Dag Hammerskjold]

It is true that "[t]rying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs". That is why (considering imperative languages, not functional ones) a language should have both classes and modules. Trying to use classes to do the job of modules is what leads to contortion.

Re: on type systems

[Tom7]

You've got a good point here, but what can I say...? People research what they like. If you like type systems, it's pretty likely that you'll like functional programming too, since they're so similar. I do believe there is something fundamentally more natural about typing a functional language than an imperative one, though.

> -you are losing power of representation and
> performance to have better compile time type
> checking

I would say that ML has an increased power of representation. Most notably, being able to get 100% abstract data types.

Over java, ML's compile-time type checking improves performance. If safety is an important language feature, static typechecking is almost certainly the way to go.

ML's design was definitely heavily influenced by its type system. Not too many people will apologize for this (since we think it's pretty good!) but you might be interested that they're doing something different with ML2000: A backend "core calculus" has all of the type stuff defined on it, and the language itself is defined in terms of a translation to this core calculus. This is a good idea, and it might help get rid of the influence of the type system (if indeed it is negative). Conversely, you could write your own frontend and have your own language with all the powerful typechecking ML2000 will have!

static typing

[Tom7]

> it is harder to argue that ML is more productive
> than Erlang or pure Lisp, for example, based on
> static vs. dynamic typing.

Really? I find static typing to be a huge help in debugging my programs. I wouldn't give it up for anything! It may come at the intellectual overhead of learning the type system, but once you do it really does make sense.

Re:static typing

[Junks Jerzey]

> it is harder to argue that ML is more productive
> than Erlang or pure Lisp, for example, based on
> static vs. dynamic typing.

Really? I find static typing to be a huge help in debugging my programs. I wouldn't give it up for anything! It may come at the intellectual overhead of learning the type system, but once you do it really does make sense.

Really :) Compared to C, both ML and Lisp provide interactive development, garbage collection, higher order functions, and less bookkeeping clutter. With all of that on the table, with both languages far beyond C in those ways, it is difficult to tell how much of an issue the type system plays in productivity. You will find many notable experts who prefer dynamic typing (Peter Norvig and Kent Pitman, for example), and you will find many other notable experts who prefer static typing. So it is more of a personal preference than anything else.

Re: Parenth's

[Nagash]

Why does it use all parenthesis?

Simple. It makes the syntax dead simple to parse. All Scheme and Lisp has this general form:

(function-name arguments...)

Of course, there are special forms, like cond and macros, etc.. I've written a parser for C, and I'd much rather write a parser for Scheme and variants. Much easier.

Anyway, delimiting expressions with parenthesis makes parsing much simpler and with an editor that matches parenth's for you, very easy to write in.

Woz

MODERATE THIS DOWN!!

[Estanislao Mart�nez]

Moderators: the parent is not (+1, Informative), but (-1, Overrated). This lenghty post is all wrong. I even checked the troll forums to make sure this wasn't a troll and found nobody claiming it. And in my experience no troll takes so much time to write a single post.

in point of fact, 'pure' functional programming (no state, no side effects) can only handle the kinds of problems that can be solved by a pushdown automaton. in theoretical terms, they can only handle prolems up to and including context free grammars.

[tons of BS snipped]

The lambda calculus, which is the logical foundation of functional programming, is Turing complete. Period. There's no getting around this. If a language has application and abstraction, it is Turing complete, and can compute all computable functions.

'pure' functional programming can't do that. it involves storing a value, and that's something functional languages don't do.

Bullshit. "Storing values" is a function from an initial state to a modified state. This is trivial to express functionally as a function on states.

to make themselves Turing-complete, functional languages rely on a trick known as 'stream programming', which rests on a sneaky form of variable storage called 'deferred execution'.

BS again. Streams have nothing to do with the Turing-completeness of functional languages. The lambda calculus is Turing complete; evaluation regime (strict or lazy) makes no difference.

we've created something static and unchanging that still manages to act like it has state.

You simply don't grasp the idea that states can be first-class objects you manipulate functionally. Yes, you can simulate states in a purely functional language. This does not mean the language is not functional; it is not, since the semantics of the language itself have no notion of state. Functional programs can explicitly implement the notions of states and state transitions.

Re:MODERATE THIS DOWN!!

[SimonK]

Yeah, you're right. Although he takes a very long time getting around to it, the parent post seems to be well confused about what constitutes a functional programming language. The author seems to thing they're equivalent to push-down automata (finite state machines with stacks, OK?), but this Just Ain't So.

The source of the confusion seems to be that he assumes functional programming languages are just fixed trees of recursing function calls. If this were so, he'd be right. They aren't, though.

Functional programming languages allow functions to be passed around as values, and these have full first-class status - so you have functions that take functions (which can do loops, or if-then-else constructions), and functions that return functions, which can do all kinds of funky stuff, including, importantly, functions that return a function that does the same thing, but with one parameters already set.

This seems to be what the author is getting at in his blather about "stream programming" and "deferred execution". Its not just a hack, though. Its the very heart of the lambda calculus - its how, in fact, you derive arithmetic from simple functions alone.

*However* the author is clearly a clever chap, and has obviously come up with all this stuff himself, so I say let him keep his mod points. Original thought should be encouraged - even when its wrong.

Re:MODERATE THIS DOWN!!

[Estanislao Mart�nez]

*However* the author is clearly a clever chap, and has obviously come up with all this stuff himself, so I say let him keep his mod points. Original thought should be encouraged - even when its wrong.

Bah. The author is clearly not clever enough to know that he should know stuff before claiming in a public forum he knows the stuff. This was as "Informative" and/or "Interesting" as a 10 page long proof that 0=1.

Re:MODERATE THIS DOWN!!

[pnkfelix]

Actually, I find 10 page proofs that 0 = 1 to be both informative AND interesting. After all, they usually demonstrate (quite forcibly) how fragile our own minds are when it comes to dealing with complex proofs.

Wait, I take that back. A 10 page proof that "0 = 1" written in a Computationally Verifiable Proof Language is neither Interesting (since documents written in those languages are rarely interesting for human eyes) nor Informative (since it wouldn't pass a Verifier). The only way such a proof COULD be Informative would be if it DID pass the Verifier, because then it would be exposing a bug in the program.

In any case, a proof that 0 = 1 written in the Style of our friend above can be a lot of fun to work one's way through, especially if it takes more than a few minutes to track down the source of the error in the proof.

Correct

[kaphka]

This lenghty post is all wrong.

I concur. My computability theory knowledge is mostly swapped to disk right now, but I know that a pure functional language can easily be Turing complete. There's a reason why the term "recursive function" is synonymous with "Turing-computable function".

Scheme is a toy research language

[Estanislao Mart�nez]

If you want a real Lisp, try Common Lisp.

If you think you're morally superior because you can write 12-level-deep lambda expressions.. I think you need to go outside some more.

Somebody who writes 12-level-deep lambdas may have a great brain, but is surely putting it to waste. Hell, if you've got just 3 nested lambdas, it is most likely the case that you should seriously rethink whatever you're doing, find suitable abstractions, and use these.

Re:Functional Programming has a bad rap

[ralphclark]

And it probably didn't help that Edsger Dijkstra was the Goto Considered Harmful man, since everybody knew those Europeans didn't really know how to program real programs! Just look at Algol, compared to real languages like COBOL or FORTRAN for crissakes!

I do hope that was intended to be ironic...

Consciousness is not what it thinks it is
Thought exists only as an abstraction

I could only use functional languages

[fishexe]

After all, if the language didn't /work/, how would I use it?

Ever get the impression that your life would make a good sitcom?
Ever follow this to its logical conclusion: that your life is a sitcom?

Functional Programming: its above our heads

[Ars-Fartsica]

While functional programming has always been considered more "elegant", a number of mitigating issues have prevented it from taking hold as a popular technique, beyond a lack of popular tools, libraries, or operating system interfaces.

The biggest mitigating issue - people don't think the way functional languages want them to. Getting to the point of "elegance" in Lisp or Haskell takes most people so long that it isn't practical to make the effort. Essentially, its above our heads. C++ has a related problem - the language is so complex that few can use it advantageously.

People should probably just accept this and leave functional languages in the dustbin of history. Looking at the real growth in languages - Java and Perl - we see two languages that take different paths to making things easier for programmers - Java through a rich set of libraries, and perl through a more "human" language structure.

Re:Functional Programming: its above our heads

[Yunzil]

Is it all a matter of personal preference, or experience? Or am I a mutant?

You are a mutant. :) No, but when I took SML in college, the problem I had was that I absolutely did *NOT* think that way. I never really got my head around it.

Re:Functional Programming: its above our heads

[Wolfkin]

Perl - we see two languages that take different paths to making things easier for programmers [...] and perl through a more "human" language structure.

Excuse me? I think I prefer my programming language to be mostly pronouncable -- at least in theory. Perl looks more like line noise than phonics. :)

Randall.

Re:Functional Programming: its above our heads

[pivo]

perl through a more "human" language structure

Perl more human? So that's why I've had trouble fitting in with humanity!

Re:Functional Programming: its above our heads

[umeshunni]

Agree with you on this one.
Functional programming languages require you to think in a recursive manner, which we are not able to do since our brains have limited stack space as well. Hell to imagine what would happed if our brains ran out of stack spaSTACK OVERFLOW. SYSTEM HALTED

Re:Functional Programming: its above our heads

[Ars-Fartsica]

Perl is significantly more complex a language than C++

The syntax can be more complex, but there is no comparison in term of development.

Perl has garbage collection, built in hashes, auto-vivification of variables, extensive regular expressions built in, etc.

Compare this with C++ (which is a fine language - don't construe this as a C++ rant), which even with the STL, still requires you to roll-your-own with many problems. In a recent Java Report interview, Bjarne admitted that C++ should have been realeased with better libraries.

Admittedly, this is an apples-and-oranges comparison - C++ and Perl attack different problem domains. I would say a better comparison is C and C++ - I think I can say with confidence that C++ has not been adopted by many C programmers due to its complexity (and also due to the huge binaries), and ultimately I think we must presume that C++'s time has come and gone.

Re:Functional Programming: its above our heads

[milesegan]

I think the real reason Java and Perl have been successful is that they were all carefully designed to resemble established, popular languages. Stroustup's stated goal in designing C++ was compatibility with C. Java is basically a simplified C++ with garbage collection. Perl is based in awk, sed and unix shell. All of these languages have marginalized languages that are technically superior in many ways - C++ vs. Ada or Modula, Java vs. Smalltalk, and Perl vs. Python.

Unfortunately, most of the obstacles to the acceptance of a new language are social rather than technical. Backward compatibility and the support of a powerful company are key. A new language faces the same resistance that a new operating system does. Corporations and programmers have made substantial investments in their current toolsets and skills and are very reluctant to throw that time and money away. Something like Java, that looks and feels very familiar, is palatable, but something like Haskell causes panic.

Open source programmers are lucky, though, because there are far fewer constraints on the tools and languages they use. We pride ourselves on making design and implementation decisions on a strictly technical basis, and there's no reason we shouldn't make our choice of languages any other way. There are a number of high quality free implementations of functional languages out there.

I've spent the last few years studying functional programming in my spare time. While I'm not sure that I'll ever use a functional language professionally, there's no question that I'm a much better programmer than I would be otherwise. Libraries like the C++ STL and language extensions like Java's anonymous inner classes make a lot more sense if you've been exposed to closures and generic functions. Studying CLOS makes the limitations of single-dispatch OO systems like C++ and Java clear. But most importantly, functional languages help you see the larger picture - to focus on the architecture of a system without getting lost in implementation details. My experience with functional programming has taught me more about software design than the shelves of OO design pattern books and UML bibles I've waded through.

Any programmer that really loves the craft of programming owes it to themselves to take a walk on the wild side with a functional language or two. I'd recommend Ocaml, a mature, full-featured system that comes with a blazingly fast byte-code and native code compiler, a debugger and profiler, a first-class YACC-like compiler generation tool, a full-featured standard library, and a growing collection of contributed code. If you really want your mind blown, read SICP.

Re:Functional Programming: its above our heads

[kaphka]

The biggest mitigating issue - people don't think the way functional languages want them to.

You know what's funny? When I first saw LISP, I said, "Wow, they made a language that works like I think!"

Is it all a matter of personal preference, or experience? Or am I a mutant?

Re:OT: Meta moderating

[umeshunni]

It probably cause you haven't turned on 'willing to moderate' in your user options. I did it last week and since then i've been getting to meta-moderate. I've been a user for only 7-8 months
I'm user #37000-sthing.. what about you ?

Elbrus E2K...

[PinkyAndThaBrain]

Is said to have hardware type support... of course I should probably say "hardware", not too many people believe it will ever see the light of day.

Interesting, but prolog did fail

[Convergence]

Interesting reading; I'll give ya that much.. Right now I'm going through the Hoar paper on your site.. Semi-interesting.

But it seems to be more along the lines of defining your langauge in a logical framework (a prolog-like language), then defining the semantics and theorems of it..

Suggestion, try looking at twelf (www.twelf.org). You can define any damned language you want in it, and for some, you can automatically derive theorems from it, and go up&down.. Not too good with the theorem proving between layers; but I doubt that you could make a useful sound top-down logic.

How about SAS?

[Voluminous Blowhard]

SAS is widely used and I would consider it a functional Language.

Re:How about SAS?

[Mdog]

No, SAS stands for something like Statistical AnalySis, or something.

I used it in school to do some pretty neat math stuff. It's not Free, it's not pretty, but it can really crunch some numbers.
Mike

Formal correctness proofs.

[Black Parrot]

Functional languages seem to lend themselves to formal correctness proofs. I don't mean to imply that it is not possible with other languages, only that it is (IMO) somewhat "natural" for functional languages.

For instance, check out ACL2. This is a LISP-derived system that can both execute code and do semi-automated correctness proofs of same. It works by having you propose correctness theorems about the code, and (cool part!) expressing those theorems in the same language as the code itself.

<trivia>ACL2 was used to validate parts of AMD's K5 and K6 FP operations after Intel's embarassing faux pas with the Pentium FP unit. I've heard that it was used even more extensively on the Athlon. (Strictly speaking, what ACL2 validated was a model of these processors, since the processors themselves are not actually written in ACL2's input languages.)</trivia>

--

Re:Formal correctness proofs.

[weg]

It is probably not user-friendly yet, but I think that correctness provers will be an integral part of future development tools. IFAD (http://www.ifad.dk) is working on an very nice proof-tool for VDM-SL, that provides a Java-User interface. Still it provides the whole power of the underlying HOL98-tool. Proofs will be part of our jobs soon...

Emacs

[Malc]

Designed for lisp. Always indicates with which opening bracket that your closing bracket balances.

Re: Parenth's

[civilizedINTENSITY]

Unlambda? Unreal!

Comment on Functional taught first

[TrixX]

In my university (not in the US), the Computer Science Carreer is taught this way:
First semester: Calculus, Number Theory, Logic, Group Algebra, Graphs, Automathon Theory, Grammars... (some of this topics are just overviewed, others are studied more deeply).

That gives a good mathematical basis; in the second semester, in the course named "Algorithms & Data structures", first programming is taught... in Haskell. With goods maths, that is very easily understood, the language is not an obstacle. We do some formal derivations and that... after Haskell, we learn to translate (ugly word in programming) that into imperative (Pascal).

So, functional, in my experience is not "innately harder", as I see a lot of people getting used more to that than to imperative (Pascal, or C, given later), it's just an issue of getting used to it.

Re:Employees resist as well

[Paul Johnson]

Too true. Of course, the way to Make Money Fast is to spot the next big language before anyone else does, and become an expert in it. Write some free software in it or something, so it can go on your CV. Then when the curve goes exponential and all the job adverts are offering training in the language, you can name your price.

Hmmm. Anyone got any historical data on Python popularity?

Paul.

Re:Dev time would take a hit.

[dvdeug]

Doubling productivity is still an enormous improvement.

And? Where do we get this "doubling productivity"? Moreso, how are we going to get a single language that doubles productivity across the board, from operating systems on up? That's what was being promised. Actually, to get the type of results he was claiming in the human sphere, you'd need an order of magnitude improvement. He was not claiming a better language, he was claiming a language so good people threw out all the old stuff and programmed in it exclusively. Something that Algol didn't do, something that Simula didn't do, something that C didn't do, something that PL/I didn't do, something that Ada didn't do, something that Java didn't do, and something that ML didn't do, no matter what the strengths of those languages. Something better than what even Fortran did, even though it probably provided order of magnitude improvements when it first came out.

Missing Features

[HiThere]

Note: After reading this I realized that I might need to make clear that by report I mean printed report. Hardcopy. Printout. Not screen display.

One thing that business "needs" is the ability to produce reports with fancy formatting. No language will be popular with business/office users if it doesn't have this feature. This is one of the mainstays of MSAccess. This is one of the reasons for MSBasic. The languages are terrible. But they make it easy to produce pretty reports about what you have done. As far as I have been able to determine these languages don't have this feature. This automatically rules them out of consideration for perhaps half to a third of today's computer application space.

Work arounds exist, but they are really kludges. The best choice that I have been able to come up with so far* is to write out a Tex file, and then order the computer to print that. This has some hope of being implemented in a portable manner.

*This defect is not the sole property of Functional Languages. It is the common property of most languages designed by and for technical people. We are generally more concerned with some other feature, though HTNL generation is becomming relatively common. But offices still run on paper. We may have spent more on printers last year than we did on computers (I exaggerate slightly, but the amounts are within a close order of magnitude).

Two cool functional languages

[Anonymous Coward]

1) Clean is a commercial, pure functional language that claims performance equivalent to C++.

2) Erlang is an open-source functional language for distributed systems, released by Ericsson. They developed it to run their networks, and say it cut their development time by about 90%. Check Google, all my links appear to be slashdotted or something.

The masses can't handle FP

[tmoertel]

Given that most of the certified "professional" programmers that I have bumped into during my last few years of consulting weren't quite up to the, er, daunting task of writing sensible code in VB -- or code that just plain worked, for that matter -- I doubt that they would understand, let alone appreciate, wonders like Scheme's call-with-current-continuation.

The legions of programmers who have entered the market recently only because they see it as a quick and easy way to make money aren't interested in taking on the more-disciplined, almost mathematical mindset that seems to allow for maximum immersion into functional languages. Rather, they'll do whatever M$ says is the best way to earn the big, easy bux.

And that's why FP languages aren't more mainstream. (Thank goodness that Perl has map! At least I can sneak FP into one corporate semi-approved language.)

Re:The masses can't handle FP

[Alik]

Y'know, I earned my bachelor's in CS a year ago, TA'ed two functional-language-based classes, and wrote extensions to Scheme that made it useful for mobile agent programming, and I still don't know what call/cc is for. When the hell do you actually need something like that?

Re:The masses can't handle FP

[Alik]

I can see the tree stuff; those are interesting examples, though they make my brain hurt to read them (I'm of the opinion that good Scheme is liberally interspersed with comments that help you to know what block you're currently in; after about the third lambda I lose track.)

As far as the list-multiplier goes, though, wouldn't it be just as simple to say

(define (multiply-list l)
(let ((recursor (lambda (lst accum)
(cond ((null? lst) accum)
((= (car lst) 0) 0)
('else (recursor
(cdr lst)
(* (car lst)
accum)))))))
(recursor l 1)))

The syntax may be off, but I believe that's close to the tail-recursive method, which seems to do just what's needed.

It has to do with education

[Nelson]

I'm a functional advocate from CMU also. I totally and completely think that it is the most important thing in programming these days. I don't do it for my job though..

I think it has to do with the demathing of the CS business. The importance of math isn't stressed as much as it used to be, hold for a handful of schools.

You can also put a 7 year old behind a computer and with BASIC or SmallTalk or some other language (Pascal or python, or anything really but the clean syntax ones seem to be more popular with children) and she can make things happen. It's usually fairly primitive but they can make it do things. The math required to appriciate (not understand) functional programming may never be taught to that 7 year old or it may be 12 years before it is taught to them. Any adult can also go pick up a book at the store and start learning how to program but most of these books stay away from functional programming. By the time someone can understand functionalism they've been entrenched into the imparitive world for so long that it's not easy to break free and if you want to work it's cake to find a java or C++ job but the Standard ML and Haskell jobs are a little bit more rare.

Re: Parenth's

[angry old man]

bagh, back in my day, we didn't need any functional programming languages. LISP and SCHEME were for acedamia and procedures were for hard working people.

Everything was procedural and when we wanted to develop an algorithm, we used GOTO's and FOR NEXT's and we liked it. Nowadays, everyone wants to use fancy schmancy functions or bloated Classes and Objects.

Bagh.
Data Structures are for Lazy young Silicon Valley kids that don't know good programming from a VAX prompt!

One word: Marketing

[bartok]

The *main* reason most languages out there don't get much attention is because they are not or badly maketed. If you're a windows programmer and have never had contact with the UNIX world, there is a fairly good chance that the only thing you've heard about functionnal programming is "this thing called Lisp that's good for AI".

From a maketing point of view, if you compare the success of languages like Java and Eiffel (cross platform stuff aside), you can clearly see that hype, buzzwords and nice little logos can go a long way into making a language known and used. I have also noticed that is you manage to throw in the word "revolution" here and there catches many a software engineer's eye.

I'm not saying that no one makes rationnal choices out there but that it's pretty obvious marketting goes a long way..

Re:This is a brilliant post

[sillysally]

the ideas behind that post are brilliant, but it is cookbook econ 101 and applies to many products, technologies and industries. Think about VHS/Beta, internal combustion engines, whatever.

j & k

[miles zarathustra]

I haven't seen anyone mention j or k , both of which are derivitives (more or less) of APL and both of which are highly functional in approach.

and how often nowadays do you see a programming environment that can ship on a floppy disk? The entirety of K was under 200k the last I checked, and it has a smoking database engine. J also is amazingly fast.

check out my mp3 page
check out my mp3 page

Provability, or something?

[Glamatron]

You can't necessarily prove that a program is correct.. For one thing, how do you prove that the proving algorithm is correct? Second, what if there is a potentially infinite loop within the program? If written sufficiently badly, I think that could cause the prover to go into an infinite loop.

Anyway, I could be wrong, but if I am, so is Douglas R. Hofstadter, and he's probably smarter than me. Furthermore, there are probably a vast number of programs for which you are right, so that's something that is really cool about functional languages.

Problems with Static Typing..????

[Tom7]

I'm thinking of vector spaces and abstract algebra, where you have operations in a space. Something like * (times) can have an analog in a number of different spaces (i.e., different types). The implementation of * is dependant on the types involved, but the concept of * is abstract from the types.

You must just have a misconception of what I mean by static typing (have you ever used ML?) because this seems perfectly easy to accomplish with signatures and structures. How does static typing problematic?

Languages with dynamic typing can do really neat things -- creating a string buffer that simulates a file, a sorted collection that has (mostly) the same interface as an unsorted collection, etc.

These techniques are both easily available to the ML programmer.

Re:Employees resist as well

[Blake]

I would totally agree with you, except that my company is trying desperately to hire Java programmers for decidedly non-DB-front-end work.

Obviously, I can't say what we are doing, but I can say that it has nothing to do with the InterWeeb, and I've already finished all the DB-related code.

Later,
Blake.

Re:Functional Programming: its very powerful

[Yunzil]

Functional Programming is the next big thing.

Haven't they been saying that since about 1950? :)

C++ vs ML

[Tom7]

You're right that some of the benefits are available under other programming paradigms, too. I do believe concurrent programming is easier in ML (CML), but I haven't really given it a chance in C++ (seemed too convoluted). You've given some good points, but I think some deserve correction:

I said: It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful.

You said: Actually, it's been done. A notable example is C++.

Definitely not true! C++ is absolutely not type-safe. It is imperative and powerful, though.

The standard workaround (also available in C) is to construct a small, machine dependent include file that defines a set of unambiguous types (i.e. int_16, uint_32).

Yet we continue to see problems porting C/C++ programs to 64-bit machines, as well as (especially!) moving to unicode strings. Both of these would only require changes to the compiler in ML, or most languages with a mature (abstract) type system. (There are other ambiguities in C++ which can be disastrous to the programmer who doesn't know the language 100%, mainly order-of-evaluation issues like you've pointed out)

To protect the guts from tampering: private member variables and private functions.
Yes, you can get around the protection. C++ explicitly gives you enough rope to hang yourself. But you have to express your INTENT to violate the protection by a particular set of casts, or you end up buried in warning messages and NOT trashing the variable.

This is the straightforward reason why C++ is not type safe and why it does not support fully abstract data types. But -- most programmers don't go around maliciously casting abstract datatypes in order to fiddle with their insides (at least, I hope this is true!). Unfortunately, this isn't the only way C++ allows you to break abstraction -- manual memory management and pointer arithmetic means that programmers can accidentally tinker with abstract data types. And this obviously happens in real life, because C++ programs crash. Have you ever worked on a team, where another programmer complained that there was a problem with your module crashing? (but it really wasn't your fault?)

ML gives you a great guarantee: if your abstract data type is malfunctioning, it's because you've done something wrong. It's impossible for the bug to be in the client's code.

Re:Haiku

[Anonymous Coward]

A functional language looks very awkward to think/program in, but once it's done, a software algoritm could prove (proof in mathematical sense) the program to be correct (or wrong :). Afaik there is no reliable way to automate debugging of C code...

Re:Network Functional Programming

[Chalst]

Logic programming languages based on Horn clause resolution (ie. all
of them) are restricted to finding solutions to formulae of very low
logical complexity. Whilst logic programmers have been ingenious in
working within this universe, I think its no accident that researchers
working in applications of computation to logic have overwhelmingly
preferred functional to logic languages, the big exception being
algebraic specification (unsurprising, since algebraic systems have
axioms of low logical complexity). Also functional languages have
some nice correlations with linguistic entities.

I think the `relations are more general than functions' is a red
herring, since it is easy to translate between programs coded in a
pure (ie. the minimal heart) functional and pure logical language.
Logic languages are nice, but in my opinion they are the best tool for
a restricted set of problems, whilst functional languages are useful
over a much wider domain.

A couple of reasons:

[Goonie]

• Functional languages are slower, as a rule, than imperative languages. Compilation, rather than interpretation, helps - but few functional languages can approach the speed of a well-written imperative program. Of course, there are many occasions where speed doesn't really matter, and even if it did it's limited by I/O, rather than CPU, but it's still a factor
• A lot of functional languages still have the element of research tool rather than real language about them - particularly in the area of their libraries and other associated bits. They don't support things like graphics toolkits, CORBA bindings, parser generators, database interfaces, and the like. Similarly, the toolchains are generally less sophisticated - while some very clever debuggers have been written for functional languages, they haven't been turned into real tools in many cases.
• A lot of people just don't get non-imperative languages. I taught Haskell as a first computer language at a university, and people frankly struggle with it - much more than they seem to with imperative languages.

I like functional languages - the project I'm working on uses them extensively, and Scheme is great to work in. It's a shame that they're not more widely used.

And, while we're naming our favourite alternative languages, you could try Mercury, a logic programming language designed for real-world programming. It compiles to C, it's got the best type checking of any language I've ever used, it's fast, and its compiler is good. The fact that it's developed at my former university has nothing to do with it :)

Re:A couple of reasons:

[Goonie]

It supports destructive updates (i.e., analogs of the assignment operator in C or C++) and yet still is purely functional.

Mercury also does destructive updates. You are quite right, they are *very* important for making functional languages run fast in the real world.

Thanks for the pointer.

Re:A couple of reasons:

[Weezul]

Functional languages are slower, as a rule, than imperative languages. Compilation, rather than interpretation, helps - but few functional languages can approach the speed of a well-written imperative program. Imperative langauges have limitations on the optimizing of code. This means that we will eventually see compiled functional langauges which produce faster code then ANY imperative langauge (assuming a time constraint and/or programmer skill constraint). There is just more analysis that can be done to functional code, so the machine can do more of the work for you. The only real problem is that someone needs to put a lot of work into the compiler. They don't support things like graphics toolkits, CORBA bindings, parser generators, database interfaces Total bullshit! Haskell has many/several diffrent packages for ALL of those things. I'd say most serious functional langauges probable have most/all of those things. Actually, imperative langauges are the ones with suck ass parser generators. You have Lex and Yacc style parser generators for Haskell, but Lex and Yacc are total crap compaired to the monadic recurisve descent parsers in Haskell. These parsers have all the power of YACC, but they are just a Haskell library & include, so you can add your own shit. Every want to intermix contex free grammors and regular expressions freely, i.e. not this stupid Lex dose the regex and Yacc dose the CFG bullshit, it's cake under Haskell.. or you could write millions of other short cots to make you CFGs much smaller/simpler. Parsing is one of those things functional langauge were made to do.. and the moderatly good ones kick the shit out of all imperitive langauge at doing it. Also, it's worth pointing out that Functionall langauges have had steller results in "ultra high reliability" programming situations (like phone switching networks), i.e. you can not afford the program to break, so you force yourselve to write it in a manor when it can be "nearly" proven to not be breakable.

Re:A couple of reasons:

[weg]

I know some functional languages that can easily compete with the speed of Java, although they provide garbage collection and bytecode portability. Have a look at SML/NJ: http://cm.bell-labs.com/cm/cs/what/smlnj/index.htm l, it provides a great IO-library, a parser generator tool (similar to yacc and lex, just that the generated code looks MUCH better), a network library (HOL98, a theorem prover that is written is SML provides a socket interface). It provides modules, so it can easily be used for big projects, too. Since functional programming is very similar to the basic mathematics everyone learns in high school, it should be (if taught in an understandable way) easier to learn than imperative languages (no side effects).

Re:A couple of reasons:

[Goonie]

This means that we will eventually see compiled functional langauges which produce faster code then ANY imperative langauge.

Yes, I'm aware of the optimization potential of functional languages, but it's just that - potential. Even the best functional or logic programming language environments aren't there yet. We're talking the now here, rather than the future.

Re:A couple of reasons:

[Skif]

I TA'ed for a first-semester Haskell class at the University of Texas at Austin. Haskell sent those freshmen running for cover. It seemed to be really hard for them to swap out of the imperative mindset. I think it's a GOOD thing that they were forced to do so, however. It's good to be flexible when thinking about a problem. And I still remember being amazed the first time I saw a quicksort implementation in Haskell--in three lines of code.

Re:A couple of reasons:

[HannahS]

Hello!

It was written, that functional languages seem to be significantly slower than e.g. C or other imperative languages.

That might be true. However, in a project here at work, we programmed a network line simulator (connect any number of BSD tun interfaces and/or Ethernet interfaces attached to with bpf, with routing and simulation of delay/loss characteristics).

As a test, we wrote a program in C, connecting two tun interfaces with no loss and no delay, and we configured the Haskell program to do the same. The performance loss was about 30%. And that, while the Haskell program is configurable and thus does things the C program did not do.

Compilation was with GHC, gcc 2.95.2 as backend compiler.

See Libraries and Tools for Haskell as a counterexample for the claim that there are virtually no tools. The only thing still missing is a CORBA binding. But that's not true for all "niche languages", e.g. Mercury, Erlang.

The struggles with non-imperative programming in first-term Haskell/Gofer/... courses is true - for those who have already experienced imperative programming and want to transfer that onto a FP language. Interestingly, people having had no programming experience at all had a less hard time!

Regards,

Hannah.

Re:A couple of reasons:

[Gurlia]

Check out Concurrent Clean. I ran into this functional language during my senior year in university, and I haven't really kept up with it since, but it has several very interesting features that may help to make functional languages more widely accepted. It addresses the first two points you listed as reasons functional languages aren't popular:

• It supports destructive updates (i.e., analogs of the assignment operator in C or C++) and yet still is purely functional. (If you don't see how this can be true, visit Clean's homepage and find out!) What's the big deal about destructive updates? Well, one of the reasons functional languages have been slow is that, in order to preserve mathematical consistency, all data objects must be immutable, and therefore, everytime you perform an operation a new copy of the object must be made. However, Concurrent Clean implements a very clever way of allowing destructive updates in a way that doesn't affect its mathematical correctness. This results in very impressive speedups (I think they claim that many Clean programs are as fast as a C/C++ equivalent, but you've gotta verify that yourself).
• Concurrent Clean has a very nice I/O system that, OT1H, fits perfectly in the functional paradigm, and OTOH, isn't contorted into an odd, un-intuitive paradigm that most functional language I/O systems are. When I did my research on Clean years ago, you could basically implement an entire GUI declaratively, in a format that's very easy to read, and very easy to understand, and yet, still totally "purely" functional. I'm sure a lot more has happened to this GUI library since then. I strongly suggest anyone interested to check it out! :-)

Now, I admit I'm biased (mostly due to having done a lot of research on Clean years ago), but Clean looks like one of the promising candidates for widespread adoption by the industry. Or at least, I'd be so bold as to say that the above two mentioned points are things that I'd probably expect a widely-accepted functional language to have.

---

Bullshit.

[Estanislao Mart�nez]

An appropriately conceived relational calculus is more powerful than a similarly conceived functional calculus because functions are special cases of relations.

Bullshit. None is a special case of the other-- they are equivalent notions, since each is powerful enough to define the other. Taking functions as primitives, a relation becomes nothing but a function from tuples to truth values.

Re:Natural way to program???

[plumby]

is this any clearer than return 1+2+3+4; and return 1*2*3*4?

Re:Functional Programming has a bad rap

[rve]

"ij" is just pronounced as the English 'i'

No need for struggling with seemingly unpronouncable 'widjng' or 'didjkstr' sequences :)

Haiku

[quintessent]

(are(languages(These), nice)
(Easy(to_write(code(bug_free))))
(If(can(read(you, them)))))

Re:Don't spout your ignorance.

[Nicolas MONNET]

I used to, but that was a while ago, and haven't touched it in years.

unctional Languages too job-specific

[John Jorsett]

My guess on why functional languages haven't been as popular as langugages such as C and Java is that they're typically good at doing one particular type of job, but not so hot generally. Consequently you end up with a bunch of different languages to solve different problems and no one language can reach a critical mass of widespread usage.

Why it's "obscure":

[jfwcc]

-
My experience (22 years on the job) showed that languages which are easy to use, are considered "childish" or worthless by the managment.

I wrote a connectivity (system) application using REXX.
Two ES/9000 mainframes and numerous AIX workstations, access to DB2 from both mainframes (which were NOT coupled).
Plus a fool-proof user interface that also worked around bugs in an IBM "user interface".
I saw persons looking at the code, saying "looks like VB"...

I know that a US finance agency runs a complete system using REXX.
I know how much trouble the developer at IBM had,
to get her implemantation of REXX for IBM's AIX machines "official".
(We used a free interpreter REGINA until the managment gave in.)

If something does look easy, it's considered worthless.
What I wrote in 1000 assembler lines in 1979 could be written in 50 lines using REXX.
But those 50 lines don't give you credit.
Write 1000 lines and the managment thinks you're really hip, a real cool cat, a hoopy frood.

Re:Why it's "obscure":

[johnnyb]

I don't know much about REXX, but languages like VB, which are extremely easy to write, lend themselves to REALLY bad coding habits, and actually prevent many good coding habits (like abstraction). What makes something take 20 lines instead of 1000 is usually library support, not necessarily something inherent in the language. The question is not "does it do the job". Any language can be used to do the job. The question is, in 5 years will someone else be able to adapt my code to new and unforseen situations? That is the main problem.

Inadequate IO and slow

[riru]

Haskell and other functional programming languages usually lack IO. Or anyway, it's problematic to use it. Still, they're also a little bit slow. But I think that we will se more of functional languages in the future.

I see you've been 'Harperized' too. :)

[Convergence]

(Professor Harper is one of the creators of Standard ML, and a very neat guy. BTW, if you could feed me some info on the TILT project, I'd love to study the compiler.. TILT is where the Python LISP compiler was about 8 years ago.)

I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago.

The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)

Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)

It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.

Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' For example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops.

For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.

This is much like the first example of aspect-oriented programming. As another example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer?

For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual.

Write-once variables are useful

[Prosaurus]

Whoops - the discussion (much of it) seems to being confusing three FP
related things: seas of parentheses, first-class functions, and
expression-orientation.

Not all functional languages use seas of parantheses - this is a
syntax choice made by the Lisp family of languages. Yep - it's
horrible, but it's not intrinsic to FP.

First-class functions are tricky beasts. Some procedural or OO
langauges have a similar power - for example, function-pointer
variables in C. Do you kow anyone who uses these regularly?

But FP languages are also expression-orientated. I've written a
compiler in Sisal (a pure expression-oriented language, but not FP). I
liked the pure expression-orientation, and it was easy to use.

Essentially, in a pure expression-oriented language, you have
write-once variables. You can only assign a value to a variable once -
and must do it once. This gives you great compile-time checking, and
makes variable-declaration comments even more useful.

Sisal's syntax is a typical procedural language syntax - hardly a
parenthesis in sight, and normal looking variable declarations, if
statements, loops, etc. There is a slight price - you declare more
variables, and loops have an extra construct to distinguish between
this-iteration and last-iteration variables - but this is easy to get
the hang of.

In summary ... The nasty syntax isn't intrinsic to FP, and if you
don't like first-class functions you don't have to use
them. Write-once variables are a great idea from FP, which can be
adapted into procedural programming as a stylistic thing, or
incorporated into procedural-seeming language design.

Functional Languages

[Enonu]

I'm a CS major at ASU, and I'm currently taking CSE 240, Introduction to Programming Languages. There, one is taught Lisp, Prolog, and Ada.

Concerning Lisp, I personally thought the language obscure and very hard to get used to. Recursion everywhere and a minimalistic view towards variables isn't easy to adopt. However, after a couple weeks, I began to appreciate how elegant certain solutions to common programming exercises were. For example, I wrote an expression evaluator which does everything but order of operations in thirteen lines of code. Try doing that in C. I've also heard that Lisp is a very popular language, if not the language to use for AI because of the ability to modify code at runtime. Functional languages definitely have their uses.

"If the only tool you have is a hammer, everything looks like a nail."

Cheers

Bugs + Math

[Tom7]

I guess it depends what you consider a bug (I make these comments merely to clarify my previous post, not to state some moral judgment.)

I consider a bug to be a mistake writing the code I think I'm writing (wrong variable, typo, freeing memory that's in use, etc.). The typechecker is great at catching those.

What you call a difficult bug isn't really a bug in my mind -- you've written a correct program, it just isn't the program you wanted to write. (The algorithm doesn't work, etc.) The typechecker doesn't help that much in this case.

Still, I think there's something about the statically-typed functional style which inspires better programs; I even find fewer "difficult bugs" in my ML programs. (This comment of course comes with lots of the YMMV, IMHO, and IANAL!)

I don't think static typing is very mathematical anyway. Most higher math deals with things in terms of properties, not types.

I don't know where you're getting this from, but it's really not true. If you've ever seen the rules for the static semantics of a language written down and the proofs of safety that accompany them, I don't see how you can not consider this math. The isomorphisms between logic, set theory, and types are well known, as well... care to elaborate?

Re:Bugs + Math

[Ian Bicking]

I don't think static typing is very mathematical anyway. Most higher math deals with things in terms of properties, not types.

I don't know where you're getting this from, but it's really not true. If you've ever seen the rules for the static semantics of a language written down and the proofs of safety that accompany them, I don't see how you can not consider this math. The isomorphisms between logic, set theory, and types are well known, as well... care to elaborate?

I wasn't saying that static typing can't be expressed mathematically, but that mathematical expression is not well done with static typing.

I'm thinking of vector spaces and abstract algebra, where you have operations in a space. Something like * (times) can have an analog in a number of different spaces (i.e., different types). The implementation of * is dependant on the types involved, but the concept of * is abstract from the types.

Of course, some languages make "ab"+"cd" = "abcd", which messes things up. Addition and concatenation aren't really the same thing. But that's just bad language design.

Languages with dynamic typing can do really neat things -- creating a string buffer that simulates a file, a sorted collection that has (mostly) the same interface as an unsorted collection, etc.
--

Whatever happened to Miranda?

[bladel]

Never had a chance to play with Scheme or Haskell, but in college I thought Miranda best fit my way of thinking about code. Anyone know of a modern implementations in Linux I could play around with? J.

Re:Whatever happened to Miranda?

[Tet]

Some english company is maintaining it and will cost you lots of £££ if you want a copy.

That'd be the imaginatively named Research Software Ltd., in Canterbury. That's basically a trading name for David Turner, the guy that created Miranda (and one of my lecturers at University). I guess he's still making at least a token amount of money from Miranda. There's no other reason to keep it closed, particularly given free alternatives like Orwell and Haskell.

Here's a deal

[Salamander]

I'll start writing in a functional language just as soon as it's supported inside any OS kernel that has a large enough user base to be worth developing for. Until then, FP languages are useless to me, though I might of course use concepts and constructs that people associate with FP (even though for the most part those things have been known and accepted as good practice in non-FP contexts for decades).

Re:Formal correctness proofs -- YES!

[plumby]

Does the same proof not work for the C function
unsigned long fib(unsigned long x)
{
if (x==0 || x==1)
{
return 1;
}
else
{
return fib(x-1)+fib(x-2);
}

}

?


I am trying to understand what is meant to be so good about functional programming, but so far everything that I've seen seems to be possible in either procedural or OO languages, if the programmer is careful.

Re:Experiences...

[plumby]

What side effects does
unsigned long fact(unsigned long x)
{
if (x==0 || x==1)
{
return x;
}
else
{
return x*fact(x-1);
}

}

have?

Re:It's a entirely new way to think

[Anonymous Coward]

Your post exposes another problem preventing acceptance of functional languages: When they teach functional languages in college courses, the languages are used to demonstrate recursion, list processing, and in general all the stuff that makes functional languages different. They don't tell you how to make practical programs in a functional system: how you can use vectors, hash tables, etc and not only lists, how to make functional programs run fast in practice... That's just something of no interest to an academic.

Just for the record, functional languages are typed -- some of them, like Scheme and Common Lisp, are just typed at run-time, and some of them, like ML or Haskell, are typed at compile time. Even in a run-time typed language, the fact that every expression does have a type allows a compiler to deduce the types of expressions at compile-time (and in Common Lisp you can help the compiler do a better job by adding type declarations).

An explanation

[Estanislao Mart�nez]

[...] Could someone then explain the difference between Haskell and say... C++/Java?

The difference here is that between functional vs. imperative languages. You need to look at the languages, and think about what the expressions in these languages mean, i.e., the semantics of the language, and what concepts these meanings invoke.

The semantics of imperative languages invoke the concept of state, which we could paraphrase "the way things are at a certain moment". The quintessential imperative construct that occurs in practical languages is the notion of putting a value in a memory location, i.e., assignment statements. What does a statement like "x:=5" mean? "x" represents some memory location, "5" a value, and the statements means that the value in that memory location changes; the state here is the contents of memory, and executing the statement passing from one configuration of memory to a different one. This is the change of state. Thus the final result from doing "x:=x+1" will depend on a factor which is external to the statement, which is the state of the computer when it gets to that statement.

A (purely) functional language, in the other hand, makes no use of the notion of state in its semantics; only of that of function, in the mathematical sense, which is different from the sense you find in a language like C. A function is something that uniquely maps input values to a unique output value. This means that giving a function some input values guarantees that an unique value will be the output. (In C, "functions" aren't; calling a "function" twice with the same parameters may return different values each time). It was proven in the late 30s that for anything you can do with a state machine (Turing machines), you can write a mathematical function that will do the same thing, and viceversa. This is easy to see, since imperative programming can be captured in functional programming by writing functions that explicitly change states. Thus, if s, t are states, you could write a function "assign", which you could use this way: "t=assign(s,x:=5)", which could mean something like "t is the state that differs from s at most in having x equal to 5".

So this is the theoretical difference between the two types of languages, and the reason they can do the exact same things.

As for the procedural/OO distinction, I'm afraid it's not as well defined or deep. OO means that there is some inheritance mechanism which controls which procedure to dispatch in a particular call. As far as I'm concerned, OO languages are procedural (but not viceversa).

Re:An explanation

[drnomad]

OO vs Imparitive vs Functional?

You cannot compare OO in this sequence - Functional and Imparitive are about algorithmns (i.e. how-to-program-certain-behaviour) while OO is about data. You can't compare data with algorithmns, out of the question.

Functional Languages in the work place

[lurkerabove]

Well, I get to use a functional language at work quite often: Prolog. IBM's Tivoli product line includes a product called TEC that can correlate discrete "abnormal" events that have been sent to it. This correllation is done using a Prolog variant (BIM prolog). It's a lot of fun and can really leave me unable to program in a procedural lang. for hours or days after. jcv

Event listeners were hard in procedural langs also

[billstewart]

Remember learning to program for X Windows or other graphics systems back when you were a C programmer? It was a major step - instead of writing code where all the subroutines belonged to you, except library stuff you could call to do things for you and return with the answers, you needed to learn to write code that

• Had functions with arguments in a format that event-meisters could call
  
• Covered all the reasons an event-meister would try to call you
  
• Used C's appalling syntaxes for asking the event-meister to call your routines if something happened instead of writing your own event loop, because your program was no longer in charge of what got called when.

Maybe that's as unnatural to do in a functional language as in a procedural language, but you have to give the functional folks as much slack as you've used. My friends who write Smalltalk swear by the stuff. A friend of mine used to write window-app prototypes in "winterp", an Xlisp windowing package that ran on X Windows, and said that the prototypes generally took much less time to write than the product C code, but also did more.

The real issues are the ability of teachers to teach the stuff, the quality of books to teach or learn from, and the availability of programming environments and tools for not only learning but also production. The latter used to be a hard problem, but now that you can include a CD in a book or put a few tens of MB on a web site, and everybody has access to Windows, it's less difficult, and we return to the previous problem of bootstrapping the learning process. Java pulled it off, but it was in the right place at the right time, with "fast web application development" as the hook when that was needed. Academics aren't always as good at self-promotion as commercial marketing departments.

A misnomer? Not!

[dcs]

Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).

An automatic formal correctness validation program will then verify these against some code that describes _how_ to achieve those results.

For instance, check Spin/Promela, and the very simple Mutual Exclusion examples. Declaring what a Mutual Exclusion algorithm must do is simple, and very different from actually writing a program to do it.

Re:A misnomer? Not!

[Ungrounded Lightning]

Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).

That the formal language you must use to operate the validation program specifies constraints on an algorithm, rather than an algorithm, in no way invalidates my argument.

You might have been on stronger ground had you taken issue with my characterization of writing these constraints as "writing a program". But even there I'd maintain I was correct, because in my opinion the constraints qualify as a "program" for the validator tool.

Validation tools that work from constraints have an input that qualifies as a very "different way to express" the program requirements - one where difficult-to-express-as-algorithms requirements can be concicely and clearly stated, improving the odds for non-overlapping bug sets.

Functional languages are great for certain tasks.

[snowtigger]

Functional languages, just as any other language has its advantages and backsides.

I recently took a class in Lisp/prolog programming. At first view, functional lanuages doesn't offer any remarcable features, but once you get in to it, it very powerful. It may not be the fastest and easiest of languages, but you can do some intelligent stuff with it. Lisp enables you to recognize forms and objects in a remarcable way. Imagine writing a program that recognizes shapes of a photograph. it would take lots of code in C. Lisp does this much more efficiently (less code).

Also functional languages are great for modelising. Mathematica is a a great example. People started thinking of how to make a computer understand mathematics using functional languages and then wrote it in C for it to be fast.

Having said all this good about Lisp/prolog, I still don't know if I will ever use it again, but they remain an interesting alternative to other languages.

"read" defined

[Nicolas MONNET]

Definition of read: to be able to tell the meaning of something written quickly. Ok, that does not necessarily fit perl very well ;)

Functional Weather (Was: they are too hard)

[Florian H.]

"If it is raining, I will not go to the park" is easy to conceptualize and easy to write in a procedural language.

It is at least as easy in Haskell:

data Weather = Rainy | Cloudy | Sunny
dosomething :: Weather -> Maybe String
dosomething Rainy = Nothing
dosomething _ = Just "go to the park"

(How are you supposed to discuss code if you can't even use <pre> in comments?)

Clean

[Hard_Code]

Check out this link I found from Kuro5hin.org to the Clean functional language: http://www.cs.kun.nl/~clean/index.html Intro to Clean language: http://www.cs.kun.nl/~clean/About_Clean/tutorial/t utorial.html I think their 2D platform games section shows that Clean can be used for practical applications, and that functional programming is not just a research toy. They also seem to have some nice IO library. Taken from the intro to Clean, thes functional implementation of common mathematical functions just seem SO elegant: Exponentiation: power :: Int Int -> Int power x 0 = 1 power x n = x * power x (n-1) Factorial: fac :: Int -> Int fac 0 = 1 fac n = n * fac (n-1) Maximum: maximum :: Int Int -> Int maximum n m | n=m = n From a quick scan of it, Clean looks VERY cool.

Re: Parenth's

[Fizgig]

But why make the end-programmer do something that the language itself should take care of (unless there are other reasons for the parens). It's generally accepted that fine-grained optimization should generally be done by the compiler, not the programmer, especially if it leads to something more readable. Why then not allow the parser to deal with parsing and not the human? (especially since you have lex and yacc to help you out)

Even C is a bit harsh. What's with all the semicolons? I guess that made it easier to parse (is there another reason for them?). There is nothing more frustrating from moving from a nice session of Python coding to C and getting compiler errors because I've forgotten a few semicolons!

Music and LISP; Alice's Lisp Machine

[billstewart]

Bob Kanefsky's Songworm Filk record has Eternal Flame, the "God wrote in LISP code" parody of Julia Eklar's God Lives On Terra, sung by Julia.

Also, there's a cached version of Alice's Lisp Machine, which has pointers to open-source figure Richard Stallman and lots of AI-Lab people and in-Jokes.

Gnome and Scheme

[dead_penguin]

In Gnome, Scheme is being used a fair bit. Guile is an embeddable scheme interpreter (written in C) that can be used to add scriptability to many projects, or used as a scheme interpreter in and of itself.

I don't think that The Gimp itself uses Guile, but a version of Scheme is used by it as its scripting language. A simple 'locate *.scm' will turn up loads of interesting stuff at /usr/share/gimp/1.1/scripts .

Why scheme was chosen for these things is a bit beyond me. Sure, it is a very nice language for quickly putting together simpler projects and having them work in a much shorter time than with most other languages, but I think there is a pretty heavy learning barrier you have to overcome first. This is especially true if you've done quite a bit of work in non-functional languages before. As a simple example, "pure" Scheme doesn't allow looping in the for of "while" or "for" loops, but rather you have to do this using recursion. This can be a daunting task at first, but works rather well when you get the hang of it (and you learn to fully appreciate recursion!).

There are many other neat features in Scheme that really can only be vaguely imitated in C/C++ and other languages using some severe pointer hackery, my favourite being that procedures are first-class citizens; i.e. a function can be passed and can return a procedure in the exact same way that it would a variable.

All said and done, I still wouldn't come close to calling Scheme my favourite language to use. It's a Lisp derivative, and we should all know that *really* stands for "Lots of Irritating, Stupid Parentheses", or something along those lines!

The future of functional languages

[drnomad]

In my opinion, functional languages are the future.

I've been developing a functional language myself for the past two years now, and for me the cause is clear. Imparitive languages like C have a problem with order. A language like Occam demonstrates nicely that order doesn't always apply. Same goes for Functional languages, illustrated by Haskell, Amanda, Miranda, Lisp, Kleisly etc.
The key problem with pure functional languages is that they are descriptive. Like Mathematics, you can develop a function ( F->X = aX^2 + bX + c), but mathematics does not tell you that you can actually use it. The same thing applies for pure functional languages, you describe a function, but you can't evaluate a functional with language features, you need an interpreter which you give the command to evaluate a function.

A pure functional language is not practical or is it? Developing a functional language with the ability to perform an action, means that you need a scheme in which you implement such features without contradicting the language itself (i.e. a F.L does not have an assignment operator, this means you cannot store information in any way). Ofcourse you can provide a lot of system-functions, or keywords, or whatever. Doing this you will get a dirty language, and it will never be widely accepted - keywords and system functions are limited perse, and never really are atomic features.

The absolute characteristic propperty of functional languages is the fact that it is suitable for multi-processor environments. You can split any combination of function evaluations into multiple processes, a functional language is therefore only interesting in multi-processor environments. In the present, we still get processors to become faster and faster, while this does not stop, a functional language seems to be obsolete. Another fact making F.L.'s obsolete is that compilers/interpreters rarely take advantage of the multi-processing feature.

For the language I'm developing, I've found solutions to all problems mentioned above. I'm implementing an F.L. in which one can store information while not contradicting the language, doing the multi-processing thing etcetera. Thanks to an O.S. called Linux, I can do a thing like this...

Comp. Languages aren't a religion

[Anonymous Coward]

Functional languages are great for somethings, they suck horribly for others. Same things with procedural languages.

Use the right tool for the right job. Damnit!

why not functional lang?

[pustulate]

Because it's hard to come up with examples that make sense and exercise the language. The strange languages also run up against conceptual problems, since most programmers don't understand the abstractions really well. Note that most of the 'successful' languages are literal, and most programmers are clueless when it comes to OO. A language abstracted even farther from the machine would be, well, too complicated.

For example, why would you use an OODL? I'll bet less than 20 people on /. would be able to explain the benefits of dynamic language features.

The question, though, is moot. PHP is a functional language, and is used extensively, as is FileMaker scripting, SQL, etc. It's a complexity thing.

Re:why not functional lang?

[Y]

For example, why would you use an OODL?

A few points to consider:

1. Using an object-oriented language allows you to create inductive data definitions that you can translate directly into code. With some of the more popular languages like C and perl, you have to hack your own representation for anything moderately complex, and there is much more room for error.

2. Well-designed object-oriented languages carry with them a guarantee of type safety. While this prevents the low-level access to memory that bitbangers are so fond of, it protects the program from crashing by protecting the contents and type of any object in memory from bizarre side-effects. One of the other nice benefits of type safety is given a type soundness theorem for the language, you can prove that your program will always produce an answer of type X. Because of C++'s memory access hooks leftover from C and the "unsafe" mode provided by the specification of C#, neither of these languages can offer any kind of real type soundness. Neither can C, but C has no such pretense: Kernighan and Ritchie explicitly state that "types" in C are just directives for the compiler that indicate how much memory should be allocated for a variable declaration.

3. Dynamic dispatch is a wonderful, wonderful thing. You can avoid writing messy if/switch statements in many cases by dynamically dispatching on the type of an object.
For example, if you had a abstract syntax tree generated by a parser, instead of using a switch statement of series of if/else if/else like this:

switch( node.type )
{
case Expression : ...; break;
case Statement : ... ; break;
case Declaration : ... ; break;
...
}

which can get really ugly when you try to add more types of nodes, use object inheritance and create an abstract node or interface called SyntaxNode that all derived nodes extend or implement (excuse my bias towards Java as my language of choice; I'm sure similar cases could be built with Smalltalk, etc.). Each concrete syntax tree node (ExpressionNode, DeclarationNode, StatementNode) can be treated as a SyntaxNode. This allows code like the following:

[ inside a class that traverses the syntax tree ]

String getInformation( SyntaxNode n )
{
return n.getStringInformation();
}

Now, the class or interface SyntaxNode has a method getStringInformation() that returns a String. Each class that extends or implements SyntaxNode is given this method as well. It's then up to each node to provided the necessary code, but when the traverser goes over each node, it will dispatch to the getStringInformation() provided by the concrete node class. That way, if you want to add a new node, say, WhileNode, it takes minimal effort to integrate this into the existing code base. With switch statements, you have to worry whether you've updated all of the proper control-point locations.

Problems with object oriented languages? The main problem is the overhead associated with creating objects and ensuring type safety. Because of this, object oriented languages are not quite at the point they need to be to code low-level projects like operating systems and drivers. However, for large-scale applications, object-oriented design often provides benefits far outweighing those provided by imperative style programming.

: Mike

warping you brain

[HalloFlippy]

is what functional programming does. and i like it. it's the most fun way to program in existence.

part of the reason we don't use it is that programming is taught as a means to an end (ie, to write programs) which implies C/C++/Java. not that this is necessarily bad -- it's where the $$ is, after all. if academic institutions were more concerned with the mathematics/theories behind computational machines, most likely they'd use functional languages more (it's my understanding that MIT does this). but about all you can use it for, in the real world, is writing emacs extensions. :)

the sad part, though, is that, in small doses, fp's can be quite useful in real-world apps. they certainly are powerful when dealing with complex data structures (imagine doing in 5 lines of Lisp or SML what it'd take 50 lines to do in C). it'd be nice if API's existed for C/C++/Java that could take in-lined fp code and integrate it with the larger program, when such would be useful. and maybe those API's are out there already.

Re:warping you brain

[drewbage1847]

yup, in 4 years at MIT, the only languages taught were Scheme and CLU. You had to learn every other language on your own Fine by me. I've heard rumors that's being changed. Bummer. As for liking Scheme, I didn't like it at 2am trying to figure out the last bits, but the rest of the time it was just fine and particularly useful during AI exercises.

GCC back-end

[dcs]

One problem with GCC back-end is that the intermediate language sucks horribly. It's completely inadequate for expressing parallelism, ordering and dependence issues.

For this reason, all OSS will suck very, very badly on IA64, btw. :-(

Re:GCC back-end

[MikeBabcock]

You meant 'all software based on gcc' not 'all OSS will suck ... on IA64", didn't you?

After all ... do you think corporations writing closed source software for Linux may or may not be using gcc?

(non functional language)

[lscoughlin]

Functional Programing will never reach mainstream acceptence for a number of reasons... But the most important and glaring reason, is because it's the most counter-intuitive style imaginable.

Worse is Better

[jfm3]

Wisdom:

Worse is better.

Commentary:

It has been said that Lisp programmers know the value of everything, but the cost of nothing.

Anyone who doubts the efficacy of Lisp systems needs look no further than GNU Emacs for true insight.

getting functional languages accepted

[smell_the_glove]

The only way to get functional languages accepted is by a grassroots effort similar to those that have resulted in the popularity of perl and python. There is NO WAY that a commercial programming shop is going to go with obscure languages, much less obscure languages that go against the dominant programming paradigms, for good practical reasons that have been summarized elsewhere in this thread. So don't waste your time! Instead, look at tasks where functional or functional-friendly languages can serve useful purposes.

In my opinion, working with "pure" functional languages like Haskell which do not allow any form of imperative updating (and yes, I know about monads) is too difficult for most programmers at this point in time. Therefore, I advocate languages like Objective CAML and guile scheme which support imperative programming as well as functional programming. These languages have different niches:

-- Objective CAML is an extremely fast dialect of ML with full static type checking and an object system (and, AFAIK, the only statically-typed functional language that has any object system at all). Timing tests have shown that ocaml can compile to within 25% of hand-optimized C code for many computationally-intensive tasks. Thus, many tasks that would normally be done in C++ can be done in ocaml.

-- guile scheme is a dialect of scheme which is targeted at the python niche: a scripting/extension language. There is no good reason why scheme can't be a superb extension language.

Unfortunately, as of this moment it's not possible AFAIK to build an application using ocaml on the bottom and guile as an extension language, but hopefully this will happen in time. Regardless, the point is to use these languages for your own pet programming projects, get the source out there, spread the word, and let functional programming grow organically, instead of trying to force it down people's throats.

Mike

XSLT is a strictly functional language.

[dwalsh]

...which means people are going to be getting their heads around functional programming soon, whether they like it or not :-)

Also, according to FOLDOC, http://wombat.doc.ic.ac.uk/foldoc/,
LISP and SCHEME aren't strictly functional - they're declaritive languages with a functional subset, by that I mean you can write functional programs if you don't use certain features.

SQL is declarative, but it is not functional.

odd and even numbers

[codemonkey_uk]

I know this is slightly off-topic, but in a forum read by many inexperianced programmers (as well as experianced) it might be a good idea to point out that if ((x % 2) == 0) is a slow way of checking for an odd/even condition, as it does a multiply and checks the remainder. While there may be some obscure platform where the following doesn't work (could anyone name one?) if is much faster to use a binary AND, thus: if ((x&1) == 0) to check for an odd / even condition.

PS - I agree with the post on typesafty. :)

Thad

FP Not Usefull For What I Do.

[TobascoKid]

I used Haskell (and a subset called Gopher) for 3 years while at uni. In all that time I wondered if it would ever be at all usefull in the "real world". I have been in the "real world" for 5 years now, and only once had I wished I could use haskell. For the most part nowadays I write small database apps with 1 - 5 clients, and my language of choice is VB. I'd dread to think what it would be like to use Haskell for the things I use VB for.

Anyway, I think the reason why FP hasn't taken off is that it is the right tool for a only certain subset of jobs - just like each and every other language. It's great for maths, list processing, hardware simulation, and interpreters, I've even seen a defender game written in it. However, I think it's a bit too "matematical" for a lot of programming tasks and for a lot of programmers as well. I think most people I've ever worked with would shudder if I starting talking about lamda calculus - the branch of maths FP is based on. Saying that, most of them would shudder if I mention relational calculus and they use relational databases quite effectively, though the field of FP seems to be more imbued with maths than the field of RDBs.

Maybe that's what FP needs - to loose it's "academics only - this is hard" feel that it has. A good professional quality IDE, easy to read documentation that doesn't feel like a doctoral thesis and painless integration with existing systems might just bring FP greater mindshare. I admit it's been five years since I last used haskell so maybe it has some of these things already, but from the posts I've read so far I doubt it.

Re:Dev time would take a hit.

[dvdeug]

I'm not arguing that language/tools don't make a difference. I program in Ada because it's better than C++, and I don't have to spend as much time chasing down random bugs. But also as an Ada programmer, I see that better doesn't nesecarily equal more popular.

What the original poster was promising was a programming language that was so much better than anything else both OS's and applications that everyone would jump aboard and start programming in it and produce an OS better than anything else because it was in that programming language. A utopial fantasy. There will be better languages; there will be better OS's. There won't be one OS or programming language for everything, and no new OS or programming language will get everyone to switch over to it. (One of my professors still uses Fortran 77 for everything.) It's was a utopial fantasy based around a silver bullet language.

how dare you

[streetlawyer]

The thing that the academics have grasped that the mareting suits haven't is that sometimes less is more.

For crying out loud, "marketing suits" already? Listen to yourself. You are so unable to believe that "hackers" are human beings to, susceptible to prejudices, fashions and mistakes, that you have decided to blame "suits" for the unpopularity of a class of computer languages that have never, ever, had a maretking campaign written for them. What the hell purpose does "marketing suits" serve in your argument? Ye faith.

Re:how dare you

[hey!]

For crying out loud, "marketing suits" already? Listen to yourself. You are so unable to believe that "hackers" are human beings to, susceptible
to prejudices, fashions and mistakes, that you have decided to blame "suits" for the unpopularity of a class of computer languages that have never, ever, had a maretking campaign written for them. What the hell purpose does "marketing suits" serve in your argument? Ye faith.

I very much appreciate your sensitivity to the cheap shot; it speaks well of you. I too often stick up for lawyers, marketers and other unpopular types. However, I was actually trying to make a point.

I never said that the failure of functional languages had anything to do with the suits; in fact my point is the reason that functional languages are not popular have everything to do with their general purpose usefulness.

The reason I mentioned the marketing suits is that they are one end of a spectrum of fussiness about the precise meanings of words; academics are on the other end. The purpose of bringing them into the argument is to hilight what gives an idea legs in the academic world by comparing it to its opposite. Both extremes miss the point. Academics get so enamored of precise definition that they loose sight of utility. Marketing types treat words as tools for making impressions -- they treat literal meaning as so unimportant that it is impossible to talk meaningfully about "relational databases" or "object oriented programming" on their terms.

Hackers are neither here nor there. They often have a good grasp of the precise criteria for what makes something, say, object oriented, but understand that the criteria are more important than the label, and exist with other criteria. Oh, hackers certainly DO have predjudices and blind spots. By in large most hackers have terrible visual aesthetics and very poor idea of usability. But they DO have a very good grasp of computer languages -- that's right up there in the area of their greatest strengths.

Re:what are you talking about?

[Weezul]

The first reply to your post was perfectly correct about the theoretical limitations of imperitive langauges (including assembly), but I was actually talking about a more practical limitation.. time. I will explain: First, assume you have a non-trivial constraint on programmer skill, preexisting libraries, and time. Now, our programmer can probable write a faster program in C then assembly since he can take advantage of things which make writing the program faster and can spend more time profiling, adding complex features which boost speed (say by using function pointers), etc. Yes, he *could* do all these things in assembly, but he would need MUCH more time and/or skill. Functional langauges provide another layer of abstraction, so there is more work for the machine to do.. and the programmer can spend more time worring about the details which are really importent to makign things faster. Example: It's easy for a Haskell or ML complier to make functions which write functions, i.e. safe complier level structured self modifing code. I'd really love to you do that in assembly. Shure your self modifing code tricks might be faster, but the functional langauge compiler's self modifing code tricks are not going to fuck up, so Joe average programmer can use them. Implementing these tricks in assembly is something only mr. assembly god can do.. and only after a great deal of time and testing.

Because the functional languages aren't so popular

[Antonio M.]

Every functional language makes an extensive use of recursion.
Think to Lisp or Prolog...both rely on recursion.
In particular the Prolog interpreter implementation make use of recursion.
And the recursion is the worst enemy of efficiency in the actual computer architectures.
That's why you see Prolog and lisp used only in really particular application and instead you see languages as c++ used everywhere.
Good bye,
Antonio

Who cares about the mainstream?

[density]

Forget about it. Although I'm not really an Ayn Rand fan, she is right about this one: "the mainstream isn't a stream at all, but a stagnant swamp."

So unless you simply want to convert heathens or ignorant mortals, just keep your good secrets to yourself. They don't care about them in the mainstream where it's just fashion and fad. The mainstream wants resume bullet points. Technology specifics don't matter.

Arizona State Rocks!!!

[GringoGoiano]

'nough said.

Make C and Java functional

[sillysally]

C and Java need to be made functional.

I learned LISP early in my programming life but I don't think it "tainted" me. I've been a C (and C++ and Java and Perl (and awk and sh)) programmer for years too. I've always thought it would be useful to add "functionality" to C in the following way: every statement should be an expression and return a value. Why? Well, really the question is why not? It's incredibly useful to be able to use all of the richness of all the semantics all the time.

Furthermore, if every statement returns a value, you can start passing pointers to snippets of code (like in Perl). The C language semantically allows it anyway, but by forcing everything to be bundled into the function declaration syntax it becomes unnatural and non-orthogonal, not to mention awkward so you avoid it in many cases that would be useful.

You don't have to love LISP to learn and apply a few of the very smart things it (and especially Scheme) does.

Re:Make C and Java functional

[sillysally]

dude, you're joking, right? Please tell me you're joking...

Re:Make C and Java functional

[Kris Warkentin]

Python has lambda functions.....it also allows you to treat functions just like normal variables, assigning them, returning them from other functions, etc. Pretty nifty if you're into that sort of thing....

Just give me prefabs and cement. and I'm happy.

[TheLink]

Functional languages are probably great and all that, but unfortunately due to history 90% of the stuff we have to interact with don't do things that way.

Sure, Material X could be theoretically the best way of building stuff. But if day after day our bosses ask us to stick planks, wooden beams and bricks together, the wonders of Material X are just academic.

Most of what I do is basically glueing things together. I'm not a hot shot programmer. Glueing OTHER people's stuff together in useful ways may not seem like much, but hey isn't that one form of modular programming and code reuse? I'm not too snobbish to admit that someone else codes better (or more ;) ), I just use their programs/modules (with their permission of course).

If my boss asks me to build something, since I'm not a hotshot programmer, I'm not going to build everything myself Material-X by Material-X. I'm just going to get a whole load of prefab stuff and then build it in a few weeks (hopefully ;) ).

So if Material X isn't good at glueing stuff together then no thank you. If Material X doesn't work well with lots of great prefabricated stuff then forget it. If prefab made from Material X doesn't work with other prefab stuff then it's useless.

If any of you wonder why Perl is popular, well it's because it's like cement/concrete. So it looks messy and icky, but it's great for sticking stuff together. If you're wise you can easily stick stuff together _securely_. And you can build whole stuff from it if you have to. May look ugly, but once it sets it'll work fine.

And the number of Artisan programmers out there are few. Whilst the number of bricklayer programmers out there are many.

I'll now leave you Artisans to debate whether Material-X or Material-Y is the best for your masterpieces.

Cheerio,
Link.

WHAT!!!

[Christopher B. Brown]

SQL may be nonprocedural; it is not particularly functional, as:

• It does not make functions first class objects;
• It does not eschew side-effects.

SQL is not even strongly relational; see Darwen and Date's Foundation for Object/Relational Databases: The Third Manifesto.

And see any of Joe Celko's books on SQL to see how weakly people tend to use what relational properties SQL has.

But as for calling SQL a "functional" language, while there may be some abtruse arguments by which some variation on it could be argued to be somewhat functional, it is certainly not recognized as such in the way that Haskell or ML are...

Re:Functional Programming has a bad rap

[Scott_Marks]

Uh, yeah, sorry that wasn't clear. I'm one of the few people I know to program in both Algol 60 and Algol 68, the latter being my favorite procedural language. Not to mention the tastefully erudite von Wijngaarden two-level grammer used in the Algol 68 spec!

That's two different computer gods with that "ij" thing in their names. Hmmm...

Use a programmer's editor

[josu]

The worthwhile ones (in my opinion) auto-indent and balance parens. There's little trouble keeping track of where you are.

You are in a fashion industry

[Paul Johnson]

I've spent the last several years trying to explain to colleagues why they should start using another obscure-but-good language, Eiffel, to no avail. Here is what I have learned. Note that this is not about the pros and cons of particular languages or paradigms, its about the way the programming language industry actually works.

The language industry is dominated by network effects. There are major costs with using a minority language, and for an individual project these completely outweigh the benefits, even when the benefits are very large. Hence it is generally far better to stay with a majority language. The costs of a minority language include:

• Support. Sure, you can get a GPL compiler for most languages, but on a project you don't want to have your coders digging into the code trying to fix a bug, you want them writing code. Support is something you outsource.
• Performance. Every minority language claims to be faster than C, but often isn't in practice. Whatever the truth, C and C++ are at least known quantities. Maybe the minority language will be faster, maybe slower. If its faster, well gee so what. If its slower then you have a major problem.
• Tool support. These days even small projects start by drawing UML diagrams and then converting these automatically into class templates. CASE tool vendors don't support minority languages. Ditto for testing and documentation tools. Little things like tying your compiler to your configuration control manager might potentially be major headaches. Again, its more risk that the PM can do without.
• Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major issue. Every language is going to bring some headaches, but if you have chosen a minority language then these headaches can be turned into an excuse for project failure, and hence for hanging you out to dry.
• Trained staff in a minority language are going to be rare. This does not necessarily make them more expensive (nobody else wants them), but it does make recruitment much harder and more uncertain. Alternatively you have to train all your existing people in the new language. And for Functional Languages its not just another syntax, its a whole new way of thinking. The industry went through this with OO languages, and many PMs have vivid memories of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been sent on a one week C++ course. Getting your head around a new paradigm can take months, and this is time that the project just does not have.

So, overall the PMs want to go with popular languages, not for PHM reasons, but for entirely rational local reasons. But rational local decisions turn into globally arbitrary decisions, as the entire herd gallops off in a random direction chosen only because most of the herd thought that most of the herd were headed that way.

The lesson of this is that if you want to introduce a language, you don't concentrate on making it a good language, you try to persuade the herd of programmers, PMs and tool vendors that your language is the Next Big Thing. The important point here is not how much the language will do for productivity, quality and cost, it is to create the perception that everyone else thinks that this language will be the next big thing.

There are two ways to do this. One way is to tackle the whole industry at once. For an object lesson in how to do this, see Java. For an object lesson in how not to do it, see Eiffel. Believe me, I know all about this. I have spent a long time giving presentations extolling the technical virtues of Eiffel, only to have my audience say "y Yes, but in the Real World....". In the Real World what counts is the network effects. And you know what? My audiences were right. It has taken me a long time to realise this.

The other more interesting and more promising way to introduce a new language is to identify a niche market and attack that. Once you have taken over your niche you can expand to nearby niches and start to build momentum. Python is doing exactly this in web serving, for example. Web serving is a good niche because lots of people do it, and productivity and quality generally count for more than raw performance. Projects also tend to be small, so experiments are not the Career Limiting Moves they are for large projects. Education can also be a useful niche if you can afford to take the long view, which is how Pascal, Basic and Unix got started.

Paul.

Re:You are in a fashion industry

[SlydeRule]

Excellent points. As an Eiffel "true believer", I would add one more: Nobody really cares about quality.

Programmers want "cool syntax" and "expressive freedom"; programming languages are for hacking with, not for the considered, careful implementation of software.

Corporations and organizations want quick and cheap results. As an all too typical example, the company I work for is on a CMM program to improve our software quality. The definition of "software quality" for our CMM program is that the software is "delivered on time and in budget". As Dilbert's PHB says, "Oh, and we need a banner which says 'Quality'."

Eiffel Sucks

[weisserw]

Eiffel is just not expressive enough to be used as a real language. One looping construct? Bleh. It may seem like nitpicking, but having ugly code (with bad CAPS USAGE and END statements), and very rigid syntax are valid reasons to avoid a language. Hell, I'll be the first one to admit that Lisp has frustrating syntax for a beginner, but Lisp also has features which most other languages cannot duplicate. Eiffel is just another imperative language clone, reminicient of C, C++, Object-Pascal, Java, Smalltalk, Ada, Algol, FORTH, etc. etc. etc. Whoopie.

Eiffel devotees have always scratched their head at C++ programmers, who were for a long time working with an "inferior" language (before C++ had templates, exceptions, etc.), but what they failed to realize was that people could develop programs QUICKLY in C++, whereas writing Eiffel code is like repeatedly banging your head against a wall.

-W.W.

Doesn't need to be slow

[josu]

Interpreted scheme/ML/etc is slow, but that's true of any interpreted language. There are compilers available.

Miranda + SPL

[idries]

I used Miranda alot during my first year of College (the department moved the courses to Haskell 2 years after I was done, so I guess they are pretty similar). It was very good for certain things. We built a symbolic integration program in like 6 lines and 10 minutes!!!!

I also took a course in Paralell Computer architecture in my last year, and we looked at a language called SPL (Symetric Processor Language). Which was like Miranda, but would allow you to declare what parts of each function had to happen "together" (ie. because the IO to transfer from one proc to another was too expensive), and what order the various parts had to happen in (ie. B = 2 x A, so we need A before we can use B etc.) Has anyone else heard of this? We only used it in "theory", so I don't know if there are any *actual* implementations of this (ok, so my 3rd year course sucked....).

Anyway, I do actually have a point here too. Functional languages are great for writing certain types of logic in, and there *may* be some great way to use them w/ multi-processor architectures. But we're never going to write desktop apps or games with them, because they are no good for graphics. Apart from the speed problems (which some of the FP advocates here say are implementation specific), it's simply not a suitable syntax for creating graphic applications, or game engines, as one of the basic concepts in such a system is WHEN things happen. For this reason, I do not think that Funcation Languages's will ever "take over", from C/Java etc. as this is a major part of computing today. If I were to write any (non-HTML outputting) program which I thought had logic which could be well expressed in an Functional Language, and had a GUI, then I would write the Functional stuff in a language which let me build a nice DLL/SO out of it, and then build the GUI seperatly. Of course, I wouldn't have enough time to do this because I work in the real world, and not in a Uni, so I'll just build the GUI, and hack the functional stuff into it....

Having said that, wouldn't it be cool if you could put somthing Miranda-like into a Database? (and have it run fast). I think that this would be an Functional Language "killer app" :^ espically if it was then decomposed by the RDBMS to use multiple processors (as in my Symetric Processor Language example). My DBA told me that making an Oracle Stored Procedure use Multiprocessors for logic (rather than for Queries) was near-impossible (I didn't look into it myself). Does anyone know if anything like this exists? I think that this is somewhere where Haskell/Miranda etc. would actually be v. useful, espically as SQL is so functional anyway (hey, I would use it).

One last thing, there is talk here of Prolog. Isn't prolog a Declaritive language rather than a Functional one? (no scarcasm). I don't really remember the difference, but there are so many Language Theory buffs posting to this thread, it's worth asking....

C is a functional language...

[Sangui5]

it just isn't a pure functional language. That is, you can write C code that conforms to the definition of a functional language, but you can, if you want to, cheat.

That, and some of the language semantics that make the other functional languages elegant are missing from C. The code ends up seeming kludgy if you do it the pure-functional way.

There's an international functional programming competition (ICFP Functional Programming Contest). Usually there are many C/C++/Java submissions, and even some in Perl/Python/Pascal. Last year I believe somebody even submitted assembler (it was a semi-hoax, as they had actually written C and then assembled it, but they were going for the joke catagory anyway). Two years ago the winning program was written in Cilk, which is a parallelized varient of C. Last year the winner was written in Objective Camel, and the runner-up in Haskel (which is a paralell pure-functional language (I think)).

Speed of functional languages

[Stephan Schulz]

In fact, LISP compilers have come a long way. For many tasks, compiled LISP or Scheme is as fast or faster than C or Fortran. We are currently reimplemting a high-performance prover in Scheme, and we have noted a 30 % speed increase compared to the old C version (which became a nightmare to maintain). Functional programs are not slow.

I recently read an interesting paper doing a comparison between LISP, Java and C++. That paper came to the conclusion that a good LISP implementation will usually be only very slightly slower than a good C++ implementation. However, an average LISP implementation usually is faster than an average C++ implementation. As for Java, forget about it ;-)

what are you talking about?

[SEAL]

Imperative langauges have limitations on the optimizing of code. This means that we will eventually see compiled functional langauges which produce faster code then ANY imperative langauge

Mind clarifying that? What limitations apply to all imperative languages, that don't apply to functional languages? Or maybe you were thinking of a specific imperative language? As long as I'm able to drop to assembly language, I guarantee I can write code the outperforms any functional language.

Or to put it another way: hardware doesn't know about functional programming. It has registers, and various commands for moving and comparing things. Functional programming is an extra layer of abstraction.

SEAL

Re:Formal correctness proofs -- YES!

[Abigail]

While that is a proof that the algorithm is correct, it is _not_ a proof that your program is a correct implementation of the algorithm.

And in fact, it's trivial to show that the program isn't correct. fib (-1) will never return an answer.

-- Abigail

Re:Experiences...

[istartedi]

But mostly I think it's fair to say that the masses can't cope with the idea of a function being a return-type in its own right (which is probably the defining feature of a pure functional language);

OK, I've been reading all these comments about "functional" vs. other types of languages trying to figure out what people mean. Now C can send back a function pointer as a return type just fine, yet the consensus here is that C is not a functional language. What am I missing?

Re:Procedural vs. Functional

[Roelof]

I'm not sure it has already been mentioned in this still growing thread. But what got me interested in functional languages was the 1985 Byte August issue.

Back then, and maybe still , Byte had a tradition of devoting its August issue to a language. So after Smalltalk, Logo, etc. the 85 issue was about functional programming.

Scheme was featured in that issue.

Natural way to program???

[ArrayMac]

> Structured/imperative programming is a much more natural way to program - at first

When I show my young cousin some APL:
+/ 1 2 3 4
10
and she immediately gets why
x/ 1 2 3 4
24
I would beg to differ from thinking that a for loop would be more natural.

In fact, someone going from APL to other languages thinks "how can they get anything done?" while someone going to APL from other languages thinks "I can't figure out what they're doing?"

Re:Natural way to program???

[ArrayMac]

It's certainly clearer when the function is not a primitive:

foo / 1 2 3 4
instead of:
1 foo 2 foo 3 foo 4

Why have an order(N) expression when you could have an order(1) ??

Re:Natural way to program???

[plumby]

Can you give any examples?

If what you are wanting to achieve is a function that acts on a variable number of elements then you can (in Java) do foo({a,b,c})

If you are talking about something like a checkAllValid which would take a variable number of fields, then (again in Java) you could do

checkAllValid(Field[] fields)

Or have I missed the point?

I'm not trying to be negative about functional progamming, I've just as yet never seen any concrete evidence that it has any fundamental advantages over non-functional languages.

Dev time would take a hit.

[Cliffton Watermore]

Assembler has become somewhat of a black art, even amoung hackers and Real Programmers (tm). As a scientest I can't deny the need for FORTRAN like functionality (Numerical Basing), or C-like flexibility. But what I will say is this: I see languages out there that I'd much rather use if they were slightly different. Python is a key example. Unfortunately it's way to slow for my needs at present, but I've had a vision.

In the future, a new language will emerge that will combine the power of C with the syntax of Python. It will be called "Sheep". Sheep will be a portable assembler attempt in line with what C is trying to acheive, but much cleaner and more readable.

C fans won't like it, but reasonable people will see the advantages of using Sheep to reimplement a lot of their software. System level software especially will benefit from be reimplemented in Sheep due to the far shorter development times it will produce.

C will seem like quite a laughable language in comparison. Microsoft will jump on the bandwagon and release Visual Sheep, but they won't move their existing codebase over from VC++ because of the sheer bloat of it. gcc will be coming out with a sheep compiler, gsp, (or something similar), in a few months. Java will be totally replaced as well, because if you think about, who needs an interpreted (bytecode interpreted then, whatever) WORA language, when there's a compiled language that does away with the #ifdef's of C, yet is faster than C and cleaner than both C and Java?

A lot of C fundamentalists (some Open Source gurus amoung them) will protest and insist on keeping C as the official language. A new open source Operating system, a system written mostly in Sheep, including most of the kernel, will replace Linux and FreeBSD because of their lack of support (and by support I mean, rewriting all of their software in Sheep, including the kernels).

This new system will mostly be a clone of BeOS, but because of the better language, it will surpass BeOS is every way - and truly bring Open Source to the masses. It will combine the best elements of BeOS with the best elements of FreeBSD and Linux. A system that, while having a very smart GUI, will not be dependent on that GUI for normal operation, and will also be totally multiuser. C compatibility libraries, written in Sheep, will exist to make the transfer easier, but once reasonable developers start writing in Sheep, they will be sickened by the thought of going back to C.

Hope you've enjoyed this look into the future :-)

Re:Dev time would take a hit.

[pnkfelix]

What he was saying in his essay was that there was no single technology that would lead to an order of magnitude improvement in programmer productivity. He sure as hell wasn't saying that better languages couldn't improve productivity. A language that doubled productivity wouldn't be a "silver bullet", by his definition. But so what? Doubling productivity is still an enormous improvement.

In base 2, doubling productivity is an order of magnitude.

I agree that doubling productivity is an enormous improvement. So enormous that I don't think that any single language is actually going to bring it about. Your "sheep" is a fictional beast, and while I'd like to believe that it could emerge in time, I'm not putting money on it ever happening.

In Lisp, the editor worries about syntax.

[Estanislao Mart�nez]

Talk with any serious Lisp programmer about parens, and you'll see that, thanks to the paren-matching, auto-indenting text editors they use, they don't even *look* at the parentheses.

The way Lisp programmers see the structure of code is by the indentation. There is only one indentation style that all Lisp programmers use, and a Lisp editing mode will enforce this style automatically. If you open one parenthesis too few or too many, you'll realize once you hit return, since the next line will probably not be indented right. A keystroke command will close all the open parens when you're done with a definition.

Re:Formal correctness proofs -- YES!

[Black Parrot]

> I am trying to understand what is meant to be so good about functional programming, but so far everything that I've seen seems to be possible in either procedural or OO languages, if the programmer is careful.

Probably every language you have ever seen is "Turing equivalent" (modulo the finite amount of memory you have to work with). It only takes a handful of properties to satisfy T Equivalence, though unfortunately I never learned them well enough to recite them for you. I think the list only had 4-5 elements (things like "arithmetic", "iteration", "recursion", etc.), and I think the list was slightly different for procedural vs. functional languages. But essentially all non-toy languages are equally powerful. (After all, they all compile down to machine code!)

--

ex-Miranda hacker says ...

[jcupitt65]

I did my PhD thesis with David Turner (designer of Miranda, which was the main starting point for Haskell). I wrote a baby operating system in Miranda. It was quite cool (I think): it had an editor, a shell, a "date" command, a file system, job control, you could have several people "logged" on at once and ... the kernel had a formal semantics, so you could prove simple properties of sets of prorams running on it. I think (1989) I held the world record for the largest hand-made Miranda program :-) 14k lines as I recall. It did have some speed issues.

Anyway: my current spare-time project is an image processing package, and I've done a little lazy, pure, O-O functional language as the scripting tool (it's GPL ... http://www.vips.ecs.soton.ac.uk, if you're interested).

I think this is an area where functional languages work really well:

- concise: duh, this is what you want in a scripting language

- speed: not at all important for an image processing scripting tool, since the primitive operations you are combining are so amazingly expensive

- formal: if you're trying to write a little script to implement a particular operation, it's great if you can prove that you have actually implemented what you thought you had :-)

- simple and easy to learn: the manual for the scripting language does the complete syntax and semantics (assumes no programming background, in a tutorial style, with many examples) in 10 pages

Conclusion: functional languages are great in niches, not so great for Big Jobs.

John

Re:This answers are obvious...

[kevina]

> Lots of Irritating Silly Parentheses and ...

Although some functional programming languages use a lot of parentheses, this is not true for all of them. Haskell for example hardly uses any parentheses and has about the cleanest syntax of any language I have seen.

While you may associate functional programming languages with recursive thinking, please do not associate them with Lots of Irritating Silly Parentheses as this is just plain false.

Nooooooo ....

[forrest]

Not "indentation as syntax" everywhere! That's scary.
Unless you do it right and outlaw tabs completely. That'd be okay.

Don't show your ignorance on NatLang.

[Estanislao Mart�nez]

human languages are above all context-sensitive

Human languages are not known to be context sensitive, free, or recursively enumerable.

Re:LISP without so many parentheses

[Lozzer]

Well I'm part of a team writing a web portal (how passé), how hard will I have to think to solve it in three lines of functional programming (or alternatively how long would those lines have to be)

Functional Programming Intros

[nickm]

I'd love to read a functional language intro, especially one that wasn't as brain heavy as SICP.

In that case, I highly recommend "The Little Schemer", by MIT press! It is presented as a simple list of questions and answers designed to get you thinking in scheme, rather than merely programming in scheme. TLS teaches recursive thought. It's a very good book, even just as toilet-reading. You can go at your own pace, since each question builds on the previous one.
--
I noticed

Re:AI

[josu]

That depends on what you're used to -- it's possible to write bad code in any language.

Don't spout your ignorance.

[Estanislao Mart�nez]

Human languages ARE *very* contextual. The real reason for Lisp being context free is because it is simpler to write a parser for it, and consequently, easier to make it bug free. Saying that a maze of parenthesis is easy to read is at best, hmmm, a fallacy.

You don't seem to know anything about natural languages, formal language theory, or Lisp. The fact that natural languages are interpreted contextually (a semantic/pragmatic concept) has nothing to do with context-freeness (syntactic concept). Lisp's syntax is not the way it is solely because it simplifies creating a parser. The "maze of parentheses" never bothers Lisp programmers because they have tools to make it invisible.

Shut up.

Re:Don't spout your ignorance.

[Peter Putzer]

But the parentheses still suck.

(And yep, I have written programs in LISP)

Re: Parenth's

[dead_penguin]

While I agree that Scheme's parentheses at times can look just plain mental, I really don't think C does it all that much differently. If in your C style you were to add a { } around every statement, and then instead of putting each closing } of a block on its own line and just closed up using }}}}}, you'd be one step closer.

Scheme does introduce new parentheses, though, in how you call a function. Every function call (form) is done by calling the function similar to a mathematical one, but instead of calling f(arg1, arg2, arg3, ...) where f is your function, you call (f arg1 arg2 arg3 ...). The function name is inside the parentheses, and the args are separated by whitespace, and can themselves be further parenthesized forms. When you end up with a form inside a form inside a ..., you usually end up closing that outside form up with a giant string of ))))))))))). (And having as many as I just put there is far from being an exaggeration!).

Of course, if your editor supports auto-indentation and matching of parentheses, you should be ok, regardless of what language you're using. If not, well you may as well go back to writing qbasic in dos-edit! ;)

Re:Experiences...

[Per Bothner]

Now C can send back a function pointer as a return type just fine, yet the consensus here is that C is not a functional language.
<P>
C does have function values. However, functions
cannot be nested in C. If functions can be defined inside other functions <EM>and</EM> the inner function can access the variables of the outer function (using standard lexical scoping <em>and</em> those variable bindings imported from the outer functions are still valid even after the outer function has returned <em>then</em> you can encapsulate state with the function. This allows a lot of cool things - for example you can emulate objects using functions.
<p>
(I'm the author of <a href="http://www.gnu.org/software/kawa/">Kawa</a> the Scheme-on-JVM system that many people like for scripting Java.)

Re:THEY AREN'T USEFUL

[josu]

So find a compiler.

Re: Parenth's

[B'Trey]

Understood. However, I don't think that the ease of writing the parser should be a consideration when designing the syntax of a language.

Experiences...

[PigleT]

There is already an established Software Industry built on the principle of going with the majority. This means C-based "because everyone knows it" and mainstream Unix-based "because it's always worked so far".

The trouble with this is, in the big industrial scene, the quality of the code produced is abhorable. It is C, batch-produced, written to some Quality Idiot's idea of a "style guide" to be enforced in totally inappropriate ways. Such things as always checking for a symbolic name as the error return value from a function just go straight out the window, "oh no it's -1 if the host's not found, isn't it?".
What's even more worrying is that code is not built up with a view to reusability or expansion - things start out small and evolve features until you realise "we should've just used a database for this whole component", but instead of this you get "New! v3! with added triggers!", d'oh.)

I've gone from BASIC through C, C++, Perl and a limited amount of Tcl / Java, into Scheme and other Lisps. I don't find the fact that Lisp as a concept/family is >40 years old a block to it being *good*. It says in the preface to Graham's "ANSI Lisp" book that functional languages can embrace OO languages with minimal addition, and it's right.

But mostly I think it's fair to say that the masses can't cope with the idea of a function being a return-type in its own right (which is probably the defining feature of a pure functional language); they're too used to the "do this, then do that" chronological programmatic way of doing things, rather than saying "make this a list of things, map this function over the list, then this one..." and so on.

I'm learning Scheme. There are some very funky Scheme environments around - Guile, Kawa and Elk all bear lots of inspection; it's definitely coming to something when you can type 'java pig1' and it executes this:

(define (factorial x)
(if (= 0 x)
1
(* x (factorial (- x 1)))))

(map factorial '(1 2 3 4 5))

Unfortunately, the corporate scene doesn't seem to wish to spend the time on this. That's its sad lookout. I'm off to have some fun and party!

~Tim
--
.|` Clouds cross the black moonlight,

Python....

[Kris Warkentin]

That may be a problem for python as well then...the code is sure nice and easy to look at...I can see people saying, "Gee, that looks like Basic" too. Python is just as powerful as Perl but way simpler and you can actually read the code too.

Re: Parenth's

[Nagash]

Granted, but since it's interpreted, it is something to consider.

Also, properly indented (as with any language), it's really not all that hard to read. Just gotta think differently :)

Woz

This answers are obvious...

[kruhftwerk]

Lots of Irritating Silly Parentheses and ...

People don't naturally think recursively.

That being said, I actually really like functional languages. I had to learn Scheme in first year Computer Science and found it to be quite an interesting experience:

• It introduced me to emacs, whose paren matching and lisp mode saved many, many, many headaches
• It showed that you can build any sort of data structure out of lists
• You can create any loop construct recursively
• Treating functions as regular data, you can do many cool things
• You don't need a complex syntax to do interesting things with a language

I remember thinking back then about why they were teaching us this useless language and not something more practical like C or C++. I think the most important this was the simplicity of the syntax. The fact that we wrote a Scheme parser in scheme by the end of the course really shows how little there is to the language but also the power of what it can do in the hands of a newcomer to programming.

People would be challenged by with the problem they were trying to solve, unlike the C/C++ courses of later years where cries of "Why wont this compile" were oh so common. It's difficult to think why someone would have trouble programming in C now that we've been doing for so many years, but think back to those Comp Sci days and it's obvious that simple, functional languages allowed the profs to teach computer science and not language syntax.

I've been meaning to learn LISP again due to that elegant simplicity that I miss about comp sci. If you're interesting, check out the Structure and Interpretation of Computer Programs. If you've ever wondered what you can do with LISP, this is the book to read.

Re:Formal correctness proofs -- YES!

[supermooresie]

As for all the people who hate parens in LISP or Scheme, check out DrScheme, the free, open-source Scheme interpreter from Rice University (URL escapes me right now, but I know it's below cs.rice.edu).

http://www.cs.rice.edu/CS/PLT/pack ages/drscheme/

Looks pretty darn slick.

Re:Hate Parentheses?

[blasphemi]

Haskell lets you do this too.

For fans of The Fast Show

[mrogers]

The closest I came to finding a working foundation for distributed functional programming (with object semantics) was a synthesis between David P. Reed's distributed file system transaction protocols and Arvind and Gostellow's U-Interpreter for dataflow computations (see the special "Dataflow" issue of IEEE "Computer", I believe it was December 1980). It turns out that Reed, Arvind and Gostellow had come, from two distinct directions, on virtual machines to describe their programming systems that were isomorphic to one another. Reed's distributed transaction file system was based on the object oriented CLU programming language developed for OO research at MIT, and Arvind and Gostellow had come at theirs from the work on dataflow computers arising from
the excitement inspired by Backus's previously mentioned Turing Award Lecture.

Obviously I was vey, vey drunk indeed.

$ cat < /dev/mouse

Re:Like structured prog wars. Funct langs have los

[TedTG]

I think you're confusing functional languages with procedural languages. To me, functional and OO are on different evolutionary branches, one is not more advanced than the other.

p.s. Has anyone noticed that most of the major paradigms have removed something from programming? Structured programming removed "goto", OO removes "case" (when done well), and funtional programming removes assignment... I don't have enough experience with logical programming to know if it does anything similar.

It's a entirely new way to think

[Nagash]

I took a course on Programming Langauges, and we studied Scheme as our first language. It was a major hurdle for many people. This is probably because you have to think in functions and recursively, as opposed to the structured/imperative way of assignment.

The ultimate goal of functional languages is to have everything act as a function of it's inputs. Setting variables should not be necessary. However, it never works out that way. It would be hell to write that many functions. The spirit is still there, tho.

Probably the biggest problem was the fact that a function is a first-class value (i.e., it can be passed as a parameter, returned from a function and assigned to a variable). Writing functions within functions to take care of little recursive problems was a major stumbling block. Instead of single-stepping your way through an algorithm, you thought of a way to write an anoymous function inside another function to take care of a something. This function is not defined - it is created at run-time. The fact that you could return it was weirding people out as well.

Another thing that throws people for a loop is the lack of non-local exits. There is no return in Scheme (or Elisp. I don't know about Lisp, but I would imagine it is similar). Instead, you have a very generalized procedure called call-with-current-continutation that does everything return does and more. It actually allows you to save the state of your program, put it in a variable and use it again later. Thus, you can make generators for infinite data structures. This is hard to grasp, especially after two years of C/C++/Java.

The fact that everything is a list in Scheme and it is not typed can be a bit of a stumbling block.

Structured/imperative programming is a much more natural way to program - at first. When you get some practice in functional languages, you see how incredibly powerful they can be. (this is not to say C/C++ style languages aren't powerful. They just lack some really handy features functional languages have as primitives)

I think people avoid them because of the total paradigm shift that is involved. It really is quite a leap. There is no lack of literature on it, it's just not published by IDG Books or SAMS ;) The fact that it is not typed and makes it a little slower is also a factor. They also hate Lots of Infernal Stupid Parenthesis! =)

Woz

Procedural are Taught First

[khog]

Procedural languages are taught first, and for a reason: they mirror lower mathematics better than a functional language. The concepts of functions and recursion aren't even present in mathematics until high Algebra and Calculus, the latter only in Calculus.

If someone learned all the math they were going to, and then began programming, functional languages would be rather easy to understand. If someone, like myself, learned QBASIC when they were seven or eight -- when they knew only lower mathematics -- they'd find functional programming obtuse and clumsy, useful only for higher math.

I see no flaw with this system, though. Imperative languages don't tend to lend themselves to very high math and certain functional tricks. Functional languages do. Each has their place, but both are versatile enough to do the job of the other (perhaps not as well).

On a side note, Scheme is the first language taught here at IU, in Intro to Computer Science, and no one really likes it. We've got Dybvig here at IU (big guy with ANSI Scheme), but that doesn't seem to help people's appreciation. Maybe some good IDEs and GUI toolkits would bring it more into the mainstream. I doubt it, though.

Mike Greenberg

If you can't beat them... use Perl.

[SpanishInquisition]

It will take a long time for people to switch to FP because the imperative mindset is so deeply anchored in their habits.
Usually people who have never encountered FP don't know the power it could give them so they don't even try to learn it.
But if you know it and want to use it at your job but management won't let you use a functional language, use an imperative language with functional possibilities, use Perl.

Perl has anonymous data structures, closures with deep binding, map, grep , sort, name it. It lacks some advanced stuff like call/cc and macros but with what you have got, you can be a happy functionnal programmer without anyone even knowing it. The only problem is if you have an imperative weenie (or an OO weenie for that matter) that has to review your code and ask you to change it because he has no clue about how 'map' works.

What I meant about perl being more "human"

[Ars-Fartsica]

Yes, perl can be vicious to read, but like most human languages, you can bend and reorder perl in almost any way you want.

As a language, it really does allow itself to be used in a way most comfortable by the programmer...in other words, as perl programmers like to say -

There more than one way to do it!

Re:they are too hard

[mistral]

you could write something analogous to:

if (it's raining) then (don't go to park)
else (go to park, or whatever).

the function is a simple conditional, an if-then.
the lambda expression is the (it's raining)
predicate, which gets bound to a variable
before the if executes. then the appropriate
clause of the conditional executes. if you're
worried about actually making something happen,
there are a number of ways to do it. You can
make the branch of the conditional return a
state variable that is executed on later, or
you can call a continuation with the proper
value indicated, or you can cause a side effect
by setting a reference variable that's monitored
by another thread, or you could thread a monadic
side-effect-execution-with-state through the
thing. sorry if this is unclear. let me know and i'll explain more.

Functional Programming has a bad rap

[Scott_Marks]

I have used functional languages since the 70s. I put together a more-or-less complete implementation of Backus' FP in Rosetta Smalltalk running on a Z-80 (64K RAM, CP/M OS) around 1980, programmed in Interlisp until '87, bogged down trying to implement Common Lisp (which can be procedural or not, your choice) in Windows 3.1 (got just about done, then Steele brought out version 2 -- ugh!) about 1992. Currently I just write one-liners in Perl. What happened?

Mostly, there were no implementations. Plus it's sort of like the Micro$oft dominance -- all the good stuff was written in procedural languages (primarily C/C++), so why fight it? But the real question is why did procedural languages win?

What I don't believe is that it is harder or less natural to think functionally than procedurally. It's just what one is taught.

Like recursion, for instance. In my small experience teaching, I saw the light go on with regularity -- you just chip away at the problem, deal with some part of it, and then (recursively!) deal with the remaining simpler problem. Hmm, that doesn't seem so hard.

Most people don't think about transactional database programming as being like FP, but just think about it -- it's just like Backus' Applicative State Transitions, where one computes the proposed new state, validates it so far as possible, and then installs it as the basis for more computation.

Another thing to think about is the long-standing tradition in math of "recurrence" relations, like the Fibonnaci series, or approximations to pi, or whatever. Those are clear examples of things which could be thought of as iterative or recursive, just depending on the color of the lightbulb.

Erlang is used

[mikemikemike]

Several major telecommunication products marketed by Ericsson are programmed in a function language - Erlang. These products are huge, hundreds of thousands of lines of Erlang code. Goodness knows how many millions of lines of code they would have been in C or C++! They include systems to control ATM switches, special purpose PABXes, Network Simulators etc.

But Ericsson doesn't want to be out there on its own as regards using functional languages. Therefore Ericsson has released the whole of the Erlang system as Open Source. For those who like such things, commercial support is also available.

So why haven't Functional Languages caught on? Someone once said "perception is reality", and peoples' perception of functional programming is that it is something you learn at school because it is good for you, like learning Latin. Then you forget all about it and use C++ or Java like everybody else. Popular perceptions are:

• FP is hard to learn and requires a PhD in mathematics
  This may be true for some functional languages, but Erlang is trivially easy to learn.
• FP are very inefficient
  Not true any longer. True the rely on recursion and other techniques which used to be inefficient - but implementation using tail recursion of last call optimization makes recursion is just as fast as normal iteration.
• You can't hire programmers who know FP
  Firstly if a programmer can't learned to be productive in a language like Erlang within a week, then they aren't worth hiring. Secondly, the number of people who are learning Scheme, ML etc at school is increasing day by day.
• You can't buy tools for FP
  And what's wrong with emacs then? If you are one of these people who like writing programs by clicking in funny boxes, then FP's aren't for you. But for the rest of us, functional programs are much closer to specifications than those funny boxes. Erlang, for example has a rich set of tools like debuggers available free.
• There aren't any libraries
  Wrong, yes there are. Have a look at the Erlang open source web and you will be amazed.
• Learning FP won't enhance my career prospects
  Unfortunately, probably true.

Now a plug for Erlang:
It is trivially easy to learn. The purists hate it as it just does things like I/O in a non-functional, intuitive way. It is also dynamically typed, which many of us like, but it makes the type purists throw up. I.e. 99% of Erlang programs are pure functional. The bits which shouldn't be functional, aren't functional. Concurrency and distribution are built into Erlang in a way which makes writing concurrent or distributed programs almost as easy as sequential ones. Erlang was designed in industry and has industrial strength well proven and supported tools.

Functional w/ Imperative vs. Imperative w/ func

[GodSpiral]

>>
For this reason, I think the best way to incorporate functional paradigms is to extend our imperative languages with functional features:

There is nothing incompatible with having both things in a language. Try Common Lisp, it embraces both models fully.

The point I was trying to make is to overcome corporate resistance, compatibility with tool sets, and the job appeal of a language:

Java + functional has a better chance of success than Visual CLOS + Tk.

Re: on type systems

[vanicat]

You've got a good point here, but what can I say...? People research what they like. If you like type systems, it's pretty likely that you'll like functional programming too, since they're so similar. I do believe there is something fundamentally more natural about typing a functional language than an imperative one, though.

the fact is that the type is a kind of proof that the program is valid (for a certain meaning of valid), and it is well known that it is easier to prove automatically something on a functional language than to prove something on a imperative one, so it's more easy to find (or to verify) automatically the type of a program in a functional language

Re: Parenth's

[Nagash]

Try writing a parser. When things are delimited, it makes it a helluva lots simpler and faster, especially since there is little to no ambiguity.

Woz

FPLs aren't so far ahead of Python

[Junks Jerzey]

The reality here is that it's not the "functional" aspect of such languages that programmers really want, it's the other biggies: garbage collection, lack of declarations, built-in support for hash tables, interactive development environment, and so on. If an imperative language had all of these, most programmers wouldn't feel the need to get the rest of what functional programming provides: higher-order functions, currying, provability, laziness, monads. And there are already languages that provide the features that are most wanted including, notably, Python.

Scheme for Neural Networks

[LinuxBean]

I used Scheme to write a neural network after taking SICP in high school. It was slow, too slow, so now I write code mostly in C++. Hasn't this been discuss years ago, like in the 70s? With the arguement between those with the Lisp machines and those with those new fangled PCs? Yes, von Neumann architecture is inefficient but all of our money goes into optimizing it. I think I am rambling. (stop 'ramble now)

LISP needs marketing, that's all.

[ten thirty]

My experience with LISP and it's MIT dialect, Scheme, where at the University, where I would imagine 95% of all other programmers have their initial and perhaps only encounter the languages, unfortunate as that may be. I was very impressed with the flexibility that LISP gives the programmer in terms of angles at which to attack a given problem. Whereas with procedural or imperative languages one might be a bit corralled by the semantics and structure of the language, LISP can mimic any language paradigm, and so allows the programmer to use the thought process best suited to the task. Paul Graham gives an implementation of an object oriented language in LISP in his handbook, ANSI Common LISP, to illustrate this point. I work now for federally funded company whose primary interests, one would think, are not in the commercial viability of their tools but in their effectiveness. However it seems that we end up using a lot of commercial off the shelf products simply because of the hype that inevitably precedes them in this day and age. I am fully convinced that everybody here would be programming happily in LISP if it were the case that LISP was marketed by SUN as unflaggingly as Java has been over the past few years. I think this is true despite the fact that Java was tailored to the programmer's familiarity with C, because LISP syntax is SO easy to learn. Sometimes I wish LISP were picked up by some huge company. A company with the resources to fill those massive bookshelves at your local megastore with vapid texts touting the grandeur of their new LISP virtual machine. Then the fun of programming could really begin!

Re:Formal correctness proofs -- YES!

[kcarnold]

Prove that the simple Scheme function:

(define fib
(lambda (x)
(cond
[(equal? x 1) 1]
[(equal? x 2) 1]
[else (+ (fib (- x 1)) (fib (- x 2)))])))

gives the nth Fibonnaci number:

Proof by induction:

Base cases (1, 2):
Conditions 1 or 2 will be satisfied, in either case returning 1.

Inductive step: Assume fib returns the correct value for k-2 and k-1, and k > 2.

Neither of the first two conditions will be satisfied, so the else clause is evaluated. (fib (- x 1)) and (fib (- x 2)) are the correct values by the assumption, and their sum, by definition,
is the k'th Fib. number.

Therefore, fib returns the correct value for all n >= 1.

(it's been a while since I've proven a program, so this might have some subtle errors)

Note that the above function is recursive, not iterative, and evaluates the same thing multiple times. (This would be fine if the interpreter recognized that the function has no side effects, so the return value could simply be stored and recalled, and maybe some interpreters do this.) Here is a more efficient algorithm that is a bit harder to prove:

(define fib-iter
(lambda (x)
(if (or (equal? x 1) (equal? x 2))
1
(fib-iter-help 1 1 (- x 2)))))

(define fib-iter-help
(lambda (fnm2 fnm1 n) ; fib(n-2), fib(n-1), n
(if (equal? n 0)
fnm1
(fib-iter-help fnm1 (+ fnm2 fnm1)))))

I've never used ACL2, but it looks interesting.

As for all the people who hate parens in LISP or Scheme, check out DrScheme, the free, open-source Scheme interpreter from Rice University (URL escapes me right now, but I know it's below cs.rice.edu). When you're done with a function and construction and have to close a bunch of parentheses, just keep typing close parens. It will highlight the area enclosed by the close parenthesis you just typed, and it'll show you if you type one too many or too few. It also has syntax checking and highlighting, and a neat feature that will draw arrows between symbol declarations and uses when you hold the pointer over it. It also works exactly the same in Linux, Windows, Mac, and whatever else it's been ported to recently. Okay, enough propaganda...

LISP without so many parentheses

[YoJ]

For all of the predictable complaints about functional languages having too many parentheses, here's a link to an applet that interprets a scaled down version of LISP that doesn't need as many parentheses. It was designed by Chaitin to illustrate program complexity ideas.

LISP Interpreter

I love functional languages. If you think about the problem you are trying to solve in the right way, often times you can find a simple three line functional program that does the job. That's the kicker though: you have think in a functional way. Simple recursion is about the deepest functional abstraction most programmers can wrap their minds around.

nojw

"Worse is Better" paper

[nonya]

Richard Gabriel wrote a paper (in 1991) called Lisp: Good News, Bad News, How to Win Big that tries to explain why lisp didn't take over the world. The "Worse is Better" section is particularly relevant.

On a slightly different topic, to understand why lisp is so interesting I highly recommend On Lisp by Paul Graham. A quick summary of cool lisp features are:

• Very powerful macros. The full power of lisp is available when a macro is expanded.
• An object system with mulitmethods and a metaobject protocall.

Disclaimer: I'm a C++ programmer. I've spent much more time reading about lisp than witting lisp programs.

Re:good intro to Scheme for GIMP scripting newbie?

[Dwonis]

Use the PyGimp extension, which allows you to write GIMP plugins in Python. Python is one of those few *intuitive* languages, and is perfect for the GIMP.
--------
"I already have all the latest software."

Employees resist as well

[John Jorsett]

Trained staff in a minority language are going to be rare. This does not necessarily make them more expensive (nobody else wants them), but it does make recruitment much harder and more uncertain.

A corollary to this is that programmers are going to be less willing to learn a language that no other employer is going to want. Having a few years of intensive (not an insult, just an example) Eiffel experience on your resume might just be a recipe for unemployment, whereas Java programmers are practically carjacked by prospective employers these days. Acquaintences of mine have quit jobs just to avoid being put into this position.

they are too hard

[Evro]

Have you ever had to write a lambda expression? Was it easy? I had to use scheme and ML in my programming languages class and I found them really hard. I can't think that way. That is the biggest problem with functional languages; it is not a normal way to think. "If it is raining, I will not go to the park" is easy to conceptualize and easy to write in a procedural language. I don't even know what the equivalent statement would be in a functional language.

Anyway, I hate them.

__________________________________________________ ___

Not well suited to application software

[kevin805]

I know you can write anything in any language and all that, and I know compiled lisp is supposed to be as fast as C, but the problem is that functional programming doesn't match how we use computers.

How do you phrase the questions when designing a program? Most likely, you think along the lines of "when the user clicks the button, then we do this", which is a procedural way of thinking. You don't think, "this function takes, X, Y, and Z, and produces W". Well, maybe if I did more programming in functional language, the second would seem natural.

Think how you would set up an event listener in a functional language. You'd probably think, "oh, that's easy, because functions are first class data", but when you go to do it, you'd probably find that you ignore the return value of the function, and the part of your code that does the work looks like procedural programming in a bunch of parentheses. Now that I'm thinking about this, maybe this is why Emacs has such a different feel than other editors.

But functional languages are great for math. Probably a good idea for embedding in another program as a scripting language. Matlab uses a funtional programming language. Autocad uses a Lisp dialect.

RPN calculator analogy / Beer

[Master of Kode Fu]

I think imperative programming languages tend to be more popular than functional programming languages for the same reason that reverse polish notation calculators are less popular than those using standard notation. . A standard notation calculator should fill a good number of common needs, but when the going gets hairy, there's nothing like an RPN calculator to do the job quickly.

The same applies to programming languages. For many programming tasks, the imperative model will serve you well, but there are times -- especially when repetitive, recursive or just plain mathematically complex tasks are involved -- that a good functional language is exactly what you need.

P.S. While probably not the best way to compare languages, you might want to check out this web page that compares how you'd get verious programming languages to output the complete lyrics to the "99 bottles of beer" song. (At last, an almost on-topic posting about beer!)

They're still too slow

[Roelof]

I find functional languages extremely interesting. In fact I've spent well over three years implementing a kind of Hope derivative called very originally TLC (Typed Lambda Calculus).

What made me do it was that at the time (early nineties) I knew of no implementation that defined a FL metacircularly. Or rather, a strict FL. So there was a challenge and one I did succeed to master.

So, TLC (or Tender Loving Care as Hal Hildebrand would have it) is a strict FL implemented in itself. Albeit just the interpreter and type inference engine.

The compiler which currently compiles TLC to plain C with gets linked to the also C VM uses the FPM compilation scheme.

Though it doesn't use optimazation like memoization or abstract interpretation it is a strict language and as such supposed to be faster than a lazy implementation.

Alas, I have found even Java to be way faster. And I do not consider Java to be anywhere near fast.

Unfortunately it is not available for download. You see, I wrote it in Smalltalk/V-PM. Even the running C interpreter is currently useless since it's for BCOS2 and relies on a OS/2 database library. Been meaning to regenerate an interpreter that does not rely on any OS/2 quirks but somehow haven't come around to doing it.

My 2 c.

Roelof

Re:They're still too slow

[Roelof]

B.t.w. one reason this particular implementation
could be a little on the slow side is because it has a reference counting GC. I needed that to have quick finalization.

SML/NJ

[J--n]

From what I've seen of functional programming, I think it's really kick ass! At CMU, there's a course that teaches SML/NJ and some of the stuff you can do with it is really cool. I think it's pretty slow, but the fact that you can write a function that returns a function saves you a lot of time. It's often the case that if you write something that compiles, it'll work the first time and everytime. Other cool stuff in SML/NJ: easy to create new datatypes, all ifs require elses, and you can nest comments (unlike java). Continuations are confusing as hell, but overall I'd say functional programming is pretty useful if you don't care about speed and just need to get stuff done.

Re:Where's this paper? It's not in POPL 83

[Animats]

Sure it is. On the POPL '83 page, see

Session II: January 24, 1983 - Chaired by Michael Fischer (Yale Univ.)

• Automatic Program Proving for Real-time Embedded Software
  Scott Johnson
  John Nagle (Ford Aerospace)

The name of the paper in the proceedings was slightly different, but that's it. The text, unfortunately, isn't on-line anywhere.

Re:Formal correctness proofs -- YES!

[kcarnold]

Try a more complicated algorithm. Add a few global variables, a few pointers here and there, and then try to prove that. Yes there are global variables in Scheme, and things that can sort of act like pointers, but functional languages are structured such that it is more natural not to use them. Oh, and the fact that your Scheme programs will _never_ segfault (given a properly written interpreter / compiler) is also nice.

Re:Formal correctness proofs -- YES!

[kcarnold]

Good point. However, a Scheme implementation is much closer to the algorithm proved in many cases. If you really want a rigorous proof, it would be necessary to break down the program into a parse tree, and define how the low-level Scheme elements map into function space.

And you got two things wrong in the last sentence. First, a Scheme function is called like (fib -1) (believe me, you can get used to it...). Second, the proof was for (or (= k 1) (= k 2) (> k 2)), not (= k -1).

Implementations

[Gepard]

One big theme I notice in all the comments on this topic: Functional languages didn't take off because there are (were) no good implementations.

Wrong.

I will speak only about Common Lisp and its direct predecessors, because of all the functional languages I know it is the most flexible and useful for real-life development.

In the 1970s and 1980s there were Lisp Machines. Read up on them sometime---I claim that they were the most advanced and powerful workstations of their time. They had graphical development tools and environments that were mere dreams in the minds of other programmers at the time. They had hardware specialized to run Lisp, and they did so very, very well. Lisp Machines (Symbolics et al.) went out of fashion at around the time when general-purpose hardware began to pick up a lot of momentum and the personal computer began to gather popularity.

Their place was taken by implementations of Lisp running on workstation-class computers. Digital, Sun, IBM, and HP boxes all had third-party Lisp implementations. Most of these implementations are alive today, and available for most UNIXes, as well as Windows and MacOS. These would be Franz Inc.'s Allegro CL, and Xanalys' (formerly Harlequin) LispWorks. Both are robust and powerful. In fact, well-written Lisp will outperform comparable C code with either of those compilers. The real issue here is that there are no free Lisp implementations that compare to the commercial offerings in quality and ease of use. There are CMUCL and CLISP, but neither holds a candle to ACL or LispWorks, for example.

The lack of popularity of functional languages stems mainly from ignorance. As several other people have pointed out, it takes some effort to learn the paradigm, and most people, even those with CS degrees, do not choose to make that effort. Lisp hackers tend to have a strong background in language theory and other topics too complicated for the average ``geek'' whose competence ends at some Perl shopping cart script.

Re:Formal correctness proofs -- YES!

[Abigail]

Second, the proof was for (or (= k 1) (= k 2) (> k 2)), not (= k -1).

Which is, of course, exactly my point. Your "proof" makes assumptions on the precondition that isn't there.

-- Abigail

Re:Formal correctness proofs -- YES!

[plumby]

I can't remember the last time I even thought about putting a global variable in a C program.

You can't even have them in Java, and there aren't pointers (well there are Reference objects now, but I've never felt the urge to use them).

However, the point that I was trying to make was that from the little bit of functional programming that I've had a play with, I seem to be able to achieve pretty much the same style with C. It seems to be more of a design issue rather than a specific language thing.

In a similar way, when I had to go back to C programming a few years ago, I still designed my system in an OO way, and coded it to be as OO as possible (data all in structures, accessed only through certain functions etc). It involved being very disciplined in the way that I used the language, but it was still just about possible. Of course, it is a lot easier to do proper OO systems in C++ or Java, and it's probably a lot easier to do proper functional programs in Haskall or Scheme, but it's not the language that makes the methodoligy, and I'm still trying to find a good overview of what makes the *principal* of functional programming so much better than anything else. It's got to be more than no pointers and no globals (hasn't it?).

And if proof *is* all about not having side effects by not having global variables, then I'm pretty sure that I can proove my C code.

Myth or Fact? Bugs in the face of Static Typing

[Tom7]

Well, it's not a myth as far as my experience or with the people I work with.

The type system can obviously be abused; you could make a variant type:

datatype variant = Int of int | Real of real | String of string | Tuple of variant list | List of variant list | ...

And then use this as the argument and return type of all your functions (this is essentially what's happening in Lisp). It's still "typed", but you've lost all the benefit of ML's type system. It's just a bad idea to do this.

But I'll tell you why you probably wouldn't run into the bug you describe:

First, in a big software graphics package, you'd define an abstract type for points. Your function might have a type like:

rect : point * int * int -> unit

(You might even have an "extent" type, depending on how useful it is to define operations on them, and how prone you are to making errors like this).

Second, if you find that you commonly make this kind of mistake, you would be wise to use records rather than tuples as arguments:

fun rect {x, y, height, width} = ...

which might get type:
rect : {x : int, y : int, height : int, width : int} -> unit

And you can call this with any argument order you like:

rect {x=10, width=20, y=5, height=20}

Finally, if you have doubt about what a function does or the arugment order, you read the signature, which is an excellent and common place for the programmer to document the purpose of the parameters.

... So yes, it's possible. But as an experienced ML hacker, I can tell you that it is really, really uncommon! I have experienced exactly 0 parameter mix-ups in the thousands of lines I've written this summer.

Network Functional Programming

[Baldrson]

Cutting to the chase:

An appropriately conceived relational calculus is more powerful than a similarly conceived functional calculus because functions are special cases of relations.

When I was manager of interactive architectures at the precursor to Prodigy I spent about a year pursuing functional programming languages as a possible public standard for the network programming language. By network programming language, I mean a language used to make programming distributed applications as transparent as possible with dynamic redistribution of functions based on load leveling and security requirements.

I chose functional programming because the dataflow graphs provided a natural network map, the nodes of which could be redistributed on the physical network without altering any of the logical analysis that went into the writing of the program. The inspiration for this work was my prior experience with the Plato network where I had pushed the creation of a mass market version of that product. (Worthy of digression is the fact that middle management killed the release of that product and may have, thereby, killed Seymour Cray's first company, Control Data Corporation along with the Midwest's chances to be the locus of the network revolution -- 20 years earlier than it finally happened.) I realized that a widely distributed mass market Plato network needed parallel distributed authoring tools for novice programmers. Combined with the Turing Award Lecture by John Backus of BNF and FORTRAN fame I was inspired to pursue functional programming when I left Plato to join with AT&T and Knight Ridder in their joint venture mass market information service experiment.

While authorized to pursue this vision by AT&T and Knight RIdder, I initiated working groups involving computer telecommunications departments from Bell Labs, Atari, Apple, Xerox PARC, MIT, Software Arts and Knight-Ridder News to explore a staged evolution from tokenized FORTH-based programmable graphics communications protocol that would fit in the earliest Videotex terminals being produced by Western Electric (which became PostScript) through distributed Smalltalk based on a FORTH VM, and on to either functional programming with data abstraction or possibly a more radical revision of Codd's work in relational programming. During this time of intense activity, I was fortunate to actually meet Alonzo Church and Haskell Curry at the 1982 ACM conference on functional programming at Carnegie Mellon shortly before Haskell's death and at least get them to sign my conference proceedings and personally thank them for their contributions.

The closest I came to finding a working foundation for distributed functional programming (with object semantics) was a synthesis between David P. Reed's distributed file system transaction protocols and Arvind and Gostellow's U-Interpreter for dataflow computations (see the special "Dataflow" issue of IEEE "Computer", I believe it was December 1980). It turns out that Reed, Arvind and Gostellow had come, from two distinct directions, on virtual machines to describe their programming systems that were isomorphic to one another. Reed's distributed transaction file system was based on the object oriented CLU programming language developed for OO research at MIT, and Arvind and Gostellow had come at theirs from the work on dataflow computers arising from the excitement inspired by Backus's previously mentioned Turing Award Lecture. Reed's system was particularly important for funcitional programming enthusiasts because he was directly addressing the concept of network state, transaction mechanisms and the practicalities of network timeouts, faults and other real-world difficulties. Unfortunately, although Reed would go on to become chief scientist at Lotus Corporation, where some collegues of mine from the Plato project were developing a distributed programming system called Lotus Notes, Reed never actually pursued his conception of network state within the context of functional programming, nor even within the context of Lotus Notes! Perhaps this was my fault for not attempting to beat Ray Ozzie over the head with Reed's thesis, but Ray was pretty cagey about what he was up to at Iris Associates back in 1984. By the time I found out Reed was Ray's chief scientist, I assumed he and Reed were working on something related to Reed's thesis. Imagine my surprise to discover Notes was not only a distributed file system of sorts, but that Reed's primary theoretic expertiese was never actually discussed as a foundation for Notes! But it gets better: the most ironic twist is that Reed and Arvind were both at MIT's Laboratory for Computer Science when I discovered their respective works. When I went to visit them at MIT's LCS, I walked up the stairs from Arvind's office to Reed's office to discover that they had no idea that their respective VM's were nearly identical despite being based on entirely different approaches -- and that neither of them were particularly interested in talking to the other about a synthesis between their works!

Academics...

In any case without a good foundation for handling network state in distributed functional programming, I was left facing the same sort of problems faced by John McCarthy when Marvin Minsky et al took off and started to kludge in all kinds of arbitrary state handling "formalisms" into McCarthy's mathematically pure implementation of Church's lambda calculus: LISP. I saw where that road led...

While a degeneration of Reed's approach was actually tried on the Intel 432 project under the iMAX operating system's distributed OO file system, to the best of my knowledge, the only other attempt to implement his system was a distributed archive object base that I prototyped a few years back at Filoli Information Systems (formerly Memex -- the company that bought out Xanadu Operating Company and attempted to resurrect hypertext after Autodesk dropped support when John Walker was displaced as CEO from that company and ultimately from the entire country).

However, I've never really been happy with the functional approach because functions are a degeneration of relations. That's why I've always been more interested in advancing the state of relational programming than that of functional programming. The problem is, functional thinking is embedded in our mechanistic views of time and causality -- sort of the way up and down are embedded in our physical structures due to having evolved on the surface of a planet. If we're going to deal with distributed persistence and transaction problems, we may as well handle the more general case -- especially since relational programming is at the root of the relational database industry, and it appears a relational formulation of time based on a revision of Russell and Whitehead's Relation Arithmetic, may end up dominating the future of physics.

Thank God

[nebby]

I just took a programming course in Scheme last semester, and I'm really happy to see that I'm not insane by the looks of this thread in the fact that I really hate functional languages. Assuming Scheme is a good taste of all functional languages, they're hard to read, hard to conceptualize, and hard to debug in my opinion.

I did write some pretty complex Scheme code so I feel that I've gotten a good enough taste to have this opinion. The thing that REALLY bothers me about the whole thing isn't even the language.. but it's the attitute of the individuals who code in it. They have this strange notion that they are somehow superior programmers and human beings because they can write recursive, elegant, Scheme code. I was able to in time, but the little elegant tricks I did in a few lines of Scheme are nothing to brag about compared to the complex systems I've designed with procedural languages. I can't see these types of systems feasible with Scheme.. our final project ended up being just a couple thousand lines and even that simple of a program felt like more of a cheap hack than a true system to me.

I can see Scheme as being useful in a few small exclusive situations involving deep recursion. Unfortunately recursion itself is only useful in a few exclusive (though important) situations.

If you think you're morally superior because you can write 12-level-deep lambda expressions.. I think you need to go outside some more.

Hate Parentheses?

[Tom7]

Here are elegant implementations in ML. If you hate the parens, you might want to try ML, since it's the only language I know of which lets you declare your own infix operators. (C++ only lets you overload, not declare new ones)...

infix 8 ^

fun b^0 = 1
| b^n = b * b^(n - 1)

- 2^8;
=> val it = 256 : int

A tail recursive version is also easily accomplished with a nested function.

Both of these have less punctuation than the lisp and C versions.

"... I know it's syntactic sugar, but it's oh so sweet!"

Commercially Relevant

[Hopeless]

I have personally developed commercial software in a functional language (Objective Caml -- a form of ML).

The fast code and small memory footprint of our product completely undermine most people's objections to functional languages. The most significant comment we receive is how rarely the product crashes -- this (to me) is the most important part of programming in functional languages: getting the job done without bugs.

A project to reimplement similar functionality in C++ had to start by writing an efficient memory allocator, implementing reference counting et cetera. I get this for free, along with true higher order functions, and much more.

But remember kids: use the right tool for the job!

-- Hopeless

Re: Parenth's

[adnt]

At least Emacs takes care of indenting pretty well.

Also the syntax it has makes it very easy language to parse indeed. It's hard to think of any other language than Scheme were it would be as easy to write metacircular parser (to write a parser for the lang in the lang).

If you want less parenthesis, choose other functional language. E.g. ML has much less parentheses. Though I myself find parenthesis helpful in following what belongs to what expression...

If you really hate parenthesis, use REAL man's functional programming language - Unlambda. It doesn't not have any parenthesis at all. :)