25 minutes is how long it will play while you're jogging. If you're training for a marathon, these things suck. I'm out there for four hours. And yes, while you're jogging, it doesn't get one good read in from the hd for the whole 25 minutes. This applies to iPod as well.
Yes, although it is easier to bring a couple of libraries of general functions (like, say, matrix multiply or something) than to bring anything more specific. The more room-like, the less portable. Not that I've ever done any of that, of course =) The good news is, most useful libraries of general functions are available free on the net anyway (GSM encoding, compression, matrix stuff, plug-in text editors, tiff readers, corba, etc).
I don't know too many software engineers that don't keep at least a library of souce code from one development job to another, regardless of the "rules". However, it seems really bold to me to say your not going to create a competing service and then create one that is named after you.
I'm not sure that embrace and extend really applies here, because the protocols involved are entirely proprietary, not taken from internet IFC's. IM is a relative newcomer to internet protocols (talk notwithstanding), so there was nothing really to embrace, that I know of. Not that I have anything against MSoft, by the way. I use development tools, and commercial Microsoft development tools are currently far better than anything open source, as far as I know. Project files are another source of protocol-based frustration; the formats don't even seem to survive subsequent versions of the same IDE.
Yes, and Java is a language. Your point? Java is turing-equivalent. According to the Church-Turing thesis, anything computable can be written in Java. Including a JVM. One does need to execute that JVM, of course, but that's true of any bootstrap operation. It is possible to compile java to native code; JIT's do it all the time. C still needs some assembly routines at startup to run, and it relies on a BIOS underneath. If you want a real mind-bender on this subject, look into Futamura projections for some fun.
I agree that there are aspects of most professional jobs which can't be learned in school. However, there are other aspects which can only be learned in school. While schools as you say don't tend to keep up on the latest and greatest implementations of software, companies don't keep up on the latest and greatest research in computer science. As fundamental research is advanced, copmanies can miss out by not taking advantage of it. I advocate continuing education in the science/algorithms/theory side of CS for architecture-level software engineers. However, as far as I'm concerned, we can skip the entire software-engineering curriculum in schools. Methodology/debugging/coding, as opposed to algorithms, is really something you can only learn on the job; all the theory about software engineering is bs, piled quite high and deep.
7) Stupid people can get PhD's far easier than smart people. Simply put, professors want stupid people out of their hair, if they can't wash em out, they graduate em. Just like elementary school.
I'm hoping it works the same way for lazy people;0)
I used to think the same thing until I stared working on one. Investigate what it really means to get one, and what it takes, and you might think different(ly).
Your characterization of the typical victim is correct; there was even someone who died from it recently. However, dehydration is still a much greater problem among first-time marathoners.
Indeed, some indigenous people are used to treating these symptoms as a calling, rather than as a disease. When someone in a shamanic culture has such an experience, they are taught by the shaman how to deal with it. By the way, I saw the movie (never read the book), and that was my impression, that Dr. Nash learned to "deal" on his own, rather than through the drugs. The drugs impaired his thinking ability, according to the movie.
Yes, very good points that I mainly agree with. I think it comes down to the level of control. Being a system-level guy, I am used to having the control I want when I need it. Most implementations of GC seem to take this away. Obviously, in most cases one wants to leave gc up to the system, but there are many times when we want a finer level of control, and we want it to be natural. And then, my pet peeve is that we should always but always be able to replace default crappy gc's with the far more clever ones of our own devising. This might be something solved by open sourcing of these systems, but I think a decent system design would simply leave something that important open for improvement. Some apps care about good GC, and some don't.
Guilty.
Of course I know about inlining functions, but I should have been more explicit about that knowledge up front, rather than allow someone to beat down my strawman.
There is overhead, even if a good programmer can work to minimize it. There are also cases where any given inferior garbage collection scheme like auto_ptr or smart pointers/reference counting fails. A good garbage collection scheme will create generations for short-term 0/1 data like this and longer term data, and handle it automatically. The overhead accumulated by all the auto_ptr assignments and such will be in general amortized to the garbage collection. But, garbage collection is much simpler to use. Code is not obfuscated with housekeeping syntax and semantics. No pointers have to be treated specially; no programming resources are wasted deciding whether something should be "special" or not (owner or not, forward vs. backward in your examples). As has always been the case, the "good programmer" resource is in the shortest supply. Yes, generalized garbage collection does have drawbacks, but it is not as bad as most C/C++ programmers suppose; and in most cases not as bad as the inferior garbage collection scheme they are already using.
Yes, but the equivalent operations are as follows: //precondition: x has pointer, y has other pointer
y = x; //postcondition: y has pointer, x is 0, other pointer is freed
There is a lot of implicit code, such as assignment of x=0 there every time you do an assignment. So inline or not, there is overhead compared to: //precondition: x has pointer, y has other pointer
y = x; //postcondition: x and y have pointer, other pointer is garbage to be dealt with later
The latter is fine for most garbage collection schemes; the saved overhead of x=0, etc. is amortized across the garbage collection overhead. Additionally, garbage collection solves far more problems than invariably having only one pointer to any object. Double-linked lists come to mind again, where I want a->b and b->a. In the list a,b,c, c and a both point to b.
25 minutes is how long it will play while you're jogging. If you're training for a marathon, these things suck. I'm out there for four hours. And yes, while you're jogging, it doesn't get one good read in from the hd for the whole 25 minutes. This applies to iPod as well.
Yes, although it is easier to bring a couple of libraries of general functions (like, say, matrix multiply or something) than to bring anything more specific. The more room-like, the less portable. Not that I've ever done any of that, of course =) The good news is, most useful libraries of general functions are available free on the net anyway (GSM encoding, compression, matrix stuff, plug-in text editors, tiff readers, corba, etc).
I don't know too many software engineers that don't keep at least a library of souce code from one development job to another, regardless of the "rules". However, it seems really bold to me to say your not going to create a competing service and then create one that is named after you.
I'm not sure that embrace and extend really applies here, because the protocols involved are entirely proprietary, not taken from internet IFC's. IM is a relative newcomer to internet protocols (talk notwithstanding), so there was nothing really to embrace, that I know of. Not that I have anything against MSoft, by the way. I use development tools, and commercial Microsoft development tools are currently far better than anything open source, as far as I know. Project files are another source of protocol-based frustration; the formats don't even seem to survive subsequent versions of the same IDE.
Yes, and Java is a language. Your point? Java is turing-equivalent. According to the Church-Turing thesis, anything computable can be written in Java. Including a JVM. One does need to execute that JVM, of course, but that's true of any bootstrap operation. It is possible to compile java to native code; JIT's do it all the time. C still needs some assembly routines at startup to run, and it relies on a BIOS underneath. If you want a real mind-bender on this subject, look into Futamura projections for some fun.
The password is world.
I agree that there are aspects of most professional jobs which can't be learned in school. However, there are other aspects which can only be learned in school. While schools as you say don't tend to keep up on the latest and greatest implementations of software, companies don't keep up on the latest and greatest research in computer science. As fundamental research is advanced, copmanies can miss out by not taking advantage of it. I advocate continuing education in the science/algorithms/theory side of CS for architecture-level software engineers. However, as far as I'm concerned, we can skip the entire software-engineering curriculum in schools. Methodology/debugging/coding, as opposed to algorithms, is really something you can only learn on the job; all the theory about software engineering is bs, piled quite high and deep.
Heck no. I wouldn't recommend getting one unless you want to teach at university. Period.
I used to think the same thing until I stared working on one. Investigate what it really means to get one, and what it takes, and you might think different(ly).
Your characterization of the typical victim is correct; there was even someone who died from it recently. However, dehydration is still a much greater problem among first-time marathoners.
Meant to include this website.
Indeed, some indigenous people are used to treating these symptoms as a calling, rather than as a disease. When someone in a shamanic culture has such an experience, they are taught by the shaman how to deal with it. By the way, I saw the movie (never read the book), and that was my impression, that Dr. Nash learned to "deal" on his own, rather than through the drugs. The drugs impaired his thinking ability, according to the movie.
Just a joke.
To the inbox? More importantly you can redirect it to a box that doesn't preview automatically as your boss walks by.
google it. You "must work for NASA" (make that Lockheed Martin) if you get your units wrong.
Yes, very good points that I mainly agree with. I think it comes down to the level of control. Being a system-level guy, I am used to having the control I want when I need it. Most implementations of GC seem to take this away. Obviously, in most cases one wants to leave gc up to the system, but there are many times when we want a finer level of control, and we want it to be natural. And then, my pet peeve is that we should always but always be able to replace default crappy gc's with the far more clever ones of our own devising. This might be something solved by open sourcing of these systems, but I think a decent system design would simply leave something that important open for improvement. Some apps care about good GC, and some don't.
Guilty. Of course I know about inlining functions, but I should have been more explicit about that knowledge up front, rather than allow someone to beat down my strawman.
There is overhead, even if a good programmer can work to minimize it. There are also cases where any given inferior garbage collection scheme like auto_ptr or smart pointers/reference counting fails. A good garbage collection scheme will create generations for short-term 0/1 data like this and longer term data, and handle it automatically. The overhead accumulated by all the auto_ptr assignments and such will be in general amortized to the garbage collection. But, garbage collection is much simpler to use. Code is not obfuscated with housekeeping syntax and semantics. No pointers have to be treated specially; no programming resources are wasted deciding whether something should be "special" or not (owner or not, forward vs. backward in your examples). As has always been the case, the "good programmer" resource is in the shortest supply. Yes, generalized garbage collection does have drawbacks, but it is not as bad as most C/C++ programmers suppose; and in most cases not as bad as the inferior garbage collection scheme they are already using.
Yes, but the equivalent operations are as follows:
//precondition: x has pointer, y has other pointer
//postcondition: y has pointer, x is 0, other pointer is freed
//precondition: x has pointer, y has other pointer
//postcondition: x and y have pointer, other pointer is garbage to be dealt with later
y = x;
There is a lot of implicit code, such as assignment of x=0 there every time you do an assignment. So inline or not, there is overhead compared to:
y = x;
The latter is fine for most garbage collection schemes; the saved overhead of x=0, etc. is amortized across the garbage collection overhead.
Additionally, garbage collection solves far more problems than invariably having only one pointer to any object. Double-linked lists come to mind again, where I want a->b and b->a. In the list a,b,c, c and a both point to b.
Sorry, here's the link.
D? Don't you geeks have any sense of history? The next language in line is P. The first language derived from BCPL was B, then C. Next is P, then L.