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.
How about some decent documentation for autoconf/make/libtool etc. Everything I've found has either been reference, assumes you already know how the tools work, or is only for setting up a specific type of program.
When I've been able to get these tools to work, they're excellent, but trying to work out how to fix the couple of problems that turn up in each case is extremely frustrating.
That's actually one of the complaints they cite in the contest pages.
However, a lot of the proposed programs (maybe half?) build on prior systems without any real new ideas. Some of the other ones look somewhat vague and use a lot of different terms. I liked the XML description of feature sets, but it looked too complex/verbose.
So I guess I'd rather see all this energy go into coming up with good examples for how to use the existing (robust, working, tried-and-true) tools. As usual, the best reference outside of good documentation is a real-live, working ugly program/script.
(For example, I learned a lot about Makefiles looking at both generated and custom-made ones, so now I have my own hybrid "favorite" Makefile-style...)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Because, quite frankly, they're not so tried and true that they couldn't be made better. What this project does is fascisticly enforce good software design from the get-go, and I'm curious about what results will get produced. And remember, it's largely an intellectual/educational exercise; having the contestants focus on these applications is just a guarantee that whatever is produced has a hope of finding a good home.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
I think the open source community needs to spend more time in the software design phase. Where I work, we don't code until we have TONS of diagrams/description of logic done. Overall, I think it leads to a much better product.
:-(
Documentation and DOL are extremely important... reminds me of a development tool that I have used that would compile psuedo code... haha. Funny stuff.
Have to agree. As it happens, I've been looking around lately for some higher-level design tools, and unfortunately, there's not a lot out there in the free-software realm. freshmeat lists Libero and TCM, which look good, but probably aren't the ultimate in software design.
Speaking of doc, what do you guys feel is the best tool for managing it. I mean something akin to doc++ or Doxygen. Are there any other better solutions?
I haven't really used any of the doc-generating programs out there-- but let me mention gtkdoc, which for C API's is probably the best of them all. (See here for an example-- ain't it beautiful?) It works through Docbook SGML and the Jade processor to produce HTML, TeX, man, and anything else you have a stylesheet for. Unfortunately, the whole thing is a b**** to get working. It's a huge mess of Perl scripts and weird Makefile rules, I tried it one day and barely made it out alive
(But man, results like that GLib documentation would be worth it!)
Of course, however, all those tools assume that your approach to documentation is placing specially formatted comments (Javadoc-style or otherwise) above each of your module/type/function definitions. I don't know of a better way to go about it-- tying the implementation and documentation together makes it hard to neglect keeping the docs up to date-- but it surely isn't the only approach.
iSKUNK!
but maybe we'll see an open sourced win9x compiler
There already is an open source compiler for windows: look here.
--
bgphints - internet routing news, hints and ti
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.
Yu Suzuki
Yu Suzuki
Deamcast. It's thinking.
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.
I really dislike a lot of the things going on with this project. The fact that they mandate the use of Python is one of my primary objections. I personally think Python is a fine language, and I support it's use in general....however, forcing everyone who wants to participate in this project to use Python seems unfair.
That, and I dislike the idea that a single langauge is ideal for all situations. Personally, I think a consistant User Interface to these utilities is much more important than what langauge they are implemented in. If they all work and act similar, then they'll be easy to use. And if people aren't forced to use Python, you might end up with better results....at the least, you'll most likely end up with more results, simply because you aren't locking people out.
When fixing the problem, fix it smartly. I agree with some of the goals of this project, I just really don't like how they're going about it.
Topher
What they are doing looks like an awesome idea. It looks like it will make the development/distrobution of code a lot easier. Props to them.
I think the open source community needs to spend more time in the software design phase. Where I work, we don't code until we have TONS of diagrams/description of logic done. Overall, I think it leads to a much better product.
Documentation and DOL are extremely important... reminds me of a development tool that I have used that would compile psuedo code... haha. Funny stuff.
Speaking of doc, what do you guys feel is the best tool for managing it. I mean something akin to doc++ or Doxygen. Are there any other better solutions?
Catcha later,
Ryan
"Don't nargin your MEX files!"
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.
----------------------------
The only problem I have with it is it is so UN*X centric that it ignores the vast number of Very Very high level development environments that are available on more "traditional" platforms.
.* face="courier new" .*>(.*)</font>!ig
As well as newer, research-oriented languages and platforms which are to Unix and Perl as those are to, say, CTSS and assembly.
For low level problems there is nothing better than a low level language. Extremely sophisticated high level languages like C++ plus STL will always disappoint becuase they are centered around coding tecniques rather than problem solving.
I'm sorry, buty I don't consider C++ to be much sophisticated, or even high-level. It's just as low-level as it was in the days when it was merely the preprocessor Cfront. It's still little more than a portable assembly language with some more-or-less-OO features tackled on. (See my recent post on compared "OO" languages for more on that.) As far as I'm concerned, C++ is mid-level at best; traditional-ish and imperative but relatively abstracted languages such as Perl and Python are high-level, and only those which are radically different from the way in which the computer actually operates (pure functional languages such as Haskell, logic languages such as Prolog, rewriting languages such as Maude, pure OO languages such as Self) can truly be called very high-level. (Of course, some languages span much of the spectrum, such as Common Lisp, which allows you to program at any necessary level of abstraction, from C-like programming with unboxed values, hard pointers and - gasp! - even a GOTO form, to something close to VHL - it fully supports functional programming, and I myself once wrote a three-page "PRolog In Common Lisp" embedder.)
Incidently if you are interested in a programing language where you could insert a diagram try XEROXes "MESA". It alowed you to use the normal VP wordprocessor as your editor. Text in "courier new" was considered compileable code, everything else was comments -- a very neat trick which I have never seen emulated in any other language!
Hrrrm. I might note that this isn't really the best way do do things - it's a better idea to use a structured writing tool such as LyX, with output indicative of content semantics, not of content layout, to write literate programs (as described by Knuth), and have in conjunction with a program (maybe even a plug-in for said editor) to "weave" these programs into compileable code and formatable text, as needed.
In blatant self-contradiction, I now present a hastily written Perl filter which, as requested, turns an HTML file into Perl code.
#!/your/path/to/perl -w
undef $/;
$file = <>;
print '#!/usr/bin/perl -w';
print "# $1\n" if m!<title>(.*)</title>!i;
print "# Preprocessed from $ARGV[0] on ", localtime(time), "\n";
print "# PART $c\n$1\n\n"
while m!<font
&& $c++;
exit;
To the editors: your English is as bad as your Perl. Please go back to grade school.