Slashdot Mirror

Why should a Windows compiler and a Linux compiler and an OS X compiler be forced to use the same name mangling? Note that there are ABI standards for C++, although they are not published by ISO. There's e.g. the Itanium ABI (named that way because originally it was meant to be used on Itanium, but it's also used on other platforms, e.g. AFAIK all Linux compilers for x86 and x86-64 follow it, making it a de-facto Linux standard (indeed, gcc following it already makes it a standard for Linux). Since OS X uses gcc as main compiler (but shifting to LLVM lately), I guess they use the Itanium ABI, too.

However note that vendors not using an ABI will be reluctant to switch to it because it breaks compatibility with all earlier versions of the compiler. Even formal ISO standardization wouldn't help much, because those vendors would most likely simply decide to not be standard conforming, or not be standard conforming by default, in this regard.

Hrm...look here. If you're developing an x86 compiler these days and not adhering to this standard, you've pretty much locked yourself out of customers.

Implicit copy constructors and assign operator bite. You don't expect them, and the STL makes heavy use of them.

If you don't expect them, you shouldn't claim to know C++.

Name mangling is not specified. Try to mix dlls build with gcc and msvc, fixed that hell? Now, try to build an dll with gcc that can replace a dll build with msvc.

It's also not specified with C (and if you think there's no name mangling in C: There were DOS compilers which preceded all global symbol names with an underscore, in order to avoid assembler conflicts with register names). It's just that on every platform today, there's a separate ABI standard or de-facto-standard for C (e.g. the psABI), and since today the OS interface is generally in C, any compiler has to follow the platform ABI. The same is not (yet) true for C++, but there are already standardization efforts (for example, while GCC in the past used a homegrown ABI, it now uses a standardized ABI which is also used by other compilers [while it's formally only an Itanium ABI, GCC uses the non-Itanium specific parts of it also for other platforms]).

Not mentioned in the FQA, but std::string is STUPID.

Agree here: std::string is not well designed. I'm pretty sure that if it were designed today, it would be designed differently.

• A gas is a compressible fluid.

  But it cannot be treated as such when the density gets too low. You couldn't treat the edge of the atmosphere as a fluid. I don't care what it is when I use a CFD, only what it behaves like.

  • The most general solvers are the most handicapped. Even the ridiculously costly commercial solvers (Ansys, Fluent, etc.) solve a limited number of problems. I was working on a project that attempted to numerically simulate the effect of electromagnetic waves on the brain. Obviously, you need to solve the Maxwell's equations in horrible medium that is your brain. That's when I realized how woefully indadequate the commercial solvers (that claim to simulate the problem) are.

  My brain's a medium? I thought I heard some dead people in there. :)

  Seriously, I entirely agree. I don't for a moment pretend that I'm anything like up enough on PDEs or high-end maths problems (it's been a while) to identify the best packages either. The best I can do is say such software exists. I'll list here the packages I list and use - not just for PDEs but for maths and logic problems as a whole. I'll leave it to you and others skilled in the subject to pass judgement on their quality.

  • ATLAS - A nice, optimized BLAS (Basic Linear Algebra System) implementation
  • HOL4 - Higher Order Logic proof assistant
  • Hypre - Preconditioner for linear equation solvers
  • LAPack - Linear Algebra Package that runs over BLAS
  • ScaLAPack - Subset of LAPack optimized for highly parallel computers
  • Overture - A PDE solver
  • PHAML - A PDE solver for 2D elliptic partial differential equations
  • SUNDIALS - An expansive (and rather nice) PDE solver
  • VSIPL++ - Nice little signal processing library

In the Q&A session afterwards one of the attendees asked what Mr. Saxby thought of Linux - he replied that it was a toy operating system that would never amount to anything, and that open source was a useless strategy for developing software and he didn't see any place for it in the business world.

When I was working at ARM on a processor (around 2007), we were paying and giving technical details to codesourcery, to add gcc support for the processor; many of the engineering tools were run on linux, and ARM's development software could run as Eclipse add-ons. There's no shortage of Linux support at ARM at the moment.

That said, when push comes to shove ARM is an IP company. Their business centres around charging people for processor designs, both upfront and per processor produced. So even given their use of and support for Linux, if someone asked them "why not open source your products and make money by charging for support, customization and improvements" they would probably reply "we don't think that would make as much money as our current closed-source licensing model".

Obviously, Microsoft is a software company, they want to make money selling their software as they have in the past. And now, more and more I think that free and open source software obviously puts a wrench in their historical business plans and profits.

I hardly consider Microsoft's buy out of Novell a contribution towards open source software. Except for Microsoft, big companies, like IBM, are paying open source developers for their work. I think that adding monetary reward to open source projects has both pros and cons attached to it. The developers get the benefit of payment for their work. The big company may have other strategic schemes in mind like, perhaps only making their wares integrate with the open source software. For example, although the Linux kernel will work on a number of CPUs, it is still primarily targeted for the legacy and proprietary x86 processors. In my opinion, the Linux kernel would be better if it worked well on lots of cores, especially open cores such as massively parallel mini CPUs.

Speaking of abandoned open source projects, there is also a lot of dead code which is owned by companies in the name of intellectual property, and failed projects. Call it corporate abandon-ware. Corporate abandon-ware is not easily available to just any developer who feels like picking it up. On the other hand, abandoned source projects can be more easily revived if a developer feels inclined to do so, and we see this happen.

C++ stinks for systems level programming. Trust me; done lots. The quickest solution when faced with C++ low level software is to quickly re-write it in C. Nice thing is, it usually ends up more concise, more reliable, and more maintainable.

Trust you? Why?

Yeah, I've also rewritten bad C++ code in C. I've also then taken the improved C code and rewritten it back to C++, with yet further improvements in concision, reliability, and maintenance, (though, granted, for a restricted set of maintainers).

Just for the record, I define maintenance as non-trivial extension of functionality, and not as continuing development with cheaper and more poorly trained resources. Repairing bad code that never could have been correct in the first place I tend to regard to as "emptying diapers".

I always end up repeating the same observation in these C++ discussions: the people who complain most bitterly about C++ tend to be the same people with low regard for their coworkers and their coworker's work output.

I would only choose to use C++ for a project where I had high regard for the other programmers involved.

Most likely, if that same crappy coworker had written the code in C originally, you would have rewritten it to improve concision, reliability, improve maintainability. Only you would have complained less, because rewriting bad C in good C requires less keyboarding than rewriting bad C++ in good C (thought generally little real difference in mental effort).

On the whole, competent C++ programmers tend to code their loops more correctly than most of the C code I've come across. A common meme in C code is to embed five return statements in a deeply nested loop to "handle" error conditions, though usually these nested return statements do a better job of creating error conditions.

In C++ the tendency for novice or mediocre programmers is to invent classes or class hierarchies with no real utility. If the class manages its own memory, it's almost certainly incorrect, though the incorrectness might not show up until the class is used differently in future (such as contained in an STL container).

I wrote my last significant systems programming project in C. In the cases where I wished I had templates available to optimize some constructs at compile time (single-reader single-writer synchronization primitives used heavily in interrupt context), I did hideous things with #define macros that I can assure you will not be maintained lightly. Templates would have accomplished this task with the same (or even better) performance, at a higher level of abstraction, with better safe-guards against incorrect use.

At the end of the day, it was only about 5% of my code base where the limitations of C required putrid convolutions with the C macro processor. If I had programmed in C++, 5% of my code base would have been devoted to hiding the ugliness of C++. Different rug, same difference.

I'm aware of many non-portable constructs in C++. Almost all of them inherited from C. Most of the C++ portability problems were a transitional effect when the standard got fairly far ahead of the compilers.

Nor do I understand the complaint about C++ lacking a standard ABI, either. That's been in the works for years:

http://www.codesourcery.com/cxx-abi/

Again, it's a matter of having access to mature compilers that actually implement this ABI now that we have it. By that standard, C wasn't portable in the 1980s, as I almost always discovered compiler bugs porting C code from one compiler to another, and rarely was I brave enough to link objects compiled by different compilers.

However, I never blamed the C language for that state of affairs.

If you measured the abstraction of a language with a thermometer, C would read about 10 degrees. Kelvin.

C++ probably has more defects than any other language I know. On average, these defects are less fatal than advertised by

It'd be nice if C++ could standardize their binary representation, even if it's only a standard valid per platform.

Yes. They could call it cross vendor C++ ABI or something.

You could always take a look at VSIPL++, which is probably the next best thing (and a lot of fun as well).

QMTest is an open-source testing framework that you should try. Fairly simple, adaptable, extensible. (Full disclosure: It's made by my company, but not by me. From reading the mailing lists, we get lots of kudos, so presumably it's working. *grin*)

As for other tools:

• avoid Rational Rose like the plague of death. I used it for a year at a previous job, and had nothing but painful user-interface experiences and craptacular code to show for it.
• CVS makes for a decent revision control system, but its limitations are a pain to work around. Subversion is considered mature, and Monotone is supposed to be quite nice, but I have no first-hand experience with them. Arch is suitable for small projects but does not scale (also, its author is an asshole, so you have no support there).
• Unless you need to support some exotic environments, the autotools (autoconf/automake/libtool) have become more trouble than they're worth. Any of the mainstream make(1) implementations -- GNU Make, BSD Make, Solaris Make, etc -- will have enough extensions to let you do just about everything a build system needs to do. GNU Make is particularly rich, but use its features sparingly or your makefiles become undebuggable.
• If you do need to support exotic environments, or think you might someday, then autoconf is your friend. Automake used to be friendly before they went overboard with it, now it's just bloated and broken; use Make extensions instead. Libtool has never been anybody's friend; more time has been put into making and debugging and debugging and debugging libtool than has ever been recouped by its wrappers -- use ELF binary format and be done with it.
• Doxygen and Synopsis are both highly capable documentation tools.

bladesjester raises a good point. As an answer, I'll point to my own current job, where I and everyone else telecommutes. Including the boss.

This raises its own unique problems of visibility and communications. (We're comfortable with our solutions, which I won't yammer about here. But these problems did need to be addressed, and they won't go away on their own; if your company tries something like this, you will need to actively tackle them.) If solved, though, telecommuting makes for a very nice visibility levelling field.

They specced out C++ ABI and libraries this time.
This is a nice addition, since many developers prefer C++ in spite of considerable rifts between it and the Unix culture.
At the time LSB 1.3 was written, there was no open C++ ABI standard, and the issue was left dangling. There is such an ABI now, and g++ supports it fully. In fact, the entire LSB 2.0 C++ spec is written around libstdc++ from gcc 3.x.

I get the impression that when you move above vanilla C code (eg C++, libraries distributed in binary form only), different compilers don't play so nicely. (Just like gcc 2.9x versus gcc 3.x).

Some examples:

See here for some info on the common C++ ABI for g++. I think everything discussed on this thread (including vtable layout) is mentioned as part of this ABI.

The Macintosh ABI covers: The PowerPC ABI, Structure Alignment and Bit Field Layout, Name Mangling, Class Object and V-Table Layout, RTTI, Exception Handling, Special C++ Calling Conventions

The Sub C++ ABI covers:

The C++ ABI includes the C ABI. In addition, it involves the following features: layout of hierarchical class objects, i.e., base classes, virtual base classes layout of pointer-to-member passing of hidden function parameters (e.g. this) how to call a virtual function vtable contents and layout location in objects of pointers to vtables finding adjustment for the this pointer finding base-class offsets calling a function via pointer-to-member managing template instances external spelling of names ("name mangling") construction and destruction of static objects throwing and catching exceptions some details of the standard library implementation-defined details typeinfo and run-time type information inline function access to members

The name-mangling algorithm is part of the ABI, because it defines how a compiler must generate external references and definitions for program entities. If two compilers or compiler versions do not mangle equivalent declarations the same way, a program composed of parts compiled from the two compilers will not link correctly.

Enough said?

Of course, a vendor could choose to follow the C ABI but not the C++ ABI. That would give you the ability to at least call native C functions. But disregarding the platform ABI for any language is not something that a vendor would ever do lightly.

And the third issue is how to represent exception-handling information, and the fourth issue is how to deal with typeinfo, and the fifth issue is initialization and destruction of namespace-scope objects, and the sixth issue is handling of covariant return types, and the seventh issue is merging static data in inline functions, and the eighth issue is representation of pointers to members, and...

A C++ ABI has to cover an awful lot of things. It's much, much more than just name mangling; that's one of the easy pieces.

gcc's C++ ABI is docuemented at http://www.codesourcery.com/cxx-abi/abi.html.

Well, it's not only name mangling, but also how exceptions are handled, how memory is (de)allocated, etc. A C++ ABI is more than just name (de)mangling.

OTOH, there is an ongoing effort to define a common ABI for C++, and GCC 3.x uses that: see here for more info.

What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.

Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.

PostgreSQL has regression tests.

There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit in one of my projects.

The Boost code has automated testing.

There's a project called qmtest.

The Wine people have recently started using regression tests.

Somebody ought to tell these guys that the rest of the world has migrated to C++.

Oh really? Did the rest of the world settle on the ABI then?

So they've gathered a lot of requirements and done a lot design, but, as the lady says, "Where's the beef?" Why do all this work to replace open source tools that already exist? Why not take those tools and contribute back to them, or if the project owners don't like the contributions, take the things they like and build from there?

Perhaps this from their web page: "The Advanced Computing Laboratory at Los Alamos National Laboratory is providing $860,000 of funding for Software Carpentry, which is being administered by Code Sourcery, LLC." And this: CodeSourcery also provides training and strategic consulting services for companies considering the adoption of free or open source software.

Why use the MIT License? Why develop in Python? Why require that the submissions to the design competition not contain any source code? They require a language but not any source? Am I being too cynical in seeing how, after all this contributed design, coding, testing, etc is done, at taxpayer expense, Code Sourcery is now in a tremendous position as the sole-source solution for support and training to the shops that choose to use these tools? And to notice that choosing the MIT license allows them to take and wrap up all the source code into their products and not give back anything? These are questions that either are in the FAQ but not clearly answered, or not spoken about. Even the SC site itself has been retired and archived.

Thanks, I'll stick with XUnit, Bugzilla, cvs (and subversion when it's ready. For build config tools, well, if you do cross-platform C and C++, then autoconf or its successor, but that's just for one language and set of development requirements.

I'll be interested to see if anything widely used comes out of this exercise. So far, of the all the tools implementations promised for "Summer of 2001", we have QMTest 1.0. The rest? Late and unfinished.

So they've gathered a lot of requirements and done a lot design, but, as the lady says, "Where's the beef?" Why do all this work to replace open source tools that already exist? Why not take those tools and contribute back to them, or if the project owners don't like the contributions, take the things they like and build from there?

Perhaps this from their web page: "The Advanced Computing Laboratory at Los Alamos National Laboratory is providing $860,000 of funding for Software Carpentry, which is being administered by Code Sourcery, LLC." And this: CodeSourcery also provides training and strategic consulting services for companies considering the adoption of free or open source software.

Why use the MIT License? Why develop in Python? Why require that the submissions to the design competition not contain any source code? They require a language but not any source? Am I being too cynical in seeing how, after all this contributed design, coding, testing, etc is done, at taxpayer expense, Code Sourcery is now in a tremendous position as the sole-source solution for support and training to the shops that choose to use these tools? And to notice that choosing the MIT license allows them to take and wrap up all the source code into their products and not give back anything? These are questions that either are in the FAQ but not clearly answered, or not spoken about. Even the SC site itself has been retired and archived.

Thanks, I'll stick with XUnit, Bugzilla, cvs (and subversion when it's ready. For build config tools, well, if you do cross-platform C and C++, then autoconf or its successor, but that's just for one language and set of development requirements.

I'll be interested to see if anything widely used comes out of this exercise. So far, of the all the tools implementations promised for "Summer of 2001", we have QMTest 1.0. The rest? Late and unfinished.

I checked the downloads page and found a Windows download for QMTest 1.0. Can't wait to try it out.

I checked the downloads page and found a Windows download for QMTest 1.0. Can't wait to try it out.

The software carpentry project/competition had a lot of useful information and implementations of build tools. You may want to read about them to weigh the pros and cons of current build systems. You may even want to use some of their implementations.

software capentry.
SC Config is the one that is of interest to autoconf alternative, and contains links to 4 alternatives (BuildConf, ConfBase, SapCat, Tan).

The software carpentry project/competition had a lot of useful information and implementations of build tools. You may want to read about them to weigh the pros and cons of current build systems. You may even want to use some of their implementations.

software capentry.
SC Config is the one that is of interest to autoconf alternative, and contains links to 4 alternatives (BuildConf, ConfBase, SapCat, Tan).

The new ABI for g++ is not standard...

Depends on what you mean by "standard". It's true that the C++ standard doesn't specify a C++ ABI. (It can't, since an ABI necessarily depends on the platform.) However, the new ABI for g++ does conform to an informal standard defined in http://www.codesourcery.com/cxx-abi. This ABI was defined cooperatively by a number of companies with an interest in C++ interoperability; it was originally defined for the Intel Itanium, and was later generalized to other platforms.

...because those maintainers in a position of authority (mostly the Steering Committee) have been too busy getting 3.0 ready for release. Herb Sutter had contacted the GCC list but apparently got no reply.

As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

The last releases, 2.95.x, as well as RH's snapshot-based spinoff of 2.96, all shipped with the old, nonstandard, noncompliant v2 C++ library, which has been mostly unmaintained for years.

Everybody's been working on the rewritten-from-scratch v3 C++ library, which has ISO compliance as its primary goal and criteria. If you get one of the nightly 3.0 build snapshot RPMS, you'll find that the new C++ library is the default.

When will 3.0 be released? Sooner, if you help.

g++ comes close, but still enough annoyances to be, well, annoying

Got a few spare CPU cycles? Help us test the 3.0 prereleases. You can download freshly-built and working RPMs from http://www.codesourcery.com/gcc-snapshots/ and run your favorite C++ through it.

The C++ library has been completely rewritten. It wasn't stable enough for 2.95 (or RH's 2.96), and since then it has depended upon recent changes in the compiler itself, so it didn't get included in 2.95.3. Someone else on this page was complaining that "even g++ doesn't have fully-templated iostreams like the standard says," but the new library always has. (It just hasn't been turned on by default in any existing gcc release, is all.)

There are other changes as well. Some really cool ones are already in the tree but won't be included in 3.0; we decided to wait until 3.1 for major user-visible features. The big (IMHO) change for 3.0 is the vendor-neutral ABI for C++ that will let you link code compiled from different compilers.

When will it be released? Sooner, if you help.

g++ comes close, but still enough annoyances to be, well, annoying

Got a few spare CPU cycles? Help us test the 3.0 prereleases. You can download freshly-built and working RPMs from http://www.codesourcery.com/gcc-snapshots/ and run your favorite C++ through it.

The C++ library has been completely rewritten. It wasn't stable enough for 2.95 (or RH's 2.96), and since then it has depended upon recent changes in the compiler itself, so it didn't get included in 2.95.3. Someone else on this page was complaining that "even g++ doesn't have fully-templated iostreams like the standard says," but the new library always has. (It just hasn't been turned on by default in any existing gcc release, is all.)

There are other changes as well. Some really cool ones are already in the tree but won't be included in 3.0; we decided to wait until 3.1 for major user-visible features. The big (IMHO) change for 3.0 is the vendor-neutral ABI for C++ that will let you link code compiled from different compilers.

When will it be released? Sooner, if you help.

What I would like to see is an implementation standard for C++

What you're looking for is called an ABI (application binary interface). And, of course, what you really need isn't an ABI, but an ABI for each platform you care about. Since you mention Sun Forte, for example, you probably care about an ABI for Sparc/Solaris.

Some ABIs already exist; they're usually defined by platform vendors. Sun, for example, has published its C++ ABI.

There's currently a multi-vendor effort to write a C++ ABI for Unix (various flavors, including Linux, Solaris, HPUX, and IRIX) running on Intel's new IA-64 architecture. The work is almost complete. The ABI is necessarily quite complicated, of course.

I don't see that this can ever be something that the C++ standardization committee can deal with, since an ABI has to involve a lot of very specific platform issues. (Which register you use for passing which argument, etc.)

Software Carpentry is running a contest with $200000 in prizes to be given away. Of course the final product will be coded in Python but that doesn't mean you can't prototype in Perl (although in a close match...).
Heh, I see a ton of Perl vs Python articles, it amazes me how people can completely miss the point. Research Python a bit. Research Java a bit. Python is a more flexible Java. Python's support librarys are inherited from too many open source projects to mention. Java has a ton of Sun proprietary standard extensions. Plus hopefully the one you want coming soon =) Sorry to be a bit off topic here, but go check out the above site for the money, the tools they want to develop will benefit the entire open source community regardless of language.
And of course if you want to check out Python, go here.

There are an awful lot of one-off hacks that have no real internal consistancy.

Well, part of the problem is the lack of consistency between "UNIX-compatible" platforms. In particular, take a look at Motif; "Where's Motif" is a game somewhat like "Where's Waldo", except that it's not actually fun - OK, is it in /usr/dt, or /usr, or /usr/X11, or /usr/X11R N, or in some random location for third-party packages (although the "I installed package XXX in some random place" problem is generally handled in autoconf with a --with-XXX= YYY option)?

Note the quote at the beginning of the autoconf Info file:

A physicist, an engineer, and a computer scientist were discussing the nature of God. Surely a Physicist, said the physicist, because early in the Creation, God made Light; and you know, Maxwell's equations, the dual nature of electro-magnetic waves, the relativist consequences... An Engineer!, said the engineer, because before making Light, God split the Chaos into Land and Water; it takes a hell of an engineer to handle that big amount of mud, and orderly separation of solids from liquids... The computer scientist shouted: And the Chaos, where do you think it was coming from, hmm?

---Anonymous

autoconf is trying to cope with the chaos.

A complete "capabilities" API for UNIX-like systems. In other words, a programmatic way (from the language of choice) to determine how the local system compares to a set of metrics like "do I have gcc" or "is this Red Hat 6.1 or later" or "what is the standard include directory list for C++".

"Is this Red Hat 6.1 or later" isn't a capability; presumably the package cares because RH 6.1 or later behave differently from some other systems - but the package presumably cares about some particular difference, and that'd be the capability you'd want to check.

The API would, of course, have to be independent of the questions you ask it, so that arbitrary questions can be answered, perhaps with "I don't know" as an answer; the set of questions a package might need to ask about the system on which it's being built/installed is open-ended, so you can't just come up with a fixed set of questions that suffice for all packages.

Given that, either it would have to be able to somehow deduce the answers to those questions without the cooperation of the system - which means, in effect, reimplementing autoconf - or it'd have to assume that the OS and the third-party packages installed atop it would supply those answers, which would require that the OS know about this mechanism and come with answers and that third-party packages know about this mechanism and use some other API to supply answers.

(This would also require that programmers using third-party package X for their software be able to find all the questions to which third-party package X supplies answers - and hope that they don't need to ask a question about that package to which the third party in question failed to supply an answer.)

A configuration language (preferably built on something a little more powerful and flexibility than m4) which can be used to generate headers, Makefiles and other pre-processed items by using the above API.

Perhaps something along those lines (although not necessarily using an API of that sort) will come out of the Software Carpentry competition. (And, if so, it'll use Python, as per the rules of the competition.)

Realistically, your average project should not have to look like more than:

buildmode: gnome_coding_standard
require: c(ansi,longlong), gtk
build_lib: fizzle(fizzle.c)
build: fazzle(fizzle, fazzle.c)

Unfortunately, many projects aren't necessarily "average". Ethereal, for example, doesn't "require" libpcap, it just disables packet capture if it's not present (and it has to go through some pain to try to find it); it doesn't "require" UCD or CMU SNMP, it just disables fancy dissection of SNMP packets if it doesn't find either of them, and it attempts to work with either of them; and it doesn't "require" libz, it just disables reading compressed capture files if it doesn't find it, and it requires not just libz, but a version of libz with particular functions in it, in order to support reading compressed capture files (as it doesn't just read the capture file sequentially).

[From the Software Carpentry project coordinator]

Thank you all for your postings regarding the Software Carpentry project. To answer some of the points that have come up several times:

This is a design competition, rather than a programming competition. Good entries should be relatively language-neutral --- we believe that at the 5000-word level, the similarities between modern object-oriented languages (C++, Java, Python, etc.) are more important than their differences.

Designs based on existing tools are very welcome. If, for example, you think the only way to meet the criteria for the "build" category is to extend the syntax of standard Makefiles, then please submit that as a design. (However, for the reasons discussed in the FAQ, if your plan for an implementation is simply to provide a Python scripting interface to GNU Make, you'll have to convince the judges that there's no "pure Python" way to achieve the same ends.)

No, Software Carpentry is not a company looking for some publicity. The project is being funded by Los Alamos National Laboratory, who believ that computational scientists and engineers need easier-to-use software engineering tools, and administered by CodeSourcery, LLC, who believe that those tools would be of use to the whole Open Source community. The FAQ talks about LANL's reasons for funding the project, as does this article from Doctor Dobb's Journal.

Yes, one of the project's goals is to give up-and-coming software designers a chance to get some attention, just as architects and classical musicians do.

Yes, the competition is open to submissions from any country.

No, this is not part of some perfidious Pythonesque plot for world domination :-). We thought very seriously about using Perl for the implementations, but after teaching classes in both Perl and Python at Los Alamos National Laboratory, came to the conclusion that the latter had a gentler learning curve. (This is not meant as disparagement of Perl as a tool for full-time professional programmers, it is simply an empirical observation of computational scientists and engineers.) Neither Guido nor any other member of the Python development team had any part in setting up the project, choosing Python, or choosing the competition categories.

Thanks for your posting regarding the Software Carpentry design competition. To answer your first point, S.C. is not a company --- it is a project funded by Los Alamos National Laboratory (whose scientists and engineers need software tools that are easier to use), and administered by CodeSourcery, LLC (which believes that the project will further the aims of the Open Source movement).

Your points about encouraging secrecy and non-cooperation are addressed in the FAQ. As for preventing people from fixing the things that are perceived to be broken in existing tools, that is certainly allowed --- we welcome designs based on existing software, as long as those designs include a scriptable Python interface. (I personally believe that a re-design that takes good ideas from several existing tools is more likely to win, but I'm not one of the judges...)

Thanks again for your posting,
Greg Wilson
http://www.software-carpentry.com

Thanks for your posting. In answer to your first comment, no, this isn't a company --- as the project home page and FAQ explain, this is being funded by Los Alamos National Laboratory (because scientists and engineers need better software tools), and being administered by CodeSourcery, LLC (who believe that it will further the aims of the Open Source community).

As for existing tools being "good enough", that's addressed in the FAQ as well (but yes, we did forget about sendmail, and will correct that).

Finally, as for this being part of Guido's grand plan, he was not involved in the project in any way until after it had been launched --- in fact, he was the last-but-one addition to the list of judges.

Thanks again for your posting,
Greg Wilson
http://www.software-carpentry.com