Lambda the Ultimate

"It is much easier to alter or delete lines of code than to add them."

Therefore, use large examples with possibly superfluous features that can be cut out.

>....you can capture an idiom or pattern using high order functions.

Languages like Haskell and SML seem to converge on the best way to do things because programs are treated as proofs. So theft...or re-use by editor or template doesn't diverge in a large scattered mess of ad-hoc hacks. (example: Prior Ltu topic: Generic Programming in Haskell)

Components seem to be a nice ideal, but which component system (CORBA , COM , Java Beans ?) and what about all the the code overhead? What-you-want-to-do always seems to be buried in mounds of COM , CORBA , interface code (I admit I don't know a lot about this...and it seems that it will change with .NET which seems to hide all the COM interface code). In highly ordered computing environments with a budget large enough to be always trying out the newest things, components must be great.

I've worked as a "consultant" in the proprietary software world for years (accounting systems for large corporations....I admit this isn't the most sophisticated programming environment) and it is standard practice to look around , find the closest thing to what you have to do , and then make the minimal amount of changes to make it do what it has to do. The client is paying the rather expensive license and maintenance fees for the software so they are paying for the right to use this approach and they also want to minimize billed consultant hours, so it is natural to use the approach in this context, the context of consulting with proprietary software on low budget projects.

However, I have also been a graduate student and teaching assistant in computer science and in this environment it was imperative that the student did their own work. Otherwise.....(knowledge-acquisition = 0) ==> F !

Since open source software isn't relying on license or maintenance fees , free and open borrowing and sharing between different packages would seem to be only limited by.........what?

Components seem to be a nice ideal, but which component system (CORBA , COM , Java Beans ?)

I wasn't talking about components in this sense, only of the much more general ideal notion of software lego. Indeed, my point was the I think current technologies are problematic. I'd love to hear interesting proposals...

in this environment [CS education] it was imperative that the student did their own work. Otherwise.....(knowledge-acquisition = 0) ==> F !

I don't agree. It is a bit difficult to seperate what can be reused from what students have to code for themselves, but it is certainly doable. I encourage my SE students to reuse code, and even suggest libraries I find useful, or appropriate - but I explain how this differs from cheating. Naturally, you can't reuse a sort routine when asked to code one according to an algorithm from class, but from that point on, I'd take point off for coding such a routine from scratch every time it is needed.

In my experience, the best reusers are usually the best students overall.

> One must notice that Scheme is very advanced in its control 
> features, and data manipulation tools (supported by GC), but the 
> Scheme standard is fairly silent about SE related features like 
> modules, functors etc. One mustn't conclude that such features are 
> inessential.

Actually, you could very nearly make that conclusion. The basic power of the components of Scheme (lexical scoping, first-class higher-order functions, latent-typing, hygienic macros) make such constructs *nearly* irrelevant.

I say nearly because virtually every Scheme has *some* kind of module system implementation. But functors *are* unecessary because every Scheme function is potentially a functor as a direct consequence of Scheme's HO functions and the type-system. The same is true of modules although there is room to add value in the management of the global namespace.

The crucial part, I agree, related to namespace management. I'd prefer to cover this under the headings of data abstraction, and information hiding mechanisms.

BTW, notice the generic units in Ada can be parametrized by various types of datas (values, routines, types and other modules). All these kinds of data are used for various purposes, making generic units different than HOF. Notice I am saying "different" and not "better". I suggest that if you are not familiar with these programming techniques, that you explore them. They are interesting in their own right. (We mentioned generic programming here several times, but finding interesting examples may be a bit hard).

Some interesting examples concern the use of one moudle as a parameter for another module. A classic example is suuplying a queue or stack to a tree search routine, to achieve either BFS or DFS.

The crucial part, I agree, related to namespace management. I'd prefer to cover this under the headings of data abstraction, and information hiding mechanisms.

Many people seem to disagree with me but I think the crucial aspect of modules is not namespace management but datatype abstraction. I think namespace management is purely a syntax issue. Using name-hiding, etc. to enforce modularity is a poor substitute for type-theoretic solutions and reveals a defect in the language.

(Certainly namespace management and datatype abstraction work well together and, in practice, you probably need the former to use the latter effectively. But they are separate concerns, and intertwining them makes the language more difficult to reason about.)

Of course, for Scheme this is not an issue, because Schemers take it as axiomatic that typing should be dynamic, but if you buy my line of reasoning above then, since in practice Scheme modules are implemented as language extensions, you might conclude that either a) the Scheme macro system needs to be extended because it can't adequately treat namespaces, or b) dynamic typing should not be taken as an axiom. :)

......I'd prefer to cover this under the headings of data abstraction, and information hiding mechanisms.

For component-based re-use what about David Espinosa's "Semantic Lego" (Scheme)? His work describes "programming languages as abstract data types. This point of view is graceful and hasn't had impact it deserves (although it's twenty years old). It shows that there needn't be a difference between 'metalinguistic abstraction' (in Abelson and Sussman's sense) and ordinary abstraction and that new syntax isn't necessary to build new languages."

Modular interpreters defined with the help of monads and denotational semantics.

Papers and thesis (lots of Scheme code):

Modular Interpreters Bibliography:
http://library.readscheme.org/page7.html#mod-interps

Author's Homepage:
http://www.swiss.ai.mit.edu/~dae/

The idea of programming languages as abstract data types is quite similar to my own ideas, so I'll have to explore the links you gave.

I agree. That's why I chose the terms I did, instead of namespace management.