Look further down at my Dolphin-safe tuna example. There you have a "cleanly manufactured" product that won't affect you any differently than a standard one. And it cost more than the alternative. And people bought it en masse.
You've been able to compile java to a static executable for years with most development environments. First there was Symantec, then Microsoft (who licensed Symantec's stuff)... IBM's Visual Age can do it. TowerJ is well known for their native compilation and speed.
And now there's gcj.
No native compilation indeed. Where have you been for the last five years?
Organic (no pesticides or hormones used) fruits and vegetables cost noticeably more than "normal" produce and yet there are people who pay extra for it. Farmers must be organic for five years before they can put the organic stamp on so there must be some demand for it.
Think of free-range meat products and dolphin-safe tuna. If given a choice, and educated about that choice, many people will choose the more expensive alernative if it serves a purpose they agree with.
Government mandates would not necessarily be an issue for individuals. Corporate policies would be an issue though as corporations are ammoral money-making machines. They'll dump radioactive raw sewage infected with Ebola if it would help their bottom line and the government didn't stop them.
On the contrary, the reason why 90% of client apps aren't written in Java is because Swing is dog-slow and a memory hog.
The Swing API on the other hand, is quite elegant and usable. MVC all the way. The interfaces were great. It's just too bad the implementation sucked.
All of those C libraries I listed (none of them were C++) are loaded on demand in the background. The developer never sees them. All he/she sees is the interface. Want a different implementation, just swap JVMs. Your code still runs. Want to use a different XML parser? Start the JVM with what amounts to an environment variable.
Now let's examine the pure C side of things. If you code to GTK, you are locked into GTK. You have no alternate implementations of GTK. If you want to switch to FLTK, you must completely rewrite the GUI layer of your app. If you code to libxml, your app is tied to libxml, and any other parser will require retooling.
That is not modularity; That's segmentation. The standard C library is an example of modularity. If I want to manipulate a string -- however poor those facilities may be -- it doesn't matter whose implementation I use. Even though the implementations are different, strcmp is strcmp is strcmp. If glibc doesn't fit the bill, use another implementation. Why? It has nothing to do with shared libraries. It has to do with the fact that the standard C library has well defined interfaces. I happen to think that a header file with functions is a fairly weak interface, but it's a modular interface nonetheless.
Your idea of modular apparently is arc-welding the wheels to the axle of a car. When you need a new pair of tires, you just pry them off and weld a new set on.
Yeah, that makes sense: Discount the only groups that actually care enough to study it.
You didn't think to ask, "where do you dive?" Perhaps he frequents areas with shark hunting bans. No, you assume that the data colected by Dalhousie University -- not just one university and marine biology organization by the way -- is tainted. Maybe I'm not as cynical. Maybe it's because I lived with a marine biologist that studied sharks for his thesis. I don't know.
Shark populations are dropping rapidly. That is a fact. The only people who deny this are the ones who haven't looked. And no, I don't mean the people that scuba dive in local, shark-infested waters. I mean people who are looking at the populations over the entire Atlantic Ocean.
java.awt and javax.swing are separate from java.util and java.lang. Perl keeps its modules separate. So does Python. Maybe you were talking about the underlying C/C++ portion of those VMs?
C/C++ doesn't have nice, modular libraries. They give you a choice between many monolithic programmatic libraries. Can you simply drop in MFC, Qt, GTK, FLTK, etc. into your app? No. You choose one and you're effectively stuck with it. That's not modular my friend. You can't be modular in a language without first defining interfaces: something C and C++ won't do because ignorant geeks incorrectly attribute completeness for bloat.
There's nothing stopping Sun from splitting the C portions of the JVM into multiple shared libraries...oh wait! They already do!
Ummm... I'd like to point out that that is exactly what UNIX/Linux are. C is very much integrated with the OS. The only reason you don't notice is that you've never know anything different.
Here's a hint: When was the last time you saw a garbage collector in the kernel? Why don't kernel functions allow for variable number of parameters? Why aren't there any kernel objects?
Without C, there is no UNIX. But I forgot. You were suggesting a LISP model for the OS. Yeah... That's not integrating the language with the OS...
Most sites aren't CPU bound; They're disk I/O or memory bound. Once you exhaust RAM, you swap to disk, and performance drops precipitously. Once the database must read/write to more sectors than can fit in RAM, page faults ensue, and performance drops precipitously.
Their solution not only saves CPU, but I/O workload as well.
In the Ace's Hardware article, they benchmark their Java-based web server against Apache 1.3.x and Apache 2.0.x. The Java-based server, Resin, beat Apache easily.
As for heavily threaded apps, no leading Java servlet container/web server uses a 1:1 model of request to threads: not Tomcat, Resin, Weblogic, WebSphere, nor Jetty.
Queuing approaches have proven to be much more scalable in other areas - no reason to think it wouldn't work for web servers.
Too late. It's already been done for months now. As JDK 1.4 comes into greater use, you will see more and more of these offerings using non-blocking I/O (read: event-driven) as the default HTTP handling method.
This is why people should set an expiration time on their static content. If, for example, I set up the images to expire one hour from the access time, multiple visits to the page (and images shared between multiple pages) would only be requested once. An ISP's proxy servers down the chain would only help in this regard.
In addition, for static content, "LastModified" is easy to compute. Clients can request a page, send an "If-Modified-Since" header with the timestamp of the static item, and if the item hasn't changed, return a 304 response and no data.
The same can be done for dynamic content, but it requires a bit more work. Most web servers do these things for static content out of the box.
As was said in the article, the fastest request is the request that never has to be made.
Two critical areas that seem to have taken a major hit are quality control and warranties. More and more drives (and in some cases, entire drive families) seem to be failing at every given opportunity. Meanwhile, the length for which they're covered has shrunk back from (typically) three years to the minimum one.
Not true. While there have been some problems, by and large the reliability has increased. Does anyone remember the old Seagate 40MB drives? Can you honestly say that they were more reliable? What about the 540MB drives? I can recall quite a few lemons in that batch.
The truth is that many companies are reducing the duration of warranties for accounting reasons unrelated to quality. Drives are actually more reliable for longer periods of time. However, keeping sale information for every drive takes time and effort. While a great deal of this information is electronic, they must also have a paper bill of sale and other info from the retailers for tax purposes. The warrantee info on paper must be housed somewhere. Major hard drive manufacturers sell a lot of drives. That's a lot of paper. That means storage costs -- accessible storage costs.
It costs them quite a bit of cash to maintain those warranties. The shortened interval has very little to do with drive quality though despite the anecdotal evidence individual Slashdotters may present. (eg. Two people saying that they have had four drives fail in the last year does not a trend make. Think in thousands.)
For 99% of users, data integrity is the holy grail and everything else comes a distant second. I wish manufacturers would remember that.
This is what backups are for. No matter how good drives get, there will always be a need for good backups. A lot of people have CD-R/CD-RW drives. A few even have DVD burners. If your important data only exists in one place, how can you say that you consider it important? If you kept all of your important documents, money, and valuable goods in your car, no matter how reliable or secure that car may be, when that car breaks down, you will be screwed. The same holds true of your computer. Make copies. The drive manufacturers are largely a scapegoat.
And no, I don't work for any hard drive manufacturers nor do any of my friends and family.
If there are no standardized interfaces, the code I write today will be intimately tied to the library I use. Or I could write an abstraction layer (basically an interface) but there will be no consistency when I change jobs or inherit someone else's work.
If there are well defined interfaces with substandard implementations, it won't matter too much. Once a better library comes out, I can just relink and use it.
Imagine being able to write the following:
Panel panel = new Panel(); Label label = new Label("There is unsaved work!"); Button button1 = new Button("Save and Exit"); Button button2 = new Button("Don't Exit"); button1.addActionListener(saveAndExit);
button2.addActionListener(exitWithoutSaving); pan el.add(label); panel.add(button1); panel.add(but ton2);
Yes, this is simplified and based on Java's GUI model, but you get the idea. No imagine that you could write to this API (or one like it) and plug in Qt, GTK, MFC, or whatever.
I don't want the ultimate graphics library (UGL); I want the ultimate graphics interface (UGI) into which I can plug in the UGL.:)
Of course, the REAL reason why CS doesn't appeal to women is that it's a boy's club. The tools, methidology, culture, and framework are all designed by rather cloistered geeks for their own use in putting out a rather arcane end product.
Are chemical engineering or mathematics tracks less in-depth or less focused than computer science? I don't think so.
My point was that there is no inherent aspect of women/girls that makes CIS/CS/CE an untenable field of study. The differences are mainly social or difficiencies in the way CS programs are run.
Yes except that people will start writing code to those C libraries and build a mountain of code that has no consistency. Even if there are native D libraries, what benefit would it give if there are three different interfaces for database access? D doesn't need to implement everything. Software darwinism is a good thing. But at least specify the interfaces!
Otherwise I will have to do the market research to determine which API I will code to. I don't have to do this in Java (or.NET). Why? Does Sun write every database driver out there? No. They wrote a database API interface almost from the beginning to which vendors could write their own implementations. The obvious standard made ad hoc interfaces seem ridiculous. And rightly so!
Imagine what C++ would have been like if it didn't have be compatible with C. Unfortunately, that similarity was the only way that it could get a foothold and get used.
D, on the other hand, is not prentending to be "C with classes" or "C only better." A D compiler cannot compile C or C++. I applaud the author for making the clean break and taking only the parts of C and C++ (and Java) that make sense. But as soon as the tutorials pop up in Dr. Dobbs and various online venues that teach OpenGL programming with D as linkage to the C library, D is screwed.
Modern C++ can do so many things, but because of the C baggage, it is constantly held back. 95% of the time, you should never use char* for strings in C++. std::string makes much more sense in almost every way. It's easier to use, consistent with the STL, and about as fast as char*. There is so much code out there that uses char*, however, that std::string adoption (and std::list, std::map, std::vector, etc.) has been unreasonably slow.
Don't underestimate inertia. D should try to stay out of the limelight as long as possible so that these design issues can be worked out. Otherwise you'll end up seeing ad hoc implementations of every major feature with no consistency. And we will be right back where we started -- only with a new name to our troubles.
but in fields such as biology, mathematics, physics, engineering, etc., women are commonly anywhere from 40% to 60% of the division population. Then we look at CS where the number drops precipitously.
There are indeed differences, but the tenacity for in-depth knowledge in a subject is not the difference. Or were you going to say that math was not requiring an in-depth knowledge. Perhaps biology is just four or five years of fluff. Oh, I know! All of those women who are receiving medical degrees are just coasting along with no in-depth knowledge.
And just to pick apart that "concentrating on a single thing for long periods of time," I have just one word: mother.
Yet another way to write and manipulate ints, floats, struct, and classes.
Why don't people put as much effort into designing standardized interfaces for networking, threading, forking, database access, distributed logic, graphics, etc.
He goes on and on about how we need unified syntaxes for unit testing, inline assembly, assertions, etc., but is curiously silent with regard to the above issues.
What are the killer apps? Apache? OpenLDAP? OpenOffice? Mozilla? Konqueror? Photoshop? Gimp? Quake? Neverwinter Nights? Crystal Reports? Gaim?
Now with that list in mind, how does D make anyone's life simpler? Need a TCP/IP socket? Sure! Just use the POSIX one...unless you're on Windows...or coding for BeOS... What about talking to a database? Well there's ODBC implementation #1, ODBC implementation #2, native database-specific API #1, etc. Well at least there's graphics right? OpenGL all the way...except when you need DirectX...or the framebuffer interface... And for GUI libraries, we have GTK+, Qt, FLTK, MFC, XUL, etc. Along those lines, do you use Gnome or KDE for your object model? Do I write to libxml or use some COM wrapper for MSXML3.DOMDocument?
What good is uniformity in a complex type when anything I want to do with the language that implements it requires an unending list of non-D libraries that throw uniformity out of the window? Please explain to me how my life is enriched by this language? Please explain how solves more problems than it creates?
Sure Java, Python, et al have their share of problems, but at least I can open a socket or a filehandle without doing market research on libraries first. At least code written in those languages is readable by someone who knows the language. Database calls look the same no matter your operating system. That's what I want. Not just some new and exciting method for representing imaginary numbers.
And while we're talking about data types, he writes at length about how ints, longs, floats, etc. are all well-defined sizes unlike in C even though saying int16, int32, and int64 would be much easier to read and helpful. In addition, while the other types are well-defined and char is well-defined as a single 8-bit byte, wchar is sometimes 2 bytes, sometimes 4 bytes, and could be something else in the future depending on the wind. Ask the i18n coders about their experiences with wchar_t. Most end up using an avalanche of #ifdefs or just sidestep it altogether with their own array of bytes. Why? Because sometimes they're using UTF-16 and other times it is UCS4. You need to know how big the character type is! It's not something you leave up in the air! char16...char32... Are these too much to ask for?
I hope to god that no one actually adopts D for real work in the near future. If they do, they will run into the limitations I mentioned above and figure out some hack to get it to work. Hack begets hack begets hack and you are left with another bloated language lacking uniformity that people will bitch about on tech discussion boards. And then some person will say, "Hey! I've got this new language that fixes all of those inconsistencies with D that we all hate."
...is not the same as DOM Level 2. DOM Level 2 (core, views, events, style, and traversal & range) became a recommendation two years ago.
This is the DOM Level 2 spec as applied to HTML and XHTML.
From the DOM Level 2 HTML recommendation:
This section extends the DOM Level 2 Core API [DOM Level 2 Core] to describe objects and methods specific to HTML documents [HTML 4.01], and XHTML documents [XHTML 1.0]. In general, the functionality needed to manipulate hierarchical document structures, elements, and attributes will be found in the core section; functionality that depends on the specific elements defined in HTML will be found in this section.
And there are quite a few Unix variants that don't have 100% support for POSIX either. This doesn't mean that a working subset isn't widely available and in common use.
Same thing goes for DOM2. Does any browser support all of that spec? No. Do Opera, Mozilla, IE, Konqueror, etc. support most of the common DOM 2 idioms? Yes.
With regard to CSS 2 support, yes, there is a great variability in support. But every browser in common desktop use supports
position: absolute;
and that's in the CSS 2 spec. I use that all of the time. 100% support is nice, but lacking that, 75% will work in a pinch. 75% isn't great, but it's a damn sight better than 0% standards support.
The validators just check that you use the spec, not that you're using the spec correctly.
For example:
while(hasmore = 1){
do_stuff();
has_more = 0;
}
Technically correct and it compiles, but it doesn't do what you would necessarily want it to do. Testing against IE is most definitely not testing against a W3C standard for rendering. IE has its share of bugs too -- sometimes bugs that only show up when viewed in another possibly more standards-compliant browser.
And why dump XHTML (I'm assuming "strict") for HTML 4.01 transitional? They are basically the same thing only XHTML transitional is well-formed XML. Since you already went through the trouble of making the site well-formed, why dump it for HTML? That's like saving up money for a BMW, not ending up with enough money, and choosing a used Ford Pinto. What about the middle ground?
Thanks for not reading the sentence after that... *sigh*
If your goal is the greatest number of eyeballs with your scripting web site, using the DOM will reach more eyeballs than document.all. That's orthogonal to IE's market dominance.
98% is greater than 95%. So code to the 98%.
document.all = 95%
DOM = 98%
And in the future, that DOM percentage will approach 100% in every reasonable case (whether Mozilla becomes more popular or not) because of full support in IE -- that market-dominating browser you love so much. document.all could either gain in share (if IE dominance extends itself) or it could drop in share (if alternate browsers get a foothold, AOL moves forward with their Gecko-based client to Windows, and Microsoft doesn't deprecate the document.all API).
The DOM simply makes sense. document.all is potentially a limiting factor.
All those kludges are awful. Microsoft revealed that they have absolutely no taste for API design. Binding the event object to the global window object was a stupid decision, it's like using global variables. And making an "all" array of everything is silly too. The document.layers API is awful too, each layer is a whole document! Maintaining these kind of kludges for ever is what make the software we use more bloated. It's also something which makes software development more difficult (you can be assigned to a project coded for these). If you knew the Microsoft Windows API you would know why the APIs are important and they should not be allowed to rotten.
It's a bad API. So was NS4's layer API. The W3C DOM is a better API. It is clear, concise, well-documented, and supported by more browsers in use today than document.all(!!!).
Neither does virtually anybody else. Given this attitude on the part of the developers, it's easy to see why.
More people use Mozilla, Netscape 6+, and the other Gecko-based browsers now than IE4- and Netscape 4 combined. The recent IE browser version support the DOM API in its entirety. If you code to the DOM spec instead of document.all, you will get more browsers than by using document.all. The "du jour" solution has greater penetration than your de facto solution. Why code for 95% when you could have 99%?
By all means, go to Microsoft's own tech documentation site, select "APIs & References" from the search dropdown, and enter in document.all. Go ahead. I dare you. The ONLY documents you will get back relate to the DOM API. Even Microsoft is trying to dump document.all. Go look up the.NET documentation. Try to find document.all instead of a DOM example. You won't find it. Who do you think was one of the biggest contributors to the DOM spec? That's right: Microsoft.
Fix your scripts now or fix them later. I don't care. But you've backed the wrong horse.
If your goal is eyeballs, standards make more sense. If your goal is simply to avoid fixing your scripts, at least be honest about it. Don't pretend that you are doing for the users' benefit.
I think the words you're groping for here are "compatibility" and "convenience."
No. The word I was "groping" for was dependence. document.all is not a good API. The only reason to implement it is for compatibility with IE.
A lot of pages write to that API. And there's the rub. Having two APIs that do the same thing (the W3C standard way and the Internet Explorer way) confuse new developers as to the correct solution and perpetuate a suboptimal solution. IE 5+ supports that W3C standard API. IE 4 has a smaller marketshare than Mozilla/Netscape at this point.
Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft. I have no problem with it being the most used browser, but I refuse to cede ownership of what I consider a public resource.
Having a standard means that you aren't dependent on one vendor or solution. Having a standard means that if someone comes up with something better, you can use it. If you use the Apache web server and decide to switch to IIS or iPlanet or Zeus you can. Why? Because any browser can talk to any of them. Why? Because they all implement the HTTP standard.
As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse. Sticking with standards is an assertion that the message is more important than the messenger.
Since it's trivial to implement it with JavaScript, and it's a feature of 95% (maybe more) of the browsers out there, why not implement it in the engine itself? Arguing that it's an easy thing to add yourself doesn't make a very compelling argument against implementing it in the browser, in my opinion.
You misunderstand. I think that implementing document.all in its entirety is non-trivial. What I was suggesting was that you code in the functionality that you are using currently -- most likely less than the full object hierarchy for document.all. Personally, as I don't use and don't care about document.all, I'm quite pleased that Mozilla developers are concentrating on other items. Remember that Mozilla is Open Source. Features find their way in because someone wants to scratch a personal itch. Perhaps you could get AOL/Netscape to push for the feature, but as they haven't cared thus far, it doesn't seem people are clamouring to pay them for the feature.
Because Mozilla is the tall poppy. The Mozillans hop on pop about their rigid and total standards compatibility, while for no good reason breaking compatibility with the vast, vast, majority of browsers and of JavaScript out there. Makes no sense.
A clean API that is used by everyone -- including Microsoft -- makes perfect sense. Just as Microsoft has dropped full support for DOS and Windows 3.x programs, it's time to drop document.all. Backward compatibility is a noble goal but not at the expense of progress. Taking the time to implement it is sinking time into a feature that is already obsolete.
The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it. If you're bitching about it as a scapegoat for your own non-standard scripting, shame on you. If you're bitching about it because a bank site requires document.all, gently remind them that you're giving them your money.
Slashdot Mirror
Look further down at my Dolphin-safe tuna example. There you have a "cleanly manufactured" product that won't affect you any differently than a standard one. And it cost more than the alternative. And people bought it en masse.
You've been able to compile java to a static executable for years with most development environments. First there was Symantec, then Microsoft (who licensed Symantec's stuff)... IBM's Visual Age can do it. TowerJ is well known for their native compilation and speed.
And now there's gcj.
No native compilation indeed. Where have you been for the last five years?
Organic (no pesticides or hormones used) fruits and vegetables cost noticeably more than "normal" produce and yet there are people who pay extra for it. Farmers must be organic for five years before they can put the organic stamp on so there must be some demand for it.
Think of free-range meat products and dolphin-safe tuna. If given a choice, and educated about that choice, many people will choose the more expensive alernative if it serves a purpose they agree with.
Government mandates would not necessarily be an issue for individuals. Corporate policies would be an issue though as corporations are ammoral money-making machines. They'll dump radioactive raw sewage infected with Ebola if it would help their bottom line and the government didn't stop them.
On the contrary, the reason why 90% of client apps aren't written in Java is because Swing is dog-slow and a memory hog.
The Swing API on the other hand, is quite elegant and usable. MVC all the way. The interfaces were great. It's just too bad the implementation sucked.
All of those C libraries I listed (none of them were C++) are loaded on demand in the background. The developer never sees them. All he/she sees is the interface. Want a different implementation, just swap JVMs. Your code still runs. Want to use a different XML parser? Start the JVM with what amounts to an environment variable.
Now let's examine the pure C side of things. If you code to GTK, you are locked into GTK. You have no alternate implementations of GTK. If you want to switch to FLTK, you must completely rewrite the GUI layer of your app. If you code to libxml, your app is tied to libxml, and any other parser will require retooling.
That is not modularity; That's segmentation. The standard C library is an example of modularity. If I want to manipulate a string -- however poor those facilities may be -- it doesn't matter whose implementation I use. Even though the implementations are different, strcmp is strcmp is strcmp. If glibc doesn't fit the bill, use another implementation. Why? It has nothing to do with shared libraries. It has to do with the fact that the standard C library has well defined interfaces. I happen to think that a header file with functions is a fairly weak interface, but it's a modular interface nonetheless.
Your idea of modular apparently is arc-welding the wheels to the axle of a car. When you need a new pair of tires, you just pry them off and weld a new set on.
Yeah, that makes sense: Discount the only groups that actually care enough to study it.
You didn't think to ask, "where do you dive?" Perhaps he frequents areas with shark hunting bans. No, you assume that the data colected by Dalhousie University -- not just one university and marine biology organization by the way -- is tainted. Maybe I'm not as cynical. Maybe it's because I lived with a marine biologist that studied sharks for his thesis. I don't know.
Shark populations are dropping rapidly. That is a fact. The only people who deny this are the ones who haven't looked. And no, I don't mean the people that scuba dive in local, shark-infested waters. I mean people who are looking at the populations over the entire Atlantic Ocean.
java.awt and javax.swing are separate from java.util and java.lang. Perl keeps its modules separate. So does Python. Maybe you were talking about the underlying C/C++ portion of those VMs?
C/C++ doesn't have nice, modular libraries. They give you a choice between many monolithic programmatic libraries. Can you simply drop in MFC, Qt, GTK, FLTK, etc. into your app? No. You choose one and you're effectively stuck with it. That's not modular my friend. You can't be modular in a language without first defining interfaces: something C and C++ won't do because ignorant geeks incorrectly attribute completeness for bloat.
There's nothing stopping Sun from splitting the C portions of the JVM into multiple shared libraries...oh wait! They already do!Looks pretty well split up to me. As for the classes and interfaces, the JVM never invokes the classloader on a class until you request it.
Next issue?
Ummm... I'd like to point out that that is exactly what UNIX/Linux are. C is very much integrated with the OS. The only reason you don't notice is that you've never know anything different.
Here's a hint: When was the last time you saw a garbage collector in the kernel? Why don't kernel functions allow for variable number of parameters? Why aren't there any kernel objects?
Without C, there is no UNIX. But I forgot. You were suggesting a LISP model for the OS. Yeah... That's not integrating the language with the OS...
The big deal is that there are still dozens of sites a year that haven't yet learned this lesson and are trounced by a Slashdotting.
The language means nothing. They are talking about software architecture issues.
Most sites aren't CPU bound; They're disk I/O or memory bound. Once you exhaust RAM, you swap to disk, and performance drops precipitously. Once the database must read/write to more sectors than can fit in RAM, page faults ensue, and performance drops precipitously.
Their solution not only saves CPU, but I/O workload as well.
If memory serves, Slashdot has a small farm of boxes -- multiple boxes dedicated to Slash and a couple dedicated to MySQL.
Ace's Hardware runs on a single box whose hardware is slower than any one of the Slashdot boxes.
As for heavily threaded apps, no leading Java servlet container/web server uses a 1:1 model of request to threads: not Tomcat, Resin, Weblogic, WebSphere, nor Jetty.
Too late. It's already been done for months now. As JDK 1.4 comes into greater use, you will see more and more of these offerings using non-blocking I/O (read: event-driven) as the default HTTP handling method.
This is why people should set an expiration time on their static content. If, for example, I set up the images to expire one hour from the access time, multiple visits to the page (and images shared between multiple pages) would only be requested once. An ISP's proxy servers down the chain would only help in this regard.
In addition, for static content, "LastModified" is easy to compute. Clients can request a page, send an "If-Modified-Since" header with the timestamp of the static item, and if the item hasn't changed, return a 304 response and no data.
The same can be done for dynamic content, but it requires a bit more work. Most web servers do these things for static content out of the box.
As was said in the article, the fastest request is the request that never has to be made.
Not true. While there have been some problems, by and large the reliability has increased. Does anyone remember the old Seagate 40MB drives? Can you honestly say that they were more reliable? What about the 540MB drives? I can recall quite a few lemons in that batch.
The truth is that many companies are reducing the duration of warranties for accounting reasons unrelated to quality. Drives are actually more reliable for longer periods of time. However, keeping sale information for every drive takes time and effort. While a great deal of this information is electronic, they must also have a paper bill of sale and other info from the retailers for tax purposes. The warrantee info on paper must be housed somewhere. Major hard drive manufacturers sell a lot of drives. That's a lot of paper. That means storage costs -- accessible storage costs.
It costs them quite a bit of cash to maintain those warranties. The shortened interval has very little to do with drive quality though despite the anecdotal evidence individual Slashdotters may present. (eg. Two people saying that they have had four drives fail in the last year does not a trend make. Think in thousands.)
This is what backups are for. No matter how good drives get, there will always be a need for good backups. A lot of people have CD-R/CD-RW drives. A few even have DVD burners. If your important data only exists in one place, how can you say that you consider it important? If you kept all of your important documents, money, and valuable goods in your car, no matter how reliable or secure that car may be, when that car breaks down, you will be screwed. The same holds true of your computer. Make copies. The drive manufacturers are largely a scapegoat.
And no, I don't work for any hard drive manufacturers nor do any of my friends and family.
If there are no standardized interfaces, the code I write today will be intimately tied to the library I use. Or I could write an abstraction layer (basically an interface) but there will be no consistency when I change jobs or inherit someone else's work.
If there are well defined interfaces with substandard implementations, it won't matter too much. Once a better library comes out, I can just relink and use it.
Imagine being able to write the following:Yes, this is simplified and based on Java's GUI model, but you get the idea. No imagine that you could write to this API (or one like it) and plug in Qt, GTK, MFC, or whatever.
I don't want the ultimate graphics library (UGL); I want the ultimate graphics interface (UGI) into which I can plug in the UGL.
I am in total agreement with you here. Well said.
Are chemical engineering or mathematics tracks less in-depth or less focused than computer science? I don't think so.
My point was that there is no inherent aspect of women/girls that makes CIS/CS/CE an untenable field of study. The differences are mainly social or difficiencies in the way CS programs are run.
Yes except that people will start writing code to those C libraries and build a mountain of code that has no consistency. Even if there are native D libraries, what benefit would it give if there are three different interfaces for database access? D doesn't need to implement everything. Software darwinism is a good thing. But at least specify the interfaces!
.NET). Why? Does Sun write every database driver out there? No. They wrote a database API interface almost from the beginning to which vendors could write their own implementations. The obvious standard made ad hoc interfaces seem ridiculous. And rightly so!
Otherwise I will have to do the market research to determine which API I will code to. I don't have to do this in Java (or
Imagine what C++ would have been like if it didn't have be compatible with C. Unfortunately, that similarity was the only way that it could get a foothold and get used.
D, on the other hand, is not prentending to be "C with classes" or "C only better." A D compiler cannot compile C or C++. I applaud the author for making the clean break and taking only the parts of C and C++ (and Java) that make sense. But as soon as the tutorials pop up in Dr. Dobbs and various online venues that teach OpenGL programming with D as linkage to the C library, D is screwed.
Modern C++ can do so many things, but because of the C baggage, it is constantly held back. 95% of the time, you should never use char* for strings in C++. std::string makes much more sense in almost every way. It's easier to use, consistent with the STL, and about as fast as char*. There is so much code out there that uses char*, however, that std::string adoption (and std::list, std::map, std::vector, etc.) has been unreasonably slow.
Don't underestimate inertia. D should try to stay out of the limelight as long as possible so that these design issues can be worked out. Otherwise you'll end up seeing ad hoc implementations of every major feature with no consistency. And we will be right back where we started -- only with a new name to our troubles.
but in fields such as biology, mathematics, physics, engineering, etc., women are commonly anywhere from 40% to 60% of the division population. Then we look at CS where the number drops precipitously.
There are indeed differences, but the tenacity for in-depth knowledge in a subject is not the difference. Or were you going to say that math was not requiring an in-depth knowledge. Perhaps biology is just four or five years of fluff. Oh, I know! All of those women who are receiving medical degrees are just coasting along with no in-depth knowledge.
And just to pick apart that "concentrating on a single thing for long periods of time," I have just one word: mother.
Yet another way to write and manipulate ints, floats, struct, and classes.
Why don't people put as much effort into designing standardized interfaces for networking, threading, forking, database access, distributed logic, graphics, etc.
He goes on and on about how we need unified syntaxes for unit testing, inline assembly, assertions, etc., but is curiously silent with regard to the above issues.
What are the killer apps? Apache? OpenLDAP? OpenOffice? Mozilla? Konqueror? Photoshop? Gimp? Quake? Neverwinter Nights? Crystal Reports? Gaim?
Now with that list in mind, how does D make anyone's life simpler? Need a TCP/IP socket? Sure! Just use the POSIX one...unless you're on Windows...or coding for BeOS... What about talking to a database? Well there's ODBC implementation #1, ODBC implementation #2, native database-specific API #1, etc. Well at least there's graphics right? OpenGL all the way...except when you need DirectX...or the framebuffer interface... And for GUI libraries, we have GTK+, Qt, FLTK, MFC, XUL, etc. Along those lines, do you use Gnome or KDE for your object model? Do I write to libxml or use some COM wrapper for MSXML3.DOMDocument?
What good is uniformity in a complex type when anything I want to do with the language that implements it requires an unending list of non-D libraries that throw uniformity out of the window? Please explain to me how my life is enriched by this language? Please explain how solves more problems than it creates?
Sure Java, Python, et al have their share of problems, but at least I can open a socket or a filehandle without doing market research on libraries first. At least code written in those languages is readable by someone who knows the language. Database calls look the same no matter your operating system. That's what I want. Not just some new and exciting method for representing imaginary numbers.
And while we're talking about data types, he writes at length about how ints, longs, floats, etc. are all well-defined sizes unlike in C even though saying int16, int32, and int64 would be much easier to read and helpful. In addition, while the other types are well-defined and char is well-defined as a single 8-bit byte, wchar is sometimes 2 bytes, sometimes 4 bytes, and could be something else in the future depending on the wind. Ask the i18n coders about their experiences with wchar_t. Most end up using an avalanche of #ifdefs or just sidestep it altogether with their own array of bytes. Why? Because sometimes they're using UTF-16 and other times it is UCS4. You need to know how big the character type is! It's not something you leave up in the air! char16...char32... Are these too much to ask for?
I hope to god that no one actually adopts D for real work in the near future. If they do, they will run into the limitations I mentioned above and figure out some hack to get it to work. Hack begets hack begets hack and you are left with another bloated language lacking uniformity that people will bitch about on tech discussion boards. And then some person will say, "Hey! I've got this new language that fixes all of those inconsistencies with D that we all hate."
1. Wash
2. Rinse
3. Repeat
This is the DOM Level 2 spec as applied to HTML and XHTML.
From the DOM Level 2 HTML recommendation:
Same thing goes for DOM2. Does any browser support all of that spec? No. Do Opera, Mozilla, IE, Konqueror, etc. support most of the common DOM 2 idioms? Yes.
With regard to CSS 2 support, yes, there is a great variability in support. But every browser in common desktop use supportsand that's in the CSS 2 spec. I use that all of the time. 100% support is nice, but lacking that, 75% will work in a pinch. 75% isn't great, but it's a damn sight better than 0% standards support.
For example:Technically correct and it compiles, but it doesn't do what you would necessarily want it to do. Testing against IE is most definitely not testing against a W3C standard for rendering. IE has its share of bugs too -- sometimes bugs that only show up when viewed in another possibly more standards-compliant browser.
And why dump XHTML (I'm assuming "strict") for HTML 4.01 transitional? They are basically the same thing only XHTML transitional is well-formed XML. Since you already went through the trouble of making the site well-formed, why dump it for HTML? That's like saving up money for a BMW, not ending up with enough money, and choosing a used Ford Pinto. What about the middle ground?
Thanks for not reading the sentence after that... *sigh*
If your goal is the greatest number of eyeballs with your scripting web site, using the DOM will reach more eyeballs than document.all. That's orthogonal to IE's market dominance.
98% is greater than 95%. So code to the 98%.
document.all = 95%
DOM = 98%
And in the future, that DOM percentage will approach 100% in every reasonable case (whether Mozilla becomes more popular or not) because of full support in IE -- that market-dominating browser you love so much. document.all could either gain in share (if IE dominance extends itself) or it could drop in share (if alternate browsers get a foothold, AOL moves forward with their Gecko-based client to Windows, and Microsoft doesn't deprecate the document.all API).
The DOM simply makes sense. document.all is potentially a limiting factor.
It's a bad API. So was NS4's layer API. The W3C DOM is a better API. It is clear, concise, well-documented, and supported by more browsers in use today than document.all(!!!).
More people use Mozilla, Netscape 6+, and the other Gecko-based browsers now than IE4- and Netscape 4 combined. The recent IE browser version support the DOM API in its entirety. If you code to the DOM spec instead of document.all, you will get more browsers than by using document.all. The "du jour" solution has greater penetration than your de facto solution. Why code for 95% when you could have 99%?
By all means, go to Microsoft's own tech documentation site, select "APIs & References" from the search dropdown, and enter in document.all. Go ahead. I dare you. The ONLY documents you will get back relate to the DOM API. Even Microsoft is trying to dump document.all. Go look up the
Fix your scripts now or fix them later. I don't care. But you've backed the wrong horse.
If your goal is eyeballs, standards make more sense. If your goal is simply to avoid fixing your scripts, at least be honest about it. Don't pretend that you are doing for the users' benefit.
No. The word I was "groping" for was dependence. document.all is not a good API. The only reason to implement it is for compatibility with IE.
A lot of pages write to that API. And there's the rub. Having two APIs that do the same thing (the W3C standard way and the Internet Explorer way) confuse new developers as to the correct solution and perpetuate a suboptimal solution. IE 5+ supports that W3C standard API. IE 4 has a smaller marketshare than Mozilla/Netscape at this point.
Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft. I have no problem with it being the most used browser, but I refuse to cede ownership of what I consider a public resource.
Having a standard means that you aren't dependent on one vendor or solution. Having a standard means that if someone comes up with something better, you can use it. If you use the Apache web server and decide to switch to IIS or iPlanet or Zeus you can. Why? Because any browser can talk to any of them. Why? Because they all implement the HTTP standard.
As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse. Sticking with standards is an assertion that the message is more important than the messenger.
You misunderstand. I think that implementing document.all in its entirety is non-trivial. What I was suggesting was that you code in the functionality that you are using currently -- most likely less than the full object hierarchy for document.all. Personally, as I don't use and don't care about document.all, I'm quite pleased that Mozilla developers are concentrating on other items. Remember that Mozilla is Open Source. Features find their way in because someone wants to scratch a personal itch. Perhaps you could get AOL/Netscape to push for the feature, but as they haven't cared thus far, it doesn't seem people are clamouring to pay them for the feature.
A clean API that is used by everyone -- including Microsoft -- makes perfect sense. Just as Microsoft has dropped full support for DOS and Windows 3.x programs, it's time to drop document.all. Backward compatibility is a noble goal but not at the expense of progress. Taking the time to implement it is sinking time into a feature that is already obsolete.
The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it. If you're bitching about it as a scapegoat for your own non-standard scripting, shame on you. If you're bitching about it because a bank site requires document.all, gently remind them that you're giving them your money.