 Welcome to Emerging Languages Camp 2010, or by Adam Clappalli. So I'm going to be talking about web applications, but I want to start out motivating this with an analogy from popular culture, or at least hopefully popular to people in this room. There's a far side comic strip that involves a man talking to his dog, and he's saying various things in English. Then we see the dog's view of this where all the dog hears is blah, blah, blah, and sometimes the dog's name, but mostly just blah. So I think the way that web applications are usually written today is a lot like that. The web application developer is writing a program that deals with a bunch of the languages that have become parts of the web architecture. And then all this is processed by a compiler or an interpreter for a general purpose language that doesn't have any support for these concepts and just sees everything as strings. And so all the nice things that your compiler or interpreter can do for you when it understands your program, you can't really take advantage of in this setting. So I want to tell you about my programming language, UrWeb, which is a domain-specific language for modern web applications. It has a fancy type system, and to calibrate this, I'd say it's even fancier than Haskell, if you can believe that. And the language has first-class support for the important pieces of web applications, which means that the compiler understands the semantics of these to various degrees. And so the advantages of this include the ability to do strong encapsulation where you can build components that own pieces of your application and protect other pieces from getting in there. And I'll go into a little more detail about that in a moment. And there's also support for metaprogramming where you're doing something like Ruby on real scaffolding where there's a program that will build a piece of your application based on some parameters. And in UrWeb, you can do static type checking of these metaprograms such that if the metaprogram passes the type checker, then it's going to be good in certain senses that I'll also talk about. And these senses include security guarantees such as any UrWeb application that passes the compiler can't suffer from code injection vulnerabilities. So the idea with strong encapsulation is to take sort of motherhood and apple pie ideas from software engineering that probably most of us agree with and then notice that they can really be applied further with better compiler support. So the usual story for strong encapsulation is that you have some functionality, for instance a hash table, that you hide behind a well-defined interface, for instance a dictionary interface. And then when client code wants to access your hash table, this can only be done using a small well-defined set of methods including, for this example, insert and lookup. And it's just not possible to go directly to the private fields of this data structure. You have to go through the interface and at least the traditional story is that the programming language enforces this rule for you. So in UrWeb, you can go further and the private data that your module owns can be things like a table in your SQL database or a cookie that is stored persistently in web browsers. So for this particular example, you can think about building a component that encapsulates the standard logic for doing user authentication on a website. And hidden inside of the component is a table that has the user and pass rate information along with conceptually for every person visiting your website, there's a cookie that stores which user that person is. And we should be able to ask this module, please insert a login form in this part of my web page but we should not be able to from outside the module reach in and screw around directly with the database table or other bad things like that. So the UrWeb compiler lets you treat things like cookies and database tables as first class values that can only be accessed through the language, not through some alternate text-based interface. So you can really enforce this kind of encapsulation. And we'd also like to go further and support the web 2.0 style where you'd like to be able to build a component that in a sense owns a piece of the web page that's been rendered. It owns a subtree of the page structure. So you can think of this being useful for a case like Facebook where you have a bunch of applications written by mutually untrusting users. You'd like to assign part of the page to each of those applications and ensure that none of the other applications can overwrite different applications, part of the page. And in UrWeb, this is supported by taking some ideas from functional reactive programming and the basic idea is that instead of viewing your web page as this big globally mutable variable, we instead view it as a pure function over a small set of data sources or maybe not so small. And when you modify one of these data sources, the runtime system automatically takes responsibility for propagating the consequences of those modifications to the parts of the page that should change. So that's the basic idea of encapsulation. So now let me tell you about metaprogramming. So metaprogramming or code generation is already really popular in the mainstream web frameworks including Ruby on Rails. And the standard example there comes from the Rails scaffolding, which will let you run a command line program and give it a description of a table in your database and then this metaprogram generates a bunch of source code files that provide a standard administrative interface to this table. So this lets you view and modify the contents of this table using HTML forms. And we can get fancier than this. For instance, here is an example of something implemented with UrWeb. It's an in-browser spreadsheet where the idea is that we see a grid here which is backed by a concrete SQL table. And some of the columns in this grid are pulled directly out of the columns of that table. Some of them are computed from the primary columns just like in Excel. And we can do things like filtering and sorting and so on. And we definitely don't want to have to implement something like this from scratch for every new database table we'd like to present this way. So it's very helpful to be able to build a metaprogram that encapsulates this idea and can be called with different parameters for different tables. So the way that UrWeb supports this is based on ideas from the type system world. So most statically typed languages can be thought of as having two parts. Compile time part and a runtime part, where we usually call the compile time part the type system. And usually the runtime part is turned complete and the compile time part isn't anywhere close to that. It barely even looks like a programming language. But in UrWeb, the type system really does look like a programming language. It's like a little functional programming language, kind of lambda calculus at the level of types. So you can use types to express some pretty interesting relationships between the inputs and outputs of functions. So the way that this works is that you build one of these metaprograms as a function from some set of metadata that's appropriate for the different tweaks that are possible. And the metaprogram then outputs some code, which you can take as a sub web of the overall web of your application. And then you have to describe this metaprogram with a type. This is actually sort of a type level program that as its input takes in the type of the metadata and then computes with that and then outputs the type of the application piece that has been generated. So for instance, the input metadata could be the columns of your SQL table. And then the type of that metadata is reflected as some type that stands for a set of columns and their associated types. Then we output the interface of a piece of the application. And so the way this is implemented in UrWeb, there are two important properties. The first one is that this is a pretty expressive type system. Whenever a metaprogram manages to type check in this setting, you get guaranteed that it's well behaved in some useful senses. Including no matter which inputs you feed it, the code that comes out is not going to be susceptible to code injection vulnerabilities. There can't be any dangling links within the application. A form has to agree on the number and names and types of its fields with the handler of the form and so on. Some sort of basic sanity properties for web applications. And this is only useful because we have this second property that it's possible to build a pretty effective static checker for this type system that does most of the work of inferring types and verifying that your metaprogram is really following the contract that you're claiming. So here's an example of a small program that uses a library that provides a sort of work alike for that standard rail scaffolding. I'm not showing you the code for the library itself because that's a little more complicated and I don't have time for that. But this is just an invocation of the library for a particular table. So at the start of this code at the bottom here, there's a table declaration which is using some syntax that's built into Irweb for defining an SQL table by giving a mapping from its column names to their types. And then down below that, there's a call to this library component called crud.make in this case. We're passing it three arguments, they're given names here. The first one is tab is an argument saying which table we'd like to build and add an interface for. We pass a string that just appear at the top of the page. And finally the interesting part is this last argument called calls, which is a record of metadata values. Where for each one of the columns of our database table, we give a little package that describes how input and output should be handled for that column. And in this example, I'm calling functions from the crud library like crud.int and so on that gives standard handlers for the primitive types. But you can also build your own custom handlers that do all sorts of things with input and output while still being subject to constraints that prevent one bad metadata handler from wrecking the whole application. So that static checking that I was just talking about is one of the nice properties that you get with the statically typed language as opposed to the dynamic languages. Another thing is that you can get higher performance. This is one of the standard arguments for using static types. And I just have here a screenshot to give a basic idea of that. I'm running the Siege load testing tool on that application whose code I just showed you with 20 concurrent connections, 100 hits each. And the transaction rate is the important part or at least that's the thing I'm focusing on. We get about 2,500 transactions per second, which isn't all that far off from just running Apache, serving static websites. And the question, yeah? So this just means transaction doesn't hits. It doesn't have a direct connection to databases. And even better, the memory usage of Erweb applications is much lower than with any of the usual tools. There's actually a whole program optimizing compiler that builds some very efficient native code from each program. And I have here another screenshot of the top program when I'm running the standalone web server that the compiler builds for that example application. It's this demo.exe that I have a box around the bottom here. After running this load test, the program only has about three megabytes of memory, resident. And as a comparison point, you can look a little further up this chart. You see a bunch of bash shells that are using more memory. So if you compare this to something like PHP or Rails, generally even just to start up your program, you have a significantly higher one-time cost in memory and a higher cost as you scale out to allocate more things. So this is really using the native C representations, despite the fact that you can write your program in a very high level way. So that is about all I have to say. I want to point you to the website for this project. So I haven't shown you that much code on these slides. And if you want to see code, you can go to this URL where you'll find, among other things, some online demos that have syntax highlighted source code. That's it. Thanks. You mentioned functional reactive programming, but you can, I don't know if you've covered it in the slides. Can you talk more about how that plays in? So, right, I didn't have any text on the slides talking about it. So functional reactive programming has two parts of it, at least the way I think about it. There's a view of dependencies among values and stating those explicitly, so you have some value that instead of modifying it imperatively, you set, instead, write out explicitly how it depends on other values. When you change those, the derived thing automatically updates. That's the part I'm using. Traditional functional reactive programming also has some idea of event streams which replace callbacks. I'm just using the normal callbacks here, which seems more intuitive to me. Does that answer the question? How is the runtime implemented? Runtime is implemented in C. Does Ergo require you to generate your HTML from your web program, or can you integrate it with Zyner, CSS, next to MIMO? So you can use the foreign function interface to go around the type system in whatever way you want. But if you're not doing that, then the HTML really needs to be processed as part of the source code, but it's pretty easy to take the usual template languages that I would expect designers to use and write some pre-processor that changes them to the right format. So have you, or has anyone made some websites with this? Like how far have you gotten this done? I have one medium-sized application that I've been working on with it, which is kind of meta in that it's a hosting platform for Erweb applications. I'm not aware of any other real, freestanding, independently interesting applications. So for the portion of this, the funds and the browser, if you have an Erweb to JavaScript compiler, and what are your biggest frustrations with JavaScript as a combination of that? Well, I guess that I can give a sort of meta answer, which is what do you mean by JavaScript? Because all the browsers are interpreting things in different ways, and that's a big part of the frustration. So if you nest enough anonymous functions, then Gekko complains about a stack overflow, even if you never call the functions. So that was enough of a pain that I switched to more of an interpreter, bytecode kind of approach for a lot of that. Any more questions? As far as languages and paradigms, it's sort of inspired, or what would you say is kind of other than similar in that regard? So the type system was inspired by dependently typed programming languages like Agda. So in general, this is a functional programming language in the tradition of ML and Haskell, but going further in the type system direction. Do you have any plans for integrating this with other ecosystems like communities that are building all of these components for web services? Do you mean web services, I think so? You showed that you have this thing that works with SQL, but then if I want to run another database, I've got people developing that, or do you have some strategy for getting it out there? You can use the foreign function interface to wrap all these other systems, and you can give them expressive enough types to get the same kind of guarantees that are present here. But I don't have any concrete plans for alternate database systems right now. Okay? Thank you.