Lambda the Ultimate

Hello

:r4 is a programing language derived from ColorForth, I start the proyect in 2005.

the code is in google code : http://code.google.com/p/reda4/

the main blog is http://www.reda4.org (in spanish)
or another blog in english is in http://dtedm.blogspot.com/

any feedback is welcome.

Hello,

Basically, I would like to present you yet another programming language.
It is in its early stage. Nevertheless, I would like to know how it is perceived and what you think of it.
All details can be found here:

http://sidewords.jimdo.com/

Any feedback and critique is very welcome.

Not sure if Cybernetics is on topic or off topic for Ltu, but some readers may appreciate the fact that this is a recursive system (ie functional). Viable System Architecture

Awesome blog post by Jonathan Edwards in the novel literary style of mock paper review comments.

Side effects are both the essence and bane of imperative programming. The programmer must carefully coordinate actions to manage their side effects upon each other. Such coordination is complex, error-prone, and fragile. Coherent reaction is a new model of change-driven computation that coordinates effects automatically. State changes trigger events called reactions that in turn change other states. A coherent execution order is one in which each reaction executes before any others that are affected by its changes. A coherent order is discovered iteratively by detecting incoherencies as they occur and backtracking their effects. Unlike alternative solutions, much of the power of imperative programming is retained, as is the common sense notion of mutable state. Automatically coordinating actions lets the programmer express what to do, not when to do it.

Coherence is not a problem of constraint satisfaction — it is a problem of constraint discovery. Previously there have been two alternative solutions: reduce the expressive power of the language so that constraint discovery becomes decidable (as in state machines and dataflow languages), or leave it to the programmer to deal with.

Just for the fun, I wonder if LtU subscribers would like to entertain themselves by thinking about how the olde rhyme about "Butcher, Baker, CandlestickMaker" (BBCM) might map either to or from, say, a design pattern or software idiom (assuming these are not tautologous).

For want of not leading the proposal, I would prefer to refrain from providing the dozen or so examples (usecases in OO-speak) that I have thought of. However to seed the discussion (and hoping the ensuring discussion will generated other seeds) let's consider some hint words like "push", "pull", "factory", "interface", "implementation" and, well, too many leading words already.

So who's up to the game?

apparently Intentional finally shipped.

Martin Fowler's overview.

Download video presentation via MSDN.

Hello,

just started a mailing list about programming language design. Simply because I couldn't find any...
It's called 'PiLuD' ;-)
For anyone interested.

subscribe : pilud+subscribe@googlegroups.com
send mail : pilud@googlegroups.com
home page : http://groups.google.com/group/pilud

You'll find a list of sample topics, only intended to help the list start & live, at
http://groups.google.com/group/pilud/web/topics
Add your own center of interests.

Denis
------
la vita e estrany

On Andrej Bauer's indispensible weblog, he posts On programming language design, which articulates some ideas about the value of safety of inductive data types, type safety, etc. Gains a thumbs up by Robert Harper.

The "LCF approach", as I understand that term, was Milner's insight that allowing proof development solely in terms of a particular type and its operations was a safe way to allow extension of the LCF proof system with ML.

The deBrujin criterion seems to be the same thing -- allowing proven terms to be constructed using only a safe kernel language.

What is the relationship of these two terms? Are they synonymous?