From: Stefan Hundhammer
[snip]
The other myths about object orientation etc. are similar: If you do non-trivial software, you simply NEED that kind of thing so you can have the kind of abstraction level you will want to have so the software can be mantained at all, much more for extended periods of time.
Many would disagree and consider it a myth that OO is more maintanable. There are few proofs outside of the limited scope of GUI code that shed positive light on the OO philosophy. [snip]
Today's software is supposed to do everything, including making coffee, cleaning your shoes and taking the dog out. You do not want to write that kind of software with a 70s era approach - monolithic blocks of code like people used to write with old Pascal, C, or (heaven forbid) FORTRAN.
Procedural code is no more likely to create "monoliths" than OO. In fact, surveying the memory map of many OO developed applications would tend to make one believe the purpose of OO is to produce massive, resource-hogging monoliths. In the C world there is an old and established concept called libraries. Any well written library means your C program doen't have to re-invent the wheel.
Sure, you CAN do that. But it hurts - big time.
C's string handling for instance sucks - it is the source of most security holes that need to be fixed.
Bad, lazy programmers are the source of security holes regardless of language.
Buffer overflows happen because C does not have a concept for variable length strings - it only has character pointers. What a nightmare.
Buffer overflows happen in many languages, not just C, due to bad, lazy programmers.
Been there, done that, hated it from the bottom of my guts.
I have been programming since the mid-80s, and even though I also tend to bitch about many things, things have improved a lot since then. No more rebooting because a null pointer in C overwrote your PC's interrupt table at 0000:0000 on MS-DOS. Anybody remember what a PITA that was?
No more dumbass 64k limits because certain ingenious inventors had considered that much memory "enough for everybody".
This is a matter of history and architecture. It's no more dumbass that any other physical limitation of hardware today. At one time 64K was viewed as generous and quite a lot of useful programs worked in it. There was a time where it was not possible -- physically, or economically -- for a typical computer to address more than 64K (or 16K or 4K depending on how far back in history you'd like to go.) Every Opteron system does not come with 64 Gigabytes of physical RAM, in spite of a theoretical 64-bit address space vastly larger than that, so is that dumbass?
And today, it's no more segfaults because the C string handling is so dumb.
Konquerer segfaults more than anything else I know. Is that written in C?
Use modern tools. Use tools like C++ - or, for that matter, C#, or even Java. Use predefined (meaning: well-tested) classes for common purposes. Do not repeat everybody's (and their mothers' ) mistakes by writing your own because you think you can do a better job at that.
Nobody is arguing every C program must be written from scratch.
You argue this comes at a price - and the price is performance and system resources. That may be right, but I rather sacrifice some MB of RAM rather than experience random crashes because nobody can debug a software of that complexity written with outdated tools any more. My time (and, for that matter, my nerves) are way more precious to me than some MB of RAM saved.
The OO approach has not eliminated bugs, crashes, errors, and the other ills of software. It has succeeded in making computers vastly slower -- a boon to the hardware industry, since everyone always needs to upgrade to maintain the status quo.
On Friday 15 April 2005 11:50 am, synthetoonz@bellsouth.net wrote:
Many would disagree and consider it a myth that OO is more maintanable. There are few proofs outside of the limited scope of GUI code that shed positive light on the OO philosophy.
Procedural code is no more likely to create "monoliths" than OO. In fact, surveying the memory map of many OO developed applications would tend to make one believe the purpose of OO is to produce massive, resource-hogging monoliths. In the C world there is an old and established concept called libraries. Any well written library means your C program doen't have to re-invent the wheel. One should take a look at FORTH, or at least Charles Moore's writings. Using already existing tested code has long been a good programming practice. This is why we have standard libraries in C (libc), and C++(stdc++, STL).
Bad, lazy programmers are the source of security holes regardless of language. I generally agree with this, but not all security holes are caused by bad and lazy programmers. A lot of times, there are some risks in code because the programmer has not forseen it. One real problem in the industry, and has been since Grace Hopper found the first bug, is the lack of proper testing. I have rarely seen a situation where a proper design-code-unit-test-test cycle has been effectively utilized. I've also seen many programmers who don't have a clue how to test. But, I've also seen some people who can take a well designed and tested application, and find bugs immediately. -- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Saturday 16 April 2005 02:06, Jerry Feldman wrote: snip>
One should take a look at FORTH, or at least Charles Moore's writings. Using already existing tested code has long been a good programming practice. This is why we have standard libraries in C (libc), and C++(stdc++, STL).
Bad, lazy programmers are the source of security holes regardless of language.
I generally agree with this, but not all security holes are caused by bad and lazy programmers. A lot of times, there are some risks in code because the programmer has not forseen it. One real problem in the industry, and has been since Grace Hopper found the first bug, is the lack of proper testing. I have rarely seen a situation where a proper design-code-unit-test-test cycle has been effectively utilized. I've also seen many programmers who don't have a clue how to test. But, I've also seen some people who can take a well designed and tested application, and find bugs immediately.
I agree with both of you. In particular, I was given two weeks to test some code. I told the young guy who had written most of it (he is exceptionally good) that I had been given two weeks to test it, but he just walked out the door ??? Then I discovered that he had gone back to his room and estimated that the code would take two man-years to test. He presented this estimate to the boss who increased to test time to four weeks. A year after I left they fired the official tester! That's an M$ attitude for you!
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Regards, Colin
On Saturday 16 April 2005 02:06, Jerry Feldman wrote:
One real problem in the industry, and has been since Grace Hopper found the first bug, is the lack of proper testing. I have rarely seen a
Jerry, I don't think that this is correct. Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II. When the computer started to miss-behave they checked the equipment and discovered that the warmth of the relays had attracted bugs which prevented them from operating properly. So a routine operation was to de-bug the relays. At the end of the war the English destroyed almost every part and document because they believed that this 'machine' would never be needed again. Foolish people. Not a one-off: they also GAVE the Americans the jet engine....
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Regards, Colin
Colin Carter wrote:
On Saturday 16 April 2005 02:06, Jerry Feldman wrote:
One real problem in the industry, and has been since Grace Hopper found the first bug, is the lack of proper testing. I have rarely seen a
Jerry, I don't think that this is correct. Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II. When the computer started to miss-behave they checked the equipment and discovered that the warmth of the relays had attracted bugs which prevented them from operating properly. So a routine operation was to de-bug the relays. At the end of the war the English destroyed almost every part and document because they believed that this 'machine' would never be needed again. Foolish people. Not a one-off: they also GAVE the Americans the jet engine....
Not to mention the Russians as well (the jet engine) ....
-- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!!
On Sat, 16 Apr 2005 15:16:27 +1000
Colin Carter
On Saturday 16 April 2005 02:06, Jerry Feldman wrote:
One real problem in the industry, and has been since Grace Hopper found the first bug, is the lack of proper testing. I have rarely seen a
Jerry, I don't think that this is correct. Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II. What you are talking about is Alan Turing's Enigma machine. But, what I was referring to is the coining of the word, "bug". I was fortunate to have had lunch with Grace Hopper once back around 1980.
http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm
--
Jerry Feldman
On Sunday 17 April 2005 23:41, Jerry Feldman wrote:
On Sat, 16 Apr 2005 15:16:27 +1000
Colin Carter
wrote: On Saturday 16 April 2005 02:06, Jerry Feldman wrote:
One real problem in the industry, and has been since Grace Hopper
found
the first bug, is the lack of proper testing. I have rarely seen a
Jerry, I don't think that this is correct. Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II.
What you are talking about is Alan Turing's Enigma machine. But, what I was referring to is the coining of the word, "bug". I was fortunate to have had lunch with Grace Hopper once back around 1980. I agree that that would have been a great honour. I envy you.
http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm
Interesting site. But I don't believe what I read, especially when it comes to computer stuff ;-)
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
I don't mean to be offensive Jerry, but It is interesting that Americans discovered the first bug after the English had destroyed their programmable computer. I also have an American book which describes the world's first auto-pilot flight - about two years after British European Airways were conducting routine auto-land in London's pea soup fogs. ("Fly the Wing" by Jim Webb, otherwise a very good book.) But I won't be pig headed about my belief - I just believe so. Especially since (I believe) the English had already destroyed their machine. I am interested in establishing which of us is 'correct', so don't drop out here. Note: I said 'establish', not 'prove I am right'. I hate that! Regards, Colin
On Mon, 18 Apr 2005 00:41:22 +1000
Colin Carter
http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm
Interesting site. But I don't believe what I read, especially when it comes to computer stuff ;-)
I don't mean to be offensive Jerry, but It is interesting that Americans discovered the first bug after the English had destroyed their programmable computer. This is true. Both the Germans and the English had one before the Americans. But, I was talking about the coining of the word, "BUG".
I also have an American book which describes the world's first auto-pilot flight - about two years after British European Airways were conducting routine auto-land in London's pea soup fogs. ("Fly the Wing" by Jim Webb, otherwise a very good book.)
But I won't be pig headed about my belief - I just believe so. Especially since (I believe) the English had already destroyed their machine.
I am interested in establishing which of us is 'correct', so don't drop out here. Note: I said 'establish', not 'prove I am right'. I hate that! I'm not a drop out, but I did drop (by way of a baseball bat) some jerk out of my helicopter at an altitude he was not prepared to drop from.
--
Jerry Feldman
On Monday 18 April 2005 00:48, Jerry Feldman wrote:
On Mon, 18 Apr 2005 00:41:22 +1000
Colin Carter
wrote: http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm
Interesting site. But I don't believe what I read, especially when it comes to computer stuff ;-)
I don't mean to be offensive Jerry, but It is interesting that Americans discovered the first bug after the English had destroyed their programmable computer.
This is true. Both the Germans and the English had one before the Americans. But, I was talking about the coining of the word, "BUG". Yes I realize that. snip>
I am interested in establishing which of us is 'correct', so don't drop out here. Note: I said 'establish', not 'prove I am right'. I hate that!
I'm not a drop out, but I did drop (by way of a baseball bat) some jerk out of my helicopter at an altitude he was not prepared to drop from. Jerry, read me well: I did not imply that you were a drop out; I meant don't drop out of the conversation - I am interested in your opinion. Anyway, does the 'helicopter' incident mean that you have been a skydiver? I did some jumping in my youth.
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
But now I must hit the sack as it is 02.27 (yes, a.m.) in Sydney. Regards, Colin
Jerry, read me well: I did not imply that you were a drop out; I meant don't drop out of the conversation - I am interested in your opinion. Anyway, does the 'helicopter' incident mean that you have been a skydiver? I did some jumping in my youth. No pilot would knowingly jump out of a perfectly good aircraft. No, I was a military helicopter pilot. The individual in question refused to
On Mon, 18 Apr 2005 02:28:50 +1000
Colin Carter
On Monday 18 April 2005 07:43, Jerry Feldman wrote:
On Mon, 18 Apr 2005 02:28:50 +1000
Colin Carter
wrote: Jerry, read me well: I did not imply that you were a drop out; I meant don't drop out of the conversation - I am interested in your opinion. Anyway, does the 'helicopter' incident mean that you have been a skydiver? I did some jumping in my youth.
No pilot would knowingly jump out of a perfectly good aircraft. No, I was a military helicopter pilot. The individual in question refused to put his fee inside the aircraft (after I had received orders from my commander). On the subsequent combat assault the crew chief used his baseball bat to push the Lt. out a bit early. You did mean "feet" ? Or was it fee? Do you still fly? My PPL is in need of a "refresh" - I just need to throw money...
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 Colin
No pilot would knowingly jump out of a perfectly good aircraft. No, I was a military helicopter pilot. The individual in question refused to put his fee inside the aircraft (after I had received orders from my commander). On the subsequent combat assault the crew chief used his baseball bat to push the Lt. out a bit early.
You did mean "feet" ? Or was it fee? Do you still fly? My PPL is in need of a "refresh" - I just need to throw money... It was feet (I type fast and sometimes leave out a letter). You've probably seen pictures of Hueys carrying 6 troops with 3 on each side with their feet hanging out. It seems that in another unit a soldier fell out at altitude, so that the group commander put out an order that troops must keep their feet inside the aircraft at altitude. On this particular day,
On Monday 18 April 2005 5:15 am, Colin Carter wrote:
the group commander was in our area and our company commander was chewing
us all out.
--
Jerry Feldman
On Monday 18 April 2005 22:01, Jerry Feldman wrote:
On Monday 18 April 2005 5:15 am, Colin Carter wrote:
No pilot would knowingly jump out of a perfectly good aircraft. No, I was a military helicopter pilot. The individual in question refused to put his fee inside the aircraft (after I had received orders from my commander). On the subsequent combat assault the crew chief used his baseball bat to push the Lt. out a bit early.
You did mean "feet" ? Or was it fee? Do you still fly? My PPL is in need of a "refresh" - I just need to throw money...
It was feet (I type fast and sometimes leave out a letter). You've probably seen pictures of Hueys carrying 6 troops with 3 on each side with their feet hanging out. It seems that in another unit a soldier fell out at altitude, so that the group commander put out an order that troops must keep their feet inside the aircraft at altitude. On this particular day, the group commander was in our area and our company commander was chewing us all out.
It must have been great fun to fly Hueys, but the object behind flying such machines must have dampened your spirit at times. I write software which reads flight data recorders so I know a little about a/c, but not so much about helicopters. Too difficult to predict! Cheers, Colin
-- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Tuesday 19 April 2005 9:38 am, Colin Carter wrote:
It must have been great fun to fly Hueys, but the object behind flying such machines must have dampened your spirit at times. I write software which reads flight data recorders so I know a little about a/c, but not so much about helicopters. Too difficult to predict! It was great fun. Didn't like getting shot at, but that came with the job.
When Leonardo DaVincie invented the helicopter, he then decided there was no
way it can fly. Take gyroscopic precession.
If you exert a downward force on the front of the rotor disk, the aircraft
will tilt toward the left (90 degrees in the plane of rotation). So, all
the controls are set up to exert their force 90 degrees ahead of the plane
of rotation.
In a fixed wing aircraft, if you go too slow the airfoil will stall causing
you to lose lift. In a helicopter, if you go too fast, the rearward rotor
blade will stall, and you will crash and burn.
--
Jerry Feldman
Jerry Feldman wrote:
On Tuesday 19 April 2005 9:38 am, Colin Carter wrote:
It must have been great fun to fly Hueys, but the object behind flying such machines must have dampened your spirit at times. I write software which reads flight data recorders so I know a little about a/c, but not so much about helicopters. Too difficult to predict!
It was great fun. Didn't like getting shot at, but that came with the job.
When Leonardo DaVincie invented the helicopter, he then decided there was no way it can fly. Take gyroscopic precession. If you exert a downward force on the front of the rotor disk, the aircraft will tilt toward the left (90 degrees in the plane of rotation). So, all the controls are set up to exert their force 90 degrees ahead of the plane of rotation. In a fixed wing aircraft, if you go too slow the airfoil will stall causing you to lose lift. In a helicopter, if you go too fast, the rearward rotor blade will stall, and you will crash and burn.
No auto-gyroing (if & after you slow back down) ? -- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!!
On Tuesday 19 April 2005 3:29 pm, William A. Mahaffey III wrote:
No auto-gyroing (if & after you slow back down) ? This is called "retreating blade stall". If you recognize it quickly enough you can recover, but what happens is that you have a very quick nose up then go inverted where you can enjoy the rest of the ride down. -- Jerry Feldman
Partner Technology Access Center (contractor) (PTAC-MA) Hewlett-Packard Co. 550 King Street LKG2a-X2 Littleton, Ma. 01460 (978)506-5243
Jerry Feldman wrote:
On Tuesday 19 April 2005 3:29 pm, William A. Mahaffey III wrote:
No auto-gyroing (if & after you slow back down) ?
This is called "retreating blade stall". If you recognize it quickly enough you can recover, but what happens is that you have a very quick nose up then go inverted where you can enjoy the rest of the ride down.
Hmmm ... not a pilot myself (obviously). OUCH !!!! -- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!!
On Tuesday 19 April 2005 11:38 pm, William A. Mahaffey III wrote:
Hmmm ... not a pilot myself (obviously). OUCH !!!! Any relation to an Army sergeant Mahaffey? -- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 20 April 2005 05:40, Jerry Feldman wrote:
On Tuesday 19 April 2005 3:29 pm, William A. Mahaffey III wrote:
No auto-gyroing (if & after you slow back down) ?
This is called "retreating blade stall". If you recognize it quickly enough you can recover, but what happens is that you have a very quick nose up then go inverted where you can enjoy the rest of the ride down.
What would happen if you slowed the forward rotor? Would the imbalanced torque cause the "rear to 'catch up' with the front", thereby get the rear rotor out of the forward's slip-stream? Colin
Jerry Feldman
Partner Technology Access Center (contractor) (PTAC-MA) Hewlett-Packard Co. 550 King Street LKG2a-X2 Littleton, Ma. 01460 (978)506-5243
On Wednesday 20 April 2005 5:46 am, Colin Carter wrote:
What would happen if you slowed the forward rotor? Would the imbalanced torque cause the "rear to 'catch up' with the front", thereby get the rear rotor out of the forward's slip-stream? The rotor system is controlled by a one-way clutch. If the engine stops the blades are freewheeling.
If your rotor RPM gets too slow, your blades will cone up and you then
become a rock.
--
Jerry Feldman
On Wednesday 20 April 2005 22:33, Jerry Feldman wrote:
On Wednesday 20 April 2005 5:46 am, Colin Carter wrote:
What would happen if you slowed the forward rotor? Would the imbalanced torque cause the "rear to 'catch up' with the front", thereby get the rear rotor out of the forward's slip-stream?
The rotor system is controlled by a one-way clutch. If the engine stops the blades are freewheeling.
If your rotor RPM gets too slow, your blades will cone up and you then become a rock. This sounds as though some of the strength in the blades is due to centrifugal force keeping the movement of the blades in the one plane.
-- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 20 April 2005 9:40 am, Colin Carter wrote:
This sounds as though some of the strength in the blades is due to centrifugal force keeping the movement of the blades in the one plane. This is correct for most helicopters. One of the first things we learned in flight school was to keep the rotor RPM in the green.
Most larger helicopters today are fully governed so that the pilot does not
have to coordinate rotor RPM, but the smaller helicopters don't incorporate
that.
--
Jerry Feldman
On Wednesday 20 April 2005 05:29, William A. Mahaffey III wrote:
Jerry Feldman wrote:
On Tuesday 19 April 2005 9:38 am, Colin Carter wrote:
It must have been great fun to fly Hueys, but the object behind flying such machines must have dampened your spirit at times. I write software which reads flight data recorders so I know a little about a/c, but not so much about helicopters. Too difficult to predict!
It was great fun. Didn't like getting shot at, but that came with the job.
When Leonardo DaVincie invented the helicopter, he then decided there was no way it can fly. Take gyroscopic precession. If you exert a downward force on the front of the rotor disk, the aircraft will tilt toward the left (90 degrees in the plane of rotation). So, all the controls are set up to exert their force 90 degrees ahead of the plane of rotation. In a fixed wing aircraft, if you go too slow the airfoil will stall causing you to lose lift. In a helicopter, if you go too fast, the rearward rotor blade will stall, and you will crash and burn.
No auto-gyroing (if & after you slow back down) ? I don't think you have the ability to slow down. Right Jerry? Colin
On Wednesday 20 April 2005 5:43 am, Colin Carter wrote:
I don't think you have the ability to slow down. Right Jerry? Not while inverted. If you recognize the beginning of the retreating blade stall, you can reduce pitch and slow down, but you only have a very short time. -- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 20 April 2005 05:18, Jerry Feldman wrote:
On Tuesday 19 April 2005 9:38 am, Colin Carter wrote:
It must have been great fun to fly Hueys, but the object behind flying such machines must have dampened your spirit at times. I write software which reads flight data recorders so I know a little about a/c, but not so much about helicopters. Too difficult to predict!
It was great fun. Didn't like getting shot at, but that came with the job.
When Leonardo DaVincie invented the helicopter, he then decided there was no way it can fly. Take gyroscopic precession. If you exert a downward force on the front of the rotor disk, the aircraft will tilt toward the left (90 degrees in the plane of rotation). So, all the controls are set up to exert their force 90 degrees ahead of the plane of rotation.
This is interesting. I know about gyroscopes, but hadn't thought about it in the sense of controlling helicopters. To move forward I imagine that the rotor plane would have to lower itself at the front (true?), in which case the force (as you mentioned at 9o deg) would have to cause a little roll of the fuselage, albeit very slight. Is this true?
In a fixed wing aircraft, if you go too slow the airfoil will stall causing you to lose lift. In a helicopter, if you go too fast, the rearward rotor blade will stall, and you will crash and burn.
I hadn't thought about that; I guess it would be much like one racing yacht "stealing" the breeze from another. I don't think I'd be very good in a helicopter: I get sea sick; not at all if the vessel is ploughing through very rough water at speed - rather when the boat has a very gentle sway/roll in almost calm waters.
Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Regards, Colin
On Wednesday 20 April 2005 5:42 am, Colin Carter wrote: > This is interesting. I know about gyroscopes, but hadn't thought about > it in the sense of controlling helicopters. To move forward I imagine > that the rotor plane would have to lower itself at the front (true?), in > which case the force (as you mentioned at 9o deg) would have to cause a > little roll of the fuselage, albeit very slight. Is this true? Not really. The rotor blades are hinged at the rotor mast. A downward force is exerted aerodynamically to the rotor blades 90 degrees in advance of the rotor plane. This causes the rotor blades to tilt forward. Try this with toy gyroscope. > I hadn't thought about that; I guess it would be much like one racing > yacht "stealing" the breeze from another. > > I don't think I'd be very good in a helicopter: I get sea sick; not at > all if the vessel is ploughing through very rough water at speed - rather > when the boat has a very gentle sway/roll in almost calm waters. There are 5 controls in a helicopter that a pilot must operate simultaneously: 1. The cyclic - This is the stick and controls the tilt of the rotor blades and the helicopter. Similar to the stick in a fixed wing, and in forward flight nearly identical. 2. The collective. This makes the helicopter go up or down. 3. The throttle (on the collective). When you pull pitch, you need to simultaneously give it more throttle. 4, 5. The anti-torque rotor pedals. Anytime a change is made with the throttle, you need to compensate for the additional or reduced torque caused by the throttle changes. Additionally, the pedals themself require more or less throttle. Much like a feedback loop. There are generally 3 kinds of rotor systems: 1. Rigid - not used very much. This was a goal that was finally achieved by Lockheed in the 1970s. 2. semi-rigid - Mainly Bell Helicopters - 2 blades that teeter on the rotor mast. Each blade can feather - increase of decrease its angle of attack independently of the other). 3. Fully articulated. Most helicopters use this. Each blade is hinged to the rotor mast where it can feather, float up or down, and even move forward or backward independently of the others. (The angle between the blades can vary). One interesting anomaly is that if the system is not tuned correctly, the rotor system can cause vibration when in contact wit the ground and self destruct. In any case, the mission of all helicopters is self destruction. -- Jerry FeldmanBoston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 20 April 2005 22:30, Jerry Feldman wrote:
On Wednesday 20 April 2005 5:42 am, Colin Carter wrote:
This is interesting. I know about gyroscopes, but hadn't thought about it in the sense of controlling helicopters. To move forward I imagine that the rotor plane would have to lower itself at the front (true?), in which case the force (as you mentioned at 9o deg) would have to cause a little roll of the fuselage, albeit very slight. Is this true?
Not really. The rotor blades are hinged at the rotor mast. A downward force is exerted aerodynamically to the rotor blades 90 degrees in advance of the rotor plane. This causes the rotor blades to tilt forward. Try this with toy gyroscope.
I hadn't thought about that; I guess it would be much like one racing yacht "stealing" the breeze from another.
I don't think I'd be very good in a helicopter: I get sea sick; not at all if the vessel is ploughing through very rough water at speed - rather when the boat has a very gentle sway/roll in almost calm waters.
There are 5 controls in a helicopter that a pilot must operate simultaneously: 1. The cyclic - This is the stick and controls the tilt of the rotor blades and the helicopter. Similar to the stick in a fixed wing, and in forward flight nearly identical.
2. The collective. This makes the helicopter go up or down.
3. The throttle (on the collective). When you pull pitch, you need to simultaneously give it more throttle.
4, 5. The anti-torque rotor pedals. Anytime a change is made with the throttle, you need to compensate for the additional or reduced torque caused by the throttle changes. Additionally, the pedals themself require more or less throttle. Much like a feedback loop.
There are generally 3 kinds of rotor systems: 1. Rigid - not used very much. This was a goal that was finally achieved by Lockheed in the 1970s.
2. semi-rigid - Mainly Bell Helicopters - 2 blades that teeter on the rotor mast. Each blade can feather - increase of decrease its angle of attack independently of the other).
3. Fully articulated. Most helicopters use this. Each blade is hinged to the rotor mast where it can feather, float up or down, and even move forward or backward independently of the others. (The angle between the blades can vary). One interesting anomaly is that if the system is not tuned correctly, the rotor system can cause vibration when in contact wit the ground and self destruct.
Very interesting (and new). The blade independence surprises me.
In any case, the mission of all helicopters is self destruction. This reminds me of Ozymandias. And also of the most important law of physics/universe: "There is a tendency toward maximum entropy."
-- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Colin, Jerry, On Sunday 17 April 2005 07:41, Colin Carter wrote:
On Sunday 17 April 2005 23:41, Jerry Feldman wrote:
...
What you are talking about is Alan Turing's Enigma machine. But, what I was referring to is the coining of the word, "bug". I was fortunate to have had lunch with Grace Hopper once back around 1980.
I agree that that would have been a great honour. I envy you.
http://www.history.navy.mil/photos/pers-us/uspers-h/g-hoppr.htm
Interesting site. But I don't believe what I read, especially when it comes to computer stuff ;-)
...
I don't mean to be offensive Jerry, but It is interesting that Americans discovered the first bug after the English had destroyed their programmable computer.
I think this passage in Captain Hopper's log is widely misinterpreted. The use of "bug" as a technological failure of some sort predates this event by a good long time. Furthermre, it seems pretty clear (or at least plausible) to me that by "first actual bug" the meaning was meant to be somewhat humorous: For the first time, the bug was an "actual [...] bug". It was probably also not meant as a historically authoritative comment, but rather something contextual only to her personal knowledge of the history of technology. I thought Captain Hopper herself once disavowed the assertion made by some that she coined the term "bug" when used in this sense. There's abundant etymological evidence that this sense of "bug" long predates the advent of the electronic digital computer. For example, Thomas A. Edison used it in 1889 to describe a problem he had during the development of the phonograph. Here's a good article from a reputable source (Random House): http://www.randomhouse.com/wotd/index.pperl?date=20010525.
...
Regards, Colin
Randall Schulz
Jerry Feldman wrote:
Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II.
What you are talking about is Alan Turing's Enigma machine. But, what I was referring to is the coining of the word, "bug". I was fortunate to have had lunch with Grace Hopper once back around 1980.
Unusually, you are wrong here. The machine was called Colossus and was built by an obscure Post Office engineer called Tommy Flowers. Enigma was the name of one of the toughest German encryption machines but was not a computer. Turing worked at Bletchley Park during the war and played a large part in working out how to break enigma codes, but the British had obtained an enigma machine at the start of the war. I'm far to young to have met Turing and never met flowers though I was fortunate to have had lunch with one of the people who worked out how the German high command machine worked once back in 1999. http://www.picotech.com/applications/colossus.html I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation and object-oriented languages are very good for this purpose - I first looked at object oriented languages when I found that FORTRAN was almost useless for discrete event simulation in the late 1980s: no function pointers means you have to use hard-coded tables to find which function actually needs to be called at runtime even though you end up writing dozens of functions with identical parameter lists. One thing that irritates me is people insisting on using object oriented programming even when it's clearly not appropriate. Some things are best just done procedurally or recursively. Many algorithms work much better and faster when the polymorphism is resolved at compile time rather than run time - so use templates. My view is: use the method that is appropriate for the task and the language that is appropriate for the method. -- JDL
John, On Sunday 17 April 2005 12:31, John Lamb wrote:
...
I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation and object-oriented languages are very good for this purpose - I first looked at object oriented languages when I found that FORTRAN was almost useless for discrete event simulation in the late 1980s: no function pointers means you have to use hard-coded tables to find which function actually needs to be called at runtime even though you end up writing dozens of functions with identical parameter lists.
Simula is acknowledged by Stroustrup as a key conceptual source in his invention of C++. However, Object-Oriented programming is generally thought to have been originated with Smalltalk, a Xerox PARC invention, and not sharing a lineal link with Simula.
One thing that irritates me is people insisting on using object oriented programming even when it's clearly not appropriate. Some things are best just done procedurally or recursively. Many algorithms work much better and faster when the polymorphism is resolved at compile time rather than run time - so use templates. My view is: use the method that is appropriate for the task and the language that is appropriate for the method.
And there are alternatives beyond O-O and procedural. There's functional programming, Aspect-Oriented programming, logic programming, constraint programming and probably lots of techniques about which I know nothing. C++ programmers have it better than most in that they have more ability to mix and match techniques and to take or leave the O-O capabilities of the language. James O. Coplien has a book called "Multi-Paradigm Design for C++" (http://www.amazon.com/exec/obidos/ASIN/0201824671/) and it addresses your very point: that one should choose a design and coding technique that is deliberately chosen to be a good match for the requirements of the problem(s) you must solve and the requirements you must fulfill.
-- JDL
Randall Schulz
On Sun, 17 Apr 2005 20:31:41 +0100
John Lamb
Unusually, you are wrong here. I stand corrected. I didn't research that, but I certainly am aware of much of the work that was done by Turing and others. -- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Monday 18 April 2005 05:31, John Lamb wrote:
Jerry Feldman wrote:
Long before the Americans got computers underway the English military built a programmable computer with valves and relays. It was used to break the German codes during WW II.
What you are talking about is Alan Turing's Enigma machine. But, what I was referring to is the coining of the word, "bug". I was fortunate to have had lunch with Grace Hopper once back around 1980.
Unusually, you are wrong here. The machine was called Colossus and was built by an obscure Post Office engineer called Tommy Flowers. Enigma was the name of one of the toughest German encryption machines but was not a computer. Turing worked at Bletchley Park during the war and played a large part in working out how to break enigma codes, but the British had obtained an enigma machine at the start of the war. I'm far to young to have met Turing and never met flowers though I was fortunate to have had lunch with one of the people who worked out how the German high command machine worked once back in 1999.
http://www.picotech.com/applications/colossus.html This is a good site John, I saw a good programme on the BBC about this. It disclosed a few secretes - I wish I had taped it. I couldn't see anything on this site about the 'bug', but I think that the BBC programme mentioned it. Any ideas?
I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation
GSS is not too bad for a quick solution.
and object-oriented languages are very good for this purpose - I first looked at object oriented languages when I found that FORTRAN was almost useless for discrete event simulation in the late 1980s: no function pointers means you have to use hard-coded tables to find which function actually needs to be called at runtime even though you end up writing dozens of functions with identical parameter lists.
One thing that irritates me is people insisting on using object oriented programming even when it's clearly not appropriate. Some things are best just done procedurally or recursively. Many algorithms work much better and faster when the polymorphism is resolved at compile time rather than run time - so use templates. My view is: use the method that is appropriate for the task and the language that is appropriate for the method.
-- JDL
Colin
Colin Carter wrote:
This is a good site John, I saw a good programme on the BBC about this. It disclosed a few secretes - I wish I had taped it. I couldn't see anything on this site about the 'bug', but I think that the BBC programme mentioned it. Any ideas?
I'm sure I saw the same programme but I don't recall the 'bug'. I guess a Google search might throw up something. There are also several books, which are bound to go into more detail. IIRC the programme was called Station X and is the sort of thing that gets repeated regularly on various history channels.
I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation
GSS is not too bad for a quick solution.
I don't recall what GSS is. For fast discrete-event simulation I now usually use C++, though Java is also good. The only thing you need that isn't pure O-O is a priority queue. FORTRAN and similar languages are very poor because a priority queue has to be an arrray of fixed size and there aren't objects or pointers to functions to put in the queue; so you end up with an array of integers and code that looks at an integer and decided which function to call. OTOH FORTRAN is undeniably well suited to efficient matrix operations and the like. -- JDL
On Tuesday 19 April 2005 17:10, John Lamb wrote:
Colin Carter wrote:
This is a good site John, I saw a good programme on the BBC about this. It disclosed a few secretes - I wish I had taped it. I couldn't see anything on this site about the 'bug', but I think that the BBC programme mentioned it. Any ideas?
I'm sure I saw the same programme but I don't recall the 'bug'. I guess a Google search might throw up something. There are also several books, which are bound to go into more detail. IIRC the programme was called Station X and is the sort of thing that gets repeated regularly on various history channels.
I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation
GSS is not too bad for a quick solution.
I don't recall what GSS is. For fast discrete-event simulation I now usually use C++, though Java is also good. The only thing you need that isn't pure O-O is a priority queue. FORTRAN and similar languages are very poor because a priority queue has to be an arrray of fixed size and there aren't objects or pointers to functions to put in the queue; so you end up with an array of integers and code that looks at an integer and decided which function to call. OTOH FORTRAN is undeniably well suited to efficient matrix operations and the like.
-- JDL
GSS: General Simulation System or some such name. It is a while since I used it, but I lectured its use in time series simulation of processes. For example, a factory might be making X-Widgets. You add units (black box) which supply the basic units/raw materials required by our factory. One specifies the average number of units available per unit of time, and the distribution (eg Poisson) Add any number of supply units, add process units and queues and product shipment routes. And say GO. Each of the units takes inputs, crunches, with delays, and distributes outputs which are channelled to other units / queues until output occurs. Bottle-necks will show up as growing queues, and inadequate supplies will also show up, delays will show up- all in the output of summaries and statistics. Great fun. A kind of plug and play lego set. Regards, Colin
John, On Tuesday 19 April 2005 00:10, John Lamb wrote:
Colin Carter wrote:
This is a good site John, I saw a good programme on the BBC about this. It disclosed a few secretes - I wish I had taped it. I couldn't see anything on this site about the 'bug', but I think that the BBC programme mentioned it. Any ideas?
I'm sure I saw the same programme but I don't recall the 'bug'. I guess a Google search might throw up something. There are also several books, which are bound to go into more detail. IIRC the programme was called Station X and is the sort of thing that gets repeated regularly on various history channels.
I believe object-oriented programming developed from an algol based language called Simula in the 1960s. Simula was designed for discrete event dimulation
GSS is not too bad for a quick solution.
I don't recall what GSS is. For fast discrete-event simulation I now usually use C++, though Java is also good. The only thing you need that isn't pure O-O is a priority queue.
I really wish people would stop using the phrase "pure Object-Oriented." The word "pure" should only be used in the context of chemistry, if you ask me. Applying it to programming or, god forbid, ethnicity just invites trouble, or, at best, confusion. Anyway, the Concurrent Programming in Java class library (now incorporated into Java 1.5 / Tiger) has a perfectly serviceable heap-based priority queue ("heap" as in the data structure, not the dynamic storage allocation mechanism). I use it extensively in my theorem prover and apart from exhibiting non-stable ordering, it works great and performs well. I created a modified version that is not synchronized so I could avoid the overhead produced by synchronization (though Sun claims that late-model JVMs have near-zero synchronization overhead). I sometimes move hundreds of thousands of items through these queues in a single proof and they do not become a hot-spot in that application.
...
-- JDL
Randall Schulz
participants (7)
-
Colin Carter
-
Jerry Feldman
-
Jerry Feldman
-
John Lamb
-
Randall R Schulz
-
synthetoonz@bellsouth.net
-
William A. Mahaffey III