Artima.com has published Part V of an interview with Python creator Guido van Rossum, in which he talks about the robustness of systems built with strongly and weakly typed languages, the value of testing, and whether he'd fly on an all-Python plane.

Here's an excerpt:

Guido van Rossum: That attitude sounds like the classic thing I've always heard from strong-typing proponents. The one thing that troubles me is that all the focus is on the strong typing, as if once your program is type correct, it has no bugs left. Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct.

Strong typing is one reason that languages like C++ and Java require more finger typing. You have to declare all your variables and you have to do a lot of work just to make the compiler happy. An old saying from Unix developers goes something like, "If only your programs would be correct if you simply typed them three times." You'd gladly do that if typing your programs three times was enough to make them work correctly, but unfortunately it doesn't work that way.

All that attention to getting the types right doesn't necessarily mean you don't have other bugs in your program. A type is a narrow piece of information about your data. When you look at large programs that deal with a lot of strong typing, you see that many words are spent working around strong typing.

Artima.com has published an article that introduces the main features of Artima SuiteRunner, a free open source testing toolkit, by demonstrating how to start Artima SuiteRunner, debug a failed test, select and run Suites, select and run JUnit TestCases, and edit and save recipe files.

Here's an excerpt:

Artima SuiteRunner is a free open source testing toolkit for Java released under the Open Software License. You can use this tool with JUnit to run existing JUnit test suites, or standalone to create unit and conformance tests for Java APIs. To get you up and running quickly, the Artima SuiteRunner distribution ZIP file includes a simple example. This article uses the example to introduce the main features of Artima SuiteRunner. This article will show you how to start Artima SuiteRunner using a recipe file, debug a failed test, select and run Suites, select and run JUnit TestCases, and edit and save recipe files.

Artima.com has published Part IV of an interview with Python creator Guido van Rossum, in which he talks about about the nature of contracts in a runtime typed programming language such as Python.

Here's an excerpt:

In general in Python, there is a contract, but the contract is implicit. The contract isn't specified by an interface. There's nothing in what the parser sees at least that says x has to be an object that supports readline that you can call with no arguments and it returns a string that means a certain thing. But that contract is certainly in the documentation or specification.

In Java, if you say this is something that has a readline method that returns a string, what does it mean? Do you expect it to always return the same string? Does it ever return an empty string? There are all sorts of things that aren't expressed by that interface that you still have to specify in documentation. That's where the interesting competition between the different languages exists.

Artima.com has published Part III of an interview with Python creator Guido van Rossum, in which he talks about about the source of Python's famed programmer productivity and the joys of exploring new territory with code.

Here's an excerpt:

I like programming problems where you think, "There has to be something really interesting over there, but I can't see it clearly." All you can do is move one step over there, with a small bit of code, and start exploring to see it more clearly. And maybe it actually wasn't there, it was over here. Or it had a different shape than you thought initially. Maybe it wasn't interesting at all, and you didn't waste a lot of time.

The danger of planning is that you plan for the contingencies you know about, but by definition you don't plan for things you don't know you'll encounter. So when you do encounter an unexpected event in your programming endeavor, you have to fix many interfaces and change multiple method signatures. If you've already committed to your original plan and that's no longer where you're going, then you have a problem.

I'm not particularly worried by the fact that people say you can prototype more easily in Python, but eventually the Java version makes it easier to build a robust large system. You can prototype in Python. Once you've explored the space more, you can do the planning and design that the Java version requires. If you start writing in Java knowing as little as you did when you started writing the Python version, you'll waste way more time exploring than actually building the system you'll eventually build.

Artima.com has published an article by Bill Venners, Matt Gerrans, and Frank Sommers in which they explain why JUnit didn't solve their particular testing problems, and how they created Artima SuiteRunner, a free, open source test toolkit and JUnit runner.

Here's an excerpt:

Because JUnit links the concepts of running and reporting in the notion of a runner, we made Artima SuiteRunner a JUnit runner. You can use Artima SuiteRunner to run and report results of JUnit tests, just like you can use JUnit's text or Swing runners. The three main advantages of using SuiteRunner to run your JUnit tests are reporters, runpaths, and recipe files:

• A reporter collects and presents test results in a highly customizable way to the user. Examples are text, graphics, Web pages, database output, CSV files, XML, and email alerts.
• A runpath lets you load classes for your tests from anywhere with an easy- to-configure list of filenames, directory paths, and/or URLs.
• A recipe file captures and saves in a file the run properties of a particular suite of tests for easy reuse.

Artima.com has published Part II of an interview with Python creator Guido van Rossum in which he discusses how he originally intended Python to "bridge the gap between the shell and C," and how it eventually became used on large scale applications.

Here's an excerpt:

The addition of privates was another small language change that was meant to make writing large programs easier. To me, it's mostly useful to address people's irrational fears than act as a practical tool. There are situations where privates are very useful, because you know you have your own namespace. But in many cases, I think it is overused.

People who fear that someone will call their code with the wrong arguments, and who are used to having static-typed language prevent that at the compiler level, will try to prevent that happening in their code by adding explicit assertions. People will check the types. They'll think, "Oh, this only works for strings, so now I'll assert that the input argument is a string."

That is the completely wrong approach, because someone could easily implement something that works just as well with your code and behaves sufficiently like a string. Maybe it's a proxy for a string, which behaves in almost every aspect as a string, except that its type is a proxy. That's something we use in Zope a lot. The persistency mechanism uses proxies, as does the security mechanism that executes untrusted Web- submitted code.

Untrusted code is executed in a sandbox environment using proxies for objects that the code shouldn't be accessing directly. So the fact that the language doesn't enforce types at either the compiler level or the implementation level is actually helpful.

Artima.com has published Part II of an interview with Sun Microsystems' fellow and chief engineer Rob Gingell in which he discusses the pressures on vendors to both create froth -- to add value on top of standards -- and maintain compatibility in a multi-vendor industry.

Here's an excerpt:

Your question addresses the fundamentals of how a multi-vendor industry operates for the good of a common customer base. The "open systems" promise to customers was the ability to treat every purchase/deployment decision independent of all others. There's no vendor lock-in. Indeed, customers lock in vendors by the standards they hold the vendors to. That's the ideal, in a steady state.

The problem with that ideal is that the needs don't stay constant, and customers constantly seek improvements from suppliers. Products improve by such actions. If a customer genuinely depends on a capability, he or she is locked in to those who supply it until, or unless, everyone supplies it.

Here's the basic conundrum: If you only implement the standard, you don't solve any new problems. If no new problems are solved, where does the evolving "practice" come from that finds its way into new standards? If you use a new thing, aren't you thus locked in? How do you meet new needs without doing a new thing?

Here's how life works: Assuming a shared initial condition, some derivation will occur, often in cactus- like fashion across an industry through competition. With time, the economic benefit of standardization is sought to codify what has emerged as existing practice. If the derivation branching grows too large, we criticize it for being fragmented. If the derivation is zero or too small, then we criticize it for being stagnant, non-innovative. There's a happy medium in which the "froth" ahead of the standard progresses the industry, but doesn't damage the base of commonality that defines a marketplace.

Artima.com has published Part I of an interview with Sun Microsystems' fellow and chief engineer Rob Gingell in which he discusses open source licensing, source and binary compatibility, binary standards, and the Java Community Process.

Here's an excerpt:

The Unix industry was regarded as fragmented by customers because you couldn't interchange the binary artifacts between systems, either in whole or in part. Yet we had all those Unix standards, and everyone claimed to conform to them. So what went wrong?

Well, in some ways, nothing?only, we had an audience mismatch. Unix was very successful in having a technology standard?source code was relatively portable. Linux's rapid rise is in part due to a ready-made set of applications, and its historical evolution was partly driven by finding an application it couldn't run and then adding what was needed. The programmers actually did, and largely do, enjoy "open systems" in Unix.

End-customers, however, did not. For them, the Unix standards have a similar import that steel standards have to a person trying to buy a car. No one cares about them explicitly, nor makes a purchase decision based explicitly on them. The JCP manages Java in both spaces, providing both programmers and end-users of their work the benefits they're seeking.

Artima.com has published Part I of an interview with Python creator Guido van Rossum in which he discusses Python's history, the influence of the ABC language, and Python's original design goals.

Here's an excerpt:

In 1986 I moved to a different project at CWI, the Amoeba project. Amoeba was a distributed operating system. By the late 1980s we found we needed a scripting language. I had a large degree of freedom on that project to start my own mini project within the scope of what we were doing. I remembered all my experience and some of my frustration with ABC. I decided to try to design a simple scripting language that possessed some of ABC's better properties, but without its problems.

So I started typing. I created a simple virtual machine, a simple parser, and a simple runtime. I made my own version of the various ABC parts that I liked. I created a basic syntax, used indentation for statement grouping instead of curly braces or begin-end blocks, and developed a small number of powerful data types: a hash table (or dictionary, as we call it), a list, strings, and numbers.

I took ABC's ingredients and shuffled them around a bit. Python was similar to ABC in many ways, but there were also differences. Python's lists, dictionaries, basic statements and use of indentation differed from what ABC had. ABC used uppercase for keywords. I never got comfortable with the uppercase, neither reading nor typing it, so in Python keywords were lowercase.

I think my most innovative contribution to Python's success was making it easy to extend. That also came out of my frustration with ABC. ABC was a very monolithic design. There was a language design team, and they were God. They designed every language detail and there was no way to add to it. You could write your own programs, but you couldn't easily add low-level stuff.

Artima.com has published a four-part interview with Scott Meyers, author of Effective C++, More Effective C++, and Effective STL. In Multiple Inheritance and Interfaces, Scott describes how his view of multiple inheritance has changed with time, the C++ community's take on Java's interface, and a schism of focus between the C++ and other prominent development communities. In Designing Contracts and Interfaces, Scott discusses interface contracts, private data, and designing minimal and complete interfaces. In Meaningful Programming, Scott discusses the importance of saying what you mean and understanding what you say, the three fundamental relationships between classes, and the difference between virtual and non-virtual functions. In Const, RTTI, and Efficiency, Scott describes the utility of const, the appropriate time to use RTTI, a good attitude about efficiency, and Scott Meyers' current quest for general programming principles.