Related articles |
---|
build simple web script language spidere800@gmail.com (Mohamed IBrahim) (2011-08-12) |
Re: build simple web script language gene.ressler@gmail.com (Gene) (2011-08-13) |
From: | Gene <gene.ressler@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sat, 13 Aug 2011 09:23:56 -0700 (PDT) |
Organization: | Compilers Central |
References: | 11-08-016 |
Keywords: | interpreter |
Posted-Date: | 14 Aug 2011 20:28:55 EDT |
On Aug 12, 3:22 pm, Mohamed IBrahim <spidere...@gmail.com> wrote:
> Welcome all
> I have a simple question that I want to design a simple programming
> language that works to build Web applications as a kind of simple
> types of exercises on the design and programming languages b b Mufsrat
> Can anyone give me some tips or resources that may contribute to
> I want her simple to the largest extent possible
> Greetings
> [The usual advice to people who want to build a scripting language is
> Don't Do That. We already have too many of them. -John]
I agree with John that there is no more room for a scripting language
that tries to be all things.
However there is tremendous opportunity in organizing a programming
language around abstracting away the grungy problems of writing good
interactive GUIs, especially server side applications talking to web
clients. Web frameworks like Rails and Django do chunks of this with
APIs. But it's still not quite right. GUI-builder envirotnments take
care of other problems, but they run out of gas just when you need
themmost.
At the heart is that it's simple and intuitive to write user
interaction loops:
loop
decide what to show the user next
show the user some information and ask some questions
receive a response
process the response
end loop
But using a general purpose language, this essential logic tends to
get badly lost. In general the loop isn't explicitly visible at all
because code is run once per response, and state between iterations
must be maintained explicitly in so-called "sessions". This is a
completely non-intuitive and broken abstraction IMO. All the things
ever written and taught about global variables being dangerous come to
life in this context. There is the assumed block of effectively
global storage in the session.
There was a project aimed at the web app part of this issue some time
back. It was called bigwig. They compiled a rather elegant little
language into C / CGI code. In bigwig you could write an interaction
loop very much like the above one with Pascal-like syntax, and
variable scope. The compiler would take care of all grungy parts of
preserving variables in session storage and many other details.
Unfortunately the project switched to a different model with jwig,
based on extending Java. It's easy to understand why the did it, but
many of the cool ideas of Bigwig got lost in translation IMO.
In the modern context, a bigwig-style back end could be juggling all
the nonsense necessary for AJAX to work, browswer compatibility, etc.
It could be implemented as an interpeter built in an Apache module.
... or maybe there are systems out there that already do this and I
just haven't seen them.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.