[Prev][Next][Index][Thread]

Re: Dylan's direction



Andreas Bogk wrote:

> Rob Myers <robm@lostwax.com> writes:
>
> > >  I personally like
> > > the idea of dylan becoming an important web technology. Other
> > > languages like java, javascript, perl, python, etc. have enjoyed
> > > much success lately mostly due to their web tie-ins.
> > The web market is over-crowded, and the major players are well-established.
>
> Right. But there's a weak spot in all of the available products
> (except WebObjects, but that is proprietary): performance. All the
> major products suffer from the fact that their languages are
> interpreted.
>

The performance question is a good one. Compiled dylan should give us
a performance edge, but it would only be compelling if there were some
cool tools which make creating cgis, or dynamic pages a snap. For
instance, I use perl for most of my web projects because it deals with text
better than dylan. I can't figure out a way to translate this perl code:

sub Template {
    local(*FILE);         # filehandle
    local($file);         # file path
    local($HTML);         # HTML data

    $file = $_[0] || bail "Template : No template file specified\n";

    open(FILE, "<$file") || bail "Template : Couldn't open $file : $!\n";
    while (<FILE>) { $HTML .= $_; }
    close(FILE);

    $HTML =~ s/<!-- \$(\w+) -->/${$1}/g;

return $HTML;
}

into a compiled dylan program and still maintain the flexibility I have
with perl. In fact, a lot of these web scripting languages offer the compelling
feature of allowing code to be kept inside HTML template file, which are
much easier to use and manage than large blocks of HTML kept inside
programs. It would be wonderful if we could create a mod_dylan which
would work like mindy, for the quick hack; and also have the compiled
code option for those people who need it.

Other cool features which would make dylan a very cool web technology
would be threads support, with access to shared memory space
to speed up dynamic page generation. Automatic state objects generated
to track sessions and such. A parser for HTML to create HTML dylan
objects which can then be played with by the programmer.

A suggestion from Dick Kreutzer, which I liked was

   "I would also like to see Dylan as a distributed
   object tool.  It would be great to be able to operate on remote
   objects transparently, just as though they were local.

   I would also like to see a JIT compilation technology which would
   allow one to send/receive methods as easily as data.  It is too bad
   that the Java VM is not adequate for this purpose, as Dylan could
   ride on the JIT technologies of others if it were."

These are lofty ideas, and I often can dream more than I can do, so others
might chime in on whether any of this seems like dylan's future.

James

> > XML. If we have a socket library, an HTTP library and XML we have the web,
> > XML-RPC and serialization to XML.
>
> Aye. XML is important.
>
> I see the future of Dylan not only in a niche market, but as a
> replacement of C++ and perl in everyday programming. The web just
> happens to be important today, and it happens to be a niche where
> people already are used to using high level languages.
>
> Andreas
>
> --
> "We should be willing to look at the source code we produce not as the
> end product of a more interesting process, but as an artifact in its
> own right. It should look good stuck up on the wall."
>  -- http://www.ftech.net/~honeyg/progstone/progstone.html
Follow-Ups: References: