The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This is starting to look more and more like a statically-typed language. I won't say whether that's a good or bad thing, as I think both have their places in development, but it just seems kind of weird in a language that professes to be dynamically-typed. What are your thoughts?

I like the direction that PHP is starting to go. PHP5 is, in my opinion, leagues ahead of where PHP4 was, and I hope PHP6 will make even more improvements, especially if it includes namespace support. That's excellent for the developers who use PHP's more advanced features, but I'm wondering what will happen to PHP's largest? user base, using procedural programming. Is PHP going to promote object-oriented programming (as I think it is beginning to in PHP5), maybe earning more respect from some developers, while alienating the others? Is PHP still going to be the language with the low barier to entry and shallow learning curve as it was in PHP4 and earlier?

I don't mind either way. I'm thrilled to see PHP going in the direction it is. I'm just wondering about the effects of this new direction.

That's excellent for the developers who use PHP's more advanced features, but I'm wondering what will happen to PHP's largest? user base, using procedural programming. Is PHP going to promote object-oriented programming (as I think it is beginning to in PHP5), maybe earning more respect from some developers, while alienating the others?

Perl will presumably have the same problem with version 6 - growing pains of the language.

Originally Posted by devbanana

Is PHP still going to be the language with the low barier to entry and shallow learning curve as it was in PHP4 and earlier?

I think it will still have a low barrier to entry, what caught the eye of so many has not changed. What probably (and hopefully) will change is the skill level requirement for professional PHP developers.

Zend are definately trying to make inroads on Java, I'd think it's now an easy transition to move from Java to PHP5 (although the salary for PHP still hasn't caught up but is improving!). If you are only producing web based systems then Java has a lot of additional complexity (being a jack of all trades language) that just doesn't exist in PHP. However, if Java was my home ground, I still wouldn't have have jumped ship to PHP yet.

The last company I worked for tried to go PHP -> Java but it didn't work out well, most of the PHP devs OO wasn't strong enough and development time was significantly increase for Java projects. Anyway, I digress...

I'll have to look deeper into memcache, so I don't know if it handles what I have in mind. In any case, just today I realized that in PHP it makes more sense to -- when you have a collection object, and for example use DB -- keep just the IDs of individual objects in an array, and then construct an object just when you need it, or at least to keep a single object and use ID to reset it to new values. That's because at the end of a request all objects are destroyed, and it doesn't make sense to create all the collection's objects -- especially if you end up using only some of them, which is often case.

In other environments full objects get persisted in memory between requests, and don't have to be recreated each time.

In other environments full objects get persisted in memory between requests, and don't have to be recreated each time.

That's true but don't forget that PHP is designed to re-compile at run time every time; whereas those other languages generally are not. The overhead of creating an object in PHP is generally extremely low compared to those languages, and when combined with the Apache DSO, the raw performance is hard to beat and makes things like a PHP application server make little sense where they are quite necessary to get good performance in other languages that were not designed for the web but were adapted to it.

There's not really any reason performance wise to persist objects between PHP requests. You'd probably end up spending more overhead to persist the object than you would have used to just create a new instance.

The only times I can think of when it would be handy to persist an object is if it is doing something extremely intensive at construction, such as merging several configuration files together into a single config object. But even with things like this, there are other ways to approach the performance issue, such as merging the config files together first, caching that, and then creating the config object which now only has to read one file instead of several.

But if an object must be persisted for whatever reason, it is quite easy to persist if the object is serializable. Just serialize it and store/cache it somewhere, whether it be a file, the database, or memory (there are a few PHP extensions to caching items in memory). The caveat is the object must be serializable, even with memcache, so objects like resources, simplexml, or other internal classes that cannot be serialized are not cacheable.

If most of the objects you are creating during a request are not even being used, rather than look for ways to persist them, I think I would ask the question, "Why are they even being created at all?". Instead of trying to persist all objects that may or may not be needed, why not only create those objects which are most likely necessary (75% or greater chance of being used for example), and reserve creation of the other objects to when you know they are needed (i.e, right before they are used)?

I'm in an airport getting ready to go from orlando, Florida to Pittsburgh, Pennsylvania, but I thought I'd try to make a reply to the replies this thread's already gotten.

Originally Posted by Serberus

Perl will presumably have the same problem with version 6 - growing pains of the language.

That's interesting. So I guess PHP isn't the only language going through this.

Originally Posted by Serberus

I think it will still have a low barrier to entry, what caught the eye of so many has not changed. What probably (and hopefully) will change is the skill level requirement for professional PHP developers.

Zend are definately trying to make inroads on Java, I'd think it's now an easy transition to move from Java to PHP5 (although the salary for PHP still hasn't caught up but is improving!). If you are only producing web based systems then Java has a lot of additional complexity (being a jack of all trades language) that just doesn't exist in PHP. However, if Java was my home ground, I still wouldn't have have jumped ship to PHP yet.

The last company I worked for tried to go PHP -> Java but it didn't work out well, most of the PHP devs OO wasn't strong enough and development time was significantly increase for Java projects. Anyway, I digress...

I hope the skill level of PHP developers does increase. Hopefully, a happy balance can be met, where it is easy to learn PHP, but novice developers are heavily encouraged to improve their skill level. Where they can't just forever make insecure, hackish scripts, but where there are a lo tmore resources for advanced topics. That'd be a happy medium.

Again, I do like these type hinting features. I just find it curious that a dynamic language is implementing such a feature. But I think it's very useful.

The scary thing is, I've met a fe wnovice developers who are currently using PHP4, and said that they don't want to learn PHP5 because it seems too complicated. That's not helping the process of migrating from most people using PHP4 to most people using PHP5.

A few of the features mentioned in the link I gave, i would have liked to see in PHP6. But I do see where they are coming from.

P.S.:

How far behind is the average salary of PHP developers in comparison to that of Java developers?

In any case, just today I realized that in PHP it makes more sense to -- when you have a collection object, and for example use DB -- keep just the IDs of individual objects in an array, and then construct an object just when you need it

Take a look at the Proxy Pattern [GoF] and Lazy Load [PoEAA]. They detail possible alternatives to just storing an array of IDs, that you may find useful.*

Matt.

* But like any design pattern, Think "Do I really need this", or do I have Patternitis?"

Hopefully, a happy balance can be met, where it is easy to learn PHP, but novice developers are heavily encouraged to improve their skill level. Where they can't just forever make insecure, hackish scripts, but where there are a lo tmore resources for advanced topics. That'd be a happy medium.

I think the majority of more seasoned developers want this as well. PHP is being used to solve bigger problems these days, with that comes better development practices to handle the increased complexity.

For the longest time the bigger community sites like phpbuilder, phpfreaks etc push a lot of procedural because that's the PHP way. Looking at some of Rasmus' articles he is "procedurally bias" (if there is such a term).

Originally Posted by devbanana

The scary thing is, I've met a few novice developers who are currently using PHP4, and said that they don't want to learn PHP5 because it seems too complicated. That's not helping the process of migrating from most people using PHP4 to most people using PHP5.

I've seen this myself as well, I hope this will seperate the wheat from the chaff as PHP5 and future versions become the norm.

Originally Posted by devbanana

How far behind is the average salary of PHP developers in comparison to that of Java developers?

From my own experience PHP used to top out about low 30's unless you head to London or take on a lead developer / semi-management role. Salaries have increased this year though and I've seen more around 40 - 45k which was almost unheard of 12 - 18 months ago.

Java can be twice this for an architect / EJB guru position. This is by no means a rule of thumb, just what I've seen advertised.

If most of the objects you are creating during a request are not even being used, rather than look for ways to persist them, I think I would ask the question, "Why are they even being created at all?". Instead of trying to persist all objects that may or may not be needed, why not only create those objects which are most likely necessary (75% or greater chance of being used for example), and reserve creation of the other objects to when you know they are needed (i.e, right before they are used)?

I agree with that.

As I see it, you can do a collection of objects in one of three ways (assuming, of course, that the objects' data is somehow persisted between requests, which is mandatory in PHP as you so nicely explained):

a) Create all objects at the time of collection's creation and hold them in some sort of array. While perhaps the overhead of creating an object might not be too big here, if the objects are large (perhaps with other objects composed into them) and there's a lot of them it can quickly fill up the memory.

The latest seems like a good compromise, because a) it has only one call to the persistance repository (database in this case), b) has the lowest instantiation count (only one) and c) is fairly object-oriented. On the other hand the Widget class has to follow a strict interface, which should include at least a set() method and a constructor with no parameters; i.e. it should be able to exist uninitialized with data, which is not always possible.

PHP6 is definitely a step in the right direction. Personally I'm not sure about the type hinted return values but the general clean up is a very good thing IMO (Ditching of magic quotes, register globals option, long arrays & safe mode etc)

I think the integration of APC is a smart move too although it is a pity that it does not auto configure itself (and hence be enabled by default).

I think the majority of more seasoned developers want this as well. PHP is being used to solve bigger problems these days, with that comes better development practices to handle the increased complexity.

Very true. But I just hope we don't forget about those who still are just creating "personal home pages" as PHP was originally intended for. Again, hopefully PHP can keep developers from both ends of the spectrum happy. Sounds like a challenge.

Originally Posted by Serberus

For the longest time the bigger community sites like phpbuilder, phpfreaks etc push a lot of procedural because that's the PHP way. Looking at some of Rasmus' articles he is "procedurally bias" (if there is such a term).

And until that stops, and until the newer features of PHP5 start to be pushed and encouraged more, I don't think there'll be a mass migration to the newer PHP versions. if there is, they will code in the same style as before and avoid the new classes in PHP5. 'Tis a shame, really.

Also, what hope does PHP have when one of the major developers of it promotes procedural development? )

Originally Posted by Serberus

I've seen this myself as well, I hope this will seperate the wheat from the chaff as PHP5 and future versions become the norm.

Hopefully. But those developers still shouldn't be alienated, just encouraged more heavily to advance their skills. The problem is that too many developers have the attitude of, "as long as it seems to work well enough, it's fine and I don't need to learn anymore."

Originally Posted by Serberus

From my own experience PHP used to top out about low 30's unless you head to London or take on a lead developer / semi-management role. Salaries have increased this year though and I've seen more around 40 - 45k which was almost unheard of 12 - 18 months ago.

Wow, not bad. Not the best salary, but great improvement.

Originally Posted by Serberus

Java can be twice this for an architect / EJB guru position. This is by no means a rule of thumb, just what I've seen advertised.

I'll have to look deeper into memcache, so I don't know if it handles what I have in mind.

There has been some work on an apache module that works like mod_perl/mod_python, that is allows persistence and gives one the ability to hook into apache. I don't think the project has gotten much attention though (sorry can't seem to find a link to it).

The overhead of creating an object in PHP is generally extremely low compared to those languages

Have you actually tested this, because its the opposite. Object instantiation in Java is dramatically faster than PHP (likewise for say C#).

Also as far as I know tools like memcache can only deal with things that are serializable but a lot of things you want to persist are not, such as connections. In Java connectin pooling is trivial..but in PHP?

what hope does PHP have when one of the major developers of it promotes procedural development?

Its only natural, they are after all developing an application writen in a procedural langauge. Maybe they need to switch to C++ : /

Personally, I'd be more than happy if PHP remained a procedural-only language, providing that there's another OOP language that is so nicely intergrated with Apache and supported everywhere like PHP is. Python has some support there, but frankly I'd be happiest if the whole wxJS thing -- and particularly mod_wxjs -- gained some traction.

I returned to PHP to get away from the complex syntax of Java and ASP.net which I had been using for the odd project. Ultimately people use PHP to create websites, not control systems for space rockets - so in my view fundamental ease of use and simplicity should come before absolute "correctness" in the eyes of a programming purist.

v6 looks like Java to me. Java isn't trivial in the same way scripting languages like PHP and ASP are, and moving in that direction would take away the mass appeal. I suggest that the PHP programmers who are looking for a way of programming like BerislavLopac demonstrates have a look at Java today. Might be good for your wallet too

I disagree that quickly written scripts are inheritantly insecure - I could be true that the more complex something becomes the bigger the holes become. (Internet Explorer being a good example) As program logic becomes obscured by programming "clutter" these flaws can be harder to spot.

I love php5 - loosely typed with all the benefits of OO. A balance should be found.

I suggest that the PHP programmers who are looking for a way of programming like BerislavLopac demonstrates have a look at Java today.

Huh? Would you be so kind to clarify a bit what "way of programming" do I demonstrate? After reading your post, I'm not sure that I understand your (rather complex) sentence, nor that you understand what "way of programming" I personally prefer...

changed "you" to "people" and added [take advantage....]

BerislavLopac, don't take it personally and I apologise if you did. I'm just saying that if you people want to program using objects and [take advantage of other programming features such as] strictly typed variables in a way that PHP5 fully doesn't support (so far as I know), then Java might be the tool for you them. Java has been like that since its conception - so no need to wait for the next version of PHP.

I didn't make any assumptions about your programming style or preferences. I was merely commenting on the examples (which I don't fully understand) in post #11. Maybe I didn't make this clear.

I'm sorry that my sentence didn't make perfect sense to you. It makes perfect sense to me. I'm quite happy to be corrected on matters of fact but I find the tone of you response overly hostile / defensive.

Last edited by neildonald; Sep 13, 2006 at 08:23.
Reason: Clarifying use of language relating to BerislavLopac points

The return hinting I am looking forward too, solely for use in interface driven design, and assuming it will be optional.

Up until now, interfaces have always felt like they are 'lacking' because although you can specify the input type, the return type could be wrong for what the method intends and ruin the whole purpose of the interface

Its only natural, they are after all developing an application writen in a procedural langauge. Maybe they need to switch to C++ : /

PHP++, now written in C++! Sorry, couldn't resist.

Originally Posted by BerislavLopac

Personally, I'd be more than happy if PHP remained a procedural-only language, providing that there's another OOP language that is so nicely intergrated with Apache and supported everywhere like PHP is. Python has some support there, but frankly I'd be happiest if the whole wxJS thing -- and particularly mod_wxjs -- gained some traction.

I don't know about that. I think it's too late for PHP to be turned to a strictly procedural language. Also, i'd be a bit lost then.

Wouldn't be bad if they had two versions of PHP though; one that was strictly procedural and one that was strictly object-oriented. That'd make me happy.

By the way, interesting link. I'll be reading more about that later.

Originally Posted by neildonald

I returned to PHP to get away from the complex syntax of Java and ASP.net which I had been using for the odd project. Ultimately people use PHP to create websites, not control systems for space rockets - so in my view fundamental ease of use and simplicity should come before absolute "correctness" in the eyes of a programming purist.

I, kinda, disagree. Sure it should be easy to use, but if it's going to be used for anywhere close to a large web site, it needs to allow for object-oriented practices comparable to other OO languages. I'd really be happy if the developers prefering procedural devlopment deveoped procedurally, while I could still use all the object-oriented features I wanted to.

Originally Posted by neildonald

v6 looks like Java to me. Java isn't trivial in the same way scripting languages like PHP and ASP are, and moving in that direction would take away the mass appeal. I suggest that the PHP programmers who are looking for a way of programming like BerislavLopac demonstrates have a look at Java today. Might be good for your wallet too

Again, the ease-of-use you refer to isn't going to work for larger-scale web sites. Do we want PHP to forever be the language only for personal, small web sites? Or do we want to be able to make a living off of it by making any type of web site needed, regardless of the size or complexity?

If I wanted to be developing in java, I would be. I like so many things about PHP, though. I've been through my share of languages, but keep coming back to PHP.

Originally Posted by neildonald

I disagree that quickly written scripts are inheritantly insecure - I could be true that the more complex something becomes the bigger the holes become. (Internet Explorer being a good example) As program logic becomes obscured by programming "clutter" these flaws can be harder to spot.

I didn't imply that. I was trying to get across that most novice developers to PHP don't really think about security, but simply throw together a script, and are happy as long as it works, regardless of security or maintenance.

Originally Posted by neildonald

I love php5 - loosely typed with all the benefits of OO. A balance should be found.

Originally Posted by worchyld

Just make it like ruby/rails, secure to code without having to worry about XSS issues, easy to understand and get full support by hosting companies to support it.

That's an unfair comparison. RoR is a framework built on Ruby. PHP is a language written specifically for the web.

Originally Posted by skinny monkey

OPTIONAL object-oriented purity. What could be better? Its there for those who want it, and not there for those who don't. It really is the best of both worlds.

I will be embracing it. All i've been after in php for a while now is OPTIONAL type-hinted return values, and namespaces. If php6 has both, it will be a pleasure to program with.

Agreed. I'm just thinking about the future of PHP in general, PHP6 and beyond. Wondering where it's going.

BerislavLopac, don't take it personally and I apologise if you did. I'm just saying that if you want to program using objects and strictly typed variables in a way that PHP5 fully doesn't support (so far as I know), then Java might be the tool for you.

Not at all, I haven't taken it personally -- it was just that I was completly taken aback with your assumption which was't clear in the previous post, but you confirmed it now.

I really have no idea where you got the impression (again, no offense -- just total confusion) that I want to program using strictly typed variables. I believe that all my posts so far, in all the threads I participated, clearly displayed my inclination towards dynamic typing, and that I wouldn't touch static typing with a ten-foot pole, except where it improves the architecture.

I've worked in quite a lot of languages, from Basic to C to PHP to Java to Python to XSLT to Javascript, and all in all I have nearly two decades of programming experience.

Originally Posted by neildonald

I didn't make any assumptions about your programming style or preferences. I was merely commenting on the examples (which I don't fully understand) in post #11. Maybe I didn't make this clear.

No you didn't, and especially I don't get where did you see static typing in those examples?

Also as far as I know tools like memcache can only deal with things that are serializable but a lot of things you want to persist are not, such as connections. In Java connectin pooling is trivial..but in PHP?

This is true (only caching serializable stuff), though in PHP there should be no need to persist a database connection into memcache or APC. Persistent connections are already handled by PHP. Admittedly, they're not identical to connection pools in Java, but they at least help solve the issue of having PHP open & close a new connection on every script invocation.

the more i learn about other languages

I started out in php and still use it @ home.

However, at work i program in .net and at school i program microcontrollers in c.

Wish list:

namespaces

nested classes support [example:
Authenticate has nested: AuthenticateCookie, AuthenticateSession
this way storeauth, logout, confirm are clean from actual implementation
.. perfect for classes only needed by one other class. [cannot be methods.. because these follow an interface also. -- parsing libraries]
]

enums

c style better procedure support:
pointers
function pointers [dispatch tables -- simulate delegates as someone above stated; High order perl book .. is best practices in procedure style programming.. i would recommend it even to oop people like myself.]

i mean if functions like http://us3.php.net/unpack exist and bitwise operators exist.. why can't i find the location of the bits. why can't i work with addresses instead of values?

how about stucts so the stack frame isn't as large as a class would be.

httpmodules ... something better than mod_action ... php.net/pdo needs more examples with advanced database feature. I have an opened item in advanced php forum talking about cursors.. i haven't been able to find any examples. [think it might be that i'm not using a persistant connection... but my laptop crapped out on me.. so i'll let everyone know by friday.]