The site is extremely slow at the moment. In case anyone has trouble accessing it, I managed to load it, and here's the relevant bit:
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.
Oh It makes complete and total sense. PHP was not a "language" originally. It was a collection of handy functions in Rasmus' toolbox. When it "graduated" to language, and I use that term loosely no one bothered to clean it up. No one bothered to clean it up is PHP's mantra and it explains everything that people hate about the language perfectly.
Or perhaps 'standards last forever'. By the time someone thought to say 'Oh, we should probably fix this mess we created', it's already being used in to many programs to change it out for something else.
Heck, even without removal, PHP being "the language of sensibly named functions with a bunch of legacy aliases that you can ignore" would still be a million times better than being "the language where every single stdlib function has its own unique form of retardation"
(</i> used in the dictionary sense, not in the able-ist sense)
I think the point is that it is simple to add symbols in the C source code. You simply count the number of characters and then add it in the appropriate place.
That he futzed around with function name lengths instead of just fixing the hash function is a pretty good analogy for both the design of the language as a whole and to much of the code that's written in it.
Queue "it's popular and therefore must be good" trolls.
I understand it but don't get it. Why use strlen? Even a simple one-line character-xor does better. (I tested using the 354 function names from the PHP2 source code.) Why would you bother bucketing, but then take such a silly approach and actually aim to name things for length?
Sometimes I feel like Rasmus Lerdorf is going to come clean one bright April Fools' Day, and reveal that PHP was just a hilarious joke that sort of got out of hand.
Yeah! Haha the joke's on Facebook, Wikipedia, Flickr, Yahoo! Answers, Photobucket, Digg (RIP), etc ... Those fools have been using a joke language and didn't even know it!
Seriously, the PHP hate gets old. It started off very much as a scratch to one man's itch. That man wasn't the best programmer ever (wouldn't even say top 10%, or even close), but he had an idea and executed it to make one of the most successful free products ever that has generated billions and billions of dollars for the world economy.
It puts the importance of good language design in perspective in two completely different ways, though!
You're completely correct, but at the same time, PHP also stands as a stark warning not to throw things together with no design, lest your misshapen child end up being immortalized.
PHP is simultaneously the best-case outcome and the worst-case outcome for a badly designed language.
In what perspective? PHP doesn't have to bear the weight of many other programmers dealing with their suboptimal design decisions.
A popular DB had an intentional feature that lost data on 32-bit builds. You might not get bitten until you've gotten plenty of data in it - it's still a terrible design that hurts everyone.
You'd have to qualify what "poorly designed" means or even what language you're talking about. In that mail, Lerdorf recounts his time writing PHP/FI nearly twenty years ago. It's like judging the current Linux kernel based on the early version Linus Torvalds was using in his lab around the same time.
Arguments from popularity can be amusing when laden with sarcasm, but that doesn't make them valid arguments.
I'd say PHP is and has been popular more because it's easy to hire an army of self-trained "php developers" for peanuts than because it is a "good" language.
I'd argue that PHP has been popular because it makes hiring a developer optional for the vast majority of folks who want to put up a website. In the days before Facebook et al. Your options were Geocities and family or a cheap shared host with apache and PHP3-4. When the most sophisticated portions of a site were a gallery and contact form, the "put files here, done" methodology is pretty hard to beat.
It being a "bad language" is irrelevant for someone who's end result requirement is a functional page over technological purity.
There was a time (and it wasn't terribly long ago) that "self trained" developers garnered additional respect in the community because they had the sand to go in and learn a system under their own power instead of having concepts spoon-fed to them in class. Academically trained developers were known first and foremost for over-engineering otherwise simple tasks and typically required two to four years in industry to break of bad habits.
> Arguments from popularity can be amusing when laden with sarcasm, but that doesn't make them valid arguments.
Informal fallacies don't automatically invalidate the argument either. Informal fallacies are rhetorical red flags: they predict problematic logic, because they're generally used in place of actual logic: but unless you're talking about formal fallacies, the argument can still be valid.
In this case, it depends entirely on whether or not you accept popularity as a valid metric for success or quality or whatnot: you're arguing whether or not the "P -> Q" premise is true or false, not whether or not the argument itself is valid. Because P is true.
I don't know if you can say that "those fools have been using it and don't even know it." It's hard to tell if they had a time machine would they go change that decision (to use php). Anyway I agree that there has already been too much time spent on this language, no need to waste more beating the dead horse.
that has generated billions and billions of dollars for the world economy.
That's an interesting thought. Has it? I wonder what a lot of websites would have used if PHP has not been around. I wonder if, overall, PHP existing has actually generated billions and billions of dollars in value.
Not sure what they would have used because it seems like no other language makes it quite as easy to install and start using. I get the feeling a lot of language designers don't really get that some poor sap has to get the language installed on the web server.
Any of the myriad of good languages available out there? Php is only easy to install because it comes pre-installed in most low-end servers out there. Without that fact, php is just as cumbersome to get started as any other language.
"Php is only easy to install because it comes pre-installed in most low-end servers out there. Without that fact, php is just as cumbersome to get started as any other language."
It comes installed because it is easy to install. Someone had to install it and PHP is sure easy for any SysAdmin to get installed. It is easy to start because the PHP folks made it easy to get started.
Look at the steps to get PHP installed versus other languages. Then look at what "Hello World" and a simple form take.
It seems many hosting companies or their sysadmins don't agree since PHP gets installed and Ruby, etc. doesn't. PHP is an easy to install module and very easy to do the first program since its just a part of the webpage.
If you want your favorite language to replace PHP, then you have to make it easy for the sysadmin to install (preferably 1 line) and for new programmers to be able to use the language by just uploading a file.
Yeah, but PHP use as CGI was likely never more than 1% of the market. What most people mean is installing mod_php is easier than setting up another language via cgi or fastcgi.
Good to know, I haven't used Apache in a while. I normally use Nginx, but that's not quite as easy to get up and running because you got to set PHP5-FPM sockets in your virtual host. ;)
There's the rub, really. I have been fascinated by how quickly the "it's so easy to install" mantra is replaced with "only a noob would use those settings, let me link you to a detailed guide on how you should really use PHP," at which point it becomes more complicated to install than alternatives.
I am not a fan, so I am biased. But I've never quite seen the appeal of such a superficial attribute as "it's already on my cheap server." Are we not programmers? How hard is it, really, to install a JVM, Python, Ruby, Go, or any other platform? It's never taken me more than scarce minutes. To my mind, it seems widespread delirium prioritizing such a non-priority over peace of mind and performance. It's akin to selecting an operating system based on the fonts it ships with.
> But I've never quite seen the appeal of such a superficial attribute as "it's already on my cheap server." Are we not programmers?
Most people who start out programming PHP aren't programmers. (I think that's a good thing FWIW.) The ease to non-programmers explains the wide spread which is what the discussion is about.
Meanwhile, Python comes already installed by default in most linux distributions. So, forget .ini files, forget apache until deployment time(hell, don't be forced onto apache if you don't want to. Choose whichever deployment server you want. I know... options... it's weird... you'll get used to it), forget worrying about php upgrades on shared machines, forget that apt-get line. .py file, and you're up and running (and headache-less).
I think your missing the point, what comes in a Linux distribution is irrelevant. What comes installed from a hosting company is what matters, and since PHP is easy for a SysAdmin to install it was installed. Choice is often limited by the host.
Most hosts out there offer linux as their main platform? Plus, installing python with apt-get is not much more difficult than php. One liner, minus the .ini configuration stuff.
Nope, I install PHP and then upload a page with PHP embedded and it works. It is not that easy with python. That's why all these hosting accounts had LAMP and not something else.
What happened to context? The guy above me clearly said he used apt-get to install php. You're gonna have to install php somehow, whether you're gonna use apt-get or not is your decision, but whichever way you choose, apt-get or make, the difficulty is about the same.
I have a fresh install of such a distro, where Python is included. What do I need to do to from Python present an input form which takes my name and a second page that greets me using the same name? Including deployment of course, how else should I test it without paying a web host?
I'm not discussing headaches, I do nit particularly like PHP. My point is just that Python is not very easy to get started with for beginners.
import web
urls = (
'/(.*)', 'hello'
)
app = web.application(urls, globals())
class hello:
def GET(self, name):
if name:
return 'Hello, ' + name + '!'
else:
return "<form><input name='name'></form>"
if __name__ == "__main__":
app.run()
upload into your web server's cgi-bin folder, or have the server configured to exec all *.py files as python
ED> yeah, this is a few more lines of code than PHP and it requires a teeny tiny amount of knowledge about how the web works - and that "takes 5 minutes to get started" vs PHP's "takes 2 minutes to get started" is a big difference for someone who doesn't know what they're doing but wants results immediately :P
EDED> Actually now that I think about it, that's how /I'd/ start a simple webapp as it has the structure in place to grow easily and elegantly -- if you're willing to do things the quick and dirty way, you can go without a framework and just print an HTTP response to stdout - in which case the only difference with PHP is that the python version requires "print 'Content-type: text/html\n'" at the top
I certainly do agree that this somewhat more abstract approach is much better for stable web applications. My point is that PHP doesn't require you to understand anything to get started, which explains its widespread usage. That is of course not true if you want security or maintainability, but that is exactly the snake oil sold by PHP.
That has tracebacks on error and HTML escaping, so I'd say it's considerably better for a tiny increase in difficulty (but you're right that no matter now tiny the difference, PHP is still easier)
> just as cumbersome to get started as any other language.
Any other language that has dedicated .INI files to determine its behaviour, maybe. PHP caught on because of "Hello world" in a web browser, and smart people didn't realize the value of novelty.
We had better designed languages. The problem is getting them installed and easy of learning. The better designed languages weren't better in those areas.
On the other hand, they have to resort to writing it in X and probably having a smaller and more expensive pool of talent to pull from. Not to mention, it may have never been a product to begin with or come to fruition fast enough under a different language. I guess everyone should be writing in C, in the event they get to Facebook scale where the economies tip towards running in a faster runtime? Oh wait, there are plenty of C haters, too; let's go shopping!
I can't say whether something else wouldn't have replaced PHP eventually, but I can say PHP definitely played it's part in making the web we know today. Back in the day, say circa 2000, unless you were wealthy/lucky enough to have your own server around, if you wanted a website you were stuck with shared hosting.
Many of us "web devs" were running desktop windows and had never even used a *nix command line or studied programming beyond BASIC. CGI (perl) scripts were absolutely painful to install, much less write. Dealing with stdin just to get post variables? Python and Ruby were rarely supported as CGI, and there were likely no web frameworks back then that you could manage to install on a shared account. Besides, a lot us back then weren't programmers to being with, we just wanted a web site to scratch an itch. Programming was a means to an end, and I think the rasmus quotes support that.
Enter PHP(&mod_php). Open up your FTP client, rename index.html to index.php, edit to add Hello <?=$name?>, load up index.php?name=Bob in IE, see "Hello Bob", MIND BLOWN! PHP was easy to use, learn, and it came with a huge function library built in. It was a sandbox to play in. The barrier of entrance difference between cgi/perl and PHP was like GIMP to Windows Paint.
The number of web scripts available to use exploded after PHP hit the scene. Message boards, calendars, photo galleries, shopping carts, etc. Sure, a lot of the code written was horrible by today's standards, or even CS standards of then, but that's not the point. Websites were launched, communities were formed, products were sold. Sure phpBB, wordpress, and others code was not properly engineered, but where would the web be without the communities and blogs they allowed to form?
Facebook started on shared PHP hosting. The mediawiki script was created because Magnus Manske wanted to try out PHP. Yahoo actually chose PHP to replace their in-house scripting language over ASP, Coldfusion, and other proprietary options when using open source was a huge risk. Python and ruby were not even on the web radar when yahoo chose PHP. [1]
Now today we may look at the code derived from the era before python, ruby, svn, github, cheap easy VPS/VM access, when shared web hosting was the only PaaS, and look in horror, but the fact remains that PHP powers 75% or more of all websites on the internet today.[2][3]
To ask if PHP has generated value, is to ask if Windows has generated value. They may have been ugly, but they got us where we are today, and the PHP of today is not the PHP of 2000.
And who cares about that, in turn? It's just the glue you write your data structures, objects and functions in. You can still write shitty code in a nice language, and you can architect something well thought out in BASIC.
A nice language makes for shorter, more expressive code, sure, but that's like having a fast car that handles well; it still matters more where you're driving it. If someone is making a trip with a caravan of a million rust buckets to a nice place, why would they care about some Porsche owner moaning about how that is all so very wrong?
If PHP developers complained all the time about how programming sucks, then you could maybe tell them to use a better language. But the PHP devs aren't really complaining, rather people who aren't even using it.
People use Wikipedia. I dare say Wikipedia improved a lot of lives a lot. Meanwhile, a gazillion static blog generators written in hip language of the day prove no real benefit over notepad, or this textarea right here. It's like making a trip with a handful of people to a place that's been explored by others decades ago, and then being bitter that nobody cares, and hating on the roaring party going on next door.
If you want to make language A or B more popular and better accessible when it comes to web hosting, write the killer app in it that nobody can do without, and which can't be implemented in PHP. That should be simple, since PHP sucks so much, right?
Lastly, is the HN code nice? I wouldn't even know, it's that irrelevant. The HTML it puts out sure is atrocious, but even that doesn't matter.
If any other programming language was as popular, there would be just as much bad code in it. Nothing about PHP forces you to write bad code, nothing about other languages forces you to write good code.
Also, if PHP is really just sucky and offers no advantages, why not simply rewrite it in a better language? Surely the costs would ammortize quickly.
I don't dispute that people will write bad code in any language. The problem I have with PHP is that it at best, makes it exceedingly easy to write bad code, and at worst has actually encouraged it (see, for example, magic quotes).
I also am not claiming that PHP offers no advantages. Certainly it has some good things about it. The choice to allow you to easily interleave PHP code with HTML is an example of a simple feature which makes life really easy when you're setting up a site.
But rewriting in a better language is not necessarily a viable option. It's generally not the call of the person tasked with maintaining it, and even if it is, "cost will amortize quickly" isn't necessarily good enough on a large project with limited funding.
Yes I know, I was just pulling out a random example that came to mind. Still, you'll find a lot of code out there running on old versions of PHP with magic quotes enabled.
And that's another part of the problem: the incorporation of really bad ideas that end up poisoning code bases for years to come, simply because they weren't properly vetted before being released.
I see more people complaining about maintaining bad code in other languages than I do about maintaining bad code in PHP. I personally have been a PHP developer since 2001, I haven't maintained any bad code... Actually, I spent a good portion of my early career completely rewriting shitty PHP code to be good PHP code.
> A nice language makes for shorter, more expressive code, sure, but that's like having a fast car that handles well; it still matters more where you're driving it.
An f1 racer driving an f1 car will always beat another f1 racer driving a beetle.
Plenty of killer apps use other languages- Instagram, Pinterest, Quora, and Youtube, for example. Google certainly wasn't written in php.
Matter of fact is, facebook has spent millions of dollars trying to change languages, trying to make php behave, trying to make php faster. Wikipedia is nice, but I bet they'd be able to serve even more people if they based used a better language.
HN code is probably nice. The HTML is just the surface of the architecture sites like these run upon.
> An f1 racer driving an f1 car will always beat another f1 racer driving a beetle.
Which is nice when you're having a race, but rather useless when you don't.
> Plenty of killer apps use other languages- Instagram, Pinterest, Quora, and Youtube, for example. Google certainly wasn't written in php.
Those are't apps in the sense that you can install and modify them, are they. The fact that youtube exists does nothing to drive Python adoption. Sure the same can be said for Wikipedia, but not for MediaWiki.
>> An f1 racer driving an f1 car will always beat another f1 racer driving a beetle.
>Which is nice when you're having a race, but rather useless when you don't.
I was driving a point using the analogy previously used. I think trying to write a php app is like trying to drive a beetle, when you could be using a transformer- It's a robot when you need it to be a robot, and it's a car when you need it to be a car.
> Those are't apps in the sense that you can install and modify them, are they. >The fact that youtube exists does nothing to drive Python adoption. Sure the same can be said for Wikipedia, but not for MediaWiki.
If you're gonna say that about youtube, the same should be said about Facebook. With python, at least we have Django, Pyramid, Bottle, Flask. All of which are good open-source platforms that allows you to quickly get a web project going(not just a wiki), and which do a lot to drive Python adoption.
> There are... Just so many open source web applications that aren't written in PHP. So, so many.
That was just an example of apps written in python. The comprehensive list is much, much larger (though I thought that was implied).
I'm not really making any strong comment about PHP's usefulness or anything. I'm just saying that many of the things that have happened in its development would sound like they came right out of the manual for INTERCAL, except that they're too over the top.
As for its popularity, well, that would be the "got out of hand" part.
Joke is sort of on them. Every single article I've read with engineers at the big sites talking about PHP mainly deals how to get around PHP. All of the things PHP is lauded for making things "easy" are the exact things the big sites go out of their way to avoid.
Those sites are popular in spite of PHP, not because of it. If Mark had been proficient in ASP instead of PHP, FB would probably be running .NET. It's not like anything early FB did was particularly impressive and relied on special language features. (Correct me if I'm wrong.)
On the other hand, what about time-to-market and worse-is-better and good-is-the-enemy-of-perfect? Could it be other efforts in the same space failed (and you never even heard of them) because they wanted to do things "right"?
That's more happenstance of what happened to be on-hand. It's unlikely using, say, ASP with VBScript, would have generated any sort of "better-is-worse" type scenario.
A Windows 2000 server with IIS/ASP installed had the same time-to-market advantage as PHP.
> I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.
> I was really, really bad at writing parsers. I still am really bad at writing parsers. We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.
I find comments like these interesting and at the same time ironic, especially on a sites like HN. I could think of 10 reasons why PHP is the "wrong" language but I could also think of 100 reasons why it made a successful one. Rasmus my not have created a perfect language but he sure did create one heck of a successful one which even the "elitest"/"perfect" language are still trying to catch upto.
Never belittle other's work, especially when striving to discover that magic formula to success. All the posts on HN about "How we made X successful" and we brush off the obvious ones in front of our eyes? Ever stopped to think why a crappy X is popular? Maybe there is something to it.
Also not to mount on irony but keep in mind, you are commenting on a site that has the HTML syntax from the Geocities era (it has its reasons though).
Can you explain how, in any possible universe, using strlen as a hash function and choosing function named to bin on length in any way helps PHP, at all?
well I can think of a reason you might do that. It's dead simple, and you can easily predict the distribution, so you can choose names that have a relatively good distribution. Sure your first few buckets go empty, but at that point, you're overthinking it, NEXT SECTION!
I've always wondered if there was a place for a language that was properly designed, but copied PHP/php-fpm's execution model? It has beautiful horizontal scaling, but perhaps the long lived process model is better (ruby, go, etc) than PHP's "stateless" (as in, the app holds no real state itself after the request, it shuts down) per-req setup. Thoughts?
Actually, I've been looking at SCGI with Nimrod... ;)
Seriously though, I've been trying to find out lately whether CGI is at all useful in this day and age, or whether if some well-designed scripting language that used the PHP style of run-time would be better to avoid using it.
Like Perl, PHP is a long-lived, heavily-used-in-production language, which means there is a lot of cruft that has accumulated over the years that's difficult for the platform developers to just slough off. But much like there is a Modern Perl movement that has coalesced around voluntarily cutting out cruft and using a much cleaner, nicer-to-work-width subset of Perl, there is a similar movement in PHP-land that's doing the same thing.
PHP The Right Way (http://www.phptherightway.com/) is a good place to start if you're curious what "modern PHP" looks like.
Python is elegant, and my first real commitment to a language, but imo nothing beats Haskell in elegance (though scheme has a certain beauty about it). Perhaps this is just me being temporarily enamored though, I can't help but to link to this post:
Haskell and I have been doing well so far in the "RealWorld" and I hope it keeps going that way :D If not, I'll probably put more time into python and C again.
I personally don't feel that I've struggled with monads that much. Perhaps that was because I was okay with "I know how to use monads or wrestle them into getting something to work" (took 20 minutes) until I got to "I understand what monads are for, I understand how to compose them, and I can see how they aren't a hindrance and in many cases are useful." (has taken 4-5 months on/off learning).
I haven't ran into memory issues yet, but I have heard others have a very hard time reasoning about memory/space leaks. However, something I hear less often is that the memory problems people have also happen in other languages.
This. Nobody taken seriously in PHP world doesn't use modern PHP tools, Good frameworks, Composer, follow PHP-FIG standards, all that stuff... Just because you had to maintain a PHP4 app 10 years ago, doesn't mean PHP hasn't changed. And it also doesn't mean real devs don't have standards and follow up-to-date guidelines.
For sure. WordPress has a lot of legacy backwards compatibility on its shoulders. If they could shrug it off and start again, I'm sure it would be a lot cleaner.
The project I'm working on (https://github.com/idno/idno) is PHP, but explicitly doesn't support legacy versions, in order to rule out the way of working that was finally made obsolete in v5.3. I'm very happy with the language, and I can usually express what I need simply. Reflection could use a little love, mind you.
I'm building some projects that are only targeted at 5.5 -- once you do that, and stick to all the PSR standards, then it's actually really nice, super productive, and the cruft that exists gets ignored. I like PHP still shrugs
True. But Wordpress is a blogging engine with tons of stuff bolted on to make it behave like a CMS. It appeals to the same group of people that disable error reporting to make their spaghetti code work.
I do a lot of PHP programming. Frameworks like Laravel are a godsend. Sometimes I have to work on a Wordpress project and it makes me cry.
PHP is more evolutionarily fit than Perl in a handful of very important ways (I would illuminate, for example, function signatures and a pre-built object system, syntactically trivial nesting of data structures, and a newcomer-friendly out-of-the-box execution model).
That said, I wrote Perl for years as a hobbyist (still do, now and then), and have spent the last 6 or so primarily writing PHP. There is not a day that passes that I don't miss some aspect of the rich, expressive, elegant, sophisticated, and intellectually delightful environment that is Perl at its best.
It is a doomed and sinking continent, Perl, but if we let the considerable wisdom of its once-great civilization evaporate into trite dismissal, we as a culture stand to lose a great deal.
PHP doesn't insist on the array() keyword, currently. The mixing of associative and sequential arrays is ambiguous, although you can think of them all as being associative; it's just, PHP will supply some keys if you don't provide any. Whether that's kludgey or acceptable is up for discussion. (I don't mind it at all.)
I had heard they were finally fixing that, which is why I made my comment a reference to the past. I'm glad they settled on a syntax that wasn't too far out of the norm from what you would expect, given PHP's roots (i.e. Perl). I seem to recall the RFC at some point had a different syntax, but I could be remembering incorrectly.
I'd think the mixing of associative and sequential arrays are one of the key things that lowers the barrier to entry though.
For me it fails the "similar things should look similar, different things should look different" test. Then again, they aren't really all that different in PHP. I guess it comes down to me preferring my sequential and associative data structures to be separate, which is a fairly fundamental difference to how PHP thinks it should be. I have a sneaking suspicion that the complexity this data structure tries to hide leaks out through the numerous functions used to interact with it[1], which just shifts the pain slightly farther down the line, and possibly from a one-time event (when learning the fundamentals) to a regular occurrence as it causes problems continually later.
There's a lesson here about how sometimes it's okay to fit your data to your code. This was, afterall, in php for years without causing much, if any, problems for end users.
I guess there won't be much agreement here on HN, but this deserves to be recognized as an amusing and clever solution to a problem. Even if the problem is self created.
PHP is great for doing quick and dirty dynamic web pages. So what if it doesn't scale out to a million line program?
Except this was no acceptable solution. Instead of using a better hashing algo than strlen(!), the function names was chosen by length, leading to one of the largest and most criticised flaws of PHP: the inconsistent function naming.
While I understand why this was done (for the sake of comparability), I feel like its better to bite a bullet and slowly phase out broken functions over several versions.
Warn initially (few versions) and then raise exception/critical errors after. If developer isn't willing to update, chances are server isnt being updated either anyways.
What about usability? "I wasn't too worried about not being able to remember the few function names." certainly indicates that usability decreased. That may have set a pattern for it getting broken, eventually.
This. I was implying that length of the string should mean length in characters, not bytes. This could lead to broken code and would require programmers to keep in mind both.
I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.
Well, not really. Consider the (very common) case of a PHP-based blog, forums or shop being hosted on shared hosting. The latter gets an upgrades, and the site explodes.
(I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)
No amount of "being a better programmer" can fix the fact that $x == $y && $y == $z does not guarantee that $x == $z or $a[$x] == $a[$y]. Nor that passing by value may or may not protect you from destructive updates, depending on whether your caller passed by reference. The language simply can't be trusted to behave predictably; a huge number of its features have some kind of trap built in by mistake.
Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.
Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism.
If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.
Builtin features you can't override have data-dependent bugs. Most values work, but some values fail (deterministically) and most users don't know that. You can't even fix the interpreter unless you're running a non-shared copy and are not running any third-party code which happens to rely on the odd misbehavior.
Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.
Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.
I'm not really sure if this is right, but my best guess is that script parsers use a hash table to map the name of a function to a function pointer or something. Hash tables enable fast information retrieval by some key (usually a string). By just knowing the key you immediately (or after some calculations) know in which bucket to search for the element. For details see http://en.wikipedia.org/wiki/Hash_table.
For the hash table to be efficient, an algorithm that stores the elements has to evenly distribute them across the buckets. But instead of using a "proper" algorithm, a string length was used to determine in which bucket a function name belongs. To have the names evenly distributed, the names had to be of different lengths, even if that meant abandoning some naming conventions.
The site is extremely slow at the moment. In case anyone has trouble accessing it, I managed to load it, and here's the relevant bit:
That can't possibly be true. I refuse to believe it.
Either way, it's hillarious :-)
Oh It makes complete and total sense. PHP was not a "language" originally. It was a collection of handy functions in Rasmus' toolbox. When it "graduated" to language, and I use that term loosely no one bothered to clean it up. No one bothered to clean it up is PHP's mantra and it explains everything that people hate about the language perfectly.
Or perhaps 'standards last forever'. By the time someone thought to say 'Oh, we should probably fix this mess we created', it's already being used in to many programs to change it out for something else.
you can still deprecate in Vx and remove in Vy.
I mean, I may understand keeping the strange array-is-a-hash thingy, but changing function names is easy.
Heck, even without removal, PHP being "the language of sensibly named functions with a bunch of legacy aliases that you can ignore" would still be a million times better than being "the language where every single stdlib function has its own unique form of retardation"
(</i> used in the dictionary sense, not in the able-ist sense)
Even with the "PHP is a personal hack", it doesn't make sense. More effort goes into naming functions than writing a one-line xor "hash".
I'm more inclined to believe Rasmus is trolling here. Sure, he used strlen, but it's too hard to believe functions were named with this in mind.
I think the point is that it is simple to add symbols in the C source code. You simply count the number of characters and then add it in the appropriate place.
Well, good thing that PHP is open source and we can just pop a visit to http://museum.php.net/php2/ to actually see that it is true.
Taken from PHP 1.99 source [1]: https://dl.dropboxusercontent.com/s/e8k4n2mx1y5vsa4/Zrzut%20...
So yeah, it's true :).
[1] http://museum.php.net/php2/php-1.99s.tar.gz
So what I don't get is why the function names needed to be of a certain length, since he's hard-coding the buckets.
It's a joke. A clever satire. I simply refuse to believe it's real.
Yeah, well, I for one just spit beer out of my mouth at a fucking public sports bar.
That he futzed around with function name lengths instead of just fixing the hash function is a pretty good analogy for both the design of the language as a whole and to much of the code that's written in it.
Queue "it's popular and therefore must be good" trolls.
How about spelling trolls? It's "cue":
"From the letter Q, abbreviation of Latin quando (“when”), marked on actor's play copy where they were to begin." - http://en.wiktionary.org/wiki/cue
maybe he wants them to line up single file?
"it's popular and therefore must be good"
Feels strawman-ish, I've never heard anyone say that. "It's popular therefore it is a legitimate language choice", sure.
PHP was doing MVP before it was cool.
I understand it but don't get it. Why use strlen? Even a simple one-line character-xor does better. (I tested using the 354 function names from the PHP2 source code.) Why would you bother bucketing, but then take such a silly approach and actually aim to name things for length?
Perhaps, and I am being totally serious here, Rasmus did not know about xor.
Sometimes I feel like Rasmus Lerdorf is going to come clean one bright April Fools' Day, and reveal that PHP was just a hilarious joke that sort of got out of hand.
Yeah! Haha the joke's on Facebook, Wikipedia, Flickr, Yahoo! Answers, Photobucket, Digg (RIP), etc ... Those fools have been using a joke language and didn't even know it!
Seriously, the PHP hate gets old. It started off very much as a scratch to one man's itch. That man wasn't the best programmer ever (wouldn't even say top 10%, or even close), but he had an idea and executed it to make one of the most successful free products ever that has generated billions and billions of dollars for the world economy.
Can you say the same?
Does the fact that it's used by large websites change the fact that it's a poorly designed language?
Does the fact that it's a poorly designed language change the fact that it's a useful one?
No.
Being poorly designed changes the extent to which it is useful.
No, but it certainly puts the importance of good language design in perspective.
We tend to overvalue good design just for good design's sake.
It puts the importance of good language design in perspective in two completely different ways, though!
You're completely correct, but at the same time, PHP also stands as a stark warning not to throw things together with no design, lest your misshapen child end up being immortalized.
PHP is simultaneously the best-case outcome and the worst-case outcome for a badly designed language.
In what perspective? PHP doesn't have to bear the weight of many other programmers dealing with their suboptimal design decisions.
A popular DB had an intentional feature that lost data on 32-bit builds. You might not get bitten until you've gotten plenty of data in it - it's still a terrible design that hurts everyone.
You'd have to qualify what "poorly designed" means or even what language you're talking about. In that mail, Lerdorf recounts his time writing PHP/FI nearly twenty years ago. It's like judging the current Linux kernel based on the early version Linus Torvalds was using in his lab around the same time.
The filesystem layout on Linux was never pessimized in order to work around using string length (STRING LENGTH) as a hash function.
...except PHP still has htmlspecialchars as a core library function. If Linux ever had these some of warts, they were resolved long ago.
No they weren't. Go look at the TTY driver if you need an example. Any place you interface with user code you are stuck.
Arguments from popularity can be amusing when laden with sarcasm, but that doesn't make them valid arguments.
I'd say PHP is and has been popular more because it's easy to hire an army of self-trained "php developers" for peanuts than because it is a "good" language.
I'd argue that PHP has been popular because it makes hiring a developer optional for the vast majority of folks who want to put up a website. In the days before Facebook et al. Your options were Geocities and family or a cheap shared host with apache and PHP3-4. When the most sophisticated portions of a site were a gallery and contact form, the "put files here, done" methodology is pretty hard to beat.
It being a "bad language" is irrelevant for someone who's end result requirement is a functional page over technological purity.
Disclosure: I develop mainly in C#
Facebook itself was PHP website thrown together without design!
I don't think we're saying different things. :)
There was a time (and it wasn't terribly long ago) that "self trained" developers garnered additional respect in the community because they had the sand to go in and learn a system under their own power instead of having concepts spoon-fed to them in class. Academically trained developers were known first and foremost for over-engineering otherwise simple tasks and typically required two to four years in industry to break of bad habits.
> Arguments from popularity can be amusing when laden with sarcasm, but that doesn't make them valid arguments.
Informal fallacies don't automatically invalidate the argument either. Informal fallacies are rhetorical red flags: they predict problematic logic, because they're generally used in place of actual logic: but unless you're talking about formal fallacies, the argument can still be valid.
In this case, it depends entirely on whether or not you accept popularity as a valid metric for success or quality or whatnot: you're arguing whether or not the "P -> Q" premise is true or false, not whether or not the argument itself is valid. Because P is true.
I don't know if you can say that "those fools have been using it and don't even know it." It's hard to tell if they had a time machine would they go change that decision (to use php). Anyway I agree that there has already been too much time spent on this language, no need to waste more beating the dead horse.
that has generated billions and billions of dollars for the world economy.
That's an interesting thought. Has it? I wonder what a lot of websites would have used if PHP has not been around. I wonder if, overall, PHP existing has actually generated billions and billions of dollars in value.
Perhaps not in value, but in GDP?
Not sure what they would have used because it seems like no other language makes it quite as easy to install and start using. I get the feeling a lot of language designers don't really get that some poor sap has to get the language installed on the web server.
Any of the myriad of good languages available out there? Php is only easy to install because it comes pre-installed in most low-end servers out there. Without that fact, php is just as cumbersome to get started as any other language.
"Php is only easy to install because it comes pre-installed in most low-end servers out there. Without that fact, php is just as cumbersome to get started as any other language."
It comes installed because it is easy to install. Someone had to install it and PHP is sure easy for any SysAdmin to get installed. It is easy to start because the PHP folks made it easy to get started.
Look at the steps to get PHP installed versus other languages. Then look at what "Hello World" and a simple form take.
> "Look at the steps to get PHP installed versus other languages"
Not much different to getting CGI working. If you need it working well, FastCGI is as much effort as PHP-fpm. SUexec is as much effort as SUPHP.
Any language could supplant PHP in terms of ease of deployment, there's little out there that doesn't have some CGI library to handle the mucky parts.
Not that I am advocating use of CGI for anything non-trivial.
> Look at the steps to get PHP installed versus other languages. Then look at what "Hello World" and a simple form take.
That's really just not true. Installing anything capable of CGI is as easy to install as PHP.
It seems many hosting companies or their sysadmins don't agree since PHP gets installed and Ruby, etc. doesn't. PHP is an easy to install module and very easy to do the first program since its just a part of the webpage.
If you want your favorite language to replace PHP, then you have to make it easy for the sysadmin to install (preferably 1 line) and for new programmers to be able to use the language by just uploading a file.
Yeah, but PHP use as CGI was likely never more than 1% of the market. What most people mean is installing mod_php is easier than setting up another language via cgi or fastcgi.
Boom, I just installed PHP5 on Apache on Ubuntu, now I just upload a file to my project root.
Let me know when you find any way easier than that.
installs apache, by default.
Good to know, I haven't used Apache in a while. I normally use Nginx, but that's not quite as easy to get up and running because you got to set PHP5-FPM sockets in your virtual host. ;)
There's the rub, really. I have been fascinated by how quickly the "it's so easy to install" mantra is replaced with "only a noob would use those settings, let me link you to a detailed guide on how you should really use PHP," at which point it becomes more complicated to install than alternatives.
I am not a fan, so I am biased. But I've never quite seen the appeal of such a superficial attribute as "it's already on my cheap server." Are we not programmers? How hard is it, really, to install a JVM, Python, Ruby, Go, or any other platform? It's never taken me more than scarce minutes. To my mind, it seems widespread delirium prioritizing such a non-priority over peace of mind and performance. It's akin to selecting an operating system based on the fonts it ships with.
> But I've never quite seen the appeal of such a superficial attribute as "it's already on my cheap server." Are we not programmers?
Most people who start out programming PHP aren't programmers. (I think that's a good thing FWIW.) The ease to non-programmers explains the wide spread which is what the discussion is about.
Meanwhile, Python comes already installed by default in most linux distributions. So, forget .ini files, forget apache until deployment time(hell, don't be forced onto apache if you don't want to. Choose whichever deployment server you want. I know... options... it's weird... you'll get used to it), forget worrying about php upgrades on shared machines, forget that apt-get line. .py file, and you're up and running (and headache-less).
I think your missing the point, what comes in a Linux distribution is irrelevant. What comes installed from a hosting company is what matters, and since PHP is easy for a SysAdmin to install it was installed. Choice is often limited by the host.
Most hosts out there offer linux as their main platform? Plus, installing python with apt-get is not much more difficult than php. One liner, minus the .ini configuration stuff.
"apt-get is not much more difficult than php"
Nope, I install PHP and then upload a page with PHP embedded and it works. It is not that easy with python. That's why all these hosting accounts had LAMP and not something else.
What happened to context? The guy above me clearly said he used apt-get to install php. You're gonna have to install php somehow, whether you're gonna use apt-get or not is your decision, but whichever way you choose, apt-get or make, the difficulty is about the same.
The difficulty isn't the same because installing python doesn't install any web server integration. That's the point.
I have a fresh install of such a distro, where Python is included. What do I need to do to from Python present an input form which takes my name and a second page that greets me using the same name? Including deployment of course, how else should I test it without paying a web host?
I'm not discussing headaches, I do nit particularly like PHP. My point is just that Python is not very easy to get started with for beginners.
upload into your web server's cgi-bin folder, or have the server configured to exec all *.py files as python
ED> yeah, this is a few more lines of code than PHP and it requires a teeny tiny amount of knowledge about how the web works - and that "takes 5 minutes to get started" vs PHP's "takes 2 minutes to get started" is a big difference for someone who doesn't know what they're doing but wants results immediately :P
EDED> Actually now that I think about it, that's how /I'd/ start a simple webapp as it has the structure in place to grow easily and elegantly -- if you're willing to do things the quick and dirty way, you can go without a framework and just print an HTTP response to stdout - in which case the only difference with PHP is that the python version requires "print 'Content-type: text/html\n'" at the top
I certainly do agree that this somewhat more abstract approach is much better for stable web applications. My point is that PHP doesn't require you to understand anything to get started, which explains its widespread usage. That is of course not true if you want security or maintainability, but that is exactly the snake oil sold by PHP.
But this web framework is much newer than PHP, isn't it? And this does not look better or easier than PHP: https://wiki.python.org/moin/CgiScripts
> And this does not look better or easier than PHP: https://wiki.python.org/moin/CgiScripts
That has tracebacks on error and HTML escaping, so I'd say it's considerably better for a tiny increase in difficulty (but you're right that no matter now tiny the difference, PHP is still easier)
./golang_app.bin
> just as cumbersome to get started as any other language.
Any other language that has dedicated .INI files to determine its behaviour, maybe. PHP caught on because of "Hello world" in a web browser, and smart people didn't realize the value of novelty.
If people adopted a better-designed language, maybe that could have generated trillions and trillions of dollars for the economy.
We had better designed languages. The problem is getting them installed and easy of learning. The better designed languages weren't better in those areas.
Oh the other hand a company like Facebook uses it and then they have to resort to developing Hip Hop to wring out more performance.
On the other hand, they have to resort to writing it in X and probably having a smaller and more expensive pool of talent to pull from. Not to mention, it may have never been a product to begin with or come to fruition fast enough under a different language. I guess everyone should be writing in C, in the event they get to Facebook scale where the economies tip towards running in a faster runtime? Oh wait, there are plenty of C haters, too; let's go shopping!
And plenty of companies move away from Python and Ruby once they hit "own our own data center" scale, too. You only optimize once it's worth it.
Perl.
I can't say whether something else wouldn't have replaced PHP eventually, but I can say PHP definitely played it's part in making the web we know today. Back in the day, say circa 2000, unless you were wealthy/lucky enough to have your own server around, if you wanted a website you were stuck with shared hosting.
Many of us "web devs" were running desktop windows and had never even used a *nix command line or studied programming beyond BASIC. CGI (perl) scripts were absolutely painful to install, much less write. Dealing with stdin just to get post variables? Python and Ruby were rarely supported as CGI, and there were likely no web frameworks back then that you could manage to install on a shared account. Besides, a lot us back then weren't programmers to being with, we just wanted a web site to scratch an itch. Programming was a means to an end, and I think the rasmus quotes support that.
Enter PHP(&mod_php). Open up your FTP client, rename index.html to index.php, edit to add Hello <?=$name?>, load up index.php?name=Bob in IE, see "Hello Bob", MIND BLOWN! PHP was easy to use, learn, and it came with a huge function library built in. It was a sandbox to play in. The barrier of entrance difference between cgi/perl and PHP was like GIMP to Windows Paint.
The number of web scripts available to use exploded after PHP hit the scene. Message boards, calendars, photo galleries, shopping carts, etc. Sure, a lot of the code written was horrible by today's standards, or even CS standards of then, but that's not the point. Websites were launched, communities were formed, products were sold. Sure phpBB, wordpress, and others code was not properly engineered, but where would the web be without the communities and blogs they allowed to form?
Facebook started on shared PHP hosting. The mediawiki script was created because Magnus Manske wanted to try out PHP. Yahoo actually chose PHP to replace their in-house scripting language over ASP, Coldfusion, and other proprietary options when using open source was a huge risk. Python and ruby were not even on the web radar when yahoo chose PHP. [1]
Now today we may look at the code derived from the era before python, ruby, svn, github, cheap easy VPS/VM access, when shared web hosting was the only PaaS, and look in horror, but the fact remains that PHP powers 75% or more of all websites on the internet today.[2][3]
To ask if PHP has generated value, is to ask if Windows has generated value. They may have been ugly, but they got us where we are today, and the PHP of today is not the PHP of 2000.
[1] http://public.yahoo.com/bfrance/radwin/talks/yahoo-phpcon200... [2] http://venturebeat.com/2013/05/17/google-app-engine-finally-... [3] http://w3techs.com/technologies/overview/programming_languag...
Who cares? It doesn't make the language any better.
And who cares about that, in turn? It's just the glue you write your data structures, objects and functions in. You can still write shitty code in a nice language, and you can architect something well thought out in BASIC.
A nice language makes for shorter, more expressive code, sure, but that's like having a fast car that handles well; it still matters more where you're driving it. If someone is making a trip with a caravan of a million rust buckets to a nice place, why would they care about some Porsche owner moaning about how that is all so very wrong?
If PHP developers complained all the time about how programming sucks, then you could maybe tell them to use a better language. But the PHP devs aren't really complaining, rather people who aren't even using it.
People use Wikipedia. I dare say Wikipedia improved a lot of lives a lot. Meanwhile, a gazillion static blog generators written in hip language of the day prove no real benefit over notepad, or this textarea right here. It's like making a trip with a handful of people to a place that's been explored by others decades ago, and then being bitter that nobody cares, and hating on the roaring party going on next door.
If you want to make language A or B more popular and better accessible when it comes to web hosting, write the killer app in it that nobody can do without, and which can't be implemented in PHP. That should be simple, since PHP sucks so much, right?
Lastly, is the HN code nice? I wouldn't even know, it's that irrelevant. The HTML it puts out sure is atrocious, but even that doesn't matter.
>And who cares about that, in turn?
Anyone who has to maintain bad PHP code, for starters.
If any other programming language was as popular, there would be just as much bad code in it. Nothing about PHP forces you to write bad code, nothing about other languages forces you to write good code.
Also, if PHP is really just sucky and offers no advantages, why not simply rewrite it in a better language? Surely the costs would ammortize quickly.
I don't dispute that people will write bad code in any language. The problem I have with PHP is that it at best, makes it exceedingly easy to write bad code, and at worst has actually encouraged it (see, for example, magic quotes).
I also am not claiming that PHP offers no advantages. Certainly it has some good things about it. The choice to allow you to easily interleave PHP code with HTML is an example of a simple feature which makes life really easy when you're setting up a site.
But rewriting in a better language is not necessarily a viable option. It's generally not the call of the person tasked with maintaining it, and even if it is, "cost will amortize quickly" isn't necessarily good enough on a large project with limited funding.
> actually encouraged it (see, for example, magic quotes).
Actively discouraged for years, and removed completely over a year and a half ago.
Yes I know, I was just pulling out a random example that came to mind. Still, you'll find a lot of code out there running on old versions of PHP with magic quotes enabled.
And that's another part of the problem: the incorporation of really bad ideas that end up poisoning code bases for years to come, simply because they weren't properly vetted before being released.
I see more people complaining about maintaining bad code in other languages than I do about maintaining bad code in PHP. I personally have been a PHP developer since 2001, I haven't maintained any bad code... Actually, I spent a good portion of my early career completely rewriting shitty PHP code to be good PHP code.
> I haven't maintained any bad code...
>I spent a good portion of my early career completely rewriting shitty PHP code to be good PHP code.
I'm curious what you think maintenance is.
Rewriting the system from the ground up, not maintaining the current code base. Sorry I wasn't so exact on that.
Code maintenance (of good code or otherwise) is a sign of success. Rewriting everything is not.
> A nice language makes for shorter, more expressive code, sure, but that's like having a fast car that handles well; it still matters more where you're driving it.
An f1 racer driving an f1 car will always beat another f1 racer driving a beetle.
Plenty of killer apps use other languages- Instagram, Pinterest, Quora, and Youtube, for example. Google certainly wasn't written in php.
Matter of fact is, facebook has spent millions of dollars trying to change languages, trying to make php behave, trying to make php faster. Wikipedia is nice, but I bet they'd be able to serve even more people if they based used a better language.
HN code is probably nice. The HTML is just the surface of the architecture sites like these run upon.
> An f1 racer driving an f1 car will always beat another f1 racer driving a beetle.
Which is nice when you're having a race, but rather useless when you don't.
> Plenty of killer apps use other languages- Instagram, Pinterest, Quora, and Youtube, for example. Google certainly wasn't written in php.
Those are't apps in the sense that you can install and modify them, are they. The fact that youtube exists does nothing to drive Python adoption. Sure the same can be said for Wikipedia, but not for MediaWiki.
There are... Just so many open source web applications that aren't written in PHP. So, so many.
>> An f1 racer driving an f1 car will always beat another f1 racer driving a beetle. >Which is nice when you're having a race, but rather useless when you don't. I was driving a point using the analogy previously used. I think trying to write a php app is like trying to drive a beetle, when you could be using a transformer- It's a robot when you need it to be a robot, and it's a car when you need it to be a car.
> Those are't apps in the sense that you can install and modify them, are they. >The fact that youtube exists does nothing to drive Python adoption. Sure the same can be said for Wikipedia, but not for MediaWiki.
If you're gonna say that about youtube, the same should be said about Facebook. With python, at least we have Django, Pyramid, Bottle, Flask. All of which are good open-source platforms that allows you to quickly get a web project going(not just a wiki), and which do a lot to drive Python adoption.
> There are... Just so many open source web applications that aren't written in PHP. So, so many. That was just an example of apps written in python. The comprehensive list is much, much larger (though I thought that was implied).
Conversely, I wonder how much time/money has been spent porting away from PHP, or working on stuff like hiphop?
I don't have an estimate, but it's an interesting question if you're going to argue in terms of economic impact.
I'm not really making any strong comment about PHP's usefulness or anything. I'm just saying that many of the things that have happened in its development would sound like they came right out of the manual for INTERCAL, except that they're too over the top.
As for its popularity, well, that would be the "got out of hand" part.
Joke is sort of on them. Every single article I've read with engineers at the big sites talking about PHP mainly deals how to get around PHP. All of the things PHP is lauded for making things "easy" are the exact things the big sites go out of their way to avoid.
Those sites are popular in spite of PHP, not because of it. If Mark had been proficient in ASP instead of PHP, FB would probably be running .NET. It's not like anything early FB did was particularly impressive and relied on special language features. (Correct me if I'm wrong.)
On the other hand, what about time-to-market and worse-is-better and good-is-the-enemy-of-perfect? Could it be other efforts in the same space failed (and you never even heard of them) because they wanted to do things "right"?
That's more happenstance of what happened to be on-hand. It's unlikely using, say, ASP with VBScript, would have generated any sort of "better-is-worse" type scenario.
A Windows 2000 server with IIS/ASP installed had the same time-to-market advantage as PHP.
Crack cocaine is a very successful product that has generated billions and billions of dollars for the world economy.
You have to watch out for arguments from popularity, they don't prove or even suggest anything other than popularity.
https://wiki.theory.org/YourLanguageSucks
I like his quotes:
> I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.
> I was really, really bad at writing parsers. I still am really bad at writing parsers. We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.
(from http://axonflux.com/5-quotes-by-the-creator-of-php-rasmus-le...)
In a very strange way, I respect this man.
I find comments like these interesting and at the same time ironic, especially on a sites like HN. I could think of 10 reasons why PHP is the "wrong" language but I could also think of 100 reasons why it made a successful one. Rasmus my not have created a perfect language but he sure did create one heck of a successful one which even the "elitest"/"perfect" language are still trying to catch upto.
Never belittle other's work, especially when striving to discover that magic formula to success. All the posts on HN about "How we made X successful" and we brush off the obvious ones in front of our eyes? Ever stopped to think why a crappy X is popular? Maybe there is something to it.
Also not to mount on irony but keep in mind, you are commenting on a site that has the HTML syntax from the Geocities era (it has its reasons though).
I would be very interested to hear those reasons.
1. mod_php
2. ...
php prevents you from having a good page structure?
I'm no fan, but that's going a bit far, don't you think? What's a rickety syntax and inconsistent naming have to do with page design?
Can you explain how, in any possible universe, using strlen as a hash function and choosing function named to bin on length in any way helps PHP, at all?
well I can think of a reason you might do that. It's dead simple, and you can easily predict the distribution, so you can choose names that have a relatively good distribution. Sure your first few buckets go empty, but at that point, you're overthinking it, NEXT SECTION!
I've always wondered if there was a place for a language that was properly designed, but copied PHP/php-fpm's execution model? It has beautiful horizontal scaling, but perhaps the long lived process model is better (ruby, go, etc) than PHP's "stateless" (as in, the app holds no real state itself after the request, it shuts down) per-req setup. Thoughts?
See CGI.
Actually, I've been looking at SCGI with Nimrod... ;)
Seriously though, I've been trying to find out lately whether CGI is at all useful in this day and age, or whether if some well-designed scripting language that used the PHP style of run-time would be better to avoid using it.
There's not much info on CGI/SCGI in 2013 :'(
I've written a few thousand lines of PHP in the last year or so. Every time I do, I want to weep.
It might be better than Perl, but not by much.
Like Perl, PHP is a long-lived, heavily-used-in-production language, which means there is a lot of cruft that has accumulated over the years that's difficult for the platform developers to just slough off. But much like there is a Modern Perl movement that has coalesced around voluntarily cutting out cruft and using a much cleaner, nicer-to-work-width subset of Perl, there is a similar movement in PHP-land that's doing the same thing.
PHP The Right Way (http://www.phptherightway.com/) is a good place to start if you're curious what "modern PHP" looks like.
Those same arguments would apply to Python too, and it doesn't seem to have nearly as much cruft.
True. But very few languages can claim to be as elegant as Python :-D
Well, that was the parent's point:
PHP, heavily used in production, godawful language.
Perl, heavily used in production, godawful language, but at least it's not PHP.
Python, heavily used in production, pretty good language most of the time. (It's refactoring effort is Python 3, but ended up not changing very much.)
Just ask a Go dev about how "elegant" they think Python is.
I would not call Go elegant. Simple maybe, but not elegant. It's not concise and it's not very powerful (concurrency aside(pun)).
Python is elegant, and my first real commitment to a language, but imo nothing beats Haskell in elegance (though scheme has a certain beauty about it). Perhaps this is just me being temporarily enamored though, I can't help but to link to this post:
http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...
Haskell and I have been doing well so far in the "RealWorld" and I hope it keeps going that way :D If not, I'll probably put more time into python and C again.
Can't disagree there. But, Monads are a huge hurdle and memory leaks are hard to fix.
(Although I should add it's a few years since I've played with Haskell. Maybe things have moved on....)
Monads are a mostly a non-issue, once you understand them.
The accidential memory leaks still exist.
> Monads are a mostly a non-issue, once you understand them.
I prefer to emphasise the "... once you understand them" bit.
I personally don't feel that I've struggled with monads that much. Perhaps that was because I was okay with "I know how to use monads or wrestle them into getting something to work" (took 20 minutes) until I got to "I understand what monads are for, I understand how to compose them, and I can see how they aren't a hindrance and in many cases are useful." (has taken 4-5 months on/off learning).
I haven't ran into memory issues yet, but I have heard others have a very hard time reasoning about memory/space leaks. However, something I hear less often is that the memory problems people have also happen in other languages.
This. Nobody taken seriously in PHP world doesn't use modern PHP tools, Good frameworks, Composer, follow PHP-FIG standards, all that stuff... Just because you had to maintain a PHP4 app 10 years ago, doesn't mean PHP hasn't changed. And it also doesn't mean real devs don't have standards and follow up-to-date guidelines.
I'm guessing you haven't spent that much time looking at the Wordpress ecosystem...there's some truly heinous stuff in there.
For sure. WordPress has a lot of legacy backwards compatibility on its shoulders. If they could shrug it off and start again, I'm sure it would be a lot cleaner.
The project I'm working on (https://github.com/idno/idno) is PHP, but explicitly doesn't support legacy versions, in order to rule out the way of working that was finally made obsolete in v5.3. I'm very happy with the language, and I can usually express what I need simply. Reflection could use a little love, mind you.
I'm building some projects that are only targeted at 5.5 -- once you do that, and stick to all the PSR standards, then it's actually really nice, super productive, and the cruft that exists gets ignored. I like PHP still shrugs
True. But Wordpress is a blogging engine with tons of stuff bolted on to make it behave like a CMS. It appeals to the same group of people that disable error reporting to make their spaghetti code work.
I do a lot of PHP programming. Frameworks like Laravel are a godsend. Sometimes I have to work on a Wordpress project and it makes me cry.
> It might be better than Perl, but not by much.
Oh come on.
PHP is more evolutionarily fit than Perl in a handful of very important ways (I would illuminate, for example, function signatures and a pre-built object system, syntactically trivial nesting of data structures, and a newcomer-friendly out-of-the-box execution model).
That said, I wrote Perl for years as a hobbyist (still do, now and then), and have spent the last 6 or so primarily writing PHP. There is not a day that passes that I don't miss some aspect of the rich, expressive, elegant, sophisticated, and intellectually delightful environment that is Perl at its best.
It is a doomed and sinking continent, Perl, but if we let the considerable wisdom of its once-great civilization evaporate into trite dismissal, we as a culture stand to lose a great deal.
syntactically trivial nesting of data structures
I always found PHP's insistence on the array() keyword annoying, and the mixing of associative and sequential arrays ambiguous.
Perl's data structures (in their simplest form) and JSON are very similar, and I think JSON is a fine format.
You're mostly right on the other points though. Although I do love Perl's use of signatures in some cases.
PHP doesn't insist on the array() keyword, currently. The mixing of associative and sequential arrays is ambiguous, although you can think of them all as being associative; it's just, PHP will supply some keys if you don't provide any. Whether that's kludgey or acceptable is up for discussion. (I don't mind it at all.)
It's not so much that I think it's kludgy, as much as I think it may be a harmful abstraction, as faintly outlined in my sibling comment.
That was actually fixed in 5.4: http://www.php.net/manual/en/language.types.array.php
You can now write
Or even
I'd think the mixing of associative and sequential arrays are one of the key things that lowers the barrier to entry though.
I had heard they were finally fixing that, which is why I made my comment a reference to the past. I'm glad they settled on a syntax that wasn't too far out of the norm from what you would expect, given PHP's roots (i.e. Perl). I seem to recall the RFC at some point had a different syntax, but I could be remembering incorrectly.
I'd think the mixing of associative and sequential arrays are one of the key things that lowers the barrier to entry though.
For me it fails the "similar things should look similar, different things should look different" test. Then again, they aren't really all that different in PHP. I guess it comes down to me preferring my sequential and associative data structures to be separate, which is a fairly fundamental difference to how PHP thinks it should be. I have a sneaking suspicion that the complexity this data structure tries to hide leaks out through the numerous functions used to interact with it[1], which just shifts the pain slightly farther down the line, and possibly from a one-time event (when learning the fundamentals) to a regular occurrence as it causes problems continually later.
1: http://c2.com/cgi/wiki?WaterbedTheory
There's a lesson here about how sometimes it's okay to fit your data to your code. This was, afterall, in php for years without causing much, if any, problems for end users.
I guess there won't be much agreement here on HN, but this deserves to be recognized as an amusing and clever solution to a problem. Even if the problem is self created.
PHP is great for doing quick and dirty dynamic web pages. So what if it doesn't scale out to a million line program?
Except this was no acceptable solution. Instead of using a better hashing algo than strlen(!), the function names was chosen by length, leading to one of the largest and most criticised flaws of PHP: the inconsistent function naming.
> PHP is great for doing quick and dirty dynamic web pages.
And a lot more besides (subtle plug for http://www.phpbeyondtheweb.com )
> So what if it doesn't scale out to a million line program
I've seen more that one PHP codebase of that size, happily (and maintainably) plodding along.
Is the PHP source from 1994 available anywhere? That would help determine if this is Rasmus's satire or not.
It's http://museum.php.net/
EDIT: It's true, it's not satire... check out e.g. lex.c in php2/php-1.99s.tar.gz
followed by all top-level functions ordered by string length.
http://museum.php.net/php1/
from php-2.0.1/src/lex.c
void IntFunc(char *fnc_name) { int i=0; int cmdlen = strlen(fnc_name);
It's amazing that, after all these years, PHP still has the ability to horrify me.
Hello again, old friend.
While I understand why this was done (for the sake of comparability), I feel like its better to bite a bullet and slowly phase out broken functions over several versions.
Warn initially (few versions) and then raise exception/critical errors after. If developer isn't willing to update, chances are server isnt being updated either anyways.
Nothing in this discussion mentions anything broken, though.
Indeed, and the title is incorrect too. Function names were not renamed to end up different buckets; Their names were picked that way.
What about usability? "I wasn't too worried about not being able to remember the few function names." certainly indicates that usability decreased. That may have set a pattern for it getting broken, eventually.
This. I was implying that length of the string should mean length in characters, not bytes. This could lead to broken code and would require programmers to keep in mind both.
I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.
Well, not really. Consider the (very common) case of a PHP-based blog, forums or shop being hosted on shared hosting. The latter gets an upgrades, and the site explodes.
(I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)
Better idea: bite the bullet, drop PHP. Switch to a language that was designed. In the eyes of many of us, PHP is beyond redemption.
Difficult to get as sign-off on re-write of large systems when there technically nothing broken.
Better idea: Be a better programmer and don't blame a language because you suck.
No amount of "being a better programmer" can fix the fact that $x == $y && $y == $z does not guarantee that $x == $z or $a[$x] == $a[$y]. Nor that passing by value may or may not protect you from destructive updates, depending on whether your caller passed by reference. The language simply can't be trusted to behave predictably; a huge number of its features have some kind of trap built in by mistake.
Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.
So, PHP is a good tool because a 'better' programmer can make good things DESPITE using PHP?
Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism.
If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.
Builtin features you can't override have data-dependent bugs. Most values work, but some values fail (deterministically) and most users don't know that. You can't even fix the interpreter unless you're running a non-shared copy and are not running any third-party code which happens to rely on the odd misbehavior.
Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.
Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.
Well, points for honesty, I guess.
Ok i will admit it, i didn't understand a thing. Would someone care to explain it to me?
I'm not really sure if this is right, but my best guess is that script parsers use a hash table to map the name of a function to a function pointer or something. Hash tables enable fast information retrieval by some key (usually a string). By just knowing the key you immediately (or after some calculations) know in which bucket to search for the element. For details see http://en.wikipedia.org/wiki/Hash_table.
For the hash table to be efficient, an algorithm that stores the elements has to evenly distribute them across the buckets. But instead of using a "proper" algorithm, a string length was used to determine in which bucket a function name belongs. To have the names evenly distributed, the names had to be of different lengths, even if that meant abandoning some naming conventions.
Fu*k it, ship it?