Teaching & Learning

Don Knuth: Musings and More

An archive of videotaped Knuth lectures.

Tutorial on Good Lisp Programming Style

An outstanding tutorial on Lisp programming style by Peter Norvig and Kent Pitman. This to me is like Strunk & White: I re-read it every year or so and it always makes me cringe at what I've been writing lately.

The material is easy to relate to other higher-order languages. Translate your favourite slides into your language of choice and post them to the mailing list!

Does Visual Studio Rot the Mind?

An long and interesting rant by Charles Petzold.

Obviously this is mostly about the IDE side of things (seeing as VS is an IDE).

Some of the features that VS provides are intended to overcome the huge size of the standard libraries, and you might argue this isn't really a language issue. At some level this is indeed a valid argument. However, I think we should pause every once in awhile and wonder whether better programming language abstractions might make modern programming - with GUIs, XML etc. - easier, and eliminate some of the need for huge libraries. In fact, one can argue that LINQ (Cw) is a step in this direction, as regards data access.

It is also worth noting that when IDEs influence the way programming is done, they influence the way languages are used, and thus influence the design space. Programmers demand new language features partly as a response to their experience with the language as it is used in practice.

Finally, the impact on teaching and learning programming shouldn't be overlooked. Students naturally want to produce cool GUI applications and use VS. If this makes it harder to introduce them to different programming techniques and languages (and I think it does), this can be highly problematic.

Here are some choice quotes from Petzold (who also said that the whole history of new programming languages... for Windows has involved the struggle to reduce the windows hello-world program down to something small, sleek, and elegant):

To get IntelliSense to work right, not only must you code in a bottom-up structure, but within each method or property, you must also write you code linearly from beginning to end — just as if you were using that old DOS line editor, EDLIN. You must define all variables before you use them. No more skipping around in your code.

If we select a new project type of Windows Application, for example, and give it a name and location on a local drive, Visual Studio generates sufficient code so that this project is immediately compilable and runable... Somehow, we have been persuaded that this is the proper way to program. I don’t know why. Personally, I find starting a program with an empty source code file to be very enjoyable.

This is the file in which Visual Studio inserts generated code when you design your form. Visual Studio really doesn’t want you messing around with this file, and for good reason. Visual Studio is expecting this generated code to be in a certain format, and if you mess with it, it may not be able to read it back in the next time you open the project.

This bothered me because Visual Basic was treating a program not as a complete coherent document, but as little snippets of code attached to visual objects. That’s not what a program is. That’s not what the compiler sees. How did one then get a sense of the complete program? It baffled me.

If Visual Studio really wanted you to write good code, every time you dragged a control onto your form, an annoying dialog would pop up saying “Type in a meaningful name for this control.” But Visual Studio is not interested in having you write good code. It wants you to write code fast.

Lowering the barriers to programming

(via the LtU forum)

Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers. Caitlin Kelleher, Randy Pausch. ACM Computing Surveys. Vol. 37. No. 2. Jun 2005.

Since the early 1960's, researchers have built a number of programming languages and environments with the intention of making programming accessible to a larger number of people. This article presents a taxonomy of languages and environments designed to make programming more accessible to novice programmers of all ages. The systems are organized by their primary goal, either to teach programming or to use programming to empower their users, and then, by each system's authors' approach, to making learning to program easier for novice programmers. The article explains all categories in the taxonomy, provides a brief description of the systems in each category, and suggests some avenues for future work in novice programming environments and languages.

You might also want to check out this older LtU item.

American lecture tour gets real

During the week of Nov. 7-11 I will be visiting five American universities and giving talks about our approach to teaching programming (as embodied by CTM) and about our research on distributed programming. The tour schedule and talk abstracts are available here. I will be happy to meet with people during the tour.

Laziness Without All the Hard Work

Laziness Without All the Hard Work. Barzilay and Clements. FDPE 2005

While teaching programming languages courses, we have discovered that an extension to PLT Scheme allows the system to accommodate both lazy and strict evaluation in the same system. Moreover, the extension is simple and transparent. Finally, the simple nature of the extension means that the resulting system provides a rich environment for both lazy and strict programs without modification.

A nice thing about this paper (aside from the fact that it uses the PLT module system) is the careful attention to the relationship between features of the language defined by the interpreter and the features of the defining language.

Concrete Abstractions on the web

From a comp.lang.scheme announcement (full text quoted below):

I'm happy to report that my publisher has agreed to make Concrete Abstractions available on the web for free, while continuing to sell the printed and bound edition. My co-authors and I hope this will allow a broader segment of the international community of schemers to take advantage of our work.

For those unfamiliar with it, I'm referring to "Concrete Abstractions: An Introduction to Computer Science Using Scheme," by Max Hailperin, Barbara Kaiser, and Karl Knight.

Follow the PDF files link from the main book page,

-Max Hailperin
Professor of Computer Science
Chair, Mathematics and Computer Science
Gustavus Adolphus College
800 W. College Ave.
St. Peter, MN 56082

CTM tour during the week of Nov. 7

During the week of Nov. 7, I will be touring the US to visit universities and other institutions teaching with my book (CTM) or thinking of teaching with it. For those who have not seen the book, it teaches programming in a way that is both broad and deep. It covers both practice (writing and running programs) and theory (semantics and reasoning about programs), and covers most of the important programming paradigms in a simple and uniform way. It is based on a long-term research collaboration (more than 15 years by now) by many people on understanding programming languages and their underlying concepts.

I will be giving talks and also talking with people. I can answer any questions about the book, its motivation and background, and our teaching experience. I can also offer advice on how to fit the book or its approach in your computer science curriculum.

I am now starting to plan the tour. If you are in the US and you would like me to visit your institution, please send me email (pvr@info.ucl.ac.be).

Design Concepts in Programming Languages

Design Concepts in Programming Languages

Below are all current draft chapters of Franklyn Turbak and David Gifford's Design Concepts in Programming Languages. This is a book based on MIT's graduate programming languages course (6.821). Many people helped in developing parts of the book, especially Mark Sheldon, Trevor Jim, Brian Reistad, and Jonathan Rees.

Haskell for C Programmers

Many people are accustomed to imperative languagues, which include C, C++, Java, Python, and Pascal....For [beginning] computer science students,...Haskell is weird and obtuse....This tutorial assumes that the reader is familiar [only] with C/C++, Python, Java, or Pascal. I am writing for you because it seems that no other tutorial was written to help students overcome the difficulty of moving from C/C++, Java, and the like to Haskell.

I write this assuming that you have checked out...the Gentle Introduction to Haskell, but...still don't understand what's going on....

Haskell is not 'a little different,' and will not 'take a little time.' It is very different and you cannot simply pick it up, although I hope that this tutorial will help.

If you play around with Haskell, do not merely write toy programs. Simple problems will not take advantage of Haskell's power. Its power shines mostly clearly when you...attack difficult tasks....Haskell's tools...dramatically simplify your code....

I am going to put many pauses in this tutorial because learning Haskell hurt a lot, at least for me. I needed breaks, and my brain hurt while I was trying to understand....

Now I'm working on a video game in Haskell...and we've written a short tutorial...on HOpenGL....

Haskell has both more flexibility and more control than most languages. Nothing that I know of beats C's control, but Haskell has everything C does unless you need to control specific bytes in memory. So I call Haskell powerful, rather than just 'good.'

I wrote this tutorial because Haskell was very hard for me to learn, but now I love it...."Haskell is hard!" "You can't write code the way I know how!" "My brain hurts!" "There aren't any good references!" That's what I said when I was in college. There were good references, but they didn't cover the real problem: coders know C.

New explorers might enjoy Eclipse IDE support (version 3.1M7 or later only). Old hands might help improve it.

Haskell compiles to C (cf. JHC) and machine code.

XML feed