RE: Curl

["Christopher Barber" <address@hidden>]

> Quite interesting, lots of great lisp features, it looks like a cross
> between scheme and dylan syntax with gratuitous replacement of ()'s with
> {}'s, to appease the C/Java programmers I guess.

It is not gratuitous.  Curly braces were choosen over parens because they do
not occur normally in most written text.  This makes it a better syntax for
embedding code within text without requiring annoying escapes.  However, I
will admit that consideration of what Java, VB and C++ programmers will
think has had a role in many aspects of the language design.

> However, the pricing structure (developer/content provider pays per KB of
> code run on the clients end, definitely a new way to discourage code bloat
> ...) and the web centric (web only ?) closed nature of the system is
> probably the kiss of death from a developer uptake standpoint, especially
> given flash is already out there with artist friendly tools.

That remains to be seen, but we don't think this will be quite as much of a
problem as you might think.  First, use of it is totally free for
non-commercial use and also costs nothing during application development; we
also make allowances for small companies (less than 500 employees).  Second,
we believe the modest cost of executing Curl content will be more than
offset by the savings on the server side.  Keep in mind that bandwidth is
often payed for in terms of the number of KB's transmitted, so our charges
should simply take the place of money already being paid out by
content-providers.

While it is true that the implementation is not open, we do intend to open
up most of the libraries eventually.  Even so, I don't see why its
closedness would be a barrier to the majority of developers who have no need
or desire to play with their compilers' sources.

It is true that the Curl language is especially geared to web development,
but as language designers we tried to make it as general as possible.  It is
quite easy to use Curl as a scripting or standard application development
language, but it is more interesting as a web-development language because
it fills a missing need, where on the other hand there are already plenty of
excellent languages for scripting and application building.

> I think there
> is a lot to be said for Paul Grahams server side approach if it
> can possibly
> be used as it far easier to develop and maintain across platforms.

Sure, there are big advantages to server side development, but there are
also significant limitations.  For one, if you push as much as possible onto
the server, you are pretty much stuck with (X)HTML on the client and the
lame user-interactions that are the hallmark of most of the WWW.
Furthermore, client-server interactions are fundamentally limited by network
bandwidth and latency.  Bandwidth, while it is much cheaper than it used to
be, remains expensive: most households still do not have high-bandwidth
internet connections, and server providers must pay real money for the
bandwidth required for their service to scale.  Latency has not improved at
the same rate as bandwidth and CPU speed and is fundamentally limited by the
speed of light; meanwhile the price/power ratio for client-side machines is
improving at a faster rate than for server-side machines.  The end result is
that client-side content is cheaper and more scalable than server side
content if you can figure out how to manage the content configuration and
versioning issues.

For these reasons, sooner or later client-side languages are going to be
much more prevalent than they are now.  The question is whether those
languages will be provided entirely by Microsoft.

> Anyhow this is getting away from language design so I should stop now.

A little bit, but for those of us working on commercial languages, business
issues are intextricably entwined in the language design.

- Christopher