Waterloo Programming Languages Seminars

Previous terms: F11 S11 W11 F10 S10 F08 S08 W08 F07 W07 F06 S06 W06

Current term:

Date Speaker Title (click for abstract) Location
Mon. May 7, 2012 at 10:00 am Karim Ali Application-only Call Graph Construction DC 2314
Wed. June 6, 2012 at 10:00 am Karim Ali Application-only Call Graph Construction DC 2314
Fri. July 6, 2012 at 1:30 pm Ming-Yee Iu Why Are Programming Languages Always in English? DC 1331

All are welcome.

Talk announcements are also posted to a public mailing list.

To volunteer to give a talk, contact Ondřej Lhoták. Talks can range from informal to formal, and they can be about any of the following:

The purpose is for us all to see what people are interested in, and motivate discussions.

Abstracts

Application-only Call Graph Construction

Karim Ali
May 7, 2012
Since call graphs are an essential starting point for all interprocedural analyses, many tools and frameworks have been developed to generate the call graph of a given program. The majority of these tools focus on generating the call graph of the whole program (i.e., both the application and the libraries that the application depends on). A popular compromise to the excessive cost of building a call graph for the whole program is to ignore all the effects of the library code and any calls the library makes back into the application. This results in potential unsoundness in the generated call graph and therefore in any analysis that uses it. In this seminar, we present CGC, a tool that generates a sound call graph for the application part of a program without analyzing the code of the library.

Application-only Call Graph Construction

Karim Ali
June 6, 2012
Since call graphs are an essential starting point for all interprocedural analyses, many tools and frameworks have been developed to generate the call graph of a given program. The majority of these tools focus on generating the call graph of the whole program (i.e., both the application and the libraries that the application depends on). A popular compromise to the excessive cost of building a call graph for the whole program is to ignore all the effects of the library code and any calls the library makes back into the application. This results in potential unsoundness in the generated call graph and therefore in any analysis that uses it. In this seminar, we present CGC, a tool that generates a sound call graph for the application part of a program without analyzing the code of the library.

Why Are Programming Languages Always in English?

Ming-Yee Iu
July 6, 2012
Currently, most of the world's programming languages are available in English only. Anyone who wants to program a real application in a mainstream programming language needs to know some English first. Even programming languages designed in non-English speaking countries such as Pascal, Python, Ruby, and Scala are only available in English. Why are all of these programming languages always in English?

This is an important question because the dominance of English imposes a barrier to computer use in non-English speaking countries. Whereas English children can learn to program as soon as they learn to read; German children need to learn some English first. Office workers in Japan need to learn English before they can write macros to automate their tasks, write formulas in Excel spreadsheets, or hack their own web pages. In the US, a college dropout can pick up some programming books, learn to program, and create an app start-up (or possibly a Microsoft, Facebook, Apple, or Oracle). Could a college dropout in Egypt with shaky English skills do the same? Does the US dominate the software industry because it has more talent and entrepreneurship than other countries? Or does it dominate because the game is rigged to favour English-speaking countries?

In this talk, I will propose different explanations for why programming languages are always in English. I will then talk about how I have designed a new programming language, a multilingual version of ECMAScript called Babylscript, to try to address these issues. Finally, I will discuss my experiences in trying to extend Babylscript to support the native languages of half the world's population.