On the
/Features page
HelmutLeitner commented:
- "Nearly perfect code quality. Never saw better code published (20 years of experience). And its free!"
...which led another user to add:
With the opinion of having been mislead by it, I would like to balance the statement "nearly perfect code quality" above. Before that however, it would be unfair not to note that UseModWiki is of great use to many people, has been generously provided under GPL by the author, and is easy to install and configure. Regarding the source code, I have spent two months modifying it to suit my needs. Having become intimate with at least half of it, I can say that it is not of high quality. Of course this view is subjective and relative. Granted, UseModWiki's code is better than at least a certain Python-based wiki that I'm also intimate with. To speak generally about the problems with the code, it is supporting far too many features for its quality, resulting in a buggy and fragile program that is difficult to maintain. It contains a significant amount of redundant code. Again, it must be admitted that programs like UseModWiki that have such a wide set of user configuration options are hard to design well. However if one is considering UseModWiki as a base to customize upon, there may be better wikis out there. --Troublemaker
- As the author of UseModWiki, I think the code quality is somewhere inbetween these comments. Code quality is not a primary goal of the wiki, but I have taken some steps to keep it maintainable. The code runs under "use strict", and should be mostly warning-free, which makes it better than a lot of Perl scripts. Some of the problems occur because UseModWiki was "grown" incrementally rather than designed from a complete starting vision. More ugliness occurs because of legacy or convenience features (such as context-sensitive subpages) that interfere with later code, especially when I've decided to implement features as options (like "free links").
- Still, I'm generally satisfied with the code. I take it as a compliment that the "Troublemaker" thought it was worth spending two months working on the UseModWiki code. Personally, I recommend rewriting a wiki from scratch if you're planning a long-term coding project--it isn't that hard to do and you won't be frustrated with other people's design decisions. (I started UseModWiki using the AtisWiki code, but practically all the old code was later rewritten.) Finally, I also recommend looking at other wiki projects (see OtherWikis)--one of them might be closer to your needs. --CliffordAdams
- I've used perl for some time, and I have to say this: I understand why UseModWiki is coded as one .cgi file. That's because OO programming is a major pain in perl. Perl code is easy to write, but very hard to maintain later. And it looks ugly to boot. Like, functions without parameters, and then using either shift or list assignment, gross! The parametrized functions in perl are horrible. If Larry could get away with half a letter per variable type, he would do so. Yea, maybe in next perl he will find a way to encode 3 or 4 types into 1 context sensitive letter. Argg... Anyway. Rant mode off. If anyone wants to either maintain or write new Wiki from scratch, you have two choices: Python and Ruby. Ruby is very nice, but a bit raw to my taste. It needs more cooking. Python is also very nice (but not as perfectly elegant as Ruby), and it's stable, mature, with tons of libraries and a huge community. Plus, Python is making big positive steps toward elimination of some of the more common complaints against it (unlike Perl, which is just getting worse). I don't know what certain Python Wiki the author above has in mind, but given that it's Python it should be at least: easy to read (only one coding style to cope with), easy to refactor (classes are natural, functions have real arguments and even defaulted arguments, unlike in Perl), easy to fix bugs with exception handling, logging and unit testing (if you must). No matter how bad Python code is, if there is anything good at all, you can salvage it easily. --Aeoo
You also have lisp! ...no, really! :) --DavidMcCabe?
Troublemaker, I think that you should try to prove your points. IMO there are only minor redundancies (please name them), the code is easy to extend and to maintain (I did for the last 14 month and will continue to do so) and I found only 2 really minor bugs. The code is consistent in its style, uses only few comments exactly where they are necessary and the Perl code is really efficient. Cliff really did a fine job. -- HelmutLeitner
- I'd rather not get into a debate at that level. As I said my purpose was to balance your statements, and I think the author is right in saying that the truth lies "somewhere inbetween these comments". Regarding Aeoo's comments, I don't agree because code quality is independent of language. I'd take a well-crafted Perl program over some slop in Python any day. My point about the "certain Python wiki" was that UseModWiki was not at the bottom in terms of code quality. I wasn't implying that Perl is better than Python. Wikis whose main feature is what language they are implemented in are hopefully a thing of the past. --Troublemaker
- I'm sorry, I don't understand your point. Cliff is an expert at Perl programming and only speaks in the tradition of a "humble programmer" not intending to argue with you about his own code quality. I do. High code quality means that an expert will look at the code, see perhaps a few possible improvements, but none that are really worth the effort. It doesn't make sense to talk about Perl vs. Python in this context. UseMod is written in Perl, and you can't do much better in Perl. If you like Python better, rewrite it in Python. After all, it is still a small program and you should be able to do it in a week or two. I would be very interested to compare the results. -- hl
- The lack of understanding is mutual :) . I'm making no issue about Perl vs. Python. That was started by Aeoo. --Troublemaker
One thing I notice about UseModWiki's code quality is that the program begins with a long list of global variables. MarkJasonDominus has described that as a RedFlag (similar to a Wiki:CodeSmell). I appreciate the ease of installation that results from having the code all in one file, but perhaps it would be worth looking into breaking it down into multiple packages within that file, to allow the current reliance on global variables to be lessened.
With that said, I have to say that the feature-set of UseModWiki impresses me greatly. I've only recently gotten into wiki-use, but after using the very basic wiki code that comes with Wiki:TheWikiWay, and taking a look at the code for [Twiki], I think that UseModWiki strikes a really nice balance between having too few features and too many. --JohnCallender
EricScheid and I are conspiring to break the script into packages just as you suggest after the mythical NextRelease. Cliff is still resisting, but I plan to anesthetize him during the procedure. -- SunirShah
Just as long as you do not break it into various files. The one-file approach has been a major plus for UseMod. What would the advantage of several packages in one file be -- a concrete advantage or just general maintainability? -- AlexSchroeder
Both, I think, but this is all speculation until it's done. -- SunirShah
- Sunir, what's your approach? I've been plotting a split into several packages in one file. My idea was to use OO, and start from a totally generic Page object, which just handles displaying header & footer. Child objects would be, for example, WikiPage?, which handles opening and parsing wiki markup, and AdminActionPage? which checks for password status -- child pages of that would perform the different admin commands. I figured that this way it would be easy to slot in extra functionality, such as MostWanted?, different groups of users with different read/edit permissions, etc. -- Tarquin
I don't think we need object orientation, but we do need modularization. I think boxing yourself into OO would make the code far more complex than it needs to be, and that means much more code to maintain. The simplest way forward is to find groups of code that are more or less independent from the rest and then place those into their own packages, one at a time, until the entire script is broken up. Then, Wiki:NarrowTheInterface so that the packages can become components more or less.
The released script will be one file, but that doesn't mean that development need to be in one file. It's a trivial thing to take separate packages and split them into separate files, and then take those separate files and recombine them into one file. We could write a helper script to manage this, or do it manually before release. It's not very difficult.
I'd also like users to be able to supply their own actions by modularization. For instance, many people want a pretty printing interface to MeatBall:WantedPages built directly into the script. This functionality is not a kernel level behaviour, so it's not necessary to put into the main script. However, if the user created a package called wanted defined with some sort of interface, then the script could activate it when asked to perform action=wanted automagically using Perl runtime reflection. I'd also like to identify parts of code that aren't necessary from the kernel and then separate them in the same way. This way, the main part of the wiki might be turned into a thin component that could slide into another application.
I know that might sound like a perfect candidate to OO, but there are certainly more ways to slice that banana than with objects. I'm open to whatever Perl has to give us, as long as it is maintainable by mortals. OO or not, the general direction is compartmentalization and separation. -- SunirShah
It would be nice if wiki hosts could add special behaviour to pages (like WantedPages?, image upload, or the Class Wikifier I made on UnrealWiki) by simply adding a block of code to the perl script file, or maybe dropping a new file into a specific subfolder (or is that too Microsoft? Hmm, no it's kinda Mac-ish, Unix-ish). I eagerly await news of BananaSlicing -- Tarquin
Some additional fodder to consider on the subject -- Murray
- With all due respect to Joel (but come to think of it, what noteworthy software HAS he written?) he's dead wrong. Netscape's prior codebase was an unmitigated disaster, and the rewrite has netted us Firefox. It's also worth noting that UseMod is itself a rewrite. I'm not entirely sure the world needs another Wiki codebase -- it seems the next thing newbie web programmers write after a template engine is a wiki -- but it's not as if we've reached such perfection that no progress in the art need be made. And certainly such progress is easier to make on sound design principles like OOP rather than a morass of highly coupled side-effecting procedures on globals. --ChuckAdams
![[Home]](/wiki.gif)