I hate to say this, but I can't take anything you say seriously on any computer/developer-related commentary when you call Perl "Pearl" and keep referring to the company Apple as "MAC" ("If MAC wanted to break into the market in any serious quantity"...) You don't even call them Mac... it's not a FUCKING ACRONYM -- made worse by the fact that MAC is a legitimate acronym in the industry for something COMPLETELY UNRELATED.
And I doubt you know what "64-bit" even means, but the MBPs are 64bit machines with 64bit processors and they can run 64bit apps in with access to 64bit memory address space in OSX today.
Only problem I have with this box is the ICH8 is not well supported by 2.6.17 but apparently 2.6.18 addresses the issues I'm having.
I think that line highlights everything people are saying perfectly. You just proved why the Mac makes sense for lots of people. Sometimes Time > Money.
They're much more than normal cells... They're push based email devices, so there's no need to poll for email or "check your inbox". It gets your email almost as soon as it shows up in your email box at home/work. Very powerful, and very useful. You're always connected (and like a phone it can vibrate or ring whenever you get an email.)
Additionally, you can send, accept, etc meeting requests, check other people's calendars, etc. In a large enterprise environment, its pretty indispensible.
The same is true (just to a lesser degree since they aren't as extreme as NYC) for cities like Chicago, LA and SF.
Hell, a freaking block in NYC contributes more tax dollars to the state than an entire small town (like Utica.)
You're spouting gibberish. The US Government subsidizes the power lines, roads and industries of rural america. This money comes almost exclusively from the wealthy, ie those who live in million dollar+ 1 bedrooms in NYC and SF (and places of that caliber.)
And in terms of Terrorism funding, can you explain to me the rationale behind giving a state like Wyoming more money per capita than New York City to fight terrorism? Do you honestly believe Wyoming is a more attractive international terrorism target than NYC? I mean, that's just ludicrious. Yet our government constantly doles out larger per capita cash rewards to rural states with barely any risk than to major risk locations like LA, SF, DC and NYC. Again, you've got it backwards. Wyoming has the world's most advanced anti-radiation lab, and NYC can't get radiation detectors paid for at all by the federal government.
Right. A PHP application can cache. Thanks for admitting that you were wrong again.
A PHP application by itself can not cache. There is a big difference between writing your application so that it can use an external program as its "cache" and having something that is implemented in the language and can be set transparently.
It's alot harder to use something like memcached after the fact in PHP (since you have to add external calls to it EVERYWHERE) than it is to just chagne one line in an XML file to turn on a cache. To turn on caching in most modern Java frameworks, you literally have to drop ONE line into your application (like: hibernate.cache.provider_class=net.sf.ehcache.hibe rnate.Provider) vs the massive system wide change you'd have to make in a PHP application.
Additionally, you have to make EXTERNAL calls to an application running as a seperate daemon/process on your system. Not only is there a performance penalty in doing that (a pretty hefty one too if you're using something older than PHP 5), but it also means you're dependent on an outside process.
You don't see the problems with that? You don't see how php making external system calls is not exactly the best way? What if you need to debug the memory caching itself, or see how the caching is evicting objects, or profile the cache? How good is your C? Better be good or you're fucked.
By your logic, you can write a file system driver in PHP. Or a 3D first person shooter. Sure, you can make system calls to your hearts content, but you're an idiot if you do that.
Right, and you have also admitted that PHP applications can cache.
Except they can't cache across multiple servers/instances. How do you keep them in sync? Especially when the cache (as mentioned above) is a completely seperate process. How is PHP on box A going to tell cache written in C on box B that stuff has changed?
I know, you can hack up some code that does it. Great! More code that you have to write instead of using something that already exists. By the time you write that up, I'll be done for a week. And unlike your bullshit about classpaths, I do believe I can edit an XML file and add one line faster than you can write a syncing caching solution.
Maybe you can sit in the server room and run between them.
Really? You started this whole thread by stating that PHP applications don't scale. Now you refuse to state how far up they can scale.
Because that question depends on millions of variables. There's a big difference between me saying "In some cases PHP does not scale" and you asking for a specific number. I'll tell you right now, as I said about 30 times before, if you're doing something like collating numerous (10,20+) datafeeds (external/internal) that are customized for thousands of users, you'd be a fool to do it in PHP. If you're doing a little application that says "Hello, Nick!" then go ahead and do it in php.
I mean, I don't get it... do you want a simple number? You seem to think this is a simple question. How about 42? Is that a good answer?
Or are you looking for reassurement? Yes... your application does seem to be ok in php. Yes, you are ok doing what you did in php since it can't break...:pats head:
Once again. By the time you set your classpath and written your XML descriptors a good PHP programmer would be halfway to done.
It takes 4 seconds. Literally. I just timed how long it took to type "cp ~/jars/*.jar WEB-INF/lib". The XML files are pregenerated, and you must be pretty slow if you can't type in a directory path in the part of the file that says "INSERT-WEBAPP-PATH-HERE"
Of course the XML files can get complicated, but that's because of the ridiculous power you have in them. Want to change your entire authentication scheme? Edit one line in an xml file and you're done. Enable caching, add one line (like I mentioned above) and you're done. No need for massive global c
Having said that I am glad you finally admitted you were wrong on that.
No, you misread me. There are NO free IDEs for PHP that are any good. I assume you now think Jedit isn't an IDE anymore... good. What is out there? PHPEclipse? It's not even supported by the authors anymore. Quanta? Again, nothing more pretty much than syntax highlighting.
There's ONE ide for PHP that's worth anything, and it costs $300 starting.
Most people run apache (written in C) and mod_jk (also written in C). Again though it doesn't matter. You have now admitted that your original assertion about caching was wrong. A PHP application does have the ability to cache.
What? No I didn't. Most people run their web applications in a Java container... in fact they have to. Tomcat, JBoss, Weblogic...all Java. Jesus Christ, next thing you'll start telling me that PHP can manipulate registers directly because it runs Unix and everyone runs Unix and Unix has kernel assembler in it!
The fact is PHP can't do Caching.. it CAN'T. CAN NOT. You need to use something NOT written in php. You have to use an application that has NOTHING to do with PHP (other than PHP can use it.)
Jeez... are you going to start saying "Well PHP can fdisk hard drives because it runs on an ext2 partition for most people and that means PHP can call system('fdisk') and fdisk too, so it's EXACTLY like C!" No, it's not. Calling external programs and relying on external programs creates extra dependencies on things written in other languages. These are needed because PHP can't do it.
The scalibility of the database is always the arbiter of the scalibity of your application. That's true of any language. If your database can't scale then you might as well pack it in.
Having said that I was able to take 2 to 20 hits per second without storing my session in the database and without multiple web servers. One server, one database that's it.
Ok to part one. Right. THAT IS WHY YOU MINIMIZE DATABASE ACCESS. That is why I've been arguing about caching this whole time. You need to use the database smartly, not hit it everytime somebody accesses the home page just for their first name.
Obviously if you don't store the session in the db that's ok... where do you store it? Do you know? Do you actually know internally what php does for sessions that are not db backed? I'll let you look that one up, I'm sick of giving you real information everytime I respond.
What you responded to was the fact that I said earlier you can't scale a PHP application across multple web servers because then you NEED to store your session in a DB... and guess what? Then you're fucked.
Well yes, I have experience with both and that's my experience.
I am now going to ask you once again the question you refuse to answer.
How big can a PHP application scale up? That's the thread topic here.
I'm not answering because its a stupid question. The answer of course is "It depends" I said that like 10 messages ago. If your PHP application says "Hello World" it's going to scale better than an enterprise portal that collates data from 20 independent sources. The need for scability is also dependent on your audience. If your running a single threaded application that is going to have an audience of two, do whatever the fuck you want. (btw, this has NOTHING to do with the ROI of java vs php.)
And your java experience must be awesome considering you basically admitted to not even knowing how to set a classpath (your "I'd have half the application done by the time you've set your classpath and xml files" comment) So don't talk to me about your "experience" in both. Learn how to set a classpath and then come back and talk to me.
You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.
Before I get jumped on by anyone else still reading this ridiculous thread (which has to soon be going for some record.) I know you can get around this problem too through different ways. None are cheap though (You can't do funky network topology changes with DNS to both machines doing a load balance because then you get an inconsistent state between the boxes.) You can, however, get yourself a clustering database, like Oracle 10g or IBM's DB2. Of course, neither are cheap (nor easy to use.)
In the end, this thread is about preference of language. Productivity from language use by itself doesn't really mean much, it just means you're more comfortable in a language. This guy knows PHP better, hence, of course, he prefers it.
It's very similar to writing a research report... you can write it in whatever language you're most comfortable in and be the most productive, but if your best language is Bangladeshi, you'll be spending more time finding references for your paper than if its in English. Same rationale in java/php debate.
First of all there was a reason I put a period between those two sentences. Once again (for the last time I hope). THERE ARE IDES FOR PHP. I use Jedit and used it for years for PHP development without ever once wishing I had something else.
Fine... There IS ONE decent commercial IDE for PHP. And even with periods, you have flow in English sentences. Like "The dog is small. I like terriers" makes more sense and is more logical than "The dog is small. I like cheese."
There are IDEs for PHP.
Fine... one decent commercial for pay IDE.
Wow. This is so stunningly weird I don't know what to say. None of that has anything to do with an IDE. None of it.
You're having a hard time following my logic. I am arguing two things in this thread. One is performance scalability and one is developmental scalability. In that block above, I argue that having tons of prewritten libraries made by professionals that provide scaffolding/framework functionality means you don't have to reinvent the wheel everytime you write a new application. This leads to faster development. This type of scaffolding framework is not really found for PHP (and the closest you can get is Drupal which isn't that close.) It relates to the IDE because BOTH lead to more productive development. Understand now?
Again weird. Jboss is a separate product, apache is a separate product, mod_jk is a separate product, hibernate is a separate product, eclipse is a separate product, resin is a separate product. What's your point again?
JBoss is written in Java. Apache has nothing to do with Java, it's a web server. Hibernate is written in Java. Eclipse is written in Java. Resin is written in Java. (I'll give you mod_jk since it's an apache plugin its written in C) Zend Optimizer is written in... C. Memcached is written in... C. All of the PHP caching solutions are written in... C. See? Get my point now? In case you don't, it's that PHP isn't capable of doing this by itself... Java is. If you are using PHP you need to use OTHER technology in addition to PHP to make caching work.
What is the upper limit of how large a PHP application can scale? I say a PHP application can easily handle 100 hits per second and can easily be divided to run on multiple web servers with session info stored in databases.
Great! So now your session data is stored in a DB, so if you have a busy site, you are getting a minimum of n number of hits to the database where n = number of hits to the site. That's your BASE LINE now. You are ALWAYS going to have a DB hit per page access at MINIMUM.
You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.
If you are writing an application that is going to handle 100 hits per second or less then use PHP. You will get a faster ROI from a PHP app.
At least you stopped claiming you know Java. Your fundamental argument for PHP this whole thread has been "YO! I wrote a site that does a bagillion dollars of sales in a month in PHP. And it was faster than writing it in [random_language] because I say so and I feel that way"
Face it, YOU personally believe PHP gives you better ROI. I can argue to the moon that the advantages Java provides. Things like never ever ever having to write sql, worry about transactional code, transparent persistence layers, model-view-controller frameworks which provide auto validation and auto type casting ( For example: you can make an option pull down form and populate it with objects not strings, and when a user selects an item on the form the actual object is returned to the application, not a string you have to manually verify and then use as a key to reload the object), database connection pools, great web services layers, etc.
Grr... I never claimed that Jedit is an IDE for PHP. I simply said I used Jedit. There are IDEs for PHP though. More then one. Get that through your thick skull. Stop saying what you know is to be false. There are IDEs for PHP.
You said this in the previous thread, "Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit." So you literally said, "There are IDEs for PHP. I like Jedit." Now maybe you didn't mean to imply that Jedit is an IDE, but it sure as hell sounded like it. (And JEdit's code complete is very basic... it can complete for loops, but it can't introspect packages for methods that are in the object [or maybe it now can, it couldn't a year ago])
Finally IDEs have nothing to do with the scalibility of PHP.
They do in terms of development.
How does that make your application more scalable? I told you that my application scaled to 20 hits per second without breaking a sweat. I calculated that it could probably do 100 hits per second but we never even came close to that.
They do in terms of development. I wasn't arguing performance scability at that point, I was arguing reinventing the wheel everytime (validating code, parameter check code, database connection pooling code, insert sql statements for object code, caching code.)
This has got the most insane conversation I have ever had. How can you simultaniously claim that PHP is unable to cache and then list one free and one paid product that enable you to cache?
Sorry... I assumed you knew what those products were. They're not parts of PHP (certainly memcached isn't... it's AN ENTIRELY SEPERATE DAEMON APPLICATION that can be used in ANY language.) They're other APPLICATIONS that you can use with PHP to store stuff in resident memory (since PHP can't DO THAT by itself without a bytecode compiler.) Your response is insane. It's like saying "Man, PHP can totally play Sam & Max because I can run SCUMMVM in Unix and Php runs in Unix too!"
That's just a flat out lie. By the time you get your classpath figured out and your XML written the PHP application will be halfway to done. How? Just go visit the PEAR library and see for yourself. I know java very well thank you.
Ok you don't know Java. It takes about 1 second to resolve a class path in a modern development environment (like Eclipse). It takes about 1 minute to make an ANT build script that contains the line: "<classpath><pathelement path="${classpath}"/></classpath>"? How hard is it to copy your jars to the common/lib directory of tomcat or WEB-INF/lib directory of your webapp? You're telling me you can write half a PHP application faster than I can type "cp *.jar $TOMCAT_HOME/common/lib"? Shit, you are good.
Again, coding a little System.out.println("Hello World") application does not mean you know Java.
That application will not be more scalable then PHP. The only time Java is more scalable then PHP is when you have to distribute your application server amongst multiple servers.
It will certainly be more scalable than PHP without some bytecode optimizations or some inmemory cache products like memcached.
"Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit."
Repeat after me. JEdit is NOT an IDE. In fact, JEdit doesn't even refer to itself as an IDE (it calls itself a "programmer's text editor.") You either don't know what an IDE is or have never used one. It's a text editor with syntax highlighting. Does it do autocomplete? No. Does it do debugging/tracing? No. Does it have integration with CVS or other source code management software? No. (Let me guess, you don't need that either!) Do you know what an IDE is?
"Somehow during my years of programming in PHP I never needed it. Maybe that's because the combination of PHP and Apache is so lightweight. As I said I was averaging less then two percent CPU utilization taking 2 to 20 hits per second."
It's NOT lightweight if you are doing complex things. There's more to load than CPU utilization. What about number of connections that your application spawns or uses? What about the number of threads it executes? Do you even know these answers?
So? How much does intelliJ or Jbuilder cost? I am glad you are now changing your argument though. you went from "there are no PHP IDEs" to "PHP IDEs cost more then eclipse" at least we are making progress.
THERE IS NOTHING OF THE CALIBER OF ZEND FOR FREE. Maybe you should read that again. So I'll be even CLEARER, there are no FREE PHP IDEs. (No your text editor that does color [which is wonderful what it does] doesn't count.) Eclipse is not only of the caliber of IntelliJ/Jbuilder but in many cases SUPERIOR. (In fact the latest version of JBuilder will just be plugins in Eclipse... Borland has even given up on making a full blown IDE because Eclipse is so good.) Not only do I say this, but so do many many other people in this topic thread.
Let's presume you are right. So? Does any of that make PHP less scalable and if so by how much? That's the real question. Somehow my company was able to make millions of dollars per month without those things on a PHP based web site. Go figure!
That's great! And you can write your application in assembler and if you're really good at assembler you can make a website that makes millions of dollars per month too! Oh hell, just write your own web server too... in Ada! Sure, why not? That's great too!
The point is these options exist and are written by professionals who probably know more about this stuff than you (just because you can't know more about everything than the experts in those fields.) I feel confident using software written by the Apache Group or the JBoss group... and you know what, I can write an entire database application without ANY SQL... and that's just great.
I already said I was 200 to 300% more productive in PHP. And yes it was worth the price. Why? because it ended up that PHP was perfectly suitable for our application. WE NEVER HAD TO REWRITE IT. The application never got so big that it needed java.
Ah... so you don't know Java. Ok... that makes more sense. I am like 30000000% more productive in English than in Thai.
How is that the fault of PHP?
Because you can't implement an in-memory caching solution in PHP without something like the Zend Optimizer since PHP spawns independent threads for each access of a page. Hell, without paying money for things like Zend Optimzer/ZendCache, PHP has to COMPILE THE BYTECODE ON EVERY HIT. But unless you use something like PEAR cache, you ain't getting in memory caches with PHP.
I know you've coded PHP, but it sounds like you don't really know how PHP works internally. But that doesn't matter becuase it's better!
Premature optimization is writing your application in J2EE because you hope one day the application will need to be the size of amazon.com and taking two years to develop something that could have been on the market in six months.
No. That's just hiring someone who doesn't know shit about the languag
I've done BOTH too... I've coded my high school's 10 year reunion site in PHP and I've coded a major portal in Java.
To say that you don't "need an IDE" is great. I can use vi to code my stuff to. The point is, it is NICE to have. It is nice to be able to debug stack traces, it is nice to be able to change variables and see the effects. It's nicer to debug code this way than it is to drop variables in HTML to see what they're set to in the execution.
And, as I said before, good luck profiling a PHP app. Need to know which method is taking up most of your execution time? For all you know, one xml transformation can be accounting for 60% of your execution time... can you find that out in PHP? Sure, you can put in lots of time printouts that print to the screen or console but its certainly not as efficient as something like Eclipse Profiler.
Notice how all the stuff that I mentioned so far is free? Zend is $300 per license (and that's not the all-incompassing package)
Additionally, yes there real packages to back up my statements. Nothing out for PHP is as powerful as Hibernate, or as AspectJ, or as the profiler above or as JMS, or etc, etc...
Again, in your architecture there is no way for you to add another box, scale the application up, etc, etc... If you ever get to that point, you have to throw everything out and write it all from scratch.
You might have been more productive in PHP. How much more productive? 10%? 50%? 80%? Is it enough to compensate for the possibility that you must rewrite if your application grows dramatically?
Were you that much more productive because you are more comfortable in PHP in general? I bet someone can be just as comfortable coding in PHP as in the Struts or Tapestry frameworks for Java.
So yes, I've done both. No need to get nasty.
"I don't think that's right. In PHP you get to set an absolute limit and once that limit is reached then it stops. You can not presume the database pooling was misconfigured, it probably worked just like the author intended."
Great, that's stupid. If the absolute limit for database connections is TWO, it should still not crash on the home page. My problem isn't the connection pooling, its the fact that a wasted database hit is being made for EVERY access to the home page. That's ridiculous. Especially on a site that has relatively static data (that doesn't change more often than once a minute.)
And trust me, I doubt ANY author would intend for their site to just "die." If that's how you intend to react to heavy load, you're just a bad author. That's isn't "premature optimization," it's obvious smart optimization.
Those are some really interesting and cool solutions to the problems high load presents on a LAMP site. I'm sure lots of those flags and parameters you added came from experimentation and testing (noticing things like IE doesn't really notice pages with different cookies but similar content are new, etc).
I did mention earlier that it is possible to code a scalable perl/php/mysql/etc application (look at/. itself.) It's just that you have to jump through lots of hoops and write alot of non-business-logic code. You had to write an implementation that added the version 'v' field to your URLs, you had to do it for your 'o' fields, you had to muck around with different content-header information for different pages.
Its great that you took the time to essentially code alot of framework or scaffold code. I hope that its extensible and can be reused on different sites (if you ever have to make a new one, hopefully you can take most of this code with you.)
The nice thing about Java (and I have no experience with.NET, but I imagine its similar) is that alot of this stuff is already done for you. You want to handle caching from your DB? Just add one line to an xml file and you're done. Caching across machines? A few more property lines. Connection pooling? Same thing. And the cache is written by the guys at Sun so you can have some confidence that its ok. If not, take one of the many others that implement the standard (or if you're really courageous, write your own.)
The nice thing about large sites (and sites that need scability) is you can focus your time on the logic of the site in Java, and not on various solutions to make sure your caching implementation works correctly.
You can definitely code a php/perl app so that it can scale well, as you did, but it requires alot of work that isn't related directly to the site.
Sorry, I was in a "web" frame of mind, since we were talking about a web application.
It is nice that languages like PHP are interpreted (or at least dynamically run in a way that seems interpreted) and its nice that functionality is provided out of the box. It does make it very easy to modify code on the fly in production (something that is very scary though!)
Java provides similar type of functionality too if you need it(you can do hotdeploys of.class files [sorta], and you can use other technologies such as velocity to change content rendered on the fly.) Of course, it's not standard and requires some extra work to get it to perform the same way, but its possible.
It also would not be the right tool the job you described (because PHP gives this to you for free.) Again, right tool for the right job. It sounds like you have a great implementation using PHP, just many people think PHP is the end-all-be-all and every website in the world should be LAMP. That's who I was really addressing in my post.
I would like to know what you mean by "scale". Even if we stipulate everything you say as being true are they really that important in order to scale your application? Is ORM mandatory for large scale application? Certainly MS does not think so because they don't reccomend ORM for.NET applications.
ORM doesn't really have anything to do with scalability (at least in terms of load.) I'm sorry if you feel that my reply above implied that. What I was implying is that the packages that exist for great Java ORM implementation packages already exist. And they include great caching implementations that can easily be plugged in.
In terms of how large can a PHP application scale? Is surviving a slashdotting a sufficient answer? This link today didn't die because of a lack of resources or a lack of memory/hardware, it died because of a lack of connections since it was making lots of wasted database calls that aren't necessary.
The programmer productivity hit of using Java in a real IDE for something substantial isn't as big as you might think. Sure, writing a simple web site in PHP (with bulletin board, etc) is quick and easy, but if you want to do anything that is complex I think its easier to use packages that already exist (Lucene for search, Spread and other services for messaging, Hibernate for ORM, etc, etc) then to write your own. Java just seems to have more of these that can scale well than PHP.
Plus, as I mentioned earlier, you still don't have a real IDE out there for PHP (and yes, there is something to be said about being able to trace your code line by line.)
There is no real answer to "how much load before it keels over." You have to decide if the site you're making will ever be big enough to need the withstand serious load (or its doing something really complicated.)
Of course, you should always imagine the stuff you build will become as big as ebay or amazon!:)
That's not a bad idea, but still kind of a hack. You run the very real potentional of having stale content on your front page for as long as the page isn't expired in your proxy. Of course, you can send some information to the proxy and have it automatically expire pages that are out of date, but now you've split your application logic into a completely different location/server, making it harder to maintain.
But it isn't a bad solution if you don't have a homepage that has constantly changing critical data.
You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)
The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.
The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.
It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)
So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.
The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...
So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.
They need to get the word out to let people know they did it so they can use it. What the hell is the point of opening your WiFi to people when nobody knows you did it? Who would know to use it if it wasn't announced that its free?
They are being good corporate citizens. They opened up their WiFi, providing a service that they specialize in, and then informed the public they did it.
Um... Welcome to 2005. You do know what HDTV is right? All 360 games are HD. In case you don't know HDTV resolutions are HIGHER than most computers can push.
You're telling me that your Computer can push out Doom 3 at 1920x1080? Xbox 360 can.
You're telling me that your computer costs less than $400? XBox 360 does.
You think a $300-$400 PC can push these types of graphics at 1920x1080?
Oh, but I can get a RAID configuration on the PC... yay...
Did you READ the pattent? Because if you did your an idiot. Sorry, but it's true.
Do me a favor, before you call me an idiot... find me the iPod clickwheel patent if this isn't it. Find me another one that even is close. (and don't tell me the ClickWheel is not patented, because then YOU'RE the idiot.)
Now as for the idea of it being an airport express remote, it is clearly 8.5"x11" or bigger.
Notice the lack of dimensions in the picture? You don't think a lawyer (especially Apple lawyers) could defend a remote that is a little smaller than what the size the picture shows.
I still feel that the wheel mouse patent applies to the iPod clickwheel. If that previous patent applied for the clickwheel, than this one is FAR closer to an iTunesMovieStore remote than the clickwheel/mouse one.
But of course, this is all speculation (and apparently only ASoT knows the truth!)
Yea... I see what you're saying. It seems WAAAAY to obvious (and un-Apple like) to just give something that big away in a patent without obfuscating it to hell and back (and a picture of a guy using a tablet is pretty much the opposite of obfusication.)
That patent you refer to was clearly for the iPod clickwheel, but by phrasing all the language and diagrams as a "mouse" with a "rotary dial" you guys totally hid the real nature of the patent until it was released. Mind you, after the iPod mini's release it was pretty obvious that the patent applied to that item.
So what you're saying is the patent is for something unrelated to a tablet... something that , once it comes out, will obviously fit that patent.
You know what I think it is (based on your hints and other things I've read.) A remote for the Airport Express Video (the one with an integrated hardware h.263 encoder and digital video outputs for a TV) that gives you a mini iTunes-y type interface to select tv shows/episodes you bought.
Yea... that sounds like it! It'd be very cool! (and surprising for a company run by a man who I've read hates the TV.)
That really wasn't a hack. Safari (and Firefox and IE) try their best to approximate a url if one fails.
For instance, if you type in "microsoft" it tries "microsoft.com" and finds it.
If you type in "www.google.com" and it can't find "www.google.com" (because of DNS issues) it tries "www.google.net.com") and wa-la!!! That's how you got that image.
So it wasn't a Google Hack... it was a DNS issue (and it also seemed to have affected amazon.com, microsoft.com, yahoo.com and a few other sites... but not nearly as hard as Google.)
Why Slashdot is refusing to even mention this?
I have no freaking idea... it's kinda ridiculous. Half the comments in all the stories today are about it... people are DYING to talk about it, and slashdot refuses to mention it in any topic...
Slashdot Mirror
I hate to say this, but I can't take anything you say seriously on any computer/developer-related commentary when you call Perl "Pearl" and keep referring to the company Apple as "MAC" ("If MAC wanted to break into the market in any serious quantity"...) You don't even call them Mac... it's not a FUCKING ACRONYM -- made worse by the fact that MAC is a legitimate acronym in the industry for something COMPLETELY UNRELATED.
And I doubt you know what "64-bit" even means, but the MBPs are 64bit machines with 64bit processors and they can run 64bit apps in with access to 64bit memory address space in OSX today.
I think that line highlights everything people are saying perfectly. You just proved why the Mac makes sense for lots of people. Sometimes Time > Money.
They're much more than normal cells... They're push based email devices, so there's no need to poll for email or "check your inbox". It gets your email almost as soon as it shows up in your email box at home/work. Very powerful, and very useful. You're always connected (and like a phone it can vibrate or ring whenever you get an email.)
Additionally, you can send, accept, etc meeting requests, check other people's calendars, etc. In a large enterprise environment, its pretty indispensible.
Intel invented ieee1394, dumped it as a technology not worth pursuing and Apple picked it up and ran with it.
That's completely and utterly false. Apple invented ieee 1394 in the 80s.
I mean, come on! That took all of 3 seconds of searching on google.
Wrong.
Wrong.
Wrong.
Cities do subsidize rural areas.
50 richest counties in america (per capita) (Notice how they're all pretty much urban?)
50 poorest counties in america (per capita) Notice how they're nearly all rural?
The GDP of New York City (America's largest city) is 16th highest in the world (after Belgium.) New York City is the largest outlier in terms of tax dollars paid vs recieved. And in terms of costs, NYC as a seperate state would rank 51st out of 51 states in energy use per capita, but it would be the 11th most populous state in America.
The same is true (just to a lesser degree since they aren't as extreme as NYC) for cities like Chicago, LA and SF.
Hell, a freaking block in NYC contributes more tax dollars to the state than an entire small town (like Utica.)
You're spouting gibberish. The US Government subsidizes the power lines, roads and industries of rural america. This money comes almost exclusively from the wealthy, ie those who live in million dollar+ 1 bedrooms in NYC and SF (and places of that caliber.)
And in terms of Terrorism funding, can you explain to me the rationale behind giving a state like Wyoming more money per capita than New York City to fight terrorism? Do you honestly believe Wyoming is a more attractive international terrorism target than NYC? I mean, that's just ludicrious. Yet our government constantly doles out larger per capita cash rewards to rural states with barely any risk than to major risk locations like LA, SF, DC and NYC. Again, you've got it backwards. Wyoming has the world's most advanced anti-radiation lab, and NYC can't get radiation detectors paid for at all by the federal government.
Right. A PHP application can cache. Thanks for admitting that you were wrong again.
:pats head:
A PHP application by itself can not cache. There is a big difference between writing your application so that it can use an external program as its "cache" and having something that is implemented in the language and can be set transparently.
It's alot harder to use something like memcached after the fact in PHP (since you have to add external calls to it EVERYWHERE) than it is to just chagne one line in an XML file to turn on a cache. To turn on caching in most modern Java frameworks, you literally have to drop ONE line into your application (like: hibernate.cache.provider_class=net.sf.ehcache.hibe rnate.Provider) vs the massive system wide change you'd have to make in a PHP application.
Additionally, you have to make EXTERNAL calls to an application running as a seperate daemon/process on your system. Not only is there a performance penalty in doing that (a pretty hefty one too if you're using something older than PHP 5), but it also means you're dependent on an outside process.
You don't see the problems with that? You don't see how php making external system calls is not exactly the best way? What if you need to debug the memory caching itself, or see how the caching is evicting objects, or profile the cache? How good is your C? Better be good or you're fucked.
By your logic, you can write a file system driver in PHP. Or a 3D first person shooter. Sure, you can make system calls to your hearts content, but you're an idiot if you do that.
Right, and you have also admitted that PHP applications can cache.
Except they can't cache across multiple servers/instances. How do you keep them in sync? Especially when the cache (as mentioned above) is a completely seperate process. How is PHP on box A going to tell cache written in C on box B that stuff has changed?
I know, you can hack up some code that does it. Great! More code that you have to write instead of using something that already exists. By the time you write that up, I'll be done for a week. And unlike your bullshit about classpaths, I do believe I can edit an XML file and add one line faster than you can write a syncing caching solution.
Maybe you can sit in the server room and run between them.
Really? You started this whole thread by stating that PHP applications don't scale. Now you refuse to state how far up they can scale.
Because that question depends on millions of variables. There's a big difference between me saying "In some cases PHP does not scale" and you asking for a specific number. I'll tell you right now, as I said about 30 times before, if you're doing something like collating numerous (10,20+) datafeeds (external/internal) that are customized for thousands of users, you'd be a fool to do it in PHP. If you're doing a little application that says "Hello, Nick!" then go ahead and do it in php.
I mean, I don't get it... do you want a simple number? You seem to think this is a simple question. How about 42? Is that a good answer?
Or are you looking for reassurement? Yes... your application does seem to be ok in php. Yes, you are ok doing what you did in php since it can't break...
Once again. By the time you set your classpath and written your XML descriptors a good PHP programmer would be halfway to done.
It takes 4 seconds. Literally. I just timed how long it took to type "cp ~/jars/*.jar WEB-INF/lib". The XML files are pregenerated, and you must be pretty slow if you can't type in a directory path in the part of the file that says "INSERT-WEBAPP-PATH-HERE"
Of course the XML files can get complicated, but that's because of the ridiculous power you have in them. Want to change your entire authentication scheme? Edit one line in an xml file and you're done. Enable caching, add one line (like I mentioned above) and you're done. No need for massive global c
Nope look further. There are more then one.
Having said that I am glad you finally admitted you were wrong on that.
No, you misread me. There are NO free IDEs for PHP that are any good. I assume you now think Jedit isn't an IDE anymore... good. What is out there? PHPEclipse? It's not even supported by the authors anymore. Quanta? Again, nothing more pretty much than syntax highlighting.
There's ONE ide for PHP that's worth anything, and it costs $300 starting.
Most people run apache (written in C) and mod_jk (also written in C). Again though it doesn't matter. You have now admitted that your original assertion about caching was wrong. A PHP application does have the ability to cache.
What? No I didn't. Most people run their web applications in a Java container... in fact they have to. Tomcat, JBoss, Weblogic...all Java. Jesus Christ, next thing you'll start telling me that PHP can manipulate registers directly because it runs Unix and everyone runs Unix and Unix has kernel assembler in it!
The fact is PHP can't do Caching.. it CAN'T. CAN NOT. You need to use something NOT written in php. You have to use an application that has NOTHING to do with PHP (other than PHP can use it.)
Jeez... are you going to start saying "Well PHP can fdisk hard drives because it runs on an ext2 partition for most people and that means PHP can call system('fdisk') and fdisk too, so it's EXACTLY like C!" No, it's not. Calling external programs and relying on external programs creates extra dependencies on things written in other languages. These are needed because PHP can't do it.
The scalibility of the database is always the arbiter of the scalibity of your application. That's true of any language. If your database can't scale then you might as well pack it in.
Having said that I was able to take 2 to 20 hits per second without storing my session in the database and without multiple web servers. One server, one database that's it.
Ok to part one. Right. THAT IS WHY YOU MINIMIZE DATABASE ACCESS. That is why I've been arguing about caching this whole time. You need to use the database smartly, not hit it everytime somebody accesses the home page just for their first name.
Obviously if you don't store the session in the db that's ok... where do you store it? Do you know? Do you actually know internally what php does for sessions that are not db backed? I'll let you look that one up, I'm sick of giving you real information everytime I respond.
What you responded to was the fact that I said earlier you can't scale a PHP application across multple web servers because then you NEED to store your session in a DB... and guess what? Then you're fucked.
Well yes, I have experience with both and that's my experience.
I am now going to ask you once again the question you refuse to answer.
How big can a PHP application scale up? That's the thread topic here.
I'm not answering because its a stupid question. The answer of course is "It depends" I said that like 10 messages ago. If your PHP application says "Hello World" it's going to scale better than an enterprise portal that collates data from 20 independent sources. The need for scability is also dependent on your audience. If your running a single threaded application that is going to have an audience of two, do whatever the fuck you want. (btw, this has NOTHING to do with the ROI of java vs php.)
And your java experience must be awesome considering you basically admitted to not even knowing how to set a classpath (your "I'd have half the application done by the time you've set your classpath and xml files" comment) So don't talk to me about your "experience" in both. Learn how to set a classpath and then come back and talk to me.
You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.
Before I get jumped on by anyone else still reading this ridiculous thread (which has to soon be going for some record.) I know you can get around this problem too through different ways. None are cheap though (You can't do funky network topology changes with DNS to both machines doing a load balance because then you get an inconsistent state between the boxes.) You can, however, get yourself a clustering database, like Oracle 10g or IBM's DB2. Of course, neither are cheap (nor easy to use.)
In the end, this thread is about preference of language. Productivity from language use by itself doesn't really mean much, it just means you're more comfortable in a language. This guy knows PHP better, hence, of course, he prefers it.
It's very similar to writing a research report... you can write it in whatever language you're most comfortable in and be the most productive, but if your best language is Bangladeshi, you'll be spending more time finding references for your paper than if its in English. Same rationale in java/php debate.
First of all there was a reason I put a period between those two sentences. Once again (for the last time I hope). THERE ARE IDES FOR PHP. I use Jedit and used it for years for PHP development without ever once wishing I had something else.
Fine... There IS ONE decent commercial IDE for PHP. And even with periods, you have flow in English sentences. Like "The dog is small. I like terriers" makes more sense and is more logical than "The dog is small. I like cheese."
There are IDEs for PHP.
Fine... one decent commercial for pay IDE.
Wow. This is so stunningly weird I don't know what to say. None of that has anything to do with an IDE. None of it.
You're having a hard time following my logic. I am arguing two things in this thread. One is performance scalability and one is developmental scalability. In that block above, I argue that having tons of prewritten libraries made by professionals that provide scaffolding/framework functionality means you don't have to reinvent the wheel everytime you write a new application. This leads to faster development. This type of scaffolding framework is not really found for PHP (and the closest you can get is Drupal which isn't that close.) It relates to the IDE because BOTH lead to more productive development. Understand now?
Again weird. Jboss is a separate product, apache is a separate product, mod_jk is a separate product, hibernate is a separate product, eclipse is a separate product, resin is a separate product. What's your point again?
JBoss is written in Java. Apache has nothing to do with Java, it's a web server. Hibernate is written in Java. Eclipse is written in Java. Resin is written in Java. (I'll give you mod_jk since it's an apache plugin its written in C) Zend Optimizer is written in... C. Memcached is written in... C. All of the PHP caching solutions are written in... C. See? Get my point now? In case you don't, it's that PHP isn't capable of doing this by itself... Java is. If you are using PHP you need to use OTHER technology in addition to PHP to make caching work.
What is the upper limit of how large a PHP application can scale? I say a PHP application can easily handle 100 hits per second and can easily be divided to run on multiple web servers with session info stored in databases.
Great! So now your session data is stored in a DB, so if you have a busy site, you are getting a minimum of n number of hits to the database where n = number of hits to the site. That's your BASE LINE now. You are ALWAYS going to have a DB hit per page access at MINIMUM.
You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.
If you are writing an application that is going to handle 100 hits per second or less then use PHP. You will get a faster ROI from a PHP app.
At least you stopped claiming you know Java. Your fundamental argument for PHP this whole thread has been "YO! I wrote a site that does a bagillion dollars of sales in a month in PHP. And it was faster than writing it in [random_language] because I say so and I feel that way"
Face it, YOU personally believe PHP gives you better ROI. I can argue to the moon that the advantages Java provides. Things like never ever ever having to write sql, worry about transactional code, transparent persistence layers, model-view-controller frameworks which provide auto validation and auto type casting ( For example: you can make an option pull down form and populate it with objects not strings, and when a user selects an item on the form the actual object is returned to the application, not a string you have to manually verify and then use as a key to reload the object), database connection pools, great web services layers, etc.
Grr...
I never claimed that Jedit is an IDE for PHP. I simply said I used Jedit. There are IDEs for PHP though. More then one. Get that through your thick skull. Stop saying what you know is to be false. There are IDEs for PHP.
You said this in the previous thread, "Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit." So you literally said, "There are IDEs for PHP. I like Jedit." Now maybe you didn't mean to imply that Jedit is an IDE, but it sure as hell sounded like it. (And JEdit's code complete is very basic... it can complete for loops, but it can't introspect packages for methods that are in the object [or maybe it now can, it couldn't a year ago])
Finally IDEs have nothing to do with the scalibility of PHP.
They do in terms of development.
How does that make your application more scalable? I told you that my application scaled to 20 hits per second without breaking a sweat. I calculated that it could probably do 100 hits per second but we never even came close to that.
They do in terms of development. I wasn't arguing performance scability at that point, I was arguing reinventing the wheel everytime (validating code, parameter check code, database connection pooling code, insert sql statements for object code, caching code.)
This has got the most insane conversation I have ever had. How can you simultaniously claim that PHP is unable to cache and then list one free and one paid product that enable you to cache?
Sorry... I assumed you knew what those products were. They're not parts of PHP (certainly memcached isn't... it's AN ENTIRELY SEPERATE DAEMON APPLICATION that can be used in ANY language.) They're other APPLICATIONS that you can use with PHP to store stuff in resident memory (since PHP can't DO THAT by itself without a bytecode compiler.) Your response is insane. It's like saying "Man, PHP can totally play Sam & Max because I can run SCUMMVM in Unix and Php runs in Unix too!"
That's just a flat out lie. By the time you get your classpath figured out and your XML written the PHP application will be halfway to done. How? Just go visit the PEAR library and see for yourself.
I know java very well thank you.
Ok you don't know Java. It takes about 1 second to resolve a class path in a modern development environment (like Eclipse). It takes about 1 minute to make an ANT build script that contains the line: "<classpath><pathelement path="${classpath}"/></classpath>"? How hard is it to copy your jars to the common/lib directory of tomcat or WEB-INF/lib directory of your webapp? You're telling me you can write half a PHP application faster than I can type "cp *.jar $TOMCAT_HOME/common/lib"? Shit, you are good.
Again, coding a little System.out.println("Hello World") application does not mean you know Java.
That application will not be more scalable then PHP. The only time Java is more scalable then PHP is when you have to distribute your application server amongst multiple servers.
It will certainly be more scalable than PHP without some bytecode optimizations or some inmemory cache products like memcached.
"Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit."
Repeat after me. JEdit is NOT an IDE. In fact, JEdit doesn't even refer to itself as an IDE (it calls itself a "programmer's text editor.") You either don't know what an IDE is or have never used one. It's a text editor with syntax highlighting. Does it do autocomplete? No. Does it do debugging/tracing? No. Does it have integration with CVS or other source code management software? No. (Let me guess, you don't need that either!) Do you know what an IDE is?
"Somehow during my years of programming in PHP I never needed it. Maybe that's because the combination of PHP and Apache is so lightweight. As I said I was averaging less then two percent CPU utilization taking 2 to 20 hits per second."
It's NOT lightweight if you are doing complex things. There's more to load than CPU utilization. What about number of connections that your application spawns or uses? What about the number of threads it executes? Do you even know these answers?
So? How much does intelliJ or Jbuilder cost? I am glad you are now changing your argument though. you went from "there are no PHP IDEs" to "PHP IDEs cost more then eclipse" at least we are making progress.
THERE IS NOTHING OF THE CALIBER OF ZEND FOR FREE. Maybe you should read that again. So I'll be even CLEARER, there are no FREE PHP IDEs. (No your text editor that does color [which is wonderful what it does] doesn't count.) Eclipse is not only of the caliber of IntelliJ/Jbuilder but in many cases SUPERIOR. (In fact the latest version of JBuilder will just be plugins in Eclipse... Borland has even given up on making a full blown IDE because Eclipse is so good.) Not only do I say this, but so do many many other people in this topic thread.
Let's presume you are right. So? Does any of that make PHP less scalable and if so by how much? That's the real question. Somehow my company was able to make millions of dollars per month without those things on a PHP based web site. Go figure!
That's great! And you can write your application in assembler and if you're really good at assembler you can make a website that makes millions of dollars per month too! Oh hell, just write your own web server too... in Ada! Sure, why not? That's great too!
The point is these options exist and are written by professionals who probably know more about this stuff than you (just because you can't know more about everything than the experts in those fields.) I feel confident using software written by the Apache Group or the JBoss group... and you know what, I can write an entire database application without ANY SQL... and that's just great.
I already said I was 200 to 300% more productive in PHP. And yes it was worth the price. Why? because it ended up that PHP was perfectly suitable for our application. WE NEVER HAD TO REWRITE IT. The application never got so big that it needed java.
Ah... so you don't know Java. Ok... that makes more sense. I am like 30000000% more productive in English than in Thai.
How is that the fault of PHP?
Because you can't implement an in-memory caching solution in PHP without something like the Zend Optimizer since PHP spawns independent threads for each access of a page. Hell, without paying money for things like Zend Optimzer/ZendCache, PHP has to COMPILE THE BYTECODE ON EVERY HIT. But unless you use something like PEAR cache, you ain't getting in memory caches with PHP.
I know you've coded PHP, but it sounds like you don't really know how PHP works internally. But that doesn't matter becuase it's better!
Premature optimization is writing your application in J2EE because you hope one day the application will need to be the size of amazon.com and taking two years to develop something that could have been on the market in six months.
No. That's just hiring someone who doesn't know shit about the languag
Snippy.
I've done BOTH too... I've coded my high school's 10 year reunion site in PHP and I've coded a major portal in Java.
To say that you don't "need an IDE" is great. I can use vi to code my stuff to. The point is, it is NICE to have. It is nice to be able to debug stack traces, it is nice to be able to change variables and see the effects. It's nicer to debug code this way than it is to drop variables in HTML to see what they're set to in the execution.
And, as I said before, good luck profiling a PHP app. Need to know which method is taking up most of your execution time? For all you know, one xml transformation can be accounting for 60% of your execution time... can you find that out in PHP? Sure, you can put in lots of time printouts that print to the screen or console but its certainly not as efficient as something like Eclipse Profiler.
Notice how all the stuff that I mentioned so far is free? Zend is $300 per license (and that's not the all-incompassing package)
Additionally, yes there real packages to back up my statements. Nothing out for PHP is as powerful as Hibernate, or as AspectJ, or as the profiler above or as JMS, or etc, etc...
Again, in your architecture there is no way for you to add another box, scale the application up, etc, etc... If you ever get to that point, you have to throw everything out and write it all from scratch.
You might have been more productive in PHP. How much more productive? 10%? 50%? 80%? Is it enough to compensate for the possibility that you must rewrite if your application grows dramatically?
Were you that much more productive because you are more comfortable in PHP in general? I bet someone can be just as comfortable coding in PHP as in the Struts or Tapestry frameworks for Java.
So yes, I've done both. No need to get nasty.
"I don't think that's right. In PHP you get to set an absolute limit and once that limit is reached then it stops. You can not presume the database pooling was misconfigured, it probably worked just like the author intended."
Great, that's stupid. If the absolute limit for database connections is TWO, it should still not crash on the home page. My problem isn't the connection pooling, its the fact that a wasted database hit is being made for EVERY access to the home page. That's ridiculous. Especially on a site that has relatively static data (that doesn't change more often than once a minute.)
And trust me, I doubt ANY author would intend for their site to just "die." If that's how you intend to react to heavy load, you're just a bad author. That's isn't "premature optimization," it's obvious smart optimization.
Those are some really interesting and cool solutions to the problems high load presents on a LAMP site. I'm sure lots of those flags and parameters you added came from experimentation and testing (noticing things like IE doesn't really notice pages with different cookies but similar content are new, etc).
/. itself.) It's just that you have to jump through lots of hoops and write alot of non-business-logic code. You had to write an implementation that added the version 'v' field to your URLs, you had to do it for your 'o' fields, you had to muck around with different content-header information for different pages.
.NET, but I imagine its similar) is that alot of this stuff is already done for you. You want to handle caching from your DB? Just add one line to an xml file and you're done. Caching across machines? A few more property lines. Connection pooling? Same thing. And the cache is written by the guys at Sun so you can have some confidence that its ok. If not, take one of the many others that implement the standard (or if you're really courageous, write your own.)
I did mention earlier that it is possible to code a scalable perl/php/mysql/etc application (look at
Its great that you took the time to essentially code alot of framework or scaffold code. I hope that its extensible and can be reused on different sites (if you ever have to make a new one, hopefully you can take most of this code with you.)
The nice thing about Java (and I have no experience with
The nice thing about large sites (and sites that need scability) is you can focus your time on the logic of the site in Java, and not on various solutions to make sure your caching implementation works correctly.
You can definitely code a php/perl app so that it can scale well, as you did, but it requires alot of work that isn't related directly to the site.
That's all I'm saying.
Sorry, I was in a "web" frame of mind, since we were talking about a web application.
.class files [sorta], and you can use other technologies such as velocity to change content rendered on the fly.) Of course, it's not standard and requires some extra work to get it to perform the same way, but its possible.
It is nice that languages like PHP are interpreted (or at least dynamically run in a way that seems interpreted) and its nice that functionality is provided out of the box. It does make it very easy to modify code on the fly in production (something that is very scary though!)
Java provides similar type of functionality too if you need it(you can do hotdeploys of
It also would not be the right tool the job you described (because PHP gives this to you for free.) Again, right tool for the right job. It sounds like you have a great implementation using PHP, just many people think PHP is the end-all-be-all and every website in the world should be LAMP. That's who I was really addressing in my post.
I would like to know what you mean by "scale". Even if we stipulate everything you say as being true are they really that important in order to scale your application? Is ORM mandatory for large scale application? Certainly MS does not think so because they don't reccomend ORM for .NET applications.
:)
ORM doesn't really have anything to do with scalability (at least in terms of load.) I'm sorry if you feel that my reply above implied that. What I was implying is that the packages that exist for great Java ORM implementation packages already exist. And they include great caching implementations that can easily be plugged in.
In terms of how large can a PHP application scale? Is surviving a slashdotting a sufficient answer? This link today didn't die because of a lack of resources or a lack of memory/hardware, it died because of a lack of connections since it was making lots of wasted database calls that aren't necessary.
The programmer productivity hit of using Java in a real IDE for something substantial isn't as big as you might think. Sure, writing a simple web site in PHP (with bulletin board, etc) is quick and easy, but if you want to do anything that is complex I think its easier to use packages that already exist (Lucene for search, Spread and other services for messaging, Hibernate for ORM, etc, etc) then to write your own. Java just seems to have more of these that can scale well than PHP.
Plus, as I mentioned earlier, you still don't have a real IDE out there for PHP (and yes, there is something to be said about being able to trace your code line by line.)
There is no real answer to "how much load before it keels over." You have to decide if the site you're making will ever be big enough to need the withstand serious load (or its doing something really complicated.)
Of course, you should always imagine the stuff you build will become as big as ebay or amazon!
That's not a bad idea, but still kind of a hack. You run the very real potentional of having stale content on your front page for as long as the page isn't expired in your proxy. Of course, you can send some information to the proxy and have it automatically expire pages that are out of date, but now you've split your application logic into a completely different location/server, making it harder to maintain.
But it isn't a bad solution if you don't have a homepage that has constantly changing critical data.
You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)
The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.
The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.
It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)
So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.
The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...
So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.
It's not even on their home page.
They need to get the word out to let people know they did it so they can use it. What the hell is the point of opening your WiFi to people when nobody knows you did it? Who would know to use it if it wasn't announced that its free?
They are being good corporate citizens. They opened up their WiFi, providing a service that they specialize in, and then informed the public they did it.
Wow... you figure they'd at least make this up to date.
The World Trade Center is still in the aerial photos for Lower Manhattan.
Now that's just pathetic.
PC - greater than TV rezs
360 - nope
Um... Welcome to 2005. You do know what HDTV is right? All 360 games are HD. In case you don't know HDTV resolutions are HIGHER than most computers can push.
You're telling me that your Computer can push out Doom 3 at 1920x1080? Xbox 360 can.
You're telling me that your computer costs less than $400? XBox 360 does.
You think a $300-$400 PC can push these types of graphics at 1920x1080?
Oh, but I can get a RAID configuration on the PC... yay...
Go sit down and stop trolling.
Of all those cities... why no New York City? I mean come on, if Sacramento and Hartford get it, shouldn't the largest city in America?
Did you READ the pattent? Because if you did your an idiot. Sorry, but it's true.
Do me a favor, before you call me an idiot... find me the iPod clickwheel patent if this isn't it. Find me another one that even is close. (and don't tell me the ClickWheel is not patented, because then YOU'RE the idiot.)
Now as for the idea of it being an airport express remote, it is clearly 8.5"x11" or bigger.
Notice the lack of dimensions in the picture? You don't think a lawyer (especially Apple lawyers) could defend a remote that is a little smaller than what the size the picture shows.
I still feel that the wheel mouse patent applies to the iPod clickwheel. If that previous patent applied for the clickwheel, than this one is FAR closer to an iTunesMovieStore remote than the clickwheel/mouse one.
But of course, this is all speculation (and apparently only ASoT knows the truth!)
Of course, by h.263 I mean h.264 ... (long day at the office today... )
Yea... I see what you're saying. It seems WAAAAY to obvious (and un-Apple like) to just give something that big away in a patent without obfuscating it to hell and back (and a picture of a guy using a tablet is pretty much the opposite of obfusication.)
That patent you refer to was clearly for the iPod clickwheel, but by phrasing all the language and diagrams as a "mouse" with a "rotary dial" you guys totally hid the real nature of the patent until it was released. Mind you, after the iPod mini's release it was pretty obvious that the patent applied to that item.
So what you're saying is the patent is for something unrelated to a tablet... something that , once it comes out, will obviously fit that patent.
You know what I think it is (based on your hints and other things I've read.) A remote for the Airport Express Video (the one with an integrated hardware h.263 encoder and digital video outputs for a TV) that gives you a mini iTunes-y type interface to select tv shows/episodes you bought.
Yea... that sounds like it! It'd be very cool! (and surprising for a company run by a man who I've read hates the TV.)
That really wasn't a hack. Safari (and Firefox and IE) try their best to approximate a url if one fails.
For instance, if you type in "microsoft" it tries "microsoft.com" and finds it.
If you type in "www.google.com" and it can't find "www.google.com" (because of DNS issues) it tries "www.google.net.com") and wa-la!!! That's how you got that image.
So it wasn't a Google Hack... it was a DNS issue (and it also seemed to have affected amazon.com, microsoft.com, yahoo.com and a few other sites... but not nearly as hard as Google.)
Why Slashdot is refusing to even mention this?
I have no freaking idea... it's kinda ridiculous. Half the comments in all the stories today are about it... people are DYING to talk about it, and slashdot refuses to mention it in any topic...
What gives with Slashdot?