Warp wrote:

>   Structured programming is more related to principles related to the
> control flow of the program, ie. related to control structures (such as
> conditionals, switch-blocks and different types of loops). It's a kind
> of subset of the more general procedural programming paradigm.
> 
>   I don't think the concept of "module" is part of the structured
> programming paradigm. A modular programming language may follow the
> principles of structured programming (and make its own additions), but
> that doesn't mean it's the same in the other way. And I don't think
> there's any requirement for a modular language to use structured programming
> principles (in the same way as an OOP language doesn't necessarily have
> to follow procedural programming principles).

My take on it is that BASIC [the *original* language] was an 
unstructured language - the entire program is basically a vast list of 
mostly sequential commands. And then we have Pascal, which is a 
structured programming language. It has user-defined data structures, 
subroutines and local variables. Things are more "structured".

As to whether modularity is orthogonal or not... I hadn't really thought 
about it.

>> (Actually, I've heard legend of another functional language where 
>> apparently modules *do* have inheritance... There are often debates 
>> about whether Haskell should do this - with most people agreeing the 
>> vast increase in complexity isn't worth it.)
> 
>   I have never understood why adding *optional* features, which you are
> in no way forced to use, to something would make it "too complex".

Well, take multiple inheritance for example. If your language supports 
multiple inheritance, it can't support using the "super" keyword, 
because it could refer to several different classes. (With single 
inheritance, it is obviously quite unambiguous.) So even if you never 
ever actually use MI, if the language your using supports it, it stops 
you from being able to have a super keyword to use. You'll have to refer 
to superclasses some other way.

It's a minor increase in complexity, but it's an example of how even if 
you don't use a particular feature, if it's available the language 
design has to cope with it.

>> [Obviously I meant "does Pascal count as modular?"]
> 
>   I don't know enough about Pascal to answer that question. (Is there
> a "standard" Pascal language anyways? I have the impression that each
> compiler company has created their own variant of Pascal, and that there's
> no official standard. I may perfectly be wrong, of course.)

Well, there are many dialects of BASIC. [And I'm not talking about VB, 
I'm talking about the *real*, unstructured BASIC.] Each one has its own 
little quirks, but you can still make general statements about BASIC 
overall.

>> Dynamic binding? Sure. That's the entire purpose.
> 
>> Inheritance? Mmm, not really, no.
> 
>   That's a bit contradictory given that dynamic binding (or its
> alternative, delegation) is inherently related to inheritance.

Dynamic binding just means choosing between several possible method 
implementation at runtime rather than compile time depending on the type 
of a particular value. You don't actually need inheritance for that.

[For example, in Haskell the "+" function has several implementations - 
for integers, doubles, ratios, and any user-defined types you care to 
add. When you add two values, it needs to pick the correct one. Often 
this can be done at compile-time, if the types are known. Otherwise it 
must happen at runtime...]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message