[cap-talk] Potting the web-calculus in a paragraph

[Ian G]

Hi Sandro,

Sandro Magi wrote:
> There is no need to learn the lambda calculus if you don't want to. The
> web-calculus is based on two very common features found in many
> programming languages: closures and reflection.
> 
> HTTP GET: return a description of the referenced interface (which should
> explain why it must be idempotent)

When you say "must be" I see that as "naturally
is" unless there is some notion within this
system that an object might upgrade its interface
from time to time.

> HTTP POST: invoke the referenced closure

And in terms of idempotency, this lacks any
support or pretence at it, which means that the
app must supply own idempotency protection if
desired.  Is that right?

But, fundamentally, separating these two things
on the basis of their idempotency is to miss the
point.  One returns the interface as a lookup,
and the other invokes.  They are completely
separate operations, semantically.

(So my earlier characterisation as get/set would
be innacurate.)

> If you don't know what a closure is, it is more or less equivalent to an
> object.
> 
> "objects as closures"
> http://www.google.com/search?q=objects%20as%20closures&ie=UTF-8&oe=UTF-8

Yes, that did indeed strike me when I read about
closures.  The big difference here being - correct
me if I'm wrong - that a closure only has one
method whereas an object has many?

(I suppose at some theoretical level objects and
closures would be equivalent if the first argument
is the method name.  But at a practical level, an
object implemented as a closure would be somewhat
hard to explain in terms of interface, as the
method name is now data.)

This then leads to the question as to why the
system is implemented as a closure rather than an
object interface?  I suppose this discussion has
been rumbling on since the beginning of OO, but it
does strike that objects won and closures are
somewhat limited in their practical appeal.  That
is, in the code bases I've come across in languages
where both are implemented, Objects are routine and
Closures are limited.

> As for whether the "web-calculus" is an appropriate "marketable name" is
> a completely separate issue from assigning a descriptive technical name
> as Tyler has done. Please, let's not confuse marketing and technical
> documentation.
> 
> RFCs for HTTP, FTP, SMTP, IMAP, etc. all contain "elite" technical
> jargon which implementors use to communicate ideas. These technologies
> also gained popular names, "web server", "e-mail", etc. which have litte
> technical content, yet suit non-technical people just fine. This
> technical terminology does not seem to have hurt the adoption of these
> internet technologies, and I don't see why it would hurt the
> web-calculus. Jargon can easily be learned, it is the usefulness of a
> particular idea/technology that drives its adoption (see "Ruby on Rails"
> for a phenomenon of developers learning a new language simply to use a
> useful web framework).

The term(s) are always an issue, I agree.  Which is why
I proposed my outrageous list of why people hide behind
new lingo.

( The problem I face is that for the most part, the
lingos of new developments do not reward, and I find
this is true in 90% or so cases.  Just some recent
examples: I've recently experienced something called
'agile development' which was forced thru with much verbage
and gusto.  End story: it has been rechristened fragile
development.  Buzzwords like REST, SOAP, webservices
reduce in similar fashion to very simple concepts that
can be explained quickly and either shown to be wrong,
misplaced or incomplete.  Now, some proponents find an
aggressive approach to these new lingos as particularly
rude - whereas what they forget is that they are asking
people to learn an entire new framework, with only a
10% or so chance that the effort will survive.  So I
personally find an economic approach is very apropos:
the onus remains to show why this is valuable, in human
terms. )


> As an aside, I've found that developers using pre-existing frameworks
> generally learn from examples, not explanatory documentation. They copy,
> paste, and extend. This implies they don't much care for the underlying
> foundational ideas, but they do care how closely the programming
> resembles the natural programming of their chosen environment.

Right.  So that's an important observation!  If
there was a desire for adoption, then examples
are the way to go.


> If you find the current explanations of the web-calculus confusing, then
> explain it in a way that makes sense to you. There is no either/or here.
> No doubt there are others who will share your particular viewpoint, and
> your explanation will serve them well as an introduction to the
> web-calculus.

Sure!  So far I see, written in Java terms:

  * a reference to objects made
    available over a URL (encoded as a big number
    that indexes into the object on server side),
  * a mapping that allows method calling over POST,
    including the passing to and return of data,
  * inspection of the interface (in Java terms)
    using a GET.

(I'm guessing that the programmer writes server side
classes that make the appropriate new objects, and
there is some what to acquire the first object ref.)

>>(As a curious footnote to this, apparently lambda-
>>calculus was included in my 4th year denotational
>>semantics unit, but only in passing as part of the
>>functional languages thread.  That of course was
>>many years ago.... and there is this idea of doing
>>FP as "the first computer language to be taught"
>>but I haven't heard that people are particularly
>>impressed with the results where it has been tried.)
> 
> 
> Actually, I recently read some articles on a computer science program
> that taught functional programming as a disciplined introduction to
> object-oriented programming. Companies that hired graduates were
> interviewed and have all been raving that the program produced the best
> crop of programmers to date. Can't find the darn thing now of course...

It would be interesting to see a proper scientific
study done on it.  I'd imagine there is enough data
for it.  At my alma mater the current school head
pushed it through, to the chagrin of some.

(Your observation that FP leads to OO is new to me.)

>>On the other hand a claim that everything can
>>be reduced to functions.  The problem is that
>>it does not really inform us at all, that I can
>>see, especially as we can also reduce everything
>>to other things (gotos, adds, branches... messages,
>>requests/responses, state, ...) and some of those
>>things work better over networks than functions
>>do.
> 
> 
> Mathematics is big on minimalism. The lambda calculus is arguably the
> most minimal universal programming language. Hence all the importance
> placed on it as a foundation for computation. Would you agree that
> simplicity and minimalism are important?

Definately simplicity and minimalism are important,
but they are not necessarily dominating.  The
pendulum of simplicity versus power swings back and
forth;  one of the complaints about Ada was that it
tried to do everything and wasn't consumable enough;
but if you look at Java that puts the lie to
minimalism as a goal.  If you look at the emergence
of different languages and their successes in the
field, it often seems to come down to a battle between
easy initial scripting and large systems complexity.

>>The things I think about when
>>designing protocols have nothing (nix nada) to
>>do with functions.  What they have to do with
>>is messaging and the coordination problem - which
>>I grant is yet another hyperventilating comp sci
>>concept;  but this one is directly involved with
>>each and every protocol, and as I don't see it
>>treated well by the notions presented here, I am
>>suspicious that they are not properly considered.
> 
> 
> Perhaps you would be more interested in other calculi then:
> 
> Calculus of communicating systems:
> http://en.wikipedia.org/wiki/Calculus_of_Communicating_Systems
> 
> Which includes...
> 
> Process calculi:
> http://en.wikipedia.org/wiki/Process_calculi
> 
> Pi-calculus:
> http://en.wikipedia.org/wiki/Pi-calculus


Lots of interesting browsing there.  I did not
see entirely the focus that I would take but I
saw many snippets alluding to it.  Thanks!

My major question then reduces to - how does the
programmer know if the POST has been done?  It
seems to be similar to RPC, in that you only
know if it has been done if it returns OK, all
other states are uncertain.

iang

PS: it is interesting that you mentioned reflection.
In my work, it is "banned" for security reasons!
Just a curious observation of different world views.