Waterloo Programming Languages Seminars
Previous terms:
F11
S11
W11
F10
S10
F08
S08
W08
F07
W07
F06
S06
W06
Current term:
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:
- completed research
- research that you plan to start ("half-baked ideas" to be critiqued by your peers)
- interesting paper(s) you have read
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.