Develop Reference

Resources containing cross-language benchmarks?

What resources are available that use benchmarks for comparing programming languages?
I am interested in both
How quickly a program in a given language can execute a given benchmark?
How many lines of code are required in a given language to implement a given benchmark?
There is a long-standing web site called the Computer Language Benchmarks Game, originally created by Doug Bagley as the "Great Computer Language Shootout". (You can view a little history at Portland Patterns Repository.)
Is anyone aware of other resources that enable programmers to compare performance and size of programs written in different languages?

Alternatives
After a quick google search, I found a couple other sites where benchmarks for various languages have been done. Some other sites mention the programming language shootout site that is currently down.
There is a CPAN module for Perl that uses the same code found on that site.
Google has a directory where pages on this topic can be found. I have not found any yet that are as comprehensive as the page you speak of, but there are certainly other resources out there for comparisons.
Archived / Cached Page
If you're only seeking some information there, you can view archived pages of the site using the Wayback Machine or Google's cached version. Try searching Google with "site: shootout.alioth.debian.org" and click on the "Cached" links for the pages you find.
Find the Author?
Perhaps the best option is to try to contact the owner of the old site and find out what happened. The author mentioned in the BSD licence on this page is "Brent Fulgham". He may or may not be the one to contact.
Wait until Alioth is Fixed
As #ioguy found out, Debian's Alioth server that hosts the site in question is currently under maintenance. I would suggest subscribing to the debian-devel-announce mailing list for updates, and an idea of when it may be fully functional again.
If you find problems in the future, you can probably post to the debian-user list.

Each year there are two or three
isolated blog posts that claim to
compare performance and size of one
or two programs written in different
languages.
As a resource the blog posts fail for obvious
reasons, most obviously:
not updated with newer versions of the language implementation
not updated with better programs
Every couple of years someone
dissatisfied with something about
the benchmarks game (often some
detail about the code repository or
website technology) starts a project that will
fix everything they dislike about the benchmarks game.
As a resource the most obvious problem with those
projects is that they never seem to get
close to publishing performance
data.
Every year some group of programmers
campaigns to have language X
included in the benchmarks game,
while some other group demands that
some program is included (or
excluded).
Sadly, they rarely accept that among
the resources provided by the
benchmarks game are
scripts they can use to make and publish language performance
measurements
examples of which basic information (language version, build
commands, run commands, measurement
techniques, ...) is required to provide context for the measurements.
They rarely accept that they are
empowered to create what they wish
to see.

The benchmarks game website is now back to normal!
From Friday 20 May 2011 through Monday 23 May 2011, ALL alioth.debian.org subdomains were down - because the alioth admins were upgrading "in every way we can find: kernel, Debian release, FusionForge software, hardware, and so on."
In addition, making the benchmarks game website work again required:
installation of the GD library on the new server, for chart generation
basic information about changes to ssh use on the new servers
basic information about the project cvs repository on the new servers
basic information about the project /htdocs location on the new servers
replacement of the long deprecated
$HTTP_GET_VARS by $_GET in a couple
of dozen PHP scripts
Since the performance benchmark site
for Programming Languages (aka
Programming Language "Shootout" &
shootout.alioth.debian.org) is
permanently down ...
The original question was predicated on a false premise.

I've found my software as cracked download on Internet, what to do?

Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
So, after 6 months of hard work finally released my application. Today I found the first web site where people download it cracked, and I was wondering if any of you fellow programmers know how to react to such stuff?
Is there anything the software author can do to get the cracked version offline, or I'm just boned and shouldn't create anymore software, but just work on client's projects? What's your advice? Anybody with experience in that?
edit: programming is what I do- so no question about whether or not continuing, just is that clients pay per project in real money, and I still don't know if indie development would pay at least for the time invested, and now with the cracked download I'm trying to evaluate what to do, and if there's way to react
post discussion: As I see how much interest this question generated I'd say even if not purely programming topic the community needed to say what they think. And I'd say this page became a very good read for any programmer interested in the topic.

Ok, I've been selling software online for almost 10 years. I have had several products marketed to both individuals and businesses.
I am always shocked when I see developers are happy that someone thought their software was worth stealing. I mean, didn't you already know that? Why else would you spend time creating it if you didn't think it was worth anything?
I'd wager you would not say, "Wow, I had some great stuff and feel honored someone went to all the trouble of taking it." if someone broke into your house and stole your property. Stealing is stealing no matter if it is a Porsche 911 turbo, music, software or a pack of gum.
There is also another popular myth that pirated versions do not impact sales. I have done a few different experiments myself and also have friends in the industry that have seen significant revenue impacts due to piracy.
In fact, I had one product that I could always tell when it was keygen'd because sales would immediately dive as much as 70%. I was using partial key verification, and when I updated the verification to make the bogus codes stop working sales immediately went back to normal. I assume you would call thousands of dollars a month a significant impact on sales?
In one experiment I used the partial key verification to redirect customers who entered a pirated key to a special web page that explained they were stealing.
Guess what? Over 50% of people who went to that page bought the software. That almost brought sales back to pre-keygen levels.
Those people would have stolen the software if the code would have worked for them. This is a product with a fully functional 30 day trial, so they had already fully tested the software. Also, the product was under $20 USD, so it wasn't an expensive one.
Other people I know have tried the redirect bogus codes to a web page technique with similar (and sometimes significantly better) results.
I do agree that some people will never buy your software, and you have to balance protecting unauthorized use and inconveniencing honest customers.
But don't be fooled into thinking piracy isn't a big problem and not worth investing a reasonable amount of effort to prevent. People aren't as honest as most of us would like to think.
Update
First I want to say, as I stated in my comment below, I am not going to get into an argument or debate about this--especially one based on semantics. I have debated this for years in person, at conferences, and in private forums. I've heard all the arguments before.
Now I will try to answer some of the constructive questions.
I tried my own experiment on two different products.
One was an Outlook add-in to manage various hidden security settings. It was purchased by both individuals and companies. The numbers above are for that product.
I also did another experiment on a business targeted product that translated database schemas to various formats. This product had slightly less (around 10% less, so 40%) conversion from the page I redirected the bogus keys to.
I also am aware of several business owners that did the same experiment and discussed the results with me in private. These were a wide range of products. Some had a vertical market and some were very horizontal. Their conversion rate on the bogus key page was between 20% and 70%. Even at the low end that's a significant amount of extra revenue.

You may want to add something like this:

If someone thought your product was good enough to be worth their time to crack it, you must be doing something right. Remember that there are more honest people in the world than dishonest and you won't get the dishonest people to buy your product whatever you do. So concentrate on keeping your honest customers happy.

I saw this interesting response today:

Contact the site owner. They should remove the incriminated download. If they don't you'll have to sue them.
Anyway you should accept piracy as a natural part of your software lifecircle.

I have to admit that I haven't read all the answers and the slew of comments, but here my view on the topic:
Concentrate on making it as easy as possible to pay for the software. Think of Steam and iTunes. Dishonest people will always go to great lengths to avoid paying, but I think most people would gladly pay you if you make it easy enough.
Keep the price low. If the price is low enough (say $5), it falls below the threshold of "practically free", and people will start thinking "$5 is nothing, I might as well pay".
These two combined will prevent your honest customers from trying to get a hacked copy of your software.

The most elegant solution I've seen was putting text along the lines on "cracks, warez, keygens, torrent files, free downloads etc. harm the publisher of this software" in small text at the bottom of all your web pages. It games the PageRank and (hopefully) causes users searching to cheat you to be sent to your site.

I would keep updating the software. Sure there must be some bugs to fix and new features to add that your customers asked? When a user has a pirated version and is happy with it finds out that your current version has more features that might be an incentive for him to buy the latest version.
Adding new features doesn't only make your existing customers happy, they also attract new customers.

There's nothing you can do. Once the software is out there, it's out there. Sure, you could send all sorts of legal threats and takedown notices to the sites in question. And then those who acquired the software will post it to other sites.
If the software hadn't already been made available for free, you could cram it full of DRM and copy protection and so on.... which just get cracked. Microsoft must have spent billions trying to prevent people from pirating Windows. I still know a good handful of people who run pirated versions of Windows 7 with no problems.
You can't prevent people from pirating your software. What you can do is make people feel your software is worth paying for. Some developers have noticed some effect simply from posting a polite and personal message on torrent sites. On the torrent for your software, post a comment saying you're the developer of this software, and while you're glad to see that people like it, the money from software sales goes directly to you and your dog and no one else, and you can't afford to keep making software if you don't get paid. So please consider buying a license.
Some companies try to combat piracy simply by treating their customers well. Make it something that people want to use. Sell it at a price that people are willing to pay. Provide extras for paying customers. Provide good support to people with a valid license.
Some people are going to pirate your software. There's nothing you can do to prevent it. And it only takes one copy to appear on one warez site, before it spreads and becomes impossible to take down. On the other hand, those people who pirated it most likely weren't prepared to pay for it anyway. If they hadn't been able to pirate it, they simply wouldn't have used it. So in that sense, you haven't lost anything. Remember who your paying customers are. They are the ones you have to satisfy in order to run a successful business. The ones who don't pay aren't your customers, so they're a lot less important.
You might find this blog post an interesting read too.
And finally, because some people find it hard to accept that the world isn't black and white, and like to think that anyone who doesn't equate software pirates with some kind of evil zombie demon hitler are secretly pirates themselves, let me be absolutely clear:
I do not condone piracy. I am not saying you should love software pirates or treat them like your own children. I am merely saying that it is an unavoidable fact of life, and too many companies spend huge amounts on "piracy prevention" which doesn't prevent pirates from using their software, but does make the software less convenient to use for paying customers.

Make you software work as SaaS in some cloud, so you'll be able to sell it for some traffic/features value, and will prevent it from cracking as it is.

This is obvious a highly personal reaction. I don't expect anyone else to share it: Celebrate! Someone thinks your software's worth stealing!
(a) It's impossible to prevent people from stealing your software,
(b) trying to only irritates your honest customers and
(c) people stealing your software means that you have solved the single biggest problem: obscurity. If no one knows of your program, no one's buying it. At least if someone's taken the trouble to crack your software, people know about your product. Another answer here offered several interesting ways of getting people to pay for your product.

Change your business model. Selling something that can be duplicated at zero cost and no limitations, isn't a smart idea.
Copyright and patents are only fake restrictions that can hardly work in the digital age.

The good news is that if somebody bothered to crack your software that means it is popular/useful enough that people actually really want to use it... so you must be selling some!
Secondly, there is a school of thought that says that usage of the cracked version may actually boost awareness of your product and result in MORE SALES long term... Try to think of it as a free marketing campaign... :-)

This reminds me of the autodesk/kinetix response, tho they claimed that the response was a complete accident, a byproduct of the crack itself.
A cracked version of 3DSMax had a nasty side behavior - each time it opened a model file it corrupted the vertex coordinates just a little bit more- not enough to be noticable on any given run, but over time, a lot of damage could take place. The cost of the program might be thousands, but the cost in time and dollars to repair the damage dwarfed that.
The mfgr claimed this was a complete accident/side effect of the crack, and to their credit here, I believe repaired something in their software - that said, they certainly delivered a powerful message to their user base......
Don't get the wrong idea - I'm not recommending this, especially since IANAL - on the other hand, I've always found it's an interesting anecdote

Just take what money you have, and move into another business. I gave up coding after the last bubble burst, and now own a couple of gas stations.
My staff have shotguns to protect our product, it seems to work better than vague legal threats and keygens/drm do in the software world.

It's not possible to make your software crack-proof.
However, there are legal things you can do. You can send cease-and-desist letters to the owner of the website to remove the cracked version from their website. You can also sue. You can contact the ISP of the owner of the website to let them know of the illegal activity of that website owner.
But in short--there's not really a whole lot you can do otherwise.
About a decade ago I created some software for sale that was quickly hacked. Then I created a version with a rather complex anti-hacking scheme in it with a scary (but meaningless) warning that only popped up when partial hacking was attempted--the warning threatened to destroy all data on the C: drive. That seemed to work (it's never been hacked--though its now completely obsolete), but only introduced some ugly support nightmares.

Contact Google with a DMCA notice, and have the page removed from the search index. This will make it difficult for people to find the pirated version.
http://www.google.com/support/bin/static.py?page=ts.cs&ts=1114905

My friend wrote this article describing how he handles this situation.

You never told us if the cracked version is from a demo version or not - but you should identify this directly from your builds.
Is my practice to identify customers in the build's with a ID constant in several places. That way I can find the source of the leak just downloading the cracked one.
Demo versions are prone to be cracked (but you should identify them too - one ID for tucows, other for major, etc). I don't have a easy way for that, except if you can consider online usage all the time.
Regards
Rafael

I believe that widespread software piracy usually means you're charging way too much for the basic version of your product, and that you'll ultimately be able to make much more money by drastically lowering the price of this entry edition - the market may even want this edition priced free. The key is then to properly segment the market to figure out who is able to pay what.
As an example of this, look at Visual Studio vs Delphi/C++ Builder. The two used to be very competitive, with old Broderbund/Borland perhaps even ahead of Visual Studio at one time. And then Microsoft figured out they needed to give away a base version of Visual Studio that honestly has enough features for most of us to get by if we really needed to. The result? Delphi/C++ Builder completely lost the low end of the market where the students are that feed into the more-lucrative professional market. Now they're fading fast into irrelevance.

It's simple. In the old days, if you couldn't afford or didn't want the cops to protect your well, or if -- in fact -- the cops didn't care, know what you'd do?
You'd POISON THE WELL.
If I were you, I'd increase prices by 5%. Then I'd release a fully-functional demo that says "Registered to [crack]" that accidentally cracks up and malfunctions.
Publish this new version everywhere. Bitorrent, edonkey, usenet, all the pirate sites you find. Drown out the competition!
Then direct cracked users to customer support and offer them a 5% discount if they register now and give the site where they downloaded the crack.
Use the crack as a promo code to drive sells.

I'd like to add, not paying for your software is like not paying your taxes. You may be getting ahead, but you are doing so by screwing everyone around you.

Just accept it. most people that are pirating your software probably wouldn't have bought it anyway. But that's not a reason to stop making software, pretty much every major piece of software gets cracked and pirated, but Adobe, major game studios, etc. are all still in business.

open source your software, then you won't have this problem :-)

I was so infuriated with some of comments and answers that justify software piracy that I had to write long rant: Is Software Piracy Stealing? .

Consider piracy as a business expense that comes with the territory of having a product that can be sold to thousands at near zero product cost. We can't have it all our way.
Just use basic protection to stop customers passing it around. Anything more is not worth the time and expense.
Don't make your paying customers jump through licensing hoops. Often I'll pay for a product, get driven crazy by the licensing scheme and seek out a cracked version.
Make trials not by period but by hours used. It's easy to get diverted and not have a chance to evaluate the software. Most people won't consider to ask for an extension.
Consider if you've pirated music CDs, movies, software etc. yourself and rest in peace knowing it somewhat evens out.
Always have different levels of your product. People don't want to pay big bucks for a product they only use 10% of.
Make the product fantastic. Customers will eagerly await the latest version and not want to wait for a crack to appear. The users of poor products think, "I hate this product, it's full of bugs, but I haven't found anything better yet". That's inviting piracy.

I find it disappointing how much people accept defeat nowadays and ignore ethical trespasses and things like fairness.

Make sure you properly version every update and version of teh product. Then store the hash of your executable file on a server and on first launch check to see if the exe file is altered. then you can take action if it is, like closing the program or deleting some of the file You installed so that the program won't start

I don't know for sure what I would do in your position, but at least one developer who found his cracked software available as a torrent emailed the host to complain -- not about the crack, but about the quality of the crack. It seems that the cracker didn't do a very good job and made the software less desirable. The developer was apparently horrified that his product, with his name, was going out to people and would ruin his product's good reputation, and demanded that if someone was going to crack it, that they needed to do a better job!
This story showed up on Slashdot:
Developer Demands Pirate Bay Not Remove Torrent

Also consider price. I have no idea what your software is but there are multiple markets for every product. For example Photoshop has a normal version that is a little out of the cost range of anyone wanting to touchup their vacation shots. For this reason they make elements, it doesn't do as much but it does serve a market. If your software is expensive and of limited personal use try releasing a home version. A trial version, an ad supported version.
What every you don't attempt to detect hacked versions. This type of DRM only annoys real users

Best way to manage projects [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is a best way to organize many software development projects, interaction with clients, project documentation, sources, emails, knowledge, time tracking, issue and features tracking, support for releases and versions etc. for a small company?
For me (and I believe for many others) it is obvious that it must be some sort of web-based solutions. It would be great if it could provide an interface for iPhone (if not, it is also OK).
Important thing: it must be hosted on our servers, so PHP + MySQL is the best platform so far.
I have found the following system to consider:
http://www.activecollab.com/ (but I didn't found issue tracking as well as support for releases and versions, so it is not the best match for software development company)
http://www.mantisbt.org/ (Great tool, but no project planing...)
http://www.twproject.com/ (didn't try yet, but it has very strange interface)
But none of them is a 100% solution for me.
It also should (but not must) support SCRUM
We have about 25 people in our team and about 50 from client side. At once we run about 3-7 projects (some in dev. phase, some in support).
So, my questions: does anybody knows any good web-based system that gives everything software development company needs? I believe this information will be useful for many of us.

I would recommend FogBugz
They have a very interesting (admittedly not everyone's cup of tea) scheduling system and is apparently supporting scrum.
Their support for release management is something i'm particularly fond of, but i should also say that i have very little experience of other similar systems.
Another feature that I like is the ability to link different e-mail accounts as well as pure HTML forms to different projects.
Oh, and it is not a MySQL/PHP solution.
Some of the features are:
Issue tracking
Project planning
Scheduling
Customer support
Wiki
References:
Scrum and Fogbugz / Fogbugz questions / FogBugz Knowledge Exchange

I think it really depends on your company size. I used activecollab for a while but it never really convinced me and then they made it commercial anyway. There is an open source fork of it called ProjectPier.
Even if it is not MySQL + PHP but Ruby On Rails Redmine convinced me the most from all tools I tried (and installing the ruby module into apache is a question of 5 minutes). It is simpel and yet has anything I need (including Eclipse Mylyn, SCM integration, E-Mail Notification and time tracking). With a little RoR knowledge it is easily customizable, too.
The most popular Open Source sollution is probably Trac. It is written in Python, so it is not a PHP either.
But maybe it makes sense to consider a non PHP sollution. I didn't find any PHP open source tool that had the functionality and simplicity of Redmine or Trac. If you don't mind a hosted sollution Basecamp is probably the first address to turn to (never tried it though).

Trac with Agilo plugin might be a good option.
Here is link for Trac pluigns, some category are:
Code Documentation
User feedback and discussions

For another pespective - having used many of the above solutions, and liking them very much for bug tracking, wiki documentation and tracking information - I tend to move towards keeping much of my project "meta-data" (summary information pulling together wiki, bugs, schedules, communication) in spreadsheets now.
For those now climbing onto the top rope of the ring preparing for a takedown, here's why... I come from a programming background, and one of the best books I read early in my career was The Pragmatic Programmer. One of the tenets they preach is finding a fundamental editor that you like, and get good with it (for various Very Good Reasons). After trying (frustratingly) to port and adapt my PM/Dev Management approach multiple times to multiple systems, I've extrapolated that Pragmatic tooling philosophy to the product/project management world I now inhabit. To stretch the metaphor, my editor is now Excel.
I can't guarantee that for any company I work with, they have "Software Project Management xyz" or "Bug Tracking System abc" with the proper plugins - but I can be darn well sure they have Excel or some variant available. I know if I get ninja-like with that tool, I can continue to use it - and focus on the project, not the tools.
This spreadsheet approach comes with some caveats:
Excel done poorly can suck. We've all seen that. Watch for bloat and stupidity.
Keep the bugs in the bug tracking system, the wiki stuff in the wiki. The spreadsheet is meant to pull this stuff together, not replace it.
Keep it readable. Don't stuff everything in just because you can. Summary sheets are good.
Try to standardize your templates and macros meaningfully for tasks and information, to maximize reuse over time and projects. Just like good programming.
Back it up - use a document management system if you can. This approach isn't in the cloud or hosted centrally by default, so be aware of that.

Have you tried Assembla? They've recently released a new product called Portfolio which is great if you have to manage multiple projects + you get free clients! :)

You might like to consider http://targetprocess.com/ We use that in my current job and it works pretty well, from a developer point of view. I'm unsure as to whether it supports your installation requirements, however.

How to write "good" user interface texts?

Many applications are let down by the quality of the 'writing' in their user interfaces: typically, poor spelling, grammar, inconsistent tone, and worse yet, "humour" are the usual offenders.
Are there good resources that can help developers to write UI messages that give a professional and positive impression to your customers, even when your code's going to hell in a handcart?
Thanks, all — Some great resources here, so I will CW this question. I'm accepting Adam Sill's answer because it's the one that (as a developer of desktop apps) I found most pertinent.

Since XP, I've been a fan of the Windows UX Guidelines sections that cover how to properly structure text (how to ask questions, how to make assertions in dialogs, etc).
http://msdn.microsoft.com/en-us/library/aa974176.aspx
http://msdn.microsoft.com/en-us/library/aa974175.aspx

Read The Elements of Style. Then re-read it.
Also, anytime you are working with a program or website make a conscious effort to notice how they choose to do their writing. Imitate those you like.

The resources found at Writing for the Web might be useful to you.

The best tool for this is called "primary education". Many developers seem to have missed this, and I don't know how to fix that problem.
Also, this may be a British thing, but I think you mean "humor" and "going to Hell in a handbasket". :)

This book has a lot of good advice:
GUI Bloopers 2.0
Short version:
Be consistent throughout your application or app suite. Don't call the same feature two different names, even if they're in different dialogs, etc. Develop a product lexicon that everyone references.
Use the same terms that people who use your software use (i.e. users don't refer to themselves as users).
Don't call two different things by the same name.
Put all of the messages displayed to the user in a central place (i.e. a resources file of some kind). This makes it easy to review all of the messages for spelling, tone, consistency, and whatever else you want to check.
Usability test your software to see if the messages make sense and people can use your software easily. If they can't, change the resources file and test it again.

I would suggest showing your UI to as many people as you can--preferably people who read a lot (Just because reading does wonders for your grammar and vocabulary).
Getting something out that people can examine, however, is awesome--even if it's just a demo of the GUI.
If you work at a company, get to know your QA and Tech Support people. They are usually really wonderful once they understand what you are trying to do--they will review your UI, give you input on text and usability as well as possibly new requirements nobody in engineering would come up with.
If you work on your own, try to find a potential customer or two to review your UI. Ask them to pay attention to the text...
The more eyes, the better. You might even ask your parents, wife or other family. What can it hurt?

Get your application's texts proofread by someone who does just that for a living. Then the UI walked through by someone who does usability for a living. Neither of these two people should have been involved in the development.
It's the only way to make sure.

Using a Wiki for Requirements Management? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!

It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.

"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.

Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version

Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!

We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.

As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.

I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....

This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.