More customer's dont want PDA's that play MPEG video with accelerated graphics. Why? Because it's a useless feature; it's a toy; a gimick; it doesn't do anything for the end user.
"Oh look, I've got a 1 minute clip of this movie trailer...everyone huddle round now...wait wait, we have to do this one person at a time, can't see the screen from a wide angle...ah shit my batteries are going dead again..."
Palm isn't interested in doing what you just asked for. Why? Because it's done better in a device you can purchase today than it could ever be done in a device that fits in your pocket. It's called a laptop.
The Palm Pilot is a PDA. It isn't meant to do "computery" things. It's something you can turn on, look for a phone number, and tun back off in about 5 seconds.
Being a monopoly isn't a bad thing in and of itself. Being a monopoly and using that position to squash competition is.
For example, if intel had refused to ship processors to anyplace that sold amd processors, then intel would have been abusing it's monopoly position and would have gotten it's pants sued off.
If you're really determined, you can adjust the autocorrection amount through one of the back doors...
It is really a matter of personal preference though. I personally like the FF method. You obviously like the 30 second skip.:)
I guess I like the FF method because if I'm into a show enough to want to skip the commercials, I want the commercials to be done with NOW. The 30 second skip rewind method feels like it takes an eternity. And I always hit the button 3 or 4 times too many, which requires me to hit the rewind button...
You don't have to "time" getting the start of the show... the Tivo has an autocorrection feature -- you hit the play button and it rewinds the show a bit, and BAM, you're at the beginning of the show.
If you REALLY like the 30 second skip feature, you can always enable it through one of the many "easter egg"/backdoor codes that the unit has.
Personally, I prefer to hit the fast forward button, zip through the commercials in 3 seconds, and then hit the play button and be at the beginning of my show instead of hitting a 30 second skip button 10 times, missing the beginning of the show, and having to rewind...
Using USB ports is a great idea. It's a standard, you don't have to pull open the computer to install it, you really arn't limited to just two devices (usb hubs), and nobody will fry their tivo trying to solder in an ISA adapter.:)
I can see one of the first things people rig up to these things being a keyboard...
Even as it is, it's helped out drastically. I've gotten maybe one junk call since the law took effect.
Instead of opting out of spam, I think there should be an opt-in list. Only problem with it is that when the list stays at zero entries for a few months some people will whine "it's not working" and change it around somehow...*sigh*
[quote]
If you don't know what's a global variable, what's an int, what's a pointer, &c. in some function before you start, you don't understand that code well enough to hack at it yet. And yes, I use the word "hack" intentionally -- because if you don't understand the wider context (and if you did, you wouldn't need or use that crutch), hacking is all you can do.
[/quote]
I agree with you here. What I'm saying is that hungarian notation makes it easier to figure out what it's doing! It's an aide; it reduces the amount of time you have to spend investigating the code and it's purpose. It's like a footnote at the bottom of the page. Without it is like reading one of those choose your own adventure books -- goto page 10, goto page 40, goto page 13.
I'm not saying that it's necessary to do code, but to suggest that it's superflous, promotes bad coding practices, or is a waste of time isn't true either. It CAN be superflous, it CAN promote bad coding practices, and it CAN be a waste of time, but it is only those things when it isn't used properly.
You've got time(2) returning a value. Time(2)'s return value is really a macro definition called "TIME" (or something).
When I write my program TIME is really a long int, so I write my code under the assumption that I'm dealing with a long int.
So I write "TIME lBlah = time();"... which is wrong way to name your variable, because lBlah isn't a long int, it's a TIME value. tmBlah or something equally descriptive would be more appropriate. If your code was "long int lBlah = time();" it's still broken, regardless of your variable naming.
Now, if I'm following what you're saying further on, I (using that term loosely) go on to make the mistake of declairing long int lFoo to hold a time value, which was mistake number two, as lFoo shouldn't be declaired long int; it's a TIME value.
You are STILL going to have this problem regardless of what kind of naming convention you use.
Hungarian notation can be trusted if you trust your coworkers to use it properly. I have yet to discover a bug that was caused due to a misunderstanding of a mislabeled variable type. I have seen one instance of a variable name being wrong (a long which was really a string) in 3 years.
A blind search and replace is always a bad idea; however, I don't recommend a blind S&R, just a search and replace (examine what's going on with the line before you make the replacement).
The system is generally considered to be a 64bit system. It's a hard definition to pin down, because everything in the unit isn't the same. The parts that benefit from 64bit operations are 64bit. On top of that, the system doesn't have a CPU, it's a collection of 5 individual processors connected to a 64bit bus.
As the FAQ above mentions, developers who worked on the machine considered it to be a 64bit machine.
You'll also find out more details about the GPU and realize that it isn't really a 32bit processor, nor is it really a 64bit processor. It's more accurate to say that the parts that benefit from 64bit data/operations are, and the parts that don't arn't.
No, it just means that without hungarian notation I have to lookup which variables are members of my class, how I need to deal with them, and what operations need to be done.
Ex:
Is customers a linked list (delete customers)? Or is it an array of customers objects (delete [] customers)?
Am I dealing with a pointer to an integer (*InvoiceNumber)++, a reference to an integer (InvoiceNumber++, with the understanding that the calling function's value will be modified), or just an integer (InvoiceNumber++, with the understanding something else will need to be done to transfer the result to a more permanant location)?
Hungariant notation isn't necessary, it's convenient. Using it means I don't have to remember/lookup the minute details of 50 variables used in a function.
I don't know about anyone else who's used it, but I find that it drastically increases readability. It also drastically reduces the amount of time I have to spend investigating a segment of code to asses what the hell is going on.
m_iInvoiceNumber tells me immediately that I'm dealing with a member of my class that is an integer, which represents the invoice number -- not a long, not a short, not a char *, not a std::string, an integer. I didn't have to check the top of the file to see if some schmuck made it a global variable. I didn't have to check the whole subroutine to see if it was declaired locally. I didn't have to open the header file, search through the text to figure out if invoice number is declaired there, or one of it's base classes. Instead of spending 5 minutes trying to figure out what the hell "InvoiceNumber" was, because I couldn't remember it from the last time I had to look it up an hour ago, I knew everything I needed to know in 1/10th of a second.
And lord help you if you're forced to maintain VB code...
If you're going to say something like that, at least get the facts right.
The jaguar had a 64bit GPU, a 64bit blitter, 32bit DSP, a 16bit 68k, and one or two other pieces that I'm forgetting about. The bus that connected all of these processors together was 64 bits wide.
I've actually found my '01 Eclipse to be easier to work on than my '84 Ranger. Brakes are simpler, struts/shocks are simpler, sparkplugs are way simpler, changing the oil is a snap. The engine is a more complicated design, but it's drastically easier to do work on. It LOOKS harder to work on, but when you get your hands dirty you find out that it's easier.
If something is going wrong, I just need to get an ODB-II logger ($150 w/cable & software) to pull the code out of the computer -- opposed to my truck where I've got to guess why the idle is off. Not only that, but I can actually have it log the performance characteristics of the car while I'm driving for even more diagnostic information.
You lose some flexability you previously had with non-computer controled vehicles, but you also gain more flexability in other areas. It's just a different kind of technology -- you've gotta get used to it. And when you figure it out, you've got more control than you could ever get before.
Unfortunately, the world is not a perfect place, and writing a wrapper for every basic datatype you ever use is NOT practicle. OOP is nice. It's a good way to abstract GRAND concepts. It's not an efficient or practicle way of dealing with low level details. C++ is not a pure OOP language. And good lord, don't get me started about COM or exception handling...
Re: "get a better editor"
Emacs won't help you if you're looking at a printout doing a code review. Type is an important bit of information when trying to know what a variable does.
Should I delete [] or delete? Is ++ a valid operation or is (*)++ what I really want?
Slashdot Mirror
And in 5 years I'll still be asking how the hell the ability to play an mpeg clip helps me organize my schedule.
More customer's dont want PDA's that play MPEG video with accelerated graphics. Why? Because it's a useless feature; it's a toy; a gimick; it doesn't do anything for the end user.
"Oh look, I've got a 1 minute clip of this movie trailer...everyone huddle round now...wait wait, we have to do this one person at a time, can't see the screen from a wide angle...ah shit my batteries are going dead again..."
I mean really, how usefull is that?
Palm isn't interested in doing what you just asked for. Why? Because it's done better in a device you can purchase today than it could ever be done in a device that fits in your pocket. It's called a laptop.
The Palm Pilot is a PDA. It isn't meant to do "computery" things. It's something you can turn on, look for a phone number, and tun back off in about 5 seconds.
Ah, but here's the rub ... at the point intel did this, they were no longer a monopoly. You arn't exactly a monopoly with 80% market share.
Being a monopoly isn't a bad thing in and of itself. Being a monopoly and using that position to squash competition is.
For example, if intel had refused to ship processors to anyplace that sold amd processors, then intel would have been abusing it's monopoly position and would have gotten it's pants sued off.
The only thing that drag car shares with an Integra is that the body vaguely resembles one. It sure as hell isn't "streetable" either.
Um, the fast forward on the Tivo goes through TV at a factor of 30x, not 8x. You can make it go up to 60x, but that's just too fast for my tastes. :)
So it takes about 4x less time than you thought it did...
If you're really determined, you can adjust the autocorrection amount through one of the back doors...
:)
...
It is really a matter of personal preference though. I personally like the FF method. You obviously like the 30 second skip.
I guess I like the FF method because if I'm into a show enough to want to skip the commercials, I want the commercials to be done with NOW. The 30 second skip rewind method feels like it takes an eternity. And I always hit the button 3 or 4 times too many, which requires me to hit the rewind button
You don't have to "time" getting the start of the show ... the Tivo has an autocorrection feature -- you hit the play button and it rewinds the show a bit, and BAM, you're at the beginning of the show.
Actually, it did "go away" for one release of the software ... enough people complaned about it that the next revision had it back in.
If you REALLY like the 30 second skip feature, you can always enable it through one of the many "easter egg"/backdoor codes that the unit has.
Personally, I prefer to hit the fast forward button, zip through the commercials in 3 seconds, and then hit the play button and be at the beginning of my show instead of hitting a 30 second skip button 10 times, missing the beginning of the show, and having to rewind...
Using USB ports is a great idea. It's a standard, you don't have to pull open the computer to install it, you really arn't limited to just two devices (usb hubs), and nobody will fry their tivo trying to solder in an ISA adapter. :)
...
I can see one of the first things people rig up to these things being a keyboard
Even as it is, it's helped out drastically. I've gotten maybe one junk call since the law took effect.
Instead of opting out of spam, I think there should be an opt-in list. Only problem with it is that when the list stays at zero entries for a few months some people will whine "it's not working" and change it around somehow...*sigh*
Missouri has a similar law.
I havn't had a junk phone call since the law went into effect. It's been great. I don't have to screen phone calls anymore.
[quote]
If you don't know what's a global variable, what's an int, what's a pointer, &c. in some function before you start, you don't understand that code well enough to hack at it yet. And yes, I use the word "hack" intentionally -- because if you don't understand the wider context (and if you did, you wouldn't need or use that crutch), hacking is all you can do.
[/quote]
I agree with you here. What I'm saying is that hungarian notation makes it easier to figure out what it's doing! It's an aide; it reduces the amount of time you have to spend investigating the code and it's purpose. It's like a footnote at the bottom of the page. Without it is like reading one of those choose your own adventure books -- goto page 10, goto page 40, goto page 13.
I'm not saying that it's necessary to do code, but to suggest that it's superflous, promotes bad coding practices, or is a waste of time isn't true either. It CAN be superflous, it CAN promote bad coding practices, and it CAN be a waste of time, but it is only those things when it isn't used properly.
I'm still missing the point ...
... which is wrong way to name your variable, because lBlah isn't a long int, it's a TIME value. tmBlah or something equally descriptive would be more appropriate. If your code was "long int lBlah = time();" it's still broken, regardless of your variable naming.
Let me see if I'm following:
You've got time(2) returning a value. Time(2)'s return value is really a macro definition called "TIME" (or something).
When I write my program TIME is really a long int, so I write my code under the assumption that I'm dealing with a long int.
So I write "TIME lBlah = time();"
Now, if I'm following what you're saying further on, I (using that term loosely) go on to make the mistake of declairing long int lFoo to hold a time value, which was mistake number two, as lFoo shouldn't be declaired long int; it's a TIME value.
You are STILL going to have this problem regardless of what kind of naming convention you use.
Hungarian notation can be trusted if you trust your coworkers to use it properly. I have yet to discover a bug that was caused due to a misunderstanding of a mislabeled variable type. I have seen one instance of a variable name being wrong (a long which was really a string) in 3 years.
A blind search and replace is always a bad idea; however, I don't recommend a blind S&R, just a search and replace (examine what's going on with the line before you make the replacement).
http://www.digiserve.com/eescape/showpage.phtml?pa ge=a2
The system is generally considered to be a 64bit system. It's a hard definition to pin down, because everything in the unit isn't the same. The parts that benefit from 64bit operations are 64bit. On top of that, the system doesn't have a CPU, it's a collection of 5 individual processors connected to a 64bit bus.
As the FAQ above mentions, developers who worked on the machine considered it to be a 64bit machine.
You'll also find out more details about the GPU and realize that it isn't really a 32bit processor, nor is it really a 64bit processor. It's more accurate to say that the parts that benefit from 64bit data/operations are, and the parts that don't arn't.
Changing your type is just as likely to kill compatibility, except it'll exhibit itself as odd subtle bugs next time you link to the library.
Or am I missing a finer detail here?
No, it just means that without hungarian notation I have to lookup which variables are members of my class, how I need to deal with them, and what operations need to be done.
...
Ex:
Is customers a linked list (delete customers)? Or is it an array of customers objects (delete [] customers)?
Am I dealing with a pointer to an integer (*InvoiceNumber)++, a reference to an integer (InvoiceNumber++, with the understanding that the calling function's value will be modified), or just an integer (InvoiceNumber++, with the understanding something else will need to be done to transfer the result to a more permanant location)?
Hungariant notation isn't necessary, it's convenient. Using it means I don't have to remember/lookup the minute details of 50 variables used in a function.
I don't know about anyone else who's used it, but I find that it drastically increases readability. It also drastically reduces the amount of time I have to spend investigating a segment of code to asses what the hell is going on.
m_iInvoiceNumber tells me immediately that I'm dealing with a member of my class that is an integer, which represents the invoice number -- not a long, not a short, not a char *, not a std::string, an integer. I didn't have to check the top of the file to see if some schmuck made it a global variable. I didn't have to check the whole subroutine to see if it was declaired locally. I didn't have to open the header file, search through the text to figure out if invoice number is declaired there, or one of it's base classes. Instead of spending 5 minutes trying to figure out what the hell "InvoiceNumber" was, because I couldn't remember it from the last time I had to look it up an hour ago, I knew everything I needed to know in 1/10th of a second.
And lord help you if you're forced to maintain VB code
Where does all of this misinformation come from?
? pa ge=a2
It was a 64 bit system. Had 2 64bit processors, 2 32bit processors, and a 16bit processor. It also had a 64bit wide system bus.
Read a FAQ if you don't believe me.
http://www.digiserve.com/eescape/showpage.phtml
It was a 64 bit system. Had 2 64bit processors, 2 32bit processors, and a 16bit processor. It also had a 64bit wide system bus.
? pa ge=a2
Read a FAQ if you don't believe me.
http://www.digiserve.com/eescape/showpage.phtml
If you're going to say something like that, at least get the facts right.
The jaguar had a 64bit GPU, a 64bit blitter, 32bit DSP, a 16bit 68k, and one or two other pieces that I'm forgetting about. The bus that connected all of these processors together was 64 bits wide.
I've actually found my '01 Eclipse to be easier to work on than my '84 Ranger. Brakes are simpler, struts/shocks are simpler, sparkplugs are way simpler, changing the oil is a snap. The engine is a more complicated design, but it's drastically easier to do work on. It LOOKS harder to work on, but when you get your hands dirty you find out that it's easier.
If something is going wrong, I just need to get an ODB-II logger ($150 w/cable & software) to pull the code out of the computer -- opposed to my truck where I've got to guess why the idle is off. Not only that, but I can actually have it log the performance characteristics of the car while I'm driving for even more diagnostic information.
You lose some flexability you previously had with non-computer controled vehicles, but you also gain more flexability in other areas. It's just a different kind of technology -- you've gotta get used to it. And when you figure it out, you've got more control than you could ever get before.
You don't get it.
Unfortunately, the world is not a perfect place, and writing a wrapper for every basic datatype you ever use is NOT practicle. OOP is nice. It's a good way to abstract GRAND concepts. It's not an efficient or practicle way of dealing with low level details. C++ is not a pure OOP language. And good lord, don't get me started about COM or exception handling...
Re: "get a better editor"
Emacs won't help you if you're looking at a printout doing a code review. Type is an important bit of information when trying to know what a variable does.
Should I delete [] or delete? Is ++ a valid operation or is (*)++ what I really want?
Search and replace is a wonderful thing.