I have been using XFS on my home machines since v0.9. The installer has had a couple of glitches in the past (0.9 left me without access to the network and my cdrom drive by default). The recent beta fixed a lot of problems and was based on RedHat 7.1 (as opposed to 7.1 betas from earlier releases).
I haven't tried the 1.0 release yet. There's only so many hours in the day. On the other hand, the last install I did with the beta, after installing everything I wanted, I fired up a dozen programs such as Mozilla, GIMP, Nautilus, etc. While the drive was churning, I hit the power switch. For those of you who have used ReiserFS, I'm sure this is no big deal.;)
It should be noticed that on my Athlon 800MHz w/ 128MB of RAM and a 27GB hard drive, I almost missed the filesystem check as it scrolled by on bootup. That had me sold forever on journaling filesystems.
I haven't seen any visible performance differnece though. There may be, but so much has changed on my system that any subjective comparisons are almost impossible/meaningless. For example, devfs is enabled by default, there's a more up-to-date kernel and the drive has a different partition layout. Who could tell what the FS performance difference may be. I definitely don't need to go back to ext2 just to see if my switchover was justified. Any more info will just be icing.
If someone wants to post "real" benchmarks (lies, damn lies, and all that) I'd love to see them too.
"That means your new script may one day be the bane of somebody's database system, and they'll have to waste time rewriting your code"
Once again, how is C somehow special in this case? If my script has a very specific purpose that affords no great speed disadvantage (2 seconds every hour or so), why are you rewriting it?
If it is bad code, rewriting is a good idea. C is not immune to this statement either. If it is easy to read with an efficient algorithm, why does it automatically need to be rewritten?
And precisely how much CPU time is being wasted here? If we think in terms of time == money (even in Free Software), the extra time spent in C as opposed to Perl (string manipulation comes to mind) might better be served by either (a) realizing that except for large-scale or time-sensitive (real-time) projects, C will not give you a sufficient return or (b) upgrading your computer. Hardware has been and will remain cheaper than people.
That said, there are definitely times where C makes more sense. Apache ported to Perl might be an interesting exercise, but in the end a horrific goal. A C program written to be used once, like parsing a web server log (as long as there are no extenuating circumstances like multi-gigabyte sizes), would be time wasted. Perl was made for it and the extra speed that C affords is immaterial in this case.
And finally, how are you wasting CPU cycles in the I/O and networking code case that I mentioned? If the device is still waiting for data (filling buffers et al), both a C program and a script will be waiting with an equal amount of CPU usage. In addition, most (all?) I/O and networking in modern scripting languages is written in a lower level language anyway (such as C). When the script is relatively small, you are basically running C with a thin wrapper.
Algorithms always beat language wars. Get over it and use the right tool for the job.
The last version of Nautilus that I used (v 1.0) did not have a feature that I have grown to love in gmc: simple and easy navigation of compressed archives.
And I don't mean a dropdown option for "view as archive" either. The gmc metaphor for archives as extensions to the filesystem tree is optimal in my opinion.
According to ISO 98 C++, your example should scope "i" to the loop. Don't blame the language for limitations in the compiler.
It's like blaming the authors of the U.S. Constitution because some representative in Congress tries to establish a law which contradicts the Constitution.
"The key is planning your code extensively, programming in a disciplined manner, and using assert() liberally, so your code is essentially "bug-free" (i.e. no "bugs", just design faults)."
This applies to all languages. Why is C or assembly special in this case? The problem is many (most?) programmers do not plan ahead, are not disciplined, and don't use assert(). When confronted with this reality, it makes sense to have the language act as a safety net in exchange for some efficiency.
If you are coding an I/O intensive application, chances are that the scripting language with run about as fast as your tuned C or assembly. Your hard drive or your network card will usually hobble the most carefully tuned C or assembly AND it will take much longer to write than the equivalent code in a scripting language.
"I think it is interesting that after less than a decade, C++ is being labeled as fossilizing. While its parent C is still very vital."
1) C++ was first released twenty years ago.
2) C++ is not fossilizing (where is your data that people aren't using C++ anymore?) The STL, a relatively new construct (less than ten years old), is being used more and more. How is that fossilization?
3) If C is so vital, then why are people flocking to Java and scripting languages?
C has its uses. C++ has its uses. Language X has its uses.
On the other hand, I agree with you that if Java adopts generic idioms and assertions, my reasons for using C++ will decrease dramatically. However, since we are talking about hypothetical futures, if C++ gains an easy to use garbage collector and unified thread and socket library, my reasons for using Java will decrease dramatically.
Languages are immaterial. Concepts are important. Use whatever language best describes the concept you are trying to present.
Oops! Totally forgot the last part of your curious position.
a[i++]=i++;
Hmmm... This is quite a problem. You're right in that it is quite ambiguous and implementation dependant. Let's try an alternative shall we?
a[i] = i;
i += 2;
- or -
++i;// no temporary
a[i] = i;
++i;
- or -
i += 2;
a[i] = i;
Yet another thing I cannot seem to grok: why do coders get so obsessed about saving a line of text in source (which is supposed to be readable by humans by the way!) when the code output by the compiler is EXACTLY the same for all intents and purposes. In fact, by avoiding temporaries (you did know that "i++" causes a temporary variable to be created right?), it might be 0.0001 seconds faster (woohoo!). The important difference being that the first example is ambiguous to read even if there were a defined behavior. All of the others on the other and are completely clear to anyone regardless of their experience level provided they've have done any rudimentary programming.
Optimize your code, not your source.
16 bit ints are completely justified on a 16 bit CPU. If you think that's weird, you should check out the systems that have 36 bit ints (yes, they exist). Not only are some ints less than 32 bits, some aren't even powers of two.
Hunh? I hate to break it to you, but unsigned int and int are two different types. The only similarity they have is their size in memory. It's counter-intuituve to you because apparently you had false assumptions. Do not blame the language for this.
If your function were as follows (warning! useless template feature approaching!)
A little forethought with the design (and I stress "little") and we find, as you did, that there are two copies of our functions in the binary. Oh no! I've lost maybe half a kilobyte on my hard drive! Look at that extreme bloat! Whatever shall my 27GB drive do? A thousand of these programs and I'll have lost close to one megabyte! Oh wait! No... If I put this function into a library like I should do for all of my heavily reused code segments, I've still only lost half of a kilobyte of position independant code AND shared libraries offset the memory footprint increase.
The waste for a single instance is far from substantial. The waste from multiple instances is far from substantial. The waste from multiple references to an instance in a shared library is so insubstantial, it is laughable.
Worry about your overall algorithms before fretting too much over this. There's a reason we don't freak out over our programs fitting into (less than) 128KB of memory and taking up less space than is available on a cassette tape.
javax.servlet and java.rmi ARE in fact merely libraries (packages in Java-speak). The only thing that makes them "integrated" are their inclusion in rt.jar.
EJB is simply an umbrella term for RMI, JDBC, JavaBeans and JNDI with some convenience classes/interfaces.
Don't get me wrong. They are wonderfully useful and reasons for me to love working with Java, but they are not intrinsic to the syntax of the language any more than the STL is intrinsic to C++. They actually are merely "libraries."
Correction: The STL is equivalent to (most of) java.util, (part of) java.io, and java.lang.String. They are not equivalent. What the original poster was mentioning was the loss of java.net, java.awt, java.sql, javax.swing, java.rmi, java.lang, etc.
Assertion: You need to talk to a database.
Question: What is the official C++ method of talking to databases?
Answer: There is none.
Assertion: You need to write a graphical user interface.
Question: What is the official C++ method of implementing a graphical user interface?
Answer: There is none.
Assertion: You need to write a distributed (multi-system) program.
Question: What is the official C++ method of implementing a distributed program?
Answer: CORBA? But which ORB?
Assertion: You need to write a multi-threaded application.
Question: What is the official C++ method of using threads and handling semaphores/mutexes?
Answer: There is none.
The biggest advantage Java has over C++ is its standard library. Period.
The biggest advantages of C++ over Java (IMHO) are memory usage and parametric (compile-time) polymorphism w/ templates.
Universal themes regardless of language? Premature optimization is the root of all evil. Efficiency of design/algorithm will almost always win over choice of language (BASIC can be faster than C given different algorithms).
Use what works for you. Use the language that best fits the problem. Let's stop the language wars and get some work done.
According to the/. icons, PostgreSQL is an upgrade while Samba is Linux-related. Hello?
I can't wait for the new religious wars to begin. MySQL vs. PostgreSQL. Who cares who comes out on top? I doubt either will come out on top. But while they keep one-upping each other and tweaking this and that and the other ad naseum, one of these days we'll stop and look around. Suddenly they won't be the Open Source "challengers." They'll be the default choice. And most of us probably won't see it happen. We'll only notice it after the fact.
The old guard will follow the road of most closed-source software: Specific niches for select clients.
So has anyone used it on Win32 lately? I've only ever played with PostgreSQL on Linux. I'm curious as to how well the ODBC libraries hold up.
If synthetics that defy all attempts to distinguish from naturals finally show up, we'll at last get to see the end of those insipid commercials. However, what effect will this have on the diamond-loving portion of the female population? Will it encourage a greater sense of aesthetics independant of size? Or will it encourage 50 carat boulders "for just 39 cents more?"
Now on a more serious note: what is the heat dissipation on a diamond heat sink as opposed to (for example) an aluminum (aluminium) heat sink? Wrong direction or will I finally find something that can adequately cool off a >1GHz Athlon?
Doesn't it strike you as midly ironic that most of these people who are against profanity and sexuality on the public airwaves are people you wouldn't want to fuck in the first place?
I'm surprised that there isn't more response to this on slashdot. A bunch of people rant and foam at the mouth because something was released under a BSD license instead of the GPL all the while screaming "Personal Liberty!"
And yet, in the real world, when an article is linked that has both "anecdotal and statistical" evidence that the various police and drug enforcement agencies around the country have been systematically targeted on the highways, people don't respond.
Is this because it is considered an "obvious problem," that folks don't feel the need to respond, are so jaded by the info that they have become apathetic, agree with profiles that follow racial lines, or that slashdoters suffer from such severe attention deficit disorder that they couldn't finish the article? Where are your staunch defenders of liberty and personal freedom!?!
OK... Now I'm finished ranting and foaming at the mouth...
1) The Scientology related info was copyrighted - nothing to argue here.
2) Slashdot didn't just pull the post. They reposted non-copyrighted material and links for more info about Scientology.
Despite many Slashdot guffaws and mistakes in the past, I don't count this as one of them. And when was the last time you heard of a paper that never made mistakes? Yeah, Slashdot has had a bad record with checking the validity of their stories, but the comments made in response to an article should serve as a note to the reader that there may be something fishy.
Hint: If you see a bunch of comments moderated to 4 or 5 say something to the effect of "This is bullshit. I work in industry-X and this is just plain wrong," chances are that it's wrong. The only dilemma is that print newspapers usually have no comments and moderation.
Could you imagine what some newspapers would look like if their stories could get immediate response and correction?
Yeah! Preach it brutha! There's some stupid folks over at NASA. Let's get some corporations and MBAs more heavily involved. After all, it's not rocket science...
Basic everywhere. At time of smalltalk and lisp, they pushed basic. Thanks for that. They ruined my life. The paperclip. This harmed millions of users. The login panel that is dismissed with the escape key.
Agreed. Well... The parperclip annoyed millions of users...
The 'control-alt-del' to login. Someone should pay for that.
On the contrary, there is a good reason for ctrl-alt-del. Unlike any other command keystroke and key combination, ctrl-alt-del cannot be caught programmatically. This means that on NT/2000, you cannot invoke a login prompt unless you are at the console or use something equivalent. This means that there cannot be some program placed on the system that will programmatically invoke a login prompt and brute-force attack the administrator's password. It's arguably more secure than linux's passing of runlevel at the lilo prompt (single mode).
However, once you get past the login prompt, the rest of your day may suck;)
Winmodems. Don't forget winmodems. Oh, and the 10bits in the cylinder number. The 504Mb limitation of hard drive ? And the 8Gb limit ?
And FAT, the Fragmented Allocation Table ? Who should pay for the countless hours morons spend looking DEFRAG.EXE painfully moving blocks around? And the windows API ? Winsock ? The API where you need a hidden window to receive data on a socket ?
Winmodems are a product of the consumer, not MS. Have any of you seen a Microsoft-branded Winmodem (not the certification)? The reason winmodems are so prevalent is that they are cheaper. Microsoft provided the ubiquitous desktop. OEMs figured that the everyday user would use anything but Windows... and they were right. Who knows, maybe something good will come of them. Check out http://linmodems.org/.
Oh my god. I don't want to break microsoft apart, I want to dissolve bill gates in an acid bath.
Now now. Bill Gates didn't code any of the above except for BASIC. He bought or employed someone to write everything else. He's just responsible for BASIC. er... ACID BATH!!!!
Ummm... Did you read my post? I did NOT say that there weren't any XML parsers for C/C++. What I said was that there is no COMMON INTERFACE for XML parsers. Very different things.
If I start using xmlpp and then find that Xerces C++ is faster, better maintained, or has better standards support, can I alter my codebase simply and easily. The answer is 'no.' I would have to go into each and every file, change the class/struct name (or use typedef or #DEFINE ugliness) and change any variation in the function calling conventions or parameters. This may involve completely reworking underlying design decisions for the entire codebase.
However on Python or Java, for example, I have a static set of interfaces that come directly from the W3C (the Java package org.w3c.dom for example) that would be used in my program. XML parsers in Java that implement this set of interfaces have only their document loading as parser specific. And Sun's JAXP package makes that a non-issue as well.
Restated: There is no common API for XML in C/C++. There are multiple parsers, but no common set of interfaces. Period.
Funny... The kids I knew that had strict parents who wouldn't let them go out at night were the ones that were always sneaking out. The "care-free hippy" childrens' parents tended to be the more sedate and boring. Trust and compassion means more to most children (at least it did to my friends and me) than stern discipline.
The bad trend in society as I see it is the lack of parental involvement in their child's life, not their supervised involvement in the world they will inherit.
There is no equivalent in C/C++ to org.w3c.dom or XML::Parser. It has basically been MS's COM interfaces, the Xerces parser (which loosly follows the Java API), expat/libxml, etc. One of the advantages of the Java parsers are that they follow indentical interfaces.
Especially when Sun's Java API for XML Parsing is brought into the mix, you have a realistic way of completely abstracting the parser in current use.
Why is this important? No parser is perfect. Some have a better memory footprint while others are pure speed demons. No to mention the possibility of a dark horse in the future that blows everything else away (XML Schema or database interaction anyone?).
As long as this common API is missing in C/C++, where the only thing necessary to update code is a relink (or no relink in the case of COM), C/C++ will continue to be overlooked by the XML community and its requisite publishing contingent.
> Let me make myself clear. Sticking with basic
> HTML elements that work on all browsers and using
> style sheets to pretty yourself up for the modern
> browsers is keeping it simple. That doesn't lend
> to eight different versions of anything.
You neglected the inclusion of CSS in my argument. We're arguing the same point here.
With regards to straight HTML, no two browsers on the planet have ever rendered HTML is exactly the same way. There has always been the need for an extra or spacer image to get the style right.
The HTML form does not allow for large, heirarchical chunks of information -- although it can be hacked in.
HTML does not give a context to information it contains. And the meta tag has basically been rendered useless.
Case in point the time when G.W. Bush's campaign site was the first site referenced on Yahoo and Google in response to the the query "dumb motherfucker". I thought it was funny as hell, but HTML alone will never solve this problem. I'm not saying that the new specs will magically make search engine problems disappear overnight. It will take work and time. But they will never be solved if we stick with straight HTML.
> Once again, I agree that JavaScript and DHTML
> have their legitimate uses, but their legimiate
> uses don't make the issues of privacy, security,
> bloat, and compatibility with all web browsers
> (not just the bloated ones that support
> JavaScript) go away.
No, but it raises the bar and gives a clear goal that everyone should be working toward. Privacy and security are separate issues. Most (all?) browsers have had problems with these at one time or another.
100% compatibility with the past is impossible. If you have to keep to the lowest common denominator of the past, note that early versions of AOL's browser didn't support the <center> tag. I realize that this was not your argument however. There should be *some* regression path for web documents. This means however that NS 4.x users will see more and more pages that look terrible.
IE 4.x+ has >80% of the market now. Most companies just code for >80% of the market with token attempts toward 10%-15% of the market (NS 4.x+). This is exactly the same as when the stats were reversed and people coded just for Netscape.
Personally I use Mozilla on Windows and Linux at home and at work. It is my primary browser. At home I use a Celeron 333 -- hardly cutting edge. I have a hard time believing it when people tell me that NS 4.x was somehow a better beast and it's not worth the upgrade. NS 6 is bloated. The people who packaged NS 6 say that it is bloated. Use Mozilla already!
I have nothing against Konqueror. But yelling at the people who code for 98%-99% of web pages that can't or won't test for Konqueror because it's so little used in the web at large is like screaming at the Rock of Gibralter expecting it to crack. Businesses are lazy. They want to do as little as possible and stay in business/not get fired (Ever seen "Office Space"?). When the bare minimum of effort gets you >90% of the eyeballs out there, there is very little incentive to work harder. It sucks, but it's classic human behavior.
I recognize the argument that the perfect browser has not come. I recognize the argument that the halfway decent browser seems a sketchy proposal.
I was not suggesting that Amaya was a day-to-day use browser. It is a reference implementation. It is slow as hell, doesn't support JavaScript and has no mailing capabilities. It is a reference implementation of XHTML and CSS. The fact that it doesn't work at all for you is unfortunate. It has worked for me in the past. But after Mozilla showed up with standards support, I stopped looking at Amaya.
Slashdot Mirror
I have been using XFS on my home machines since v0.9. The installer has had a couple of glitches in the past (0.9 left me without access to the network and my cdrom drive by default). The recent beta fixed a lot of problems and was based on RedHat 7.1 (as opposed to 7.1 betas from earlier releases).
;)
I haven't tried the 1.0 release yet. There's only so many hours in the day. On the other hand, the last install I did with the beta, after installing everything I wanted, I fired up a dozen programs such as Mozilla, GIMP, Nautilus, etc. While the drive was churning, I hit the power switch. For those of you who have used ReiserFS, I'm sure this is no big deal.
It should be noticed that on my Athlon 800MHz w/ 128MB of RAM and a 27GB hard drive, I almost missed the filesystem check as it scrolled by on bootup. That had me sold forever on journaling filesystems.
I haven't seen any visible performance differnece though. There may be, but so much has changed on my system that any subjective comparisons are almost impossible/meaningless. For example, devfs is enabled by default, there's a more up-to-date kernel and the drive has a different partition layout. Who could tell what the FS performance difference may be. I definitely don't need to go back to ext2 just to see if my switchover was justified. Any more info will just be icing.
If someone wants to post "real" benchmarks (lies, damn lies, and all that) I'd love to see them too.
"That means your new script may one day be the bane of somebody's database system, and they'll have to waste time rewriting your code"
Once again, how is C somehow special in this case? If my script has a very specific purpose that affords no great speed disadvantage (2 seconds every hour or so), why are you rewriting it?
If it is bad code, rewriting is a good idea. C is not immune to this statement either. If it is easy to read with an efficient algorithm, why does it automatically need to be rewritten?
And precisely how much CPU time is being wasted here? If we think in terms of time == money (even in Free Software), the extra time spent in C as opposed to Perl (string manipulation comes to mind) might better be served by either (a) realizing that except for large-scale or time-sensitive (real-time) projects, C will not give you a sufficient return or (b) upgrading your computer. Hardware has been and will remain cheaper than people.
That said, there are definitely times where C makes more sense. Apache ported to Perl might be an interesting exercise, but in the end a horrific goal. A C program written to be used once, like parsing a web server log (as long as there are no extenuating circumstances like multi-gigabyte sizes), would be time wasted. Perl was made for it and the extra speed that C affords is immaterial in this case.
And finally, how are you wasting CPU cycles in the I/O and networking code case that I mentioned? If the device is still waiting for data (filling buffers et al), both a C program and a script will be waiting with an equal amount of CPU usage. In addition, most (all?) I/O and networking in modern scripting languages is written in a lower level language anyway (such as C). When the script is relatively small, you are basically running C with a thin wrapper.
Algorithms always beat language wars. Get over it and use the right tool for the job.
The last version of Nautilus that I used (v 1.0) did not have a feature that I have grown to love in gmc: simple and easy navigation of compressed archives.
And I don't mean a dropdown option for "view as archive" either. The gmc metaphor for archives as extensions to the filesystem tree is optimal in my opinion.
According to ISO 98 C++, your example should scope "i" to the loop. Don't blame the language for limitations in the compiler.
It's like blaming the authors of the U.S. Constitution because some representative in Congress tries to establish a law which contradicts the Constitution.
"The key is planning your code extensively, programming in a disciplined manner, and using assert() liberally, so your code is essentially "bug-free" (i.e. no "bugs", just design faults)."
This applies to all languages. Why is C or assembly special in this case? The problem is many (most?) programmers do not plan ahead, are not disciplined, and don't use assert(). When confronted with this reality, it makes sense to have the language act as a safety net in exchange for some efficiency.
If you are coding an I/O intensive application, chances are that the scripting language with run about as fast as your tuned C or assembly. Your hard drive or your network card will usually hobble the most carefully tuned C or assembly AND it will take much longer to write than the equivalent code in a scripting language.
Premature optimization is the root of all evil.
"I think it is interesting that after less than a decade, C++ is being labeled as fossilizing. While its parent C is still very vital."
1) C++ was first released twenty years ago.
2) C++ is not fossilizing (where is your data that people aren't using C++ anymore?) The STL, a relatively new construct (less than ten years old), is being used more and more. How is that fossilization?
3) If C is so vital, then why are people flocking to Java and scripting languages?
C has its uses. C++ has its uses. Language X has its uses.
On the other hand, I agree with you that if Java adopts generic idioms and assertions, my reasons for using C++ will decrease dramatically. However, since we are talking about hypothetical futures, if C++ gains an easy to use garbage collector and unified thread and socket library, my reasons for using Java will decrease dramatically.
Languages are immaterial. Concepts are important. Use whatever language best describes the concept you are trying to present.
Oops! Totally forgot the last part of your curious position.
// no temporary
a[i++]=i++;
Hmmm... This is quite a problem. You're right in that it is quite ambiguous and implementation dependant. Let's try an alternative shall we?
a[i] = i;
i += 2;
- or -
++i;
a[i] = i;
++i;
- or -
i += 2;
a[i] = i;
Yet another thing I cannot seem to grok: why do coders get so obsessed about saving a line of text in source (which is supposed to be readable by humans by the way!) when the code output by the compiler is EXACTLY the same for all intents and purposes. In fact, by avoiding temporaries (you did know that "i++" causes a temporary variable to be created right?), it might be 0.0001 seconds faster (woohoo!). The important difference being that the first example is ambiguous to read even if there were a defined behavior. All of the others on the other and are completely clear to anyone regardless of their experience level provided they've have done any rudimentary programming.
Optimize your code, not your source.
16 bit ints are completely justified on a 16 bit CPU. If you think that's weird, you should check out the systems that have 36 bit ints (yes, they exist). Not only are some ints less than 32 bits, some aren't even powers of two.
Hunh? I hate to break it to you, but unsigned int and int are two different types. The only similarity they have is their size in memory. It's counter-intuituve to you because apparently you had false assumptions. Do not blame the language for this.
If your function were as follows (warning! useless template feature approaching!)
template <class T>
void swap (T& x, T& y){
T a;
a=x;
x=y;
y=a;
}
and you did this:
unsigned int a=1, b=2;
swap(a, b);
a and b are swapped, which is correct!
A little forethought with the design (and I stress "little") and we find, as you did, that there are two copies of our functions in the binary. Oh no! I've lost maybe half a kilobyte on my hard drive! Look at that extreme bloat! Whatever shall my 27GB drive do? A thousand of these programs and I'll have lost close to one megabyte! Oh wait! No... If I put this function into a library like I should do for all of my heavily reused code segments, I've still only lost half of a kilobyte of position independant code AND shared libraries offset the memory footprint increase.
The waste for a single instance is far from substantial. The waste from multiple instances is far from substantial. The waste from multiple references to an instance in a shared library is so insubstantial, it is laughable.
Worry about your overall algorithms before fretting too much over this. There's a reason we don't freak out over our programs fitting into (less than) 128KB of memory and taking up less space than is available on a cassette tape.
Premature optimization is the root of all evil.
Already been done. It's called Smalltalk. And one of the reasons it did not take off was the fact that everyone already knew C (or a C-like language).
There is a reason that C++ has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that Java has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that Perl has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
There is a reason that ECMAScript has curly braces for scoping, parentheses for parameter lists and square brackets for array syntax.
I sense a pattern here...
There is also a profound resistance to OO thoery in the C language camp that I still can't quite understand, but that is another story...
javax.servlet and java.rmi ARE in fact merely libraries (packages in Java-speak). The only thing that makes them "integrated" are their inclusion in rt.jar.
EJB is simply an umbrella term for RMI, JDBC, JavaBeans and JNDI with some convenience classes/interfaces.
Don't get me wrong. They are wonderfully useful and reasons for me to love working with Java, but they are not intrinsic to the syntax of the language any more than the STL is intrinsic to C++. They actually are merely "libraries."
Correction: The STL is equivalent to (most of) java.util, (part of) java.io, and java.lang.String. They are not equivalent. What the original poster was mentioning was the loss of java.net, java.awt, java.sql, javax.swing, java.rmi, java.lang, etc.
Assertion: You need to talk to a database.
Question: What is the official C++ method of talking to databases?
Answer: There is none.
Assertion: You need to write a graphical user interface.
Question: What is the official C++ method of implementing a graphical user interface?
Answer: There is none.
Assertion: You need to write a distributed (multi-system) program.
Question: What is the official C++ method of implementing a distributed program?
Answer: CORBA? But which ORB?
Assertion: You need to write a multi-threaded application.
Question: What is the official C++ method of using threads and handling semaphores/mutexes?
Answer: There is none.
The biggest advantage Java has over C++ is its standard library. Period.
The biggest advantages of C++ over Java (IMHO) are memory usage and parametric (compile-time) polymorphism w/ templates.
Universal themes regardless of language? Premature optimization is the root of all evil. Efficiency of design/algorithm will almost always win over choice of language (BASIC can be faster than C given different algorithms).
Use what works for you. Use the language that best fits the problem. Let's stop the language wars and get some work done.
Must be "The Day the Earth Stood Still" because Gort was the name of the robot and not mentioned in the AoD Necronomicon cemetary incantation.
I am NOT a geek... I am NOT a geek...
Heh heh... "select" clients. Sorry about that folks. Totally unintentional pun.
According to the /. icons, PostgreSQL is an upgrade while Samba is Linux-related. Hello?
I can't wait for the new religious wars to begin. MySQL vs. PostgreSQL. Who cares who comes out on top? I doubt either will come out on top. But while they keep one-upping each other and tweaking this and that and the other ad naseum, one of these days we'll stop and look around. Suddenly they won't be the Open Source "challengers." They'll be the default choice. And most of us probably won't see it happen. We'll only notice it after the fact.
The old guard will follow the road of most closed-source software: Specific niches for select clients.
So has anyone used it on Win32 lately? I've only ever played with PostgreSQL on Linux. I'm curious as to how well the ODBC libraries hold up.
If synthetics that defy all attempts to distinguish from naturals finally show up, we'll at last get to see the end of those insipid commercials. However, what effect will this have on the diamond-loving portion of the female population? Will it encourage a greater sense of aesthetics independant of size? Or will it encourage 50 carat boulders "for just 39 cents more?"
Now on a more serious note: what is the heat dissipation on a diamond heat sink as opposed to (for example) an aluminum (aluminium) heat sink? Wrong direction or will I finally find something that can adequately cool off a >1GHz Athlon?
Doesn't it strike you as midly ironic that most of these people who are against profanity and sexuality on the public airwaves are people you wouldn't want to fuck in the first place?
(With apologies to George Carlin)
I'm surprised that there isn't more response to this on slashdot. A bunch of people rant and foam at the mouth because something was released under a BSD license instead of the GPL all the while screaming "Personal Liberty!"
And yet, in the real world, when an article is linked that has both "anecdotal and statistical" evidence that the various police and drug enforcement agencies around the country have been systematically targeted on the highways, people don't respond.
Is this because it is considered an "obvious problem," that folks don't feel the need to respond, are so jaded by the info that they have become apathetic, agree with profiles that follow racial lines, or that slashdoters suffer from such severe attention deficit disorder that they couldn't finish the article? Where are your staunch defenders of liberty and personal freedom!?!
OK... Now I'm finished ranting and foaming at the mouth...
1) The Scientology related info was copyrighted - nothing to argue here.
2) Slashdot didn't just pull the post. They reposted non-copyrighted material and links for more info about Scientology.
Despite many Slashdot guffaws and mistakes in the past, I don't count this as one of them. And when was the last time you heard of a paper that never made mistakes? Yeah, Slashdot has had a bad record with checking the validity of their stories, but the comments made in response to an article should serve as a note to the reader that there may be something fishy.
Hint: If you see a bunch of comments moderated to 4 or 5 say something to the effect of "This is bullshit. I work in industry-X and this is just plain wrong," chances are that it's wrong. The only dilemma is that print newspapers usually have no comments and moderation.
Could you imagine what some newspapers would look like if their stories could get immediate response and correction?
Yeah! Preach it brutha! There's some stupid folks over at NASA. Let's get some corporations and MBAs more heavily involved. After all, it's not rocket science...
Note the sound of sarcasm dripping
Agreed. Well... The parperclip annoyed millions of users...
On the contrary, there is a good reason for ctrl-alt-del. Unlike any other command keystroke and key combination, ctrl-alt-del cannot be caught programmatically. This means that on NT/2000, you cannot invoke a login prompt unless you are at the console or use something equivalent. This means that there cannot be some program placed on the system that will programmatically invoke a login prompt and brute-force attack the administrator's password. It's arguably more secure than linux's passing of runlevel at the lilo prompt (single mode).
However, once you get past the login prompt, the rest of your day may suck ;)
Winmodems are a product of the consumer, not MS. Have any of you seen a Microsoft-branded Winmodem (not the certification)? The reason winmodems are so prevalent is that they are cheaper. Microsoft provided the ubiquitous desktop. OEMs figured that the everyday user would use anything but Windows... and they were right. Who knows, maybe something good will come of them. Check out http://linmodems.org/.
Now now. Bill Gates didn't code any of the above except for BASIC. He bought or employed someone to write everything else. He's just responsible for BASIC. er... ACID BATH!!!!
Ummm... Did you read my post? I did NOT say that there weren't any XML parsers for C/C++. What I said was that there is no COMMON INTERFACE for XML parsers. Very different things.
If I start using xmlpp and then find that Xerces C++ is faster, better maintained, or has better standards support, can I alter my codebase simply and easily. The answer is 'no.' I would have to go into each and every file, change the class/struct name (or use typedef or #DEFINE ugliness) and change any variation in the function calling conventions or parameters. This may involve completely reworking underlying design decisions for the entire codebase.
However on Python or Java, for example, I have a static set of interfaces that come directly from the W3C (the Java package org.w3c.dom for example) that would be used in my program. XML parsers in Java that implement this set of interfaces have only their document loading as parser specific. And Sun's JAXP package makes that a non-issue as well.
Restated: There is no common API for XML in C/C++. There are multiple parsers, but no common set of interfaces. Period.
Funny... The kids I knew that had strict parents who wouldn't let them go out at night were the ones that were always sneaking out. The "care-free hippy" childrens' parents tended to be the more sedate and boring. Trust and compassion means more to most children (at least it did to my friends and me) than stern discipline.
The bad trend in society as I see it is the lack of parental involvement in their child's life, not their supervised involvement in the world they will inherit.
There is no equivalent in C/C++ to org.w3c.dom or XML::Parser. It has basically been MS's COM interfaces, the Xerces parser (which loosly follows the Java API), expat/libxml, etc. One of the advantages of the Java parsers are that they follow indentical interfaces.
Especially when Sun's Java API for XML Parsing is brought into the mix, you have a realistic way of completely abstracting the parser in current use.
Why is this important? No parser is perfect. Some have a better memory footprint while others are pure speed demons. No to mention the possibility of a dark horse in the future that blows everything else away (XML Schema or database interaction anyone?).
As long as this common API is missing in C/C++, where the only thing necessary to update code is a relink (or no relink in the case of COM), C/C++ will continue to be overlooked by the XML community and its requisite publishing contingent.
> Let me make myself clear. Sticking with basic
> HTML elements that work on all browsers and using
> style sheets to pretty yourself up for the modern
> browsers is keeping it simple. That doesn't lend
> to eight different versions of anything.
You neglected the inclusion of CSS in my argument. We're arguing the same point here.
With regards to straight HTML, no two browsers on the planet have ever rendered HTML is exactly the same way. There has always been the need for an extra or spacer image to get the style right.
The HTML form does not allow for large, heirarchical chunks of information -- although it can be hacked in.
HTML does not give a context to information it contains. And the meta tag has basically been rendered useless.
Case in point the time when G.W. Bush's campaign site was the first site referenced on Yahoo and Google in response to the the query "dumb motherfucker". I thought it was funny as hell, but HTML alone will never solve this problem. I'm not saying that the new specs will magically make search engine problems disappear overnight. It will take work and time. But they will never be solved if we stick with straight HTML.
> Once again, I agree that JavaScript and DHTML
> have their legitimate uses, but their legimiate
> uses don't make the issues of privacy, security,
> bloat, and compatibility with all web browsers
> (not just the bloated ones that support
> JavaScript) go away.
No, but it raises the bar and gives a clear goal that everyone should be working toward. Privacy and security are separate issues. Most (all?) browsers have had problems with these at one time or another.
100% compatibility with the past is impossible. If you have to keep to the lowest common denominator of the past, note that early versions of AOL's browser didn't support the <center> tag. I realize that this was not your argument however. There should be *some* regression path for web documents. This means however that NS 4.x users will see more and more pages that look terrible.
IE 4.x+ has >80% of the market now. Most companies just code for >80% of the market with token attempts toward 10%-15% of the market (NS 4.x+). This is exactly the same as when the stats were reversed and people coded just for Netscape.
Personally I use Mozilla on Windows and Linux at home and at work. It is my primary browser. At home I use a Celeron 333 -- hardly cutting edge. I have a hard time believing it when people tell me that NS 4.x was somehow a better beast and it's not worth the upgrade. NS 6 is bloated. The people who packaged NS 6 say that it is bloated. Use Mozilla already!
I have nothing against Konqueror. But yelling at the people who code for 98%-99% of web pages that can't or won't test for Konqueror because it's so little used in the web at large is like screaming at the Rock of Gibralter expecting it to crack. Businesses are lazy. They want to do as little as possible and stay in business/not get fired (Ever seen "Office Space"?). When the bare minimum of effort gets you >90% of the eyeballs out there, there is very little incentive to work harder. It sucks, but it's classic human behavior.
I recognize the argument that the perfect browser has not come. I recognize the argument that the halfway decent browser seems a sketchy proposal.
I was not suggesting that Amaya was a day-to-day use browser. It is a reference implementation. It is slow as hell, doesn't support JavaScript and has no mailing capabilities. It is a reference implementation of XHTML and CSS. The fact that it doesn't work at all for you is unfortunate. It has worked for me in the past. But after Mozilla showed up with standards support, I stopped looking at Amaya.