Lambda the Ultimate

The problem is: running user scripts on your server. Supposing the Java runtime is in use, you'd like to guarantee:

1. the users code won't blow up the heap and crash every other users scripts.
2. view or alter other users code and data using reflection
3. blow out it's thread with recursion abuse

Java can be made pretty 'safe' using the it's built in sandboxing features (SecurityManager, AccessController, and Classloader) but most all JVM languages out there now (JRuby, Jython, Groovy, ...) are dynamic in nature and nearly impossible to 'secure' in the sense of the three items above:

1. Heap: users can blow up the heap with simple string concatenation
2. Code/variable visibility: these languages don't respect private access modifiers in general, from there you can own the system by accessing whatever classloading architecture the given JVM language implements. Also depend on this to acheive their dynamic natures.
3. Recursion; methods call methods not much to be done about this

So you might suppose a language that disallows reflection and heap allocation might be a good thing in such an environment. Suppose 'new' was not a keyword, and a convention were adopted such as 'declaration is instantiation' then you could generate bytecode that would simulate stack allocation thus protecting the heap. Disallow recursion by embedding some code to examine the call stack for the current method.

Has anyone else considered this use case? Am I talking about Ada here?

What is the state of the art in tool support for looking at a codebase composed of open abstractions extended by independent modules, through a "lens" that allows programmers to see the final inter-dependent code as if all the abstractions were closed?

I'm thinking of this question in the context of ideas like the "Independently Extensible Solutions to the Expression Problem" paper. Open abstractions are great in that you can add new functionality without disturbing an existing, working codebase. The down-side is that open abstractions can end up obscuring the structure and control flow of the program that actually runs. When it comes time to debug a program, or diagnose performance issues, it really helps to view/treat a system as closed.

Coming from a performance-oriented world (real-time rendering, games, and GPU compute), this is a common criticism I hear of virtual functions in C++: you need to know about every possible implementer of a virtual function before you have any idea what actually happens at a call site. You can't even intercept "all calls to this particular virtual function" in your debugger.

It almost seems like there is a correspondence between the per-feature modules introduced in something like the "independently extensible" work, and changelists/patches that are shared in a distributed version control system. Each of these approaches allows a discrete feature to be packaged up, and then applied to a codebase. Sometimes you want to see the codebase in terms of a set of composed features/changes, which can be added/removed/reordered easily, and other times you want to see it as a single crystallized artifact that results from "squashing" a set of changes.

Another workable UI metaphor would be the way that layers work in, e.g., Photoshop. Your primary view of a document is the composition of all the active layers, but you can still target edits toward particular layers, or toggle their visibility.