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...
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...
FYI, one of the categories in the Software Carpentry project's first design competition is a platform configuration handler to supercede autoconf. For details, please see:
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 for your post. In fact, neither Guido van Rossum nor any other member of the core Python development team was involved in setting up this proposal; Guido was invited to be a judge only after the project's funding had been secured (and in fact was the last-but-one judge to be added to the list). The FAQ discusses our reasons for choosing Python --- it was initially going to be Perl, but after teaching courses to scientists and engineers at Los Alamos for a year and a half, we believed that something simpler was necessary.
Thank you for your posting regarding the Software Carpentry design competition. In answer to your point about "educating new developers", please check out the project's white paper. That was the first thing we tried, but again and again we found that the "accidental complexity" of existing tools was getting in the way --- so much so that intelligent, highly-motivated scientists and engineers were choosing not to use the tools at all, rather than try to climb their unnecessarily-steep learning curves.
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.
As a footnote to my earlier post, please note that this is a design competition, and not a coding competition. Implementation will eventually be done in Python, but at the level of a 5000-word design outline, most of today's high-level object-oriented languages (C++, Java, Python, Perl, etc.) are pretty much equivalent.
Thanks for your posting --- our reasons for choosing Python are discussed in the project FAQ. In answer to your specific question (about why we didn't choose C or C++), these four tools are mostly concerned with text manipulation, process control, and database access, for which scripting languages (Python, Perl, etc.) are better-suited than stricter compiled languages (C++, Java, etc.).
Thank you for your posting. We chose not to tackle revision control in the first design competition because we felt it was too big a topic --- so far as we know, no-one has done something quite like this before, and we wanted a chance to test and tune the design competition process. There is a fuller discussion of this in the Software Carpentry FAQ (suggestions for additions always welcome).
Regarding the "missing requirement" of a migration path from make, entrants are free to make that a requirement --- part of the aim of the contest is to pool ideas, as well as effort. However, we don't believe that forward compatibility is an "absolute" requirement --- Java GUIs are not forward compatible with the C/C++ GUIs they are replacing, for example, and C was not forward compatible with any of its predecessors.
A note on Brento's comment about IPO'ing being the only way to get recognition: many recent IPO's had their start in Open Source projects (e.g. sendmail). We hope that this design competition will be a way for fresh talent to get recognition. Recognition leads to funding. Funding leads to rapid development. Rapid development leads to a public offering. Public offerings lead to --- hmm, perhaps best to stop there:-).
Slashdot Mirror
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.
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...
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...
No: it's "free software" as in "free speech", not as in "free beer". As Richard Stallman said:
We are awarding prizes because we think people should be rewarded for hard work. The only regret is that we can't award more...
Amen. As the FAQ says:
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
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
http://www.software-carpentry.com
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
[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 post. In fact, neither Guido van Rossum nor any other member of the core Python development team was involved in setting up this proposal; Guido was invited to be a judge only after the project's funding had been secured (and in fact was the last-but-one judge to be added to the list). The FAQ discusses our reasons for choosing Python --- it was initially going to be Perl, but after teaching courses to scientists and engineers at Los Alamos for a year and a half, we believed that something simpler was necessary.
Thanks for your post,
Greg Wilson
http://www.software-carpentry.com
Thank you for your posting regarding the Software Carpentry design competition. In answer to your point about "educating new developers", please check out the project's white paper. That was the first thing we tried, but again and again we found that the "accidental complexity" of existing tools was getting in the way --- so much so that intelligent, highly-motivated scientists and engineers were choosing not to use the tools at all, rather than try to climb their unnecessarily-steep learning curves.
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
As a footnote to my earlier post, please note that this is a design competition, and not a coding competition. Implementation will eventually be done in Python, but at the level of a 5000-word design outline, most of today's high-level object-oriented languages (C++, Java, Python, Perl, etc.) are pretty much equivalent.
Thanks,
Greg Wilson
http://www.software-carpentry.com
Thanks for your posting --- our reasons for choosing Python are discussed in the project FAQ. In answer to your specific question (about why we didn't choose C or C++), these four tools are mostly concerned with text manipulation, process control, and database access, for which scripting languages (Python, Perl, etc.) are better-suited than stricter compiled languages (C++, Java, etc.).
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
Thank you for your posting. We chose not to tackle revision control in the first design competition because we felt it was too big a topic --- so far as we know, no-one has done something quite like this before, and we wanted a chance to test and tune the design competition process. There is a fuller discussion of this in the Software Carpentry FAQ (suggestions for additions always welcome).
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
http://www.software-carpentry.com
Regarding the "missing requirement" of a migration path from make, entrants are free to make that a requirement --- part of the aim of the contest is to pool ideas, as well as effort. However, we don't believe that forward compatibility is an "absolute" requirement --- Java GUIs are not forward compatible with the C/C++ GUIs they are replacing, for example, and C was not forward compatible with any of its predecessors.
Thanks for your posting,
Greg Wilson
Software Carpentry Project Coordinator
http://www.software-carpentry.com
A note on Brento's comment about IPO'ing being the only way to get recognition: many recent IPO's had their start in Open Source projects (e.g. sendmail). We hope that this design competition will be a way for fresh talent to get recognition. Recognition leads to funding. Funding leads to rapid development. Rapid development leads to a public offering. Public offerings lead to --- hmm, perhaps best to stop there :-).
Thanks,
Greg Wilson
Software Carpentry Project Coordinator
http://www.software-carpentry.com