Crazy ramblings from an 18-year-old

[LB]

Imagine a divided graph like this:

A | B | C

Where B can fit into both A and C, but A and C exclude each other.

Most languages we know and use practically every day fall into section B (e.g. C++, Java, Python, C#, etc.), whereas functional languages fall into section C (e.g. Lisp, Haskell, etc.). However, to my knowledge, no language falls into section A.

What are the requirements for being in section A? Well, quite the opposite of those for being in section C. What's the opposite of functional languages?


Let's backtrack. Languages in category B such as C++ allow you to program in a variety of ways, both including and excluding the way you program in languages in category C. For example, in C++ I can follow both functional programming conventions and object-oriented conventions, or other conventions, even at the same time. For maintainability's sake, we generally choose one methodology and stick to it.

The methodology chosen will always be somewhere on the slider between A and C, and the code falls into category B simply because the language does not enforce strictly A or strictly C methodologies (with some wobble room of course).

It's obvious what brings B code closer to C code: using functions. But the use of objects and classes keeps B code away from C code - the only issue is that functions must always be used, so you can't cross the half-way point between A and C code to get closer to A code.

But what makes B code closer to A code? RAII. The idea that object lifetimes control the behavior of the program rather than functions. Obviously in C++ constructors and destructors, as well as scope, are heavily attached to functional programming. Or are they?

The last time I checked, constructors and destructors *looked* like functions but are treated so specially that I seriously consider them not to be. Even scope, which you may think requires a function, is not so attached to functions as you would think.

I would like to know whether scope is an integral part of functional languages or if it is just a way to prevent name collisions. Currently my viewpoint is that scope is not integral to functional languages and is just used to make it easier to understand the code.

So finally I get to describe A languages: languages in which the lifetimes of objects, that this, their scope, determine the behavior of the program. A languages are scope languages, object lifetime languages, whatever you want to call it.

But how does this work? How can it, without functions? What about dynamic memory? Isn't this just absurd?

It's quite absurd. All this comes from some 18-year-old who doesn't fully understand or comprehend all that that is programming languages. So, probably all this is nonsense, incorrect, irrelevant, logically contradictory, mislead, confused, etc.

So I'm just having you all read this because I found it interesting to think about and thought you might find it interesting too. In a few hours or maybe a day I will look back at this and have no idea what I was thinking - I just wanted to write it down so I didn't forget it.

[Catfish4]

Where B can fit into both A and C, but A and C exclude each other.

Stop right there! How can A and C exclude each other if they can have a common element?

[LB]

A = {1, 2, 3}
B = {2, 3, 4, 5}
C = {4, 5, 6}

[Disch]

I skimmed.

I would like to know whether scope is an integral part of functional languages or if it is just a way to prevent name collisions. Currently my viewpoint is that scope is not integral to functional languages and is just used to make it easier to understand the code.

It's an integral part. Each call to a function has to be unique to itself or else certain techniques are impossible.

The most obvious example of this is a recursive function which has a local variable. Consider this stupid example:

int recursive(int foo)
{
    if(foo > 100)
        return foo;

    int v = 5;
    if(foo & 1)
        v += 2;
    v += recursive(foo+1);

    return v;
}

Without scope... 'v' would be accessible everywhere in the program. This implies that 'v' is global. In which case the above code won't work, as each call to 'recursive' would trash the previous call's value for 'v'.

Or if you still want to maintain that each call to recursive has it's own value for 'v'... then how can you access 'v' from outside the function? You can't just say recursive.v ... because which of the potentially hundreds of different 'v's are you trying to access?


This problem gets even worse when you consider multithreading.

[LB]

@Disch I though functional languages did not have local variables? Certainly there are no local variables when defining functions in math...?

[Disch]

Oh durr. Nevermind. I thought he was talking about C++. That's what I get for skimming.