Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

CityScript

Will CityScript grow as CityDesk grows and more features are added? (E.g. there was a post about adding bits of server-side functionality in future releases like discussion forums or mailing list management).

The handful of commands that CityScript has now to accomplish its disciplined and limited functionality are clear and consistent, but will it turn into another full-on web programming language as time goes on?

Is there a VB equivalent of something like Perl's "use Safe" or PHP's "safe mode" to restrict the kind of things people could write. This way, scripting in CityDesk would not requiring learning another language. (I'm m assuming VB is embeddable, but I could be wrong.)

Alternatively, maybe the scripting engine could be abstracted so that different languages could be plugged-in, like how ASP works?

This may be needless grumbling in anticipation of something that won't happen, but it would perhaps be good for CityDesk to avoid the curse of the custom markup language (Perl's n different templating systems, Cold Fusion, Zope, etc.)

David Sklar
Thursday, November 01, 2001

All good questions. It's hard to predict the future. We're open to input.

I guess it depends on how CityDesk develops. If we get a lot of home-users/HTMLers, it's important to keep CityScript as simple as possible.

If we get professional developers, we should allow scripting languages. If we did this, it would be pretty easy to allow plug-in scripting languages like ASP which would get us JScript and VBScript for free.

In either case the existing language is SO simple that mechanical translation will be trivial, so we can pretty much guarantee that your sites will continue to work in future versions.

Joel Spolsky
Thursday, November 01, 2001

If the scripting needs evolve to the appropriate level of complexity, my instinct is that allowing different actual languages ala ASP provides the most benefit to users (as well as the largest possible user base).

Perhaps in this model, the CityDesk internals could be exposed to the particular language as an object model that can be manipulated however is appropriate in that language, so for example the question someone had in another post about optionally printing bylines only when there is something in the author field turns into something like (in perlish syntax):

if ($article->author) {
  print "By $author";
}

So instead of loading CityScript down with iffieldexists() methods, you just rely on the  features of the chosen scripting language.

This interface to the content would also be a nice way to be able to automate operations over the entire set of content in a site, like generating a list of links to all articles by a particular author.

I think that no matter how simple the intended uses of the product are, and how focused the product is on letting Aunt Petunia publish her website about flowers, plenty of users are going to wring every possible bit of functionality out of the scripting in unanticipatedly logic-bending ways. It may be a good strategy/discipline/product development decision to not worry about those users now (or ever). If those users are (or will be) important, however, letting them leverage existing language skills is a big selling point. (Actual or psychological, I'm not sure, perhaps a bit of both.)

David Sklar
Friday, November 02, 2001

*  Recent Topics

*  Fog Creek Home