How do you know when a language is "enterprise ready"

[JaredWhite]

Can somebody that prefers open source software explain to me briefly why exactly YOU side with open source instead of closed source?

If something is open source, and I find a problem with it, odds are someone else is too. And probably fixing it. The people that build products simply can't be expected to anticipate every single way it will be used. With open source, the people that use the products can change or create the functionality they want. Simple as that.

I also don't trust closed source. What if the company that develops the product or technology decides to radically alter it in a future version? What if they get bought? What if they discontinue it? With open source, that danger is non-existent because the code is there. You can work on it and support it -- or in extreme cases, fork it. WordPress, one of the most successful PHP apps around, started as a fork of a discontinued blog app.

The argument against open source in terms of its reliability are pretty laughable considering that the entire computer industry, including the Internet, would come crashing to its knees if all of the open source software powering a lot of it stopped working. It's like arguing that the Sun is really unstable and might explode tomorrow. Sure, it's always a possibility, but that certainly hasn't happened in the past 6000+ years (or billions if that's your thing).

Jared

[awasson]

Can somebody that prefers open source software explain to me briefly why exactly YOU side with open source instead of closed source?

This is going to be interesting.

Variety of solutions, dedicated contributors as well as full diclosure. What more would you like?

As far as quality goes, here's a little something to chew on:
http://www.eweek.com/article2/0,4149,1420487,00.asp

[dagfinn]

p.s. I really hope the "Extreme Simplicity" approach takes off in PHP land. There is a big risk that we will get more junk like the SPL RecursiveIteratorIterator, and PHP will simply become as unusable as Perl. Perl is the one language that is more of an enterprise failure than PHP.

There seems to be an overlooked issue with "extreme simplicity": what's extremely simple for the developers of a language may not be extremely simple for its users.

The way object-orientation was introduced in Perl 5 is a case in point. It's extremely simple in the sense that very little was added to the language to achieve it. There's the "bless" function that transforms anything into an object of a given class and a few small pieces of syntactic sugar. That's about it, if I remember correctly.

That doesn't mean the object-oriented code you can write in Perl is as simple as possible. Quite the contrary.

I'm not sure this distinction is clear to the PHP developers.

EDIT: See also Martin Fowler's discussion of humane interfaces.

[Carl]

I have read through this thread and aside from a few remarks about buzz words no one has tried to define "enterprise ready". You can't very well say PHP is or is not something without knowing what that something entails. What are the traits of an "enterprise ready" language?

I am interested in this because I am writing a report on enterprise database techniques and technology and why open source PHP projects don't use them.

A few of the things that I would say that would make PHP not "enterprise ready" are:

1)no native unicode support
2)cannot be compiled (uses c to compile its components) and is in all senses a scripting only language unlike Perl and some others that can actually do whatever C language does. Cold Fusion had this problem also but now they have melded it so close to Java that it is not as noticable a drawback.
3)PHP has a very shallow reach into the operations of the webserver and OS. This becomes evident trying to control user access permissions and other items.
4)no multi-threading support (at least I have never seen a multi-threaded PHP application)
5)light weight memory handling with none available on certain OSes

[Benjymouse]

Business Case. In an enterprise the going wisdom is that you are accountable for everything you do. Every hour you work (and thus should be paid for) must be accounted for, so that in the end the correct customer/dept can be invoiced.

Budgets and accounts rules. Love it or hate it, but that's the way enterprises work.

Before you can launch a project a business case has to be made. The business case details the benefits (predicted value) and the predicted cost. Typically, a management forum will process potential projects, look into their business cases and consider the projects role in the overall business strategy. Then, on basis of that, they will decide for each suggested project whether to give a go-ahead, reject, postpone or ask for revision/further details.

More important, good management always keep a wary eye on the running cost of capacity and ownership. The only thing they loathe more than high, recurring costs are unpredicted costs.

In the typical enterprise, (percieved) predictablity is everything. You don't want to launch a project without having a somewhat reliable estimation of the costs incurred by the project.

But the absolutely most unwelcome kind of costs are unpredicted costs originating from his/hers choice of platforms or tools. This is so because of mainly two concerns: 1) there's no project (and thus no budget account) which could be stretched to absorb the costs, and b) the choice of platform/tools are the sole responsibility of the IT organisation. And with the responsibility comes the blame.

Realizing that roadmaps and promises are just that, the typical manager responsible for making platform/tools choices will instictively look at platform/tool history and at the organisation behind the platform/tool.

In this light PHP does not come across as a good choice. Consider the following (I'll be wearing my asbestos suit in a minute):
- Releases (also point releases) have broken backward compatibility, while security concerns forcing you to upgrade. An enterprise may have 100s of projects to consider. Operations must be allowed to do an upgrade of the platform with the expectation that only a few apps will encounter problems. In an enterprise it's not the developer who has the responsibility of the platform!
- There's evidence of mavericks making project decisions which clearly had not been thorougly discussed.
- Fluctuating concepts: Older functions rely on the programmer to check return codes, while more recent libraries may rely on exceptions. Procedural language-turned-half-OO. Weakly/dynamically typed but still introducing type hinting.
- Samples of facilities which were percieved as smart at the time of inception, but later have proven to lead to unstable and - worse - exploitable code. Think "register globals" or paramerized includes.
- Fragmented community: Everybody does their own class library. May work for independant developers, but it's a non starter in the enterprise.
- Performance considerations. Even with an accellerator, even quoting google, there's still concerns about performance/scalability.
- Concerns about specialised resources. An enterpise does other projects than web projects. So far PHP is percieved as a web-only tool.

PHP may get there, but my guess is that PHP must prove itself with the 6.x platform. If 6.x proves stable, predictable, performant, scalable, productive, managable and secure, and with the backing of the likes of IBM and Oracle, it might just cut it around 7.0.

Whether or not PHP is a technically viable alternative for the enterprise now is merely the first step. PHP must also prove worthy in the sometimes surreal and sub-optimizing reality which is the enterprise of today. Whether you like Microsoft or not, like Sun or not, like IBM or not - they are all more defendable choices, simply because they are who they are. If PHP are to overcome this intrinsic unfairness, PHP must excel in preditability, robustness, security and productivity.

[BerislavLopac]

A few of the things that I would say that would make PHP not "enterprise ready" are:

1)no native unicode support
2)cannot be compiled (uses c to compile its components) and is in all senses a scripting only language unlike Perl and some others that can actually do whatever C language does. Cold Fusion had this problem also but now they have melded it so close to Java that it is not as noticable a drawback.
3)PHP has a very shallow reach into the operations of the webserver and OS. This becomes evident trying to control user access permissions and other items.
4)no multi-threading support (at least I have never seen a multi-threaded PHP application)
5)light weight memory handling with none available on certain OSes

PHP is not a general purpose language like those you mention -- it's strictly a server-side Web scripting language currently implemented on a C-based platform that is called the same as the language.

PHP should be considered exclusively under these considerations -- despite the presence of PHP-GTK and Winbinder, it's not a language to use for general development, only for server-side Web applications and probably shell scripting. So, there is no wonder it has no compiling, multithreading and memory handling (as for the other two complaints, I agree for unicode, while it has quite a good support for Web server features, though not for OS).

So, don't expect PHP to be what it isn't, it's like complaining that you don't have a TV, a bar and a nitro-booster in your Yugo.

[Scheisskopf]

it's like complaining that you don't have a TV, a bar and a nitro-booster in your Yugo.

Can i complain that i don't have four wheels on my Polo?

[Carl]

PHP is not a general purpose language like those you mention -- it's strictly a server-side Web scripting language currently implemented on a C-based platform that is called the same as the language.

Looking at the post above I guess everyone agrees then. PHP is not "enterprise ready" because most enterprises would not naturally opt for something that has such a narrow field of usage. They have to be sold on the idea or a concept that includes PHP and considering its limitations. Those are very few right now. If PHP starts winning the choices like the ones made when Basecamp was created then maybe it will finally get its enterprise props.

[BerislavLopac]

The term "enterprise-ready" means absolutely nothing. Or, to be more precise, it means many things to many people, which is essentially nothing.

[mx2k]

The term "enterprise-ready" means absolutely nothing. Or, to be more precise, it means many things to many people, which is essentially nothing.

despite it's elusive meaning, its still a major factor/criteria in corporations using it to build web apps, which is important to developers because it could help in getting a job or a project and etc.

[dagfinn]

In this light PHP does not come across as a good choice. Consider the following (I'll be wearing my asbestos suit in a minute):
- Releases (also point releases) have broken backward compatibility, while security concerns forcing you to upgrade. An enterprise may have 100s of projects to consider. Operations must be allowed to do an upgrade of the platform with the expectation that only a few apps will encounter problems. In an enterprise it's not the developer who has the responsibility of the platform!
- There's evidence of mavericks making project decisions which clearly had not been thorougly discussed.
- Fluctuating concepts: Older functions rely on the programmer to check return codes, while more recent libraries may rely on exceptions. Procedural language-turned-half-OO. Weakly/dynamically typed but still introducing type hinting.
- Samples of facilities which were percieved as smart at the time of inception, but later have proven to lead to unstable and - worse - exploitable code. Think "register globals" or paramerized includes.
- Fragmented community: Everybody does their own class library. May work for independant developers, but it's a non starter in the enterprise.
- Performance considerations. Even with an accellerator, even quoting google, there's still concerns about performance/scalability.
- Concerns about specialised resources. An enterpise does other projects than web projects. So far PHP is percieved as a web-only tool.

Very nice summary. But in all fairness, at least some of these have been or are being addressed. The Zend Collaboration Project is only part of the evidence for that.

[M. Johansson]

This discussion is very nice. It doesn't take to ordinary PHP/Enterprise spin, but actually gives a lot of real, tangliable insights why PHP haven't established itself in enterprises.

[dagfinn]

Can i complain that i don't have four wheels on my Polo?

You mean the number of wheels is not configurable??

[Ryan Wray]

It seem PHP is stuck: If it breaks BC, it is not enterprise ready, however, if it doesn't break it (ie. the language flaws are removed), then it is also not enterprise ready. I think PHP 6, if it acts as a fresh start, could be enterprise ready for new projects. And as long as they do it well, backwards compatibility could be maintained as best as possible throughout all further versions.

[Dr Livingston]

PHP is not "enterprise ready" because most enterprises would not naturally opt for something that has such a narrow field of usage.

That is complete and utter rubbish, to make a statement like that. Is PHP limited just because it's a server side development language, compared against a general programming language?

Of course it's not. You certainly couldn't describe it as being Enterprise Ready, or otherwise, based on that comparison

[quenting]

To add on the PHP "not enterprise-readiness", I'd say the fact that java exists contribute to it.

Almost all the advantages of using PHP that are related to its open-sourceness are also applicable to java: most java applications rely on open-source software (struts, hibernate, spring, jboss, tomcat, eclipse, just to name a few). I don't want to turn the discussion in a java vs php threads, but the question really is why would an enterprise make the strategic decision of using PHP rather than java, when most of PHP's strengths are also Java's, and the developper availability is greater for java, it's already used by many enterprises, and the CIO has actually heard about it.

PHP needs to differentiate from Java (which it seems it's not trying since each PHP release brings it closer to sun's language) to find an enterprise audience.

[ShytKicka]

it compiles to java at a lower level, the language itself is not pure java. And if i really wanted to waste my time, it would be no problem to pick up the syntax for cold fusion, people simply pass it over due to the hosting cost, not because you have to be an elite programmer to utilize it or because its considered enterprise ready (and to my knowledge, i don't know of too many people going around thinking of it as an enterprise platform, i'm not arguing that it is or is not, because i just simply do not care.) and please don't insult java just because cold fusion compiles into java bytecode.

I use both c#, vb.net., and php, and php being open source, has absolutely no bearing on it's enterprise readiness. I actually root for php to get better as a language and as part of the wamp/lamp platform.

To mock the power that open source code has given to people, is a sure sign of pure ignorance to, and thats coming from the village idiot of the php forum (yeah that would be me).

Are you kidding me? What are you trying to do, preach to me what Coldfusion is? You have no idea who you are talking to. Another script kiddie.

Coldfusion is pure Java at run-time. And it always will be pure Java. Since the syntax is different, it doesn't make it a different language, what is executing this syntax code? Java. When the Coldfusion files are first ran after server start-up, or after editing the file, they are dynamically pre-compiled into Java Bytecode which is stored in the server's memory. The executed code at run-time is the Java Bytecode. Please, you're right, don't waste your time, because you have no clue who you're talking to, and what you are talking about.

It is no problem to pick up the syntax for any language, what you think your little php scripties that sell for $4 bucks are so much better? And if anything, I'd be supporting the language that is easier to develop for, and that is basically why Coldfusion sells, because of its tag-based syntax. And guess what, you can't argue that it is too easy because Coldfusion also has a script-based syntax, that is familiar to Javascript and all the other web developing languages you've seen, or haven't seen for that matter.

Why bother arguing with script kiddies, please get out of here and sell your little polls for $3 bucks instead.

[jayboots]

The term "enterprise-ready" means absolutely nothing. Or, to be more precise, it means many things to many people, which is essentially nothing.

Well said. Not only is there a wide range of opinion within a group but ask a bunch of upper-managers what they expect compared to a bunch of technologists/engineers and I'd expect characteristically different answers as well.

[Quaint]

What I find interesting is that I don't even agree to PHP NOT being enterprise-ready?!?! Where do you base that on? I'd by now be ready to deploy PHP in enterprise applications, why not?

[mx2k]

Are you kidding me? What are you trying to do, preach to me what Coldfusion is? You have no idea who you are talking to. Another script kiddie.

Coldfusion is pure Java at run-time. And it always will be pure Java. Since the syntax is different, it doesn't make it a different language, what is executing this syntax code? Java. When the Coldfusion files are first ran after server start-up, or after editing the file, they are dynamically pre-compiled into Java Bytecode which is stored in the server's memory. The executed code at run-time is the Java Bytecode. Please, you're right, don't waste your time, because you have no clue who you're talking to, and what you are talking about.

It is no problem to pick up the syntax for any language, what you think your little php scripties that sell for $4 bucks are so much better? And if anything, I'd be supporting the language that is easier to develop for, and that is basically why Coldfusion sells, because of its tag-based syntax. And guess what, you can't argue that it is too easy because Coldfusion also has a script-based syntax, that is familiar to Javascript and all the other web developing languages you've seen, or haven't seen for that matter.

Why bother arguing with script kiddies, please get out of here and sell your little polls for $3 bucks instead.

thank you for proving my point, it compiles into Javabyte code, but its not the language java as i previously posted, i can see how that could confuse you.

c#and vb.net are not scripts. both are compiled into msil. but i see that you missed those in your obvious frustration of proving an unfounded point. And i did state that cold fusion compiles into javabyte code,

but there is only so much you can do with server tags/scripts, which is what cold fusion is, you said so yourself.

Could you code in java and use it with cold fusion, if i am not mistaken, you can along with com objects, but if you knew that, i'm sure you would have posted it instead of using the arguement about scripting......

the same priciple would go for people that just use server controls/user controls for asp.net. Which leaves you limited, why not be free to use language itself, ie java or if you are using asp.net, c#/vb.net etc?

you use markup tags and a little bit of scripting similar to javascript and you dare to start name calling in a php forum? ooookkk.

and please stop trying using words to sound elite. at least i do admit to being the village idiot. script kiddies take code that someone else has written and tweak it for themselves and then run around mistyping words on IRC and use words like NoOb because they KeWl. I don't know of any "script kiddies" that actually try to sell code.

and techinically speaking, i could compile php into MSIL by using Phalanger.

i didn't say coldfusion is terrible, but i don't see it being better than php, or that ease of use markup was a good trade off with being stuck running a J2EE compliant application server or JRun.

as for who you are? who cares. you brought an unprofessional attitude into this thread and presented weak arguments, its probably best that no one knows who you are. Good Day to you sir!

[Luke Redpath]

You have no idea who you are talking to. Another script kiddie.

Please, you're right, don't waste your time, because you have no clue who you're talking to, and what you are talking about.

It is no problem to pick up the syntax for any language, what you think your little php scripties that sell for $4 bucks are so much better?

Why bother arguing with script kiddies, please get out of here and sell your little polls for $3 bucks instead.

Your rather obnoxious and condescending stance doesn't really help your argument.

[arborint]

I have read through this thread and aside from a few remarks about buzz words no one has tried to define "enterprise ready". You can't very well say PHP is or is not something without knowing what that something entails. What are the traits of an "enterprise ready" language?

There is no specific definition because it is both a marketing term and a techinical term. To marketers it means "My product will meet your company's needs" and to a techie it means "I got that product to meet my company's needs".

[sweatje]

There is no specific definition because it is both a marketing term and a techinical term. To marketers it means "My product will meet your company's needs" and to a techie it means "I got that product to meet my company's needs".

I think it is more like:

For the product salesman/marketer: "It is going to cost your company a lot of money to run my product, but I am going to take your CIO on a golf outing to make sure we are defined as the only acceptable standard"

and to the techie it means: "I don't know how these goofy corporate standards keep getting defined, I can do the same thing faster for free with this"

[Dr Livingston]

i didn't say coldfusion is terrible,

No, you didn't. But I will - ColdFusion sucks. Okay, I've said it. It isn't a development language, it's a technology. A limited technology at that, and has no basis to be compared to the likes of PHP, Java, etc.

Another disadvantage of ColdFusion is price - an important factor. Fair enough the price may well have fallen, I don't know, but I do know that 18 months ago it was costly.

Your rather obnoxious and condescending stance doesn't really help your argument.

Like, I can't even take those comments as being serious

[jayboots]

There is no specific definition because it is both a marketing term and a techinical term. To marketers it means "My product will meet your company's needs" and to a techie it means "I got that product to meet my company's needs".

A technical term? I think not in any way what-so-ever. It most certainly is a euphemism used by marketing droids and managers. Also, by "I got that product to meet my company's needs" I take it that must mean a manager and not a "techie", yes?

Take "load balanced", "connection pooled", "reverse proxied" -- at least those have some semblence of a technical meaning. Yet the marketing pundits will come in and discuss "scalability". "Enterprise Ready" comes from the lexicon of those who don't necessarily understand the finer points of technology (such as the point of this forum: application design). I posit that decision makers do not have nearly the same set of guiding principles as technologists.