I suppose that could happen. After all, even if it is SQL Server under the hood, they don't have to allow anything to talk to it. I'm currently assuming that they won't lock it down like that, that ODBC et all drivers will be available for it. I think it would be a poor move strategically for them to lock it down. After all, how useful of a resource would a filesystem be if other platforms cannot access it?
The script kiddy scenario is a danger I suppose, but not anymore than it is today. How secure is NTFS after all? Itâ(TM)s as secure as the services that offer it, right? Security of these types of resources is an ongoing battle. No technology resource that can be externally exposed outside an organization is immune from those concerns.
3. Getting a relational filesystem to do those things will be easier and require less outside products to do it. Time will tell I guess. Also, there will be things you can do with a relational filesystem that a normal filesystem will NOT be able to do at all.
4. I see your point. The main problem with SQL worms, etc. isn't SQL Server's relational engine; it's the communication ports into the database service that make it accessible to the outside world. Those same types of exploits may very well be usable against a relational filesystem which is externally accessible. If you put a filesystem or database outside the firewall, it had better not be very important. Businesses do it anyway, but they also get hacked. SQL hacks are only effective on sloppily programmed systems that trust the user to not put extra SQL clauses in data. Simple field validation scanners that only allow legitimate input characters of pre-determined lengths prevent that sort of thing. These are all risks of using SQL Server for a file system, but none of those risks negate the overall benefits of relational filesystems.
And, will Longhorn finally do away with the whole drive letter concept?
Well, I don't really know what the objection would be to this? After all, it's not like the drive letters really mean much anymore except to users. Most users would rather type "F:" instead of "\\Server1\HumanResources\WorkToDo\PersonalVolumes \JoeBlow", for some strange reason.:+)
What I've always objected to is that we can ONLY assign single letters like "F" instead of something that would make sense like "MyWorkToDo". This was one of my complaints about Windows when I came to the PC world from Amigas. I could do this in AmigaDOS, but not in the PC world. That never made sense to me since it seems like it would be so easy to add to the OS. My guess is that they were too afraid of breaking existing programs to do it.
I'm looking forward to this! I personally am sick and tired of filesystems as we know them today. Today's filesystems are a strict hierarchy, the existence of which is only necessary in the systems of yester-year.
A filesystem based on a relational database will have some characteristics to which today's filesystems can only aspire:
1. ACID - In every way that the underlying database supports Atomicity, Consistency, Isolation, and Durability, so now will the filesystem. In so far as the database is robust, the filesystem will be robust. Please spare me the comments about the supposed unreliability of SQL Server. Itâ(TM)s certainly more reliable than NTFS; which is itself very good.
2. As an offshoot of the above - Imagine multiple file updates to a filesystem which is transactional! Imagine that transaction failing and being able to just rollback the changes without touching every file in your program! Imagine being able to make file changes programmatically without having to worry about locking because the engine will do it for you (just handle any exceptions)! Yeah, you could do all that today if you like. But it takes extensive to make it happen.
3. Operational characteristics - We can run queries against databases. We can index them. We can cluster them. We can replicate them. We can access them easily from any development platform you can imagine. Now your filesystem is a database. The possibilities make me shiver!:+) Maybe the initial implementation wonâ(TM)t get all this right. But at least it stands a chance.
4. Another offshoot from #3 - Security. Databases are inherently better than filesystems (IMNSHO) at enforcing security and enabling administration of security.
I only have reservations about one issue with the database as filesystem area: recovery. Currently, all good and low-tech filesystem recovery tools really are based on the filesystem allocation table sort of scheme. Obviously, databases usurp this category of tried and true tools. However, good tools already do exist that allow recovery of relational databases. Itâ(TM)s just a matter of getting easily accessible tools of this sort into the hands of professionals that need them. It's more of a training issue I guess, but it will still need addressing.
I know many people will have a knee jerk reaction to this idea, and I understand why. But I would encourage people to keep an open mind to this. While there will probably be some issues with the idea, there's so much more that could easily be done with a filesystem on top of a database than could be done easily (or well) with a traditional filesystem.
Just out of curiosity: Isn't it possible for people like Mr. Klinck to keep salary considerations off the table? If he states something like âoeSalary requirements: Negotiableâ or âoeFlexibleâ or something like that, wouldn't that be a good clue for a future employer that he may very well be happy with the $50K or whatever they have budgeted for the position?
I think this whole "over-qualified" thing is a bit ridiculous when people clearly are willing to take on positions for which they might seem over-qualified. I frankly don't understand what "over-qualified" means. If someone is willing to take on the position and the corresponding salary, then I think the company ought to congratulate themselves on filling the position with someone that has considerable experience. Additionally, that person will probably feel a measure of gratitude for the break and offer back to the company a measure of service and insight to which the company would not otherwise have access.
That's a bad reason, if any...JUST LIE!!!! Does it really matter? What _really_ matters is doing it right and doing so efficiently.
Bzzzt! Wrong answer!
What *really* matters (to me, anyway) is staying employed. Your strategy employs two faulty tactics: lying and not focusing on what the customer needs or say they need. If you lie about your experience, then be prepared to accept the consequences when you're found out. If you do a project in Python when a customer specifically requests Java, then be prepared to lose the business.
Your opinions about Python are all well and fine but if you have the choice between Java and Python on a project, use Java.
Even though I happen to agree that Python is a better language (for the most part), I would always stick to Java. I chose Python on a project I did. I would much rather have that experience on my resume as Java instead. Python is nice, but employers just aren't looking for it.
Sad, but true.
On a side note: Microsoft Site Server 3.0 was written in Python by the original shop that wrote it (an acquired product). No one would touch the source until they moved it to C++ for the next version of the code (it's called Commerce Server now). If you don't believe me, install Site Server and look for the.pyc files in there.
Gee, now if we could just hook 'em all up to energy collection devices while they're sitting around tuned into their games. Then they could power all the devices we "non-wireheads" use.
Where have I heard that before? Hmmm...
Here's looking forward to freely moving traffic!;)
Do you think AOL bought up the rights to Netscape and established the Mozilla OSS project out of the goodness of their hearts?
I don't think so.
It has been obvious to me for some time that Mozilla is an ace card that AOL can use when bargaining with Microsoft over the rights to use the IE browser from their AOL client. Without Mozilla, Microsoft would be able to dictate the terms of the agreement. With Mozilla, Microsoft has to give a little so they can take a little. The arrangement is much more fair that way.
Personally, I think AOL played this one smart. They will probably continue to feed the Mozilla project for the foreseeable future; it's just a question of to what degree they will do that.
Yes, I do read replies; even replies to messages I had forgotten about.;+)
It's too bad it happened that way for you. I'm glad to hear that a looser environment like that can work out for a business. If I ever get in the entrepreneurial mood someday, I may give it a try.
Ok.. I just checked, and SQL Server at least will only do one table scan when you do a "select * from mytable". This makes sense, because the database engine doesn't need to do a table scan to find out all of the columns in the table; it just uses the metadata about the table in the database instead. In the case of SQL Server, the database engine probably looks at the contents of the sysobjects and/or syscolumns system tables to get the column information. And in that case, there shouldn't be a table scan against those either because the engine will query those system tables using an indexed column (probably the name of the table itself or its object id, I'm too lazy to check right now) to get the columns in the table.
I would agree that 99% of MySQL "developers" don't know much about databases in general; that's why they chose MySQL in the first place. Obviously, MySQL does have its place, but I don't think they know what they're missing compared to a more complete RDBMS.
My sympathies on your love affair with SQL Plus.;+)
Oh stop the bullshit, the MS stuff still crashes all the time. I have a xp box at work that crashes every three days.
Well, it must be the case that it senses your anti-MS 'tude, and craps out on you just to get under your skin.
Or perhaps you installed crappy drivers/software.
Or perhaps you have crappy hardware.
Or.. whatever.
I don't care. The point is that the vast majority of people out there are far happier than they've ever been with Windows. FUD and anecdotal evidence won't change that. The fact that it doesn't work for you isn't proof of anything.
BTW - If you love Linux so much, don't use Windows. In fact, I think you should refuse.
When the crap hits the fan, maybe you could just do the Killerbotics thing full time and forget about IT. Given all the time you're spending on your hobbies, you can't actually know what you're doing with Windows.
At my last company we had a pool table, a ping-pong table, two fooz ball tables, a dart board, a wide screen TV, DVD player, and sometimes people would bring in movies or hook up a game system.
That kind of says it all doesn't it? Your "last company"? Are they still in business?
If so, great! I would love for this sort of thing to actually work out. If not, I'm not surprised.
So, what happened? Did you quit? If so, why quit such a great employer? Were you fired? If so, was it because of a layoff or perhaps from excessive screwing around?:+)
I agree that your situation sounds like it was pleasant. I just don't see how it was necessarily productive.
NineNine: That's not why you don't do "Select *". You don't do it because "select *" requires an extra full-table scan
I believe your statement is only correct if the select has no where clause.
So: select * from mytable
Would cause a full table scan, unconditionally. Yup, that's bad.
However: select * from mytable where myindexedcolumn = somevalue
Would not use a full table scan as long as myindexedcolumn is indeed indexed. But if it is not indexed, then we're back to a full table scan. Note that just because we're using an index scan instead of a table scan, we're not necessarily optimal at this point. We may still need to consider paging, index clustering, server memory, etc.
To jdh-22's point: I would agree that using "select *" instead of "select cola, colb, colc.." is bad because you'll be returning too much data. If you don't actually need all the columns in the table, don't ask for them. To request unecessary columns is just a waste of resources.
BTW, your point about Windows doesn't hold very well: I know and use a lot of keystrokes for Windows, Word, NT Emacs, Explorer, etc.
Well, I do that too. And you know, I haven't been able to get through the day without reaching for the mouse. Browser stuff is particularly bad since hitting tab 40 times to get to the field you want to enter really isn't efficient compared to just clicking on it with the mouse.
I would dearly love to dump my mouse if I could work just as efficiently without it as I can with it; but that isn't the case.
Show me a way to do that and I'll PayPal the price of a nice dinner to you if I agree it works (efficiently). I would even tolerate a bit of a learning curve (like maybe 4 hours worth TOTAL) if the method in question works. My only criteria is that the replacement has to be just as fast without the mouse (once I've conquered the learning curve) as it is with the mouse.
Can that be done? Not without dumping Windows entirely I suspect. The problem here is that while there are some keyboard standards in Windows, applications are ultimately free to define how they map keyboard shortcuts. Collapsing an outline is done with the keyboard one way in Explorer, and another way in Word. The problem is even worse if you're talking about Windows apps not developed by Microsoft. Every new program is another adventure in keystroke memorization.
The mouse is simply king of that domain. Point. Click. It can't be any simpler than that. Unfortunately, it's horrible for my arm. That's just too bad for me I guess.
As soon as I get over my fear of relearning all the Emacs/Bash/KDE shortcuts I know, I'll switch back to Qwerty.
Concerning this, I do have a solution to this for you that would solve the problem instantly:
Using Windows instead of *nix*.
*duck*
Yes, I'm only kidding. Don't get all traumatized about it.:+) Of course, the issue with going to Windows is that you practically have to use the mouse to get by, so your wrists will quickly succumb to "mouse-itis". I do wish I could completely do without a mouse in Windows.
Yup... this is definitely a danger. You've got to lay down the law and enforce it. You've also got to live up to it.
If you're goofing around at home instead of working, your spouse will get pissed off that you're not helping out around the house instead. If you tell him/her "don't bug me between 9 to 5, pretend I'm not here", you damn well better be busting your ass for a client.
If you're doing anything else, then just do some random stuff around the house BEFORE goofing off. It keeps the friction way down.
The only problem now is that I have broadband, so I can't dial into my PC:) So maybe the article is news:)
I still don't think it's news. After all, couldn't you just set up a WAP and get a wireless card for your Palm (as well as Palm that can take a wireless card)?
Re:Writing a language in itself
on
Python in a Nutshell
·
· Score: 2, Insightful
For compiled languages, implementing the language in itself serves a real purpose. For example, gcc is implemented in C which helps its portability. That is, the compiler can bootstrap itself into existence simply by compiling from an existing compiler on the system or cross-compiling itself from another system.
You're right. But I wasn't really addressing this. By implementing a "language in itself", I was really referring to more dynamic languages like Python, Perl, TCL, LISP, Smalltalk, etc. A Python program could run a Python interpreter, which could run a Python interpreter, etc. and it could change at run-time as per the user. Doing the same think in C, C++, Ada, Pascal, etc. doesn't even make sense unless you're talking about some sort of interpreted versions of those languages. I would say that bootstrapping is quite different from "dynamic re-entrancy" (my term, yeah it's not a real term).
At any rate, either of these techniques are of little interest to non-nerds (see my above definition).
Also, I wouldn't say that just because I can implement a language in itself, that the language is mature. Any Turing complete language can, theoretically, be implemented in any other Turing complete language. To me, a real developer who develops real solutions for real customers, a language is "mature" when I can use it for a client and not be let down by the language and the accompanying tools and environment. That's a far more difficult thing to measure and the measure is much more demanding to satisfy, once it is measured.
It's a nerd thing (I would say it's a geek thing, but a geek is a nerd that can actually function well in society and I'm not convinced people who do these things have actually graduated to geek). If a language can be used to create an implementation of itself, and that implementation can in turn be run on itself, then it's considered proven that the language is sufficiently useful for "real" usage.
I won't claim to understand it. It certainly doesn't do anything for the general populace. It ought to be enough to say that a language is Turing complete to say it can be used "for real". For some reason, it just gives the CS crowd big warm fuzzies when they do stuff like that.
Hmm... maybe you could start a local branch of the BSA and help to crack down on the companies that denied you employment because they were running unlicensed software?
It would be very cathartic for you, Microsoft would get a short term revenue increase, and the Linux camp in Russia would probably get a boat load of Windows defectors who finally caved into local BSA pressures.
Of course, you getter have a freaking battalion of goons to help you or I imagine you would be sans knee caps real quick-like, but I guess that goes without saying in that kind of work in that kind of area.
If you're a anti-MS type, then you might rejoice in this decision. Why? Well, because MS is obviously dishing out serious dough to a company you like and support in order to delay releasing the game anywhere else until the XBOX version is released. In the console gaming world, the XBOX really isn't cutting it with the market share they're (not) getting.
So, to summarize: A company you may hate is propping up a company you love to release the game on a platform they're going to flush on the next console life cycle iteration. (Witness the Dreamcast. Me? Bitter? hmmph)
Net effect: The company you love is going to PROFIT (glad to see *someone* figure out how to do this) at the expense of the company you don't like.
Feel better?
Now, go pre-order a copy of DoomIII or something.;+)
Old computers are still very useful
on
Implementing VisiCalc
·
· Score: 3, Insightful
It's hard to get by these days without knowing at least a little bit about how to use a PC.
Well, you're right about that, but it misses the point. The educational value of a computer does not, for the most part, lie in learning how to use the computer for its own sake. A computer is a general purpose information tool and one goal in owning a computer is education. Education can include reading, writing, math, science, social studies, etc. A computer can, to an extent, help with all of those subjects.
Note that an Apple ][ will help you just as much with your math as a PC, as long as the software on each is roughly equivalent.
I do get tired of hearing about school districts that just dropped $250,000 for a brand new computer lab, and then they turn around and lay off teachers then complain about the student:teacher ratio. It doesn't make sense to do that when you consider that they really don't even need the lab.
The above probably set you to thinking about how inadequate an Apple would be to learn computer science subjects. You would be right to an extent, but a lab really sees far more uses than just for computer science education. If the goal is to best serve the majority of the student body, then buying your computer equipment (and by extension the education software) around the needs of your computer science oriented students is a poor choice.
Slashdot Mirror
I suppose that could happen. After all, even if it is SQL Server under the hood, they don't have to allow anything to talk to it. I'm currently assuming that they won't lock it down like that, that ODBC et all drivers will be available for it. I think it would be a poor move strategically for them to lock it down. After all, how useful of a resource would a filesystem be if other platforms cannot access it?
The script kiddy scenario is a danger I suppose, but not anymore than it is today. How secure is NTFS after all? Itâ(TM)s as secure as the services that offer it, right? Security of these types of resources is an ongoing battle. No technology resource that can be externally exposed outside an organization is immune from those concerns.
1. Cute. 'Nuff said there I think. :+)
;+)
2. Yup.
3. Getting a relational filesystem to do those things will be easier and require less outside products to do it. Time will tell I guess. Also, there will be things you can do with a relational filesystem that a normal filesystem will NOT be able to do at all.
4. I see your point. The main problem with SQL worms, etc. isn't SQL Server's relational engine; it's the communication ports into the database service that make it accessible to the outside world. Those same types of exploits may very well be usable against a relational filesystem which is externally accessible. If you put a filesystem or database outside the firewall, it had better not be very important. Businesses do it anyway, but they also get hacked. SQL hacks are only effective on sloppily programmed systems that trust the user to not put extra SQL clauses in data. Simple field validation scanners that only allow legitimate input characters of pre-determined lengths prevent that sort of thing. These are all risks of using SQL Server for a file system, but none of those risks negate the overall benefits of relational filesystems.
So, nyah!
And, will Longhorn finally do away with the whole drive letter concept?
s \JoeBlow", for some strange reason. :+)
Well, I don't really know what the objection would be to this? After all, it's not like the drive letters really mean much anymore except to users. Most users would rather type "F:" instead of "\\Server1\HumanResources\WorkToDo\PersonalVolume
What I've always objected to is that we can ONLY assign single letters like "F" instead of something that would make sense like "MyWorkToDo". This was one of my complaints about Windows when I came to the PC world from Amigas. I could do this in AmigaDOS, but not in the PC world. That never made sense to me since it seems like it would be so easy to add to the OS. My guess is that they were too afraid of breaking existing programs to do it.
Oh well... *sigh*
I'm looking forward to this! I personally am sick and tired of filesystems as we know them today. Today's filesystems are a strict hierarchy, the existence of which is only necessary in the systems of yester-year.
:+) Maybe the initial implementation wonâ(TM)t get all this right. But at least it stands a chance.
A filesystem based on a relational database will have some characteristics to which today's filesystems can only aspire:
1. ACID - In every way that the underlying database supports Atomicity, Consistency, Isolation, and Durability, so now will the filesystem. In so far as the database is robust, the filesystem will be robust. Please spare me the comments about the supposed unreliability of SQL Server. Itâ(TM)s certainly more reliable than NTFS; which is itself very good.
2. As an offshoot of the above - Imagine multiple file updates to a filesystem which is transactional! Imagine that transaction failing and being able to just rollback the changes without touching every file in your program! Imagine being able to make file changes programmatically without having to worry about locking because the engine will do it for you (just handle any exceptions)! Yeah, you could do all that today if you like. But it takes extensive to make it happen.
3. Operational characteristics - We can run queries against databases. We can index them. We can cluster them. We can replicate them. We can access them easily from any development platform you can imagine. Now your filesystem is a database. The possibilities make me shiver!
4. Another offshoot from #3 - Security. Databases are inherently better than filesystems (IMNSHO) at enforcing security and enabling administration of security.
I only have reservations about one issue with the database as filesystem area: recovery. Currently, all good and low-tech filesystem recovery tools really are based on the filesystem allocation table sort of scheme. Obviously, databases usurp this category of tried and true tools. However, good tools already do exist that allow recovery of relational databases. Itâ(TM)s just a matter of getting easily accessible tools of this sort into the hands of professionals that need them. It's more of a training issue I guess, but it will still need addressing.
I know many people will have a knee jerk reaction to this idea, and I understand why. But I would encourage people to keep an open mind to this. While there will probably be some issues with the idea, there's so much more that could easily be done with a filesystem on top of a database than could be done easily (or well) with a traditional filesystem.
And for you hard-core naysayers out there, you have to ask yourself this: If this is such a bad idea, then why did Oracle provide this as a feature too?
"erroneous mistakes"???
;+)
Methinks *you* need more of that rest you seem to hold sacred.
Just out of curiosity: Isn't it possible for people like Mr. Klinck to keep salary considerations off the table? If he states something like âoeSalary requirements: Negotiableâ or âoeFlexibleâ or something like that, wouldn't that be a good clue for a future employer that he may very well be happy with the $50K or whatever they have budgeted for the position?
I think this whole "over-qualified" thing is a bit ridiculous when people clearly are willing to take on positions for which they might seem over-qualified. I frankly don't understand what "over-qualified" means. If someone is willing to take on the position and the corresponding salary, then I think the company ought to congratulate themselves on filling the position with someone that has considerable experience. Additionally, that person will probably feel a measure of gratitude for the break and offer back to the company a measure of service and insight to which the company would not otherwise have access.
What am I missing here?
That's a bad reason, if any...JUST LIE!!!! Does it really matter? What _really_ matters is doing it right and doing so efficiently.
Bzzzt! Wrong answer!
What *really* matters (to me, anyway) is staying employed. Your strategy employs two faulty tactics: lying and not focusing on what the customer needs or say they need. If you lie about your experience, then be prepared to accept the consequences when you're found out. If you do a project in Python when a customer specifically requests Java, then be prepared to lose the business.
Your opinions about Python are all well and fine but if you have the choice between Java and Python on a project, use Java.
.pyc files in there.
Even though I happen to agree that Python is a better language (for the most part), I would always stick to Java. I chose Python on a project I did. I would much rather have that experience on my resume as Java instead. Python is nice, but employers just aren't looking for it.
Sad, but true.
On a side note: Microsoft Site Server 3.0 was written in Python by the original shop that wrote it (an acquired product). No one would touch the source until they moved it to C++ for the next version of the code (it's called Commerce Server now). If you don't believe me, install Site Server and look for the
*sigh*
Gee, now if we could just hook 'em all up to energy collection devices while they're sitting around tuned into their games. Then they could power all the devices we "non-wireheads" use.
;)
Where have I heard that before? Hmmm...
Here's looking forward to freely moving traffic!
Do you think AOL bought up the rights to Netscape and established the Mozilla OSS project out of the goodness of their hearts?
I don't think so.
It has been obvious to me for some time that Mozilla is an ace card that AOL can use when bargaining with Microsoft over the rights to use the IE browser from their AOL client. Without Mozilla, Microsoft would be able to dictate the terms of the agreement. With Mozilla, Microsoft has to give a little so they can take a little. The arrangement is much more fair that way.
Personally, I think AOL played this one smart. They will probably continue to feed the Mozilla project for the foreseeable future; it's just a question of to what degree they will do that.
Yes, I do read replies; even replies to messages I had forgotten about. ;+)
It's too bad it happened that way for you. I'm glad to hear that a looser environment like that can work out for a business. If I ever get in the entrepreneurial mood someday, I may give it a try.
Best of luck!
Ok.. I just checked, and SQL Server at least will only do one table scan when you do a "select * from mytable". This makes sense, because the database engine doesn't need to do a table scan to find out all of the columns in the table; it just uses the metadata about the table in the database instead. In the case of SQL Server, the database engine probably looks at the contents of the sysobjects and/or syscolumns system tables to get the column information. And in that case, there shouldn't be a table scan against those either because the engine will query those system tables using an indexed column (probably the name of the table itself or its object id, I'm too lazy to check right now) to get the columns in the table.
;+)
I would agree that 99% of MySQL "developers" don't know much about databases in general; that's why they chose MySQL in the first place. Obviously, MySQL does have its place, but I don't think they know what they're missing compared to a more complete RDBMS.
My sympathies on your love affair with SQL Plus.
Oh stop the bullshit, the MS stuff still crashes all the time. I have a xp box at work that crashes every three days.
Well, it must be the case that it senses your anti-MS 'tude, and craps out on you just to get under your skin.
Or perhaps you installed crappy drivers/software.
Or perhaps you have crappy hardware.
Or.. whatever.
I don't care. The point is that the vast majority of people out there are far happier than they've ever been with Windows. FUD and anecdotal evidence won't change that. The fact that it doesn't work for you isn't proof of anything.
BTW - If you love Linux so much, don't use Windows. In fact, I think you should refuse.
When the crap hits the fan, maybe you could just do the Killerbotics thing full time and forget about IT. Given all the time you're spending on your hobbies, you can't actually know what you're doing with Windows.
At my last company we had a pool table, a ping-pong table, two fooz ball tables, a dart board, a wide screen TV, DVD player, and sometimes people would bring in movies or hook up a game system.
:+)
That kind of says it all doesn't it? Your "last company"? Are they still in business?
If so, great! I would love for this sort of thing to actually work out. If not, I'm not surprised.
So, what happened? Did you quit? If so, why quit such a great employer? Were you fired? If so, was it because of a layoff or perhaps from excessive screwing around?
I agree that your situation sounds like it was pleasant. I just don't see how it was necessarily productive.
I think you're both deluded. ;+)
NineNine:
That's not why you don't do "Select *". You don't do it because "select *" requires an extra full-table scan
I believe your statement is only correct if the select has no where clause.
So:
select * from mytable
Would cause a full table scan, unconditionally. Yup, that's bad.
However:
select * from mytable where myindexedcolumn = somevalue
Would not use a full table scan as long as myindexedcolumn is indeed indexed. But if it is not indexed, then we're back to a full table scan. Note that just because we're using an index scan instead of a table scan, we're not necessarily optimal at this point. We may still need to consider paging, index clustering, server memory, etc.
To jdh-22's point:
I would agree that using "select *" instead of "select cola, colb, colc.." is bad because you'll be returning too much data. If you don't actually need all the columns in the table, don't ask for them. To request unecessary columns is just a waste of resources.
BTW, your point about Windows doesn't hold very well: I know and use a lot of keystrokes for Windows, Word, NT Emacs, Explorer, etc.
Well, I do that too. And you know, I haven't been able to get through the day without reaching for the mouse. Browser stuff is particularly bad since hitting tab 40 times to get to the field you want to enter really isn't efficient compared to just clicking on it with the mouse.
I would dearly love to dump my mouse if I could work just as efficiently without it as I can with it; but that isn't the case.
Show me a way to do that and I'll PayPal the price of a nice dinner to you if I agree it works (efficiently). I would even tolerate a bit of a learning curve (like maybe 4 hours worth TOTAL) if the method in question works. My only criteria is that the replacement has to be just as fast without the mouse (once I've conquered the learning curve) as it is with the mouse.
Can that be done? Not without dumping Windows entirely I suspect. The problem here is that while there are some keyboard standards in Windows, applications are ultimately free to define how they map keyboard shortcuts. Collapsing an outline is done with the keyboard one way in Explorer, and another way in Word. The problem is even worse if you're talking about Windows apps not developed by Microsoft. Every new program is another adventure in keystroke memorization.
The mouse is simply king of that domain. Point. Click. It can't be any simpler than that. Unfortunately, it's horrible for my arm. That's just too bad for me I guess.
Nice post.
:+) Of course, the issue with going to Windows is that you practically have to use the mouse to get by, so your wrists will quickly succumb to "mouse-itis". I do wish I could completely do without a mouse in Windows.
As soon as I get over my fear of relearning all the Emacs/Bash/KDE shortcuts I know, I'll switch back to Qwerty.
Concerning this, I do have a solution to this for you that would solve the problem instantly:
Using Windows instead of *nix*.
*duck*
Yes, I'm only kidding. Don't get all traumatized about it.
It's their games review program. They tend to be somewhat goofy, but they're fairly objective.
I agree that the channel can get pretty disgusting with the amount of pandering to vendors that they do, but the channel isn't a total waste.
Yup... this is definitely a danger. You've got to lay down the law and enforce it. You've also got to live up to it.
If you're goofing around at home instead of working, your spouse will get pissed off that you're not helping out around the house instead. If you tell him/her "don't bug me between 9 to 5, pretend I'm not here", you damn well better be busting your ass for a client.
If you're doing anything else, then just do some random stuff around the house BEFORE goofing off. It keeps the friction way down.
The only problem now is that I have broadband, so I can't dial into my PC :) So maybe the article is news :)
I still don't think it's news. After all, couldn't you just set up a WAP and get a wireless card for your Palm (as well as Palm that can take a wireless card)?
For compiled languages, implementing the language in itself serves a real purpose. For example, gcc is implemented in C which helps its portability. That is, the compiler can bootstrap itself into existence simply by compiling from an existing compiler on the system or cross-compiling itself from another system.
You're right. But I wasn't really addressing this. By implementing a "language in itself", I was really referring to more dynamic languages like Python, Perl, TCL, LISP, Smalltalk, etc. A Python program could run a Python interpreter, which could run a Python interpreter, etc. and it could change at run-time as per the user. Doing the same think in C, C++, Ada, Pascal, etc. doesn't even make sense unless you're talking about some sort of interpreted versions of those languages. I would say that bootstrapping is quite different from "dynamic re-entrancy" (my term, yeah it's not a real term).
At any rate, either of these techniques are of little interest to non-nerds (see my above definition).
Also, I wouldn't say that just because I can implement a language in itself, that the language is mature. Any Turing complete language can, theoretically, be implemented in any other Turing complete language. To me, a real developer who develops real solutions for real customers, a language is "mature" when I can use it for a client and not be let down by the language and the accompanying tools and environment. That's a far more difficult thing to measure and the measure is much more demanding to satisfy, once it is measured.
It's a nerd thing (I would say it's a geek thing, but a geek is a nerd that can actually function well in society and I'm not convinced people who do these things have actually graduated to geek). If a language can be used to create an implementation of itself, and that implementation can in turn be run on itself, then it's considered proven that the language is sufficiently useful for "real" usage.
I won't claim to understand it. It certainly doesn't do anything for the general populace. It ought to be enough to say that a language is Turing complete to say it can be used "for real". For some reason, it just gives the CS crowd big warm fuzzies when they do stuff like that.
Hmm... maybe you could start a local branch of the BSA and help to crack down on the companies that denied you employment because they were running unlicensed software?
:+)
It would be very cathartic for you, Microsoft would get a short term revenue increase, and the Linux camp in Russia would probably get a boat load of Windows defectors who finally caved into local BSA pressures.
Of course, you getter have a freaking battalion of goons to help you or I imagine you would be sans knee caps real quick-like, but I guess that goes without saying in that kind of work in that kind of area.
Have fun!
If you're a anti-MS type, then you might rejoice in this decision. Why? Well, because MS is obviously dishing out serious dough to a company you like and support in order to delay releasing the game anywhere else until the XBOX version is released. In the console gaming world, the XBOX really isn't cutting it with the market share they're (not) getting.
;+)
So, to summarize: A company you may hate is propping up a company you love to release the game on a platform they're going to flush on the next console life cycle iteration. (Witness the Dreamcast. Me? Bitter? hmmph)
Net effect: The company you love is going to PROFIT (glad to see *someone* figure out how to do this) at the expense of the company you don't like.
Feel better?
Now, go pre-order a copy of DoomIII or something.
It's hard to get by these days without knowing at least a little bit about how to use a PC.
Well, you're right about that, but it misses the point. The educational value of a computer does not, for the most part, lie in learning how to use the computer for its own sake. A computer is a general purpose information tool and one goal in owning a computer is education. Education can include reading, writing, math, science, social studies, etc. A computer can, to an extent, help with all of those subjects.
Note that an Apple ][ will help you just as much with your math as a PC, as long as the software on each is roughly equivalent.
I do get tired of hearing about school districts that just dropped $250,000 for a brand new computer lab, and then they turn around and lay off teachers then complain about the student:teacher ratio. It doesn't make sense to do that when you consider that they really don't even need the lab.
The above probably set you to thinking about how inadequate an Apple would be to learn computer science subjects. You would be right to an extent, but a lab really sees far more uses than just for computer science education. If the goal is to best serve the majority of the student body, then buying your computer equipment (and by extension the education software) around the needs of your computer science oriented students is a poor choice.