Not having a prepared dissertation ready is perfectly fine. And it's definitely true that people on slashdot occasionally pull facts out of their ass.
I'm not happy about it, but I don't necessarily want to discredit you. I want to read up about it. Background info is after all how we form informed opinions.
Then again, this implementation leaves a great deal of room for optimization on the back end in subsequent versions of the JVM without breaking the interface.
For example, it seems likely to me that Sun (or someone else) would implement a specialization for collections that hold nothing but primitives.
But for now, you're right. For tight memory needs, it's an issue. The introduction of a preprocessor like with fastutil doesn't sit well with me though. Once you start with a preprocessor, #pragma and #ifdef directive hell is sure to follow.
I noticed the URL. For what it's worth, I think Zope/Plone is an excellent web framework. It has some warts that have really frustrated me (usually from 3rd party addons rather than the core), but overall well worth the time examing/using it....and let me tell you, when it works, it's great. When you need to see some API documentation for it, I start wishing for something more like javadoc. Yes, I've seen the automatic documentation from source for Python. While I found the functions easily, the weak typing in Python made what you pass to those function unclear.
That said, the WebDAV support and object management are top notch. I'm glad I chose it for a project. There's no way I could have implemented another solution from start to finish in less than a month without it in any language (even Python).
Sounds like you were trying to code C in Java. In almost every case, less code is required in Java than in C. The same story with Perl. You absolutely cannot make a direct translation. Between Perl and C, the lines are pretty clear. Between Java and C however, the differences between the two can really come around to bite you in the ass.
Think of Spanish versus English. If I were to say, "Me duelen los pies," any Spanish speaker would understand what I was talking about. Let's make a direct translation to English: "Me they hurt the feet." Given sufficient patience, an English speaker could figure out what you were talking about, but it's definitely not clear. "Oh!" you say in English, "you mean, 'My feet hurt.'" To which the literal translater passes back to the Spanish speaker, "Mis pies duelen." To which the Spanish speaker recoils half expecting you to kick him. Humor ensues.
String is not just a sequence of bytes (and characters are two bytes long, not one or variable). Vector/ArrayList reallocations double the memory when it gets full (just like std::vector). Vector/ArrayList are effectively the same speed as a fixed size array, so avoiding them for efficiency is usually pointless (like std::vector). "instanceof" is slow. Reflection is slower. Reuse of long-lived objects is important. I/O should almost always be buffered.
Coming from C (and getting past the initial horror of Strings getting concatenated with the '+' operator), it looks perfectly fine syntactically and runs like an absolute dog. But just as my earlier English/Spanish example, to a Java programmer, it's obviously a problem. (Perhaps compilers in the future will become smart enough to handle this and more complex items.) Remember, Java String objects are immutable. This example is gratuitously slow because multiple implicit StringBuffer objects are created and destroyed. Use StringBuffer explicitly here instead.
StringBuffer output = new StringBuffer(); for (int i=0;i<1000;++i) {
output.append("key=").append(myKey).append(
";value=").append(myValue).append("\n"); } Syste m.out.println(output);
The reworked version is much faster as the buffer will simply reallocate as space is needed as opposed to recreating and destroying multiple buffers on each loop. However, to inch out a little more speed, we can fall back on some of our old C habits such as preallocating a buffer.
StringBuffer output = new StringBuffer( 16000 ); for (int i=0;i<1000;++i) {
output.append("key=").append(myKey).append(
";value=").append(myValue).append("\n"); } Syste m.out.println(output);
Now dynamic memory allocation is at a minimum. This works if we know that the keys and values are all eight characters or less for example. Well... technically it works even if they're not. It's just that the StringBuffer will reallocate the memory if the buffer fills up (as opposed to getting a buffer overflow in C).
But this is more of the mundane and somewhat cryptic aspects of Java. The reason I like it is the interfaces, pure and simple. When I want a database connection, I don't code for a particular database. I code to the JDBC interfaces. When I want a thread, I don't hunt for a cross platform thread library or choose between POSIX flavors and Win32. I get a Thread. When I want to work with XML, I use the W3C DOM interfaces or SAX interfaces. The databases may change. The operating systems may change. The parsers may change. But the interfaces stay the same. If I need to use database-specific features, I can. But it is abundantly clear in the code what is the standard inteface and what is a driver extension.
Then there's javadoc. Once you get used to one set of documentation, you've gotten used to them all. If yo
Pad programmers in any paradigm create muddy holes, not the paradigm. Some paradigms just make it easier to avoid the muddy holes.
Just as is the case with young children, some programmers just don't get why the older folks avoid the mud. After they have to clean the mess themselves for a change, avoiding the mud becomes important for them too.
It sounds to me like an issue with web development in general (tables or not) than with CSS. The real difference is how much control you have over the server than the client in case.
And separate libraries keep it even more compartmentalized. My networking library requires no knowledge of my hash table or linked list. With one library like Java's, to know one part you need to know a large chunk of it. Part of it is the ridiculous depth of the hierarchy they use, part of it is due to the high degree of cross-linkng between sections.
So you're saying that if a networking library requires a linked list or hashtable it should roll its own rather than reusing an existing, efficient implementation?
Also, your example seems contrived. Please show me where I need to access a linked list from within the classes in java.net. Will some List implementation be loaded by the classloader in your networking program? Probably, but not by the networking packages. If it's loaded, it's because the programmer needed a List.
Also, a JVM will likely have quite a few *.so files lurking in the background. Unless the classes that need the native support are loaded by the classloader, the loadlibrary call is never called for them. Class definitions aren't loaded into memory unless they're used.
THe point is that projects don't need the 1500 classes. THey'd be better off downloading libraries that just do what they need. Chances are those libraries will do a better job than the one size fits all standard library.
You'd advocate splitting off the string handling functions of the standard C library from the other functions? Sure, it's a different header file, but it's the same *.so file. After all, all I need to do in my program is tokenize a string and spit it back to the console. Why should I have to map a 1.2MB library just for that? (By the way, I was being facetious.)
As for reinventing the wheel and no standardization- no, you search the web, find libraries, or go to a library repository to find one. No reinventing needed, and I've never had a problem to have standardization. Of course, maybe I'm just a better programmmer than you.
Or maybe you enjoy dealing with twenty different ways of threading. And if you point to your one favorite threading library, do you use that same library on UNIX, Mac, et al.? Or are you the type that states that threading has no place in software -- a fork is the only true way kinda guy. What about database access? ODBC or do you code each and every database separately? (Then again, with ODBC, you have to make enough special cases that indeed you do code each and every database somewhat differently.)
My point is these are solved problems. And for that matter, there is nothing stopping a person from writing their own linked list or hashtable implementation. Nothing. Why doesn't anyone? Because over and over what has been seen is that the standard ones are either (a) better or (b) good enough that the extra effort isn't worth it. I know that (b) probably upsets you, but if my project isn't about hashtables and the difference between the two implementations would have a negligible impact on the overall project, it's not worth doing. Reinventing the wheel in this case is what KILLS innovation.
The best comparison is- Java's library is McDonalds. Its edible, you can get by on it, but it isn't very good.
Enough hyperbole. Please show me where the JSL is deficient. Let's debate specifics.
There's been improvements on even simple stuff like strings that has improved average performance in the past 5 years. COW is one that's come into use. Similar techniques have popped up in hash tables and lists. FOr large tables and lists, a library using modern techniques is at least 10% better than it was 5 years ago.
It's funny you should mention that. I'm assuming you are talking about C++'s std::string and using type traits and template parameters to make appropriate forms of strings for the task at hand. (See, I read Modern C++ Design and Dr. Dobbs too.) First,
1. Classes are encapsulations of logic (variables and functions). What was once a shared library on its own can be distilled to one or a few classes. If each class had about five methods (functions) and two static properties (variables), the equivalent code body would be 7,500 functions and 3,000 global variables. Since classes/objects (and packages!) keep similar functionality compartmentalized, it's actually easier to keep a significant chunk in mind. Interfaces (method definitions without implementation) make it even easier. Personally I haven't had a problem keeping the packages I use on a project straight in my mind. But then, maybe I'm just smarter than you.
2. The smaller the library, the less it does. What's your point? At the end of the day, when your project (without objects or a complete standard library) is finally ready, you have linked to quite a few shared libraries, reinvented the wheel twice, and have very little standardized that would be recognized by the next person who comes to maintain the project.
The more the standard library does, the less code (with bugs) you have to write and maintain. The great part about the standard library is that since everyone is using it, everyone's finding and fixing the bugs together. That said, the Java standard library has been extremely solid for me. What bugs have you run into habitually? You do have some examples right?
There is no requirement that a developer use all features of a standard library any more than it's required that a developer use every interface defined by POSIX in every project. But in both cases, it's nice to know the standard interface for your next project is there.
3. Yes, better to compartmentalize items. Make separate components. Put them in... ummm... PACKAGES. Yeah, that's it. That way I can keep my general utilities and basic data structures separate from my I/O routines which are kept away from my database layer and my GUI and... java.util, java.io, java.sql, java.awt, etc. So what's the problem?
Huge projects like C's standard library and the hodgepodge of 3rd party libraries end up producing subpar code. Your point?
4. Yes! Because Java hasn't changed in the last ten years at all. Pray tell, what innovations were you speaking of? The innovation of yet another person making yet another linked list or hashtable tailored exactly for their needs? (Wee! This keeps a specific type of object in 1KB less per thousand objects than the standard! I am 7331!) You want to talk about innovation? C and C++ coders couldn't get together to decent database abstraction layer. ODBC (although more specifically the drivers written for that vague standard) is such a piece of crap, people started actually thinking datasource abstraction was a bad idea. What about the fact that few C or C++ (or LISP or Perl...) coders bothered to make documentation at all let alone generate it from the source code itself until javadoc came along. Now it's all "we have that too!"
If you're spending all your time reinventing the wheel, when do you have time to make something new?...to innovate? Innovation comes when you don't have to reinvent the wheel and can concentrate on the task at hand (which probably isn't determining the next new hashtable implementation).
5. Nothing says innovation quite like "Fuck! The library changed interfaces again. Alright, let's go back, fix stuff, and rebuild again." In Java, you can remove/change things as well. It's this thing called "deprecation." Perhaps you've heard of it. It's present in other languages as well. You tell people that something is changing/going away and then later on you change it or make it go away.
But then, more often than not, keeping the old code around doesn't hurt anything, it just doesn't change. So tell me, how many versions of the standard C library do you have around? And that's just one library! By comparison, the definitions for String and StringBuffer, two fundamental cl
After making a site WAI-AAA compliant (temporarily), I am aware of the issues you've brought up. I agree with you about Jaws and absolutely believe that if they made developer toolkits for little to no cost, more sites would be accessible.
That said, content-driven sites that rely on Flash are an oxymoron. What I have found is that JavaScript should be used for form validation and data hiding (on a content-driven site). This means that the text reader in the worst case scenario gets more information rather than less than their visually-oriented counterpart.
You have some sympathy from me about the users of DreamWeaver and FrontPage, but since you are getting paid for it, not that much. It's drudgery, but that's why it's called "work." If your users outputted HTML directly from Word or Excel, it would suck for you more, but it doesn't detract from the need for accessibility. In fact, in accentuates the need.
If the ADA provides a reason for companies to demand accessibility-friendly tools, I am all for it. Will it cause pain? Surely it will. Is the pain worth it? I believe it is.
Your argument was that 100% accessibility (especially in your strict, academic environment) is prohibitively difficult. My argument was that the bar is so much lower than that in the "real" world, that even minor accomodation of accessibility (such as well-formed, valid markup including alt attributes and form labels) would be an improvement.
I agree with you partly, but "place of public accommodation" not applying to a web site? You will forgive me if I don't consider websites fitting that definition an extension any more than the first amendment applying to a telephone conversation an extension. The intent seems clear even if technological advancement makes the original wording seem vague.
The ADA was passed so that those with various disabilities could function independantly in our society and take advantage of the goods and services available to everyone else. With more and more time spent online, I don't see how stripping the visually impaired of these goods and services at a whim (or through laziness or inaction) is somehow consistent with the ADA.
To simply wave your hands and say that "the Internet" is a public space would be overly broad. Very precise categorizations of what sites the ADA applies to need to be created. As private homes are not covered by the ADA, neither should private home pages. Accessibility is a good thing, but it can be too much work for some private webmasters to try to overhaul.
The ADA concerns commercial (and government) entities and not private residences and the like as you say. If an entity is governed by the ADA when they are constructing a building, why are these rules not applied to websites?
If Jane Doe has a vanity website taking about her cats, I do not see how it is ambiguous. Perhaps if someone is writing for free and puts up a PayPal link, this could be fuzzy. But Southwest Airlines? Is there any ambiguity about their commercial status?
Instead of throwing the baby out with the bathwater, why not treat the clear cases with established rules and punt only on the ambiguous ones?
Blogs are not affected by this. This is not some cut and dried freedom of speech argument. Businesses have government-imposed limits all the time -- ADA guidelines for access into and out of a building for example. As far as free speech goes, businesses are not allowed to say that their hair dryer cures cancer. Is this an abridgement of free speech.
Accessibility in (commercial) web sites is not restraining speech; it's adding more content. Accessibility is not about removing images. It's about adding meaningful alt attributes to those images. How is free speech hurt by adding labels to forms -- which incidentally can be removed with CSS so that precious aesthetics are not lost but screen readers can still use.
Take a look at the W3C accessibility checklist. Of the three levels, the first is downright simple. Level three is definitely more work, but with a visually impaired tester or two and XHTML+CSS, it's more than possible for all but the smallest of businesses with an online outlet.
But in answer to your question, yes, I would lay money that the congressmen who voted for the ADA would have included commercial web sites had they known about them.
The wording doesn't support my position because it only explicitly lists physical places like restaurants? Maybe this is because interaction with businesses was only possible physically prior to 1995 (or so). Accessible websites are the cheapest, simplest, and one of the most straightforward ways to make a business usable by the physically disabled. To say that businesses have to put in a concrete ramp so that those with wheelchairs can get access -- even if they are less than 1% of the customers -- but a website can be completely inaccessible for the visually impaired is lunacy.
Point #1: Southwest was offering special deals over the Internet that are not available via phone or other alternative. This means they were offering a commercial service that notably excluded the visually impaired from taking advantage simply because they were visually impaired.
Point #2: Southwest has since revamped the website so that this is no longer the case. For something that squelches free speech or would be prohibitively expensive, they sure fixed the problem quickly while keeping the same look for fully-sighted users.
Is it more effort than not worrying about accessibility at all? Certainly! But "easier" wasn't the point of the ADA and shouldn't be the primary point for web accessibility.
...but since web designers often don't focus sufficiently on the information, regulations are perhaps necessary. This isn't dictating an exact format for a page. This is simply laying down some basic guidelines on top of which the web designer is free to do as he or she pleases. Just adding alt attributes to images and clearly defined form elements solves 99% of major accessibility issues. Compared to installing a concrete ramp as an alternate entrance/exit to a building, the cost of web accessibility is peanuts.
The court cited the fact that the Internet wasn't listed in the 1991 law....which of course is to be expected since lawmakers would have been unaware of anything called the Internet back in 1991. To assert that the Internet is not a "place of public accomodation" is lunacy considering the ever-increasing amount of goods and services available over the Internet and amount of time the average American spends online.
Considering the fact that the ADA covers such items as cement walkways without overly tight turns and the installation of elevators, I find it hard to believe that the comparatively inexpensive addition of alt attributes to images and clearly defined form elements constitutes an undue burden on businesses and the web at large. I also find it hard to believe that exclusion of the Internet and Internet-related facilities from the ADA is consistent with the spirit of the law as written in 1991. Does anyone truly believe that if common knowledge of the Internet existed back in 1991 that the ADA would not have included it in its guidelines and requirements?
The Whiskey Bar is absolutely wonderful. Well written. Great op-ed. Fact checking up the wazoo -- something sorely missing from most blogs. The guy definitely knows what true journalism is. Unfortunately, the site's been silent for the last month.
Check the archives though. It's worth it. It'll take weeks just to read through it all and each one is as good as the last.
This material you speak of has a substantially shorter period of time where it is dangerous to humans. When nuclear vessels are decommissioned, they are indeed radioactive, but not for thousands of years. The halflives are closer to 5 years and after 10 halflives is no longer dangerous. 50 years is not too long to store these items. They aren't that abundant or voluminous. And they can't be made into nuclear bombs.
Some rudimentary lessons in nuclear radiation. Radioactive decay is measured in the number of particles that are emmitted -- helium isotopes in the case of alpha radiation, electrons in the case of beta radiation, and photons in the case of gamma. In a given mass, there are a limited number of decays possible as matter doesn't just appear out of nowhere; it must come from somewhere. If it comes from the radioactive source, the mass of that radioactive source decreases. Therefore the faster the decay rate, the more dangerous it is. The slower the decay rate, the lower the danger. This is a gross simplification, but the overall principle is correct. So if something has a 10,000 year halflife, it isn't emitting as much radiation as another item of equal mass with a halflife of one week.
Psycho-social effects among those affected by the accident have been the major problem, and are similar to those arising from other major disasters such as earthquakes, floods and fires.
The most recent and authoritative UN report has confirmed that there is no scientific evidence of any significant radiation-related health effects to most people exposed to the Chernobyl disaster. The UNSCEAR* 2000 Report is consistent with earlier WHO findings. The report points to some 1,800 cases of thyroid cancer, but "apart from this increase, there is no evidence of a major public health impact attributable to radiation exposure 14 years after the accident. There is no scientific evidence of increases in overall cancer incidence or mortality or in non-malignant disorders that could be related to radiation exposure." As yet there is little evidence of any increase in leukaemia, even among clean-up workers where it might be most expected. However, these workers remain at increased risk of cancer in the long term.
Some exaggerated figures have been published regarding the death toll attributable to the Chernobyl disaster. A publication by the UN Office for the Coordination of Humanitarian Affairs (OCHA) entitled Chernobyl - a continuing catastrophe lent support to these. However, the Chairman of UNSCEAR made it clear that "this report is full of unsubstantiated statements that have no support in scientific assessments."
* the United Nations Scientific Commission on the Effects of Atomic Radiation, which is the UN body with a mandate from the General Assembly to assess and report levels and health effects of exposure to ionizing radiation.
You can read the report yourself. If you find errors in it, feel free to point them out.
Sources and Effects of Ionizing Radiation,
United Nations Scientific Committee on the Effects of Atomic Radiation,
UNSCEAR 2000 Report to the General Assembly, with Scientific Annexes, Volume 2: Effects,
Annex J (106 pp)
ISBN : 92-1-422396
Those are my sources. What are the BBC's? Do you have your own or are you relying on that one BBC article?
I'd like to see your source for this stat please. I have read very different things.
Since every square meter of solar panel will only ever collect less than 1.367kW (and commonly convert far less), the costs of manufacture don't seem to match up with your recoup estimates.
This is the same as the nuclear industry saying "look, concrete is radioactive, so you don't need to worry about the additional background radation added to the environment because percentagewise it's about the same as the radioactivity of concrete." Even if this is true, it implies a doubling of the background level of radiation, so it's a misleading argument.
Without radiation, we would not be here. It's fundamental to species diversity
The human body is surprisingly adaptable to low levels of radiation
The radiation outside of nuclear plants is normally much lower than what is found in nature. Nuclear power stations are usual located in areas with an already low amount of ambient radiation
We normally receive about 200-300 mrems of radiation each and every year including the 20mrems or so we get from potassium isotopes in our own blood
You will receive more radiation every year if you live in high altitudes
Taking an international flight will likely expose you to more radiation than living ten years near a nuclear power plant
Nuclear plants are allowed to emit less than 10-15 mrems of radiation every year at a constant rate. Usually this number is below 5 mrems
Maximum safe dosage (over a year) of radiation is estimated at about 10 rems (10,000 mrems). Healthy adults can usually deal with more
Problems due to iodine radioactive isotopes can be mitigated with treatment although the ones most at risk are young children
No large scale energy production is absolutely safe
On the last point I'm sure we are in complete agreement.
A nuclear disaster would be devastating for human nations, but the ecosystem(s) involved would recover.
As opposed to a natural gas disaster or coal disaster? On land used for oil refineries, the cost of cleanup is much greater than the value of the land itself. This is true even in areas where the land would otherwise fetch top dollar. And this is when everything goes right!
Coal veins can catch fire in the ground and burn for decades.
Nuclear power plant designs in Western Europe and North America haven't had any "disaster" level accidents. Note: Sellafield was primarily for weapons and Three Mile Island had zero civilian casualties or health problems. Japan has had an accident where the population had to be relocated temporarily if memory serves, but no worse than when fossil fuel stockpiles go boom. At least with modern nuclear designs, you get some advance warning. With fossil fuels, a spark can lead to immediate problems.
As for fusion as opposed to fission, sure fusion is better. The only small detail is that we can't do it right now. It's not currently an option. Fission is.
I just restarted my browser, navigated to a few sites with a bunch of open windows and tabs, and checked memory usage. Firefox is sucking up some RAM, but I accept that since the alternative is browsing the web with a browser that doesn't render as quickly or as well.
Then I went to the site with the Theora stream. Memory went up, but not by much -- especially when compared to the total browser footprint. After all is said and done, I'm looking at a 160MB chunk of memory for the browser, all of the windows, the JVM, and the video stream. Considering that I have 512MB in the box and RAM is cheap enough that 512MB more isn't out of the question, I don't much care.
Bottom line: it doesn't matter so much how much RAM is used up with regard to "bloat." Just as with most engineering problems, what matters is that I am able to use the computer. If I am using less memory than I have available to me, it doesn't matter if it's a little less or a lot less. If I can't see an overall slowdown in the system (and I can't), then by definition it's not an issue.
I'll trade increased memory footprint for buffer overflows any day of the week and most sundays. As far as people playing "little java games online and wonder[ing] why their internet is slow," I can name more than a few games written in C, C++, Pascal, etc. (and assembly for that matter) that were slower than molasses -- and many of them weren't even network aware nor did the graphics look that good.
Surprise! Bad code runs slowly. The Theora streaming applet loads and runs quickly. Surprise! Good code runs quickly.
Don't paint all Java programs with the same brush.
Slashdot Mirror
That is the funniest thing I've seen on Slashdot in a long long time.
Not having a prepared dissertation ready is perfectly fine. And it's definitely true that people on slashdot occasionally pull facts out of their ass.
I'm not happy about it, but I don't necessarily want to discredit you. I want to read up about it. Background info is after all how we form informed opinions.
Then again, this implementation leaves a great deal of room for optimization on the back end in subsequent versions of the JVM without breaking the interface.
For example, it seems likely to me that Sun (or someone else) would implement a specialization for collections that hold nothing but primitives.
But for now, you're right. For tight memory needs, it's an issue. The introduction of a preprocessor like with fastutil doesn't sit well with me though. Once you start with a preprocessor, #pragma and #ifdef directive hell is sure to follow.
I noticed the URL. For what it's worth, I think Zope/Plone is an excellent web framework. It has some warts that have really frustrated me (usually from 3rd party addons rather than the core), but overall well worth the time examing/using it. ...and let me tell you, when it works, it's great. When you need to see some API documentation for it, I start wishing for something more like javadoc. Yes, I've seen the automatic documentation from source for Python. While I found the functions easily, the weak typing in Python made what you pass to those function unclear.
That said, the WebDAV support and object management are top notch. I'm glad I chose it for a project. There's no way I could have implemented another solution from start to finish in less than a month without it in any language (even Python).
Sounds like you were trying to code C in Java. In almost every case, less code is required in Java than in C. The same story with Perl. You absolutely cannot make a direct translation. Between Perl and C, the lines are pretty clear. Between Java and C however, the differences between the two can really come around to bite you in the ass.
Think of Spanish versus English. If I were to say, "Me duelen los pies," any Spanish speaker would understand what I was talking about. Let's make a direct translation to English: "Me they hurt the feet." Given sufficient patience, an English speaker could figure out what you were talking about, but it's definitely not clear. "Oh!" you say in English, "you mean, 'My feet hurt.'" To which the literal translater passes back to the Spanish speaker, "Mis pies duelen." To which the Spanish speaker recoils half expecting you to kick him. Humor ensues.
String is not just a sequence of bytes (and characters are two bytes long, not one or variable). Vector/ArrayList reallocations double the memory when it gets full (just like std::vector). Vector/ArrayList are effectively the same speed as a fixed size array, so avoiding them for efficiency is usually pointless (like std::vector). "instanceof" is slow. Reflection is slower. Reuse of long-lived objects is important. I/O should almost always be buffered.
String output = "";
for (int i=0;i<1000;++i) {
output += "key=" + myKey + ";value=" + myValue + "\n";
}
System.out.println(output);
Coming from C (and getting past the initial horror of Strings getting concatenated with the '+' operator), it looks perfectly fine syntactically and runs like an absolute dog. But just as my earlier English/Spanish example, to a Java programmer, it's obviously a problem. (Perhaps compilers in the future will become smart enough to handle this and more complex items.) Remember, Java String objects are immutable. This example is gratuitously slow because multiple implicit StringBuffer objects are created and destroyed. Use StringBuffer explicitly here instead.
StringBuffer output = new StringBuffer();
for (int i=0;i<1000;++i) {
output.append("key=").append(myKey).append(
";value=").append(myValue).append("\n");
}
Syste m.out.println(output);
The reworked version is much faster as the buffer will simply reallocate as space is needed as opposed to recreating and destroying multiple buffers on each loop. However, to inch out a little more speed, we can fall back on some of our old C habits such as preallocating a buffer.
StringBuffer output = new StringBuffer( 16000 );
for (int i=0;i<1000;++i) {
output.append("key=").append(myKey).append(
";value=").append(myValue).append("\n");
}
Syste m.out.println(output);
Now dynamic memory allocation is at a minimum. This works if we know that the keys and values are all eight characters or less for example. Well... technically it works even if they're not. It's just that the StringBuffer will reallocate the memory if the buffer fills up (as opposed to getting a buffer overflow in C).
But this is more of the mundane and somewhat cryptic aspects of Java. The reason I like it is the interfaces, pure and simple. When I want a database connection, I don't code for a particular database. I code to the JDBC interfaces. When I want a thread, I don't hunt for a cross platform thread library or choose between POSIX flavors and Win32. I get a Thread. When I want to work with XML, I use the W3C DOM interfaces or SAX interfaces. The databases may change. The operating systems may change. The parsers may change. But the interfaces stay the same. If I need to use database-specific features, I can. But it is abundantly clear in the code what is the standard inteface and what is a driver extension.
Then there's javadoc. Once you get used to one set of documentation, you've gotten used to them all. If yo
Pad programmers in any paradigm create muddy holes, not the paradigm. Some paradigms just make it easier to avoid the muddy holes.
Just as is the case with young children, some programmers just don't get why the older folks avoid the mud. After they have to clean the mess themselves for a change, avoiding the mud becomes important for them too.
It sounds to me like an issue with web development in general (tables or not) than with CSS. The real difference is how much control you have over the server than the client in case.
Sources please.
So you're saying that if a networking library requires a linked list or hashtable it should roll its own rather than reusing an existing, efficient implementation?
Also, your example seems contrived. Please show me where I need to access a linked list from within the classes in java.net. Will some List implementation be loaded by the classloader in your networking program? Probably, but not by the networking packages. If it's loaded, it's because the programmer needed a List.
Also, a JVM will likely have quite a few *.so files lurking in the background. Unless the classes that need the native support are loaded by the classloader, the loadlibrary call is never called for them. Class definitions aren't loaded into memory unless they're used.
You'd advocate splitting off the string handling functions of the standard C library from the other functions? Sure, it's a different header file, but it's the same *.so file. After all, all I need to do in my program is tokenize a string and spit it back to the console. Why should I have to map a 1.2MB library just for that? (By the way, I was being facetious.)
Or maybe you enjoy dealing with twenty different ways of threading. And if you point to your one favorite threading library, do you use that same library on UNIX, Mac, et al.? Or are you the type that states that threading has no place in software -- a fork is the only true way kinda guy. What about database access? ODBC or do you code each and every database separately? (Then again, with ODBC, you have to make enough special cases that indeed you do code each and every database somewhat differently.)
My point is these are solved problems. And for that matter, there is nothing stopping a person from writing their own linked list or hashtable implementation. Nothing. Why doesn't anyone? Because over and over what has been seen is that the standard ones are either (a) better or (b) good enough that the extra effort isn't worth it. I know that (b) probably upsets you, but if my project isn't about hashtables and the difference between the two implementations would have a negligible impact on the overall project, it's not worth doing. Reinventing the wheel in this case is what KILLS innovation.
Enough hyperbole. Please show me where the JSL is deficient. Let's debate specifics.
It's funny you should mention that. I'm assuming you are talking about C++'s std::string and using type traits and template parameters to make appropriate forms of strings for the task at hand. (See, I read Modern C++ Design and Dr. Dobbs too.) First,
1. Classes are encapsulations of logic (variables and functions). What was once a shared library on its own can be distilled to one or a few classes. If each class had about five methods (functions) and two static properties (variables), the equivalent code body would be 7,500 functions and 3,000 global variables. Since classes/objects (and packages!) keep similar functionality compartmentalized, it's actually easier to keep a significant chunk in mind. Interfaces (method definitions without implementation) make it even easier. Personally I haven't had a problem keeping the packages I use on a project straight in my mind. But then, maybe I'm just smarter than you.
...to innovate? Innovation comes when you don't have to reinvent the wheel and can concentrate on the task at hand (which probably isn't determining the next new hashtable implementation).
2. The smaller the library, the less it does. What's your point? At the end of the day, when your project (without objects or a complete standard library) is finally ready, you have linked to quite a few shared libraries, reinvented the wheel twice, and have very little standardized that would be recognized by the next person who comes to maintain the project.
The more the standard library does, the less code (with bugs) you have to write and maintain. The great part about the standard library is that since everyone is using it, everyone's finding and fixing the bugs together. That said, the Java standard library has been extremely solid for me. What bugs have you run into habitually? You do have some examples right?
There is no requirement that a developer use all features of a standard library any more than it's required that a developer use every interface defined by POSIX in every project. But in both cases, it's nice to know the standard interface for your next project is there.
3. Yes, better to compartmentalize items. Make separate components. Put them in... ummm... PACKAGES. Yeah, that's it. That way I can keep my general utilities and basic data structures separate from my I/O routines which are kept away from my database layer and my GUI and... java.util, java.io, java.sql, java.awt, etc. So what's the problem?
Huge projects like C's standard library and the hodgepodge of 3rd party libraries end up producing subpar code. Your point?
4. Yes! Because Java hasn't changed in the last ten years at all. Pray tell, what innovations were you speaking of? The innovation of yet another person making yet another linked list or hashtable tailored exactly for their needs? (Wee! This keeps a specific type of object in 1KB less per thousand objects than the standard! I am 7331!) You want to talk about innovation? C and C++ coders couldn't get together to decent database abstraction layer. ODBC (although more specifically the drivers written for that vague standard) is such a piece of crap, people started actually thinking datasource abstraction was a bad idea. What about the fact that few C or C++ (or LISP or Perl...) coders bothered to make documentation at all let alone generate it from the source code itself until javadoc came along. Now it's all "we have that too!"
If you're spending all your time reinventing the wheel, when do you have time to make something new?
5. Nothing says innovation quite like "Fuck! The library changed interfaces again. Alright, let's go back, fix stuff, and rebuild again." In Java, you can remove/change things as well. It's this thing called "deprecation." Perhaps you've heard of it. It's present in other languages as well. You tell people that something is changing/going away and then later on you change it or make it go away.
But then, more often than not, keeping the old code around doesn't hurt anything, it just doesn't change. So tell me, how many versions of the standard C library do you have around? And that's just one library! By comparison, the definitions for String and StringBuffer, two fundamental cl
After making a site WAI-AAA compliant (temporarily), I am aware of the issues you've brought up. I agree with you about Jaws and absolutely believe that if they made developer toolkits for little to no cost, more sites would be accessible.
That said, content-driven sites that rely on Flash are an oxymoron. What I have found is that JavaScript should be used for form validation and data hiding (on a content-driven site). This means that the text reader in the worst case scenario gets more information rather than less than their visually-oriented counterpart.
You have some sympathy from me about the users of DreamWeaver and FrontPage, but since you are getting paid for it, not that much. It's drudgery, but that's why it's called "work." If your users outputted HTML directly from Word or Excel, it would suck for you more, but it doesn't detract from the need for accessibility. In fact, in accentuates the need.
If the ADA provides a reason for companies to demand accessibility-friendly tools, I am all for it. Will it cause pain? Surely it will. Is the pain worth it? I believe it is.
Your argument was that 100% accessibility (especially in your strict, academic environment) is prohibitively difficult. My argument was that the bar is so much lower than that in the "real" world, that even minor accomodation of accessibility (such as well-formed, valid markup including alt attributes and form labels) would be an improvement.
I agree with you partly, but "place of public accommodation" not applying to a web site? You will forgive me if I don't consider websites fitting that definition an extension any more than the first amendment applying to a telephone conversation an extension. The intent seems clear even if technological advancement makes the original wording seem vague.
The ADA was passed so that those with various disabilities could function independantly in our society and take advantage of the goods and services available to everyone else. With more and more time spent online, I don't see how stripping the visually impaired of these goods and services at a whim (or through laziness or inaction) is somehow consistent with the ADA.
The ADA concerns commercial (and government) entities and not private residences and the like as you say. If an entity is governed by the ADA when they are constructing a building, why are these rules not applied to websites?
If Jane Doe has a vanity website taking about her cats, I do not see how it is ambiguous. Perhaps if someone is writing for free and puts up a PayPal link, this could be fuzzy. But Southwest Airlines? Is there any ambiguity about their commercial status?
Instead of throwing the baby out with the bathwater, why not treat the clear cases with established rules and punt only on the ambiguous ones?
Excellent point.
Blogs are not affected by this. This is not some cut and dried freedom of speech argument. Businesses have government-imposed limits all the time -- ADA guidelines for access into and out of a building for example. As far as free speech goes, businesses are not allowed to say that their hair dryer cures cancer. Is this an abridgement of free speech.
Accessibility in (commercial) web sites is not restraining speech; it's adding more content. Accessibility is not about removing images. It's about adding meaningful alt attributes to those images. How is free speech hurt by adding labels to forms -- which incidentally can be removed with CSS so that precious aesthetics are not lost but screen readers can still use.
Take a look at the W3C accessibility checklist. Of the three levels, the first is downright simple. Level three is definitely more work, but with a visually impaired tester or two and XHTML+CSS, it's more than possible for all but the smallest of businesses with an online outlet.
But in answer to your question, yes, I would lay money that the congressmen who voted for the ADA would have included commercial web sites had they known about them.
The wording doesn't support my position because it only explicitly lists physical places like restaurants? Maybe this is because interaction with businesses was only possible physically prior to 1995 (or so). Accessible websites are the cheapest, simplest, and one of the most straightforward ways to make a business usable by the physically disabled. To say that businesses have to put in a concrete ramp so that those with wheelchairs can get access -- even if they are less than 1% of the customers -- but a website can be completely inaccessible for the visually impaired is lunacy.
Point #1: Southwest was offering special deals over the Internet that are not available via phone or other alternative. This means they were offering a commercial service that notably excluded the visually impaired from taking advantage simply because they were visually impaired.
Point #2: Southwest has since revamped the website so that this is no longer the case. For something that squelches free speech or would be prohibitively expensive, they sure fixed the problem quickly while keeping the same look for fully-sighted users.
Is it more effort than not worrying about accessibility at all? Certainly! But "easier" wasn't the point of the ADA and shouldn't be the primary point for web accessibility.
...but since web designers often don't focus sufficiently on the information, regulations are perhaps necessary. This isn't dictating an exact format for a page. This is simply laying down some basic guidelines on top of which the web designer is free to do as he or she pleases. Just adding alt attributes to images and clearly defined form elements solves 99% of major accessibility issues. Compared to installing a concrete ramp as an alternate entrance/exit to a building, the cost of web accessibility is peanuts.
The court cited the fact that the Internet wasn't listed in the 1991 law. ...which of course is to be expected since lawmakers would have been unaware of anything called the Internet back in 1991. To assert that the Internet is not a "place of public accomodation" is lunacy considering the ever-increasing amount of goods and services available over the Internet and amount of time the average American spends online.
Considering the fact that the ADA covers such items as cement walkways without overly tight turns and the installation of elevators, I find it hard to believe that the comparatively inexpensive addition of alt attributes to images and clearly defined form elements constitutes an undue burden on businesses and the web at large. I also find it hard to believe that exclusion of the Internet and Internet-related facilities from the ADA is consistent with the spirit of the law as written in 1991. Does anyone truly believe that if common knowledge of the Internet existed back in 1991 that the ADA would not have included it in its guidelines and requirements?
The Whiskey Bar is absolutely wonderful. Well written. Great op-ed. Fact checking up the wazoo -- something sorely missing from most blogs. The guy definitely knows what true journalism is. Unfortunately, the site's been silent for the last month.
Check the archives though. It's worth it. It'll take weeks just to read through it all and each one is as good as the last.
I want to see a reputable journal with a reputable study.
This material you speak of has a substantially shorter period of time where it is dangerous to humans. When nuclear vessels are decommissioned, they are indeed radioactive, but not for thousands of years. The halflives are closer to 5 years and after 10 halflives is no longer dangerous. 50 years is not too long to store these items. They aren't that abundant or voluminous. And they can't be made into nuclear bombs.
You can read the report yourself. If you find errors in it, feel free to point them out.
Those are my sources. What are the BBC's? Do you have your own or are you relying on that one BBC article?
I'd like to see your source for this stat please. I have read very different things.
Since every square meter of solar panel will only ever collect less than 1.367kW (and commonly convert far less), the costs of manufacture don't seem to match up with your recoup estimates.
Government subsidies don't count.
- Without radiation, we would not be here. It's fundamental to species diversity
- The human body is surprisingly adaptable to low levels of radiation
- The radiation outside of nuclear plants is normally much lower than what is found in nature. Nuclear power stations are usual located in areas with an already low amount of ambient radiation
- We normally receive about 200-300 mrems of radiation each and every year including the 20mrems or so we get from potassium isotopes in our own blood
- You will receive more radiation every year if you live in high altitudes
- Taking an international flight will likely expose you to more radiation than living ten years near a nuclear power plant
- Nuclear plants are allowed to emit less than 10-15 mrems of radiation every year at a constant rate. Usually this number is below 5 mrems
- Maximum safe dosage (over a year) of radiation is estimated at about 10 rems (10,000 mrems). Healthy adults can usually deal with more
- Problems due to iodine radioactive isotopes can be mitigated with treatment although the ones most at risk are young children
- No large scale energy production is absolutely safe
On the last point I'm sure we are in complete agreement.Coal veins can catch fire in the ground and burn for decades.
Nuclear power plant designs in Western Europe and North America haven't had any "disaster" level accidents. Note: Sellafield was primarily for weapons and Three Mile Island had zero civilian casualties or health problems. Japan has had an accident where the population had to be relocated temporarily if memory serves, but no worse than when fossil fuel stockpiles go boom. At least with modern nuclear designs, you get some advance warning. With fossil fuels, a spark can lead to immediate problems.
As for fusion as opposed to fission, sure fusion is better. The only small detail is that we can't do it right now. It's not currently an option. Fission is.
I just restarted my browser, navigated to a few sites with a bunch of open windows and tabs, and checked memory usage. Firefox is sucking up some RAM, but I accept that since the alternative is browsing the web with a browser that doesn't render as quickly or as well.
Then I went to the site with the Theora stream. Memory went up, but not by much -- especially when compared to the total browser footprint. After all is said and done, I'm looking at a 160MB chunk of memory for the browser, all of the windows, the JVM, and the video stream. Considering that I have 512MB in the box and RAM is cheap enough that 512MB more isn't out of the question, I don't much care.
Bottom line: it doesn't matter so much how much RAM is used up with regard to "bloat." Just as with most engineering problems, what matters is that I am able to use the computer. If I am using less memory than I have available to me, it doesn't matter if it's a little less or a lot less. If I can't see an overall slowdown in the system (and I can't), then by definition it's not an issue.
I'll trade increased memory footprint for buffer overflows any day of the week and most sundays. As far as people playing "little java games online and wonder[ing] why their internet is slow," I can name more than a few games written in C, C++, Pascal, etc. (and assembly for that matter) that were slower than molasses -- and many of them weren't even network aware nor did the graphics look that good.
Surprise! Bad code runs slowly. The Theora streaming applet loads and runs quickly. Surprise! Good code runs quickly.
Don't paint all Java programs with the same brush.