Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?

It's mindboggling. It's sad. It's penny wise, pound foolish.

If it's cost > it's profit, why is it still used so widely?

I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.

If it's cost > it's profit, why is it still used so widely?

Network effects, data lock-in, asynchronous information exchange in markets. Just because something is rationally better doesn't mean that the market actors are rational.

That said, companies like EA, Apple, and Amazon license Jive Forums (which is not cheap), Confluence, et al for a reason.

I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.

Your anecdote is a personal anecdote, coming from the person most likely to have a particularly jaded view of both the short and long-term costs involved.

And that's not a personal anecdote? You aren't particularly jaded? I don't understand why I would have a jaded view of the short and long term costs involved. You'll have to explain. I'm not a PHP developer, btw. I consult across a wide variety of technologies and have done so for the last 15+ years. I would have certainly been better paid for that particular gig had I stuck with C#.

It would make sense that Apple and Amazon use Jive since all of their web properties are largely Java based, why step outside of a core competency?

Maintaining PHP apps can be a pain and the language isn't the prettiest to work with.

However, PHP has created a world where millions of people can create basic web applications, which has led to the creation of tens of millions of new sites and applications, some of those which have changed the world.

PHP has allowed more people to code, which has allowed the world to test many more ideas, many of which have created tremendous value that I think far outweigh the costs.

- A world that has PHP and enabled web developers.

- A world without PHP in which only Java EE-enabled engineers can write webapps.

I think that's a demonstrably false assessment. A language as poorly designed and implemented as PHP isn't necessary to be accessible to "millions of people" -- in fact, does the opposite in enabling them to make serious and expensive mistakes.

And then we had PHP.

I'm inclined to side with the parent poster - yes, PHP has a lot of problems when you attempt to make it overly complex, but on the other hand it has introduced many people to programming who would otherwise never have even attempted (or even be able to), and driven ubiquitous web scripting forward single-handedly. Heck, even today, think about someone trying to run a blog - anyone reasonably experienced with a computer can buy hosting and install WordPress with almost no work... try that with anything written in Python?

PHP has a very low barrier to entry, and IMHO a lot of the hate directed at it is frankly jealousy. We are jealous, as professionals, that it is deadly simple to replicate some of our hard work, and that the people doing it are amateurs. This is the same reason people heap hate on VB.

I'm inclined to compare PHP to MySpace - yes, MySpace pages aren't pretty, in fact a lot are downright atrocious. You can make some specious claims about how MySpace-inspired "web design" has made the internet a worse place, somehow, but it would be a pretty thin argument. At the end of the day, both PHP and MySpace opened up a world of possibility to a lot of users who didn't have it before; picking at it really is just being pretentious and elitist.

When did we have all that? In 1995, when PHP was started, I remember having Perl, shell scripts, and C server-side CGIs.

I don't recall significantly better viable alternatives becoming available until quite some time later.

If you can, put aside all that you know about language design, frameworks, and software engineering, and try to think from the perspective of a person just wanting to "get something up". Say you want an online store. An online store requires a shopping cart. You ask google how to do this, and google tells you: How to build a shopping cart with PHP. For whatever reason, php was chosen by the internet gods to be the beneficiary of a positive feedback loop: beginners use php, find it easy to use, write tutorials. Tutorials attract google, which means the community is likely to be less of the programmer type (programmers would already know how to do these things in python) and more of hobbyists/internet entreprenuers with little technical skill. Because this community is comprised of less technical people, they are more understanding of the shortcomings of n00bs. They turn away less "stupid" questions, write more tutorials and abstract more of the academic attributes of programming that "make it work". By virtue of attracting so many people, inevitably, there will be some truly capable practitioners that will go on to have success. Derek Sivers of CD Baby fame is one I can think of.

The point i'm really trying to drive home is that the accessibility of a language isn't just about being easy to learn, but about having a welcoming community and environment that helps new users.

I don't think it's fair to blame bad programming on the language itself.

>Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?

Software written in other languages doesn't require upgrading?

Think of all the cool stuff they could have been inventing had they not needed to look up the name of strfind(?), and whether it takes the needle or the haystack first.

There's a whole generation of programmers out there that couldn't hack their way out of a wet paper back without the help of an IDE telling them what function parameters go where.

And in C I also still can't remember if the fwrite call takes (buffer, sizeof(element), nelements, fp) or (buffer, nelements, sizeof(element), fp).

This is all about religion, the PHP church has a large number of followers and it's 'bible' contains some arguably wrong pages, so those in other churches will go out of their way to shake their heads at all the fools in the PHP church when it's clear to everyone else that their religion is broken.

Meanwhile the PHP guys will simply get the job done and take home the loot.

I can program in lots of languages but for quick & dirty stuff (and don't tell me everything you write is of world class importance) it is very well suited, if you're disciplined you can take it to considerable heights before you run out of steam.

In Python, by contrast, that fwrite call is just:

  fp.write(text)

(And actually...of late, everything I write is of world class importance, but that's an artifact of my current project and the fact that it's sorta taken over my life. I used to write quick & dirty stuff much more often, and I usually used Django for it.)

Java and C++ made me money, PHP made me bupkis. Python at least is fun.

This "we get it done, everyone else doesn't, ergo X is better despite its flaws" logical faux pax drives me up the bloody wall.

That's not what I wrote. It's simply good enough.

A toolbox analogy:

We all know that brand 'x' is 'the best' possible tool available.

So why doesn't everybody use brand 'x' ?

Well, because some people have gotten used to brand 'y' and it is good enough for them.

What's better doesn't enter in to it. There is a minimum level of performance required for the job and both tools meet those requirements, so both are valid tools to solve the problem with.

Which one is the 'better' one is a matter of perspective, and in that sense there are as many truths as there are observers.

After over a decade of writing software, I'm willing to accept this up-front cost in favor of long-term (and often short-term) gain. Sure, I can quickly hack out code when I'm not writing tests, but long term experience with both methodologies has demonstrated to me that it's not worth it.

Like many other 'methodologies', it has uncritical advocacy. (http://blog.objectmentor.com/articles/2009/10/07/tdd-derange...) (HN discussion: http://news.ycombinator.com/item?id=866707)

I agree that automatic testing is nearly always a net gain, but using tests themselves as the primary driver for the design process suggests to me that the developer has little other design experience to draw upon.

It's like make HTML/CSS for a webpage. First level, you create you HTML/CSS code and test it with Firefox usually. Then when you are happy with, you check safari/chrome and debug IE :).

For instance, MailChimp takes CSS styles and modifies your HTML by placing your CSS into inline style tags. This is great, because you can have cleaner markup but still support clients that don't apply CSS well.

(I'm not affiliated with them in any way, just found the app to be very useful while working on a recent project)

If I understand this correctly, this means that the vertical axis goes from "similarity in large-scale structure" at the top to "similarity at the momentary scale" at the bottom, so the triangle is a sensible way to look at it.

Or at least that's how this musicology-phile interpreted them.

They're not "manag[ing] it themselves" -- it's a gigantic stretch to say that software RAID on an instantly-configured EBS volume is remotely equivalent to specifying, ordering, building, installing and maintaining a number of RAID arrays in a data center.

Basically this seems to put a fairly low upper limit to using 'the cloud' for something a little larger before you get back exactly the same kinds of issues that you were dealing with when using self-hosted hardware, only at a higher price point.

This is ridiculous. The primary issues with self-hosted hardware:

- Energy usage. Data centers only have so much power and cooling to spare, what's available costs money, and you constantly have to monitor/juggle utilization and search for more energy-efficient hardware, which leads to the next issue ...

- Physical plant. You often need to buy it well ahead of time to ensure that you'll have power and space available for expansion should you need it. You need to wire that space, buy switches and routers, and that leads to the next issue ...

- People. You'll need people to order, build, and install those servers. You'll need people to swap out dead components in those servers. You'll need trained people to install PDUs and console management systems, to configure and run your switches and routers.

EC2 and similar pushes these issues upstream. You can manage your servers in software. You don't have any routers or switches to manage, you don't have to order, build, or install hardware. You don't have to expend significant capital outlay on servers or rack space.

Pushing issues upstream does not make them go away, it makes them someone elses problem. If that someone else doesn't take care of those issues then you end up having to solve them yourself.

And I've played enough with software raid that I know that configuring it to perform well is not a walk in the park, in fact I think it may be harder than getting a good hardware raid solution up and running on a dedicated box.

The nice thing of course of an EC2 setup is that once you've figured out how to do it you can do it again without much trouble.

As for the energy usage and the physical plant, that is entirely up to your way of using your servers. For instance I try to balance the quality of the service with the load on the servers to gracefully degrade the service when the load is at its peak (which is only a few hours per day anyway). That way I maximize my flat-rate payments on bandwidth and serverlease at a relatively small fraction of what it would cost me to get similar performance out of the various cloud suppliers offering. In a cloud environment those servers would be using just as much power and AC as they do today.

It takes me a little longer to get a server provisioned, on the order of 2 to 3 days, but that is 2 to 3 days, whether I order one, 10 or 100 servers. Very few businesses would ever need to grow faster than that.

Maybe my business is a lucky one in that it can make optimal use of a dedicated server setup but I see plenty of people choosing for a cloud based solution when if you run the numbers it makes very little sense.

The cloud comes in to its own if you have wildly fluctuating loads and/or jobs that need large numbers of machines for a relatively short period.

But for the majority of longer term high bandwidth uses I can't make the numbers work at all.

- What scale you're operating at.

- What vendor you've found that can provide you with 100 leased servers in 2-3 days while costing less than a cloud provider and not requiring you to maintain your own routing/switch/etc infrastructure.

- How you see a dedicated vendor providing managed leased server hosting, network services, on-hands management, etc, as to be genuinely different from a cloud provider -- other than requiring a significantly longer turn-around on provisioning and management tasks.

- How expensive (and for what length) the lease terms are on that server hardware. I've yet to find a quality managed hosting provider that will lease hardware at terms that come close to matching the pricing of either in-house maintained or EC2 provisioned servers).

- http://leaseweb.com

- probably they are not very different than a cloud provider in that aspect, other than that I seem to be getting a pretty good treatment from hosting providers in general (EV1/The Planet excepted, they've gone downhill to the point that we quit hosting there).

There are differences between providers, but for the most part those are relatively small once you reach a certain level.

- The lease terms are variable depending on the use case, but the majority of the longer term leases are for a year to two years, flat rate published price is about 1E29 / Mbit exclusive VAT for 100Mbit, including server lease. I get a better deal than that but I've been asked not to publish it, I'm sure you understand.

A box with 24 1T drives, 8G of ram and dedicated 1G flat-rate uplink currently lists at E1199/month ex vat if you pay in one go for a year, a bit more if you pay month-by-month.

http://www.leaseweb.com/en/configurator/index/id/95

If you're located outside the EU then you do not pay VAT (and if you are in the EU you'll get it back).

Good negotiators will probably be able to shave some off that price, and if you are able to serve lots of bandwidth with relatively little cpu you can add another G for E750, which puts you under 1 euro / Mbit.

If I would do the same using Amazon I'd be paying a multiple.

IMO they would do better to offer hard-to-turn down deals to energy companies in return for guaranteed clean power. (it would be a hell of a thing to have on your power companies adverts)

Is it any stranger than designing and commissioning the manufacture of their own server hardware as to achieve a more efficient ratio of price/reliability for their specific use-case?

There's a lot of information to organize, and doing it efficiently at scale requires moving quite a bit farther down the stack.

Designing your own hardware also, incidentally, lets you control power consumption.

And you thought the iPhone was just Apple's way of muscling into the mobile business! No, it’s really a proactive battle against a wide swatch of proprietary platforms promising to plague a new wave of mobile devices."

http://www.roughlydrafted.com/RD/RDM.Tech.Q2.07/879DD82D-559...

Even if Monty does not succeed, he has the ability to do significant damage to Oracle, Sun, and even industry perceptions of not only the GPL, but of open source in general.

For sure

>and wrong.

Eh, it wasn't something he intended at the time. It's the fact the database is being sold to its competitor is the issue. If say, McCaffee or Apple bought SUN, I doubt he'd be pulling this stunt.

>He sold the product, and now he is actively undermining the product that he sold with the potential of costing Sun/Oracle considerable sums of money to defend against his clearly self-serving claims.

I'd say, I'd be really hesitant to buy something from the dude again. But then again, I've always thought MySQL AB was a bit of a scam and counseled against linking against MySQL it (and therefore having to buy it). The claims could serve Monty, for sure, but they also serve all the rest of us as well.

>Even if Monty does not succeed, he has the ability to do significant damage to Oracle, Sun, and even industry perceptions of not only the GPL, but of open source in general.

I honestly think that's a fine cost. You see, the reason we're seeing issues is here is one of the most restrictive commonly used licenses (GPL) was used without linking exceptions. That's a retarded thing to do for a library you want to be used. Then as a band-aid, MySQL AB repeatedly allowed de facto linking exceptions, but they are not clearly allowed by the license, more as notices, comments, etc.

The GPL, used in libraries, without linking exceptions, is a HORRIBLE thing for consumers of the library, especially mixed with this wink wink nod nod stuff that MySQL engaged in to allow people to use the free version.

If they wanted exceptions, they should have put them in the license. As it is, they DIDN'T, so they've left a huge swath of products build on this wink wink nod nod understanding in legal limbo.

But yes, the GPL, without exceptions, is a horrible license for infrastructure that you integrate against, like DB servers. I think industry SHOULD be hesitant to use it.

What you need to do is point out WHY the GPL is bad in this case, so industry understands the finer point there, and pushes back to have more libraries add exceptions.

Monty's actions leave a bad taste in my mouth too.

I've still signed the petition, because I think Oracle's intentions towards MySQL can only be bad -- they want to neuter it so people have to buy their expensive databases instead. This would not matter so much, except that MySQL is an important part of the technology infrastructure, particularly as part of the LAMP stack.

I wonder when some Sun/Oracle lawyer is going to give him a call and let him know about the legal trouble he could be in for this. I mean, wouldn't this type of behavior have been dealt with in the original MySQL purchase agreement?

That's a stretch. Just because it's called "GCC" doesn't mean it behaves exactly the same on every platform, even if the CPU architecture is the same.

Apple makes extensive modifications, has their own ABI (see below), etc.

In a possibly related note, however, Apple has bizarre and unnecessarily strict alignment policies for Mac OS on x86:

It's not "bizarre and unnecessarily strict" if you want to be able to rely on SSE2+. Apple had the advantage of being able to define their ABI without regard to most legacy concerns, and so they did.

The reason that it's strictly enforced everywhere is that since Apple's compilers use SSE2+ they must be able to assume that, at function entry, the stack is properly (16 byte) aligned.

I understand your pain -- I've had to update a JIT implementation to deal with this, along with quite a bit of assembly that assumed 4 byte alignment, but Apple's reasoning makes sense.

See also: http://stackoverflow.com/questions/612443/why-does-the-mac-a...

The stack has --known alignment-- on entry, which removes the need to compute alignment at runtime. Any other approach requires more instructions overall.

It's not so hard for the callee side of the ABI to make sure the stack is aligned if it's going to use SSE2 and friends; it's rather more onerous to require every call site to make the alignments for the benefit of the callee.

I disagree that it's onerous. It seems silly to increase the runtime costs in exchange for a minutely simplified compiler port. It's not as if non-4-byte aligned ABIs are unusual.

And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully reviewed and modified to port from a platform without this requirement to one with it? Particularly since almost every other platform targeting the same architecture doesn't have the requirement?

SSE2 is used everywhere. That's unlikely.

And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully reviewed and modified to port from a platform without this requirement to one with it? Particularly since almost every other platform targeting the same architecture doesn't have the requirement?

Do you have any idea what the advantages are of being able to use SSE2+ everywhere? I find your position to be startling naive, especially given the fact that the vast majority of the existing Mac OS X developer base did not have any hand-coded inline assembly targeted at x86-32.

Other than game developers, how many legacy x86-32 developers is Apple genuinely interested in courting? Even for game developers (or JIT authors, or otherwise) with an overabundance of x86 4-byte-alignment-assuming assembly, fixing stack alignment is an annoying issue, not an impossible one.

The reasoning makes sense and I'd have done the same. I fixed our code and moved on.

However, if you put the technical reasons aside, and only focus on the business reasons for making a choice here, it's clear to me that the best way to go is to fall in line with the existing precedents for the platform. That way maximizes your business upside. There is no business reason for wanting 16-byte alignment, only business reasons for not wanting it.

The technical case would need to outweigh the business case in order for it to win. But I don't see the technical case as being that strong. Floating point code is rare. Outside of scalable vector-oriented UI libraries and domain-specific number crunching, it's hardly ever used. Many architectures survived for decades with only optional support for floating point, in a coprocessor. Many embedded architectures still use emulated FP, if it's needed at all.

And I really meant it about shockingly naive back there. It tells me everything I need to know about what you know about commercial compilers: that you think of them in the academic sense of being the bit that turns text into code. There's more to it than that in the real world.