Yes, engineers need to learn to be less direct in their communication, and learn to obfuscate like a manager.
For instance, "launching now would kill the crew", becomes, "the current orbital insertion paradigm may cause a negative value proposition for this and all future missions".
See how much more understandable the second quote is? The best part about it is that it doesn't mention death, which is better for shareholder value.
These posts are getting long, but I'll try to respond to each point you made.
Probably should have taken this one offline. Whoops.
However, I maintain that it is rare to need it in C++ otherwise.
Especially if you use something like ACE.
The point is that this is another requirement imposed on the programmer, whereas again in C++ it's handled by the language itself via templates.
That's true, it's an idiom in Java. The good news is, a lot of people complained, so templates are going into the language for 1.5. Before Sun committed to that, a ton of people used GJ.
I don't look on wrapping as much of a problem, because usually the generic container doesn't do everything I want, so I end up wrapping the container anway (e.g. I want to label all the apples).
If you're unlucky, and the finalizer never runs, you have a resource leak. Alas, even Sun's own material sometimes implies that the finalizer will always clean up, which is not a safe thing to do.
That's because there's a lot of myths surrounding garbage collection. The GC doesn't read minds, and if there is heap left above its threshold, it's not going to make an attempt at cleaning up garbage. In small programs, you may not even see finalizers run before the program exits, which is usually not an issue. In memory intensive or long running programs, you end up with gigantic pauses when the GC decides to suddenly clean things up, much to the astonishment of the horrified programmer standing in front of the large group of VC. The myth is that the System.gc() call has no effect (or can't be trusted to have an effect), so no one bothers to call it. The truth of the matter is that System.gc() should be called once in a while, simply because the GC can't read your mind. So Sun's documentation isn't lying about the finalizer. It will clean things up, but the GC has to get involved with the object first.
At any rate, it's much better practice to call my_stream.close() explicitly in a finally block when you're done with the stream.
Oh definitely. Although with your own classes, you may want to implement finalize anyway, and have it call close or whatever. That way, if somebody forgets to close, it'll get cleaned up eventually.
In each case, you just use these to access your resources, and never have to write the release code again. If the resource ownership is handled by whatever library supplies the resource -- and in decent libraries it invariably is -- then you never have to worry about the release issue at all, and you never have to write even a single line of release code yourself.
That's what I was trying to point out. There's quite a few interfaces in Java as well that manage their resources so you don't have to. Actually, you've given me an idea for something more generic.
Didn't someone later write a lengthy criticism demonstrating that that idiom wasn't so safe after all, though?
From what I remember, they didn't implement it correctly. However, this too will soon be a moot point. Check out who the spec. lead is.
Ah, yes, program with interfaces. I try to keep stuff as Collections, handy if you need to swap from an ArrayList to a HashMap or other.
Yeah, that works pretty good. Usually I have one of the methods on my wrapper class create a Collection for just such an emergency.
Great way to learn how things work, but when there are industrial strength xml parsers out there - why not use them.
True dat. I think the expat author said something to the effect of, "You don't write an XML parser".
That's one thing I love with java though, You will always find something in the standard libs that'll do the thing you want to do. Some call it bloat, but I rather see it as a helping hand.
You know, as far as I can tell, it's not any more or less bloated than Ada, Smalltalk, Perl, Python, or even STL. Everything has a little bit of bloat.
From the article:
"That was certainly much ado about nothing," says Steve Chesley of NASA's Jet Propulsion Laboratory in Pasadena, California.
This seems pretty ironic in light of:
"It's nothing," he said. "Just an ordinary asteroid someone has painted black."
He was killed by an infuriated mob, but not for that. He was killed after he publicly announced that he would write a great and moving play about the whole episode.
He said, "I shall call it Much Adieu About Nothing."
All humanity applauded his death.
In my experience, almost nothing uses a void* in C++. It's used occasionally in system call APIs, but rarely elsewhere.
Not in the core language, no. C++ inherits its runtime from C, though, so many important APIs return void*. So, I end up casting quite often for system related functions in C++ where in Java I don't.
You keep implying that I don't understand Java, without giving any supporting reasoning.
Alright, that's fair. I'll try to be a little more clear. That's not to say that I'm going to straight out give you the answer.
This isn't very constructive, not least because you're way off-target in guessing my Java experience.
Okay, I'll give you that. There are certain programming idioms that you use in C++, right? Do you use Java's idioms, or do you try to apply C++ idioms to Java?
Why do you think that I think finalizers are supposed to be destructors?
Maybe I shouldn't have assumed, but it's been my experience that when C++ programmers complain about Java while citing RAII, it usually means that they've tried to use a finalizer as a destructor. "They tried and failed?" "They tried and died."
Why do you think I don't know how to do resource management properly in Java?
Well, let me ask you this: What happens when you forget to close a FileInputStream? Why? What are Reference objects?
OK, getting back to the point, how do you propose to store a set of Apples and pull them out of the container without casting in (pre-generics) Java? What is it that I, my colleagues, pretty much every book on Java I've ever read and Sun's own Java web site are all missing?
If you use the generic containers, you need to cast, because the containers return an Object type. However, you only need 1 cast. Ask yourself, why isn't it a good idea to use generic container types directly?
C++ moved past this years ago with RAII.
And, C++ doesn't force you to use it. You can still screw it up too can't you? That's because it's an idiom. So by the same token, yeah, you can screw up Java idioms or not use them too, right? The point is, the languages have different idioms, and if you're going to use C++ idioms in Java you're going to have a bad time.
With these idioms, write your resource release code once, and then get it for free every time you use the resource
Which class do I inherit so my code can release any kind of resource without having to recode it specifically for that resource?
In Java, you have to remember to write a finally block and get it right every time you use a resource.
Hmmm, never noticed. Probably, because I don't use it every time, and it's not that easy to screw up.
don't you think some of us might have read those books you mentioned?
Seems like a bit of 'overkill' those time when you really just need a List or a HashMap or other container, even if it should clean up the code a fair bit.
Oh, yeah, definitely The initial thought is, "Why am I doing this again?" Then your performance engineer comes back and says, "It's too slow". That's when you realize that that one little wrapper will keep you from working the weekend.
Oh, one more tip: Don't use the concrete types like HashMap to the left of a declaration and in method parameters, use an abstract type like Map. It'll save you some agony.
we're not allowed to introduce any meta/pre compilers into our toolchain though at work
Too bad. GJ + AspectJ + JUnit is a killer combo.
I hear you, though, in '96, my boss wouldn't let us add the CGI module in Perl, even though that was the defacto standard. Even after CGI got added in as part of Perl, she still wouldn't let us use it. So I spent a lot of my time enhancing and fixing defects in our cgi library.:(
I don't think we disagree with that either. We're just saying that C++ doesn't abstract everything away from the way the machine works. For instance, in C++ there is the register storage class, which other languages don't have an equivalent to.
He was primarilly a logician, and not a skeptic. It was clear he was very in love with skepticism as a subject of study, but as a logician primarilly I think he was not inclined to advocate it directly... which in a way made him a pyrrhonist.:)
Cool, that's what I thought. He's got a book called Skeptical Essays, besides the translation of Sextus Empiricus, BTW. It looks like it could be interesting.
I don't know a lot about him, actually, but I was told he was a well respected logician, and I do know that logic was his main area of expertise/study.
Me either, I just knew that he had a book on logic. Now I know he's got some books on skepticism as well. Thanks for that information.
Fortran has too many structural problems to use for major applications.
Fortran is the language used in the communication terminals the Navy uses to send and receive data through the Milstar satellite communication network. These devices are used in ground stations, ships, and boomers. That's a pretty major application.
If you wan't to know what's hurting fortran you might try readin Dijkstra's "Goto Considered Harmful".
How often do people actualy use a goto in Fortran? I can't remember ever using a goto in the Fortran stuff I did. Of course, we had a preprocessor that may have helped with this, so I'm not sure if it didn't turn certain constructs into gotos. Seriously, how often do people use a goto?
You do need an excessive amount of casting in Java (1.4), which is inherently less safe than the alternatives offered by numerous other languages (not just C++).
I do an excessive amount of casting in C++, because many things return a void*.
I'm assuming that what you're referring to is lack of templates in combination with the generic containers in java.util. Did you ever think for a minute that you're actually using them wrong?
Similarly, you do need to use finally an excessive amount because Java's garbage collection mechanism is only good for avoiding memory leaks, not resource leaks in general.
I'm not really sure why you think that the garbage collector should help you with resource deallocation. Java doesn't have destructors. Are you trying to use finalize() as a destructor? That's not what it's for. It's a last resort mechanism, which is the reason why uncaught exceptions get ignored in finalize methods. In Java, you explicitly tell an object that you are done using it, and then null out the reference. That seems pretty straightforward to me.
What is so horrible about the finally block? It should make your code smaller, not larger.
If you have some technique or idiom for avoiding these problems, please share it, because I'm sure a lot of Java programmers would like to hear it.
So how would one go on and extract data from a container in java without all these endless casts?
I wrap all my generic containers in types that perform specific operations on the type I wish to contain. There's a lot of advantages to doing this:
It's more object-oriented.
You end up with a single cast inside the object which contains the generic container.
You get compile-time type checking.
It's easy to make drastic changes to the container implementation without having to recode the client.
This is more than making a simple wrapper class, and thus I do this in C++ as well (even with templates).
If you find this detestable, you can also use Generic Java.
Generics is a thing java has been sorely lacking since it's birth, thank god they're getting it now at last! (yes, I do code java for a living)
I agree. Unfortunately, it will probably be abused.:(
I claim that C/C++ never takes you away from how the machine works... the way it makes you think is "like the machine thinks"... so it can introduce OO concepts, but not to the point they conflic with how the machine works.
Yes, I agree with that. C++ doesn't entirely disconnect you from the machine. This is either one of C++'s strong points, or weak points depending on how you look at it. I think it's a strong point personally.
So here's a question: Does the same argument hold for Java, where the machine in this case is the Virtual Machine?
Ok, it's a little tacky to name drop in general... but cool, eh?!
That's very cool actually. That must have been sometime around 95-96 or so. I'm jealous, when I get the opportunity to learn from a decent scholar like this, it's usually when I'm too busy and can't go.:(
It doesn't make the language butchered in the least, quite the opposite, the end result is very clear to use and the confusing part is hidden inside the classes, where it cannot cause trouble.
I just posted my comment, because some people really revile metaprogramming techniques. It was a bad joke.
Blitz++ uses templates in an elegant, mind blowingly cool way.
That's what scares the crap out of me.;) I've got it bookmarked now, so I'll check it out.
It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
Hopefully better then the way ACE uses them. Man, that thing was a pain to debug. It also took several hours to build on a Sparc with the Sun compiler because of the templates, AND I had to add swap. Sheesh.
but you have to remember that C++ is designed to open up the power of the machine to you, not make you think a particular way or be magical for you.
I guess any language ends up indirectly making you think in a different way. Maybe that's the magical part.
The onus is on the "our language does it for you" crowd because you were not supposed to say "oh, you have to understand how the VM is working"... right?
Well, my point was that the languages are different in more ways than many C++ programmers (or Java programmers) realize. For instance, many C++ programmers think that finalize methods are destructors, and many of them use finalize incorrectly because of this. Then some of these programmers choose to complain loudly about Java, when the problem lies with them. They need to learn a new paradigm or their programs will continue to function incorrectly. There are definitely best practices in C++ that are bad ideas in Java.
Obviously, this works in reverse, too. You can't go from Java to C++ without changing your thinking as well. Many Java programmers have made this mistake.
Of course, in the end, all languages will have to tell us this "oh, yes, well, you have to know something". Of course you do! It will always be this way.
So choose the most efficient and effective language for you and learn it well, learn a different one if called for, etc.
Yeah, I agree. I use languages as a tool, not a crutch. If I see a problem that is better represented by Perl than Java, I'll use Perl. Or Python, or 6502 assembly...
Java memory management seems to be a lot like Applesoft Floating Point BASIC. The program would run fine, allocating strings and variables until a garbage collection pass occurred. So, at unpredictable intervals your program would slow to a crawl, and then speed up again.
In Java, that's usually a sign that either you need to increase the size of the Java heap, or you have a memory leak somewhere. The pauses you are seeing are when the JVM does a "full" garbage collection. It does this whenever the heap gets close to being exhausted. This is a last resort mechanism to try to free up as much memory as possible before throwing an OutOfMemoryException. I would take a look at your program and determine if it needs more memory to run normally, and run OptimizeIt on it to check for leaks.
Slashdot Mirror
Yeah, tell me about it.
--
Dick Hertz
Holden, MA
How about allowing the crew time to contact their familes before they die?
For instance, "launching now would kill the crew", becomes, "the current orbital insertion paradigm may cause a negative value proposition for this and all future missions".
See how much more understandable the second quote is? The best part about it is that it doesn't mention death, which is better for shareholder value.
Been there, done that.
While I was running a 400M, the guy next to me clipped my leg causing me to fall face first onto a cinder track...
...10M from the finish line.
I went from first place to last place in a split second. And, yes, it fucking hurt.
It's alright, though. I got the fucker in the relay. Muh, ha, ha, ha!
Probably should have taken this one offline. Whoops.
However, I maintain that it is rare to need it in C++ otherwise.
Especially if you use something like ACE.
The point is that this is another requirement imposed on the programmer, whereas again in C++ it's handled by the language itself via templates.
That's true, it's an idiom in Java. The good news is, a lot of people complained, so templates are going into the language for 1.5. Before Sun committed to that, a ton of people used GJ. I don't look on wrapping as much of a problem, because usually the generic container doesn't do everything I want, so I end up wrapping the container anway (e.g. I want to label all the apples).
If you're unlucky, and the finalizer never runs, you have a resource leak. Alas, even Sun's own material sometimes implies that the finalizer will always clean up, which is not a safe thing to do.
That's because there's a lot of myths surrounding garbage collection. The GC doesn't read minds, and if there is heap left above its threshold, it's not going to make an attempt at cleaning up garbage. In small programs, you may not even see finalizers run before the program exits, which is usually not an issue. In memory intensive or long running programs, you end up with gigantic pauses when the GC decides to suddenly clean things up, much to the astonishment of the horrified programmer standing in front of the large group of VC. The myth is that the System.gc() call has no effect (or can't be trusted to have an effect), so no one bothers to call it. The truth of the matter is that System.gc() should be called once in a while, simply because the GC can't read your mind. So Sun's documentation isn't lying about the finalizer. It will clean things up, but the GC has to get involved with the object first.
At any rate, it's much better practice to call my_stream.close() explicitly in a finally block when you're done with the stream.
Oh definitely. Although with your own classes, you may want to implement finalize anyway, and have it call close or whatever. That way, if somebody forgets to close, it'll get cleaned up eventually.
In each case, you just use these to access your resources, and never have to write the release code again. If the resource ownership is handled by whatever library supplies the resource -- and in decent libraries it invariably is -- then you never have to worry about the release issue at all, and you never have to write even a single line of release code yourself.
That's what I was trying to point out. There's quite a few interfaces in Java as well that manage their resources so you don't have to. Actually, you've given me an idea for something more generic.
Didn't someone later write a lengthy criticism demonstrating that that idiom wasn't so safe after all, though?
From what I remember, they didn't implement it correctly. However, this too will soon be a moot point. Check out who the spec. lead is.
Yeah, that works pretty good. Usually I have one of the methods on my wrapper class create a Collection for just such an emergency.
Great way to learn how things work, but when there are industrial strength xml parsers out there - why not use them.
True dat. I think the expat author said something to the effect of, "You don't write an XML parser".
That's one thing I love with java though, You will always find something in the standard libs that'll do the thing you want to do. Some call it bloat, but I rather see it as a helping hand.
You know, as far as I can tell, it's not any more or less bloated than Ada, Smalltalk, Perl, Python, or even STL. Everything has a little bit of bloat.
This seems pretty ironic in light of:
Not in the core language, no. C++ inherits its runtime from C, though, so many important APIs return void*. So, I end up casting quite often for system related functions in C++ where in Java I don't.
You keep implying that I don't understand Java, without giving any supporting reasoning.
Alright, that's fair. I'll try to be a little more clear. That's not to say that I'm going to straight out give you the answer.
This isn't very constructive, not least because you're way off-target in guessing my Java experience.
Okay, I'll give you that. There are certain programming idioms that you use in C++, right? Do you use Java's idioms, or do you try to apply C++ idioms to Java?
Why do you think that I think finalizers are supposed to be destructors?
Maybe I shouldn't have assumed, but it's been my experience that when C++ programmers complain about Java while citing RAII, it usually means that they've tried to use a finalizer as a destructor. "They tried and failed?" "They tried and died."
Why do you think I don't know how to do resource management properly in Java?
Well, let me ask you this: What happens when you forget to close a FileInputStream? Why? What are Reference objects?
OK, getting back to the point, how do you propose to store a set of Apples and pull them out of the container without casting in (pre-generics) Java? What is it that I, my colleagues, pretty much every book on Java I've ever read and Sun's own Java web site are all missing?
If you use the generic containers, you need to cast, because the containers return an Object type. However, you only need 1 cast. Ask yourself, why isn't it a good idea to use generic container types directly?
C++ moved past this years ago with RAII.
And, C++ doesn't force you to use it. You can still screw it up too can't you? That's because it's an idiom. So by the same token, yeah, you can screw up Java idioms or not use them too, right? The point is, the languages have different idioms, and if you're going to use C++ idioms in Java you're going to have a bad time.
With these idioms, write your resource release code once, and then get it for free every time you use the resource
Which class do I inherit so my code can release any kind of resource without having to recode it specifically for that resource?
In Java, you have to remember to write a finally block and get it right every time you use a resource.
Hmmm, never noticed. Probably, because I don't use it every time, and it's not that easy to screw up.
don't you think some of us might have read those books you mentioned?
Well, did you?
Oh, yeah, definitely The initial thought is, "Why am I doing this again?" Then your performance engineer comes back and says, "It's too slow". That's when you realize that that one little wrapper will keep you from working the weekend.
Oh, one more tip: Don't use the concrete types like HashMap to the left of a declaration and in method parameters, use an abstract type like Map. It'll save you some agony.
we're not allowed to introduce any meta/pre compilers into our toolchain though at work
Too bad. GJ + AspectJ + JUnit is a killer combo.
I hear you, though, in '96, my boss wouldn't let us add the CGI module in Perl, even though that was the defacto standard. Even after CGI got added in as part of Perl, she still wouldn't let us use it. So I spent a lot of my time enhancing and fixing defects in our cgi library. :(
Anyway...
I don't think we disagree with that either. We're just saying that C++ doesn't abstract everything away from the way the machine works. For instance, in C++ there is the register storage class, which other languages don't have an equivalent to.
Cool, that's what I thought. He's got a book called Skeptical Essays, besides the translation of Sextus Empiricus, BTW. It looks like it could be interesting.
I don't know a lot about him, actually, but I was told he was a well respected logician, and I do know that logic was his main area of expertise/study.
Me either, I just knew that he had a book on logic. Now I know he's got some books on skepticism as well. Thanks for that information.
Fortran is the language used in the communication terminals the Navy uses to send and receive data through the Milstar satellite communication network.
These devices are used in ground stations, ships, and boomers. That's a pretty major application.
How often do people actualy use a goto in Fortran? I can't remember ever using a goto in the Fortran stuff I did. Of course, we had a preprocessor that may have helped with this, so I'm not sure if it didn't turn certain constructs into gotos. Seriously, how often do people use a goto?
And remember, it's not a C++ style comment, it's an Algol style comment!
Ahh, I was just a tad off there. Does he teach logic as well?
I do an excessive amount of casting in C++, because many things return a void*.
I'm assuming that what you're referring to is lack of templates in combination with the generic containers in java.util.
Did you ever think for a minute that you're actually using them wrong?
Similarly, you do need to use finally an excessive amount because Java's garbage collection mechanism is only good for avoiding memory leaks, not resource leaks in general.
I'm not really sure why you think that the garbage collector should help you with resource deallocation.
Java doesn't have destructors. Are you trying to use finalize() as a destructor? That's not what it's for.
It's a last resort mechanism, which is the reason why uncaught exceptions get ignored in finalize methods.
In Java, you explicitly tell an object that you are done using it, and then null out the reference.
That seems pretty straightforward to me.
What is so horrible about the finally block? It should make your code smaller, not larger.
If you have some technique or idiom for avoiding these problems, please share it, because I'm sure a lot of Java programmers would like to hear it.
These can help:
I wrap all my generic containers in types that perform specific operations on the type I wish to contain.
There's a lot of advantages to doing this:
- It's more object-oriented.
- You end up with a single cast inside the object which contains the generic container.
- You get compile-time type checking.
- It's easy to make drastic changes to the container implementation without having to recode the client.
This is more than making a simple wrapper class, and thus I do this in C++ as well (even with templates).If you find this detestable, you can also use Generic Java.
Generics is a thing java has been sorely lacking since it's birth, thank god they're getting it now at last! (yes, I do code java for a living)
I agree. Unfortunately, it will probably be abused. :(
Yes, I agree with that. C++ doesn't entirely disconnect you from the machine.
This is either one of C++'s strong points, or weak points depending on how you look at it. I think it's a strong point personally.
So here's a question: Does the same argument hold for Java, where the machine in this case is the Virtual Machine?
That's very cool actually. That must have been sometime around 95-96 or so. :(
I'm jealous, when I get the opportunity to learn from a decent scholar like this, it's usually when I'm too busy and can't go.
Alright, fine. This may be easier for you to understand:
Yo, beeyatch! Yo best be down wit the new snootch else I put a cap in yo ass!
You got it, dood.
I just posted my comment, because some people really revile metaprogramming techniques. It was a bad joke.
Blitz++ uses templates in an elegant, mind blowingly cool way.
That's what scares the crap out of me. ;) I've got it bookmarked now, so I'll check it out.
It might not be clear how it works to many, but that doesn't change how it works. Truly beautiful. And it makes the code easier to read, not harder.
Hopefully better then the way ACE uses them. Man, that thing was a pain to debug. It also took several hours to build on a Sparc with the Sun compiler because of the templates, AND I had to add swap. Sheesh.
I guess any language ends up indirectly making you think in a different way. Maybe that's the magical part.
The onus is on the "our language does it for you" crowd because you were not supposed to say "oh, you have to understand how the VM is working"... right?
Well, my point was that the languages are different in more ways than many C++ programmers (or Java programmers) realize. For instance, many C++ programmers think that finalize methods are destructors, and many of them use finalize incorrectly because of this. Then some of these programmers choose to complain loudly about Java, when the problem lies with them. They need to learn a new paradigm or their programs will continue to function incorrectly. There are definitely best practices in C++ that are bad ideas in Java.
Obviously, this works in reverse, too. You can't go from Java to C++ without changing your thinking as well. Many Java programmers have made this mistake.
Of course, in the end, all languages will have to tell us this "oh, yes, well, you have to know something". Of course you do! It will always be this way.
So choose the most efficient and effective language for you and learn it well, learn a different one if called for, etc.
Yeah, I agree. I use languages as a tool, not a crutch. If I see a problem that is better represented by Perl than Java, I'll use Perl. Or Python, or 6502 assembly...
PS: "pyrrhonist"... right on!
I like yours too. Pyrrho was cool.
Hey, we could all do a DOS attack simply by entering the wrong name over and over!
In Java, that's usually a sign that either you need to increase the size of the Java heap, or you have a memory leak somewhere. The pauses you are seeing are when the JVM does a "full" garbage collection. It does this whenever the heap gets close to being exhausted. This is a last resort mechanism to try to free up as much memory as possible before throwing an OutOfMemoryException. I would take a look at your program and determine if it needs more memory to run normally, and run OptimizeIt on it to check for leaks.