Lisp also loses to PHP on maturity, documentation and support
Lisp is 50 years old and standardized for 15 years. Has both an ANSI and ISO standard, freely available books and manuals written by the best and the brightest of the Art. There are 4 commercial Lisp companies and a total of 8 standard-compliant implementations.
There is absolutely no comparison, and it's both telling and sad you would utter them in the same sentence. Take it back.
(also available in 7-8 other languages). Note all useful string concepts are one click away, and the documentation allows user commentary (much of which is quite helpful).
In Common Lisp, strings are a subtype of Sequences :-) The PHP String library you linked to is appalling. It includes a lot of stuff that shouldn't be squashed together in one "section"; strings, characters, locale management, i18n, cryptography, sequences, generic formatter, currency parsing and formatting, uu(en|de)coding, even fuzzy string matching!
Who does this appeal to? no abstraction, no modularity, no visible type hierarchy or any sense of order.
Aaaaaannnd... this is the number two reason Lisp's are not more successful (number one being the syntax, although that is somewhat related). Instead of helping to solve your problem, advocates (and the reference documents, "tutorials") want to engage in academic chest beating exercises.
How hard is it just to acknowledge, just a teeny bit, that PHP is more successuful than Lisp for real reasons -- not just because everyone but you is an idiot. That's nice that you think the string library is appalling. Perhaps it is -- but jesus, how do you even get work done with an attitude like that? Do you write everything you do from scratch?
Go write a graduate paper on the perfect string library and others can get real work done.
I wasn't commenting pro-php; the php api design isn't going to win any awards other than popularity.
You're not really responding to the point I was raising: poorly-designed or not, php's official site has easily-findable and easily-accessible documentation (which it needs given the quality of the api design); its official central documentation site is well within the range of modern best practices.
There's not to my knowledge a comparable common lisp online reference (reference, not tutorial) that's anywhere near as accessible to the beginner or intermediate user (that nebulous phase between getting through a few tutorials and having deep knowledge).
...which I'd say is probably the best of the online manuals.
But more to the point:
There are minor issues with the formatting of the hyperspec no one's bothered fixing. Aside from the lack of a pretty stylesheet and the lack of wiki-style user comments
The most obvious is that if I eg go to the Strings or Array section it just gives me a page with a sub-table of contents; it'd be a lot friendlier to have all the Array or String docs on a single html page.
This wouldn't even be that hard to implement, and the "moar docs on one page" approach to online docs keeps winning out for a reason (it's easier to find what you're looking for if you only know approximately where it is if you can get everything that might be related on a single page and ctrl-f your way through it; having deeply-nested content is far unfriendlier).
I do think the hyperspec is not very well-thought-through as end-user documentation.
It mixes levels of concerns that ought to be separate; someone reading documentation with the goal of finding out if there's a built-in function for "split a string delimited by a particular character into a list of strings?" has very different requirements from someone who needs to know how strings are implemented, for example.
IMHO the hyperspec tries to do both; it's fine as a nitty-gritty reference but could be improved as a day-to-day programmer's reference.
Python's docs are a good example of end-user documentation done right. They have a clearly-delineated split between the language specification ( http://docs.python.org/reference/index.html ) and the standard library specification ( http://docs.python.org/library/index.html ) and additional, separate documentation over lower-level aspects of implementation.
Each body of documentation is organized for the convenience of its typical user.
Yes all of this I know; you claimed common lisp has superior documentation to php and I've consistently shown you ways in which even php's documentation is superior to that possessed by common lisp at this time (at least in any sense that matters to me).
I should clarify: there certainly is documentation for common lisp, some of it quite good; the situation is that in many ways common lisp's documentation is outclassed by even php's documentation.
Let's turn this around: take a good look at php.net; put aside your disdain for the language (blech!) and just look at how the documentation is structured, in terms of organization (high level and low-level, like in what size chunks it's presented in).
Do you really think there is nothing to be learned from how the php people have assembled their official documentation?
I'd additionally argue that as nice as in-environment documentation is it's a sub-optimal approach to accessibility.
Part of the issue is for the abject beginner it multiplies the things to learn: everyone knows how to work firefox and google and can google something to see what turns up; having to learn how to work the in-environment documentation takes you from one problem ("how do i shot web?") to two problems ("how do i shot web?" and "how is docs found?"). A serious student will pick it up pretty quickly but .
The larger issue is that the lack of a central documentation + discussion hub means that there's no system taking the informal knowledge possessed by discrete practitioners -- stuff like what implementations of what functions on which platforms have unanticipated quirks, or what function non-newbies typically use instead of the function you're currently reading the docs for -- and capturing it for posterity in an easily-searchable format.
Some of that information can be gleaned from usenet and mailing list archives if you know to search there and have time to wade through flames and trolls and other gunk, but the rest of it is stuck in the minds of individuals and is therefore largely inaccessible.
The php approach (which is used by other projects, like eg mysql and pgsql) of having a central online documentation area with integrated user comments is that it provides a natural place for such informal knowledge to wind up; once it's there once it's there for everyone (and can be googled and so on).
You could create an in-environment system that had most of these advantages -- some "social" version of the docs, essentially a wiki-ish system -- but that's hypothetical, and I'm talking concretely, and concretely the available common lisp documentation is largely outclassed by the documentation available for php (and for python, and java, and c#, and many others).
As a parting note you really shouldn't underestimate the advantage of dumping more information into a single page.
Much of the useful knowledge about a language and its core libraries is knowing the logical structure of how everything fits together; much of this is never documented in any formal way, but can be inferred from an overview of the larger-scale organization.
When you present stuff all on one page it's pretty easy to take this in: notice how quickly you could tell the php strings api was poorly designed? That's b/c you could at a glance see everything that was relevant and infer the entire structure (or lack thereof).
When you present things in tiny little atomized chunks it requires much more effort for the reader to get the birds-eye view of the system, as the reader is not provided the convenience of seeing it all laid out in one place.
You're thrown a typical webdev task, like setting the filesize limit for user uploads. Quick, how much time will it take in CL? Connect to MySQL and store some data. How many minutes, how many lines of code, how many libraries downloaded? Now determine the dimensions of a jpeg image. And parse some JSON from a file. Faster! (In PHP we haven't even left the standard library yet. It's that perfectly tailored for what web people do.) A weird problem arises, what's the chance that some PHP user had it before and wrote it up, compared to CL user? Something more complex: HTTP request goes in, ping to payment system goes out, file starts downloading with correct mimetype, where do you go for working code examples? You need to move your app to another webhost, how much hassle will it take? Client needs a CMS, which one do you pick, and how often does it get security updates? You make your app open source and people want to install it, what instructions do you give them?
Yes dammit, let's get practical. Let's get our hands dirty. I love this stuff.
You are showing a complete misunderstanding of software engineering. You don't go running around looking for examples and installing 3rd party packages willy nilly. Weird problems don't just "arise" out of the blue, and although there is some urgency to things there is never any chaos. Things are a bit more controlled, and you are assumed to know what you're doing, Lisp or otherwise.
A better way of stating it, is that while Lisp is older, there is a lack of real world experience, documentation, and support for using Lisp as a language for web development. The volume of material, understanding, and optimization strategy for PHP is far and away greater than Lisp.
As an example, search for a simple question on how to do some developmental task on google for both PHP and Lisp. PHP will have more informative pages.
Lisp is 50 years old and standardized for 15 years. Has both an ANSI and ISO standard, freely available books and manuals written by the best and the brightest of the Art. There are 4 commercial Lisp companies and a total of 8 standard-compliant implementations.
There is absolutely no comparison, and it's both telling and sad you would utter them in the same sentence. Take it back.