Just finished another paper writing push: camera-ready OOPSLA paper, submission to FOOL on multiple ownership, and a submission to PLATEAU on evaluating Go, the new programming language from Google. The two new papers are both mostly students work, so working on them has been a bit of a new experience. The Go paper is an area I am new to (PL evaluation) and about a language I was new to, so was a new experience all round. It's all been pretty exhausting, and looking forward to doing some actual research again soon (although there is a journal version of an old paper in the works first).
Also, back to teaching again in two weeks. Teaching type systems again for six weeks. The first time I've taught the same stuff again, so hopefully I will be better and more polished, and it should be less work.
I'm a research engineer at Mozilla working on the Rust compiler. I have history with Firefox layout and graphics, and programming language theory and type systems (mostly of the OO, Featherweight flavour, thus the title of the blog). http://www.ncameron.org @nick_r_cameron
Thursday, August 19, 2010
Monday, August 02, 2010
On advertising, the software industry, and Bill Hicks
"By the way, if anyone here is in marketing or advertising...kill yourself." - Bill Hicks
I watched "American: The Bill Hicks Story" at the weekend. It was an excellent film and well worth watching, especially if you are a Bill Hicks fan. How is this relevant to programming languages? It's not. But it is vaguely relevant to the state of the software industry, bear with me...
One of Bill Hicks' 'things' is with marketing and advertising; see, for example, the above quote. Now I wouldn't quite agree with that, but I do agree that advertising and marketing make my life considerably worse, and I really can't stand them. I think that working in these industries cannot, morally, be justified. Whilst I am a supporter of capitalism (it might not be a great economic system, but it is definitely the least worst that anybody has come up with so far), I detest the current climate of consumerism and think it is a great detriment to most societies. Advertising/marketing is a key feeder of consumerism and thus, I don't like it.
Now the great thing about a lot of software right now is that it is free. Some is really free, made by volunteers out of the goodness of their hearts, but most is funded by advertising. The most obvious and successful example being Google. Furthermore, a whole lot of non-software information is funded by advertising, for example, most of the internet. So I can't close my eyes and wish that all the advertising in the world would go away, because then so would most of the software I use and websites I read. And companies I might one day like to work for.
So is there a moral problem to using such ad-funded software and websites. I use adblock, so of course I don't actually see any ads, and certainly never click any. So I'm kind of getting a free ride (oh, how I wish there was adblock for TV and real life). So I'm not funding the ads in anyway. But, this opens up a new problem: am I just free loading on those who are less tech-savvy than I and who do not use adblock? Well they don't pay for the ads, even if they click them, so not in a monetary sense. Although I guess they put up with the inconvenience (who knows, perhaps they even like the ads). And at the end of the day it's a slice of the price of the goods that we all buy, so in a way there is a consumption tax that is used to fund free websites and software, which is kind of nice. And also hundreds of engineers and investors, which is not so cool. And of course as a tax on consumption to fund information, it must be highly inefficient, since the advertisers and marketing people and managers at Google on obscene salaries all take their cut. It may still be more sefficient than an actual tax administered by a government though.
I watched "American: The Bill Hicks Story" at the weekend. It was an excellent film and well worth watching, especially if you are a Bill Hicks fan. How is this relevant to programming languages? It's not. But it is vaguely relevant to the state of the software industry, bear with me...
One of Bill Hicks' 'things' is with marketing and advertising; see, for example, the above quote. Now I wouldn't quite agree with that, but I do agree that advertising and marketing make my life considerably worse, and I really can't stand them. I think that working in these industries cannot, morally, be justified. Whilst I am a supporter of capitalism (it might not be a great economic system, but it is definitely the least worst that anybody has come up with so far), I detest the current climate of consumerism and think it is a great detriment to most societies. Advertising/marketing is a key feeder of consumerism and thus, I don't like it.
Now the great thing about a lot of software right now is that it is free. Some is really free, made by volunteers out of the goodness of their hearts, but most is funded by advertising. The most obvious and successful example being Google. Furthermore, a whole lot of non-software information is funded by advertising, for example, most of the internet. So I can't close my eyes and wish that all the advertising in the world would go away, because then so would most of the software I use and websites I read. And companies I might one day like to work for.
So is there a moral problem to using such ad-funded software and websites. I use adblock, so of course I don't actually see any ads, and certainly never click any. So I'm kind of getting a free ride (oh, how I wish there was adblock for TV and real life). So I'm not funding the ads in anyway. But, this opens up a new problem: am I just free loading on those who are less tech-savvy than I and who do not use adblock? Well they don't pay for the ads, even if they click them, so not in a monetary sense. Although I guess they put up with the inconvenience (who knows, perhaps they even like the ads). And at the end of the day it's a slice of the price of the goods that we all buy, so in a way there is a consumption tax that is used to fund free websites and software, which is kind of nice. And also hundreds of engineers and investors, which is not so cool. And of course as a tax on consumption to fund information, it must be highly inefficient, since the advertisers and marketing people and managers at Google on obscene salaries all take their cut. It may still be more sefficient than an actual tax administered by a government though.
Friday, July 30, 2010
Teaching programming
I taught a second year course on Java programming last semester, and, being in a university (and being a programming languages person), I think about teaching programming a fair bit. In particular, which languages should we teach?
Here is how I would design a curriculum if I were king (or head of programme or whatever):
1st year: assembly (8086, none of this RISC crap) and Haskell in parallel (in fact I would start with machine code and lambda calculus for the first few weeks).
2nd year: C and Python, again in parallel
3rd year: C++ and Java.
You could swap Haskell for some other pure, lazy, functional language if you like, and Javascript, Ruby, or Perl for Python, and Java for C#, and you probably don't need C++ and Java in the third year, one or the other would do.
And of course, this wouldn't work in real life --- you would scare off most of the students in the first year and it would only appeal to the very smartest and geekiest of students. But I think it is a good order: students would get some key concepts (recursion, pointers, machine organisation) early which they can apply when the learn the later langauges. The problem with learning Java first and then the fun stuff, is you don't learn your lessons that way - programming in C helps to make you a better Java programmer, but not vice-versa.
I think this organisation would give a good appreciation of real-life computers (too many students have no idea about how their Java programs relate to bits and bytes); and how to think about programming in a 'smart' way (higher order functions etc.)
A final advantage, the languages match the scale of the exercises: small programs in assembly/Haskell up to large programs in Java, just the way it was all designed.
I honestly think this would be the best way of teaching programming to good students. Unfortunately, a CS degree is about more than just programming, and students get a say in how they are taught, so it will never catch on.
Here is how I would design a curriculum if I were king (or head of programme or whatever):
1st year: assembly (8086, none of this RISC crap) and Haskell in parallel (in fact I would start with machine code and lambda calculus for the first few weeks).
2nd year: C and Python, again in parallel
3rd year: C++ and Java.
You could swap Haskell for some other pure, lazy, functional language if you like, and Javascript, Ruby, or Perl for Python, and Java for C#, and you probably don't need C++ and Java in the third year, one or the other would do.
And of course, this wouldn't work in real life --- you would scare off most of the students in the first year and it would only appeal to the very smartest and geekiest of students. But I think it is a good order: students would get some key concepts (recursion, pointers, machine organisation) early which they can apply when the learn the later langauges. The problem with learning Java first and then the fun stuff, is you don't learn your lessons that way - programming in C helps to make you a better Java programmer, but not vice-versa.
I think this organisation would give a good appreciation of real-life computers (too many students have no idea about how their Java programs relate to bits and bytes); and how to think about programming in a 'smart' way (higher order functions etc.)
A final advantage, the languages match the scale of the exercises: small programs in assembly/Haskell up to large programs in Java, just the way it was all designed.
I honestly think this would be the best way of teaching programming to good students. Unfortunately, a CS degree is about more than just programming, and students get a say in how they are taught, so it will never catch on.
Wednesday, July 21, 2010
Python
My project for last weekend was to learn how to program in Python. Possibly an ambitious goal for a weekend, but I feel I have a good grasp of the basics.
I didn't find it a hard language to learn, I guess it is designed that way, but being familiar with Groovy and Javascript probably help. I've only written small programs, but here are some thoughts:
I love the syntax and general feel, it feels very 'right'. Most things are done the way I would do them. I like indentation much better than braces and don't miss semi-colons one bit. On the other hand, it is much more readable than Perl. The only things I object to is colons to initiate block statement and pass statements rather than empty blocks, both seem to go against the minimalist syntactic philosophy, and both seem unnecessary.
In fact I love the language. It seems very good at what it sets out to do, much like C and unlike C++. There are very few rough edges, and lots of things that make you go "nice!".
I like the support for first-class functions, lambdas, map, filter, etc. Syntax for lists, slices, list comprehensions, generators, etc. I thought slices could have been used instead of the range() expression.
The jury is still out on yield.
Not using types is liberating in small programs. But my Groovy experience is that I quickly want to use them for documentation once the programs get larger ("just use variable names" you say; OK, I want compiler-checked documentation). Optional/hybrid types are the obvious solution. Maybe it is because I'm too used to C/Java programming.
The inefficient implementation scares the hell out of me. But, intellectually, I know it doesn't matter for 99% of applications, but still... Also I would prefer the implementation was not as obvious to the programmer (in docs as well as reflective code).
I like the duck typing approach to objects. It feels so much more lightweight than implementing interfaces. It makes me think that interfaces could be supported in a typed language much more easily. Not sure how, but something like Donna Malayeri's blend of nominal and structural types could be helpful.
I find the way fields of classes are handled strange: adding fields when they are assigned to fits nicely with the way variables are used, but feels very uncomfortable for fields. I think this is Java/C++ conditioning at work, and I haven't written programs that make use of this facility yet, so I am reserving judgement. It may well be a good idea, but it gives me the creeps.
I like the 'everything is public' philosophy, although I fear that those of a more software engineering bent would be horrified.
In conclusion, I like Python a lot. Of the scripting/dynamic programming languages I've looked at, it is my favourite. I hope to have an opportunity to use it for something serious soon.
And I still have the feeling that there is a huge space for a programming language with some of the dynamic features of a language like Python, combined with a more heavyweight class system (virtual classes) and optional typing to make a very pleasant general purpose language.
I didn't find it a hard language to learn, I guess it is designed that way, but being familiar with Groovy and Javascript probably help. I've only written small programs, but here are some thoughts:
I love the syntax and general feel, it feels very 'right'. Most things are done the way I would do them. I like indentation much better than braces and don't miss semi-colons one bit. On the other hand, it is much more readable than Perl. The only things I object to is colons to initiate block statement and pass statements rather than empty blocks, both seem to go against the minimalist syntactic philosophy, and both seem unnecessary.
In fact I love the language. It seems very good at what it sets out to do, much like C and unlike C++. There are very few rough edges, and lots of things that make you go "nice!".
I like the support for first-class functions, lambdas, map, filter, etc. Syntax for lists, slices, list comprehensions, generators, etc. I thought slices could have been used instead of the range() expression.
The jury is still out on yield.
Not using types is liberating in small programs. But my Groovy experience is that I quickly want to use them for documentation once the programs get larger ("just use variable names" you say; OK, I want compiler-checked documentation). Optional/hybrid types are the obvious solution. Maybe it is because I'm too used to C/Java programming.
The inefficient implementation scares the hell out of me. But, intellectually, I know it doesn't matter for 99% of applications, but still... Also I would prefer the implementation was not as obvious to the programmer (in docs as well as reflective code).
I like the duck typing approach to objects. It feels so much more lightweight than implementing interfaces. It makes me think that interfaces could be supported in a typed language much more easily. Not sure how, but something like Donna Malayeri's blend of nominal and structural types could be helpful.
I find the way fields of classes are handled strange: adding fields when they are assigned to fits nicely with the way variables are used, but feels very uncomfortable for fields. I think this is Java/C++ conditioning at work, and I haven't written programs that make use of this facility yet, so I am reserving judgement. It may well be a good idea, but it gives me the creeps.
I like the 'everything is public' philosophy, although I fear that those of a more software engineering bent would be horrified.
In conclusion, I like Python a lot. Of the scripting/dynamic programming languages I've looked at, it is my favourite. I hope to have an opportunity to use it for something serious soon.
And I still have the feeling that there is a huge space for a programming language with some of the dynamic features of a language like Python, combined with a more heavyweight class system (virtual classes) and optional typing to make a very pleasant general purpose language.
Women and Computer Science
Let it be known that I have been thinking about the issue of women in computer science. More precisely the fact that they are extremely under-represented.
This was in part set in motion by a talk on the subject by Barbara Crump at the NZCSRSC.
Anyway, I have lots of thoughts and opinions, but mainly for now I am reading and pondering. Musings on the subject will have to wait until I feel sufficiently informed, which may take some time...
This was in part set in motion by a talk on the subject by Barbara Crump at the NZCSRSC.
Anyway, I have lots of thoughts and opinions, but mainly for now I am reading and pondering. Musings on the subject will have to wait until I feel sufficiently informed, which may take some time...
Tuesday, June 29, 2010
TOOLS Europe day 1
So, after a monstrous 16hr journey from Maribor to Malaga, I arrived at TOOLS Europe. Malaga is surprisingly nice, all the package holiday tourists stay out of town - win!
The day kicked off with Oege de Moor's invited talk. I was not that excited about the prospect, but it was actually a really interesting talk - his tool is very useful and does some interesting things, all whilst being language independent. And the internal language is a pretty cool combination of logic/relational query language and OO.
My talk was at 2:30, and went pretty well. I should probably have had more and better examples; I realised as I talked that I was expecting the audience to keep rather a lot in their heads - why is this so obvious when giving the talk, but impossible to comprehend when practising?
Erik Ernst followed with an interesting talk on virtual types/parametric types/their relationship. Lots more interesting virtual classes stuff to think about.
Johan Ostland finished off the session with a talk about Welterweight Java, the talk filled in a lot of background about the various -weight Java calculi that I wasn't aware of, but probably should have been. As nice as Welterweight Java looks, I hope to never have to use it - my languages are already too big, and the smaller the better: if I could work purely in the untyped lambda calculus I would.
The day kicked off with Oege de Moor's invited talk. I was not that excited about the prospect, but it was actually a really interesting talk - his tool is very useful and does some interesting things, all whilst being language independent. And the internal language is a pretty cool combination of logic/relational query language and OO.
My talk was at 2:30, and went pretty well. I should probably have had more and better examples; I realised as I talked that I was expecting the audience to keep rather a lot in their heads - why is this so obvious when giving the talk, but impossible to comprehend when practising?
Erik Ernst followed with an interesting talk on virtual types/parametric types/their relationship. Lots more interesting virtual classes stuff to think about.
Johan Ostland finished off the session with a talk about Welterweight Java, the talk filled in a lot of background about the various -weight Java calculi that I wasn't aware of, but probably should have been. As nice as Welterweight Java looks, I hope to never have to use it - my languages are already too big, and the smaller the better: if I could work purely in the untyped lambda calculus I would.
Friday, June 25, 2010
ECOOP day 3
The day kicked off with Erik Ernst's invited talk: there was some philosophising, but mostly it was about virtual classes and gbeta ("the nomination for best foreign programming language syntax goes to..."). I very much approve of virtual classes --- they are awesome and with any luck will be in a major language soon. Erik motivated virtual classes using the standard expression problem and an example using wireless communication. He also talked a little about proof assistants, and gave a mention to his work with Sophia and I on Java wildcards.
Gilad Bracha talked about modules as objects in Newspeak and was awarded the best paper award. More nested classes stuff, this time to support modules. Late binding of names apparently gives nested and virtual classes and mixins straight up. Abolishing the global namespace means imports have to be passed in when top level classes are instantiated. At the root of it all, classes must be passed in by the IDE or some other tool. This leads to automatic sandboxing of code.
I liked the talk on inline caching, I love this kind of compiler optimisation stuff, it brings out my inner geek. But, it is far enough out of my area, that I need to read the paper to get the most out of that one, so no comments, sorry.
And that is the end of ECOOP for another year, now onto Malaga and TOOLS...
Gilad Bracha talked about modules as objects in Newspeak and was awarded the best paper award. More nested classes stuff, this time to support modules. Late binding of names apparently gives nested and virtual classes and mixins straight up. Abolishing the global namespace means imports have to be passed in when top level classes are instantiated. At the root of it all, classes must be passed in by the IDE or some other tool. This leads to automatic sandboxing of code.
I liked the talk on inline caching, I love this kind of compiler optimisation stuff, it brings out my inner geek. But, it is far enough out of my area, that I need to read the paper to get the most out of that one, so no comments, sorry.
And that is the end of ECOOP for another year, now onto Malaga and TOOLS...
Wednesday, June 23, 2010
ECOOP day 1
So, other than the crap wifi and an absence of snacks with coffee, the conference has been going well. There are many more people here than expected, it's not as quiet as many of us had feared. The Habakuk is a fairly good venue, the main conference room is nice, with desks, but crap wifi. The summer school room is a bit how and air-less, but has marginally better wifi (but still uselessly bad). Lunch is good, although it could have more vegetarian options (there seems little point in asking about dietary needs at registration if you are not going to bother making any dedicated food for said needs).
Anyway, Shriram gave another talk about Javascript --- this time about a core calculus, interesting they had actually implemented the de-sugar-er and operational semantics so could execute Javascript using their formalism.
I really wanted to see Gavin Bierman's talk on dynamic types for C# --- he is always a great speaker. Unfortunately I went on a mission to buy some new t-shirts at lunchtime (due to the relative pricing of a new t-shirt v. having a single t-shirt laundered at my hotel) and got lost. As compensation to myself I had a delicious blueberry gelatto.
I attended Andrew Kennedy's summer school session on unit types in F#, it was a good session with lots of interesting theoretical stuff about unit types (I couldn't believe there was so much to talk about them). I guess though, I would have preferred more on these interesting details (Andrew skipped quite a few slides), and a bit less on F# itself.
I would have liked to have seen the talks on "Verifying Generics and Delegates" and (especially after Shriram's plug yesterday) "Recency Types for Analysing Scripting Languages", but these clashed with the summer school. This was a shame, I believe they could have scheduled this better (there are other clashes later in the week too).
Anyway, Shriram gave another talk about Javascript --- this time about a core calculus, interesting they had actually implemented the de-sugar-er and operational semantics so could execute Javascript using their formalism.
I really wanted to see Gavin Bierman's talk on dynamic types for C# --- he is always a great speaker. Unfortunately I went on a mission to buy some new t-shirts at lunchtime (due to the relative pricing of a new t-shirt v. having a single t-shirt laundered at my hotel) and got lost. As compensation to myself I had a delicious blueberry gelatto.
I attended Andrew Kennedy's summer school session on unit types in F#, it was a good session with lots of interesting theoretical stuff about unit types (I couldn't believe there was so much to talk about them). I guess though, I would have preferred more on these interesting details (Andrew skipped quite a few slides), and a bit less on F# itself.
I would have liked to have seen the talks on "Verifying Generics and Delegates" and (especially after Shriram's plug yesterday) "Recency Types for Analysing Scripting Languages", but these clashed with the summer school. This was a shame, I believe they could have scheduled this better (there are other clashes later in the week too).
Tuesday, June 22, 2010
Worst wifi connection ever
Is foiling my attempts to live-blog ECOOP :-( So, more dead-blog entries later...
FTfJP invited talk - "Electrifying Javascript"
By Shriram Krishnamurthi. O for awesome. Good speaker, good talk, very electrifying! Presented a type system for Javascript (which seems to be fashionable right now, this one focuses on the dynamic parts of the type system, rather than finding class-like types). Cool type system - must be flow sensitive, features tags (like types, but simpler and descriptive, to support "typeof") and a nice way to go from tags to types, and non-nullness.
Actually uses flow analysis, but a simple (and intra-procedural) kind, looking only at tags. The type system uses tagchecks, and the flow analysis inserts tagchecks.
A slogan: "Types on the outside, flows on the inside".
The type checker assumes function parameters are anntotated with types. The final piece of the puzzle is that they dynamically infer these types which can then be used for type checking (!)
The whole process seems to work pretty well - good results, but over a relatively small code base.
[Note to self: reasonable plug for recency types, tomorrow]
Actually uses flow analysis, but a simple (and intra-procedural) kind, looking only at tags. The type system uses tagchecks, and the flow analysis inserts tagchecks.
A slogan: "Types on the outside, flows on the inside".
The type checker assumes function parameters are anntotated with types. The final piece of the puzzle is that they dynamically infer these types which can then be used for type checking (!)
The whole process seems to work pretty well - good results, but over a relatively small code base.
[Note to self: reasonable plug for recency types, tomorrow]
Subscribe to:
Posts (Atom)