On April 20, 1999 a couple of kids brought improvised explosive devices to Columbine high school along with a handful of guns. Their explosives failed to detonate but they did manage to kill 13 people and injure a whole bunch more. As usual, Wikipedia has more.
Cat: Forget red - let's go all the way up to brown alert! Kryten: There's no such thing as a brown alert sir. Cat: You won't be saying that in a minute! And don't say I didn't alert you!
No, I don't really make that assumption at all and you're really missing the point. "Somebody else coulda done it and maybe better" in no way causes this contribution to have less value.
Re-read your post again a few times but try replacing "Google" with some other tools you use to do your job: Linux, GCC,... In each case although it is arguably true that someone else could have made that contribution and possibly done a better job of it -- but that doesn't devalue the contribution at all.
Well, yes. Given the amount of coverage their IPO story got and the number of blurbs about them tied to their stock performance and the frequency with which it is mentioned I would hazard to guess that quite a few businessmen, day-traders, and so on are at least peripherally aware of this fact.
Ignoring, for instance, the Summer of Code (and all of the other grants they've made) Google has made one contribution to Linux users everywhere: google.com.
To start with, Google is the most well-known poster-child of Linux success. If you don't think that adds value to every other opensource project, well... *shrug*
As a more tangible and direct benefit I can say that google.com is an immense resource as far as answering any Linux question which comes my way. Between the web search and usenet search features they provide to everyone free it makes using Linux a lot easier. Stop in on any Linux IRC channel and you'll see what I mean. I volunteer off and on doing Linux support and I can tell you that without Google there would be a lot of questions that I would be unable to answer.
Ask and ye shall recieve. Note that I am not a physicist and I am in no way an expert in fluid dynamics -- I'm certain that there is some technical innacuracy in the post which follows. I welcome any corrections anyone may make, so long as they don't mock me too much for my ignorance (which I've already disclaimed).
That said, I invite you to consider the ideal gas law, and one of the derived equations (Boyle's law if memory serves -- but it's been a loooong time since my last physics class) which indicates that p[1]v[1]/t[1] = p[2]v[2]/t[2]. Let's start with a simple scenario, a bottle of canned air like you might use to blow the dust out of your computer. If you hold it in your hand while you discharge the gas contained inside you're lowering the presssure inside the container, but the volume remains a constant. But the equation still balances -- you will see a drop in temperature. This is part of how your air conditioner works.
Now let's look at it from the other side: say you're down at the local SCUBA shop and they're filling someone's tank. The volume of the container remains a constant, but the pressure climbs -- and you will note an increase in the temperature (this is why they fill tanks slowly and immerse them in a cooling bath while filling them).
Now take the shuttle, which is moving seriously fast when it's inserted into the atmosphere. The shuttle (and to a large extent the shockwave it generates as it slides in) is going to compress a LOT of air, really hard and really fast, which is going to make a LOT of heat.
Note that I'm not saying that a shuttle insertion is frictionless, just that the vast majority of the heat comes from compression of the gasses in the atmosphere gasses. The angle they put the shuttle in at is picked, in part, to minimize the friction experienced: if the shuttle came into the atmosphere at the wrong angle there'd be considerably more friction and no shuttle to land.
Well, who knows what you're talking about then Jerry, because the question was about something that happened while the shuttle was parked on the runway going through the postflight shutdown procedures.
No matter, it's already been answered and I'm glad to know they're home safe.
Negative. The pilot handles most of the banking maneuvers as the skycar glides in on approach leaving the commander free for any comms with Houston and to load the updated nav data then there is an exchange of flight controls and the commander handles the landing.
Is there news on why they landed at the alt instead of Florida?
The usual: weather. WALO were favorable but there was a cloud deck which would interfere with sighting on the runway and showers in the 30NM zone they want clear when they bring the shuttle down at KSC.
Ram pressure != friction. Very little of the heat from re-entry is from friction. The insertion into the atmosphere is made very carefully to minimize friction.
A quick question to any shuttle geeks who might be reading: I watched the landing and then found myself staring at an infrared shot of the aft end of Discovery on the ground. To the immediate left of the vertical stabilizer/rudder assembly there was a patch of air that kept lighting up and going dim, kind of like what you'd see if you light a bit of gas on fire. Any ideas what that might be? It didn't look rythmic enough to be a landing light or steady enough to be heat venting.
The problem is, a good portion of people who loudly support Perl cite these kinds shortcuts as reasons they can write code quickly (and with as few characters as possible).
The people you hear saying these things are probably people who write "one shots" and "one liners" a lot of the time, and this is one of several scenarios where Perl excels. If you're writing a program (or a series of programs) on the command-line fewer characters quickly becomes a major asset. But that really becomes a matter of "Perl as a better shell" and not "Perl as a programming language".
But if you're working on a larger program and not just a few quick lines to do something now you quickly learn about the Right Place. Face it, every language has a number of things where you can say, "just because you can doesn't mean you should". To put it another way: you can write brainfuck in any language.
We do regular and thorough code reviews at my shop. If I see an idiom I'm not familiar with or a shortcut which detracts from readability I always flag it and propose a more verbose solution. My co-workers do the same for my code. After a few months of this it happens much less frequently -- by a sort of "reverse acclaim" process we've settled into the subset of the language we feel is appropriate for the tasks we're performing.
I'm starting to sound like a bit of an evangelist, but of any language I've seen, Ruby is the closest to what you've asked for.
I'll definately have to check it out. Thanks for the heads up.
I'll admit - I'm no Perl guru. I could make better arguments if I were. Because of my interest in languages, I'll get to it one of these days.
Do that. I think you might be happily surprised. Perl's an awesome tool for a lot of things and it can be a lot of fun to work with.
C++ is not the pinacle of OO design,
If you'll take a quick second to re-read what I'd said you'll note that I didn't claim it was. In point of fact my assertion was pretty much the opposite.:)
I'm glad you're here backing up your side maturely.
I'm glad I posted on a language discussion and didn't need protective clothing for it. One thing though: I don't really have a side on the choice of language issue because I have no personal stake in it. At my most recent interview I was asked if I'd be willing to learn Python after I started -- I said, "Sure -- Perl's a job skill, not a religion."
This thread is really starting to make my point for me.
I dunno. Unless your point was that you shouldn't use features of a language you don't understand I don't think this made your point at all.
Perl is just too idiosyncratic. There's too much to remember,
Funny that... Once you understand the key philosophies which made Perl the way it is, it doesn't really seem that odd -- and given that its backgrounds are in UNIXish operaring environments and C programming culture it maps to my own experiences quite well. As to the "too much to remember" I'd answer, "No. Not really.". It's neat that a lot of the one-off stuff is there but you don't really need to commit it to memory.
and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.
Hm.... I don't spend my time thinking about the niche features at all. I spend my time looking at how to write the program and then writing the program. Take the comments about the diamond operator, for instance. I know it's there, I know I can use it if I want to, but until VGPowerlord brought up its magic behavior in the no-filehandle-given case I hadn't thought about that aspect for... Oh, six years.
And that was just correcting a newbish misunderstanding about the language -- if you know of a language where new programmers don't make any mistakes or misunderstand anything I'd love to learn it.
Don't go telling me that Perl has superb OO features.
Well, you don't want to hear it so I won't say it. I will say that Perl's OO mechanisms are quite nice and dovetail quite simply with the way Perl does everything else. For sharp contrast look at how C++ handles OO behaviors.
I swear I'm done. I'll go piss off some Java people now, unless any Python junkies want to step up (I haven't yet seen much of that yet, and I'm surprised)...
Well, if you were trying to piss someone off I think you failed miserably. You made well reasoned arguments and presented them without being inflammatory. I happen to disagree with you but that's not enough to piss me off.
I'll close by saying that the important thing to me about Perl isn't if it's the perfect programming language or not. No, the important thing is that it let's me do the work I need to do quickly and easily while I get paid a handsome sum to do something I enjoy.
Your point about the default operands is well received -- but it's a handy feature included in the language primarily to support a specific scenario: one-liners. A small change in your mindset will help you tremendously with these -- think about Perl as being rather like an RPN calculator.
As to the diamond operator it has an ecological niche which is part of Perl's philosophy of cooperation -- in this case the cooperation is making it easy to write Perl programs which exhibit similiar behavior to a whole slew of unixish shell utilities. Say you wanted to make a special kind of 'cat' utility -- the diamond operator would prove quite handy for this.
In both cases these default behaviors are there to make certain sorts of tasks easier to perform with Perl. Use them when appropriate. Use the more explicit longhand format when appropriate.
Slashdot Mirror
Some HAMs are reporting excellent signal propogation and some awesome DX contacts...
I like it!
That's Blasphemy! FSM WTF
Damn. They billed you for login time?? My quota was on normalized CPU hours, and at a certain nice level spare processor time was free.
On April 20, 1999 a couple of kids brought improvised explosive devices to Columbine high school along with a handful of guns. Their explosives failed to detonate but they did manage to kill 13 people and injure a whole bunch more. As usual, Wikipedia has more.
How is it that you have time to answer questions on Slashdot but elect to ignore questions and problems reported by paying users on your own forums?
Cat: Forget red - let's go all the way up to brown alert!
Kryten: There's no such thing as a brown alert sir.
Cat: You won't be saying that in a minute! And don't say I didn't alert you!
He touched my breast!
But aren't those registered trademarks of the MPAA ?
Seriously, does it give you pleasure being so pedantic that you're unable to come to reasonable conclusions based on the context of a statement?
Re-read your post again a few times but try replacing "Google" with some other tools you use to do your job: Linux, GCC, ... In each case although it is arguably true that someone else could have made that contribution and possibly done a better job of it -- but that doesn't devalue the contribution at all.
Well, yes. Given the amount of coverage their IPO story got and the number of blurbs about them tied to their stock performance and the frequency with which it is mentioned I would hazard to guess that quite a few businessmen, day-traders, and so on are at least peripherally aware of this fact.
To start with, Google is the most well-known poster-child of Linux success. If you don't think that adds value to every other opensource project, well... *shrug*
As a more tangible and direct benefit I can say that google.com is an immense resource as far as answering any Linux question which comes my way. Between the web search and usenet search features they provide to everyone free it makes using Linux a lot easier. Stop in on any Linux IRC channel and you'll see what I mean. I volunteer off and on doing Linux support and I can tell you that without Google there would be a lot of questions that I would be unable to answer.
Just a thought...
That said, I invite you to consider the ideal gas law, and one of the derived equations (Boyle's law if memory serves -- but it's been a loooong time since my last physics class) which indicates that p[1]v[1]/t[1] = p[2]v[2]/t[2]. Let's start with a simple scenario, a bottle of canned air like you might use to blow the dust out of your computer. If you hold it in your hand while you discharge the gas contained inside you're lowering the presssure inside the container, but the volume remains a constant. But the equation still balances -- you will see a drop in temperature. This is part of how your air conditioner works.
Now let's look at it from the other side: say you're down at the local SCUBA shop and they're filling someone's tank. The volume of the container remains a constant, but the pressure climbs -- and you will note an increase in the temperature (this is why they fill tanks slowly and immerse them in a cooling bath while filling them).
Now take the shuttle, which is moving seriously fast when it's inserted into the atmosphere. The shuttle (and to a large extent the shockwave it generates as it slides in) is going to compress a LOT of air, really hard and really fast, which is going to make a LOT of heat.
Note that I'm not saying that a shuttle insertion is frictionless, just that the vast majority of the heat comes from compression of the gasses in the atmosphere gasses. The angle they put the shuttle in at is picked, in part, to minimize the friction experienced: if the shuttle came into the atmosphere at the wrong angle there'd be considerably more friction and no shuttle to land.
No matter, it's already been answered and I'm glad to know they're home safe.
Negative. The pilot handles most of the banking maneuvers as the skycar glides in on approach leaving the commander free for any comms with Houston and to load the updated nav data then there is an exchange of flight controls and the commander handles the landing.
The usual: weather. WALO were favorable but there was a cloud deck which would interfere with sighting on the runway and showers in the 30NM zone they want clear when they bring the shuttle down at KSC.
Ram pressure != friction. Very little of the heat from re-entry is from friction. The insertion into the atmosphere is made very carefully to minimize friction.
Just curious...
The people you hear saying these things are probably people who write "one shots" and "one liners" a lot of the time, and this is one of several scenarios where Perl excels. If you're writing a program (or a series of programs) on the command-line fewer characters quickly becomes a major asset. But that really becomes a matter of "Perl as a better shell" and not "Perl as a programming language".
But if you're working on a larger program and not just a few quick lines to do something now you quickly learn about the Right Place. Face it, every language has a number of things where you can say, "just because you can doesn't mean you should". To put it another way: you can write brainfuck in any language.
We do regular and thorough code reviews at my shop. If I see an idiom I'm not familiar with or a shortcut which detracts from readability I always flag it and propose a more verbose solution. My co-workers do the same for my code. After a few months of this it happens much less frequently -- by a sort of "reverse acclaim" process we've settled into the subset of the language we feel is appropriate for the tasks we're performing.
I'm starting to sound like a bit of an evangelist, but of any language I've seen, Ruby is the closest to what you've asked for.
I'll definately have to check it out. Thanks for the heads up.
I'll admit - I'm no Perl guru. I could make better arguments if I were. Because of my interest in languages, I'll get to it one of these days.
Do that. I think you might be happily surprised. Perl's an awesome tool for a lot of things and it can be a lot of fun to work with.
C++ is not the pinacle of OO design,
If you'll take a quick second to re-read what I'd said you'll note that I didn't claim it was. In point of fact my assertion was pretty much the opposite. :)
I'm glad you're here backing up your side maturely.
I'm glad I posted on a language discussion and didn't need protective clothing for it. One thing though: I don't really have a side on the choice of language issue because I have no personal stake in it. At my most recent interview I was asked if I'd be willing to learn Python after I started -- I said, "Sure -- Perl's a job skill, not a religion."
I dunno. Unless your point was that you shouldn't use features of a language you don't understand I don't think this made your point at all.
Perl is just too idiosyncratic. There's too much to remember,
Funny that... Once you understand the key philosophies which made Perl the way it is, it doesn't really seem that odd -- and given that its backgrounds are in UNIXish operaring environments and C programming culture it maps to my own experiences quite well. As to the "too much to remember" I'd answer, "No. Not really.". It's neat that a lot of the one-off stuff is there but you don't really need to commit it to memory.
and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.
Hm.... I don't spend my time thinking about the niche features at all. I spend my time looking at how to write the program and then writing the program. Take the comments about the diamond operator, for instance. I know it's there, I know I can use it if I want to, but until VGPowerlord brought up its magic behavior in the no-filehandle-given case I hadn't thought about that aspect for... Oh, six years.
And that was just correcting a newbish misunderstanding about the language -- if you know of a language where new programmers don't make any mistakes or misunderstand anything I'd love to learn it.
Don't go telling me that Perl has superb OO features.
Well, you don't want to hear it so I won't say it. I will say that Perl's OO mechanisms are quite nice and dovetail quite simply with the way Perl does everything else. For sharp contrast look at how C++ handles OO behaviors.
I swear I'm done. I'll go piss off some Java people now, unless any Python junkies want to step up (I haven't yet seen much of that yet, and I'm surprised)...
Well, if you were trying to piss someone off I think you failed miserably. You made well reasoned arguments and presented them without being inflammatory. I happen to disagree with you but that's not enough to piss me off.
I'll close by saying that the important thing to me about Perl isn't if it's the perfect programming language or not. No, the important thing is that it let's me do the work I need to do quickly and easily while I get paid a handsome sum to do something I enjoy.
As to the diamond operator it has an ecological niche which is part of Perl's philosophy of cooperation -- in this case the cooperation is making it easy to write Perl programs which exhibit similiar behavior to a whole slew of unixish shell utilities. Say you wanted to make a special kind of 'cat' utility -- the diamond operator would prove quite handy for this.
In both cases these default behaviors are there to make certain sorts of tasks easier to perform with Perl. Use them when appropriate. Use the more explicit longhand format when appropriate.
I'm pulling for you. We're all in this together.
Even reading the submission would have been enough, you slimy little piece of troll shit.
...well, obviously they don't need to. You're still paying for it, right?
Now that's a bit of an overstatement.