The message you should get from this post is that familiarity with one's tools easily trumps any aesthetic flaws (consistency in parameter ordering, naming conventions, etc are really nothing more than aesthetic flaws and not "deep" [1] as the author suggests. After all, human language is inconsistent. After awhile you just get used to it and don't think about it anymore. Programming languages are no different.

I agree with Marco that it will take "years to master" whatever he chooses next. I always scratch my head at these "I learnt Python in a day" claims you often see around here. No, you didn't learn Python in a day. You learnt the syntax for a for loop in a day. Idiomatic Python takes much longer.

I don't agree that choice is the reason people don't use Linux on the desktop. Desktop Linux is the reason people don't use Linux on the desktop. I'm sorry but it's truly awful and probably won't ever get better. In the absence of product direction you have us geeks making everything configurable because, you never know, you may want to write your own window manager (and knowing us geeks, no two will agree on what's right) so you have no consistency, no grand UI/UX design and it's just terrible.

I use Linux/Ubuntu at work basically because I have to. There are advantages on having your dev environment mirror your production environment and Linux (over OSX) does actually have a package system (it's a messy hack on OSX) but I certainly don't like it.

The only computers I use that I truly enjoy using are my iPad and my Macbook Air.

Fear of the wrong choice isn't I believe what motivates most people. Fear of looking like an idiot? Sure. But that's different and will probably be the case with anything new.

People don't tend to weight up two or more options, decide which is best and go with it. They tend to use the first thing they come across until its flaws (perceived or actual) outweigh the "cost" of transition and appearing like an idiot for awhile.

[1]: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Linux can be really, really awesome, if you're prepared to spend time making your work environment great.

Lastly, all this time is not wasted, you end up learning so much stuff that you can apply to every where else - because of my linux knowledge I often find myself helping out my friends who use OSX but don't understand things like headers and libraries.

Granted, I use Gnome Shell for my desktop of choice, and find that much closer to my definition of "beauty", while KDE4 is busy chasing some idea of beauty that more resembles a mish-mash of Win7 style glass that spends more time distracting my eyes than allowing me to work, so take my opinion with a grain of salt.

I think OSX has come closest to the mark of "beauty" from a desktop environment, but it's such a terrible window manager compared to X11 that I can't stand using it except when I have no other good choice. Even then the only thing keeping me from insanity is a set of third party window managing tools that still only get me about 50% of the way to where I want to be.

I'm sure we do, I'll justify what I claimed, though - the colour scheme is unified across the entire system, fonts are readable, the borders are thin and the windows have a little spacing so it isn't too crowded. I've toyed with a lot of aesthetics, and I'm quite happy with this one at the moment.

Yes, it's very information heavy, but it suits the way I work, I find it visually appealing (though I can understand why people who like OSX's aesthetics would dislike it), but quite a lot of thought has gone into how it looks :)

That's my definition of beauty. I can go days without noticing it and if I take a step back and take in the whole experience, I find the beauty.

Ubuntu does it for me. Especially because I can take time to make it beautiful for me and I can have a free hand while doing it.

This is why I dropped Linux/BSD on the desktop over a decade ago, and switched to something I don't have to think about, and instead I can simply use to get my actual job done.

The reason I don't use Windows or OS X any more (and I've used both extensively in the past) is simple: sure, both are easier to set up (with a new computer, there is no set up). But both are strictly less productive than a good Linux setup is.

The reasoning is simple: setting up a computer is a basically an O(1) operation. Sure the constant may be high, but it's just that: a constant. On the other hand, the drain on productivity of using OS X or Windows is in O(n) where n is how much programming I do. And, happily, I do a lot of programming.

So I've never understood the rather condescending argument of simply getting your actual job done. People using Linux aren't all shortsighted or masochists! We use it because we want to get real work done faster.

I'd also disagree that Linux is objectively faster for getting "real" work done. An example to illustrate the point: I've been using Ubuntu on and off, and tried to set up IntelliJ to match my Android development environment on Mac OS X.

First of all, the installation process sucked compared to drag-installing on Mac OS X. I had to download a .tar.gz, open up the terminal, run an installation shell script to create the requisite desktop files to make the app visible in the GUI.

Then, once I had it installed, the fonts all looked like crap. I spent about half an hour trying to track down how to make OpenJDK fonts on Ubuntu not look like crap, before finally giving up and resigning myself to the ugly UI. I found lots of people with the problem, but not many solutions.

Stuff like this happens all the time. Before Mac OS X, I resigned myself to dealing with this kind of regular crap. Now, I expect an application to drag-install and just work correctly.

I'll try to get ahead of some common arguments I've heard regarding app installation:

At this point you might start arguing that I should be using software from the official APT repositories, or something. That's a broken model. It's ridiculous to require the OS vendor to maintain an integrated repository of every piece of software available for the platform. It's not sustainable, and it means stale software and extra trouble if the software that would make my job easier (programming, right?) is not open-source and doesn't fit the OS vendor's software licensing ethics.

Then you might argue that I should use a third-party APT repository to fetch dependencies, which means that first I have to find such a repository, then I have to update a bunch of annoying configuration, and lastly I have to trust that their apt repository won't steal precedence on a system package. You can prevent that precedence problem with more configuration, but that's even more complicated.

No thanks. I'll take drag-installs, or better yet, the app store. I realize that Ubuntu is trying to go in this direction themselves, but it's not there yet. I'll reconsider when and if it they ever reach a level of working integration on par with Apple's.

Until then, I'm going to use IntelliJ under Mac OS X with nice looking fonts.

It sounds like IntelliJ has garbage Linux support and you're blaming the OS for it.

For example, when I was using OS X (several years ago, now), I could not figure out how to update Java. Apparently it involved using the "Software Center", but it didn't actually work, so I was stuck with the old version. So the project I was working on in Windows at the time just didn't work on OS X because it was using new APIs. Absurd! I've never had a problem like that on Linux.

More recently, I tried to install Git on OS X (without administrator access). It was a horrible pain, so now I only ever log on to the Linux servers at school.

Also, there is no way "drag install" is easier (after learning about it) than "yum install", or whatever your distro provides. I don't have to find anything to drag; if I want to install something, I can just type its name in an voila, I have it. What about programs not in the repository? Well, they're easy too, assuming the vendor packaged it up for you (but you have to assume the same on OS X). I needed to install a beta version of MongoDB recently; all I had to do was download the RPM, click on it and enter my password.

Now, I agree that Linux alone does not make you more productive. But a Linux configured to do exactly what you want? Now that's productive! On OS X, I can't have a full-screen program on one screen and a couple of programs on the other. On Linux (at least with KDE), that is just a couple of settings away. And, to me, that's extremely important: I want to maximize my Emacs space as much as possible on one monitor while having a browser and some other stuff open on my other screen. I've already gotten rid of the flanges, the tool bar and the menu bar of Emacs; it seems silly to have window borders and the annoying OS X top bar still there!

However, the point isn't that any one feature (like the full-screen windows) is important to everybody. Rather, the point is that you can set pretty much any feature that is important up. Sure it's more difficult to configure than OS X--but you can actually configure it! That is exactly what I was talking about when I said O(1): to get a computer that behaves exactly how I want it to behave is only possible on Linux and takes a constant amount of time.

Coincidentally, it isn't even strictly easier to set OS X up for some really basic things. For example, a bunch of people I know use Emacs and LaTeX for a bunch of different things. On Linux, I just type sudo yum install auctex and it gets everything for me. My friend on OS X? He spent hours trying to set everything up correctly, and I'm not sure it all worked in the end.

Also, for what it's worth, I've had the best luck with fonts on Linux. Not only do they look great, but the one I use for programming actually supports all the symbols I need. I want to be able to read and use Greek letters and all sorts of math symbols without worrying, and Deja Vu is the only set of typefaces I've found that let me do that. Deja Vu Sans Mono is also a great looking typeface for code--certainly my favorite of all the different ones I've tried on all of the platforms.

I remember everything you're describing from 10 years ago, and if things are still operating that way, then I'm glad I'm not using Linux.

It's clear from your comment that you don't understand how to use OS X as a developer. I used the BSDs and Linux on the desktop for most of the 90s, and have stayed current with Linux on both servers and desktops (though I don't ever use it by choice on my own). I don't think you're equipped to make a fair comparison.

I did use OS X for Java development for a whole year. Moreover, I've had to use it a little bit recently at school and work, so I've played around with the newest versions. If that isn't enough experience to "understand" OS X, I'm not sure what is.

Not much else to say here, because all you've done is act condescending and solely attack my perceived credibility. Because, obviously, if I didn't like OS X, I just didn't understand it!

No, you just plain don't understand how to use it, so there wasn't really any room left to discuss its relative merits. Whether or not you liked it is irrelevant given that your judgements were based on an acquired understanding of Linux, and a terse at best understanding of Mac OS X.

Let's just take your git example:

> More recently, I tried to install Git on OS X (without administrator access). It was a horrible pain, so now I only ever log on to the Linux servers at school

How exactly was it more difficult on Mac OS X? Did you try to ./configure && make && make install by hand, just like on Linux-sans-admin-access? Or did you try to use MacPorts' or homebrew's support for running without admin access, and simply tried '(port|brew) install git'?

Or, let's talk about Java:

> I did use OS X for Java development for a whole year.

During that whole year, you never stumbled onto Apple Menu -> Software Update? It runs automatically, you don't even have to invoke it manually.

You never googled "Mac" and "Java" and determined that Apple provided the Mac port of Java? Assuming this was in the time period of the 1.5 release, you never found Soylatte using Google, and used that?

Or, your friend with the LaTeX problem:

  port install texlive

As for Java, I couldn't update despite using the Software Update menu. It worked on Windows, but OS X just hadn't gotten around to adding it. And, as is usually the case with Apple, there was no good way around it: since Apple hadn't update Java, I couldn't just install it myself. (Or, at least, there was no obvious way of doing this.)

I don't know exactly what my friend tried to install AucTeX and the rest of the LaTeX ecosystem, but he certainly did not find it easy. And this is somebody studying CS at a fairly good university: certainly not unintelligent or unfamiliar with tech.

Over all, your descriptions make OS X seem worse than Linux in the very areas it supposedly excels in!

I installed git on a coworker's computer in a couple minutes today, so I don't know what to say.

> As for Java, I couldn't update despite using the Software Update menu. It worked on Windows, but OS X just hadn't gotten around to adding it. And, as is usually the case with Apple, there was no good way around it: since Apple hadn't update Java, I couldn't just install it myself. (Or, at least, there was no obvious way of doing this.)

It wasn't that Apple hadn't "added" it, there simply wasn't a port of that version of Java to Mac OS X, because they needed to port it. If someone external to Apple had produced a port (like, say, Sun), you could have installed it, exactly in the same way that we install Oracle Java today.

Someone did eventually produce a partial non-GUI port, and it later became the base of Oracle's officially supported Mac OS X Java: http://landonf.bikemonkey.org/static/soylatte/

This has little to do with Mac OS X being somehow broken, and a lot to do with the fact that Sun only provided Java binaries for Solaris, Linux and Windows.

For Java 7 on, Oracle will be supporting Java for Mac OS X directly.

> I don't know exactly what my friend tried to install AucTeX and the rest of the LaTeX ecosystem, but he certainly did not find it easy. And this is somebody studying CS at a fairly good university: certainly not unintelligent or unfamiliar with tech.

I'm not sure what intelligence has to do with it. It sounds like he just didn't know what he was doing, and ignorance has little to do with intelligence.

If he'd approached Linux and had never read up on "yum" or "apt", I imagine he'd be equally stymied.

> Over all, your descriptions make OS X seem worse than Linux in the very areas it supposedly excels in!

I don't see how, but I imagine we're talking at cross-purposes at this point.

Updating Java on OSX is trivial (download & run), no idea what problem you ran into with git, OSX has full-screen apps and multiple desktops, and OSX has always had the nicest font support and type rendering of any OS -- Apple has always been at the forefront of that.

The problem I ran into with Git was simple: I could not figure out how to build it from source or install it without administrator privileges. After about an hour of screwing around, I just gave up and sshed into a Linux box instead (both were for school).

Updating Java was an issue back when I was doing Java development. I simply couldn't get the version of Java I needed, period. I don't see how it can be a bad example when that's exactly what happened. I think Apple has since given up on packaging Java themselves, which probably ameliorated the issue.

As far as fonts go, I have no doubt OS X has decent font support. My point was that Linux also has great font support these days.

These aren't random problems I heard about: these are actual problems I've personally experienced. I definitely had a higher density of problems per unit time spent on OS X than on Linux or Windows, which says quite a bit.

Had to do it. I like linux a lot, but It doesn't make the quote false.

(See what I did there? Linux, OS X, and Windows all enable infinite tweaking. No setup will ever be perfect, and making it closer to perfect takes time. If all you want is a web browser, that's a click away in every major OS.)

  > See what I did there

OSX is beautiful, it's smooth, and it can run a lot of my games too. But, just like Windows, it lacks functionality. Setting up a MAMP server with my required PHP extensions for work was an absolute nightmare even with Homebrew. Even when working with my Ruby projects I was struggling, when some gems required certain libraries to be installed, it was a nightmare to install them too.

Not to mention installing software and keeping it up to date was a pain too. Once you become used to relying on robust package managers it's very difficult to turn back.

Linux is designed to be powerful and functional foremost, and that's what makes it fantastic.

Same on any nix system I use : sandboxing is the way.

- Want to use hg-git for mercurial, dont, homebrew that !! Build it in your ~/bin/ or in your $HOME sandbox, give all PATHS in your $HOME precedence, and rejoice.

- need mysql, postgre,... Don't homebrew that !! Either build it, or use the Macos dedicated installer with propper service installation, on dedicated port.

- etc,...

All in all, Homebrew, Fink and Macports are great for one thing : showing you how to patch the default tgz, saving the user hours of work for his custom, sandboxed install of any software (which as itself has been a life saver, for myself, on many an occasion).

Macos still is, as far as i'm concerned the best laptop platform for someone who has to use licenced software (external job/office constraint) but also needs a nix (bsd) environment. Otherwise, what can't you do with the default Ubuntu 12 LTS (i guess you agree) ? Macos, sure, is's on its way to become worthless as The Lion slowly sandboxes the user out of the OS, but tat's another story.

EDIT : and let it be said that OF COURSE, I agree with you that aptitude, yum and the like have no decent equivalent on the Apple/Microsoft closed platforms.

I found running a VM on my mac to be the best of both worlds. Plus you can backup and distribute your VM so the entire team develops on the same setup.

From the impression I get of Marco whilst listening to his Build and Analyze podcast, is that he does have a lot to say about the technical aspects of his work. However when he does, it is often written/spoken out as a response to a question. The constant talk about PHP in recent weeks has probably triggered something he's been thinking about for years.

I wonder if you've tried homebrew? It's really really good, esp compared to the horrors of MacPorts.

someone who has mastered in PHP will no doubt be a lot more proficient in developing apps than a junior/intermediate python or ruby developer. same can be said for reverse.

it really all comes down to knowledge and experience.

Have you tried Unity or G-S lately? I'm not as willing to argue G-S has as clear a direction as Unity, but they both ship with a very limited amount of configurability and they're both insanely easy to start using even without background knowledge.

Anecdote: I've used Ubuntu for a long time, but due to some nonfree applications dependence on mac/win I've gotten myself a apple laptop. It's mostly the same, I use a browser, terminal, vim and a thousand silly apps but they are about the same amount of config-time.

The biggest difference is that Ubuntu ships with APT and a lot of tools that are good for a hacker, but it's not to hard to get equivalents on osx.

Summary: Mac OS and Ubuntu are more on par in ease to use than I could have believed before I tried.

I'm very surprised that Google doesn't provide some kind of consistent dev VM environment that is similar to prod that developers can SSH into.

If I want to write a hello world application in PHP, it's neither as long as <?php print("hello world");?> nor as short as <?="hello world"?>

Rather it's simply: hello world. Just type in those 11 characters in a text file and save it as hello.php. Now load it on your browser [or run it from command line] and it will print hello world. I don't think it can get any more simpler than that in other languages. PHP was developed from the ground up as a templateting language for serving HTML pages. These other languages are more of a general type.

Therefore the replacement for PHP should come through a new language targeted as a replacement for PHP as Jeff said. Otherwise there always be extra web/template stacks for the developers to take care of. And that will be the first hurdle to learn and overcome for novice developers looking for switching to something easier.

After 15 years of one of the biggest bursts of innovation the open source world has ever seen, and with such diversity in frameworks that the mind boggles, nobody has returned to this model successfully. I've got MVC-inspired designs coming out my ears, continuation-based designs, frameworks just beginning to incorporate web sockets deeply (instead of as an afterthought), GWT, ASP.net, and other attempts at building a fundamentally different model and compiling it into another, and everything under the sun... but no return to the page-is-program model.

I don't think it's the key to PHP's success, because even in the competitive-yet-very-fertile soil of the web framework world, nobody else can make it work anymore. I think it's vestigial, and nothing else.

(Personally I think the key is simply that everybody has deployed it, and since there's basically no way to force every web hosting company to support Language X simultaneously, PHP isn't going away until the entire concept of web hosting goes away. Which isn't anytime soon.)

It's true that other languages have not wasted a lot of time trying to displace PHP as the language of choice for anonymous random dinosaur servers. That's because there's no money in fighting PHP on its home turf. The turf just isn't worth enough.

"Vestigial" is the wrong word. That's like describing a screwdriver as "vestigial" because the impact driver has been invented. Sure, impact drivers can accomplish many things that mere screwdrivers cannot, but that doesn't mean that screwdrivers aren't still useful, and numerous, and popular.

You may disagree that my characterization is correct, but it is certainly the characterization I intended to convey. That's why I parenthetically commented that I think the real reason it has carried on is another one, to contrast the relevant characteristics to the irrelevant ones. Creating a new "PHP-killer" and focusing too much on the vestigial features of PHP is a recipe for failure.

Ease of install is part of the same pattern. PHP has always been easy (with connections to a free database), and got easier with good package management systems. What's coldfusion like for ease of install, ease of install with database access?

ASP for Windows was huge. It was even easier to get started on than PHP because you just needed to install IIS from a EXE and you could reference access files. The only reason it's not still massive is that MS moved on.

There are alternatives, but nothing that simply 'just works' like PHP seems to.

This is solid advice for an engineer. And absolutely moronic for a businessman.

Choosing what platform to use is a business decision.

If you take too long to get it right, you will never get the chance to make a dime off of your work.

We are all working on limited time frames. It is far better to throw something together that works and rewrite later, when you're actually making money.

PHP is amazing at letting you write something fast and rewrite it into something more manageable later.

From experience, the mountain of technical debt organizations acquire when starting with PHP can make it near impossible to rewrite it into something more manageable later, and it's a false dichotomy to claim PHP lets you write something fast while the alternatives do not.

"Hey kid, first one's free"

Unfortunately, nobody starts out well-educated and experienced. And many projects start out small and grow. If you want to make your platform a broad success, you need to have a good experience for noobs and quickies. PHP is an abomination as languages go, but it's massively successful because any idiot can quickly get something basic up.

    $ echo 'hello world' | erb
    hello world
    $ echo 'hello world' | php
    hello world

If you truly only need a single page template without any further abstraction, then why not use PHP? It seems all of the complaints about PHP stem from using it in big projects. It is hard to argue that it does a single page template very well for when that is all you need. Right tool for the job and all that.

Why not improve it? After the millions of man hours that have gone into the plethora of open source PHP based frameworks and tools (aka, what powers the internet) - wouldn't we as a community want to improve the foundations rather then scrap them entirely?

You know, like what happened with Javascript...

PHP has a lot of them. And they interact badly.

All languages (like any system) will have cruft, after a while. Is the solution really to do a periodic break with backwards compatibility for purity reasons, Python 3 style?

There should be a better way?!

What about a low level machine like Java/.Net and just let the next language evolve on top of that -- so old libraries could run? (Maybe there could be Xcompilers for Ruby/Perl 6/xxx to the Perl "bytecode", to take advantage of CPAN?)

Figuring out when that happened to you is a judgement call.

If us PHP developers have such bad judgement, show us the error of our ways.

And do not link to some other persons blog post - explain it yourself.

Wouldn't that also apply to jsp, cfm, gsp, jsf and asp?

But it's preaching to the choir. If you've never seen anything other than PHP, you won't understand two thirds of the list or why they're problems. (<- Not looking down on PHP coders there, rather I'm thinking back to when I started out on PHP and am speculating on how I would have received the document.)

How do we communicate effectively what makes other languages better to someone with no reference frame other than PHP itself?

So to encourage developers to start with something other than PHP you'll need to lower the barrier to entry to modifying existing software, and also make something as popular and widely useful as WordPress and MediaWiki.

This is going to take a while.

A big hurdle is ops dev. All hosting services support PHP out of the box.

Now I'm faced with the "distro choice". Which server do I use (lighthttpd / nginx / tornado)? Which framework (django / flask / web2py / cherrypy / pylons / pyramid)?

Like the original author, I've had a VPS sitting unused for 2 months paralyzed by choices. I eventually decided on nginx / flask, but haven't had the time to set it up. Maybe I should have just used Heroku. shrugs

Just choose one and learn it. They're all excellent web servers. I'd recommend going with Flask or Django in the beginning, simply because they have the best documentation. web2py also has pretty good documentation. The only problem with Django and web2py is that they are monolithic. If you don't like their ORM, or templating engine, or authentication/authorization, it's generally hard or impossible to switch, and if you do switch you lose all the benefits of the integrated system. With Flask and Bottle, on the other hand, you are free to pick and choose components. I think the same modular design approach is used by Pylons and Pyramid, but I'm not sure since I've never used them. But as you learn more, there's a lot to be said for being able to switch out components of your framework, or even writing your own in a pinch.

Two thirds of that list are actually incorrect.

But I programmed in Java, C++, C, VB, and so on before I started coding in PHP many years ago. So many years ago, in fact, that PHP was easily the best choice.

The problem with lists like that is they obscure the truth -- and that is -- that solving a programming problem in modern PHP isn't really that different from solving it in Python and Ruby. It's just not that much of a leap.

Got a link to a good rebuttal?

http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.ht...

Not a good rebuttal but I've done my own here:

http://news.ycombinator.com/item?id=4177516

> That's sad.

Err, huh? What's with the preachy tone and the presumptuos attitude there? No, I don't need to convince myself, nor am I looking for confirmation - I know that I'm happier coding in Python than I was coding in PHP, that I get more done in less time, that I've vastly increased the average reusability of code that I write, and that it blows up less in production.

> Have confidence in yourself. You made the right choice for yourself and let others choose for themselves.

That's not what this is about. It's about how I didn't make a conscious choice to use PHP back then - nor would I have if I had been in a position to make a choice. I believe the same is true for many others, so how do we get to a point where they have the facts to make a choice?

> Python on the other hand ... aside from Google, who's using it at a massive scale? Even Google has been shifting to Java for a long time.

Shrug. It's you who's playing up the PHP vs. Python angle here, really -- for me there's plenty of stuff out there that's better than PHP, not just Python.

> If you're convinced that there is no proper application for PHP, then you're not even trying to be objective ... you're just trying to make yourself feel better about the choices you made.

Actually I think there are circumstances where PHP is the right choice, though it's mostly a matter of market considerations, certainly not technical strength.

I think technical strength is valued differently in this community than in the web development community at large. I've had a lot of commercial success with PHP and never found a serious problem caused by "a lack of technical strength".

Surely certain languages have created a vision of technical strength that is appealing to programmers who think mostly about programming as the challenge in itself, rather than a tool for the market challenge.

However to people that think mostly about solving market problems, such as entrepreneurs, PHP is known for many attributes that are high value and perhaps have little to do with what you might consider technical strength.

The multi-core reality means that the long-term languages will have a strong concurrency model. Clojure and Go are two languages with strong concurrency models that are building momentum and have potential to go mainstream.

But for your first foray out of PHP, I would pick a language that has a large, well-established community with mounds of documentation, books, and resources.

My path out of PHP would be:

  1. Python
  2. Clojure
  3. Go

Then once you're comfortable with Python, I would venture into Clojure. It's different, but in a good way. And you get access to all of Java's libraries so it's practical now, even though it's relatively new.

And then look at Go. Go is building momentum fast, but right now it doesn't have the massive libraries that Python and Clojure have. However, in a few years, this will change.

It would be nice to have a language that lets you prototype quickly but also build the real deal efficiently. Actually, not having such a language should be embarrassing for the software industry.

Maybe Clojure fits the bill, difficult to say.

So if you're stuck in limbo trying to "make the right choice," concurrency is the feature that you should pay attention to because it will bring the dominant language in years to come, even if the CRUD devs don't use it directly.

And who knows what the basic Web app of the future will be, it may not be CRUD forever.

If your goal is to become independent and wealthy, perhaps not.

PHP is good. I'm living proof of that. I'm a very successful developer and PHP does just about everything I ask of it. I also find it enjoyable (when you don't use crap frameworks or CMS' like Drupal). For those of you that do struggle with PHP, then what on God's green Earth makes you think you'll do any better with the next language? There comes a point when you've rifled through everything saying they are all junk that you gotta look in the mirror and ask yourself what's really the problem?

Interested in learning something that isn't PHP to code your web applications in? Ok. You have a ton of options and this is a very exciting time to be a web developer.

Do you want to lean towards stability and proven concepts and work within a full application structure? Look at Django and Rails.

Do you want to serve up responses from a simple script without a lot of extra pieces? Look at Sinatra and Flask.

Do you want to get in on the cutting edge and don't mind forging some of the path yourself? Look at Node.js and Meteor.

Got a high level decision made? Sweet. Now compare the primary languages between your choices (forget the framework for now). After a few minutes looking at each, which reads better to you? Feel free to go on gut instinct here: there are no wrong choices.

You've now made a choice for your next learning target. Now: don't spend years. Don't worry about knowing everything about the framework and the language. Google for "X tutorial" and follow the first link that looks reasonable and current. Do that tutorial. Now you have some bearings within the framework and have some idea of how it thinks.

Now. Pick something you want to build (a todo list is popular now, it used to be a blog or a wiki). Build it. You will make mistakes. You will be confused. Google for answers (if you're in Node.js or Meteor you will have trouble here) or hack until you get something working.

Throw what you built up on github and ask others to check it out. Build something else. Repeat.

If you are already a decent programmer with a good grasp of the web and how HTTP works: you will pick up any of these frameworks well enough to work in it in a month or so. In six months you'll be well advanced: especially if there are good books available for the framework/language you are working in.

Have fun!

Oh.

I hate PHP as much as anyone (of course), but that's what it does.

To deploy you just push to a free heroku instance and you are fine until you get big. Much, much easier than setting up your own Apache+PHP. And much, much cheaper than buying hosting.

Unfortunately Heroku is down right now. The wide-availability of choice, it's ubiquity, is why many PHP sites are still running right now - they are not reliant on a single point of failure.

There are many thousands of hosts, spread across the world, offering Cpanel accounts so I'm not tied down to the meteorological events in North Virginia.

If an act of God happens in Michigan right now, I can switch my site very quickly from there to a freshly minted Cpanel accout in California (thanks regular Cpanel backups!), or London or Manchester (Possibly not Newcastle right now, though). I'm really spoilt for choice here.

What are the alternatives to Heroku that don't have the same failing that are running right now that are comparable in getting an app up and running equivalent to PHP time?

It costs 3 bucks for host gator, hmm maybe 4, but heroku is very opinionated on how you should structure your project.

The only advantage PHP has in terms of deployment is that there are more cheap, crappy shared hosts that support it.

It's a similar problem as Ruby and Python, believe it or not.

The advantage it has is that you can run a ton of hosted sites on one mod_php apache server. With Rails, for example, you have to run an environment. Same with many Python apps, or Java, etc.

So it has the memory advantage of being able to run multiple sites on one environment.

Not that big a deal if you're doing any serious deployment, but a big deal for its ubiquitous nature.

90% of people just run a web site on a hosting server. Granted it's getting less and less common with the advent of the centralized service-based web, but still, that's the source of success.

That's the problem. I'm in the same boat as Marco with pretty much the same reasoning. I'm not interesting in learning something -- I'm interesting in starting and completing my next project as quickly, cheaply, and well designed as possible. I'm willing to accept that, all things being equal, a better design is possible in Python or Ruby. But for that to be true, I need to know Python or Ruby. I need to know the framework I'm working on.

I can certainly put the time into learning, the time into heading down the wrong path in both design and technology for a project (and that will happen), perhaps rewrite a few times. But with only so many hours in the day (less than I really need), it's not much of an option.

Software development is a Red Queen field [1]. If you don't take the time to keep up, you will eventually get left behind.

[1] http://en.wikipedia.org/wiki/Red_Queen%27s_Hypothesis

It's built for smaller web apps, and rapid prototyping. The system of mapping endpoints to functions is incredibly intuitive -- if you've used Python before, learning Flask is incredibly easy.

The idea of Flask is to build a good foundation for all applications. Everything else is up to you or extensions.

http://flask.pocoo.org/docs/design/#what-flask-is-what-flask...

There's even an entire section in the docs about scaling your application up: http://flask.pocoo.org/docs/becomingbig/#becomingbig

What I meant was that it lends itself well to small apps because the lack of code/architectural overhead, as opposed to Django, where coding small apps often feels like only furnishing one room in a five-bedroom house.

Django is good for getting small, simple apps up and running quickly. It all gets overly complex very quickly when you need anything more than that. For a big app, it's better to start with something small that can grow to meet your needs rather than starting with something big that you'll have to fight to do what you need to do.

With Flask, you just have to learn Python, as Flask is so mindfuckingly simple.

That being said, for a 'big' project I'd recommend Django over Flask, if for no other reason than googleability -- if you run into a particular error or question, Django's community (due to size) is probably going to be more helpful than Flask's.

I believe that Flask will move to Python 3 eventually, but at the moment I agree with the decision of Flask's creator (Armin Ronacher) to stick with Python 2.7. In the end, Python 2.7 is probably better for someone new to the language. There's more documentation, and it's still the default Python on most systems(although a few are starting to pre-bundle Python 3).

As far as python 3 support is concerned: this is a minor annoyance, but it will probably be rectified by the time python 3 is relevant in production environments.

I know it's difficult to compare or find an observer who could adequately judge between the two, but I wonder if Ruby made Jekyll easier to write and maintain? Of course, there's not any easy way to make that judgment without knowing how much effort Marco put into Second Crack versus what was put into Jekyll.

So when I start something that has a deadline in 24 hours or just a few days, I can either fall back to PHP to get something going fast or spend most of my time just learning a new language. So, I have been typically going with PHP…

I've found that the important thing is to take the time to set yourself up with the minimum environment that can get something, anything going in a different language: that means whatever is needed to print something on a page and get some logic working with GET and POST parameters. Because the nice thing with PHP is that it's so easy to write a single file that displays text on a page, or that responds to POST and GET parameters with some logic behind it. If I started with Ruby for example, I wouldn't know how to do this basic thing. (granted, with Rails and Heroku, this is easy)

My plan is to make Python my generalist programming language and I started to look at Flask (http://flask.pocoo.org/) for that reason: it's a mini-framework that doesn't take long to learn how to do these simple things. I can then play with it for simple things.

*though it can make things easier since I can just work on whatever I want in whatever language I want :)

Sure, there's a learning curve to any new language, and I would love to learn a "better" language, but, if you can't explain to a novice why a certain language is better, the novice is going to go for the smallest learning curve and the language with the best/most ubiquitous documentation.

What do Python or Ruby do that PHP can't? Are they "faster?" I've heard that they are more secure, but does that mean that PHP can't be as secure if a skilled developer is coding for security? People say things like "rapid development," but I've been using CodeIgniter and it seems pretty rapid to me. What it all comes down to is this: are Ruby and Python "practical" for novice programmers like me? Truly? If not, then doesn't it make sense to start with a language like PHP and then, when you have figured shit out, make the jump to Python or Ruby? I wish this was more clear.

Something that I'm not seeing people take into account generally when they decide to develop in a "new" language or complain about any established language additionally is how far along that new language is and how many people know it well. Choosing the best thing also involves how easy it is to get the help of others. An analogy might be an automobile purchase. If you are located in the middle of nowhere it might be a better idea to buy the Honda where there are multiple local dealers rather than the NewGreatAuto (pick any car with less market share that is better price and feature wise) where you have to travel 50 miles each way for warranty service.

I went through this with hardware back in the 90's choosing SGI servers that were better price and performance wise than Sun, only to find that many open source software ready to run was not available for SGI. And that there were less people that knew IRIX than Solaris.

Why do I need to switch?

You've already gone through the pain of learning how to work around all of its warts, and you will lose a ton of productivity immediately after switching to a new language. This may seem trivial if you are just programming as a hobby (and fun, even, to learn something new) but if you are a professional programmer, the productivity loss can be a problem. If you are a freelancer billing at a good rate, can you charge the same thing to your new client knowing things will take you twice as long and be less optimal, with bugs happening in new surprising places?

Taking on a new language needs to happen for a better reason than "the language I'm an expert in is kind of ugly." Are there libraries that are only available in the new language? Is there a different server architecture that lets you write applications with several times the performance in certain important use cases? These are valid reasons. "Too many functions in the global namespace" is not, especially if you already have them all memorized.

I severely doubt it's as easy as the latter. I'd like to see an article that explains in less than 140 chars how to deploy a simple app as Hello World to the web in Python without the use of a framework like Django or Flask.

Edit: In the amount of chars Twitter accepts, here's how to get Hello World going in PHP.

sudo apt-get install php5 && echo '<?php echo "hello world"; ?>' > /var/www/index.php

85 characters. I'm done. Now let's see this done in Python... Ruby... Any other popular language this quickly.

  echo "hello world" > index.html && python -m SimpleHTTPServer

echo 'hello world' > /var/www/index.html

Set up something a little more useful albeit trite such as a blog and you wouldn't be able to do that in 10 minutes with PHP without using a framework either. PHP is great for "unit testing" of ideas but once it grows out of that it's debateable

I do concur that deploying a Python or Ruby web app is a pain in the ass. Installing git and installing Heroku, you're only 2 lines of code away though.

Which requires you to learn git.

You're saying that learning Git is going to be the barrier to someone switching to Ruby? Naw, don't think so.

   gem install sinatra && echo "require 'sinatra';get '/' do 'Hello, world!';end" > hi.rb && ruby hi.rb

Wait, that didn't work. I got all kinds of errors and warnings. I must have the wrong version of something. You win, point taken.

There should be an easier way. I should be able to just run "apt-get install rails-easy" and have a system that is completely configured for development.

I haven't touched python in too many months to write it here, but it's not much harder than importing an http package, creating a two line handler and listening for connections. Now you have a much more realistic and robust system and your potential for applications is already hugely increased. (Write a websocket server in php, go on).

Here, I can write "Hello World" in an even easier language!

`cat "Hello World" > index.html`

Exactly, who cares?

That's simply not true. I love Python (I'm using Flask for projects at this moment), but saying that setting up a python web service is as easy as php is disingenuous.

Like PHP, .PYP files would be templates with no limits on mixing presentation and logic. The filesystem hierarchy provides the default URL-routing.

But, you get the regularity/power/compactness of Python wherever you want it. (Perhaps, every line in a .PYP file beginning with '\' is meaningfully-indented Python.) If you ever want to hijack a part of the URL-space from the filesystem, there are routing utilities to do that.

Would such a glide-path from PHP to Python be a good thing? Or bad? ("The barbarians are at the gates!")

I don't think it's widely used, though, probably because the possibility of using PHP in this template-like way isn't actually a big advantage (serious PHP devs almost certainly don't use PHP that way); PHP's big advantage is that it's installed everywhere.

Go with Python if you already find it appealing.

a) You need to know it anyway.

b) Node.js is awesome and works the way web servers ought to work.

c) JavaScript, if you avoid the obvious warts, is a really nice language. Every other language I've learned either has as many warts as JavaScript or isn't practical.

Having picked JavaScript, it turns out to be amazingly powerful. Need to automate content production? Adobe's stuff is all scriptable via JavaScript. Want to write a 3d game? Unity uses a dialect of JavaScript.

Time to learn some more languages.

I stopped myself from, unfortunately, not building things. I've spent the last year learning Ruby, Python, Rails, Django, and a half dozen javascript frameworks to get myself acquainted with it all. Only recently I took a position where I'll be working with Rails full-time. It's a tough addiction to break, but it's so liberating once you learn what else is out there and what you can do with it!

So if I was operating in the capacity of a recruiter for a project/company/startup, I'd definitely pick a skilled RoR dev over a skilled PHP dev, because the frameworks and the language themselves are handicaps for the PHP dev. Even if PHP is faster for a very small project, as soon as you move into a decent sized project, the frameworks start paying handsome returns for using them.

Note: I don't particularly love RoR/Django. Substitute with your favorite framework. It's just to illustrate a point.

I mean, I install node, I install the node package, I start the server...

And then it just looks for an "index.node" file or something in a directory? URL's would map to node files? It would use some kind of templating syntax like <? ?> or whatever, but the point is, it would be as easy to use as PHP. (Each template could get the URL parameters, and read session variables, just like PHP.)

I've used Express, of course, but that's overkill for throwing together a little website. People love the PHP model of files. It's clearly not theoretically ideal, or particularly scalable, but it works and is easy.

Anything out there? Maybe I should throw it together myself...

But even if you do decide to use the synchronous functions everywhere, having all your function names end in Sync would just add unnecessary confusion.

So, while you idea certainly doesn't lack merit, it would make more sense for something other than node.

I guess that's why nobody's done it yet. :) Thanks!

The fact is that my comfort with PHP stems from knowing what I know, knowing there are things I don't know, knowing there are unknowns I don't know, and knowing there are unknowns that are unknown. (Thanks, Rumsfeld)

Its this grasp on the language that gives me comfort. Mix that in with the universality of PHP and I'm more than willing to take my lumps for being told I solve problems using a shitty language.

There are shitty guns and shitty marksman. A good marksman can kill you with a shitty gun, but a shitty marksman will always be a shitty marksman.

Same with my distro - I am currently using Mint, but that may change, when my next boot hard drive fails.

Even with VBA, where I had done much of the work using DAO (started in 2005 with what I already knew) I am now trying to make the next changes using ADODB. The benefit being it will be easier to shift the back end to MySQL (or any other ODBC-compliant flavor) and have more then one language used in different front ends.

Ah, the learning! My joy in life.... And these days, thankfully little tuition required.

Between these two extremes run all others with their fair share of incongruencies and imperfections. They are just not popular and probably never will be. So I don't care. Let me know when there is a language that slaps me on the wrist for bad design and coding!

I imagine authors do have very strong opinions on whether it is better to write a poem or a short story or a novel.

A huge part of node's appeal to me (and many others, I'm sure) was the fact that I already knew javascript. Making the switch couldn't have been easier.

I used to defend PHP; but now when I look at PHP code, even well-written code, it just makes me go "ugh".

It's not exactly mind-shattering stuff, but it's nice to have some common terms to describe the properties programming languages have that make them the kinds of products they are.

This discussion seems to be missing a key factor: context.

I seriously dislike PHP and its inconsistent, unpredictable features and libraries. I avoid PHP whenever reasonable/possible. I also avoid talking to mean, verbose or dumb people whenever reasonable/possible. But sometimes I just gotta do it...

So I use PHP, Python, [Java|Coffee]script, Ruby, Django, Pyramid, Express, Wordpress, Joomla, or whatever else is the right tool for the context/job.

In the context of building a 100M request/month API server, I used Python + Django. I would never have used PHP and I consider it a serious mistake to build large scale systems in PHP. Of course, others would choose Ruby, Clojure, Java, Scala, etc and those are all reasonable answers. I happened to be able to get the thing up and running fastest and most effectively in Python + Django.

In the context of currently re-building a client site that needs social features, a small CMS, etc, we're using PHP and Wordpress. I would never have used Python + Django because the client would not know how to host it and whomever is called on to fix a template is going to have to set up a Python stack, learn git and SSH, log into a VPS, etc in order to tweak anything.

Blends are good, too. We recently worked with a client where the website and application were built in PHP/Wordpress, but their API was Python. The "application" was basically a handful of Wordpress templates that pulled API data. They got the nice little CMS interface of Wordpress which made the website admins happy, but the developers got to do the heavy lifting in Python. Their anti-PHP developers were quite happy with the arrangement.

On Marco's post:

    If you can get PHP programmers to agree that they need to stop using it, 
    the first question that comes up is what to use instead, and they’re met 
    with a barrage of difficult choices and 
    wildly different opinions and recommendations.

I think the tension for PHP developers is in understanding on a personal-level how and when to make the transition to newer languages. Unfortunately, many seem to ignore the possibility that a transition is underway.

Everyone should be skeptical of claims that include the word "everyone". Here's some history of ice cutters who did adapt; their business established in 1848 is still operating today:

http://www.capepondice.com/company_history.htm

I would love to be able to not write PHP. But the language that replaces it has to be that easy to deploy.

Passenger (mod_rack/mod_rails) looks like an attempt to imitate that stack to some degree but so far the results are far from perfect.

mod_php is stable enough for what it is... robustness is arguable... mod_php might not scale but it's a key component in php's popularity because it's a zero configuration plugin for apache that works perfectly for the needs of 90% of people writing php or running php applications.

[1] This does not include Dreamhost, Bluehost or any of the other oversold shared hosting (please, feel free to search G+ and see complaint after complaint about them, especially recently).

I guess I don't see any "real" sites being deployed in environments where only PHP is available. A random script that you want to let someone else use for a few minutes, sure, upload that to randomphphost.com, but a real life public webapp??

If you take the time to learn it, deploying C#, python, ruby apps can be insanely easy. And to be my usual self, deploying Golang apps are beyond insanely simple. (I cross compile from my Mac to my Linux 64bit target, upload and run `sudo ./server -host=:80` and I'm deployed).

A few more features get added in this way over the next few month and years and all of a sudden the sites popularity explodes. Now they have a whole bunch of stuff to deal with, and rewriting the entire site in some other language they know nothing about is not on the top of their priority list.

I've deployed C# apps; I did .NET exclusively for about 8 years. It's great! But telling Joe's Washer Warehouse that they have to pay for the .NET stack, and that they can't just find a random PHP guy to do any further development is kind of tough pill to swallow.

Yes, PHP sites are usually the lowest common denominator, but on the other hand there are lots of people that are only willing to pay for that. There's a reason the PHP market is as big as it is. Thankfully for those of us in PHP-land there are starting to be lots of quality frameworks like Drupal and Symfony so that it's not such a horrible experience as it used to be.

And the other part is really the market. You want a large CMS-driven website? PHP is where it's at. That's where the code and communities are. There's a reason that lots of very large websites use Drupal. Sure, if I was going to try and make some sort of big-backend web app that did a lot of services and whatever, I'd want to do .NET. But as a freelance web developer, those projects just aren't there. Like it or not, I'm in PHP land.

(And RoR used to be a total nightmare to deploy. That whole community needs to send a collective giant cardboard check to the mod_passenger guy.)

But even Java is so much better than PHP. If you like it, go for it.

Knowledge of Java can be useful though, as terrible as the language is.

The only thing you might argue is that the JVM is a better runtime than CPython or CRuby, and for that there's JRuby and Jython.

Make small incremental steps.

The investment you think you have in X (PHP) is less than you think. It's much more in how to code, how web works, etc. the PHP parts are cruft you won't miss anyway.

Edit: Perhaps I worded my question wrong. How do PHP programmers try and keep to DRY (ala layouts and view templates)?

EDIT: Disclaimer: I'm a PHP guy trying to make a break for it, and the question was both rethorical and tongue-in-cheek.

    template = """<boilerplate html>%(greeting)s</boilerplate html>"""
    parts = {'greeting': "Hello, World!"}
    page = template % parts

http://mustache.github.com/

An excuse for not learning something new.

-Bjarne Stroustrup

It runs half the Internet quite well, but if you went by the posting on HN, you'd think it was Windows Vista.

I've probably read every article critical of PHP that has hit the front page of HN in the last few years, and the one thing they all have in common is the vague refrain that PHP is a broken language. And yet the gap between tangible proof of that being the case in real world use and the gossip of it supposedly being true, couldn't be wider.

No, what's "wrong" with PHP is that other things that are better have come along since. That's not a fault of PHP, that's the nature of language evolution.

> It runs half the Internet quite well

COBOL runs tons of mission critical business services quite well. It doesn't mean that nobody's improved on COBOL or that you should use it for a new project today.

The problem is, no, nothing else has. Node.js is awesome and fun, but far harder to set up for basic webpage serving. Python is awesome, but also has a huge learning curve to learn how to serve basic webpages with. And... I can't think of anything else. Perl? ASP? Java is a huge pain to set up and maintain.

What other language out there is better than PHP for getting simple webpages up and running quickly? I wish there were one, but when you consider practical aspects instead of just theoretical ones, there really isn't. Sadly.

Myself and an army of other ex-PHP developers disagree.

> What other language out there is better than PHP for getting simple webpages up and running quickly?

This discussion is not just about "getting simple webpages up and running quickly". In fact, it's pretty clear people are talking about developing web applications, and not slapping together a quick and dirty page or two.

If you want to have a discussion about what language is best for inexperienced people to whip up a simple site without having to bother learning much, that's fine, but that's not this discussion. At the very least, that's certainly not what Marco was talking about, nor Jeff in the blog post Marco was responding to.

Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP. (Rails doesn't save you from creating a mess, neither does the broad separation of concerns of any MVC framework.).

There are thousands of ex-PHP developers out there that think they are now better programmers because they now use Ruby or Python, building thousands projects that proof otherwise.

Five to ten years from now, people will be bitching on HN about legacy RoR software like there's no tomorrow. And they'll probably be blaming the language and/or the framework.

Also, does the word "ghetto" ring any bells?

Not that I think Python solves all the problems well either. I'm a fan of Lua, personally, but only because it's a much cleaner language design, and it's faster, and it's easier to set up, and it's easier to write Node.js-style code that's easier to read, and... well, I guess there are a few reasons.

[1] http://discuss.joelonsoftware.com/default.asp?joel.3.309321....

[2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...

> Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP.

That's a longer-winded version of "You Can Write FORTRAN in Any Language". Certainly nothing exclusive or even particularly unique to PHP or PHP programmers.

> But when I wanted to write Second Crack, I went right back — it was a quick little project that I only wanted to spend a couple of days on, so it didn’t justify the overhead of learning a new language.

Whether it's webpages or web apps, nothing else is better than PHP for getting something small up and running quickly. That's the whole point of why Marco feels "addicted". I really wish there were something better in this context, but there isn't.

(And what do you mean, "ex-PHP developer"?? I've never heard someone call themselves an "ex-C" developer or an "ex-Java" developer. You make PHP sound like a cult or religion, instead of just a popular programming tool.)

The crazy thing is that all of that could change with a simple project that does <?coffee > (or whatever) style templating while automatically offering access to CGI data and cookies at a scope reasonably close to the global one. This should take days to implement, and when I have a few of those to spare, I plan to tackle it.

better = in a better "programming language design" sense only

Hey now, we're all human. Even engineers. As soon as something becomes popular, it is no longer cool. Cool is the next popular. Cool is being different. That's just how things work.

Apache is slooooow (NGINX is cool!). MySQL is retarded (Postgres is cool!). PHP sucks (Python is cool!). Red Hat is lame (Ubuntu is cool!).

See a trend? The tech that sucks is the most popular and well established. The tech that's cool isn't popular. It has nothing to do with any objective qualities of platforms. It's all about being a part of the cool croud!

Remind you of high school much?

Now, if this is just a hobby, who gives a shit? Roll with the cool kids. If you're starting a business, be aware that the future welfare of your family is relying on your decisions. Think real hard about that.

Apache is a webserver from 1995. It uses a process (sometimes a thread) per request, a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. Only back in January was the Event MPM added (and it's still experimental), allowing you to have many Keep-Alive connections open at once without degrading performance. Nginx was started in 2004, and is event-based allowing for much higher concurrency. (Yes, I'm hand waving.)

PHP is among the worst languages most sane programmers have ever used. The referenced article, "A Fractal of Bad Design" is a pretty good starting point if you want more details on why it sucks. PHP stands for letting amateurs code effectively. Python is designed with an emphasis on readability, and manages to have a rational type system and a fairly regular standard library.

Apache vs Nginx is about learning from the mistakes of your ancestors. Apache was designed with the 90s in mind, and our technology has moved on to the point where the decisions made in its architecture simply don't work anymore.

PHP vs Python is about being a rational, non-masochistic, human being.

To say what is cool "has nothing to do with any objective qualities of the [technologies involved]" is to know nothing about programming as a business.

People have a tendency to overrate their rational capacity to reason out a viable decision. While you listed a few solid critiques, the situation is infinitely more complex.

And by infinitely, I do mean exactly that. As in, beyond your capacity to reason it out.

In the end, the only right decision is a decision which withstands the test of time. Both Apache and PHP have done that and continue to do so.

Apache holds 65.5% of the market [1]. PHP holds 77.9% of the market [2].

Those solutions are working, right now, for all of those people. That's reality, not grand "rational, non-masochistic" theories.

[1] http://w3techs.com/technologies/details/ws-apache/all/all [2] http://w3techs.com/technologies/details/pl-php/all/all

Now that we're finished with that, I'm going to enjoy myself.

> a architectural decision which made it nearly fundamentally incapable of solving the C10K problem.

C10K is not a problem and never was. The limiting factor in the overwhelming majority of deployments is the pipe. Apache can saturate the pipe just as well as NGINX. You will saturate the pipe long before you reach 10K connections. Which is why people continue to use Apache. Being technologically superior is pointless when there are no real-world benefits to that technological superiority.

On top of that, Apache's thread model provides it with greater stability. If a worker thread crashes for whatever reason, another will simply spin up. If your NGINX process dies, you'll need to wait until your monitoring solution brings it back up. Which could be a long time.

> PHP is among the worst languages most sane programmers have ever used.

Worse than COBOL? Yes, yes, a fractal of bad design! Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.

> Python is designed with an emphasis on readability

Was that humor? Python shoves its version of readability down your throat and laughs as you choke on it. Not all of us get off on syntactically significant white-space. In fact, most of us don't. Which explains why Python is so unpopular. But I get, I get it. It's cool.

> C10K is not a problem and never was.

Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist.

> Which is why people continue to use Apache.

For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php.

This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run.

> Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.

Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?

> Which explains why Python is so unpopular.

Now I know you're spouting nonsense: https://github.com/languages/

Not even close. The author trolled through a bunch of other misinformed articles, copied some them verbatim mistakes and all. He doesn't know PHP and didn't research anything.

> Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?

http://news.ycombinator.com/item?id=4177516

    class MyClass {}
    class YourClass {}

    $myclass = new MyClass();
    $yourclass = new YourClass();

    var_dump($myclass > $yourclass); // false
    var_dump($myclass < $yourclass); // false?

    class MyClass {}
    
    $myclass = MyClass;
    $anotherclass = $myclass();

That all comparisons between objects, except equals and strict equals, return false doesn't seem terribly unreasonable.

> In regard to his "there's no pass-by-object identity..." point, there's no way to do this:

    class MyClass {}
    $myclass = new ReflectionClass('MyClass');
    $anotherclass = $myclass;
    $instance = $anotherclass->newInstance();

    $myclass = 'MyClass';
    $instance = new $myclass();

I think you'll be hard pressed to find too much fault with my criticisms of that article. The author doesn't even know common language terms like private/public/protected. And clearly he's never even seen C++.

It should throw an error, not return false. This goes back to PHP's "try as hard as possible to run the script" mentality.

The author doesn't need to know C++ to comment on PHP's failings, does he? And he knows private/public/protected— you even quote him using them. You're probably not familiar with Python, but there aren't any private methods (aside from double underscored-prefixed methods, but that's not entirely the same). That's where he was coming from. It's not that he doesn't know those terms; it's that he thinks that's how they should work.

Judging by your other responses, you're quick to toss out whether someone is a "PHP programmer" or not, as if that has any bearing on their argument. I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.

I don't disagree. Although I think this goes towards PHP weak typing not it's try as hard to run the script.

> It's not that he doesn't know those terms; it's that he thinks that's how they should work.

He thinks they shouldn't exist at all. Which is one philosophy but that's not a valid criticism.

> I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.

Even where he clearly doesn't know what he's talking about and didn't try the code he was supposedly saying doesn't work?

Those who don't know their tools are bound to have more problems or believe things that are just wrong.

No it's not. We're not talking about music --how popular Bieber is vs Bach, for example. So he didnt just say "tons of people use PHP", he said "tons of people use PHP and it solves their problems giving results".

This is not an "argument by popularity", its an argument by number of empirical verifications. Which is supposedly what engineering and science is all about.

On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results. "That's (eg python) is how a language should be, and not like php" etc. All the while forgetting to take no account practical, verified, php benefits.

>Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there?

OIf it meets their needs and has them happy, of course! Anything else would be dellusional to say.

The original discussion was about whether PHP was a good language. He came in and said, "It is because look at all the people who use it! Obviously it's fine!" That's an appeal to popularity.

> On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results.

What results? We're not talking about Mom & Pop's Homepage, here. Posting about how most sites run on PHP doesn't help us when we're not talking about most sites. We're talking about building apps.

The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes.

Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly.

It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures.

In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases.

Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc.

Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.

I hear this a lot. I think people assume that because lots of amateurs use PHP, it must be helping them be effective. This is not a safe assumption. A shoe does not help amateurs drive nails effectively, no matter how many amateurs you see using one.

For a better of idea of how amateurs interact with PHP, see http://stackoverflow.com/questions/tagged/php

The problem is, it often does take into account objective qualities.

The downsides of popular platforms are often ignored because they carry with them all the advantages of popularity: good support, a well-established community, a wealth of experienced people you can hire or draw upon.

These are not "objective qualities" of the technology, but real side-effects of popularity. In fact, you could say it's a technology's popularity that fools you into ignoring many of the objective qualities of the platform.

I think part of tech hipsterism (which, let's face it, is what you're talking about) is a rejection of this groupthink, and a return to true technological thinking. It's the ability to say "we don't care what's popular, we're just going to look at what works again and see where we end up." I think this very idea is considered 'cool' in the tech world because we tend to like people who think logically about their problems and don't just blindly follow what people have already done. We like people who look at lesser-used technologies (which all of the "cool" tech you listed above actually are) just on their technical merits alone. This is, perhaps, one reason they're considered cool; because it takes actual thought to break away from simply using what everyone else has used for years.

So I think you have noticed a definite trend, but I don't believe it's as purely social as you imply.

That said, "be aware that the future welfare of your family is relying on your decisions" is an argument that's used in so much Enterprise software that it's almost scary. Often the most popular, most entrenched, least risky, biggest company with the largest pockets wins because the CTO can't be blamed for fucking up that decision. It's an incredible driver of technological stagnation in the Enterprise world. It is great to think through your decisions to their far-reaching impact, but be thankful that all of technology is not driven by that kind of strictness, or we'd never use anything new.

Going with cool new things for everything is very risky. This is terrible for established businesses, it's great for startups with no legacy and no pressure to maintain inertia. There cultural differences are endemic to the realities of both types of businesses and aren't just the product of politics.

Just because a technology is "cool" doesn't mean that you're acting like a high schooler for using it. Nor does using non-"cool" technology make you an adult.

Truer words have never been spoken. When you think about it that way, these types of arguments about why language X rocks/sucks become trivial and unimportant.

I like to geek out over languages and technologies as much as the next guy, but there needs to come a time when you put your foot down and make a decision based on more important reasons than personal preference/feelings towards a language.

Cool-ness biases are perhaps not so easy to distinguish from justified ones.

I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.

It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).

For example,

* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?

* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...

* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?

* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".

* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...

* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.

* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.

That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.

Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.

Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.

For historical accuracy, the HTTP server binary of the Apache project has been called 'httpd', compiles to 'httpd' in the source official distributions and is distributed as 'httpd' in the binary official distributions for ages, if not since day one.