Lambda the Ultimate

In the process of working on the mechanics of my pet language design something just occurred to me: is "trampolining" as is normally done for tail-recursion, etc., just a poor-man's version of calling continuations?

Just a thought.

This is about to put a definition/description to test. So please cooperate!
;)
Is this a useful – sufficient, not complete – definition/description for a
monad; for an imperative mind: (?)

"A monad is like a loop that can run a new function against it's variable in
each iteration."

(I insist on the simplicity! And I will resist any expansion of this
sentence (except for an exceptional note that I think of it hardly).
I think there is not any complete definitions in computer world. At least
there are many things to know when you want to use them in practice. So
please have this in mind and review me!)

Cheers :)

Note:
This is not correct in the context of Haskell. (Alexis Hazell mentioned it on haskell-cafe to me)

But I meant in (for instance) the context of C# , for a C# programmer,
who have not any Haskell knowledge.

Jedi aims to bring a more functional style of programming to Java. It does so by providing a library of routines for filtering, iteration, conversion from one collection type to another, first order logic functions, etc. It makes extensive use of higher order functions and closures. Unlike most libraries with similar aims, Jedi tries to take the hard work out of producing the required closures by providing JDK 1.5 annotations which generates the necessary filters, commands and functors.

Jedi has been used on a number of commercial applications and has been found to significantly simplify the code.

Saeed Dehnadi and Richard Bornat describe a test for programming aptitude:

Learning to program is notoriously difficult. A substantial minority of students fails in every introductory programming course in every UK university. Despite heroic academic effort, the proportion has increased rather than decreased over the years. Despite a great deal of research into teaching methods and student responses, we have no idea of the cause.

It has long been suspected that some people have a natural aptitude for programming, but until now there has been no psychological test which could detect it. Programming ability is not known to be correlated with age, with sex, or with educational attainment; nor has it been found to be correlated with any of the aptitudes measured in conventional intelligence or problem-solving-ability tests.

We have found a test for programming aptitude, of which we give details. We can predict success or failure even before students have had any contact with any programming language with very high accuracy, and by testing with the same instrument after a few weeks of exposure, with extreme accuracy. We present experimental evidence to support our claim. We point out that programming teaching is useless for those who are bound to fail and pointless for those who are certain to succeed.

Based on their experience, there are essentially three groups in an introductory programming class, those who want to learn more faster, those who manage to pass and those who still have no idea what programming is all about once the course is completed. It seems it is not the teachers fault either,or as they put it:

The cause isn't to be found in inappropriate teaching materials or methods either. Essentially, the computer science community has tried everything (see section 2) and nothing works. Graphics, artificial intelligence, logic programming languages, OOP, C, C++, PROLOG, Miranda: you name it, we've tried it. We've tried conventional teaching, lab-based learning by discovery and remedial classes. We've tried enthusiasm and cold-eyed logical clarity. Nothing makes a difference. Even the UK's attempt in the 1980s to teach the whole UK population to program on the BBC Micro ran into the sand.

Food for thought.

As I understand, quite a few of usual LtU readers do Java programming on a daily basis.
JBoss Seam (not Seam VM) seems quite popular lately (more than for a year already) in Java "enterprisish" community.

Could we try and critisise Seam from PLT point of view? Can it be considered a PL? If yes, of what paradigm? Is it a DSL? What existing formalisms can be used to model Seam? What conclusions will follow (unsaveable, perfect, needs this and that changes to become more uniform/consistent)?

Comprehensive Comprehensions, Phil Wadler and Simon Peyton Jones

"The new constructs proposed here are more general than the constructs in the other languages, because they work with any function of a given type, rather than being limited to specific functions. Parametricity of these functions plays an important role in ensuring the semantics of such constructs is independent of particular details of how tuples of bindings are represented."

Its somewhat surreal where everything is heading now. Microsoft has been developing a new language called X#. Can you guess what it is? Read about it here. Microsoft has just reincarnated LISP and soon will singlehandedly attempt to take over the programming world.

I suppose it was only a matter of time before Microsoft used XML as a language that allows functional definition of data, is perfect for OS and system neutrality (that one outdoes Java), and can be used as an AST, which means it could be syntax-rendered on screen as anybody's favorite programming language.

Bye,bye javascript/HTML/CSS complex, hello XML browser!

It will be intriguing to see what this new era brings for programming.

An interesting item; perhaps a bit off-topic.

W. Bradford Paley (an interaction designer at Columbia) and a few collaborators have produced a "map of science"--basically segmenting the realm of science into over 700 sub-disciplines based on an affinity graph produced from surveying over 800,000 papers, and who cites whom. Cross-discipline "links" are noted, as are keywords common to each disciplien. Also noted are various terms of art used in each discipline, which are common among the papers found therein.

Paper is here

Other than a coarse assignment of research fields to top-level disciplines (i.e. "computer science", "biology"), no attempt is made to name the disciplines--they are identified only by their "keywords". Though there is one bubble which obviously corresponds to PLT...

Volta is exploring innovation that empowers programmers to delay decisions about tier-splitting to the last possible responsible moment by using either code refactoring or declarative annotations.

Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 1 [Channel 9 Video, 25 minutes]

Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 2 [Channel 9 Video, 32 minutes]

LINQ 2.0: Democratizing the Cloud (pdf)

In OOP many times I encountered a bad structured code; just because of absence of a good recommendation on it. This is asking about one of them.
So Is this a valid/useful recommendation in OOP:
[Methods must not instantiate objects of other classes (at least the classes in the same "sub-system"); but they must be declared as fields.]
(Because using objects directly in methods - not as fields - will break useful definition path of OO things. Of course this may be an old quota; but recently I saw many codes that violates this and if this is important how can we enforce it?)