Lambda the Ultimate

Some, admittedly vague, thoughts about programming:

I think programming languages in isolation generally are insufficient to support the (main) goal of programming: reducing complexity and improving obviousness.

The buzzword 'patterns' may point to a fruitful approach whereby programming would consist of enabling (language independent) code/design-patterns found with a search-engine (matching design comments over a pattern library) in combination with 'smart' preprocessors that allow the programmer to add details or improve the patterns. Ideally, the target-language could disappear from sight almost entirely. Maybe a new road to realize the goals of 'literate programming' (with more help from the computer).

This could also be a good way to standardize large-scale projects.

And possibly, this way aspect-oriented programming (http://www.parc.xerox.com/csl/projects/aop/) could become a mainstream technique to compose applications.

(Maybe I'll try to come up with a more mature version of these ideas later)

For simple libraries, this is not a big problem to be language independant, but it can be... and costly too! I may have misunderstood what you're aiming at, but seeing the pb of achieving a nice toolkit binding for haskell, i wonder...

My message was an attempt to allure more people to be contributing editors, that can post directly to the homepage.

This is a pretty complex issue, which is the focus of much research, and merits much more. That's what component programming is all about.

The EJB and the XSLT are relevant, and also worth reading.

You might also enjoy this paper, about patterns and programming languages.

This discussion should really be in its own thread.

When you recognize a pattern, you can import a well rounded and documented template (and that the language is Java is not very important) and go from there. If the template needs considerable change you could decide to improve the template itself instead (including documentation). This template would serve as documentation about the basic structure of the program.

Next step could be to automate finding relevant patterns by using the English documentation as search-argument on a pattern library. This would give the programmer access to tested solutions likely to be relevant in the context.

Next step could be to fill out the template with smaller-scale code templates, so as to minimize ad-hoc exercises in the programming language at hand. Maybe the documentation ultimately could state enough details to allow automatic code generation altogether.

Next step could be to import patterns to integrate other 'concerns' (see aspect oriented programming) like distribution over networks, unit testing, logging, synchronization, security etcetera.

Of course the further you go with automating, the more difficult it is to get it right.

The main idea is to flexibly reuse on the highest level possible, so as to avoid most of the lower-level ad-hoc coding. Ad-hoc code always requires people to 'get into the mind' of the writer, a time-consuming and unreliable process.

ps. the 'patterns and programming languages' paper seems to require a password.

The Bosch article tries to address some key-issues with directly using higher-level patterns, by defining a way to flexibly extend the programming environment with a layered/filtering approach to code generation (in a OO-only context, I must admit). Compare http://trese.cs.utwente.nl (AOP with composition filters).

I'll try to come up with a concept for a separate thread about why patterns should be kept separate from programming languages, even if languages exist that happen to contain support for some patterns.

Currently it seems the best programming environments are for Smalltalk and friends (refarctoring borwser etc.).

Some things are being translocated to other languages. Check this out.