

RTML - The templating language created by pg - IsaacSchlueter
http://developer.yahoo.com/stores/V1/rtml.html

======
henning
1\. Create a Lisp-based or Lisp-like markup language. Users: "wtf, my eyes".

2\. Add isomorphic whitespace and linebreaks that can be easily converted into
the original s-expressions. Users: "golly, that's neat!"

~~~
silentbicycle
See also: <http://www.ai.mit.edu/projects/dynlangs/ll1/shriram-talk.pdf>

"Stupid Parenthetical Syntax" vs. "Smart Parenthetical Syntax"

------
dshah
What I find interesting is how many people independently arrived upon this
"put logic in markup" approach to building customizable web applications.

Allaire had a fair amount of success with this with ColdFusion.

~~~
cturner
Unfortunately when you ty to find a system that is pure in separating logic
from presentation you run into a situation of needing to have a logic core
with no user interface assumptions wrapped by an interface filter. Building a
simple implementation of this is not too hard, but doing it in a way that
gives you the sorts of flexibility that will allow you to build something your
users are happy with is very complicated.

I have an idea that such a thing is possible and have been working on just
such a project for several years, but it's non-trivial, and I don't know of
anyone having achieved it so far.

There are lots of systems that claim to separate UI from logic but which are
in fact innundated with assumptions about state transitions. At some level,
every system I've seen assumes a binding between GUI and application logic,
even if it's not as obvious as in this case.

~~~
baltoo
Isn't a fundamental problem that form is function? With that I mean that in
the end the form of the UI is part of it's function. So are other parts, e.g.
"content" is part of the UI's function as well.

This would imply that there's no true dichtomy between logic and presentation
as such, but rather different types of functionality. Just as there are very
seldom any bulk-heads between different types of a whole's functionality in
general, I think it would be impossible to truly separate logic and
presentation. (Not that some separation cannot go a long way.)

In the end we cannot escape presentation at any stage of the design of a
system. If not anything else we have an internal presentation for the internal
representation of the external problem. This alone makes us design things
assuming much about the form. Is there even such a thing as representation
without presentation? With that I again mean that presentation is a
fundamental and non-separable part of any thing we handle.

I'm sorry if this comes across as mumbling. I've troubles expressing these
thoughts clearly. Guess I don't understand them well enough..

~~~
cturner
It was me that set it off on a theoretical track. Thanks for your interest -
no mumbling in sight :)

    
    
        Isn't a fundamental problem that form is function?
        With that I mean that in the end the form of the UI
        is part of it's function. So are other parts, e.g.
        "content" is part of the UI's function as well.
    

I agree on the issue of form and function being actually the same. And in this
sense, I think that blatantly mixing markup and code is a kind of honesty.

However, I think there is an important contrast between logic and presentation
from the perspective of the system. Generally, we don't care too much what a
user does with their user interface. If it crashes or displays something weird
this is unpleasant and undesirable but unlikely to be more significant than
that. A layer back from that, what happens in the application itself is
certainly important but not critical - if it approves a transaction at a
wildly wrong price then this is certainly a bad thing, but in an enterprise
application you can often reverse or at least cover position on this before
the close of business. Then a layer back you have a datastore - and if stuff
is in here and wrong it's very unsettling because that's the source of
evidence about the nature of the world your product lives in.

At the moment, we (computing world) commonly protect datastores against
certain sorts of danger by using a relational database with typing and
primary/foreign-key constraints. This is all very nice, but only offers basic
protections on a datatype layer - it is ignorant of your business
circumstances.

The common evolution to achieve greater business integrity is to hide all
communication with the database behind stored procedures. I think the reason
for that is to do with tools and skills - it's easy for banks to hire Oracle
guys who can do this work.

One failure of this is that it's not stateful beyond the state you get with a
database transaction, which for a distributed application needs to be short-
term (ie: not span longer than a few ms if possible). Sometimes you might want
to issue the user with a long-life token that they can use to recall a
position later on. This is 'possible' using stored procedures and database
transactions, but highly impractical [1].

A second failure is that you don't have a nice mechanism for stopping the sort
of bad transactions I talked about before without code and interface logic
getting all confused with one another. Those problems occur often because
programmers will hook interface into the system in ways that are subtlely
wrong. I see this as being a room for improvement.

A third problem is that you end up with a range of inconsistent RPC interfaces
glue into the side of the business logic layer. Once these interfaces are in
it becomes awkward to reform the business logic because everything you do has
RPC consideration. My background is in foreign exchange trading APIs and I've
seen this pattern repeatedly here. But it's equally valid in a situation I
faced when I was consulting where a third party developer was writing a web
frontend to my franchise management system. [2]

What you really need is to be able to defend not just the datastore, but the
business logic of your application space behind an abstraction layer that is
comparable to that which we get on the datastore layer with the patterns of
tables, operations and short-lived transactions. The goals of this pattern
include (1) ensuring that nothing bad gets in; (2) support for concurrent
long-life transactions things can be done in certain ordered steps; (3)
supporting a programming team role for someone who is focussed on the business
logic and has no interface considerations beyond the logic layer's facade
patterns.

The pattern I'm talking about is actually somewhat similar to a text
adventure, where the application presents you with a common interface, and
track your state as you proceed through it using a limited syntax.

After implementing the first version of this pattern I discovered a really
neat side-effect: it becomes trivial to write a dumb interface layer that
automatically creates blunt user interfaces from the logic presentation that
are suitable to present to users. [3] Shortly after that I wrote a simple
syntax that allowed me to define unit tests before writing any application on
it.

I've finally managed to develop most of what I'm talking about above after
three years and at least four rewrites. The most recent version is in python
and actually took only a day to implement from nothing. Building apps on it is
pretty straight forward - I built a simple expert system in it in twenty
minutes the last time I played with it, and then automatically had multiple
user interfaces to it (web html, command-line, WSDL, unit-test, etc). However,
I'd like to improve the mechanisms used to easily bind user interfaces to the
system before I start to invest energy in attracting a community and other
programmers.

If you have any further thoughts about this or even whether my explanation
makes sense I'd be interested to hear. Thanks.

\--

[1] You can't just give them the id of a table and maintain validity, because
when it came back in you'd then need to vet it to make sure it was one they
should be dealing with). In my own attempts to build logic layer platforms I
call this sort of token a 'reference'. The reference is mapped to an actual
object (or table id or whatever) within something like a stateful session bean
on the server side where integrity can be trusted.

[2] In much the same way that tools like Toad can inspect and allow you to
interact with numerous relational databases of varying structure.

[3] In the early meetings they were fans of just writing directly into our
database. No thanks - don't really want to be supporting the consequences of
two systems created by different programming teams depending on the same
database. However - an arrangement like that with stored procedures is common
in the enterprise. This has huge consequences for interlocking the design of
the applications that interact with the datastore, and creates larger
depenence on key staff.

------
jwilliams
I often wonder if many of the struggles with HTML/CSS and standards would be
alleviated by a strong macro language for markup.

In fact, whenever I touch CSS I often wish it was more like a macro language.

~~~
jonknee
I think the struggles are almost all related to the rendering differences in
browsers. That's what makes it (especially CSS) such a pain in the ass.

------
dkd
Was that written by Paul Graham or by Robert T. Morris?

~~~
jsmcgd
If I remember correctly it was mainly written by PG and named after RTM.

