SitePoint Sponsor

User Tag List

Page 3 of 8 FirstFirst 1234567 ... LastLast
Results 51 to 75 of 190
  1. #51
    l º 0 º l silver trophybronze trophy lo0ol's Avatar
    Join Date
    Aug 2002
    Location
    Palo Alto
    Posts
    5,329
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ShytKicka
    Whoever argues in this topic about either language, is not a successful developer, I'll tell you that.
    Only ColdFusion developers would say something like THAT in an attempt to make up for their language's own shortcomings. Just kidding.

    People need to chill. Different strokes for different folks, and all that jazz.
    .
    Zach Holman
    good-tutorials — blog — twitter — last.fm

  2. #52
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You shouldn't care too much about types.
    I care about static typing...for many reasons that have already been stated.
    What happens if you want to rename a class? Static typing is obviously bad for maintainance.
    What happens is you click the "refactor" button and click "rename" and the IDE you are using renames all instances of that class in your project to the new name. Dymanically typed languages don't avoid this issue....
    No, there is a nearly complete working patch available at that site.
    "Nearly complete" in other words its not complete and can't be used in product code. PHP still lacks namespaces.
    There was a presentation of ruby on rails. One rewrote his java app in ruby, and guess what? It was faster.
    These sorts of things are meaningless. Was the java implementation done well? etc. Also do you have a reference to this result? If not...why bother?
    really hope APC will be standard in PHP 6. There is no reason for it not to be.
    There is one reason it should not be...Zend wants to make Money off its stupid "Zend Platform". This is one reason I dont' use PHP much....to get nice features (that are stable) you have to get the Zend Platform. Where as other technologies (servlets, mod_perl, mod_python) etc you get it all for $0.

  3. #53
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > There was a presentation of ruby on rails. One rewrote his java app in ruby, and guess what? It was
    > faster.

    I don't believe that for one minute. It's doubtful at best, considering the current release version of Ruby On Rails at the moment, and the numerous issues such as performance on speed for one.

    Besides, to compare one platform against another is rudimentory at best, since there are just too many variables to take into consideration between those platforms.

  4. #54
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ikeo
    Can you prove this.
    Sure, just run a test that loops through infinitely and allocate / free memory (drop refcounts using null assignment), and notice how memory doesn't get freed very quickly. There are also many memory leaks that create all sorts of problems. In a web app, it really doesn't matter (the context only lives for a fraction of a second), but in a daemon it's a killer. This is a known limitation of the PHP engine, and it's not likely something that's going to be fixed anytime in the near term.

    I've done some reading on this, and from what I understand JIT would help Java perform better than PHP because PHP is interpreted (after being compiled to Zend opcode).

    read this and let me know what you think
    Like I said, in theory a JRE should be able to run faster, but in practice it doesn't. The main reason is because of all the extra overhead that the JRE has to carry around with it throughout the process.

    What the hell are you even talking about? In java any code that becomes "hot" will be compiled to native code. Whether that code is running a web application or desktop app simply doesn't matter.
    Because the time required to compile to native code is unacceptable in the context of a web app. JIT is nice in theory, but in practice it never lives up to it's expectations. That's why we're seeing emergence of things like compile on install, like what you get with .Net.

    google.com - Anybody that denies that Java as a language is faster than PHP is a mindless fan-boy of PHP. ...hell try writing any NON-TRIVIAL algorithm in PHP and Java and see which which does better. PHP can solve some of its performance problems by outsourcing its work to C via an extension though. PHP is just not in the same class as Java, compare it to Perl, Python etc.
    Google uses Java for some of their apps (and python, and perl, and, from what i've been told, even some PHP), but their search engine is most certainly not built in Java. Yahoo, however (which gets much more traffic than google on a daily basis) is mostly built on PHP (although extensions are used...extensively). Yes, on a straight algorithm vs. algorithm basis, Java will beat PHP in most circumstances -- but anybody who's actually developed a real application knows that you can't use that as a basis for comparison.

    Sure they have advantages...one of the advantages NOT being scalability. And...hmm..call me crazy but I'd imagine that a variables Data type would indicate something namely its data-type =).
    If you don't think PHP applications are scalable, you're just plain wrong. Wikipedia, yahoo, flickr, etc. -- all built with PHP. I work with large scale, high performance, extremely high scalability systems every day, and scripting languages have a huge advantage here due to the fact that you can always just toss more instances at the problem. It works every time. PHP just happens to be better than most because it runs faster than the other popular scripting languages.

    Again, what does data type tell me about an object? Absolutely nothing. In fact, it can be a hindrance because now when I want to change my data type later, I'm stuck having to manually go through my code to adjust.

    Statically typed languages have to resort to nasty hacks like generics to solve the problem.

    Adding typing information to variable names makes things really ugly. Furthermore if you have to add typing information to the variable names and/or document how does this imply less work?
    I never said "add typing information". I said "use sensible variable names". That means names like "PlayerName" or "NumberOfIterations" or "TimeToLive". You could do something like this in a statically typed language:

    void StartTimer(int ttl);
    void StartTimer(time_t ttl);
    void StartTimer(float ttl);

    or, perhaps:

    template<typename T> void StartTimer(T ttl); (assuming you're using a statically typed language that has actually at least implemented generics, of course...)

    etc.

    In php, you'd never have to change that function signature.

    If you have a case where you REALLY think that the type of data requested is going to be non-obvious (and you can't be bothered to add comments to the function signature), PHP supports type hinting:

    function CompareTwoObjs(MyObj $Obj1, MyObj $Obj2);

    as well as various functions for comparing data types.

    Again, no FORCING of static typing on anybody.

    Have you actually worked with java web applications AT ALL?
    Yes. And I don't deal with apps that just run on one server. The apps I write are built to be cross colo, multi-server applications designed to handle millions of unique visitors every month. I can say with absolute certainty that what we do where I work gets more traffic than what you do where you work. You CAN'T just scale a java app by throwing more hardware at it, but time and time again it's been shown that you can do that with many PHP apps (not all, of course, since database dependencies and such can bite you, but there are plenty that do just that).

    Large web applications have thousands and thousands of source files being worked on by many people....there is no sensible way to manage this with PHP.
    You don't manage source with PHP, you manage it with CVS (or SVN or Perforce, if you prefer). I can assure you that the thousands of PHP source files that the company I work for has in our CVS repository work just fine for us.

    don't see how a platform that has "pretty terrible" garbage collection can possibly excel as a general-purpose scripting language. "General-purpose" means that you may not be dealing with short-lived requests and environments that are being tossed out rapidly.
    You're confusing general purpose language with general purpose *SCRIPTING* language. Java, C, and C++ are general purpose languages. When I say scripts I'm talking about scripts in the literal sense -- bits of code that perform simple, quick tasks, then exit. PHP serves as a fine replacement for Perl or Bash in almost all cases.

    My personal opinion is that the lack of namespaces in PHP makes encapsulation at a library-level difficult and discourages the development and sharing of generic classes and class libraries.
    Yes, PHP's lack of namespaces is annoying, but it's hardly as crippling as some people make it sound. C (NOT C++!) doesn't support namespaces either, but it's used by thousands of developers around the world on thousands of projects (and is much older than any of the languages being discussed).

    [offtopic]
    Actually, I've seen it stated that Ruby scripts are currently not compiled to bytecode/machine language, but are converted into an abstract syntax tree and interpreted. So, it could be argued that Ruby isn't compiled.
    a rose by any other name...The compilation method differs from others, but it's still a case of converting a language into a simplified representation and then passing it into a machine that can interpret those commands (directly to the processor, into a VM, etc.) [/offtopic]

    as memory is so cheap
    Memory is only "cheap" under a few circumstances. If you're dealing with sunfires or such, then adding more ram is generally not a big deal, but that type of hardware is so overpriced as a whole that it really doesn't make the RAM "cheap". To achieve the high levels of scalability demanded by many of today's web sites (e.g. google, yahoo, etc.), you're dealing with a commodity hardware paradigm. 2GB or 4GB of RAM is fairly cheap, but most of these machines are limited to 4 or 8 memory banks, and RAM is exponetially more expensive the larger your modules are. There's very little sense in putting 16GB of RAM into a box like this when that extra 12GB cost you twice as much as it would to add another server. That's why they don't do it.

    I'm not sure what you are talking about here, explain?
    __autoload + auto_prepend_file directive can make it so that you never really have to worry about where your classes come from.

    PHP's arrays are not universally loved.
    The only real case where they cause problems tends to be when you need to do array merges, though. PHP's other conventions make it so that it's an ideal system. For most stuff that you'd use PHP for, maps make much more sense than arrays. I wouldn't be opposed to seeing a purely indexed array added, but I'd also be willing to bet that it'd get very, very little use.

    Quote Originally Posted by bonefry
    For those who say Java uses a lot of memory ... think about mobile applications.
    Oh, Java does use a lot of memory on mobile applications. That's why writing mobile apps is such a pain in the butt. The ONLY reason for Java's success on mobile devices is because writing portable C code for what is literally thousands of different architectures would be nearly impossible.

    JAVA beats the living crap out of PHP, when it comes to performance, for the following reasons:

    1) The Hotspot JVM knows about "adaptive optimizations" ... something that even the .NET CLR doesn't have yet
    And, again, something that doesn't matter to PHP because it's tearing down the app every view.

    2) PHP, being so crapy, is recompiled at every request, so that Zend can make a living
    Or you can just do what everyone who knows anything about PHP does and use APC.

    3) The cost of a new process is higher than the cost of a new thread
    Not by much on linux or freeBSD, and the overhead of locking usually far outweighs the overhead of extra processes. Threading is usually only advantageous when you need to do a lot of inter-process communication on these systems. Aside from that, PHP *IS* thread safe (at least in all the core libraries, some extensions aren't), and works perfectly fine with apache's MPMs.

    4) The JAVA language can be optimized very efficiently because it is a static language
    In theory, yes, in practice it makes very little difference for the types of applications you'd use PHP for. Yes, Java would trounce PHP-GTK for desktop development, and Java would smoke PHP for long-lived server processes, but otherwise it makes little to no difference.

    5) A LAMP setup doesn't have stuff like connection-pooling by default
    Lots of things don't exist by default.

    For those who say that PHP is more scalable that JAVA ... PHP is scalable because of its mediocrity
    Uhm...right.
    ... and tell me ... what infrastructure does PHP provide for distributed applications ?
    Are you talking about distributed as in load balancing or distributed as in package distribution? For the former, it doesn't need it, and for the latter you've got PEAR, PECL, or, well, any package management utility, since PHP doesn't require any kind of application registration or other such nonsense. You copy files to where they need to go and you're done.

    Anyone that says otherwise is clearly wrong, ignorant or religios about it.
    Except for when they're right. Web sites using PHP (big ones like Yahoo and Wikipedia) continually demonstrate lower hardware costs than Java based ones (Amazon being the nearest compatable site in terms of size off the top of my head). If Java is superior in performance, then why doesn't that show up in practice? You could possibly argue that Yahoo and Wikipedia have far better engineers than Amazon, but I'm pretty familiar with people working at these organizations and I can assure you that it isn't the case.

    This thread is useless as it clearly leads to a flamewar ... because of fan-boys that can't accept the limitations of a scripting language ... and thus they bash a technology they do not use or know.
    If you want productivity, then PHP may be the answer for you, but if you want performance ... with PHP it is like looking against the SUN
    How about the fan-boys that can't accept the fact that a scripting language can trounce a compiled language, even when the evidence is right there in front of them? No, in the "general sense" PHP isn't faster than Java, but for the things you use PHP for, it is.

    In fact, PHP cannot scale too well precisely because of its shared-nothing architecture
    You've got that completely backwards, friend. If you actually want to explain why you don't believe this to be true, go ahead, but anybody who's actually dealt with situations where hundreds of requests per second are being thrown at an app can tell you that the "shared nothing" architecture works like a dream.

    Why wouldn't they? Part of what makes a application scalable is its ability to deal with large development teams, large code bases etc. Which language used clearly effects this...
    Large development teams always lead to slow development. You break your project up into small, managable teams and put everything under source control.

    Your point is just myopic. Please look at what it takes to implement a regular expression engine (and regular expressions are used ALLLL over the place in web apps). When you start writing non-trivial web applications you'll find that there are no longer PHP extensions to do all the hard work for you.
    I write plenty of "non-trivial" web applications, and, while there are certainly some things that PHP doesn't do well, It's pretty rare to encounter a situation where there isn't already an extension to do the hard work for you. The only cases where I can recall in recent memory where there weren't good solutions in PHP was when I had to interface with external services that were being provided through some low level system (shared memory transports and the like). Most people on this forum will NEVER have to deal with these types of issues.

    Well the site clearly states why php should have namespaces...but they don't offer a solution they offer ideas on how a solution would look like. I mean they clearly state what they are doing is for demonstration. Namespaces are the sorts of things that need to be added to the language itself.
    Actually, they do offer a solution (and it works), it just hasn't been made a part of PHP yet due to some performance issues that are still being sorted out. Most likely no decision will be finalized until PHP6 and all the unicode changes have been finalized.

    But just one question ... is Java and PHP comparable?
    For some applications (we're discussing web apps, specifically here)

    similerly is it fare to compare Zend Vs. SUN?
    Not at all.

    The only thing that is obvious is that you have no experience with modern statically-typed languages, and are speaking from ignorance. Static typing makes renaming classes, methods, constants, etc. easier because tools such as IDEs can perform static analysis on your code and know 100% that all references have been updated.
    Except that you rarely, if ever, control all the code that you're working with. It's the old "binary compatability" problem. I'd love it if there was an IDE capable of actually loading 1000+ files at once and doing find and replace on them all.

    In Eclipse you select an identifier, hit ALT-R, type in the new name, and you are done. ALL references in your project are updated automatically. No regular expression search and replaces required. And this is possible precisely because of the information that static typing provides the tool.
    Actually, this tool does use regexes to update. It just changes the source code. Just because you don't have to manually type in a regex doesn't mean that's not what's happening.

    Dynamically typed languages make such refactorings much more difficult.
    They would, if it weren't for the fact that you don't need to do it in the first place because you don't declare type.

    Since PHP (and other dynamic languages) allows you to store the names of classes, methods, etc. as strings and invoke them that way even the most inclusive regex can't gaurantee that all references are updated.
    Nope, and in Java you can't do that AT ALL (well, you kind of can with reflection, but that has the same limitations that you just mentioned). What's your point?

    Simply put, if you have never used a modern IDE with a statically typed language such as C# or Java then you have no idea what static typing makes possible regarding tool support.
    Because you *DON'T NEED IT* in PHP. The most useful tool that most IDEs provide is autocomplete (intellisense, if you will) and module / function / class heirarchy management. Both eclipse and zend studio do this just fine for PHP.

    Why is it some of the largest enterprise web applications are written in Java? Power and Scalabilty! Look at Ebay, UPS, Fedex, PetsMart (I could go on for ever) .... I have yet to see an honest to god enterprise level application written in PHP ...... PLEASE show me one!
    Wikipedia, Yahoo, etc...all mentioned already (and lets not even get into all the usage of C/C++, perl, and python). Maybe you should have read the whole thread before you commented. Java got sold to enterprise customers because Sun marketing people pushed it at the same time that they were pushing hardware, so it caught on.

    WHAT STARTUP COSTS!
    Nobody's discussing money here. We're talking about startup cost in the performance sense. Again, read the whole thread.

    PHP is fine for this type stuff, it's easy to write (usually) and works fast enough. BUT when I need a massive app that has to be able to do anything I need in any way shape or form I go to Java.
    And this ENTIRE THREAD has been about web apps. Nobody's trying to argue that PHP is faster than Java in the traditional application space. I'd also question the wisdom of ever creating a "massive app", in any language, on any platform, for any purpose.

    There is one reason it should not be...Zend wants to make Money off its stupid "Zend Platform". This is one reason I dont' use PHP much....to get nice features (that are stable) you have to get the Zend Platform.
    Funny, I've never used Zend's products outside of the evaluation period (some of their tools are alright, most of them aren't really worth the money in my opinion), and I can't think of a single "nice feature" that they have that I don't currently have in a stable form.

  5. #55
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    Actually, this tool does use regexes to update. It just changes the source code. Just because you don't have to manually type in a regex doesn't mean that's not what's happening.
    No, as I stated, rename refactoring is accomplished via static-analysis of the soure code. The static-typing information makes it possible to know for certain at compile time the types of each variable, and where each type and method are referenced. In Eclipse, regular expressions are only used if you choose the option to "Update textual matches in comments and strings" or to "Update fully qualified name in non-Java files". In fact, because these things are inexact, the refactoring tool forces you to preview the changes before they are made. But changes to the actual code are not updated via regexes. If you have reason to believe they are, please back up your assertion.

  6. #56
    SitePoint Evangelist ikeo's Avatar
    Join Date
    Oct 2004
    Location
    Austin Texas
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Holy crap Etnu! You can't be human!
    I am so glad to be seating at the feet of obviously smarter more experienced developers ... who don't even know I'm there :]

    I had a few questions about some things you've posted.

    You said PHP uses Reference counting, I looked over it briefly in Wikipedia and it is supposed to be faster in theory since once an object is no longer referenced it is reclaimed .... Is it that Zend just does a bad implementation of it in their garbage collector for PHP?

    - In regards to static vs Dynamically typed languages I think this amounts to a Holy war. It is clear that both have their benefits, I think in a web environment dynamic typing wins out? I've been doing a lot of code in ASP.NET (C#) and being forced to declare type just seems like a hassle with no true reward for my trouble.

    Question to Etnu: Don't you think PHP would benefit from being able to switch between being able to check types and the old fashioned way of just making a best-guess conversion? Just something like an application variable you could turn on or off.


    You don't manage source with PHP, you manage it with CVS (or SVN or Perforce, if you prefer). I can assure you that the thousands of PHP source files that the company I work for has in our CVS repository work just fine for us.
    I'm interested to see what Snailly will say on this.



    Yes, PHP's lack of namespaces is annoying, but it's hardly as crippling as some people make it sound. C (NOT C++!) doesn't support namespaces either, but it's used by thousands of developers around the world on thousands of projects (and is much older than any of the languages being discussed).
    Great point ... I hadn't thought about that.



    Not by much on linux or freeBSD, and the overhead of locking usually far outweighs the overhead of extra processes. Threading is usually only advantageous when you need to do a lot of inter-process communication on these systems. Aside from that, PHP *IS* thread safe (at least in all the core libraries, some extensions aren't), and works perfectly fine with apache's MPMs.
    This contrasts with what Jonas Maurus says here ...
    PHP isn’t thread-safe
    PHP 4 and 5 can only be used with Apache2’s mpm_prefork model, not with mpm_worker. That means that PHP limits your performance choices with the Apache HTTP-server. It seems that it can be used with mpm_worker by not using the mod_php plug-in directly, but by using FastCGI.
    How say you?


    How about the fan-boys that can't accept the fact that a scripting language can trounce a compiled language, even when the evidence is right there in front of them? No, in the "general sense" PHP isn't faster than Java, but for the things you use PHP for, it is.
    Just from the back and forth on this thread and anecdotal evidence from surfing Yahoo, Flicker, Sun, ebay et al. I think their speed is just about even, which of course (for the pro-PHPsters) sounds like a win for PHP, since Java is (theoretically) supposed to wipe the floor with it.




    You've got that completely backwards, friend. If you actually want to explain why you don't believe this to be true, go ahead, but anybody who's actually dealt with situations where hundreds of requests per second are being thrown at an app can tell you that the "shared nothing" architecture works like a dream.
    I'd honestly like to see a bit more detail from both sides about this. I understand PHPs "shared nothing" architecture but I don't see why it would help it scale or not (forgive me if I sound naive ... around here I am)
    Last edited by ikeo; Feb 26, 2006 at 02:43.

  7. #57
    SitePoint Evangelist ikeo's Avatar
    Join Date
    Oct 2004
    Location
    Austin Texas
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That was a lousy read. It was dated, the guy didn't know anything about Java and it showed.

    Quote Originally Posted by sysice
    Oh JOY, arguements about what languages is the best never really get anywhere.

    Paul Graham talks a lot about language, and of course he will side towards Lisp, but here is an interesting piece about Java.

    http://www.paulgraham.com/javacover.html

    This whole thing reminds me of the Mythbusters episode where they put the toy car against the real car. Over 100 feet the toy car was faster, but over 400 feet it was slower. It really comes down to the specifics of what you are measuring to determine if one is faster then the other.

  8. #58
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ikeo
    Holy crap Etnu! You can't be human!
    I am so glad to be seating at the feet of obviously smarter more experienced developers ... who don't even know I'm there :]

    I had a few questions about some things you've posted.

    You said PHP uses Reference counting, I looked over it briefly in Wikipedia and it is supposed to be faster in theory since once an object is no longer referenced it is reclaimed .... Is it that Zend just does a bad implementation of it in their garbage collector for PHP?
    The garbage collector is crap. But it doesn't really matter, and nobody cares unless they're trying to write daemon processes in PHP for the most part, because when the process is finished, everything is "garbage collected". Yes, refcounting is fast, but it's also error prone (see the microsoft DOM implementation for IE...). Regardless of the GC methodology being used, nothing is effective if your GC is crap the whole way through.

    - In regards to static vs Dynamically typed languages I think this amounts to a Holy war. It is clear that both have their benefits, I think in a web environment dynamic typing wins out? I've been doing a lot of code in ASP.NET (C#) and being forced to declare type just seems like a hassle with no true reward for my trouble.
    Static typing is important for micro-optimization and situations where expected data types can be ambiguous. PHP solves the latter problem by way of type hinting.

    Question to Etnu: Don't you think PHP would benefit from being able to switch between being able to check types and the old fashioned way of just making a best-guess conversion? Just something like an application variable you could turn on or off.
    It does and can. It's called type hinting.

    This contrasts with what Jonas Maurus says here ...

    How say you?
    PHP is thread safe, some extensions are not. Look up ZTSRM (Zend Thread-Safe Resource Manager) for more details. Most experienced people will tell you that on a linux or bsd box, though, you're better off spawning more processes instead of threads for this sort of task.

    I'd honestly like to see a bit more detail from both sides about this. I understand PHPs "shared nothing" architecture but I don't see why it would help it scale or not (forgive me if I sound naive ... around here I am)
    Simple, if the process doesn't have to share anything, and it's all torn down between requests, then you have a situation where scalability is simply a matter of having more processes available to handle requests. No worries about communication between systems of any sort. In other words, it's a whole lot easier to spread the load across multiple machines. Now, obviously this is a huge oversimplification (you'll ALWAYS have other bottlenecks in any app), but it does ensure that PHP will rarely (if ever) be your bottleneck. This approach would never work for most traditional applications, but it works perfectly for the web.

    I hate to bring it up again, but it has to be said: Friendster.

  9. #59
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not wanting to go off topic, nor am I looking for an arguement, but...

    > In fact, it can be a hindrance because now when I want to change my data type later, I'm stuck
    > having to manually go through my code to adjust.

    You would not have to do that in the event you are using PHP5? If you are using PHP5 you should be developing with Interfaces in my view; While not entirely removing the problem, you would find that you have more scope and options if you were to use Interfaces.

    If you are using Interfaces, and you still are having trouble, then I can only imagine that either you are not using Interfaces properly, or that your not taking the full advantage of what Interfaces offer the developer

    Good post btw...

  10. #60
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh god...


    Well, Etnu, let me help you a bit, yeah?
    Like I said, in theory a JRE should be able to run faster, but in practice it doesn't. The main reason is because of all the extra overhead that the JRE has to carry around with it throughout the process.
    There's no such overhead. The JRE only loads what it needs...

    Because the time required to compile to native code is unacceptable in the context of a web app. JIT is nice in theory, but in practice it never lives up to it's expectations. That's why we're seeing emergence of things like compile on install, like what you get with .Net.
    That's wrong. The Java-files will be compiled once. Actually, you're not going to upload *.java files to a web-server... you'll upload an JAR/EAR with *.class files. These will be loaded by the server when they're used. They'll get JIT-compiled into processor-optimized native code (much better than C could do). Once HotSpot got hold of them, you'll have them and there's no need to recompile it. PHP interprets the Opcode every time. It doesn't get optimized and it won't become native code. It'll do that for every request. Are you seriously trying to tell us an interpreter written in C could be faster than native code, optimized for the particular processor your code is running on? Have you even thought about that?

    Again, what does data type tell me about an object? Absolutely nothing. In fact, it can be a hindrance because now when I want to change my data type later, I'm stuck having to manually go through my code to adjust.
    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.
    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?

    Statically typed languages have to resort to nasty hacks like generics to solve the problem.
    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!

    I never said "add typing information". I said "use sensible variable names". That means names like "PlayerName" or "NumberOfIterations" or "TimeToLive". You could do something like this in a statically typed language:
    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...

    What is "NumberOfIteration"? A number? What do you mean by "number"? A double? An int? Maybe a byte? Or is an object itself?

    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.

    In php, you'd never have to change that function signature.
    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...).

    PHP supports type hinting:
    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.

    The apps I write are built to be cross colo, multi-server applications designed to handle millions of unique visitors every month. I can say with absolute certainty that what we do where I work gets more traffic than what you do where you work. You CAN'T just scale a java app by throwing more hardware at it, but time and time again it's been shown that you can do that with many PHP apps (not all, of course, since database dependencies and such can bite you, but there are plenty that do just that).
    There are a lot of Java-apps out there that handle multiple millions of visits per day.

    You don't manage source with PHP, you manage it with CVS (or SVN or Perforce, if you prefer). I can assure you that the thousands of PHP source files that the company I work for has in our CVS repository work just fine for us.
    Reread what you've answered this too... it's almost off-topic.

    Yes, PHP's lack of namespaces is annoying, but it's hardly as crippling as some people make it sound.
    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, something that doesn't matter to PHP because it's tearing down the app every view.
    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.

    Or you can just do what everyone who knows anything about PHP does and use APC.
    And let the Opcode be interpreted, instead of using native code once HotSpot detected it with Java.

    Except that you rarely, if ever, control all the code that you're working with. It's the old "binary compatability" problem. I'd love it if there was an IDE capable of actually loading 1000+ files at once and doing find and replace on them all.
    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...

    Actually, this tool does use regexes to update. It just changes the source code. Just because you don't have to manually type in a regex doesn't mean that's not what's happening.
    These tools use a real parser to build an AST of your sources. It'll then operate on this AST.
    More advanced Java-IDEs like IntelliJ IDEA even provide search-and-replace functionality based on an AST as well. You type a statement to be looked for, it'll be compiled to an AST and then it'll be searched for in the sources.

    They would, if it weren't for the fact that you don't need to do it in the first place because you don't declare type.
    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...

    Because you *DON'T NEED IT* in PHP. The most useful tool that most IDEs provide is autocomplete (intellisense, if you will) and module / function / class heirarchy management. Both eclipse and zend studio do this just fine for PHP.
    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.

    Wikipedia, Yahoo, etc...all mentioned already (and lets not even get into all the usage of C/C++, perl, and python). Maybe you should have read the whole thread before you commented. Java got sold to enterprise customers because Sun marketing people pushed it at the same time that they were pushing hardware, so it caught on.
    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...

    Nobody's discussing money here. We're talking about startup cost in the performance sense. Again, read the whole thread.
    The startup cost of a running server isn't really high... also, as far as I know, servers like Resin and Tomcat take around 30 to 40 seconds to restart... and they stay running.
    If you want to talk about startup cost, you'd want to discuss desktop-applications, not servers (also, this is mostly a discussion of Tomcat vs. Apache).


    Just to clearify this: I use PHP myself very often (not as often as I did a few years ago, though). I use it to build small cms and shops for sites with little traffic. I'm using Java for desktop applications.
    I like both, PHP and Java, but I prefer Java. Mostly because of the weak IDEs for PHP.

  11. #61
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Now, if they had only added type hinting for the return value and general variable types ...



    But not only that, but for other types such as integers and strings as well... Maybe well get that in the near future though.

    As to your other points, PHP is specifically for web development, better than Java; There are just too many publically available facts between the comparison to say otherwise in my view. The one real benifit that Java has over PHP - for the moment anyways - is that Java has better tools, an area where PHP is still playing catch up

  12. #62
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I just bought a new computer for €400,- (AMD 64 3500+, 1024RAM, 160GB HD, etc. etc.)...
    I think the time of large investments in hardware are gone Aren't performance questions getting less and less important (At least for Web applications)?
    If PHP is too slow just make a little investment
    The one real benifit that Java has over PHP - for the moment anyways - is that Java has better tools, an area where PHP is still playing catch up
    I totally agree... I've been switching IDEs for too many times already

  13. #63
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I hope I said it, but I'm not using Java on the server side. I wouldn't want to, because my tasks are easier to do in PHP than they are in Java (ok... they would be easier with better IDEs).
    Right now I believe I could be more productive with Java and Wicket than with PHP.

    The one real benifit that Java has over PHP - for the moment anyways - is that Java has better tools, an area where PHP is still playing catch up
    Give me a few more months and this situation will have changed.

  14. #64
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Simple, if the process doesn't have to share anything, and it's all torn down between requests
    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.
    Yes. And I don't deal with apps that just run on one server. The apps I write are built to be cross colo, multi-server applications designed to handle millions of unique visitors every month. I can say with absolute certainty that what we do where I work gets more traffic than what you do where you work. You CAN'T just scale a java app by throwing more hardware at it, but time and time again it's been shown that you can do that with many PHP apps (not all, of course, since database dependencies and such can bite you, but there are plenty that do just that).
    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?
    __autoload + auto_prepend_file directive can make it so that you never really have to worry about where your classes come from.
    This solves nothing if you have two classes with the same name there will be a conflict.
    If you have a case where you REALLY think that the type of data requested is going to be non-obvious (and you can't be bothered to add comments to the function signature), PHP supports type hinting:
    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.
    Because the time required to compile to native code is unacceptable in the context of a web app.
    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...
    If you don't think PHP applications are scalable, you're just plain wrong. Wikipedia, yahoo, flickr, etc. -- all built with PHP. I work with large scale, high performance, extremely high scalability systems every day, and scripting languages have a huge advantage here due to the fact that you can always just toss more instances at the problem. It works every time. PHP just happens to be better than most because it runs faster than the other popular scripting languages.
    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.
    You don't manage source with PHP, you manage it with CVS (or SVN or Perforce, if you prefer). I can assure you that the thousands of PHP source files that the company I work for has in our CVS repository work just fine for us.
    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.

  15. #65
    SitePoint Addict
    Join Date
    Feb 2003
    Location
    eez
    Posts
    331
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm working for a comp in Denmark and let's say 8 months ago we had the mission to develop a quite complex site involving an Oracle db. The site would have to handle about 100 000 or more unique hits per day. The database choice was already decided, we weren't sure of what programming language to use (asp was not an option). After very thorough research, we came up with PHP and Java. Our client was very keen on performance and asked us explicitly to do extensive benchmarks before choosing the final programming language. And what we found out was very surprising and frankly made us freak out... For our server (dual xeon 2.8 Ghz with 4GB ram), PHP was 4 to 6 times faster than Java (mix of traditional and applets). 4 to 6 times!!! We expected Java to be slightly faster or much faster than PHP depending on the given task. This proved terribly wrong. From this moment on, we almost exclusively do projects in PHP and aspx and only rarely use Java (mostly applets) for very specific tasks.

    P.S. PHP version 4.3 (4 to 6 times faster) and PHP 5 (a little slower).

    P.S. 2. We also used the IBM DB2 database and obtained similar results.

  16. #66
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > 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.

    Not sure where you going with this, but the only singular problem with PHP in regards to large teams working with PHP in respect to how the application is developed is the lack of Namespaces; In no other area is PHP lacking in that context, unless of course you were thinking of something else?

    But even with that, at the moment the community as a whole, for the most part has got around that issue anyways.

  17. #67
    SitePoint Enthusiast
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP was 4 to 6 times faster than Java (mix of traditional and applets).
    How did you manage to compare server-side PHP with server and client-side Java? Doesn't sound like it was a benchmark I would care about. Also, how much experience had the developers with each language? Are you sure you weren't just to inexperienced to write fast Java? Are you sure you did configure your server right? You won't get the maximum out of Java if you configure your server wrong. And, while I'm at it, which App-server did you use? Did you try different ones?

  18. #68
    l º 0 º l silver trophybronze trophy lo0ol's Avatar
    Join Date
    Aug 2002
    Location
    Palo Alto
    Posts
    5,329
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aqw
    For our server (dual xeon 2.8 Ghz with 4GB ram), PHP was 4 to 6 times faster than Java (mix of traditional and applets). 4 to 6 times!!! We expected Java to be slightly faster or much faster than PHP depending on the given task. This proved terribly wrong. From this moment on, we almost exclusively do projects in PHP and aspx and only rarely use Java (mostly applets) for very specific tasks.
    Eh, I'm wary of relying on "evidence" like this. For example, I switched from PHP to Java on my site (which handles quite a bit of traffic) and it was faster and had a smaller load with Java than with PHP. These types of experiences seem too variable to me, and I would rather go with hardcore, professional benchmarks instead, if you really care about a microsecond of difference.

    Maybe people ignore me (and another minority figure of two or three) when we say things that can't easily be refuted: PHP and Java are both solid languages, which is why hundreds of thousands of servers run each. This is like politics- ie, if you're in America, the hardcore Democrats don't even see what the hardcore Republicans say, and vice versa. In actuality, each have very good reasons why they believe the way they do. Arguments like this are pointless because you're trying to attack the position of other people who won't give ground on their own beliefs. PHP isn't the best and Java isn't the best. PHP isn't the worst and Java isn't the worst. It depends on how you value the language. I switched to Java purely because I was more comfortable coding in it (it made more intuitive sense logically to me) than PHP. There are many where the reverse are true. Each have strong points, each have weak points. The sort of blind unrelenting arguing in this thread is tiresome and annoying.
    .
    Zach Holman
    good-tutorials — blog — twitter — last.fm

  19. #69
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP was 4 to 6 times faster than Java (mix of traditional and applets). 4 to 6 times!!!
    "mix of tranditional and applets"...oh boy. Why do people post junk like this?
    Not sure where you going with this, but the only singular problem with PHP in regards to large teams working with PHP in respect to how the application is developed is the lack of Namespaces; In no other area is PHP lacking in that context, unless of course you were thinking of something else?
    Lack of namespaces, dymanic typing, lack of naming conventions (related to first) etc.
    But even with that, at the moment the community as a whole, for the most part has got around that issue anyways.
    No they haven't as the fact that nothing even close to say CPAN exists for PHP.

  20. #70
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > No they haven't as the fact that nothing even close to say CPAN exists for PHP.

    That is true that PHP doesn't have something like that, but to be completely honest with you though, I doubt that you'll ever see something like that for PHP medium term; It just doesn't suit PHP it's self, in that the way that PHP has come, from the early days, to present day, in the sense of the community that drives PHP.

    The only thing that could come close, in that it could in thoery, bring everyone together, to use something, is proberly the Zend Framework but even then, that's only a mere framework; It doesn't alter the actual language or the environment of which PHP exists upon.

    But that isn't actually a hinderance either in my view; Imagine all the diverse libraries, etc that have sprung up on the need to create the functionality, that would normally be around, due to any pre-packaged for you with other languages.

    Also, you are forgetting about the functions that PHP has as well... That isn't something to be sniffed at

  21. #71
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Lack of namespaces, dymanic typing, lack of naming conventions (related to first) etc.

    Only the Namespaces is the real issue to resolve the problem you brought up - the rest we can get by without them, at least for the most part if needs must.

  22. #72
    SitePoint Enthusiast Buddha443556's Avatar
    Join Date
    Apr 2004
    Location
    FL, USA
    Posts
    87
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The sort of blind unrelenting arguing in this thread is tiresome and annoying.
    ... and useless too.
    Simple fool to the 3rd include.

  23. #73
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    dymanic typing
    This is not a downside. Even when it is, it's individual per developer.

    Quote Originally Posted by Snaily
    No they haven't as the fact that nothing even close to say CPAN exists for PHP.
    Except for PEAR and PECL. I'm not saying they're perfect, far from that -- but you said "nothing even close"...

  24. #74
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Only the Namespaces is the real issue to resolve the problem you brought up
    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.
    but you said "nothing even close"...
    I did...and PERL and PECL aren't even close to what CPAN does for Perl.
    The sort of blind unrelenting arguing in this thread is tiresome and annoying.
    If you think this...why are you posting in the thread? Makes little sense.

  25. #75
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How did this thread get featured on the main page?

    Yet another potentially good topic idea goes up in flames

    *wiping memory from last 10 minutes*


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •