I'm not sure if I should list the dozens of proprietary languages I also unfortunately know. If I know "some" of a language that means I probably passed an assignment to write some code in it, or wrote some incidental code based on someone else's, but probably am not familiar with current work in or nor the right libraries to use. I don't know Python yet, that might be my next one.
The assembly language I knew best was 6502, today considered an early RISC processor. Given how few people know any assembly language now, and how popular RISC is, I'm going to say I know this.
I'm not going to list all the C-like languages I know like WSL. Most of them are probably dead.
I have a BMath from University of Waterloo where I learned too many languages.
I like LISP best but the programming language I still know best is C++, I taught it to about 500 people in the late 80s and 1990-1 when it was still evolving, and contributed improvements to an excellent course in the language originally written by Wm Leler. My teaching career was before the Standard Template Library which we sorely needed, in fact before templates worked well at all - our problems were similar to those that still exist because of poor support for STL by IDEs.
I did some finance API work in C++ just after that and participated on the ANSI C++ Committee for Canada briefly. I made some mostly-futile arguments about the necessity of fixing the way inheritance and template interacted (badly).
 patterns and templates
One of the few who totally understood the issue was Jiri Soukup, author of Taming C++, who defined "a special class which represents an entire pattern which led to extension of the STL to association classes. As Jiri puts it "The main advantage of pattern classes is the de-coupling of application classes. In situations that traditionally lead to large clusters of mutually dependent classes (traditional frameworks), pattern classes allow you to test and compile most classes independently. Also, each pattern can be tested as an independent unit."
 extracting explicit protocols from implicit dynamic type use
Another useful debate was regarding duck typing and the way explicit protocols could be extracted from code making use of looser typing so the conversions actually being assumed or invoked could be monitored and controlled based on actual use, requiring "a tool would actually determine, for any given compiled-and-linked module, which interfaces were actually being used, and would document them as an abstract type called a protocol. This would be based on actual usage, not on any intent or guess. If there were too many protocols then they would be easy to simplify into a set of abstract types. Shipped code could carry protocol information so as to allow any module loaded to flag exceptions, that is, cases where a protocol was violated (even if the actual call ran). That way, the "potential problem" of violations of protocol would be separated from "actual problem", in time to notice and modify the code. As more and more code was running on the Internet, it would be easier and easier to discover potential problems in actual usage of the modules involved, if a culture of trust (leaving the protocol test and notification to the library's authors) could be created."
If you like this idea let me know and we'll make it work. ;-)
I also wrote a course in Trellis in 1990-91 but haven't used it since. Sadly it didn't make it. This was a Python-like language with excellent garbage collection and templates/generics and an interactive development environment that DEC sold briefly to those needing OODB tools - it was the first programming language actually designed to integrate perfectly with an OODB.
 Literate programming
I've always believed in literate programming and I created this user page largely out of respect for the excellent support for it in this wiki. I believe software is a craft rather than a science, generally, a "process art". I'm a fan of "Why Literate Programming Matters" and hopefully will think of some feedback for it some time.
I have lots of code left over from various projects. Let me know if any of this is of interest and I may try to dig it up:
- C++ interface for time spans, suitable for time series algebra (no implementation unfortunately, just the API)
- LISP code for dozens of random things mostly related to processing relation-like matrices
- Smalltalk code for manipulating an in-memory database very efficiently in under 4MB of memory