Microsoft implemented a scheme to enable floppies to be 'ripped-out' and Apple did not.
Not really. If you "ripped-out" the floppy at the wrong time under DOS, you got a nice bunch of "Abort, Retry, Fail?" errors.
The fundemental problem was that the original Mac had only one floppy drive, but the System + Applications usually did not fit on a single disk. So the Mac was always telling you "Please insert Disk: Application", "Please insert Disk: System" endlessly over-and-over-again. So the hardware had to force you to have the right disk in the drive at the right time.
PCs always had 2 floppys and largely avoided this problem.
Browsers render HTML progressively, before the page has completed downloading. That's not possible if you need to validate the document before hand (and how do you deterimine if it is invalid without validating it?). Furthermore, browsers in wide use like FF are tolerant and well optimized for "Quirks", so there's not necessariliy any speed penalty for doing so.
Yes, I think it is not likely that Opera's usage is underestimated as much as Opera Fans like to think, and it is not likely that a change in the UA will lead to increased Opera support. My site stats were simply an example of why.
Not at all in my experience. Our CSS works fine with IE6/Win, Firefox, and Safari, but on IE5/Mac it's often screwed. IE6 positioning support is pretty complete (as long as you use the correct DOCTYPE), it just has some annoying bugs. IE5/Mac appears to be both incomplete and even more buggy.
It's a little more complicated than this, because you need to serve IE pages with a HTML 4.0 DOCTYPE in order for CSS to work somewhat correctly. So you would also need to rewrite the doctype if you doing any CSS positioning.
Also, I've read that if you serve application/xhtml+xml to Firefox/Mozilla it perform a validation and render pages much more slowly.
What will happen though is webpages from 1998 will have to be updated to stop checking for IE vs NS4 with silly useragent checks
Fat Chance. Anyone who is still doing NS4 detection is probably using a library script that they don't understand. If they aren't checking for Opera now, this change alone won't cause them to start.
and start using object existance checks
I tested a script-heavy site with an old version of Opera. It turns out the DOM objects and methods existed, but didn't do anything. I guess Opera just put them there so that scripts wouldn't error out in a manner that allowed users to see why the site didn't work. I don't know if Opera still does this, I hope not.
Supposedly as in they claim to detect it, but I haven't actually verified it myself.
Doesn't that tell you that the "supposedly" above might be wrong? Most people agree that (even with today's flawed browser stats), Opera has at least closer to one per cent globally.
Actually it reinforces my opinion that "flawed stats" are an excuse that allows Opera Fans over-estimate their marketshare by dismissing any emprical evidence that runs counter to their assumptions (just what you did). Quite frankly, Opera's issue with stat packages are their problem, not mine, and one I'm glad to hear they are addressing.
Regardless, it's site-dependant, so it's quite possible Opera has 1% marketshare somewhere else, but on this (large, consumer, CSS2) site it's 0.2%.
What rights could Xerox have given them if look and feel is not covered by copyright?
Well, that's a trick question. Since Apple believed that Look-n-Feel was legally protected by copyright, it follows that they should have bought the imaginary rights from Xerox.
Amazing! Only 16k onboard and the 64k would have made it around 80k or so. How did these things sell like hotcakes? I mean they weren't really any better than much else that was out at the time
Originally the IBM PC was targetting the Apple II+, and shipped with similar specs and pricing. However, when it started getting adopted by businesses, it was usually loaded out with more memory and storage than the Apple systems. 64K was the maximum memory for an Apple II and the minimum for an IBM. (Oh, and nobody ever relied on Casette BASIC.)
By 1983, the PC XT came with a standard hard drive and between 256 and 512K of memory. In comparison, the original Mac looked pretty lame in certain departments -- only 128K RAM, no hard drive, etc.
The thing that held PC GUIs back wasn't the CPU or memory however, it was the terrible graphics adapters. It wasn't until VGA appeard in the late 80s that a PC GUI became tenable, and not coincidentially that's right when Windows took off.
Apparently your reading comprehension is so poor that you failed to understand the thread was about Java (not.net), and that I stated that PHP works great for huge sites like Yahoo, You, sir, are living proof why PHP programmers are the lowest paid in the industry.
It's like IBM took Apple's "think different" motto, but instead of "thinking innovative", they went the "think anti-intuitive" route instead.
Notes really was an innovative product, but that was back in the 80s. It was a distributed Hypertext system years before the WWW came around.
The problem was that when the web appeared and got popular, they just hacked HTML generation into the system. The goal wasn't to create a good web development environment, it was to keep Notes relevant after it had been obsoleted.
Well, I wouldn't expect a PHP programmer to understand that Java and.NET are two different things. So, I will attribute your reply to the intense gay lust you have for me and my super l33t programming sk1lz. (Cue "Can't Touch This" by MC Hammer.)
This allows the application only to run the code it needs to for the action necessary, and to include an extensible set of possibilities without having to maintain separate decision trees.
OK, I think I understand what you are getting at, but I'm not clear if you are doing this only because PHP doesn't cache bytecode without a 3rd party piece.
I've done something similar for one application where users could create and publish their own forms. The approach was to use dynamically loaded ASP.NET controls, which keep a nice interface between the "UI/Form" code and the application logic.
(Cue my stalker pal with some more random incoherant flames.)
Sure, but look up at your titlebar. The thing about webapps is that (unlike embedded), one can throw hardware at the problem. When Java webapps have performance issues, it's usually due to application architecture and not the VM/runtime.
Yahoo with its PHP, google with its C/C++ were considered much bigger than any enterprise site
Much bigger in terms of traffic, but much simplier. The definition of an "enterprise" app is one that integrates with multiple systems -- application servers, databases, web services, mainframes, etc. Java has tons of solutions to those problems.
Yahoo is huge, but they are simply splatting some news and stock quotes into a template. Their primary problem is scaling, not complexity.
So if you are working on corporate systems rather than a big dotcom, what Yahoo uses isn't really all that relevant. And even then, Yahoo even came out and said they'd rather use Java than PHP, but had problems with FreeBSD compatibility.
(Ignoring the search engines of course, which are their own kind of complexity.)
Notice how the programmer only needs to specify the SQL datatype and can ignore SQL quoting rules? I think this is much easier for the newbie than learning how and when to use sprintf.
No, like most PHPers, you just have no understanding how other environments do things. With a decent data layer, SQL quoting and escaping are handled automatically, and web programmers are not worrying about when to "addslashes" (not to mention that / is a DB-specific escape char and shouldn't be anywhere near your processing code).
Now, obviously a good programmer can work around bad infrastructure, and a bad programmer can always create problems. But for an entry-level environment, PHP takes a hack approach that makes things harder than necessary, and you can blame them for that.
Dynamic includes don't really substitute for COM or other objects, nor do they seem to be a very sound "large application" strategy, so I don't get your point.
Slashdot Mirror
Microsoft implemented a scheme to enable floppies to be 'ripped-out' and Apple did not.
Not really. If you "ripped-out" the floppy at the wrong time under DOS, you got a nice bunch of "Abort, Retry, Fail?" errors.
The fundemental problem was that the original Mac had only one floppy drive, but the System + Applications usually did not fit on a single disk. So the Mac was always telling you "Please insert Disk: Application", "Please insert Disk: System" endlessly over-and-over-again. So the hardware had to force you to have the right disk in the drive at the right time.
PCs always had 2 floppys and largely avoided this problem.
Browsers render HTML progressively, before the page has completed downloading. That's not possible if you need to validate the document before hand (and how do you deterimine if it is invalid without validating it?). Furthermore, browsers in wide use like FF are tolerant and well optimized for "Quirks", so there's not necessariliy any speed penalty for doing so.
o del.htm
This page describes how certain valid DOCTYPES can knock IE6 into "legacy mode": http://css.maxdesign.com.au/listamatic/about-boxm
Yes, I think it is not likely that Opera's usage is underestimated as much as Opera Fans like to think, and it is not likely that a change in the UA will lead to increased Opera support. My site stats were simply an example of why.
Not at all in my experience. Our CSS works fine with IE6/Win, Firefox, and Safari, but on IE5/Mac it's often screwed. IE6 positioning support is pretty complete (as long as you use the correct DOCTYPE), it just has some annoying bugs. IE5/Mac appears to be both incomplete and even more buggy.
It's a little more complicated than this, because you need to serve IE pages with a HTML 4.0 DOCTYPE in order for CSS to work somewhat correctly. So you would also need to rewrite the doctype if you doing any CSS positioning.
Also, I've read that if you serve application/xhtml+xml to Firefox/Mozilla it perform a validation and render pages much more slowly.
I'm not the one who cited stats from my own site and pretended that they represent the entire world.
Apparently you have a reading comprehension defect, because I did just the opposite.
What will happen though is webpages from 1998 will have to be updated to stop checking for IE vs NS4 with silly useragent checks
Fat Chance. Anyone who is still doing NS4 detection is probably using a library script that they don't understand. If they aren't checking for Opera now, this change alone won't cause them to start.
and start using object existance checks
I tested a script-heavy site with an old version of Opera. It turns out the DOM objects and methods existed, but didn't do anything. I guess Opera just put them there so that scripts wouldn't error out in a manner that allowed users to see why the site didn't work. I don't know if Opera still does this, I hope not.
Supposedly as in they claim to detect it, but I haven't actually verified it myself.
Doesn't that tell you that the "supposedly" above might be wrong? Most people agree that (even with today's flawed browser stats), Opera has at least closer to one per cent globally.
Actually it reinforces my opinion that "flawed stats" are an excuse that allows Opera Fans over-estimate their marketshare by dismissing any emprical evidence that runs counter to their assumptions (just what you did). Quite frankly, Opera's issue with stat packages are their problem, not mine, and one I'm glad to hear they are addressing.
Regardless, it's site-dependant, so it's quite possible Opera has 1% marketshare somewhere else, but on this (large, consumer, CSS2) site it's 0.2%.
Our stats package can supposedly detect Opera's spoofed UA, and I'm still seeing numbers like 0.2%.
Despite my username, right now IE5/Macintosh is the bane of my existance as it is still over the magic 1.0% line.
What rights could Xerox have given them if look and feel is not covered by copyright?
Well, that's a trick question. Since Apple believed that Look-n-Feel was legally protected by copyright, it follows that they should have bought the imaginary rights from Xerox.
Amazing! Only 16k onboard and the 64k would have made it around 80k or so. How did these things sell like hotcakes? I mean they weren't really any better than much else that was out at the time
Originally the IBM PC was targetting the Apple II+, and shipped with similar specs and pricing. However, when it started getting adopted by businesses, it was usually loaded out with more memory and storage than the Apple systems. 64K was the maximum memory for an Apple II and the minimum for an IBM. (Oh, and nobody ever relied on Casette BASIC.)
By 1983, the PC XT came with a standard hard drive and between 256 and 512K of memory. In comparison, the original Mac looked pretty lame in certain departments -- only 128K RAM, no hard drive, etc.
The thing that held PC GUIs back wasn't the CPU or memory however, it was the terrible graphics adapters. It wasn't until VGA appeard in the late 80s that a PC GUI became tenable, and not coincidentially that's right when Windows took off.
Apparently your reading comprehension is so poor that you failed to understand the thread was about Java (not .net), and that I stated that PHP works great for huge sites like Yahoo, You, sir, are living proof why PHP programmers are the lowest paid in the industry.
It's like IBM took Apple's "think different" motto, but instead of "thinking innovative", they went the "think anti-intuitive" route instead.
Notes really was an innovative product, but that was back in the 80s. It was a distributed Hypertext system years before the WWW came around.
The problem was that when the web appeared and got popular, they just hacked HTML generation into the system. The goal wasn't to create a good web development environment, it was to keep Notes relevant after it had been obsoleted.
Well, I wouldn't expect a PHP programmer to understand that Java and .NET are two different things. So, I will attribute your reply to the intense gay lust you have for me and my super l33t programming sk1lz. (Cue "Can't Touch This" by MC Hammer.)
I guess I should have said "Enterprise Beans" instead of "J2EE". True that web services are useful, but they don't solve the same problem as COM+.
This allows the application only to run the code it needs to for the action necessary, and to include an extensible set of possibilities without having to maintain separate decision trees.
OK, I think I understand what you are getting at, but I'm not clear if you are doing this only because PHP doesn't cache bytecode without a 3rd party piece.
I've done something similar for one application where users could create and publish their own forms. The approach was to use dynamically loaded ASP.NET controls, which keep a nice interface between the "UI/Form" code and the application logic.
(Cue my stalker pal with some more random incoherant flames.)
Of course, most PHP coders (especially newbies) don't seem to know about this. :(
Wow. As a newb PHP programmer, I certainly never saw this syntax example (which is a good deal easier than the usual suggestions).
I suppose part of the problem is that PHP has now developed a subcult of "smart" coders that have figured out their own workarounds.
EnterpriseServices is COM+.
Sure, but look up at your titlebar. The thing about webapps is that (unlike embedded), one can throw hardware at the problem. When Java webapps have performance issues, it's usually due to application architecture and not the VM/runtime.
Yahoo with its PHP, google with its C/C++ were considered much bigger than any enterprise site
Much bigger in terms of traffic, but much simplier. The definition of an "enterprise" app is one that integrates with multiple systems -- application servers, databases, web services, mainframes, etc. Java has tons of solutions to those problems.
Yahoo is huge, but they are simply splatting some news and stock quotes into a template. Their primary problem is scaling, not complexity.
So if you are working on corporate systems rather than a big dotcom, what Yahoo uses isn't really all that relevant. And even then, Yahoo even came out and said they'd rather use Java than PHP, but had problems with FreeBSD compatibility.
(Ignoring the search engines of course, which are their own kind of complexity.)
Probably more accurate to say "similar to ASP/VBScript". The Java HotSpot compilier is vastly more sophisticated than anything available for PHP.
Are you replying to me? I'm talking about "tiers" in terms of process isolation. And with .NET, the "enterprise application server" is COM+/MTS.
No, like most PHPers, you just have no understanding how other environments do things. With a decent data layer, SQL quoting and escaping are handled automatically, and web programmers are not worrying about when to "addslashes" (not to mention that / is a DB-specific escape char and shouldn't be anywhere near your processing code).
Now, obviously a good programmer can work around bad infrastructure, and a bad programmer can always create problems. But for an entry-level environment, PHP takes a hack approach that makes things harder than necessary, and you can blame them for that.
Dynamic includes don't really substitute for COM or other objects, nor do they seem to be a very sound "large application" strategy, so I don't get your point.