Re: Flamebait if I ever saw it

On 2007-10-07 17:57:54 -0400, tumbling toad said:

I think you have misunderstood what ML is. All MLs provide both first-class
lexical closures and mutable variables, just as Lisp and JavaScript do.
Consequently, Lisp and ML are both families of impure functional
programming languages.

The whole point of functional programming is to be able to reason about the parts of a program separately, in the same way that we can reason about separate mathematical functions separately.

When you have mutable data in a *dynamic* language you can no longer do this - any function, anywhere in the program, can mutate not just the value of a datum, but it's *type* as well. Thus you can't reason about the parts of a program separately - you must do *whole program* analysis which completely defeats the purpose of functional programming.

Both JavaScript and Lisp are *dynamic* in this sense, so unless you restrict yourself to a subset of the language, neither JavaScript nor Common Lisp is a functional language.

And before you go off on another rant, the reason such dynamism is desirable to lispers, even though it defeats the purpose of functional programming, is that it allows the programmer to change representational types in a *running* program as it is being developed, without having to:

1. kill the program,
2. recompile it,
3. restart it, and
4. recreate the relevant program state

just in order to see the changes. It also allows a programmer to run an incomplete, inconsistent, or incorrect program for debugging purposes.

In *ml each datum is constrained at compile time to be of a particular *type* for the duration of the program, even if it's *value* changes. This allows both programmers and the compiler to do effective reasoning (in particualr, type inference) about separate parts of the program separately; this is why *ml *are* functional languages. You can still do useful reasoning about separate parts of the program separately, even in the face of mutable data.

This is the trade off that you've been ignoring for months now. You have chosen the ability to reason effectively about separate parts of the program, even in the face of mutable data *values*. We have chosen the ability to change representational types in a running program without restarting the program, the ability to run incomplete, inconsistent, or incorrect programs, etc.

We have diferent preferences, that is all. Attempting to argue that your preference is *objectively* superior just betrays your lack of social skills - your inability to understand that others have different minds than you, and different preferences. Choosing something you would not choose is *not* an indicator of some logical failing, merely different preferences in this trade off.

.

Relevant Pages

  • Re: ANN: Q language website (new)
    ... that is the single best reason for adopting higher-level features - ... be simpler than in any other language. ... > implementation of the program would either match or beat the Lisp ... You need to be careful when you use the word "polymorphism" as it means ...
    (comp.lang.misc)
  • Re: C++ sucks for games
    ... The claim _seems_ to be that the Lisp code was better than the SPUC ... This goes back to the syntax in Lisp. ... languages however: one is that a real language provides reasonably ... reason that this is often helpful in solving the problems for which it ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... The claim _seems_ to be that the Lisp code was better than the SPUC ... This goes back to the syntax in Lisp. ... languages however: one is that a real language provides reasonably ... reason that this is often helpful in solving the problems for which it ...
    (comp.lang.cpp)
  • Re: Why Lisp is not popular with average programmers
    ... > Michael Sullivan writes: ... If one wants lisp to ... newbies to the language to deal with simple GUIs and network programming ... It's not a good reason to reject lisp, ...
    (comp.lang.lisp)
  • Re: TRM - Morbidity has set in, or not?
    ... One can consider each of them in complete isolation, and good designs will separate them as much as our tools allow. ... Aspect oriented programming and literal programming both attempt to isolate separate concerns in source code. ... oncern for correctness in network data models, ... the instructor required we use the unix m4 macro processor to add a type-safe parameterized list type to a language that doesn't support parameterized types. ...
    (comp.databases.theory)