The most important distinction is between descriptive and prescriptive.

A descriptive language describes the result to be computed and leaves
it up to the compiler to work out how to do it. This is often termed
"lazy" since one simple option for the compiler is to put off
computing things till really needed. Also the semantics of descriptive
languages typically require that nothing bad will happen if an
infinite (or failing) intermediate result is described as long as
there is no need to compute all of it. I think a descriptive language
has to be functional. Haskell is the relevant example.

A prescriptive language describes exactly how a result will be
calculated in a sequence of steps. Erlang is in this category, so it
is much easier for the traditional C/java programmer to get into. .

Scala can swing either way. However currently its libraries are
java-like or erlang-like. There is a wonderful series of blog postings
on how to monadify scala which points the way to writing scala
programs in the descriptive style: http://james-iry.blogspot.com/.

Descriptive style means using monads (or something moderately
equivalent) for interacting with external changing state. The whole
point of these is to restrict the compiler's options for
reorganization. Of course if it was done perfectly it would restrict
as much as necessary but no more. However I suspect that descriptive
compilers are going to have to learn to go through the same
optimization tricks as prescriptive languages to be really efficient
for dealing with monads: i.e. they will have to look at monadic
sequences of operations and say "the author wants these things done in
sequence but I can see that it can be reorganized without loss". I'd
love to hear that I'm wrong on this.

Still the main thing that seems to be relevant to efficiency for web
frameworks is a good system for efficiently fielding a large number of
very small communicating processes, as we see in Erlang and
(partially?) recreated with Scala actors. So a key step to moving to a
more descriptive style would seem to be introduce something like that
to haskell or monadified scala. Not that I am competent to make any
suggestions on how to do that.

The other distinctive "functional" common feature of erlang, haskell
and scala is pattern matching. This make for a nice programming style,
but I'm not sure if there is any deep significance?

Bob

I suspect we're still at the point where simplicity wins - getting
distribution right on the server is more important than what
particular code runs. If performance becomes a problem, then it's
worth writing dirty, but faster, code. The trick is getting to that
point (coding quickly but in a manner where units can be optimized
cleanly later).

Event streams (functional reactive programming) can be treated like
backwards Erlang processes. My view here is biased  so I shouldn't say
much more :) Arrows are largely motivated by them, with the disclaimer
of that's not how I think about streams.

Neelk has a POPL submission this year (draft on his website) for some
proofs about how pattern matching corresponds to proof case statements
(it is intuitively part of the induction), but I mostly use them as
sugar (eg, they're available in PLT Scheme, and I've been known to set
a bang or two).

More on my mind is how to deal with the layers of computation and the
various forms of persistence. Distributed objects have historically
failed, yet apollo / google gears have forced the issue. Do we need
bidirectional programming (harmony), modal types, continuations (plt
server), or what to deal with consistency issues between them? On that
note, do we like the page model w/ the back button - and if so, does
that argue for simpler connections between pages, the continuation
approach, or what? If we want to have a page context sensitive (small
device, flash enabled, for the visually impaired, ...), how do we deal
with that (HaXe? Hop? separate programs..)? Is the rich web app
separated or integrated with the server app? Do we take a Happs-like
approach to in-program memory as well, or allow computation in the DB
(a la CouchDB), ... ? In a reverse note, what about more mashable and
user-oriented programming? How about discretionary access control,
versioning of data, 3d party software, ...

Essentially, what is a web framework supposed to simplify? If you had
X million dollars and the dream team, what would you make?

My laundry list:

- UI heavy experiences (hence, FRPish systems)
- Simple persistence (save, load, map/reduce = CouchDB/S3)
- Simple consistency
- Simple communication w/other apps (think distributed cellphones)
- Simple discretionary security (incl. emails, delegation, and
anonymous capabilities)
- Support for slashdot effect and other context-sensitive
transformations
- Automated testing (concolic tester for browser incompatibilities?)
- Url, Back button support
- Web service consumption and generation (w/versioning)
- Data centric program analyses, page structure centric analyses
- User's data integrity, confidentiality wrt the server
- Analytics

And don't forget.. we may need to run this all on many-cores or cells
or whatnot. If parallel browser functionality is exposed (more like
when), would we be ready to take advantage of it?

Web apps encapsulate some of the hardest PL, SE topics I know. I don't
think we've hit the sweet spot for how to distribute DSLs (do we need
just one, or many, and if so, for what?) - I'm still stuck on what
we're trying to express, let alone how to type it for correctness or
particular compiler transformations. A lot of it can probably be
answered with libraries (we hacked out a bunch way too quickly for
flapjax) at this stage - but rich security models, (distributed)
persistence, distributed computing issues, and the sorts of program
analyses we want are big question marks to me, and that coupled with
flexible delivery / target platforms/environments make language
support seem vital to manage the complexity. The forest is too blurry
for me to find the trees :)

This is an open-ended response to an open-ended question, but these
are all things I've spent way too much time thinking about in the past
couple of years and am just becoming more puzzled by.

On Nov 15, 6:53 am, leo <lmeye...@gmail.com> wrote:

I'm quite partial to the web-calculus:

http://www.waterken.com/dev/Web/

It specifies and motivates many of the features that you've mentioned
above in a simple, general framework reminiscent of a distributed
lambda calculus. Many of its design features were motivated by the Joe-
E and E capability secure languages such as capability URLs, promises/
futures and message pipelining.

Sandro