Fog Creek Software
Discussion Board


I have a question about the design of CityDesk ... it's very clear that you tried to leverage the components that Microsoft provides as part of their platform.  What I was wondering was if you ever considered embedding VBA into CityDesk instead of building your own CityScript language?  My thoughts on why you chose the approach you did: (1) only needed a simple language for the features you wanted to provide (2) licensing costs.  On the other hand, VBA might have given you some extensibility that would come in handy (like the ability to create your own placeholders). Just curious ...

Mike Sennett
Thursday, November 29, 2001

This question is particularly interesting because of Joel's history with VBA.

I've read Joel's justification for using VBA rather than developing a new language.  So what is different about Citydesk?

Perhaps Windows Scripting Host rather than VBA - Web publishers would be more familiar with the VBScript used in ASP pages.

Ged Byrne
Thursday, November 29, 2001

I can't comment specifically on VBA, but MS doesn't license it directly.  Two other companies actually license VBA out to people to use.  While I can't go into specifics of the costs of VBA (you have to sign an NDA to get the specifics), lets just say its expensive.  More expensive then a $349 dollar professional tool could swing.  But if you want the ultimate in flexibility, it is well worth the costs.

As for why they didn't use VBScript, I can only guess that depending on which version of Windows and/or IE version you have, is which version of VBScript you get.

With CityScript, they know exactly what they have.  I guess this goes back to his article on "Not Invented Here".


Justin Rudd
Thursday, November 29, 2001

OK, here's the answer.

When I was designing VBA for Excel, I spent a large portion of my life thinking about how to express common operations in the syntax of different languages.

For example, a common operation in an Excel macro might be to change the value of a cell.

Now, you really want to write something like

A1 = "23"

where A1 is the cell. If your scripting language is, say, C, you can't do that without modifying the C compiler. In C you would probably have to do something like


Of course cells can also have strings in them, so you need another function for setting a string. (Remember, this is C - no overloading.)


Not very natural. I beat up the Visual Basic compiler people until we convinced them to add some features to the language that would make VB a better macro language for Excel. Some of the features I insisted on were:

* A variant data type, so we have a type for the value of a cell.
* Syntactic sugar where you could write [string] in the code which would be evalutated by the compiler as Evaluate("String") and we could implement Evaluate any way we wanted. This let you do [a1].value = 34. The Access guys (Adam Bosworth) had separately insisted on getting default properties so you could even do [a1] = 34.
* For Each, since you're always doing things like looping over rows in Excel macros. I don't think I had seen for each elsewhere in a popular programming language but I probably got the idea from csh.
* With blocks, stolen from Pascal, because you often end up changing a bunch of properties of the same object in a row.

OK, back to CityScript. Before choosing a scripting language for CityDesk you have to think of what kind of operations you do commonly, and how to express them. Most of the existing scripting languages do not really have elegant ways to express the kind of complicated conditional clauses which CityScript requires, and which eventually need to generate SQL WHERE clauses. That's why embedded SQL became so popular.

Another thing to think of, of course, is the target audience. The target audience for CityDesk scripting is HTMLers, not programmers. I'm thinking of the kind of HTMLers who understand tags and stuff, but just don't really understand programming and can't be bothered to learn. We had to have a scripting system that was simple enough for HTMLers.

So for the first version of CityDesk, we came up with our own very lightweight "scripting" language which really doesn't have any programming constructs at all. This has some nice advantages. Since the language is so simple, it can mechanically be transformed. We're working hard on coming up with a good GUI way to represent everything you see in CityScript. This is much easier since we don't have variables, expressions, if clauses, etc. It's just a few tags.

I have a lot of experience incorporating scripting languages into applications -- I put VBScript into Juno and VBA into Excel -- and I can tell you that writing a compiler from scratch for our dinky language was much easier. Babak knocked it off in a week or so, using C++ for performance.

But we definitely know that there will be a CityDesk consituency that wants power programming features. It makes sense. One of the things on our Huge List of Features That We'll Never Have Time For, in fact, pretty high up on that list, is to allow for pluggable scripting engines into CityDesk, alongside CityScript, for advanced users.

Joel Spolsky
Thursday, November 29, 2001

The 'Dinky' compiler was knocked out in 'A week or so' in C ++.

Your certainly not exagerating about the quality of your programmers.

Ged Byrne
Friday, November 30, 2001

> Your certainly not exagerating about the quality of your
> programmers.

A small compiler like CityDesk's one is not too difficult to implement. The fact it took a week to complete implies that they have a strong and well designed base, not necessarily (sp?) a good programmer (though that Babak guy used to work in some absolutely amazing places. Btw, I remember a page about the FogCreek crew, but I can't find it anymore)

Leonardo Herrera
Saturday, December 1, 2001

Monday, February 4, 2002

*  Recent Topics

*  Fog Creek Home