I’ve always thought this was a dumb idea. Apparently, the python gods noted that people would often try typing 'exit' to exit the interpreter. But, instead of allowing this, they added a toplevel string variable with a default value of "Use Ctrl-D (i.e. EOF) to exit.". So, if you type 'exit', that string gets evaluated, and subsequently printed by the interpreter.

Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

>>> exit

‘Use Ctrl-D (i.e. EOF) to exit.’



I guess that’s helpful, but you know what would be more helpful? Just exit the freaking program!

To me, this is like if your web browser had a “refresh” button that popped up a dialog telling you to press the “reload” button.

By the time you acknowledge your users’ expectations by adding code to your product, the only sane choice is to make your product do what your users are expecting. I bet whoever added it thought it was clever that the interpreter would print the string when it was evaluated, and “clever” won over “sensible.” Oh well.

That’s not even the worst part. The other bad thing about this hack, is that it only really works in the interpreter. If you mistakenly type 'exit' as part of a python program, this hack means you don’t get an error. Unfortunately, you don’t get a program exit, either. You just get a silently disregarded string value. I can imagine a poor entry-level coder trying to debug that problem! “It seems to be disregarding my exit statement!” meh… The poor user’s only hope is if they misspelled it, since 'exut' would raise a NameError (which would actually exit the program if it’s not caught).

Don’t get me wrong. I like python quite a bit (though I use it very little). This is just one of those things that’s always irked me.

Another video from the fine Google Tech Talks series. This one is mainly about concurrency in Java, and the way concurrency interacts with the memory model is JDK5 and JDK6. Lots of stuff on non-locking synchronization, which I’ve never tried to do in java. I’ve always just used locks and been done with it. When I used to code in C/C++ a lot, though, I used to try to avoid mutex locks as much as possible, as a matter of principle. So, for example I was interested in the part on what promises the JVM makes regarding volatile variables. Good talk, overall.

From the abstract:

Dynamic languages like Python have gained significant popularity in mainstream … all » programming. To support their dynamic features, they are often interpreted. In scientific computing applications, this works well for prototyping, but often means that significant efforts must later be invested in building the “real” application. Our thesis is that dynamic languages like Python can be effectively compiled by translation to statically typed functional languages like OCaml. Not only that, but this approach is highly amenable to formal verification. This, in fact, entails developing a formal semantics for the dynamic language.

From the abstract:

This talk will provide an overview of the new features introduced by concepts and how they will benefit C++ programmers. We will see how concepts can be used to express the core components of the C++ Standard (Template) Library, and explore some of the new capabilities that concepts bring to the C++ language.

A talk by Neal Gafter about adding closures to java. From the abstract:

This talk describes the proposed language extension and its design rationale, and shows how it will affect existing and future APIs.

Interesting hint of bureaucracy at google at the end of this video…

A talk by Peter Seibel. From the abstract:

In his talk, Peter will discuss how our choices of programming language influences and shapes our pattern languages and the architectures we can, or are likely to, invent. He will also discuss whether it’s sufficient to merely broaden your horizons by learning different programming languages or whether you must actually use them.

Guido van Rossom, 2/14/2007: