Lambda the Ultimate

I have much more experience with imperative code (like most programmers) but I'm starting to branch out and have done a little bit of Ocaml and am endeavouring to learn lisp. So I stumbled on this article, "Functional Programming For The Rest of Us," thinking it might inform me about the benefits of my choice to learn some functional languages.

My question is: What am I missing? The article seems to ascribe a number of features to functional languages that don't seem to be particular to them. Treating functions as first class objects for instance. Or partial evaluation. He says that debugging is much easier because there's no global state -- but you can just view global variables as syntactic sugar for variables that are passed to every function.

He claims that patching Java code at runtime would be much harder than in FP -- but I don't see how that's something inherent about Java as a language (as opposed to implementation). He says this is because in an FP language "all state is stored on the stack." Which a nice thing to stay, but I could just as easily say, in a C program, "all state is stored in the global segment, the code segment, the data segment, and the stack segment." So if saving and modifying the stack is so easy, why can't I do it for a C program? Apparently we have some method for restoring the stack segment, the code and data segments are constant, and the global segment is just a list of values.

Closures are also described as being a functional language thing. I see them as a "easier to implement if you're delaying compilation until runtime" sort of thing. Python 2.5 can supports all the coding techniques described in the article and it certainly feels more imperative than functional, and certainly lacks the most distinguishing feature of FP I know of (no side effects).

Is he just confusing functional languages implementing certain features before imperative languages did with there being an inherent advantage to functional languages?

Admittedly, one advantage that he does bring up that seems accurate to me is that functional languages are easier to mathematically reason about. Although I remain skeptical of the practical advantages of this -- for all the cheering about it, every functional language implementation I've seen has been slow compared to C (yes I know it hard to objectively state that one language is faster than another, but one somehow becomes remarkably better at determining this when there's a paying client that needs something super performant). If lack of side effects and lazy evaluations provide such an optimization bonanza, why haven't I seen it yet?

In the June 2006 Issue of IEEE Computer (Volume 39, Number 6) Gerald J. Holzmann of the NASA/JPL Laboratory for Reliable Software authored "The Power of 10: Rules for Developing Safety-Critical Code" on pages 95-97.

I don't have an online link to the article text, but it can be summarized as:

Rule 1: Simplify Control Flow Banishing Recursion.

Rule 2: Set a fixed upper bound on all loops, excluding non-terminating event loops.

Rule 3: Banish Dynamic Memory Allocation and Garbage Collection.

Rule 4: Restrict each function's size to around 60 lines of source code.

Rule 5: Make liberal use of assertions to test any condition that can't be statically guaranteed.

Rule 6: Use static scoping to hide "data objects" to the greatest extent possible.

Rule 7: Check all return values and caller supplied parameters.

Rule 8: Banish any significant macro use (like "token pasting", "variable argument lists", and "recursive macro calls") beyond header file inclusions and simple defintiions.

Rule 9: Banish handles, macro-driven pointer manipulation, and function pointers while restricting pointer use to one level of dereferencing.

Rule 10: Continuously recompile all code with all compiler warnings turned on and ship no code until all warnings are eliminated and it passes strongly typed static analysis.

One gets the sense that these strictures are informed by life in the C/C++ discourse community, but they do raise deeper questions of whether the dynamic world and functional programming in general can support Safety-Critical Code. Could literate programming techniques be leveraged to further improve the reliability of such code?

Could we in effect replace these 10 rules with:

Rule 1: Code in Scheme, Haskell, or F#.

Rule 2: Embrace Literate Programming.

Contents

• Purpose
• Site Policies
  • Rules of Discussion
  • Policy Enforcement
• Important Considerations
• Credits

Purpose

Lambda the Ultimate (LtU) is a weblog dedicated to the study of general properties of programming languages, with an emphasis on programming language research and theory. The central focus of the site are the links to programming language related papers, articles, projects, and related news, which are posted to the home page by contributing editors. These items are intended to be discussed in the comments section associated with each item.

LtU also provides a discussion forum, which is for use by regular members to raise and discuss relevant topics that they think may be of interest to the LtU community.

LtU is foremost a place to learn and exchange ideas. The LtU Forum is not a debating forum for advocacy, posturing, attacks, vendettas, or advertising. It is a forum for informed professional discussion related to existing work.

Your contributions are welcome, subject to the policies described below. Abusive or off-topic posts will be deleted immediately. Posting here is a privilege, not a right.

Note that these policies were developed mainly to help new members understand the site, and to help maintain a high quality of discussion. It is difficult to capture the spirit of LtU in a set of written policies. If you are a new member, we recommend reading the site for a while to orient yourself before posting. For some discussion of the intent behind these policies, see the LtU: Policies document thread. For perspectives on LtU from some of its members, see The Spirit of LtU.

LtU has a large and vibrant community, with diverse interests and skills. The main thing uniting us is our interest in programming languages. Note that there's an important distinction between being interested in a particular programming language vs. being interested in programming languages, plural. Most LtU members have an interest in a multitude of languages, even if they may have one or two favorites. This is a good indication whether LtU is an appropriate venue for you. If you have a sincere interest in programming languages, you belong here. As you become part of the community, you naturally have a larger impact on the topics under discussion.

Site Policies

1. User names: Many of us here post with our real, full names. Anonymity and the use of pseudonyms is discouraged. We recognize that there can be legitimate reasons for wishing to post under a pseudonym. If you do not register using your real name, then if possible, please include identifying information in your user profile, such as your real name or a link to a personal home page or blog. Using a pseudonym by which you are known elsewhere can also help.
2. Signatures: Please do not include any kind of "signature" in your posts here, i.e. boilerplate text at the end of a post which includes affiliation, contact information, URLs, etc. You may include a link to your web site in your user profile information.

Rules of Discussion

3. Civility: first and foremost, we aspire to a high quality of discussion. This requires civility. It should hardly be necessary to explain this: be polite, avoid ad hominem attacks, etc. For more on the subject, see The Core Rules of Netiquette.
4. Provide context and substantiate claims: LtU depends heavily on links to papers or articles to provide context and grounding for discussions. Please try to provide references where appropriate. The following are cases in which external links are particularly important.
   1. Avoid design discussions: LtU is best used to discuss ideas that have been published and argued elsewhere. It is not usually a good place for design discussions or hashing out the details of a new idea. You can post here to let people know about a new angle you are working on, but please move the detailed discussion elsewhere, and link to it.
   2. Avoid ungrounded discussion: Discussions which start out with the posting of an opinion or idea that hasn't been clearly described, and for which no references are given, tend to result in unproductive debates with a reduced quality of discussion. It is much easier to evaluate and respond to someone's position when given a link to a carefully thought-out description of that position, and/or references which put the idea in a clear context. If a long description proves necessary, it should be posted elsewhere, such as on your own blog or website, and posted as a link on LtU.
   3. Strong claims require strong evidence: Resist the temptation to make big claims about programming languages that aren't already known, such as that you know the solution to a major problem, or that some feature which doesn't currently exist is easy to implement. The explanation of such claims should meet a higher standard than usual, and LtU is not the place to publish the necessary detailed explanation. Such an explanation should be posted elsewhere, and posted as a link on LtU.
   4. Link to prior threads, where appropriate: When discussing ideas or papers that were previously discussed on LtU, please try to link to the previous discussion. Not only does this help put your comments in context, it makes it easier for readers to find related information on the site. If what you have to say is directly related to a prior thread, consider posting a comment in that thread.
5. Don't pose controversial claims as questions: A common problematic pattern is to ask an apparently sincere question, when the real purpose of the question is either to argue against the subject of the question, or to introduce some new or controversial idea as the answer to the question. This may be a legitimate rhetorical device in some circumstances, such as when used in a paper, but in the context of a discussion it can be difficult to distinguish from a troll.
6. Off-topic subjects The following subjects are considered off-topic:
   1. Rants and "bashing": In general, rants and "bashing" of corporations, languages, and paradigms is off-topic here. However, criticism that is relevant to the subject of programming languages is acceptable, if it is offered in a professional manner, with an appropriate amount of detail and/or references.
   2. Objections to terminology: Computer science and programming language theory uses a great deal of well-established terminology. If you're not familiar with a term, either try to look it up and learn about it, or ask politely about it. Complaints about terminology, e.g. that some term doesn't make sense, are usually off-topic, particularly in the absence of a full understanding of the term in question. Of course, there may be times when someone does indeed use a term incorrectly, in which case questioning them about it may be appropriate. However, keep in mind that terms have a context - see point 14 below, "Terminology has a context".
   3. Complaints about file formats: Complaints about the file formats of publications, slideshows, etc. are off-topic. It is OK to ask if a file is available in a different format. However, please respect copyright. (Note that arguments about copyright are off-topic, too.)
   4. Language advocacy: It is of course perfectly acceptable to discuss the programming languages you're most familiar with, in the appropriate context, or mention features of a language that are relevant to a discussion. However, unmitigated language advocacy is off-topic. Remember that the emphasis here is on learning about and understanding general properties of programming languages. Statements about preferences in programming languages are opinions, and debating programming language preferences is off-topic.
7. Mentioning your own work: When it is relevant to a topic under discussion, it's fine to include links or references to your own work. Remember to acknowledge it as such. Avoid excessive self-promotion.
8. Announcements: Regular members who wish to announce something of direct relevance to the LtU community may do so by creating a new topic in the discussion forum. Don't create a new topic for every minor revision of a project. Rather, if you feel that it is appropriate to announce a minor revision, post a comment to a previous announcement for the project in question, if possible (see policy 4(d) above). Inappropriate announcements will be deleted without warning (example: announcements of computer science conferences not specific to programming languages). Announcements by brand-new users may be deleted unless they are considered particularly interesting to the community, i.e. don't sign up for an account here just to post about something you wish to promote - the post is likely to be deleted without notice. Announcements can always be submitted for consideration to one of our contributing editors, or to a regular member for posting in the discussion forum.
9. Keep threads focused: The most useful LtU threads remain focused on their original topic, or something closely related. If a thread begins to stray into other areas, consider creating a new forum topic for it.

Policy Enforcement

We encourage regular and respected members to let other posters know when their posts violate the policies or spirit of LtU. Such posts should be polite, pointing out the relevant site policy if appropriate. Avoid engaging in argument, and in particular, don't try to use policy enforcement to win arguments. If you, as an LtU regular, are unsure about your objection, it is best to mention it publicly. Publicly stating such objections helps us all to get a better sense of what kinds of posts are eliciting negative reactions, and if necessary, discuss the issues and perhaps refine the written policies. Note that not every minor infraction requires a response — rather, it is a consistent pattern of infractions that require attention.

We expect that such posts are likely to most often be directed at newer members, or those who haven't previously been active posters. Members who are regular posters are more likely to already be familiar with the site policies, and also are likely to be tolerated more easily if they occasionally stretch the rules.

As a newer member, if you receive a response of this sort, it is firmly suggested that you review your contribution, and accept that your chosen style of discussion or choice of topic may be inappropriate for this site.

Important Considerations

The following are not policies, but it is helpful to keep these points in mind during discussions. Their numbering is consistent with the policy numbers to avoid ambiguity when referencing them.

10. Know your audience: LtU includes many members who have studied programming languages daily for years, either in academia or in industry settings. LtU member Dominic Fox put it well: "Smarter people than me think LtU is full of smarter people than them; and yet it's also accessible to the newbie and the wannabe, and provides opportunities for both to participate in a learning community that's managed to maintain high levels of intellectual curiosity and professional courtesy." If you feel you lack the theoretical foundation required in order to follow some of the more advanced discussion threads, or are unfamiliar with existing programming language research results, our Getting Started discussion may provide useful pointers.
11. Respect and trust is earned: If you haven't previously posted to the site, it is likely that other members don't know anything about you, your areas of knowledge, or your discussion style. New members who begin posting provocatively and/or profusely are much more likely to trigger negative responses than regular members who have earned the respect and trust of others. Please keep this in mind when posting to the site as a newer member.
12. Do some homework: If you are sincerely interested in programming languages, you should not only be studying them (see point 10) but also experimenting with them. For example, it's easy to write an interpreter for a toy language — if you've never done it, that's an excellent way to get your feet wet. As computer scientist Alan Bawden put it, "All these things that people seem to have so much trouble with, like first-class procedures and continuations, are really easy to understand once you see how they can be implemented in a page or two of code." The only way we know of learning these things is by reading about them and playing with them (i.e., programming). You cannot learn swimming by debating the color or shape of pools.
13. Generalizations: Try to avoid overgeneralizing from your own experience, or making unfounded generalizations about programming languages. It requires a great deal of knowledge to generalize successfully about languages. Different languages can have very different purposes. When discussing the properties of programming languages, we can't just restrict ourselves to one kind of application, or one approach to writing code — we have to acknowledge that there's a bigger picture, even if it may not be of interest to us personally. It is much better to restrict the scope of your claims, than to generalize based on incomplete knowledge, which can lead to being considered a troll.
14. Terminology has a context: The same terms may have different meanings in different contexts. This can lead to misunderstandings. Before objecting to someone's use of a term, try to make sure you understand the context, and if necessary, ask a question about it. Also see policy point 6(b) above, "Objections to terminology".
15. Other resources: LtU is not intended to be an all-purpose programming languages site. If the style and focus of discussion here isn't appropriate for what one has in mind, many other forums are available. In the same vein, LtU cannot replace language-specific sites, and is intended to explore programming language topics of general interest. Some other resources which may be of interest include:
    • The comp.lang hierarchy of discussion groups on Usenet. A couple of non-language-specific groups which may be of interest include comp.lang.misc and comp.lang.functional.
    • The Langsmiths group on Yahoo, for people writing their own programming languages.
    • The C2 wiki, and the various other blogs and wikis linked in page footer below.

Credits

These policies are the result of many helpful suggestions by members too numerous to mention. To them our thanks. Some of the comments which we found helpful can be found on the The Spirit of LtU page, in the LtU: Policies document thread, and in the Ltu: blog not forum! thread. Others have made good suggestions which we will keep in mind for possible future implementation.