Slashdot Mirror
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.
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
I'll probably be accused of being a "zealot", but I really think that big-money competitions just aren't in the spirit of free software. There's nothing wrong with receiving some financial compensation for your work, but coding solely to earn money was exactly the concept that free software was supposed to eliminate.
So basically you're saying that free software is supposed to eliminate all commercial software (including free software written by a commercial interest). That is not true: the free software movement was started because (RMS felt that) all software should be free for people to use (and modify and copy and redistribute). And RMS is OK with the sale of free software; see http://www.gnu.org/philosophy/selling.html for more information about this.
Who cares if code is written for no other reason that to make money? As long as the source is available and freely modifiable, it's just as "good" (in the moral sense) as a piece of software written for love alone. It is "free".
Note that personally I think BSD/MIT code is more "free" in the sense of allowing freedoms to the end user. Just to keep people from responding to this with "GPL is not free", etc, etc.
although I didn't send an entry in. I was mainly interested in the "Config" section.
It's been interesting. As soon as the entries were posted, some people who hadn't seemed to have read the spec immeaditly began posting stuff justifying the way they did things. There's nothing wrong with that in itself, but the fact that there was a lot of money hanging over the judges decisions made it worse than most lists - the list has driffed further and further off-topic in the last few days.
As soon as the results were announced, it went pretty quite again, apart from some interesting (but mostly offtopic) discussion of languages which are written entirly in XML.
I'm hoping that all those who didn't win don't abandon the project, but find a way to continue to contribute.
As for those who are saying that they don't see a need for these tools: Neither did I, until I heard some horror stories about people who couldn't build their softwear because of bugs in the build tools on some platforms, and the makefile/autoconfig scripts were so full of work arounds for other (Operating Sytem) problems that no one could figure out how to fix them. These are nuclear physicists we're talking about, too.
Fair isn't the issue, with their choice of Python as the implementation language. First and foremost was their desire that all the tools interoperate as a development framework, and not a whole bunch of non-related tools. Not that they are interdependent, but that they work smoothly together. Partially it was a maintenaince/design thing. Support only one language, as opposed to many/all languages, in the contest.
They never said Python was an ideal language for all situations, just that it did enough well to fit their design. You're right, of course, that allowing other languages creates a bigger participant pool, but adding other languages introduces other support problems; language compatibility across platforms, versions, OSes, patches, etc. It's tough enough with ONE language, let alone many/all if they didn't require Python.
I mean, part of the initial design document was ease of use, maintenance, and management. Single language seems a reasonable way to get this. Single OS is not, but notice they support NT and Linux. Hopefully Mac and other Unix support will fall out of the fact that it's Python code(Python runs on other systems, of course), and that no Win or Linux dependent design is implemented.
-AS
-AS
*Pikachu*
...why we need these other tools?
Not only are the standard tools good, but there are already alternatives! (cook, autoconf, configure, blah blah blah...)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Also there is the question of migration: suppose I want to use one of these super-wizzy tools on my existing project: can I just feed my existing makefiles into a converter to set them up? If not, then they will have a hard time gaining penetration, since old projects will never move over, and many "new" projects start out as mutations of old projects.
Another thing that my (cursory) scan of the site didn't turn up was interfacing to source code management: I'd like to see a good integration into CVS, so that I can easily build different trees from my source base.
Lastly, while they are requiring some degree of cross-platform support (IMHO if you can get the tools working under NT as well as *nix, you have a high probability of getting them working under any OS) do they have the ability to support building the same project on different hosts without modifying the project? For example, I develop embedded systems running VxWorks: I can theoretically build under NT or Linux, but keeping my make files so that they will work under both is a nightmare (Thank you Microsoft for not using / as a directory seperator! Thank you for not having a decent shell! May I have another?)
I'm just glad somebody is looking at this part of the development process and saying "That's great, but is there a better way?"
www.eFax.com are spammers
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.
2 1337 4 u!
Well, if you went to the webpage and actually read the entries, you'd see that each of them justifies their existance as part of the proposal.
blah blah blah is a very weak argument compared to the statements found, for example in the paper for BuildConf. Also you only list two programs, cook and autoconf. Configure, last I checked, is an autoconf generated script.
Of these programs I've only used autoconf, and I must agree with the author of BuildConf, that it's poorly documented and confusing. It forces a syntax on you (m4) which is rarely used in other situations. It does many things right, but this, combined with a lack of good documentation on it, is a fatal flaw.
And more importantly, why does it matter if we get other, better tools? You may prefer better documentation to autoconf, I may not. Does that make me wrong, or you wrong? not at all. There's room for all of us, and software darwinism will help choose the best (most adaptable, most powerful, most appropriate) tool.
----------------------------