The Zen of Python is a set of 20 aphorisms that "succinctly channels the BDFL's guiding principles for Python's design".
Some of these are contradictory, or consist of pairs saying "This is true. But not really". But we can ignore all that.
Because one of them stands out clearly at the top.
Beautiful is better than ugly
Beauty is something Perl does really badly, because the Perl community as a group trends towards pragmatists and sysadmins. We lost the "front end" (HTML-side) of the community to PHP long ago, and never really recovered.
Perl has a public reputation of having ugly code. This can be true, but is often incorrect or besides the point. But with a stereotype like this in play the LAST thing we want to do is have ugly websites, which only serve to reinforce "Perl (code) is ugly" to the uninformed.
This is especially true in the case of our oldest core websites.
http://perl.org/ is horrible.
An 800-wide fixed-width site with dark, block colours, small type in a link colour not clearly distinguishable from black to non-perfect eyes and purple "visited links" ala 1998 and dense clusters of links with no descriptions, ratings or ranking.
It's slogan is "When you need perl, think perl.org".
But clearly not many people do, with the number of distinct visitors to search.cpan.org alone running 1-2 orders of magnitude higher than perl.org.
The "download @ % Perl" image link is ugly and doesn't even look clickable and the yellow box that says "Where do you want to go tomorrow?" is both meaningless and out of place.
Even as a "directory", the website fails horribly to help me with anything I want to do.
http://cpan.org/ is almost as bad.
It's minimalist, contains almost no information, and itself only serves as a directory to other CPAN websites.
But of course it also has a website design circa 1998, doesn't actually link to most of the CPAN-related websites at all, and doesn't even have a search box! You have to read through three search website descriptions and pick one before you can actually search.
And lets not forget http://www.perl.com/, which has (admittedly very slowly) degraded over the years under O'Reilly's stewardship.
The irony in this situation is that the most useful link on http://perl.com/ is the link to "our expanded news coverage" at http://perl.oreilly.com/, which is a far far better website than perl.com. Even though everything on perl.oreilly.com is based around commercial services offered by O'Reilly, it is a much more useful resource for commercial Perl people when compared to perl.com.
When someone turns up to the perl.com, perl.org or cpan.org websites with some task in mind, we don't do much of anything to help them get where they are going.
Looking through the list of all the other Perl websites, the look and feel disaster just keeps going on and on.
http://learn.perl.org/ is just a three page ugly clone of the ugly perl.org website, with two of those three pages links back to perl.org.
http://history.perl.org/ is another three page ugly mid-nineties style website, although this one isn't a copy of perl.org. It's a whole different ugly.
http://search.cpan.org/ is simple, clean, suitably elegent and has a search box right on the front page, where you'd expect it. And, I'm sure partly because of this, it also has the highest traffic of any Perl website.
http://cpanratings.perl.org/ is another ugly copy of the perl.org website, but feels more comfortable in that skin, because it's behaviour more like a simple review blog instead of an actual website, and it points you in plain language directly at the three things you might actually want to do when you arrive there.
http://annocpan.org/ isn't too bad, but has a completely different colour scheme from the rest of the Perl websites (most of which are blue) and is to some extent "confusingly similar" to search.cpan.org.
Surely it would be nicer if some of the annotation Javascript magic was just merged into search.cpan, and you only went to the main annocpan site when you REALLY need to dive into annotations vs revisioning.
http://dev.perl.org/ is another ugly perl.org clone, with a front page that's basically just a joke (although hey, it is at least informative).
http://rt.perl.org/perlbug/ is different from BOTH the perl.org style and the rt.cpan.org style.
http://dbi.perl.org/ is horrible, but at least it knows that it is and is going to change.
http://perl.apache.org/ is reasonably competent (although you'd expect that from a group of people who are completely web-focused).
The YAPC website at http://www.yapc.org/ is decent, which you'd hope for a conference website who's entirely reason for existing at all is as marketing. O'Reilly's OSCON website is of course great (although we've finally reached the end-state, where the string "The Perl Conference" does not actually appear anywhere on the website, that Google can see anyway).
http://www.pm.org/ is another horribly plain website with a front page image circa 2000, although at least it's not fixed width.
http://perldoc.perl.org/ is actually pretty good looking, and does look like something you'd expect from a document archive. In that sense, it has a similar suitability-for-purpose feel to the Oracle documentation archives.
Except, of course, perldoc.perl.org doesn't actually have all the Perl documentation like the typical visitor would expect.
At the Birmingham hackathon Jon mentioned something about this being because he builds the website on his laptop, and it would take too long to upload via FTP/rsync if he built it for all versions of Perl.
Can someone please hunt Jon down and force him to accept your donated server space to generate the full website on? As one of the few people we have that can produce a good looking and functional website, we really should be giving him more technical/infrastructure backup.
http://faq.perl.org/ is fucking horrible and looks like the kind of Windows 3.1 post-install help pages that were being generated in 1993.
http://www.nntp.perl.org is sparse, but functional, although it could do with someone giving it a little chrome.
And of course, nobody has any idea that it exists. Partly because we also have http://lists.cpan.org/ which is a second website for the same mailing lists. No, I don't understand the difference between the two either.
http://www.theperlreview.com/ is fine, but someone needs to have a talk to Brian about some of those yellow-on-white mouseovers.
http://perlcast.com/ is mostly ok, but as it mentions on the front page has been podfading a bit, and doesn't release on a regular schedule that people can anticipate.
http://perlmonks.org/ is crufty and could use some CSS attention. But it is a great community and does seem to have made something positive out of the cruftyness. After all, monks themselves are pretty crufty. Of course, I still find the chatterbox weird and hard to use, and if I can't use it as an semi-regular visitor how is any casual arrival going to use it.
Apart from the ugly perl.org chrome http://planet.perl.org/ actually does a really good job of aggregation. I have a small question about why Plagger wasn't good enough to run our Planet website, but that's a secondary issue and something I guess I'll take up with Miyagawa one day.
And of course there's the http://use.perl.org/ debacle. It's now mostly a news site without much news, hosting a highly valuable set of blogs that can't do images, syndicate to the blog aggregation services, support trackbacks or do any other normal bloggy things that help get our message out into the wider community.
Given the astonishingly large amount of blog software that is written in Perl, I find it astonishing that no Perl blogging companies, and no Perl blog system authors have managed to find the time to make a best-of-breed blog.perl.org.
I suspect that if we had such a thing, most of the people still on use.perl.org (including me) would move over to it pretty much overnight, and then use.perl.org can go back to what appears to be it's real purpose, being pudge's private beta testing website for slashdot.
https://donate.perlfoundation.org/ is also another ugly website, and doesn't contain anything on it that actually tries to convince me to give anyone any money.
The Perl Foundation's website is just as horrible, although there's another bitter irony here that when the Perl Foundation News section basically failed, they created a "blog" (called http://news.perlfoundation.org/) which is really a news page, and it's far far prettier and usable than the actual Perl Foundation website (although it's still fairly plain and ordinary by normal standards).
If we look at the CPAN websites, things are just as bad. http://www.cpantesters.org/ has been improving in leaps and bounds functionally but the look is horrible... except for its wiki at http://wiki.cpantesters.org/ which looks pretty good, but is really mostly for internal consumption by a small number of people. And the statistics website is yet another ugly perl.org clone.
The CPANTS website is also horrible. The name CPAN Testing Service remains annoyingly and confusingly similar to CPAN Testers and badly needs rebranding. Perhaps "CPAN QA"? (but keep "Kwalitee for the name of the metric).
And did you even know that the CPAN had a bookmark database? http://bookmarks.cpan.org/ is another practically useless directory, but this one is so bad we could live with it just dying outright. It's link to perl.com doesn't even point to a valid page.
http://svn.perl.org/ is so simple, trivial and ugly that even my personal repository at http://svn.ali.as/, which I INTENTIONALLY made ultra small and ugly so it would work on my crippled mobile phone browser, looks good by comparison. What does it say when someone trying to look ugly can end up far better looking and functional than the official Perl subversion repository.
And hey, at least my list of modules doesn't throw Python exceptions like the svn.perl.org one does.
I could keep going (I probably should have stopped long ago) and I'm not even going to bother talking about technical beauty yet in this post.
What's it going to take to fix this crap?
Do we need a dedicated website group who can start taking over the crap and come up with a standard website design that doesn't look a decade out of date?
Do I need to start taking over these websites and moving them into my repository? I already have a collection of six simple websites that anyone with commit to my repository can edit, and they are automatically synchronised from SVN to the web server. Should I just start sucking in all the small websites?
Could I just take over perl.org and all those bits and pieces websites and act as a steward in the same manner I've done for abandoned toolchain modules and (most recently) DBD::SQLite?
Would a Vertical Metre of Beer competition for a new look and feel for all of the Perl/CPAN websites be useful?
And for god sake, can someone with a spare thousand bucks leftover from a YAPC PLEASE organise legitimate crypto certificates for the SSL websites? This whole self-signed certificate crap makes us look like incompetent amateurs (when we are supposed to actually be competent amateurs)
Re:The right thing to do...
Alias on 2009-04-22T07:39:06
The logo we already have. The onion can be used really well and in different ways.
It's the site template, done in a way that we people making up new perl.org/cpan.org websites can easily integrate, that we badly need.
Re:The right thing to do...
Denny on 2009-04-22T11:40:22
A proposed redesign for use.perl.org, created by Andy Wardley the last time this discussion happened:
http://wardley.org/use.perl.org/test.htmlA few different people tried to contact pudge with no response, so plans/hopes to improve the looks of use.perl were abandoned.
Trying to do something useful with the wave of enthusiasm for Perl websitey things, at Digital Craftsmen we built this:
http://perlisalive.com/Which obviously uses a modified version of Andy's design. Meanwhile, Andy was working on a redesign of the London.pm website:
http://london.pm.org/Which also has the 'glass onion' theme/style going on.
Back at Digital Craftsmen, we started looking at adapting the first design for use on www.perl.org instead:
http://digitalcraftsmen.net/perl.org/slice.pngUnfortunately after discovering that we'd need an Apache 1.3 environment to host the combust CMS that perl.org runs on, we lost momentum on implementation of that idea. It'd be nice to pick it up again, but currently client work takes priority. As mentioned previously, it's also a bit tricky to find an entire spare server so that we can downgrade it enough that it will run combust - an example of how the technology used on the back-end can sometimes influence the availability of design/implementation efforts for the front-end.
So... there have been some efforts recently to try to generate a 'suite' of sites with a co-ordinated look-and-feel, but not a great deal of concrete progress, particularly where the core sites are involved. If there's a willingness to make more progress now, then people will probably step up to do the work.
As a footnote, last I heard dev.perl.org was very open to suggestions and help in improving the look and feel of that site, so that might be a good staging ground for any improvements eventually intended for www.perl.org
Re:The right thing to do...
Alias on 2009-04-22T13:02:51
Wait wait wait... that THING is a CMS?
I can't see anything there I couldn't replicate with an svn repository and a copy of DreamWeaver.
Re:The right thing to do...
Alias on 2009-04-22T14:25:41
It's nice to see that somebody has been trying to do something.
I suspect, however, that we might need to be one step more abstracted from where your examples are.
I've been part of two site redesigns of this kind, the Cisco design they used on all their sites during most of the 2000s, and a smaller more recent one at my current employer.
The first phase almost never results in a useful website and often not any useful prototypes either, it's a look and feel process.
The result is usually separate CSS and HTML fragments that describe the font/headings/content, others for headline page headers, alternate low-height headers, "site network" headers, menu options, footers, and so on.
This catalogue of look and feel assets then get handed off to the actual developers. In the extreme case (the Cisco example here) there's going to be multiple dozens of different websites running in different languages, run by disparate groups, on different platforms.
Done properly, the look and feel catalogue provides enough bits and pieces so that each separately operated website can achieve a similar look that appears to be part of a cohesive whole, even those they are implemented differently.
With somewhere between 20-30 Perl websites that would need to be converted, I can't see that it's feasible for us to approach it any other way. Targeting specific websites for individual design attention seems like it could only have a limited effect.
Re:The right thing to do...
pudge on 2009-04-23T22:58:33
Most of Andy's changes were meaningless cosmetic changes, and I simply don't care about that, and don't have the time to give to shepherding through things that to me are unimportant. I have too many actually important things to ignore! I know a lot of you care deeply about how shiny a web page is. I am not one of these people. I don't apologize for it, and I find it odd that your perception of the site would be so drastically impacted by that.
As to the lack of news that Alias mentioned, I've many times offered to allow people to post news, and sometimes I get a response, and usually I don't. If anyone else would like to post news, let me know.
As to Alias' other complaints, I see no value whatsoever in trackbacks, and I maintain the syndicating content TO aggregation services is wrongheaded.
I also don't care about images in journals myself, but we have support for that now and am willing to allow it; this can be discussed (though perhaps in a different context than this). Might take a wee bit of work, because actually, use.perl.org is not much of a testbed for Slashdot anymore, as we now have other internal systems for testing, and use.perl.org's code has not been updated for a few months now.
Re:The right thing to do...
pudge on 2009-04-23T23:09:14
Oh and BTW, I think Andy's changes mostly look good, I am not attacking him or them; I am just saying it's something I don't have the time to care about.
Re:The right thing to do...
chromatic on 2009-04-24T19:32:08
If someone had the time and inclination to apply some of those visual changes here, would you be willing to give access to do so? (I realize that your "I don't care about those things" means that you aren't likely to work on them. I'd just like to know if that means you're opposed to them.)
Re:The right thing to do...
pudge on 2009-04-24T19:54:05
Perhaps. As noted, right now the code on this site is a bit behind. I am planning on updating it soon, within the next few weeks. I would be open to pure CSS+images changes. Unlikely I'll be too interested in code/HTML changes, as those tend to take up a lot of time, but you never know.
Re:The right thing to do...
hex on 2009-04-24T07:03:09
"I simply don't care... I also don't care"
Thanks for getting so efficiently to the root of the problem.
Re:The right thing to do...
pudge on 2009-04-24T15:14:18
You appear to be trying to criticize me, but I don't think you actually are.
Re:The right thing to do...
hex on 2009-04-24T17:15:03
You think wrongly.Allow me to rephrase it in a way that you can understand: you have your head so far up your own ass you could kiss your own tonsils. Hope this helps.
Re:The right thing to do...
pudge on 2009-04-24T17:53:55
Nope, you've confirmed I was right all along. You were not, in fact, criticizing me. You were trying to, but you did not. You think it is a criticism of me that I don't care about such things. It's not. You think that the fact that I don't care about such things means I "have my head up my ass." You are wrong.
I could, of course, say the exact same thing to you, from my perspective: anyone who thinks a "shiny" web page makes a lick of difference, and actually cares about such things, has his head up his ass. Ho ho, look how clever I am! But as with your statement, I could not substantiate such a stupid claim. Matters of opinion about the importance of aesthetics are not worthy of such inane insults.
It's odd to me that anyone thinks their opinion should be reflected by me, or that I have a significant obligation to the "community" to care. I set up this site and invited people to it, and they used it and it was good. I don't owe anyone anything, and I will not feel compelled to care about something just because you want me to. I have a very busy life, and I refuse -- in any aspect of it -- to be bullied into caring about something I am not prone to care about on my own.
Like I said, it's very odd to me. Regardless, I still don't care meanigless cosmetic changes, and unless you can give me a rational reason to do so -- fat chance there -- my feelings about it are not going to change.
Re:The right thing to do…
Aristotle on 2009-04-27T18:35:01
Do you care about the layout of code?
Re:The right thing to do…
pudge on 2009-04-27T18:37:29
Do you care about the price of tea in china?
Re:The right thing to do…
Aristotle on 2009-04-27T19:52:19
Hmm, I just got a mail telling me there was a reply. I don’t see one.
Re:The right thing to do…
pudge on 2009-04-27T20:48:27
I thought you started a game of Non Sequiturs. It's your move!
Re:The right thing to do…
Aristotle on 2009-04-27T20:53:55
Hmm, must be a bug somewhere.
I whole heartedly agree that the websites for the CPAN Testers family has been in need of a complete overhaul for sometime. I have asked occasionally of designers I know for some ideas, but so far nothing has stood out. The Wiki was my rework of an OSWD template, which originally was intended to be the first branding of the CPAN Testers websites, with the others using the same layout, but different colours. However, I didn't think it suited the other sites.
The current CPAN Testers Reports site makes use of the YUI style, which I also copied for the Preferences website. However, with the way CPAN & reporting has gone, the YUI design often makes life difficult. So far I haven't found a suitable alternative, but if any designers out there have any suggestions I'd be delighted to hear from them
Re:CPAN Testers Family
barbie on 2009-04-22T07:53:45
Actually having a quick look this morning, there is a recently uploaded design to OSWD that fits very well. Clean, professional and functional. I'll have a go at reworking for CPAN Testers
:)
Given the astonishingly large amount of blog software that is written in Perl, I find it astonishing that no Perl blogging companies, and no Perl blog system authors have managed to find the time to make a best-of-breed blog.perl.org.
I was astonished by that too. But having prodded round the edges of the problem, it seems to me that no Perl blogging engine is up to the job.
If anyone reading this thinks I'm talking nonsense and would like to prove me wrong, then please get in touch.
Re: Beautiful is better than ugly
mw487 on 2009-04-22T13:15:58
I am definitely of the 1998 school, but what about Movable Type? Not that I could ever prove you wrong, and such is not my intention. I just hope the problem can be solved, and I know that I can only be a very minor actor.
Re: Beautiful is better than ugly
davorg on 2009-04-22T13:48:05
but what about Movable Type?
That's exactly what I thought. I tried. It didn't work.
I'm hoping that this discussion will flush out an MT expert who will be able to show me where I went wrong.
Re: Beautiful is better than ugly
mw487 on 2009-04-22T16:19:55
Well, I am definitely not that expert. But I was thinking about playing with MT- even changing my cheap provider (1&1) to do so.
When you say, "It didn't work.", could you be a little more specific? e.g. Didn't install? Didn't reproduce this page (with link)? Didn't handle spammers? Brought your box to its knees? Didn't support slashboxes? (Specificity might trigger a post by that expert...)
Re: Beautiful is better than ugly
davorg on 2009-04-23T08:19:48
Oh it installs just fine. I'm really happy with MT. I run many blogs on it.
But this was the first time that I had tried to set up a multi-blog installation. I assumed that it would all just work out of the box, but it didn't.
There are a couple of discussions that I had on the MT forum here and here.
There was a new release a couple of weeks ago, so I might see if I can find the time to try again over the next week or so.
Oh, and by the way, I run all of my MT installations on 1&1 servers. Not sure why you think you'd need to change hosting providers.
Re: Beautiful is better than ugly
mw487 on 2009-04-23T18:37:49
On 1&1, I could be wrong. I buy the very cheap service. It used to include shell access. But I think they took that away from me.
Do I need shell access for MT?
Do you have the cheapest level?
I was thinking about Blue Host.
Re: Beautiful is better than ugly
davorg on 2009-04-24T07:41:17
I don't think you need shell access to set up MT, but I've always done it using shell access so I could be wrong there.
I have a root server with them. I can't imagine running web sites on a server that I didn't have full control over
:-) Re: Beautiful is better than ugly
mw487 on 2009-04-24T13:31:04
I think playing with MT would be a royal PITA without shell access. Sure, root is nice, but user access is not bad, I think I could handle that.
And I likely would not want to fool around with any open source that does not intelligently support non-root use.
But imagine trying to use perl modules with only ftp! Seems like CPAN.pm and things would be out of the picture. Kill me now.
Mind me asking how much you pay for root at 1&1?
Re: Beautiful is better than ugly
davorg on 2009-04-26T15:20:40
MT bundles all of the CPAN modules that it needs. So if you can FTP a directory tree into your web space then you're all set. All of the set-up and configuration is now run through a (very nice) web-based system.
I have a Value Server from 1&1. It costs me GBP 30/month and I happily run about a dozen domains on it.
Re:I'd love to help ...
Alias on 2009-04-22T09:07:06
Step 1. Politics
If we're going to start redesigning websites wholesale it needs buy-in from the appropriate people who built and own the websites, so that anything we create is suitable for purpose and reusable across all of the websites properly.
Re:I'd love to help ...
nicholas on 2009-04-22T09:17:39
it needs buy-in from the appropriate people
Which also means some technical constraints*, because it has to be able to run on the existing hardware budget if not the existing hardware, and scale to the size of known traffic peaks. Yes, these sites can end up on the front page of slashdot, so the "static" pages better not be making umpteen calls to a database to generate their content.
* constraints are good. A good artist uses constraints to channel their creativity and inspire them. Well, that's my story and I'm sticking to it
Re:I'd love to help ...
soulchild on 2009-04-22T09:31:30
I don't know the current infrastructure, but IMHO it'd be a good idea to utilize some sort of flexible and static content generating CMS (Bricolage comes to mind... Maybe we can even get David Wheeler to help with the setup and planning of the site)? Re:I'd love to help ...
barbie on 2009-04-22T09:56:30
I think you're missing the point. Adam is talking about presentation and layout design, not a CMS or whether we're using a flavour of the month framework. Templates and CSS can be integrated into any site. Ruby on Rails largely got peoples attention because the initial websites looked well designed, and had nothing to do with the backend codebase.
The problem is that many of us are decent coders, and can put together a functional site pretty well. However, we're mostly not website designers and that's what we need right now.
Re:I'd love to help ...
soulchild on 2009-04-22T11:20:53
I think I DID get the point that first and foremost an optical change is needed. nicholas brought up technical constraints which is why I thought about switching the backend as well. I didn't know that the sites which look like they can be dated back as far as 1985 had a decent CMS that sports a separation between backend and presentation;-)
Anyways, does anyone know why exactly the TPF doesn't invest some money into a professional web designer to polish Perl's appearance? This stuff really doesn't cost a fortune... Re:I'd love to help ...
Denny on 2009-04-22T11:43:14
The main reason Digital Craftmen didn't manage a full implementation of our proposed glossy design for www.perl.org is that combust (the perl.org CMS) requires apache 1.3 and mod_perl 1 to run... we don't have any servers that out of date, and we couldn't spare one to downgrade for the build and test.
While I agree that the back-end shouldn't be the driving force in an aesthetic redesign, it seems that it can sometimes be a very effective brake.
Re:I'd love to help ...
soulchild on 2009-04-22T12:07:44
To be honest, I also really don't see a problem with starting from scratch to set up a more friendly www.perl.org with a modern CMS and/or backend framework. If the backend holds back any new development, it's time for a change. But guessing from other posts this is not gonna happen in the near future... In any case, there's way too much information on perl.org ATM which is only remotely useful. That's why I think the main emphasis should be put into some conceptual work to restructure the whole thing and make it more appealing to new users because the veterans already know where to get the information they need. Re:I'd love to help ...
Denny on 2009-04-22T12:37:05
I think there's just a general feeling of caution amongst experienced developers about 'changing the cms' being the first response to any issue with a website. We all like playing with new technology, but sometimes all that's really required is to put some effort into coercing the old technology to behave better.Re:I'd love to help ...
soulchild on 2009-04-22T12:56:03
Being responsible for a 10-year-old legacy web application on a daily basis, I fully understand these concerns:) But there's always the possibility of a gradual transition ... I'd start from scratch and design a new perl.org primarily targeting new users with the usual "Getting started", "Download", "Documentation", "Community" and so on sections. From there we can always link into the guts of the old (content-heavy) sites. Re:I'd love to help ...
Shlomi Fish on 2009-04-22T19:29:55
I have intended The Perl Beginners' Site to be the (unofficial so far) first-stop for Perl beginners. About two years ago, I've adapted an OSWD template for its look, which should have made it attractive enough. There's still some problem with the testimonials section being lacking, but I plan to correct it when I find some time to dedicate to it.
Contributing and building upon Perl-Begin is very easy because the sources are available in a publicly-accessible Subversion repository, and the licence is CC-by. As far as I know, the sources for all the perl.org are not publicly available, and I don't know what their licensing terms are.
Re:I'd love to help ...
Alias on 2009-04-22T13:40:35
This isn't necessarily about perl.org specifically, or about this CMS or that CMS.
ALL of these websites are crap, run by a dozen different people/groups on a dozen different platforms, have all degraded or rotted, regardless of the sophistication of the backend.
I've managed to do a perfectly acceptable job of operating a site (and been complimented for it a number of times) with nothing but a plan HTML editor, an svn repository that 20 other people have commit to, and a cron job.
A lot of this problem isn't going to be problem relating to backend software.
It's going to be coming up with a look and feel that doesn't absorb the entire page into a giant glob. That isn't gaudy, doesn't dictate a layout, and that people who own various sites (or take over maintenance) can drop in different pieces.
If done right we end up with the sites having a consistent "flavour" (or perhaps two flavours... one for the perl.org sites and one for the cpan.org sites) and sharing many different pieces, but NOT having to necessarily be part of the same actual website.
Re:I'd love to help ...
perrin on 2009-04-22T14:10:36
You don't need to dedicate a server to running a different apache. You can run as many different apache/mod_perl binaries as you like on a single machine.
Re:I'd love to help ...
mpeters on 2009-04-22T13:48:36
We at Plus Three (http://plusthree.com/) are big contributors and users of the Krang CMS (http://krangcms.com/ and http://krangcms.com/screens.html) which was originally designed to mimic Bricolage in a lot of ways but is now considerably different. We have a clustered setup of the CMS and other servers to serve the content for our clients and we would be willing to help out if anyone needs it.
A very well written article. But what has Python got to do with it? Yes, "Beautiful is better than ugly." but "Form follows function." and "A witty saying proves nothing." Perl has its own culture, its own community, its own egregor and its own spirit. Do we want to be Python? Do we want to be Ruby? I would like Perl to be Perl. If I wanted Perl tu be Python, I'd use Python.
Also, there have been lots of proposals for changes, especially to the looks of various parts of the Perl infrastructure. But the problem isn't coming up with something that looks better. The problem is migrating all the content, keeping it up-to-date, keeping it maintained. That can be awful work that nobody wants to do.
IMO the core of the Perl community is too much worked up with developing code than to care about looks. If you want $x.perl.org to look better, why not just put a big "We're looking for (designers|maintainers) for this website!" banner on top of it?
Re:What's with the Python?
soulchild on 2009-04-22T12:44:13
Do we want to be Python? Do we want to be Ruby? I would like Perl to be Perl. If I wanted Perl tu be Python, I'd use Python.
And this helps with attracting new developers to Perl exactly how? Or selling Perl to your pointy-haired boss? IMHO these two things should be the driving force ATM. The community's predominant underground attitude is cool, but Perl is not only a hobby of mine anymore, it also pays my bills and as such is a commercial tool in which I have commercial interest.
Re:What's with the Python?
phaylon on 2009-04-22T13:00:07
That's what I'm asking. How do these comparisons help? We should point out why Perl is good itself, and it has many areas in which it is. Btw, Perl is paying my bills too, and it's doing it very well.
Re:What's with the Python?
soulchild on 2009-04-22T13:15:46
Correct. Unfortunately it's not enough to have a good "product", you also have to make it appealing utilizing some sort of marketing fu. In reality, books are still judged by their covers - and perl.org is one of the more ugly covers I've seen when it comes to language websites:) Re:What's with the Python?
phaylon on 2009-04-22T13:17:20
So? I'm not doubting that there's uglyness.
Re:What's with the Python?
soulchild on 2009-04-22T13:23:31
Oh, nevermind then. I must have misread your original post.Re:What's with the Python?
Alias on 2009-04-22T13:31:13
> Do we want to be Python? Do we want to be Ruby? I would like Perl to be Perl. If I wanted Perl tu be Python, I'd use Python.
Yes. Yes we do.
Perl has always been about taking the best ideas from other languages and borging them in.
Re:What's with the Python?
phaylon on 2009-04-22T13:38:44
And what are those ideas in this case?
Re:What's with the Python?
gizmo_mathboy on 2009-04-22T14:02:04
Beauty is better than ugly...sometimes.
Perl is good, the marketing side is ugly as Alias has pointed out.
To be honest, the glass onion look is a great start in my opinion.
Re:What's with the Python?
phaylon on 2009-04-22T14:03:24
We need to reference Python to say that the Perl sites need to look better?
Re:What's with the Python?
gizmo_mathboy on 2009-04-22T19:23:13
No.
Re:What's with the Python?
Alias on 2009-04-22T14:03:47
In this particular case, "Beautiful is better than Ugly".
:) Re:What's with the Python?
phaylon on 2009-04-22T14:11:17
I'm not trying to be annoying here, I just don't see how that's anything Python specific. If you say "Python has put aesthetics as first priority, and so should we." then I'd have to disagree. If you just reference it for the truth of the saying, well, then it's pretty apparent that "Beautiful is better than ugly" and "less bugs are better than more bugs" and "flexible solutions are better than inflexible ones" or "consistency trumps chaos."
:) Re:What's with the Python?
Alias on 2009-04-22T14:52:46
> I just don't see how that's anything Python specific.
There isn't. They aren't the only ones that think it.
> If you say "Python has put aesthetics as first priority, and so should we." then I'd have to disagree.
I don't say that and neither to they.
It's just the first one in the list, which doesn't prioritise the elements within the list. You've over-read.
> If you just reference it for the truth of the saying, well, then it's pretty apparent that "Beautiful is better than ugly"
If it was, we wouldn't have so many ugly websites.
Re:What's with the Python?
phaylon on 2009-04-22T20:31:25
I didn't overread, that's why the "if" was there
:) This sounds like you think people chose to make websites less appealing intentionally, and not as a side-effect of focus on function.
Re:What's with the Python?
Ovid on 2009-04-23T11:06:40
Some people say "Perl is dead". If I didn't know where to look, the Web sites I find would imply "Perl is dead". Appearance matters. I think that's what Adam's trying to say. I agree with him 100%.
No one is saying we should be Python. No one is saying that we got into this mess intentionally. No one is saying anything other than "our Web sites look amateurish and this has an impact on perception". We do have a perception problem and we need to address it.
Re:Good luck
Ovid on 2009-04-23T11:08:03
Yeah, the comment system is astonishingly bad. When I first visited this Web site when I wasn't logged in, I was shocked at how unusable it was. I even switched browsers on the off chance that it was a browser bug. It's not
:( Re:Good luck
pudge on 2009-04-23T22:50:52
Not for nothing, but the comment system works astonishingly well for Slashdot.
The last time I saw statistics on Perl.com, the most useful link to visitors was to "Download Perl". Only that and the front page received any traffic of note.
Re:Perl.com
Alias on 2009-04-23T00:06:47
What about the perl.oreilly.com site?
Re:Perl.com
chromatic on 2009-04-23T00:29:50
I rarely saw statistics for any of the technology-specific subdomains. I can't imagine they drew much traffic at all, lest the company would have reported on them. They were long a source of contention between the company and its writers, as the latter believed they provided very little value, especially compared to sites such as XML.com, Perl.com, and ONLamp.com when the latter were actually maintained.
The best you can say about perl.oreilly.com is that it's not horrifically ugly, and that it doesn't look abandoned yet.
Re:Perl.com
Ovid on 2009-04-23T11:09:06
Is there no other traffic because no one is interested in anything else or because people don't find the site useful?
Re:Perl.com
chromatic on 2009-04-23T11:30:58
I suspect it's both. There were three drops in traffic while I edited the site. The first came after I received the order to cut publishing from two to one article per week. The second came a few months later, when I received the order to cut publishing from one article per week to two articles per month. The third came a few months later, when I received the order to cut publishing from two articles per month to one article per month.
By the time I received the order to "Publish something so that it shows up on the site and it doesn't look completely dead", there was so little traffic it didn't matter.
There were blips; I started to revise Doug Sheppard's "Beginner's Introduction to Perl" series to cover Perl 5.10, and that brought in a fair amount of traffic. Even so, Modern Perl Books gets almost as much traffic in a week as Perl.com's articles did, the last time I checked. That shouldn't surprise anyone; I've published more there in the three months of its existence than I could on Perl.com in the past two years.
I'm no longer a Perl fan, but I think the Perl sites are fine. I'd almost say that they're beautiful. They seem to do what they need to do without a lot of excessive visual trash or mental overhead.
In terms of Perl's future, I think it would be much more useful to spend time regularizing and reducing the language. The latest (albeit dated) version of Programming Perl is 1100 pages. Imagine what that'll balloon to for Perl 6.
Re:The sites are fine--it's the language that's ug
linuzer on 2009-04-24T01:19:17
have you ever seen Moose or Catalyst?
I don’t find the default Combust template per se ugly at all. It looks simple and clean to me.
But in most cases the sidebar content serves little or no useful purpose and the organisation and typography of the main content area is terrible – aside from the fact that it’s rarely helpful to anyone but search engines. Perl.org is the worst of them all – the download button is a disaster, and I can’t see myself ever linking anyone, novice or veteran, to that site for any purpose, nor using it myself.
PS.: on an unrelated note, I can distinctly remember being very annoyed by the CPAN front page even back when I was a complete Perl neophyte – over a decade ago. And it hasn’t change a single bit since then.
