I worked for a company with PHBs above me as far as the eye could see. The word came down to reduce the bug count. Incentives were tied to the bug count coming down. The good news is that bugs were closed. The bad news is that many of those bugs were not fixed. So, yay, goal achieved, I guess, but now we didn't know what was broken, in many cases.
I left without waiting to find out whether there was a perceived drop in quality, with more incentives for filing bug reports, (many of which were closed but not fixed in the first round of incentives).
Among the great revelations of relational databases was the JOIN command. With JOIN, we could save disk space by removing repeated fields like city, state, and ZIP code. By storing this frequently accessed and repeated data in separate tables that can be included in future results through a JOIN, we keep our database tidy and our disks slim. But JOINs can be tricky for some and hard on RAM, and though it's still a good idea to isolate and access data in separate tables through JOINs, there's not as much need to save disk space now that disk drives are measured in multiple terabytes. The space is so cheap that some database designers end up denormalizing their data because the JOINs are too slow.
This is just so wrong. If you store, let's say, city/state/zip redundantly, then you run the risk of having the copies, that should be kept synchronized, diverge. This is especially true in the absence of all-or-none transactions. And not to mention the fact that having to update the "same" datum in multiple places is going to affect performance.
And then there are dumb programmers. I was working on a server product, which could be accessed by a browser. IE something.something used to put up a generic "... or contact Microsoft support" message when the server being contacted wasn't responsive. We were debugging a server, so of course it wasn't responsive. This dummy was seriously arguing with me that the right course of action was to call Microsoft support.
(He wan't a novice. He was experienced, in the sense that he has been pressing buttons attached to a computer for many years. But a dummy.)
Microsoft is becoming AOL. A crappy, proprietary, expensive, unreliable impediment to getting onto the internet. Their applications have plateaued, and open-source desktop and web-based competitors are improving rapidly. They'll hang on longer, but they've begun their long decline.
I suppose writers, spreadsheet jockeys, and developers all have to share the "generic" category, which doesn't seem right.
In the generic category, they are going for cool appearance (interesting materials, backlight) over functionality, key layout, tactile feedback, and durability. How else to explain the complete absence of any "clicky" keyboards? The old IBM keyboards are still available. They are fantastic, I'm using one right now. And there are newer keyboards with similar mechanisms -- I expect that they are very good but I haven't tried them.
BInding a single device to a 2-year contract is nuts. Especially a device as limited as a cell phone or netbook.
The iphone, for example, is very cool, but I'm just not interested at $70/month. Yet I pay more than that for my tv/phone/internet connection at home. I'm OK with that because at home I have flexibility -- I can attach as many phones and computers as I want.
I'm sticking with my pay-as-you-go, featureless cell phone until there's an expensive contract that gives me a lot more flexibility.
"robots can provide not only a sense of being a 'buddy' by playing soothing music or providing other entertainment."
Yes, if I'm pinned in a car wreck and bleeding to death, I would like nothing more than to listen to muzak and hear a recorded voice urging me to be patient.
What I want is my 1TB USB keychain (or iphone) to have my favorite OS, apps, and all my data, and to be able to plug it into CPU/keyboard/mouse/display/diskless/OSless stations in airplanes, cafes, hotels, etc.
The various Linux-on-a-thumbdrive distributions and products are a step in the right direction. What we really need now is for vendors to design stations that these doodads can plug into.
Look, I know everyone is saying the same thing, but sometimes, you know, you've just got to express yourself.
This has got to be the absolute worst computer I've seen since the Adam. That keyboard is insanely ill-conceived -- the key layout, the split, the two big buttons idea. The display is horrendous. I've seen that sliding window idea on laptops and it really just completely sucked. Horrible. And it's just about the ugliest laptop I've ever seen.
An abortion.
Dreck.
Awful.
How sad that someone devoted all this time and money to such a piece of crap.
I took two graduate compiler courses from Prof. Dewar at NYU in the late 70s, which had a huge influence on me. First, he was a great teacher -- passionate about his subject, very knowledgeable, and drawing on long practical experience. Second, he was one of the authors of SPITBOL (Speedy Implementation of Snobol), the best implementation of my favorite language of the day. A really unique, very elegant language. Third, he was involved in the design of a research language, SETL, in which sets were a primitive type. Fourth, SETL was the jumping off point for his lectures on macro compiler optimization, which were expressed in concise, elegant set expressions. And he had his students visit and talk about using SETL to optimize itself. His courses were one of the great learning experiences of my life.
Linux was my desktop for several years, after leaving Windows. But I got tired of spending evenings getting audio and video to work, Fink lets me run a good amount of open-source software under OS X (e.g. postgres), I have Linux either onboard (via Parallels) or ssh, and OS X runs X windows. And the hardware is just so gorgeous.
Breaking a query into pieces and evaluating them at nodes containing a subset of the database has been written about since the 1970s. I read about it in grad school back then. Whether that's actually the thing actually patented by jarg is an entirely separate question. If it is, the PTO has screwed up once again. If it isn't, then perhaps there is a deeper similarity that TFA isn't describing.
I've been "stuck" at the architect level for 10 years now. Several years ago, I was considering going into management, to eventually become a VP of engineering. But I really enjoyed the hands-on work, and really loathed the management work -- schedules, resources, reviews, hiring,.... I thought about this for many months. I finally talked to my boss about it. He made a very good point that decided the issue for me once and for all. He pointed out that if I didn't really enjoy being a manager, I would be awful at it, and that would make me miserable.
I realized I have something I'm good at and really enjoy doing. In the interest of not spoiling a good thing, I decided to stay a techie and I've been very happy with my choice.
Are you really sure you want to make this transition?
No, I get that, my point is that a hash table with collisions is probably just fine. Another responder mentioned the use of perfect hashes to avoid collisions when looking for reserved words in a parse. That application makes sense, but again, I really wonder if perfect hashing is worth the trouble. Does it really provide a noticeable performance improvement over an out-of-the-box hash table?
Perfect hash functions are curiosities. If you have a static set of keys, then with enough work you can generate a perfect (i.e. collision-free) hash function. This has been known for many years. The applicability is highly limited, because you don't usually have a static set of keys, and because the cost of generating the perfect hash is usually not worth it.
Gperf might be reasonable as a perfect hash generator for those incredibly rare situations when the extra work due to a hash collision is really the one thing standing between you and acceptable performance of your application.
I thought maybe we were seeing a bad writeup, but no, it's the authors' themselves who talk about the need for high-performance command-line processing, and give the performance of processing N arguments as O(N)*[N*O(1)]. I cannot conceive of a situation in which command-line processing is a bottleneck. And their use of O() notation is wrong (they are claiming O(N**2) -- which they really don't want to do, not least because it's wrong). O() notation shows how performance grows with input size. Unless they are worrying about thousands or millions of command-line arguments, O() notation in this context is just ludicrous.
I don't know why I'm going on at such length -- the extreme dumbness of this article just set me off.
The researchers managed to transfer data at intervals of about 40 femtoseconds, or quadrillionths
of a second, about 100 times faster than conventional magnetic transfers
That optimizes a tiny part of the problem. There are two mechanical issues, 1) waiting
for the right part of the disk to rotate under the read/write head, and 2) arm motion.
Without eliminating one or both of these delays, I don't see how this leads to faster secondary
storage access in practice.
I listen to MP3s exclusively, but buy only CDs because:
CDs are higher quality than MP3s.
They serve as another layer of backups.
I can rip them to whatever level of quality I want and get DRM-free music.
Buying individual tracks, I'd miss some great music. CDs are full of unappreciated gems. There's often a lot of filler, of course, but the obscure tracks make it worthwhile.
I've been building software at startups for 20 years, averaging 5 years/company. It takes a long time to get a large, interesting piece of software right, and you have to stick with it through a few releases. When I interview people, I definitely look for someone who understands all this, and has proven that he can write code, debug it, support it once it's in customers' hands, improve it, and keep it maintainable across all this. I'll almost always discard a resume from someone who doesn't have any job lasting more than a year.
If you want to spend your career writing a long list of uninteresting, trivial apps, yes, you'll do well during the good times. But I personally wouldn't find such a career very satisfying, and I believe that when hiring dries up, you'll be at a disadvantage. There will be thousands of candidates with essentially the same resume.
If you want to do interesting, satisfying work, I think you have find a project that floats your boat and then stick with it for a few years. And your resume will definitely stand out from the competition.
I don't think you can actually choose one path or the other. Maybe you relish the fast pace of a new project every few weeks or months. If on a larger project, you find that you're bored to tears "doing the same thing" every day, then it just isn't for you.
Sorry, but no. I upgraded to FC4 to FC5 and my soundcard stopped working.
And configuring a Linksys wireless card on my Dell laptop is still beyond me. I know what I'm doing, but haven't been able to debug this. It doesn't get much more vanilla than Dell + Linksys.
If this stuff doesn't just work, then Linux is just not ready for the average desktop.
24 is amusing on this point. They obviously have someone who knows something provide jargon. But then it gets translated into near-gibberish. Nearly every episode has Chloe "opening a web socket", or Tony will ask someone to "send it to my screen". It's nonsense, but you can see where it came from.
Kids used to do a DOS on toilets. They'd arrange for all of the toilets in a school to be flushed at once. Maybe they got suspended. But DOS-ing a school web site results in a felony charge? Jail?
Slashdot Mirror
I worked for a company with PHBs above me as far as the eye could see. The word came down to reduce the bug count. Incentives were tied to the bug count coming down. The good news is that bugs were closed. The bad news is that many of those bugs were not fixed. So, yay, goal achieved, I guess, but now we didn't know what was broken, in many cases.
I left without waiting to find out whether there was a perceived drop in quality, with more incentives for filing bug reports, (many of which were closed but not fixed in the first round of incentives).
So, basically, a NoSQL database.
Among the great revelations of relational databases was the JOIN command. With JOIN, we could save disk space by removing repeated fields like city, state, and ZIP code. By storing this frequently accessed and repeated data in separate tables that can be included in future results through a JOIN, we keep our database tidy and our disks slim. But JOINs can be tricky for some and hard on RAM, and though it's still a good idea to isolate and access data in separate tables through JOINs, there's not as much need to save disk space now that disk drives are measured in multiple terabytes. The space is so cheap that some database designers end up denormalizing their data because the JOINs are too slow.
This is just so wrong. If you store, let's say, city/state/zip redundantly, then you run the risk of having the copies, that should be kept synchronized, diverge. This is especially true in the absence of all-or-none transactions. And not to mention the fact that having to update the "same" datum in multiple places is going to affect performance.
Heh heh heh.
And then there are dumb programmers. I was working on a server product, which could be accessed by a browser. IE something.something used to put up a generic "... or contact Microsoft support" message when the server being contacted wasn't responsive. We were debugging a server, so of course it wasn't responsive. This dummy was seriously arguing with me that the right course of action was to call Microsoft support.
(He wan't a novice. He was experienced, in the sense that he has been pressing buttons attached to a computer for many years. But a dummy.)
Microsoft is becoming AOL. A crappy, proprietary, expensive, unreliable impediment to getting onto the internet. Their applications have plateaued, and open-source desktop and web-based competitors are improving rapidly. They'll hang on longer, but they've begun their long decline.
I suppose writers, spreadsheet jockeys, and developers all have to share the "generic" category, which doesn't seem right.
In the generic category, they are going for cool appearance (interesting materials, backlight) over functionality, key layout, tactile feedback, and durability. How else to explain the complete absence of any "clicky" keyboards? The old IBM keyboards are still available. They are fantastic, I'm using one right now. And there are newer keyboards with similar mechanisms -- I expect that they are very good but I haven't tried them.
BInding a single device to a 2-year contract is nuts. Especially a device as limited as a cell phone or netbook.
The iphone, for example, is very cool, but I'm just not interested at $70/month. Yet I pay more than that for my tv/phone/internet connection at home. I'm OK with that because at home I have flexibility -- I can attach as many phones and computers as I want.
I'm sticking with my pay-as-you-go, featureless cell phone until there's an expensive contract that gives me a lot more flexibility.
"robots can provide not only a sense of being a 'buddy' by playing soothing music or providing other entertainment."
Yes, if I'm pinned in a car wreck and bleeding to death, I would like nothing more than to listen to muzak and hear a recorded voice urging me to be patient.
What I want is my 1TB USB keychain (or iphone) to have my favorite OS, apps, and all my data, and to be able to plug it into CPU/keyboard/mouse/display/diskless/OSless stations in airplanes, cafes, hotels, etc.
The various Linux-on-a-thumbdrive distributions and products are a step in the right direction. What we really need now is for vendors to design stations that these doodads can plug into.
Can someone please remind me how they differ?
Look, I know everyone is saying the same thing, but sometimes, you know, you've just got to express yourself.
This has got to be the absolute worst computer I've seen since the Adam. That keyboard is insanely ill-conceived -- the key layout, the split, the two big buttons idea. The display is horrendous. I've seen that sliding window idea on laptops and it really just completely sucked. Horrible. And it's just about the ugliest laptop I've ever seen.
An abortion.
Dreck.
Awful.
How sad that someone devoted all this time and money to such a piece of crap.
Whoever invented this is the anti-Steve.
I took two graduate compiler courses from Prof. Dewar at NYU in the late 70s, which had a huge influence on me. First, he was a great teacher -- passionate about his subject, very knowledgeable, and drawing on long practical experience. Second, he was one of the authors of SPITBOL (Speedy Implementation of Snobol), the best implementation of my favorite language of the day. A really unique, very elegant language. Third, he was involved in the design of a research language, SETL, in which sets were a primitive type. Fourth, SETL was the jumping off point for his lectures on macro compiler optimization, which were expressed in concise, elegant set expressions. And he had his students visit and talk about using SETL to optimize itself. His courses were one of the great learning experiences of my life.
Linux was my desktop for several years, after leaving Windows. But I got tired of spending evenings getting audio and video to work, Fink lets me run a good amount of open-source software under OS X (e.g. postgres), I have Linux either onboard (via Parallels) or ssh, and OS X runs X windows. And the hardware is just so gorgeous.
Breaking a query into pieces and evaluating them at nodes containing a subset of the database has been written about since the 1970s. I read about it in grad school back then. Whether that's actually the thing actually patented by jarg is an entirely separate question. If it is, the PTO has screwed up once again. If it isn't, then perhaps there is a deeper similarity that TFA isn't describing.
I've been "stuck" at the architect level for 10 years now. Several years ago, I was considering going into management, to eventually become a VP of engineering. But I really enjoyed the hands-on work, and really loathed the management work -- schedules, resources, reviews, hiring, .... I thought about this for many months. I finally talked to my boss about it. He made a very good point that decided the issue for me once and for all. He pointed out that if I didn't really enjoy being a manager, I would be awful at it, and that would make me miserable.
I realized I have something I'm good at and really enjoy doing. In the interest of not spoiling a good thing, I decided to stay a techie and I've been very happy with my choice.
Are you really sure you want to make this transition?
No, I get that, my point is that a hash table with collisions is probably just fine. Another responder mentioned the use of perfect hashes to avoid collisions when looking for reserved words in a parse. That application makes sense, but again, I really wonder if perfect hashing is worth the trouble. Does it really provide a noticeable performance improvement over an out-of-the-box hash table?
Perfect hash functions are curiosities. If you have a static set of keys, then with enough work you can generate a perfect (i.e. collision-free) hash function. This has been known for many years. The applicability is highly limited, because you don't usually have a static set of keys, and because the cost of generating the perfect hash is usually not worth it.
Gperf might be reasonable as a perfect hash generator for those incredibly rare situations when the extra work due to a hash collision is really the one thing standing between you and acceptable performance of your application.
I thought maybe we were seeing a bad writeup, but no, it's the authors' themselves who talk about the need for high-performance command-line processing, and give the performance of processing N arguments as O(N)*[N*O(1)]. I cannot conceive of a situation in which command-line processing is a bottleneck. And their use of O() notation is wrong (they are claiming O(N**2) -- which they really don't want to do, not least because it's wrong). O() notation shows how performance grows with input size. Unless they are worrying about thousands or millions of command-line arguments, O() notation in this context is just ludicrous.
I don't know why I'm going on at such length -- the extreme dumbness of this article just set me off.
Sorry if I wasn't clear -- I was responding to the slashdot writeup, not to the researchers (obviously)
or the article.
That optimizes a tiny part of the problem. There are two mechanical issues, 1) waiting for the right part of the disk to rotate under the read/write head, and 2) arm motion. Without eliminating one or both of these delays, I don't see how this leads to faster secondary storage access in practice.
I've been building software at startups for 20 years, averaging 5 years/company.
It takes a long time to get a large, interesting piece of software right, and you
have to stick with it through a few releases. When I interview people, I definitely
look for someone who understands all this, and has proven that he can write code,
debug it, support it once it's in customers' hands, improve it, and keep it maintainable
across all this. I'll almost always discard a resume from someone who doesn't have
any job lasting more than a year.
If you want to spend your career writing a long list of uninteresting, trivial apps,
yes, you'll do well during the good times. But I personally wouldn't find such a career
very satisfying, and I believe that when hiring dries up, you'll be at a disadvantage.
There will be thousands of candidates with essentially the same resume.
If you want to do interesting, satisfying work, I think you have find a project that
floats your boat and then stick with it for a few years. And your resume will definitely
stand out from the competition.
I don't think you can actually choose one path or the other. Maybe you relish the fast
pace of a new project every few weeks or months. If on a larger project, you find that
you're bored to tears "doing the same thing" every day, then it just isn't for you.
Sorry, but no. I upgraded to FC4 to FC5 and my soundcard stopped working.
And configuring a Linksys wireless card on my Dell laptop is still beyond me. I know what I'm doing, but haven't been able to debug this. It doesn't get much more vanilla than Dell + Linksys.
If this stuff doesn't just work, then Linux is just not ready for the average
desktop.
If computer science isn't about computers, what is it about?
I agree, but Dijkstra said: "Computer science is no more about computers than astronomy is about telescopes."
24 is amusing on this point. They obviously have someone who knows something provide jargon. But then it gets translated into near-gibberish. Nearly every episode has Chloe "opening a web socket", or Tony will ask someone to "send it to my screen". It's nonsense, but you can see where it came from.
Kids used to do a DOS on toilets. They'd arrange for all of the
toilets in a school to be flushed at once. Maybe they got suspended.
But DOS-ing a school web site results in a felony charge? Jail?