Revised definitions of object and object-oriented

I revised my proposed definition of object based on feedback, to be more general. Please put comments on the original post. I'm very interested in getting more feedback on the definition.

The Day Functional Programming Became Pure

The definition of "functional programming" changed slowly over the last 20 years, as expressed on the Wikipedia page on Functional Programming. Perhaps the process started even earlier with John Backus's famous Turing Award lecture Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs. [Note, I have revised this to put the quotations in chronological order and add a new paragraph on the end]

Before 14 August 2003, the page described functional programming as a style that emphasized the use of functions. For example on 14 October 2001‎ the entire page was 220 words long, and began:
Functional programming is a style of programming that emphasizes the evaluation of functional expressions, rather than execution of commands. The expressions in these languages are formed by using functions to combine basic values.  
A functional programming language is a language that supports and encourages functional programming. The oldest example is LISP. More recent examples include Scheme, ML, Haskell, Erlang, Clean.
Lisp is identified as the first functional language, and Schema, ML and Haskell are on equal footing.

The changes started on On 14 August 2003 when the pages from Nupedia, which had a structured and peer reviewed model for content production, were integrated into Wikipedia by Luxor to create a page with 1,640 words:
Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. In contrast to imperative programming, functional programming emphasizes the evaluation of functional expressions, rather than execution of commands. The expressions in these languages are formed by using functions to combine basic values.  

At this point functional programming is not about emphasizing use of functions. Instead it means programming with mathematical functions. Implicit in this definition is that such functions are pure, but because it is not explicit the implications were not clear. This description was elaborated until 29 May 2006, when the page read:
Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. Functional programming emphasizes the definition of functions rather than the implementation of state machines, in contrast to procedural programming, which emphasizes the execution of sequential commands. A purely functional program does not modify state to produce values (as is done in imperative programming), it constructs new values from (but does not overwrite) existing values. 
There is no uniform agreement on what constitutes functional programming or a functional programming language. Often considered important are higher-order and first-class functions, closures, and recursion. Other common features of functional programming languages are continuations, Hindley-Milner type inference systems, non-strict evaluation (i.e. "laziness"), and monads.
There is still a distinction between (ordinary) functional programming and the "pure" form of functional programming, which avoids the use of mutable state. At this point there was a small but significant change, in the middle of the night, with no fanfare, by an unknown person. At 01:07 on 29 May 2006 it was changed to read:
Functional programming is a programming style that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programming emphasizes the definition of functions, in contrast to procedural programming, which emphasizes the execution of sequential commands. 
Functional programming relies on concepts from the lambda calculus, Lisp, and more recently Haskell. Frequently mentioned are the avoidance of state and side-effects (which provides for referential transparency), higher order functions, recursion, and closures. 
At a stroke, the author made explicit the requirement for purity and added it to the definition of functional programming. This requirement had been implicit in the description of functional programming, as computation with mathematical functions. This author also resolved the uncertainty about how functional programming should be defined. Prior pages said there is no agreement, but the new definition was stated without such doubts.

The change was made by ideogram, whose real-world identity is not disclosed. This account was created a few days before the active editing of the Functional Programming page started. Since then the account has been banned numerous times for unacceptable behavior (trolling) but this seems to be urelated to the editing of the Functional Programming page.

They didn't leave a revision comment. On the other hand, there is some discussion about the issues on the Functional Programming Talk page. There have been edits since this point, which have restored some of the previous language, but they are later removed. Currently (July 14, 2012) the page reads:
In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.[1] Functional programming has its roots in lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus.[1] 
In practice, the difference between a mathematical function and the notion of a "function" used in imperative programming is that imperative functions can have side effects, changing the value of program state. Because of this, they lack referential transparency, i.e. the same language expression can result in different values at different times depending on the state of the executing program. Conversely, in functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) both times. Eliminating side effects can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.
[1] Paul Hudak. 1989. Conception, evolution, and application of functional programming languages. ACM Computing Surveys volume 21, issue 3 (September 1989).
What are the implications of this? How did this change come about? Are we in the midst of a (small) scientific revolution? Who is behind this?


According to the new definition ML and Lisp are no longer functional languages. It is possible to write some some in a functional subset of these languages. The first requirement is avoiding the use of "ref" types in ML, or the use of assignment and structural mutation in Lisp languages. However, this is not enough, because many of the standard libraries for ML and Lisp languages have side-effects. This is especially true of any libraries for IO. As a result, the range of program that can be conveniently written in a functional style is fairly limited.

Interesting discussion on DSLs

Discussion of Domain Specific Languages (DSL) on Lambda-the-Ultimate. Originally the discussion was sparked by a Facebook status update by Erik Meijer. But not everybody is friends with Erik, so it was not public. Please put comments on the LtU page.

Why do North Americans not like MODELS?

Why don't North Americans (US+CA) publish work at the MODELS conference? The conference is often outside the US, but even when it is located in the US (Denver), North Americans don't publish there in great numbers. Even then, there is a higher percentage of North American papers at ECOOP, which is never located in North America. We don't like AOSD very much either.

ConferenceLocationNorth American papers
Models 12Austria16%
Models 09US21%
AOSD 12Germany22%
ECOOP 11UK35%
OOPSLA 11US54%

Of course, maybe they do submit papers but they just aren't accepted :-)

Update: The numbers for USA are even worse:


ConferenceLocationUS papers
Models 12Austria6%
Models 09US12%
AOSD 12Germany22%
ECOOP 11UK31%
OOPSLA 11US52%