Software Carpentry Project's First-Round Winners

GenericBoy writes: "The four first round winners for each category of the Software Carpentry competition have been announced. It's really exciting to see all these potential replacements for tools that are in such wide-spread use. If you haven't heard of Software Carpentry yet, they're hosting a competition (for BIG $$$) for developing Free tools in the Configure, Build, Bug-tracking and Testing categories." As source code becomes less and less an obscure concept, it's good to see that some people are working to make its construction less obscure as well.

Comments

Reply from Software Carpentry Project Coordinator

[gvwilson]

My thanks to everyone who commentd on the first-round results in the Software Carpentry design competition. I've replied to a few points directly below. Please note that many of these issues are addressed in the project's FAQ as well.

forcing everyone who wants to participate in this project to use Python seems unfair.

Allowing multiple languages moves the burden of learning new syntax and execution models from developers to users. (Essentially, it allows a minority to be lazy, while creating work for the majority.) Feedback from the 140 students who took the software engineering courses I co-taught at Los Alamos National Laboratory in 1998-2000 was unequivocal: as long as we keep making the tradeoff in favor of developers, people will continue to be frustrated and confused by the tools we build.

As an aside, one entrant from Europe said that he'd be a lot more impressed with programmers' sincerity if they put as much effort into creating documentation in multiple (human) languages as they do into arguing over what (machine) language should be used for coding...

...since winners are chosen on functionality/interface and not on implementation details why does the language matter?

We did ask people to keep their designs as language-neutral as possible, and I for one would be very excited to see implementations of (for example) the winning bug-tracking entry in Perl, Java, and other languages as well as Python. (If nothing else, it would permit a real "compare and contrast" study of the languages.) However, since we had chosen an implementation language, we felt it would be dishonest not to say so.

One posting to this thread said that the discussion list had "wandered off" onto the topic of representing programming languages in XML. This actually isn't off-topic: XML means that we finally have a standard language-neutral way of representing hierarchical data, such as the static dependencies in a makefile. However, we still don't have an equivalent way to represent procedural information (loops, conditionals, etc.). As a result, any non-trivial makefile (or configuration file for any other tool) must be bound to a particular language: most makefiles, for example, are tied to the syntax of the Bourne shell. If anyone's looking for a way to change the world, they could start by fixing this...

The whole idea of free software is just that -- that it's free and is being made to produce good software and not because someone is pursuing a cash prize. A certain project being developed with the Software Carpentry Project competition in mind might be rushed through development just so it can meet the contest deadline. End result: A buggier product with fewer features.
...coding solely to earn money was exactly the concept that free software was supposed to eliminate.

No: it's "free software" as in "free speech", not as in "free beer". As Richard Stallman said:

Having a design competition does not go against the principles of free software. The idealism of the Free Software Movement is not that "there should be no competition". It is that we should work for our freedom as computer users, by writing free software to do all the jobs that matter, and thus eliminating non-free software from our lives.

We are awarding prizes because we think people should be rewarded for hard work. The only regret is that we can't award more...

I'd rather they had specified a means by which scripting tools could plug into the system, so that any language (possibly with a small modification) could be used. Of course, the question then becomes how to plug in...

Amen. As the FAQ says:

Component software is clearly the next big thing in software development... However, while COM, CORBA, and (Enterprise) JavaBeans are becoming more popular, they are still new to most programmers, and still do not have robust cross-platform Open Source implementations.

Less formally, COM is proprietary, CORBA is bloated, and EJB is immature and lacks stable bindings for other languages. Creating a lightweight, usable, cross-platform, multi-lingual component system would be a good way to address the issues that Rob Pike raises in: http://cm.bell-labs.com/who/rob/utah200 0.ps

Another thing that my scan of the site didn't turn up was interfacing to source code management...

Amen again. Everyone who has suggested categories for next year's competition has mentioned version control, and no-one seems happy with the tools we have today. However, we had to start somewhere...

Greg Wilson
Software Carpentry Project Coordinator

Python... but no code?

[Frymaster]

Okay, I admit it's a grand idea... but why have they specified a mandatory language if they insist that entries contain no code? I realize that ultimately, winning proposals will necessitate the writing of code... but since winners are chosen on functionality/interface and not on implementation details why does the language matter? A good flowchart should be equally applicable to all languages and the language should be chosen for reasons of pure implementation expediency.