Such questions are bound to end up in language wars. I'll try a neutral
approach below to stop this sub-thread right here and now, but if anyone
really wants to follow this question any further, may I suggest to take
this general part of the discussion to comp.lang.functional?
>On Wed, Sep 22, 1999 at 02:53:03PM +0100, Claus Reinke wrote:
>> Functional programming, i.e., programming with functions, is possible in
>> languages that do not support all features that have become common in
>> many functional languages.
>[eg. higher-order functions]
>
>Well then, it appears that I have a mistaken idea of what functional
>programming is. Can you give me, to cure my ignorance, a few examples
>of languages (preferably ones that are in use nowadays) that are *not*
>functional and the reasons why this is so. Is C functional, since it
>is possible to program with functions in it?
There have been attempts to define functional languages in various ways
and with different goals, and with my naive definition of functional
programming I tried (unsuccessfully) to avoid starting these discussions
again.
Most of the time, I find the following sufficient (opinions will differ;-):
- A functional language is a language
that supports functional programming.
- A purely functional language is a language
that only supports functional programming.
- A pure (functional/logic/..) language is a language that supports
(functional/logic/..) programming and is free of features that would
be considered impure, i.e., destroy some desirable property. In the
context of declarative programming languages, uncontrolled
side-effects are an example of an impure feature as they destroy
referential transparency.
So, if you want, you can call C a functional language, but its support
for functional programming isn't very good, so it is not a good
functional language (let alone a pure or purely functional one). Support
for functional programming in ML is much better, so ML is a much better
functional language. ML is neither purely functional (it supports
imperative programming) nor pure (it allows uncontrolled side-effects)
according to these definitions. Haskell tries to be pure, but as it also
aims to support imperative programming, it is no longer purely
functional.
>> From the perspective of numerical programmers, you could also ask: Isn't
>> compilation of high-level array operations into efficient code a
>> necessary part of every useful (FP) language?
>
>I would definitely agree with that question if you didn't refer to FP
>in it. You don't define FP as "useful", do you?
No, parentheses were used to indicate optional attributes. Numerical
programmers need efficient high-level array operations in any language.
If functional languages are to be useful there, they have to follow
suit.
Claus
