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.
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.
Yet the fact of the matter is that's how the cards fell - we had the well-designed, well-implemented languages and frameworks that failed utterly to find any foothold with amateurs and beginners, and only found refuge with the Java EE-enabled engineers.
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.
Yet Wordpress is still the most widely used blog software ever. PHPBB and it's ilk still run the forum game. Wikipedia has yet be unseated.
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.
- 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.
I'm not religiously in favor of "tests first, always" (who actually is?), but I find that when you emphasize testing, you spend less time debugging, more time coding, and the end result is generally better engineered.
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.
Interesting, but the problem with writing HTML e-mail is rarely real-browser testing, but rather, testing the convoluted filtering/rendering of the various webmail clients (Hotmail, Yahoo, GMail).
- 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).
It is advantageous to them to have power, sure - but it doens't really directly contribute to their goal of organising the worlds information does it?
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.
It definitely looks as though they ended up having to manage it themselves.
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.
Do you genuinely believe that a company with such a huge investment in data centers is demonstrating a lack of focus by concerning themselves with energy?
It's duplicitous and wrong. 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.
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.
No, Apple made a perfectly sane business and technical decision to optimize for their users and existing developer base rather than a small subset of the non-Apple developer base who would have issue with 16-byte stack alignment.
The reasoning makes sense and I'd have done the same. I fixed our code and moved on.
But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere.
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 stack is not actually aligned on function entry, because the return address is on top, so more alignment will be needed to avoid SSE2 locals being misaligned.
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.
For the same CPU architecture, compiler and FPU control word, you should expect the same results.
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.
This shouldn't surprise anyone and I can't say I understand the breathless post. For more information, I recommend Write Great Code: Understanding the Machine -- Chapter 4, Floating-Point Representation.
Multiprocess approaches are both significantly more complicated to implement and significantly more constrained in their functionality.
Unless you have overriding design restrictions (such as requiring privilege separated worker processes), it seems that the only genuine argument for the "multiprocessing" model is simply that Python doesn't support anything else.
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.