ha ha. dump ass. DUMP ass. haha. What a moron. Can't even spell dumbass. Doesn't know it's one word. Hahah. And look, his UID is more than 5 times my UID. Heh.
But don't forget the climate at the time. Fuel costs were very very high, and many people were looking to provide fast transport without using turbojets.
If you recall the concepts of the time, you will remember planes that looked like DC-9's, except they had large propellors with about 50 curved blades rather than the usual 2,3, or 4 blades. This was what Beech wanted to build.
Basically everyone else held off on actually building that sort of plane, and in a few years we had something functionally equivalent: high-bypass turbofan engines.
So, don't blame it on Burt - he built a plane that embodied everyone's best ideas at the time about how to build a fast non-jet transport. The fact that it wasn't successful is at least partly because technology eclipsed it much faster than expected.
I've been running Linux since June 1993. The first box I put it on was a 386/SX at 20 mhz, with 4 megs of RAM. It ran decently, and I used it like that for a long time as a development box.
Before that, my dorm had an AT&T 3B2 in the basement. That machine was slower than the 386SX, and it supported 16 users. Ironically, the terminals were smart graphics terms, with 68000 CPUs inside. The main box ran an AMD 32K processor. I think the hard disk was 32 megs or something like that. UNIX workstations definitely weren't just dumb terminals. All the processing happened on that little 3B2. All 16 users, plus whoever logged in from their rooms over a modem.
That PALM should be able to run UNIX, and support 16 users. It's got many more horses.
Would be better to say they had some poop in them.
Re:Beware of Microsoft Money/Taxcut rebates
on
Are Rebates Scandalous?
·
· Score: 2, Insightful
Write another letter back and CC it to the FTC and your Senator, explaining that barcode means barcode, and if they don't send the rebate, more politicians might be hearing about corporate rebate scams than just your Senator.
Enron was a tasty snack, and chewing up some companies to win some popular votes appeals to a great many politicians.
I don't really understand why someone would do this, other than to harass the target. Sure, they get a free phone call, but it's not a phone call to talk to somebody. They are calling and just leaving the line open. Why would anyone bother?
Spend the $65 a month that the 5 static IP service costs. It's a good deal compared with other static IP options. No PPOE stuff to worry about, plus you can run your own servers.
Right. There's two kinds of money - enough, and not enough. When I was in college I had no money. Just like a lot of people. I determined back then that when I reached the point where I could decide to go to the theater and see a movie, on a whim, any time I liked, without worrying about paying the phone bill, that would meet my definition of "enough" money. Everything past that would be gravy.
What I discovered was that it takes a surprisingly small amount of money to meet that definition. I'm not saying that you should set your goals as I did way back when I was a poor college student, but you should set some kind of goals first. What do you want to make the money for?
If your goal is to make a billion dollars in order to become a patron of the arts, that's a completely different strategy than to save two million dollars by the time you are 65, so you can go on a permanent RV camping trip driving between your children's homes.
Pick your goal first, figure out how much money is "enough", and center your life on the improvement of the person and not the acquisition of stuff in the meantime.
I read that the bird killing thing is mainly fixed by the newest turbines. The blades are large and don't turn fast. They use their huge size to slowly turn a lot of generators to generate a lot of power, rather than turning a few generators very quickly as the smaller windmills do.
The rising demand issue is met just like they always have. Bring more generators online. If you need more because of heat wave, fire up the standby gas plants. If you need more because of a long-term rise in consumption, you build more windmills.
Wind power is shaping up to be the best alternative. There was a recent article - maybe it was on/. but I don't remember - about the new turbines, and how more megawatts of wind generating capacity has been installed recently than all the installations in the last 50 years.
Even the price is approaching parity with oil and gas fired generated, and will probably drop below. When that happens, it'll really explode. So, at least until someone posts a followup explaining why I'm full of crap, it looks like wind power might quickly become dominant in the US. We've got the vast open spaces, new windmills are more efficient, quieter, and safer for wildlife, we've got the wind, so it's one of those lucky convergences of technology, politics, and demand.
sheep-like herding is rather cumbersome to say. I propose what we come up with a nifty term that means sheep-like herding so we can talk about it and sound smart.
Decouple an abstraction from its implementation so that the two can vary independently.
OK, my situation is that I've got this COBOL program that reads a bunch of boring business crap. It has to write it's data into an Oracle database OR it has to send the data to a mainframe computer using MQ-Series.
So, I write the program to process it's data, and write it into a temporary ISAM database. Then, depending on where the data actually needs to go, 1 of two programs will run. The first one reads the ISAM database, converts it to a flat file format and submits it to MQ-Series for mainframe processing. The second program reads the ISAM database, converts it to a relational format, then uses Oracle PRO-COBOL routines to store it in the Oracle database.
As you can see, Bridge does not depend on polymorphism. The pattern only talks about decoupling the abstraction from the implementation, which can be done without polymorphism support. In this case, the abstraction of the consumer of the data turns out to be a COBOL ISAM database. The producer of the data does not know nor care where the data is going after that.
I'm not a COBOL programmer, but I know how they think. I'll give it a shot:
Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
OK. I've got a COBOL program that reads a data file, and performs some operation on the data.
I can write the program like this:
1) read the data file 2) the first line of the file is the name of a program to execute 3) the rest of the data file is consumed by the program named on the first line. 4) invoke the program that implements the strategy, passing data to and from the program in temporary files 5) voila. strategy is implemented. This pattern fulfils all of the initial requirements posed in the problem section of the pattern.
I should have asked how much money you would have paid before I gave my answer.:-)
I have a book of recipes. It's called "100 Chinese eggroll recipes".
If you claim that you have a recipe book of hamburgers, then you would be *technically* correct that it is a recipe book, but that doesn't change the fact that the clearest and best manifestation of recipes is done with Chinese eggrolls.
All the patterns you refer to rest on OO principles. I could rewrite every single one of those patterns in such a way that it would be useful to COBOL programmers.
The example that is brought up with all the shapes turns out to have a fault. Inheritence might not be a good way to model those relationships.
So, all this article has done is show that the P-OOP thing is better than a octopus inheritance tree. Of course it is. Inheritence tends to get used way too much anyway.
Consider the famous example that we have all seen: an employee class is derived from a person class. That example appears in countless books, and probably countless systems in actual production today. But is it correct? The challenge of designing a system is to make it flexible enough to stand in the future.
Suppose we have a person who is an employee and a student at the same time. Should we use multiple inheritence? That would be screwy, and also not natural to implement in a language like Java. It turns out that breaking the problem apart into an inheritence type arrangement isn't the best or most flexible way to approach the problem.
In short, the article has made a good case why inheritence is sometimes not the right tool to use. But remember that OOP is three things: 1) inheritence 2) encapsulation and 3) polymorphism. And a language like C++ (and Java soon) has the notion of *generic programming* which the article didn't talk about.
Slashdot Mirror
You're wrong, and dump ass yourself.
ha ha. dump ass. DUMP ass. haha. What a moron. Can't even spell dumbass. Doesn't know it's one word. Hahah. And look, his UID is more than 5 times my UID. Heh.
Why not a guide to hardware mods instead?
So, what kind of GPS was that maintenance company using when they got lost and captured by the Iraqis?
I wonder if it was an old unit that broke down. They should have a rule that says three GPS per unit at least. And a good map as backup.
But don't forget the climate at the time. Fuel costs were very very high, and many people were looking to provide fast transport without using turbojets.
If you recall the concepts of the time, you will remember planes that looked like DC-9's, except they had large propellors with about 50 curved blades rather than the usual 2,3, or 4 blades. This was what Beech wanted to build.
Basically everyone else held off on actually building that sort of plane, and in a few years we had something functionally equivalent: high-bypass turbofan engines.
So, don't blame it on Burt - he built a plane that embodied everyone's best ideas at the time about how to build a fast non-jet transport. The fact that it wasn't successful is at least partly because technology eclipsed it much faster than expected.
Oops. It was an AMD 29K processor. Information on the 29030 Information on the 29000 processor
I've been running Linux since June 1993. The first box I put it on was a 386/SX at 20 mhz, with 4 megs of RAM. It ran decently, and I used it like that for a long time as a development box.
Before that, my dorm had an AT&T 3B2 in the basement. That machine was slower than the 386SX, and it supported 16 users. Ironically, the terminals were smart graphics terms, with 68000 CPUs inside. The main box ran an AMD 32K processor. I think the hard disk was 32 megs or something like that. UNIX workstations definitely weren't just dumb terminals. All the processing happened on that little 3B2. All 16 users, plus whoever logged in from their rooms over a modem.
That PALM should be able to run UNIX, and support 16 users. It's got many more horses.
Would be better to say they had some poop in them.
Write another letter back and CC it to the FTC and your Senator, explaining that barcode means barcode, and if they don't send the rebate, more politicians might be hearing about corporate rebate scams than just your Senator.
Enron was a tasty snack, and chewing up some companies to win some popular votes appeals to a great many politicians.
I don't really understand why someone would do this, other than to harass the target. Sure, they get a free phone call, but it's not a phone call to talk to somebody. They are calling and just leaving the line open. Why would anyone bother?
I have a computer and a monitor. Any ideas?
Spend the $65 a month that the 5 static IP service costs. It's a good deal compared with other static IP options. No PPOE stuff to worry about, plus you can run your own servers.
Right. There's two kinds of money - enough, and not enough. When I was in college I had no money. Just like a lot of people. I determined back then that when I reached the point where I could decide to go to the theater and see a movie, on a whim, any time I liked, without worrying about paying the phone bill, that would meet my definition of "enough" money. Everything past that would be gravy.
What I discovered was that it takes a surprisingly small amount of money to meet that definition. I'm not saying that you should set your goals as I did way back when I was a poor college student, but you should set some kind of goals first. What do you want to make the money for?
If your goal is to make a billion dollars in order to become a patron of the arts, that's a completely different strategy than to save two million dollars by the time you are 65, so you can go on a permanent RV camping trip driving between your children's homes.
Pick your goal first, figure out how much money is "enough", and center your life on the improvement of the person and not the acquisition of stuff in the meantime.
Nuclear power isn't that cheap because the plants are expensive to build and run. Wind power has fewer issues.
I read that the bird killing thing is mainly fixed by the newest turbines. The blades are large and don't turn fast. They use their huge size to slowly turn a lot of generators to generate a lot of power, rather than turning a few generators very quickly as the smaller windmills do.
The rising demand issue is met just like they always have. Bring more generators online. If you need more because of heat wave, fire up the standby gas plants. If you need more because of a long-term rise in consumption, you build more windmills.
Wind power is shaping up to be the best alternative. There was a recent article - maybe it was on /. but I don't remember - about the new turbines, and how more megawatts of wind generating capacity has been installed recently than all the installations in the last 50 years.
Even the price is approaching parity with oil and gas fired generated, and will probably drop below. When that happens, it'll really explode. So, at least until someone posts a followup explaining why I'm full of crap, it looks like wind power might quickly become dominant in the US. We've got the vast open spaces, new windmills are more efficient, quieter, and safer for wildlife, we've got the wind, so it's one of those lucky convergences of technology, politics, and demand.
aka. Inspector Javert
They'll try to hire Muhammed Saeed al-Sahhaf. Density barriers smashed on the gates of Baghdad and all that.
I know that LISP introduced it, but we're looking for things that might take off after OOP. Generic progamming might be one of those things.
It's not like a supernova makes a very practical weapon...
sheep-like herding is rather cumbersome to say. I propose what we come up with a nifty term that means sheep-like herding so we can talk about it and sound smart.
Second challenge: Bridge
Decouple an abstraction from its implementation so that the two can vary independently.
OK, my situation is that I've got this COBOL program that reads a bunch of boring business crap. It has to write it's data into an Oracle database OR it has to send the data to a mainframe computer using MQ-Series.
So, I write the program to process it's data, and write it into a temporary ISAM database. Then, depending on where the data actually needs to go, 1 of two programs will run. The first one reads the ISAM database, converts it to a flat file format and submits it to MQ-Series for mainframe processing. The second program reads the ISAM database, converts it to a relational format, then uses Oracle PRO-COBOL routines to store it in the Oracle database.
As you can see, Bridge does not depend on polymorphism. The pattern only talks about decoupling the abstraction from the implementation, which can be done without polymorphism support. In this case, the abstraction of the consumer of the data turns out to be a COBOL ISAM database. The producer of the data does not know nor care where the data is going after that.
I'm not a COBOL programmer, but I know how they think. I'll give it a shot:
:-)
Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
OK. I've got a COBOL program that reads a data file, and performs some operation on the data.
I can write the program like this:
1) read the data file
2) the first line of the file is the name of a program to execute
3) the rest of the data file is consumed by the program named on the first line.
4) invoke the program that implements the strategy, passing data to and from the program in temporary files
5) voila. strategy is implemented. This pattern fulfils all of the initial requirements posed in the problem section of the pattern.
I should have asked how much money you would have paid before I gave my answer.
I have a book of recipes. It's called "100 Chinese eggroll recipes".
If you claim that you have a recipe book of hamburgers, then you would be *technically* correct that it is a recipe book, but that doesn't change the fact that the clearest and best manifestation of recipes is done with Chinese eggrolls.
All the patterns you refer to rest on OO principles. I could rewrite every single one of those patterns in such a way that it would be useful to COBOL programmers.
The example that is brought up with all the shapes turns out to have a fault. Inheritence might not be a good way to model those relationships.
So, all this article has done is show that the P-OOP thing is better than a octopus inheritance tree. Of course it is. Inheritence tends to get used way too much anyway.
Consider the famous example that we have all seen: an employee class is derived from a person class. That example appears in countless books, and probably countless systems in actual production today. But is it correct? The challenge of designing a system is to make it flexible enough to stand in the future.
Suppose we have a person who is an employee and a student at the same time. Should we use multiple inheritence? That would be screwy, and also not natural to implement in a language like Java. It turns out that breaking the problem apart into an inheritence type arrangement isn't the best or most flexible way to approach the problem.
In short, the article has made a good case why inheritence is sometimes not the right tool to use. But remember that OOP is three things: 1) inheritence 2) encapsulation and 3) polymorphism. And a language like C++ (and Java soon) has the notion of *generic programming* which the article didn't talk about.
Patterns don't rest on OO. The meta-pattern is as follows:
1) Describe a sticky situation
2) Describe a way to solve that sticky situation
That's it. OO has nothing to do with patterns.