That's the same logic as if you saw some people on the street fighting with knives, tearing each other up and you say "meh, whatever".Originally Posted by Snaily
| SitePoint Sponsor |
That's the same logic as if you saw some people on the street fighting with knives, tearing each other up and you say "meh, whatever".
.
Zach Holman
good-tutorials — blog — twitter — last.fm
I seriously wonder which sort of logic you have in mind (bushian logic?).... but yes "same logic" except in this case when you ignore the issue nobody gets hurt in anyway. Unless you are suggesting that your posts are some how saving us all? When I find things "timesome and annoying" I don't bother with them...apparently you do.That's the same logic as if you saw some people on the street fighting with knives, tearing each other up and you say "meh, whatever".
Please leave your politics at the door. I simply was making my opinion known that I think this is a fairly pointless "debate". People get way too uptight about this stuff, as evidenced by your jump on my mediating words. There's nothing getting done in this thread. This sums it up best:
I'm sorry to butt my ugly, rude head into this by calming stepping in and offering a neutral opinion. I'll tell you what's going to happen. People are going to continue to jump into this, go at each other's throats for the next couple of days, with each party escalating the argument with points that are less and less substantiated until finally we close the thread and everyone loses out. There is a lot of opportunity for both sides (and more importantly, bystanders sitting and watching all of this go down) to learn and to explain, but it's just going to get squandered and no one will end up the better because of it, as dreamscape pointed out.
.
Zach Holman
good-tutorials — blog — twitter — last.fm
Found these links quite interesting, thanks.
Could this have been anything but a flame thread?
up next: Who can tell me why Apple computers are better than PCs?
As to the topic:
Java is faster because it's named after coffee, coffee has caffeine, caffeine is a stimulant, stimulants make you feel like you're going faster.
P-H-P kinda looks like p-o-o-p, if you squint really hard; poop isn't very fast at all.
lo0ol do you use JSTL?
"A nerd who gets contacts
and a trendy hair cut is still a nerd"
- Stephen Colbert on Apple Users
No tool, however good, can make up for the power and flexibility you loose with static typing.
I don't know the technicalities but I've used both apps on my servers and I can tell you that Java apps eat up far more system resources than PHP apps that do the same thing. The JSP environment(whether tomcat, etc) just consumes much more memory than the apache environment. I can run most any php app fine on 512MB ram. I need upwards of 2GB to run many java apps.
Why? Tomcat certainly doesn't use that much memory (not even close). Are the applications using 2GB of memory??? Do you get exceptions when you restrict the heap size to numbers lower than 2GB?I need upwards of 2GB to run many java apps
Taken in a straight algorithm vs. algorithm way, of course not (assuming that the end product of a JIT compilation actually optimizes as well as the native C functions that you're calling in PHP, which is rarely the case). Nobody would argue that PHP is faster than java in those kinds of comparisons. We're talking response time and server load being generated.
So does a sensible variable name. An object does NOT (in and of itself...) tell you a damn thing about what it can do. For that, you need to consult documentation and/or use an IDE that has some kind of intellisense-like support built in, and even then you'll still wind up consulting documentation most of the time.The data type tells me a lot about the object. It tell's me what kind of an object it is. It tells me what I can expect the object to be able to do, it tell's me what the object knows. Actually, it tells me everything I need to know about that little object.
This:
Player GetPlayer(string PlayerName);
doesn't really tell you anything more than:
function GetPlayer($PlayerName);
(unless, of course, there's no documentation for either function, which is really quite silly).
The limitations that static typing imposes on you are not justified by the marginal gain in "obviousness" of code. You can argue static typing as a performance advantage if you want, but the information provided is a pretty weak argument.
What if I change from accepting a simple string to accepting a complex data type as well? What if I've switched database platforms and now I need to handle a different type of result set object in my abstraction layer?I won't want to change the data type later on. Why would I want to do that? Appears to be really stupid to me.
In the code working with the object you'll have method-calls on this object, you'll access properties, you'll pass it to other methods that themself rely on the type of that object. Are you sure you know what an object is?
The most common solution to these sorts of problems in static languages is to have some type which is actually a wrapper around, or an alias to another type. In PHP, that's completely unnecessary. Refactoring is much, much simpler when you don't have to worry about data types.
Generics are used in any sitaution where you have to be able to handle multiple data types. The same is true of overloading. With PHP, you don't need this. You can store any data type you want in your containers (and you get heterogenous containers for free, too).Generics solve an entirely different problem... that is, for example, for object (like collections) that do not care about the type of object they're collection. For that, generics provide compile-time safety. Generics are an add-on to provide static typing to collections and the like!
Yeah, maybe if you're completely clueless this would be a problem, but in practice it doesn't come up. The vast majority of your arguments are going to be primitive data types, and even those that aren't are going to be obvious if you write easy to read code. I could see this being an argument in an environment where you had no access to the documentation or no access to the code library that you're calling, but this is definitely not something that happens with PHP.What type is "PlayerName" of? Is it a type itself? Could very well be, maybe a subclass of Name. Or did you mean it to be a String? Couldn't tell from that name, though...
It means a number. Any normal human being knows what a number is. PHP doesn't care what the actual data size is (nor is there any logical reason to in these scenerios).What is "NumberOfIteration"? A number? What do you mean by "number"? A double? An int? Maybe a byte? Or is an object itself?
You'd only think that if you're a Java developer and insist on wrapping every primitive data type in an object that doesn't do anything but add complexity into the system. "Time to live" is a common term in computer science, and anybody who's programming would know what it is (except maybe a Java developer who thinks it should be a TimeInSeconds object which is derived from a NumericTimeRepresentationObject which is in turn built upon the base abstract Time class...)I'm, however, pretty sure your "TimeToLive" would be a variable of type "Time" - except it is an unix-timestamp... in that case it'd be an int/long... oh well... guess I do not know what type it is of... I'm sorry.
I'm, however, pretty sure your "TimeToLive" would be a variable of type "Time" - except it is an unix-timestamp... in that case it'd be an int/long... oh well... guess I do not know what type it is of... I'm sorry.
Unless you're adding more parameters (or removing some...), then you'll never have need to do so. And even then, manually changing a piece of code is hardly going to "break your neck". If you're refactoring something significantly enough so that changing the signature will actually break other code, then you've probably got a whole lot more to worry about.But if you have to (because of maintainance), it'll break your neck. With modern Java-IDEs this is one of the easiest tasks. With PHP, your toast (I'm working on this, though - but because of missing types in PHP my work on producing a real IDE for it is way harder - if I had decided to create a Java-IDE I'd be done by now...).
Yep, PHP ones too. The largest project that I've ever worked on (which is built mostly out of C++, and has been around for 7 or 8 years) handles ~1200 requests per second. However, that's not what I do every day (nor is it what most people do every day...). I work on some of the most high traffic services on the internet, but not everything I do means millions of hits per day. Very few web sites even get a million unique visitors a day for the entire site, let alone a single service. IM networks are probably the most hit service in existance, and even those are only processing about 100 million requests a day.There are a lot of Java-apps out there that handle multiple millions of visits per day.
Sure, it'd be helpful, but the point here is that nobody's FORCED to use it when it's COMPLETELY UNNECESSARY. That's the *big* point here. There are certainly cases (although they're rare) where static typing can be useful, but forcing them across the board just slows the development cycle needlessly.I'm using this in every PHP-project I'm working on. I'm really glad they added this. Now, if they had only added type hinting for the return value and general variable types - I'd be happiest man ever.
Not at all. My point is that the kind of modularity that you get from these language features don't really make all that big of a difference, and that as long as you're using a good version control system you shouldn't have to worry about it all that much.Reread what you've answered this too... it's almost off-topic.
It's an issue, and I'm sure most people would welcome the change, but, like I said, thousands of apps have been developed in C for much longer than Java has been in existance and people seem to do just fine. It's a minor annoyance that usually hits you when you're integrating your project with someone else's code, but it's not really a deal breaker.It isn't? Really? Well... if you new how angry I was when PHP added SPL, you wouldn't say that. It is because of the lack of namespaces that one has to fight with stupid classnames like "PEAR_Whattheheck". Or, otherwise, having to fear that one day your code will break because you've been using classnames that PHP now uses for its own purpose. This breaks code and that is a serious issue.
And, again, it doesn't matter. The vast majority of function calls that I make in PHP are made to native C functions which are almost always FASTER than the Java equivilent. The speed gains here don't come at a place where it actually matters.And doesn't get the benefit of native compiled code, yepp. You might want to change your statement to: You can't bring that as an argument. PHP doesn't even get half the way where it would be worth to think about this stuff. Another answer of yours could be: Sorry, I don't know what I'm talking about.
See previous. Any case where you're going to see a huge difference here is rare, and even then if absolute speed is the most important thing to overall system performance(and it rarely is), then Java isn't really the answer, anyway.And let the Opcode be interpreted, instead of using native code once HotSpot detected it with Java.
"Capable" means that it has to actually do it in a reasonably useful manner so that you can continue your work (and using your system for other tasks, too...). sed can do a find and replace on your entire system, too, but that doesn't mean that it's something you'd want to do.They do... actually. Ok, they're processing them one after the other for this kind of task, but they'll go through all of your projects code and change it to represent the changes.
This is also how my own IDE will do this, too. It'll open all project files and try to apply the changes. Due to the nature of PHP this will be a really hard task as there are nearly no information about the types, but...
These are the cases where search and replace works just as well as anything else that you'll get out of a tool.Oh yeah... you don't use the "new" statement, don't you? And you've never renamed a method, right? And of course it wouldn't even come to your mind to change an object to a singleton. Modern IDE do all this for you with just a few refactorings...
Most of the "new" calls that I make in PHP are things like return new self; No changes necessary there...
Yep, it's true that better tools can make developers more productive, but at the end of the day PHP projects get done more quickly than Java ones, so I'd say that the relative merits of what's currently available don't seem to be making a whole lot of difference. All the thousands of people using emacs and vim seem to be pretty happy.Yeah... if you say that, you must be right. And I should stop my development right now. PHP-developers don't need an IDE that makes them productive. They never look back at their code once they wrote it and if it is necessary at all, they'll just start from scratch... oh boy... grow up, please.
There are features in Java IDEs you don't even dream about if you're pleased with Zend Studio.
Refactoring isn't really a whole lot different from one tool to the next. Help with declaration (what IDEs do for you) is nice, but not really that big of a deal, because most of your changes are in implementation, not declaration.
Which is pretty much what 99% of web applications are. The most complex things that you'll find in auction sites are the alert services that they export. Other than that, the performance characteristics are pretty well comparable to wikipedia because the end-product is essentially the same. A read-mostly database (10% writes / 90% reads for most sites of this nature is common. I've never worked for ebay specifically, but I've worked on similiar systems), and a bunch of html on the front end. The areas where complexity really comes into play are in terms of data analysis, which you're going to be doing "offline".I don't know about Yahoo, but Wikipedia certanly isn't a good example for a big website. Sure, it contains quite a few things in its database, but compared to eBay that's just a joke. Building a Wiki is something everyone with a year of coding experience could do easily. Take data from database, print it, be done. Really a complex application...
Not if you serve any significant amount of traffic. You can serve maybe 500k -1 million requests per day on a relatively powerful machine and an average application (say, a dual opteron with 4GB of RAM).think the time of large investments in hardware are gone Aren't performance questions getting less and less important (At least for Web applications)?
The usual BIG limiting factor is RAM before anything else. Once you run out of RAM, everything else goes because no CPU is fast enough to make disk access quick. Vertical scalability is available all the time, but it's extremely expensive (compare the price of a system with 16GB of RAM vs a machine with 4GB...it'll usually be 3-4 times the price of the base system, JUST for more RAM!) Certain types of servers (the blade variety, like sunfires) make vertical scalability a bit easier, but the base prices for these systems (a few thousand to several million) means that they're already ridiculosly more expensive than what you'll get with commodity hardware.
No, I speak from experience. It *IS* possible to do this with Java, but it doesn't work as well. It *IS* possible to do things differently with PHP, too, but nobody bothers because it's not a very good way to build web applications.The people at Zend make this argument you are of course just repeating it as you are a PHP fan-boy. But its a completely stupid argument. You can mirror this with java if you'd like...ahem its called making your application distributable. The difference is that java gives you the option of doing things otherwise...php does not. Furthermore you can use things like sticky sessions to deal with applications that are not distributable. You clearly are just repeated crap you've read.
Except that I do work with "big stuff". I'll be happy to tell you where I work in private if you must know, but I'd rather not have my opinions constituted as representative of the company that I work for.Oh this is the good old "I'm going to pretend like I work with big stuff...". Why repeat yourself? JUSTIFY what you say. If your app isn't distributable why can't the problems be solved via clustering? If it is distributable what is the problem?
Sure, that's why namespaces would be nice. Not critical, but nice.This solves nothing if you have two classes with the same name there will be a conflict.
I wouldn't expect anyone to memorize function signatures, I'd expect anybody to be able to look at the function signature and know what parameters are expected. In a few circumstances, it might be non-obvious, but you can always consult the documentation for that.Type hinting solves only a few problems and was already mentioned. Also in large code basis its usually the case that the types being passed are "non-obvious". Well at least that is the case for us without super memory that enables us to remember the signatures of 1000's of class libraries.
It's time spent that usually results in very little gain. It can certainly help in some instances, but most of the time you'd be better off with nothing changing.Why is the time required to compile hot stops to native code unacceptable in the context of a web app? You realize its just compiling small pieces of code right and takes very little time...
Not from any of the tests that I've run (and we use all those languages where I work). Yes, again, on specific x vs y benchmarks, you'll usually see better performance from perl and python (the typical math & io benchmarks that you see all over the web), but when it comes to the stuff that web apps actually do (very little math and all the IO is database or apache level stuff), things are very different. I wouldn't necessarily recommend PHP as the language of choice for implementing high performance statistical analysis tools, but I'll put money on PHP winning the day for the vast majority of web apps.I never said "php doesn't scale" rather dymanically typed languages make the management of large code basis difficult and therefore are hard to scale in that sense. And oh god....PHP is not "faster than the other scripting languages". Perl/python with respectively mod_perl and mod_python will perform better than php with mod_php.
And my point was that it's not really an issue with PHP. Maybe if you're using some boneheaded development strategy (like having 20 developers all working on the same module/library/whatever) it's an issue, but most code development is already modularized on a package / property / site specific level. PHP is especially easy to work with because dependencies are limited exclusively to what you actually use. Unit testing can be as simple as running PHP in lint mode.Oh geez...yes the "company you work for" <wink wink>. CVS/SVN are version control systems and have nothing to do with my point. My point rather was regarding the fact PHP makes it hard for large groups of developers to work on a large project, the reason for this has been stated many times already so I won't repeat it.
And yet PHP is the most common web development language out there. I wonder how all of us PHP developers have been getting by with "no" good tools available to us. Most seasoned develors that I see use one tool for every language. It slows them down to use something else. Hell, I personally disable the autocomplete crap in every IDE i've ever worked with because I find it more annoying and distracting than useful. Class / function browsers are helpful, but those work just fine with PHP already. I'll take dynamic typing over some lame IDE features every time.I disagree the lack of static typing makes it impossible to build good tools for the language. But this issue isn't unique to PHP, like the namespace issue.
I'd argue that PHP doesn't have as great a need for something like CPAN as perl does. More libraries never really hurt (unless they're bad...), but I'm not really seeing PHP developers clamoring for it, either.I did...and PERL and PECL aren't even close to what CPAN does for Perl.
I just want to say that I appreciate the exemplary class you bring to this discussion Etnu.
This discussion has turned from "which is faster" to "which is better"
I beleive that both of the questions are not practical; IMHO if you want to decide which language to use in a certain situation you will need to study that situation to decide which solution is going to be "better" or "faster" than other solutions because it depends on a lot of factors.
Flaming each other by criticizing both PHP and JAVA aren't going to help; both are not absolutely-perfect (not even dot-NET nor is C). The keen developer is the one who knows what to use after studying the requirements and the environment of the desired application.
I think its helpful so long as its not done stupidly for the most part the dicussion has been good, with the exception of a couple of people.Flaming each other by criticizing both PHP and JAVA aren't going to help
Yeah apparently this goes over your head....there are no packages in PHP!Maybe if you're using some boneheaded development strategy (like having 20 developers all working on the same module/library/whatever) it's an issue, but most code development is already modularized on a package / property / site specific level.
No you don't...you speak from another location on your lower back side. You've yet to justify yourself.No, I speak from experience. It *IS* possible to do this with Java, but it doesn't work as well. It *IS* possible to do things differently with PHP, too, but nobody bothers because it's not a very good way to build web applications.No they aren't they sare used when you want to have type-safe collections. pre java 1.5 you could easily "handle multiple data types", it just wasn't type-safe.Generics are used in any sitaution where you have to be able to handle multiple data types.
Ugh I cant read more of what you wrote..its too painful.
The lack of namespaces is one of the reasons PHP programmers don't ussualy use third-party frameworks.
Critical is a kind word here.
This is a BIG problem for PHP ... it is usually acting as a glue language for a C / C++ backend.
In fact, most (or even all) great examples where PHP "scales" invove a C++ backend ... examples like Yahoo.
With Java you have purity ... and even if the language is a little rigid, at least you don't have to drop to C code to be able to handle ~1200 requests per second.
This pretty much sums up your Java knowledge ... no offense.
Generics are for type-safety ... without generics you still have polimorphism, and with polimorphism you CAN have collections of multiple data types ... type-safety which cannot be enforced on PHP's arrays even if you want to ...
PHP-- && JAVA++
First of all, Emacs is bad example, as Emacs is an ***-kicking IDE that can work with code-completion and refactoring.
Second ... at the end of the day I find Java more productive, because ... if I want to build a quick processing form, I can always write a JSP with simple scriplets ... pretty much PHP style. And if I want to build a big application ... there is no platform out there with as many `good` frameworks as Java ... and within those frameworks, you can find the right approach that best suits your application.
I guess productivity is a matter of which language/platform you find the most familiar ... and I am more productive in Java, but you won't find me saying that PHP is less productive ... because that is only a matter of perception.
Yeah...I think this is something that PHP people don't get. But in the case of Yahoo etc they already had a backend written in C/C++ so it ends up working nicely. But its not like this is a unique feature of PHP...you could do it with Java, Perl etc.In fact, most (or even all) great examples where PHP "scales" invove a C++ backend ... examples like Yahoo.
I get the feeling of wasting my time... well.
Do you have any imagination of how hard it is to provide effective auto-completion for a PHP-IDE? I'm in the process of doing this right now. There are lots of cases where you're simply unable to guess the type of a variable. Lots of. Not only for the parser used by the IDE, but also for the human reading your code years after you wrote it (maintainance, that is). A few extra characters will decrease the possibility of passing a wrong type to a function (an IDE could easily check if you're passing something that looks just wrong into a method) and increase the readability.So does a sensible variable name. An object does NOT (in and of itself...) tell you a damn thing about what it can do. For that, you need to consult documentation and/or use an IDE that has some kind of intellisense-like support built in, and even then you'll still wind up consulting documentation most of the time.
Of course the documentation is important. Of course you'll look at it, but if you know what type an object has, you'll know lots of other things about it. Have you ever used Java or any other modern language with static typing?
You do not only gain readability and better tool-support, you'll also gain better protection of your code. It's just impossible to pass an object of wrong type to a method. Methods are forced to return the right objects. This is just way safer.
That's arguable again. But something I start noticing, might it be that you have C# experience? 'cause your "Java"-version looks like C#.Player GetPlayer(string PlayerName);
doesn't really tell you anything more than:
function GetPlayer($PlayerName);
(unless, of course, there's no documentation for either function, which is really quite silly).
Anyway. With the first version I know for sure that I'll get a Player-Object. There is no way I'd get something else. With the last one I can guess that I'll get a Player-object, but I can't be certain of that.
It get's more interesting if you have something like this:
In the client-code the Java-version will safe you even more keystrokes.Code:public void set(Player player); // against public function setPlayer($player);
Also, the PHP-version will force you to do a typecheck (except if you add the type-information to the method, but you don't want to do that anyway).
It occured to me that a softwares maintainance-phase is much longer than the initial development, thus lazyness can not be favored over readability and maintainability. The "marginal gain" will be much more important over time. Be sure of that.The limitations that static typing imposes on you are not justified by the marginal gain in "obviousness" of code. You can argue static typing as a performance advantage if you want, but the information provided is a pretty weak argument.
I wrote lots of Java-code and until now I have no idea what "limitation" you mean.
You'll overload the method to handle that type. You cannot handle a simple string with the same code as a complex type. But if you could you'd convert the complex object into the string (or vice-versa). Of course, this couldn't be done for PHP... it's not capable of overloading, thus you'd have to remove the typing information... but that's not a fault of static typing, but of PHP.What if I change from accepting a simple string to accepting a complex data type as well?
Well... in Java that won't matter. A Query will return an ResultSet-object, which is just an interface which defines methods. Of course you might have to change the code that works with the ResultSet, depending on the kind of change. There's no loss with static typing here. I'm sorry for you.What if I've switched database platforms and now I need to handle a different type of result set object in my abstraction layer?
Some people might refer to this as "OOP" or "Application design", but anyway...The most common solution to these sorts of problems in static languages is to have some type which is actually a wrapper around, or an alias to another type. In PHP, that's completely unnecessary. Refactoring is much, much simpler when you don't have to worry about data types.
Abstraction (you refer to it as "wrapper") is essential if you want to make your application flexible. Easy adoption and the like.
For example: In my PHP-IDE I'm using a set of interfaces that abstract the access to the filesystem. By doing this I can use the same code for interaction with an FTP-server and the local filesystem (and, while I'm at it, with every other filesystem that has an appropriate wrapper for my API). This is actually a big gain in flexibility, productivity (I only need to write the code once) and power (I can abstract low-level operations to a higher level easily).
You said that these variables are as meaningful as static typing. They're not, as I showed you.Yeah, maybe if you're completely clueless this would be a problem, but in practice it doesn't come up. The vast majority of your arguments are going to be primitive data types, and even those that aren't are going to be obvious if you write easy to read code. I could see this being an argument in an environment where you had no access to the documentation or no access to the code library that you're calling, but this is definitely not something that happens with PHP.
Searching the code of a libary might be the last possibility, but it's certainly not the first thing I think about. Actually, it's the last possibility I'd take.
On the primitive-thing: I have to disagree here, but I start to think we're just using a different development style. I prefer OOP. You seem to be happy with procedual code, that also explains why you won't want static typing and why you have no idea of how Java works.
Ok... so is 12.5 a valid value? I believe that is a number, but is it a legal value for that variable?It means a number. Any normal human being knows what a number is. PHP doesn't care what the actual data size is (nor is there any logical reason to in these scenerios).
Good joke.You'd only think that if you're a Java developer and insist on wrapping every primitive data type in an object that doesn't do anything but add complexity into the system. "Time to live" is a common term in computer science, and anybody who's programming would know what it is (except maybe a Java developer who thinks it should be a TimeInSeconds object which is derived from a NumericTimeRepresentationObject which is in turn built upon the base abstract Time class...)
No, I think it depends on what I want to represent with this thing.
If I wanted to have a higher level object, then I'd want this one to be a "Time"-object. That would provide access to the low-level data (the timestamp) and it'd offer me nice methods to work easier with this data.
But of course, if I knew this variable was a long and it had that variable name, I'd know it is a timestamp. Without the information about the type, I have to guess it.
And no, Java developers do not tend to be that ridiculous about abstraction.
We do abstract more than necessary, but that's fine because the code will scale very well.
I'd love to watch you manually updating a source-base with, say, 1000 files that have an average size of 200 lines of code.Unless you're adding more parameters (or removing some...), then you'll never have need to do so. And even then, manually changing a piece of code is hardly going to "break your neck". If you're refactoring something significantly enough so that changing the signature will actually break other code, then you've probably got a whole lot more to worry about.
On the code-breakage: This comes down to your style of coding. I, personally, even add methods to an interface as long as I have not published it as a "final". My APIs usually evolve over time, based on requirements. I think someone called that "bottom-up design". This principle produces best result for me (in combination with enough thoughts about the requirements and options before starting). Doing a refactoring is not much of a hazard with good tools, thus there is no need to not change a piece of code you just noticed as being crap. With no tool support you'll, of course, have to think about making the change twice.
See above.Sure, it'd be helpful, but the point here is that nobody's FORCED to use it when it's COMPLETELY UNNECESSARY. That's the *big* point here. There are certainly cases (although they're rare) where static typing can be useful, but forcing them across the board just slows the development cycle needlessly.
Something you'll do all the time if you're not going to reinvent the wheel every few minutes.It's a minor annoyance that usually hits you when you're integrating your project with someone else's code, but it's not really a deal breaker.
Native C functions are slower than processor-optimised assembler...And, again, it doesn't matter. The vast majority of function calls that I make in PHP are made to native C functions which are almost always FASTER than the Java equivilent. The speed gains here don't come at a place where it actually matters.
The question of this topic was "which is faster". Did you forget that?See previous. Any case where you're going to see a huge difference here is rare, and even then if absolute speed is the most important thing to overall system performance(and it rarely is), then Java isn't really the answer, anyway.
I have yet to see a PHP-IDE that supports refactorings at all. And for Java-IDEs: There are big differences in efficiency of refactorings.Refactoring isn't really a whole lot different from one tool to the next. Help with declaration (what IDEs do for you) is nice, but not really that big of a deal, because most of your changes are in implementation, not declaration.
With most PHP-IDEs I've tried so far, I would agree with you here. There implementations of Auto-completion is crap (and slow).Hell, I personally disable the autocomplete crap in every IDE i've ever worked with because I find it more annoying and distracting than useful.
But it can be a real time-saver. As an example: If I want to use the str_replace-function, I can just easily type "s_r<control SPACE>" in my IDE and it'll offer me str_replace (and a couple of other functions) as items. This turns out to be a real time-safer. Same holds true for class-methods (once I implemented the required parts). Instead of "getPlayer", you'll just type "gP<control SPACE>". This will save even more time if your method names are longer. If the IDE does it clever enough and know about the type of the object and has a cache so it doesn't need to parse the code all over again, then this can be done really fast and effective.
That's wrong perpective. It's speeds them up to use a good tool.It slows them down to use something else.
Because you don't know anything about these features you're talking about.I'll take dynamic typing over some lame IDE features every time.
Autocompletion is the most basic feature an IDE has to implement. There are tools far behond this. There are Java-IDEs that are smart enough to notice bugs in my code as I type it.
Still, I'm not arguing that Java is better than PHP. I like PHP, because I can easily put together simple applications and it's really cheap to host a PHP-application. Both are useful, both have its problems.
Virtually every system has components that they need to interact with that aren't in the language that you're working with. You wouldn't write these services in PHP, because it's just not the right tool for that sort of thing (databases, web servers, etc.)In fact, most (or even all) great examples where PHP "scales" invove a C++ backend ... examples like Yahoo.
The only C/C++ code that makes up any "backend" that I work with are those low level services, database connections and the like, and PHP extensions. You'll have the same things in any Java application. Sometimes the process that you connect to will be in Java, sometimes in C++, sometimes in some more esoteric language. Most of the time it's some old C or C++ library that's been in use for many years and you'll never have to think about it because you're only concerned with the interface that it exposes.
Now, if what you program involves some massive monolithing piece of code that does everything for your entire site (I've actually seen this at a few places...) in a single process, this might be a reasonable argument, but it's kind of silly otherwise.
Typesafe collections and recyclable routines. Say you want a comparison function for sorting (a > b ? a : b). Generics are a common use case here. This isn't limited entirely to type safe containers.The lack of namespaces is one of the reasons PHP programmers don't ussualy use third-party frameworks.
Critical is a kind word here.
This is a BIG problem for PHP ... it is usually acting as a glue language for a C / C++ backend.
In fact, most (or even all) great examples where PHP "scales" invove a C++ backend ... examples like Yahoo.
With Java you have purity ... and even if the language is a little rigid, at least you don't have to drop to C code to be able to handle ~1200 requests per second.
This pretty much sums up your Java knowledge ... no offense.
Generics are for type-safety ... without generics you still have polimorphism, and with polimorphism you CAN have collections of multiple data types ... type-safety which cannot be enforced on PHP's arrays even if you want to ...
PHP-- && JAVA++
You completely missed the point. People have been using the same tools for years, and IDEs don't make a big difference one way or another. Some of the best applications out there are written by people using nothing more than vim and gdb. You can add as many useful things to the tool as you want, but at the end of the day people using IDEs that support those features aren't creating projects any faster than people using plain text editors.First of all, Emacs is bad example, as Emacs is an ***-kicking IDE that can work with code-completion and refactoring.
If you pass the wrong data type into a function, the program probably won't work. Now, maybe you're the type of person that doesn't believe in testing code, but I find that unlikely. The vast majority of function calls that are made in a PHP application are passing primitive data types. It just isn't that big of a deal.Do you have any imagination of how hard it is to provide effective auto-completion for a PHP-IDE? I'm in the process of doing this right now. There are lots of cases where you're simply unable to guess the type of a variable. Lots of. Not only for the parser used by the IDE, but also for the human reading your code years after you wrote it (maintainance, that is). A few extra characters will decrease the possibility of passing a wrong type to a function (an IDE could easily check if you're passing something that looks just wrong into a method) and increase the readability.
It comes with an illusion of safety that comes with a huge price that just isn't worth it for web applications. Dynamic typing is the future, like it or not.You do not only gain readability and better tool-support, you'll also gain better protection of your code. It's just impossible to pass an object of wrong type to a method. Methods are forced to return the right objects. This is just way safer.
I work about 20/30/40/10 in C++, Javascript, PHP, and "other". C++ for the high performance back end services (shared memory caches and the like), Javascript for front end code, and PHP for all the application code. The "other" is mostly bash and perl. I've previously worked in Java, FoxPro, Python, and numerous proprietary scripting languages. I've never used C# outside of hobby projects.That's arguable again. But something I start noticing, might it be that you have C# experience? 'cause your "Java"-version looks like C#.
Anyway. With the first version I know for sure that I'll get a Player-Object. There is no way I'd get something else. With the last one I can guess that I'll get a Player-object, but I can't be certain of that.
Except that making a function named "set" suddenly makes your CALLING code impossible to follow. How much sense does this make?n the client-code the Java-version will safe you even more keystrokes.
obj.set(player);
What does that tell me? Compared to:
$obj->setPlayer($player);
Ahh...
Sure, if it really mattered. Sometimes it does, othertimes it doesn't. In the cases where it does (i.e. where there's a significant chance of the wrong data type being passed in), you just use type hinting. Most of the time you use duck typing to determine capabilities and/or check against multiple types and perform different actions depending on what the object can be interpreted as. It's quite powerful, and I can assure you that it's quite "safe".Also, the PHP-version will force you to do a typecheck (except if you add the type-information to the method, but you don't want to do that anyway).
Then you've clearly never used the full power of a modern dynamic language. If you don't "get it" now, I don't suppose you ever will.It occured to me that a softwares maintainance-phase is much longer than the initial development, thus lazyness can not be favored over readability and maintainability. The "marginal gain" will be much more important over time. Be sure of that.
I wrote lots of Java-code and until now I have no idea what "limitation" you mean.
This is not true in PHP.You'll overload the method to handle that type. You cannot handle a simple string with the same code as a complex type. But if you could you'd convert the complex object into the string (or vice-versa). Of course, this couldn't be done for PHP... it's not capable of overloading, thus you'd have to remove the typing information... but that's not a fault of static typing, but of PHP.
function setPlayer($player)
{
$this->playerName = (string)$player;
}
...
class Player
{
private $name;
function __toString()
{
return $this->name;
}
}
(simple example).
Beyond that, I can think of plenty of instances where you'd never have to modify the code. You can use interfaces and inheritance to achieve a limited sub-set of this power (both of which PHP supports, anyway...) but there's no replacement for full dynamism. And, again -- the choice is up to you.
Ideally, you'd get the same interfaces implemented in all compatable libraries, but we all know that in practice this isn't the case. If you can manage to get people creating client libraries for hundreds of seperate applications to all use the same interface, then you're a better person than I am.Well... in Java that won't matter. A Query will return an ResultSet-object, which is just an interface which defines methods. Of course you might have to change the code that works with the ResultSet, depending on the kind of change. There's no loss with static typing here. I'm sorry for you.
And I can do all of that with PHP, but it's just usually not actually necessary for the majority of the code being written. You only really have to enforce interface implementation on public methods (and even then, it's not that big of a deal to work around it). That's kind of the whole point being made. With Java, I'm forced into a specific paradigm. With PHP, I can choose the right development strategy for the job.Some people might refer to this as "OOP" or "Application design", but anyway...
Abstraction (you refer to it as "wrapper") is essential if you want to make your application flexible. Easy adoption and the like.
For example: In my PHP-IDE I'm using a set of interfaces that abstract the access to the filesystem. By doing this I can use the same code for interaction with an FTP-server and the local filesystem (and, while I'm at it, with every other filesystem that has an appropriate wrapper for my API). This is actually a big gain in flexibility, productivity (I only need to write the code once) and power (I can abstract low-level operations to a higher level easily).
99% of the code I write is dealing with objects. Time and time again, though, I see the same exact problems: exposing too much complexity at the public interface level is universally bad. The vast majority of routines only need to deal with strings, numbers, and basic container types (arrays, hashes, lists, etc.). In PHP, arrays are hashes, and they're a primitive data type.On the primitive-thing: I have to disagree here, but I start to think we're just using a different development style. I prefer OOP. You seem to be happy with procedual code, that also explains why you won't want static typing and why you have no idea of how Java works.
Something like:
function __construct($data)
{
$this->data = array_merge(self::$defaultData,$data);
}
is a whole lot easier to deal with than plucking off member variables of complex types. Could someone theoretically push junk data into the $data parameter? Absolutely! You shouldn't hire those types of people (or programmers who would blindly pass user data in, either...)
Yep. A number is a number is a number. declaring that something is an int, float, byte, or anything else doesn't tell me anything more than what size and format the data is in. It doesn't tell me anything else. Time in seconds? minutes? hours? Nope. Nothing at all. Of course, you could just name the variable $TimeInSeconds and solve that minor ambiguity as well. Viola.Ok... so is 12.5 a valid value? I believe that is a number, but is it a legal value for that variable?
I don't write code where you'd ever have to actually modify every single one of a thousand files to change ANYTHING. That's just bad, bad design.I'd love to watch you manually updating a source-base with, say, 1000 files that have an average size of 200 lines of code.
This is true of every API ever created.My APIs usually evolve over time, based on requirements.
Again, the tools you're referring to really only help you with declaration. If you have some magic IDE that's capable of turning a crap piece of code into a good one, I'd LOVE to see it.doing a refactoring is not much of a hazard with good tools, thus there is no need to not change a piece of code you just noticed as being crap. With no tool support you'll, of course, have to think about making the change twice.
I was referring to large scale integration (i.e. complete system integration). The PHP community has long since used the practice of prefixing (as has the c community...) for years. Like I said, we'd all welcome namespaces, but at the end of the day there's not much difference between ModuleName_ObjectName and ModuleName::ObjectName.Something you'll do all the time if you're not going to reinvent the wheel every few minutes.
What? Do you know what a compiler does? Java's advantage here is that you have to think less about optimizing (build once for all platforms), not that it builds "better" machine code. In practice, though, hardly anybody is ever writing code that's going to be used on more than a small handful of architectures (usually just x86). Call me when Java lets me do inline assembly if you want to talk about performance.Native C functions are slower than processor-optimised assembler...
And the whole point of this ongoing discussions is web application performance, not whether or not PHP is faster than Java in x,y, or z. It's already been pointed out numerous times that PHP sucks as a daemon and is even worse as a desktop application.The question of this topic was "which is faster". Did you forget that?
Not just for PHP; I found it especially annoying with visual studio. 99 times out of 100, I already know what the parameters are, and popping up some annoying little box every time I start typing is a surefire way to get me to use another product.I have yet to see a PHP-IDE that supports refactorings at all. And for Java-IDEs: There are big differences in efficiency of refactorings.
With most PHP-IDEs I've tried so far, I would agree with you here. There implementations of Auto-completion is crap (and slow).
Zend studio does that too. I can't say I've ever found popping up a menu in the middle of typing be useful. Macros, on the other hand, can be useful, but every text editor on the planet has macro capabilites.can just easily type "s_r<control SPACE>" in my IDE and it'll offer me str_replace (and a couple of other functions) as items.
Yeah, that's why they use vim. It's a great tool.That's wrong perpective. It's speeds them up to use a good tool.
And you clearly don't know anything about dynamic typing.Because you don't know anything about these features you're talking about.
Yargh. I've heard that claim before, and I've yet to see an IDE that actually achieves anything like this (for ANY language) in any meaningful way. The best they can usually do is trap = vs == and other things of that nature. The technology just isn't good enough to get people to move away from what they're already comfortable and proficient with.There are Java-IDEs that are smart enough to notice bugs in my code as I type it.
What Schlossnagle is commenting on (in the blog entry referred to in the beginning of this thread) is lack of perspective: PHP vs. Java is not the difference that will make the difference to how fast an application performs, and yet too many programmers like to believe that it is. Others have said similar things in this thread.
It goes beyond even that. Why do we want to optimize? Are we trying to reduce server load or minimize user response time? If user response time is the issue, perhaps the most effective thing we can do is to change the user interface so that the user can get the same result with fewer explicit actions. By limiting our thinking to one narrow technical perspective, we prevent ourselves from seeing this.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Take a look at IntelliJ IDEA. It tells me about possible null-pointer bugs, about missing resources, about coding-style violations, about wrong algorithms, wrong usage of variables, about... well. It actually has more than 500 inspections to watch me doing my job right.
It even tells me if the code I wrote isn't thread-safe or if I don't close a resource.
Really? The last time I tried it, it couldn't. But then, that's a few versions back.Zend studio does that too.
You noticed yourself that both versions tell you exactly the same, didn't you?Except that making a function named "set" suddenly makes your CALLING code impossible to follow. How much sense does this make?
obj.set(player);
What does that tell me? Compared to:
$obj->setPlayer($player);
Ahh...
I've used PHP, Python and even some Ruby. Also I wrote quite a few things in Javascript. Then I wrote a few things in Groovy and Beanshell (Scripting language for Java with Java-syntax) does support dynamic typing, too...Then you've clearly never used the full power of a modern dynamic language. If you don't "get it" now, I don't suppose you ever will.
I'm quite sure that I did enough black magic in any of them to know that dynamic typing can be useful, but it comes with a cost and that's something I wouldn't accept for a real application that has to work reliable and has to be maintained.
Here's the Java-version:This is not true in PHP.
But then, what could you possibly do with the string representation of a player? You would loose all those information the Player-object has to offer.Code:public void setPlayer(Object player) { this.player = player.toString(); }
Of course you could pass everything in there... you could pass an int, a float, a string some object and a player, but I don't see the logic behind this.
The interface-implementation of PHP is... a joke at best. It's far from being usable.You can use interfaces and inheritance to achieve a limited sub-set of this power (both of which PHP supports, anyway...) but there's no replacement for full dynamism. And, again -- the choice is up to you.
Would map to:Something like:
function __construct($data)
{
$this->data = array_merge(self::$defaultData,$data);
}
is a whole lot easier to deal with than plucking off member variables of complex types. Could someone theoretically push junk data into the $data parameter? Absolutely! You shouldn't hire those types of people (or programmers who would blindly pass user data in, either...)
Congrats, you've saved a line (except I write an Utility-function...Code:public ClassName(Collection data) { this.data = data; data.addAll(defaultData); }
Funny, that happens for me for almost every project I'm working on. The DB-Abstraction-code, for example. Or configuration-stuff, or the classes to provide me with translations for internationalization.I don't write code where you'd ever have to actually modify every single one of a thousand files to change ANYTHING. That's just bad, bad design.
Oh... and that's true for both, PHP and Java.
Try IDEA.Again, the tools you're referring to really only help you with declaration. If you have some magic IDE that's capable of turning a crap piece of code into a good one, I'd LOVE to see it.
You mean like copying inlineable methods into another method? That's there since 1.3 as far as I know.Call me when Java lets me do inline assembly if you want to talk about performance.
The compiler must optimize the code for the least common determinator. Java can optimize the code for the actual platform, thus achieving better results (in some cases, though).What? Do you know what a compiler does? Java's advantage here is that you have to think less about optimizing (build once for all platforms), not that it builds "better" machine code.
Yeah. I don't like that type of auto-completion, too. If I need it, I'll ask my IDE for it and not the other way around. I disable that automatic opening myself.Not just for PHP; I found it especially annoying with visual studio. 99 times out of 100, I already know what the parameters are, and popping up some annoying little box every time I start typing is a surefire way to get me to use another product.
Sure, but they differ in power of implementation. IDEA (and I believe this is true for Eclipse as well) can guess what variable you'd like to use in your macro. Really cool.Macros, on the other hand, can be useful, but every text editor on the planet has macro capabilites.
I know one guy who used to use Vi, but recently switched to IDEA. He's happy about that because IDEA makes him even more productive.Yeah, that's why they use vim. It's a great tool.
I know about dynamic typing, about duck typing, about all these things. It's just that I prefer static typing because I've seen it working for me.And you clearly don't know anything about dynamic typing.
But then, this discussion is pretty pointless. PHP is fast enough. Static and dynamic typing has been discussed numerous times and it's clear both have good and bad sides. Personal preference, I guess.
If you want to know how good JAVA is, even running on SUN servers, contact the banks in Brazil, if you can. Ask them what they think of it. Look, NOBODY - even a few years ago - could tell you if JAVA was a program, an operating system, a server or a whole different language.
JAVA is just like Apple, IBM and Digital. They were very fast when they first came forward, sold it to everybody, got arrogant and then hit the skids on their "laurels". Even Bill Gates lost his penchant for "open source" after winning the case against IMB for DOS.
If you know anything about this industry, you know that SUN is a dead man walking, and JAVA genius will just be parted out to other folks. What do you think Oracle and Cisco are riding on? Their previous sales, not their new ones.
We went Open Source a long time ago and recommend it to our clients who seem to pay more attention to what they are spending these days - like everybody. You can do the Mandelbot Fractals all you want...Nobody really cares unless you have stable programs that give them the results they need to conduct business. LAMP can do that at a fraction of the cost and is completely enterprise capable.
So what do you do now without the support of a global programming community and the money from locked-in clients who have found that JAVA support is not only unmanageable but transient? Tell them to buy MacIntosh, I suppose, and join the swelling force of fools who really think they are making a personal identity statement by purchasing a computer like they do an automobile.
TheDragonMaster, I'll be very quick: it's not about whether PHP is better than Java or vice-versa. They follow two different philosophies.
That being said, note that there is only one advantage which static typing provides over dynamic typing, and that is IDE-friendliness. And I never found that advantage so compelling, compared to the speed of development and ease of maintenance provided by the combination of unit-testing, duck typing and dynamic variables.
And I'm not talking about PHP and Java -- I've worked in Java, C and C++ on one side, and Javascript, PHP, Python and Ruby on the other, so I know what I'm talking about.
Static vs. dynamic type debate is pretty much obsolete nowadays. More modern languages than php or java already offer satisfactory tradeoffs like "dynamic strict typing" or type inference.
Zend studio still sucks...I have the most recent version. They still haven't even added good cvs/subversion support yet. Its debugger is the only thing that is worth its salt.Really? The last time I tried it, it couldn't. But then, that's a few versions back.
Cute...you say this like its actually true! Other advantages of static typing have been mentioned in this post..why not explain why they aren't actually advantages? I've yet to hear one person say things like this that have actually worked on large projects.That being said, note that there is only one advantage which static typing provides over dynamic typing, and that is IDE-friendliness.
Yes yes of course...name one popular language that doesn't use either static typing or dymanic typing? Try also looking into the research journals on programming languages...you'll find all sorts of stuff written on typing, proof carrying code, program verification etc. The latter two involves things that are like typing on steroids. That is to say...in the real world things are not moving away from things like static typing.Static vs. dynamic type debate is pretty much obsolete nowadays.
@Berislav: If I remember it right, I've said in every of my post that none is better than the other... in every single post, just so no one could have a chance to say I had said otherwise.I'll be very quick: it's not about whether PHP is better than Java or vice-versa. They follow two different philosophies.
If I said I liked (or prefered) one more than the other, than I clearly stated that this was my personal preference - as is with static typing (look at my last post).
I really hope you just misread my posts or did not see these statements, 'cause it definitivly wasn't my goal to say PHP was bad or anything like that. I'm using it since quite a long time and I'm happy with what I can do with it, so there is no reason for me to claim it was bad (except for a few problems, but from what I can tell every language has its problems). And I also said that it is fast enough.
So, where's your problem? I got arguments and examples, I responded with the same - while clearly stating I wasn't going to say any is better than the other.
From what I can tell this is called a "discussion". Then, again, discussions are not made up by commands, so please try to use arguments instead of things like "And now note this and that and be quiet!", 'cause that is, how your comment appears to me.
But then, I think it doesn't matter anyway. I've made my point and that shall be enough.
Posting Permissions
Bookmarks