The thing about cars is that they can kill or maim. _Far_ more people die or end up crippled in car accidents yearly than died in the 9/11 terrorist attack. More die or end up crippled in car accidents than in violent crimes.
That's why those laws are there, and that's why those cameras are there. I'd hardly discount that as "enforcing laws that are easily mechanized, not laws that are most critical to public safety." It _is_ critical to public safety, and if it can be easily mechanized, I for one am all for it.
And here's my take on all those "waah, the police is evil because they don't let me go 'only' 20mph over the speed limit" morons: do the maths folks.
Kinetic energy is proportional to the _square_ of the speed. Friction however can only dissipate that energy _linearly_ with the braking distance. So the braking distance is increases literally with the _square_ of the speed.
A 40% increase in speed _doubles_ the braking distance.
Here's a _fact_: if you have two identical cars, car A going at 50 km/h (the speed limit in cites here), and car B doing 'only' 70 km/h, car B needs _double_ the braking distance to stop. In fact, at the point where car A stopped, car B is still going at 50 km/h.
So when that moron goes at 20mph out of parking, or when that idiot jock on the bike goes in front of you, the 50 km/h car might stop and save a human life where the 70 km/h will kill or cripple.
And for what?
Most of the time streetlights are synchronized anyway. Someone who obeyed the speed limit will just go through the streetlights with less stress (on themselves _and_ the car), while the 70 km/h macho cretin will just have to brake and accelerate all the time... and still not get home any faster.
So all that endangering others' lives was for... nothing whatsoever.
So here's my take. Forget revenue generation. I'd like to see some public executions. Yes, I'm talking death penalty. Have them swinging by the neck from the streetlight pole. That would serve as a better warning to others than the cameras.
Very good advice, but if I'm allowed two minor comments:
1. Personally I wouldn't say that trimming the serialized form is breaking OO design. The way I see it, even OO itself is built upon the concepts of "class" and "instance". The instance doesn't have a complete copy of the class's code, nor the constants, but just what's different: the actual variables. For the rest, there's the pointer to the actual class code.
Dunno, I found it just natural to apply the same thinking to serializing objects, game or no game. E.g., if in the game you have an upgradeable H&K MP5 SMG, I'd think of it as "a weapon object with a mile long list of stuff like range, burst size, etc" but rather as "an instance of the H&K MP5 SMG 'class'".
Well, not a "class" in the sense of a code block, but a game object definition "class". There is a master definition of a H&K MP5, and the actual objects in the game are instances thereof. All that needs to be saved is what can be _different_ from the master object: ammo remaining in clip, upgrades (e.g., a silencer), status (e.g., if it's jammed) and such. For the rest, there's a pointer (or id) to the master H&K MP5 "class".
E.g., for the RTS example, you can treat the map as a "class", and only need to save what can be different from that definition. E.g., buildings.
Seems to me like it cuts down the saved size a lot, without breaking OO design at all. In fact, it's IMHO just a natural extension of it.
2. In all that comment, you haven't actually proven his professor wrong. In fact, if anything, your approach just says that his professor _is_ right and he is wrong.
Blindly saving a block of global variables, which is what he wanted to do, just prevents all those optimizations. _And_ almost prevents versioning.
What I'm trying to say is that, ok, his professor is technically wrong about the "never ever" part, but it's still not a bad thing to teach those students. Even if one ends up cutting corners, it's better to start with a good idealized design and then cut corners, than to start with an unstructured turd and try to polish it.
It's easier to implement those good optimizations you've written there, when one starts from a good OO design, than when one starts with a block of global variables written en masse to disk.
E.g., the trimming of data is actually quite easy to do when each kind of object is a class that knows what it can trim. (E.g., a weapon class can know what upgrades a weapon can have, compared to the master definition, while a map class can know that scorch marks aren't needed.) Whereas if one started with a huge block of global variables, implementing those optimizations will mean rewriting most of it from scratch.
Let me tell you a story: I've actually written game engines, in the days of Doom, before accelerated 3D graphics cards were anywhere near common. I've actually had to optimize stuff lots.
You had to calculate and paint every pixel in a 320x200 pixel image. Assuming an overdraw factor as low as 2, that's 128,000 pixels written per frame. You want 30 frames per second? Good, that's some 3,740,000 pixels drawn per second.
So you wrote assembly, counted cycles to optimize by hand, and unrolled loops by hand like there's no tomorrow. Yep, that was a different beast. (It was also fun.)
But here's the other side of the coin: optimizing stuff that's _not_ the bottleneck is just plain old stupid. "Optimizing" it in a way that ties your hands in another area, is double-plus stupid.
And "optimizing" without even measuring is downright lobotomized. _The_ worst code, including worst performing, code I've seen so far was invariably code that someone thought they "optimized" but never measured it. You'd be surprised in how many ways reality can differ from what you think as "the fastest way."
E.g., at one point we thought that getting rid of compression for the resources (ought to speed level loading up. I mean, it's logical enough, right? You save the time to decompress those files, right?
Turns out that it actually loaded faster with the compression in place. The CPU time saved for decompression was actually a spit in the bucket compared to the extra time used by the HDD to read the uncompressed data. Go figure.
So to get back to the topic at hand, I find the claim _very_ suspect that saving a raw block of RAM is needed nowadays.
It has a _ton_ of disadvantages, it's fragile, and for what? Even if we're talking coding for a console and their slow memory cards (in fact _especially_ for consoles) a well written serialization can actually write less data than blindly dumping a huge static block where you pre-allocated the largest arrays you can possibly ever need during the game.
All your 5 points are very insightful, but if I may be allowed to add one from experience:
6. Blindly writing a block of memory prevents using _any_ kind of pointer, not just virtual function table pointers. _Any_ kind of a linked list, hash table, dynamically sized array, etc, suddenly becomes taboo.
For example, how's a fixed memory block going to accomodate the inventory in an RPG? Have a fixed buffer for every single object in the game, for example, saying how much of each you've got?
Sounds good until you realize that this prevents any kind of mod, and you can't even make an official expansion pack that doesn't require starting the game from scratch. You can't add a new object, because you don't have space for it in that fixed buffer.
Oops.
How about objects that take modifications? E.g., a rifle that can be added a sniper scope, or a pistol which can take a silencer? Or a SMG that can take _both_? Suddenly you can't just add a linked list that points at the augmentations added, because those don't work well with the save-whole-memory-block technique.
No offense, but you seem to make two of them yourself.
1. Basically "if we don't have 100% consistency, we should go for 0% instead". Or, if you will, "bah, you already had a change of look-and-feel some 5 years ago, so suck it up and accept one daily, for each program."
Sorry, no. The real world isn't that clear-cut black-and-white. Sometimes you have to settle for "good enough" instead of "perfect".
2. More importantly, the underlying fallacy is "looks are all that matters." Seein' as what you came up with is flat buttons or different icons.
And that's not just a fallacy, it's also _the_ number one _failure_ of GUIs designed by programmers, graphics artists, marketting, etc. (Though each of them for very different reasons.) Generally anyone else who really has _zero_ clue about usability, and just thinks anything graphical will do.
What I'm more concerned with isn't "waaah, but they changed the 'new folder' icon in XP!" I'm more concerned with how things work. Which is why my point explicitly said "reusing skills" not "reusing graphics."
Take the Windows file open dialog for example. Sure, some apps might add a preview field next to it, or a couple of extra fields, but by and large it stayed the same since Windows '95. You can still do the same things (e.g., creating or renaming a folder right in the list), in the same way, in all apps that use it.
The important thing is: Once you've learned to use it once, you can do it mechanically, without even thinking about it. Even if you just bought/downloaded/compiled/whatever a brand new app, you already know how its file dialog works. That's one less thing to go through a learning curve about.
Now kindly open a GTK dialog box in Windows. E.g., open a file in Gimp. Ugh. WTF is that box? What was wrong with the "normal" box, that needed replacing? Or try it with a Swing app. Ugh. Why does everything look and act differently?
Try to answer those questions _without_ going into technical details about widget sets and libraries. Pretend I'm Joe Average, who doesn't even know what GTK is. And more importantly, who doesn't _care_ about such details. I just want to use the program, with a minimum of learning curve or thinking.
What was wrong, from a _functionality_ point of view, with the old dialog? What end-user functionality absolutely wasn't available through it, so that it needed a completely different dialog?
Writing perfectly portable code is possible, but as they say "there ain't no such thing as a free meal." Let's take your DirectX vs OpenGL example, just as a random example, to illustrate the problems.
1. It costs extra time and money.
And it costs time and money to also _test_ it on the new platform. Otherwise you won't even know what functions don't exactly work the same. Or you won't even know that the widget sizes are different on the other platform, and the whole GUI is a disfunctional piece of junk with truncated texts and buttons falling completely out of the dialog box.
(Writing the code is not the alpha and the omega, as you undoubtedly already know. Testing and debugging can easily account for 10 times more time.)
The promised DirectX-vs-OpenGL example: Now _Direct3D_ is pretty much an equivalent of OpenGL. No, not the same function calls, but you can get the same results.
But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.
2. Performance problems, here we come.
Of course, you could just use a wrapper that encapsulates, abstracts and emulates everything. Proper software engineering, right? The problem is: it costs performance.
DirectX-vs-OpenGL fits nicely here too: as fate would have it, Matrox already tried handling that via a wrapper. Back in the days of the G100 and G200, Matrox thought the're smart. No use writing two different 3D libraries that do the same, right? So they actually wrote their OpenGL implementation as a wrapper around DirectX.
The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.
Just in case you wonder why no games are written using one of those wrapper libraries, now you know why. Because noone wants to make a game that looks like classic ass (low polygon count) or gets single digit FPS. Or both.
3. Those pesky users.
There's one thing that all these emulation and one-lib-to-rule-them-all apologists just don't get: reusing existing skills is good.
When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app. No, I don't want it to look like Swing, I don't want it to look like QT, and I sure don't want Mozilla's skinned idiocy, and I'm gonna puke if I have to use another idiotic GTK file dialog in _Windows_, etc. I want it to look and _act_ exactly like one thing: the Win32 widgets. Nothing else.
And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.
It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.
Believe it or not, that was the whole fundamental difference I was talking about between 100 lines and 100,000 lines. At 100,000 lines you have to have clearly defined structure, clearly separated modules modules and clear interfaces to find your own ass with a map and a compass.
So you're arguing... what? That you want to call "programs" what I call "modules"? Sure, fine by me. As long as it still walks like a duck, and quacks like a duck... Then what I meant is "a 100,000 line _project_" (composed of more of those things you call "programs") instead "a 100,000 line program."
That surely noone but you can write a subroutine? Bit of an arrogant assumption, isn't it?
Well, we can easily aggree that _most_ people hired as "programmers" nowadays don't have that skill. A study here said that only about 1 out of 4 programmers can program at all. Writing a _structured_ program/project/module/whatever-you-wanna-call-it, obviously even fewer.
But assuming that basically _everyone_ but you can't possibly write a subroutine... well, that's a helluva lot more arrogance even than _I_ have. And god knows I'm a pretty arrogant bastard:P
"You learn software engineering by not writing 100,000 line programs."
is at most another fine example of hubris. If you never wrote programs that had to go over 100,000 lines of code, mighty fine for you, but that's hardly something you can make into a rule.
Some programs never have to be that large, true. E.g., most web applications. On the other hand, other stuff _has_ to grow 10 times larger by sheer scope of the problem to be solved.
E.g. if you think you can write something like MS Office or OOo in 10,000 lines of code, you've got to be kidding.
E.g., even as intranet programs go, not all the world means basically a simple bulletin board. One Swing application we coded had to cover basically the whole range of database stuff the company employees had to do.
Including a _ton_ of forms: each frame was a tab pane with at _least_ five different forms. No, not a wizard with 5 simple pages, but actually 5 full forms, a lot of them with tables and filters in them. The data model objects alone accounted for a lot more more than 10,000 lines. Data validation adds more than that too. Add some data entry helpers too: for example finding the Zip code or region by city, or viceversa.
And including reports with templates they can edit themselves, previews, statistics (think: data mining) over that data, etc. And a completely customized look and feel, with bitmaps splatered across the tabs, and custom shapes for every control. (One of the company directors was an ex-graphics-artist. They like visual stuff.)
Now also add more internal stuff like custom caching of the database data. Heck one module even took apart basic SQL statements for the tables, and added the filters, the fetching only a certain row range, etc, and optimized the result for Oracle based on some rules and lots of experimenting. Because the users don't want to wait ad nauseam to scroll through 3 million records in a table.
Sure, you can split it all into modules, you can reuse code or libraries, etc. In fact, at that complexity level you _must_. All mighty fine practices, and all helpful, no doubt. But no ammount of engineering, and no language ever invented, will keep that under 100,000 lines.
If that's what you think, you might be in for a _very_ nasty surprise at some point.
That nobody at the workplace cares about you in a good way, that's probably not a bad frame of mind. Cynical, that's true, but most of the time it's accurate.
But you might be surprised who cares about you in a _bad_ way. Who's out on a personal quest to prove to the boss that your code is utter crap and you should be fired. Or at least he should be promoted before you.
I've already posted one such true story on Slashdot (I fondly called it "Jack and Jill up corporate hill), where a marketeer-turned-programmer I know (and to my shame, which I've helped get into programming) made it a personal quest to get both female programmers on his floor fired. He succeeded too.
He'd run with snippets of those programmers code to every single guy in the building, to show everyone what bad code they wrote. Invariably he was wrong, and just showed _massive_ incompetence, and their code was good. He didn't even know the most elementary _basics_ of Java, the language he's paid to program in. But obviously it wasn't obvious to the boss, seein' as he did get them both fired, and he got promoted.
A more sad case was someone who couldn't program at all. No, not just "not a top programmer." He just couldn't write code that even compiled. At all.
So a couple of co-workers took pity and started helping him. Well, not as much "helping", as outright writing his modules for him.
So what does he do? Make it his personal quest to bad-mouth them to the boss behind their backs, and "prove" that they just interfere with his work and he surely would have done better if they hadn't edited his files. (Never mind that he had actually asked for their help to start with.)
There's one important lesson in corporate cynicism there, grasshopper. The person you helped might be not a friend, and not even indifferent: you might have actually made an _enemy_. You're one of those who know he's incompetent, and that makes you dangerous. Worse yet, you might be seen as a good programmer, and as such in his mind (and usually _only_ in his mind) someone who might get promoted before him. You're an obstacle to be taken out of the way.
Aggreed. That's exactly the difference and phenomenon I was talking about.
I left a larger interval there because everyone has their own limits. The point where I myself actually noticed that I was swapping something out of my brains each time I was swapping a new module in, was around 13,000 lines. Probably it had started earlier, though, and the 13,000 line mark is just were it got to _really_ bug me.
Piling tons of extra work upon your programmers, and unrealistic deadlines, comes back to bite you in the ass in various forms. Of course, a true PHB won't see it, and can pat themselves on the back for "getting the most out of the people". When in fact they're getting the least.
1. Bad code.
The thing about programming is that there's at least 20 ways to achieve anything. About 18 of them involve cutting corners and making a bad product, just to keep that unrealistic schedule the boss gave you.
Making and implementing a good design takes time. Throwing together a piss-poor Write-Only hack takes a lot less time. Guess which one you get if you just mindlessly pile more work on people.
Sure, it looks like you're getting some extra work done at first... until it's time to debug or maintain it. Then you start finding gems like "oh dear, instead of making a proper connection manager class, they've just directly accessed and _changed_ internal variables in other modules and got their connection from there." Any change suddenly involves a lot more work, because instead of a clear orthogonal design, it's a spaghetti mess.
Oops. It bit you in the ass.
(And so far _twice_ I've not only encountered such messes, but had to deal with them because even the original coders didn't want to touch it any more.)
2. Lack of test cases, or even of manual testing.
_The_ more common excuse for lack of that is that there's no time for it. Pile enough work on someone to give them the idea "hmm... I could still make it if I dropped the test cases", and those will be the first to go.
And it only makes problem 1 suddenly cost 10 times more time. Because not only you never know which other module messes with the innards of your class, you can't even tell if you broke something when changing it.
True personal story: oops, changing the table model also caused all the reports to stop working. And it was only found after we delivered it to the client.
True personal story: oops, the program was packed by an overworked coleague with the test templates instead of the real templates. Some real business partners got bullshit emails as a result. (If you thought MS's inapropriate comments in code were fun, emailing stuff is more fun.)
3. Tired people are stupid people. (Not meant as an offense. I'm stupid when extremely tired too.)
Every notch you go above someone's limit, and every hour of overtime they have to do for more than 1-2 weeks in a row, soon starts reducing their productivity. They make more mistakes. They need more time to find them and to fix them. They see less of the picture, so each fix is more likely to break something else.
4. Lowered morale also lowers productivity dramatically.
Nerds are a funny breed. If you overworked a factory worker, they'd be more likely to tell you "no, sorry, this is as far as I'll go." Or just do as much as they can, and pack their bags cheerfully when the clock struck 5 PM.
Nerds tend to be more insecure. A lot are autistic too, so they can't even tell how bad or not bad the situation is. They'll go beyond their physical limits, rather than risk disappointing the boss.
Unfortunately, as they say, "there ain't no such thing as a free meal". The extra effort comes at the cost of tiredness and lowered morale. Either of which alone can count for up to an order of magnitude productivity, if brought to extreme levels.
Why engineers want info up front can be broken up roughly into the following problems. Usually it's a combination.
1. Bad management.
It's more common than you think to be blamed for not reading the client's mind. (You should have just known that when they explicitly wrote "save when exitting every field", they actually meant "we don't want the info to disappear, but we don't really want disk access every time we hit TAB." Whatever gave them the idea that info just disappears in a form. It's your fault when they come back complaining about performance.)
Or when it's not outright "you're to blame, you horrible monster", it's being asked to do overtime to "fix" it. Because the boss is too weak to tell a big client that those changes cost extra time to implement.
I can tell you that it doesn't take more than 1-2 such projects, to give one the idea "no, you don't. Not again. Give me a good spec up front this time." Because anything short of a full spec simply comes back to screw you with a chainsaw lately.
2. Bad management again: changing the same thing back and forth, just because the client can't make up his/her mind.
It's been said that the most depressive thing you can do for example to a prisoner is to just make him do not something that's hard work, but something that's obviously _useless_. Such as asking the prisoners to move a big pile of sand from here to there, and then back to the same point. That "I'm doing useless stuff" thought saps someone's self-esteem and ultimately even health faster than if you tortured them or made them break rocks with a pickaxe.
And the same applies to software projects.
I've _actually_ been in one project where for a whole _year_ the client manager couldn't make up his mind whether he wants the reports landscape or portrait. Never mind that the program included a report designer, where he can lay them out in whatever goddamn way he needs. No siree, bob. He's not gonna accept the program until the reports are landscape... then portrait... then landscape again... then portrait again. Repeat ad nauseam. For a year.
Going through something like this will make it _very_ tempting to say "screw this, I want a signed spec up front".
3. Bad design.
Most programs are basically Write-Only. People give no thought to maintenance later, and even the smallest change means rewriting half the stuff.
Now I'm not a fan of extreme programming as such. (And please, if anyone feels like taking it as an opportunty to preach, have mercy and spare both my time and yours.) But I do think that they did get the basic ideas right. (It's just the turning it all to the max that I disaggree with.) Programs should be written to be easily changed.
4. Lack of test-cases.
That's probably the worst anti-pattern. So you most often have not only a spaghetti program that's hard to change, but it's not even possible to be sure you didn't break something else.
I doubt that anyone would place comments in code that basically boil down to "I hate my job and my employer." At the next code review, or the next time a bored coleague looks into your code, it's just begging to be used against you.
If comments about the company or other co-workers are present, they'll more likely be a lot milder and kept to something you can sorta justify as just documenting code behaviour. E.g., "this is a work-around for Bug X in Function Y of the MSFC".
On the other hand, there is plenty of room for utterly inapropriate comments about other companies and products. Think along the lines of "unlike the utter crap we took from the BSD monkeys, this one is 40 times faster and uses 10 times less memory." Or "this is here only because the monkeys from are too stupid to do their own buffer checking before calling my function."
Excessive hubris is pretty much part of the job description for nerds. Remember kids, everyone else sucks and is an idiot luser. Only you can possibly know anything at all about computers. And only the skills you have (e.g., pushing the power button or typing "emerge kde") are l33t and cool, the rest is idiot luser stuff.
But my guess is more like MS is just playing defensively. There are a lot of people and has-been companies that are out for MS's blood. Comments that noone minds in the Linux kernel, if found in MS code would get those people screaming for blood and gathering a proper medieval crowd with pitchforks and torches.
I mean, look around. Even a comment as benign as "this is a work-around for bug X in function Y" would get half the MS-bashers on/. screaming and waving it around as definitive proof MS can only write bad code.
Doubly so for those who:
A) never wrote any productive code in their entire life, but think they're uber-l33t because they can run someone else's scripts (e.g., "emerge kde"), or
B) wrote a 20 line program in BASIC once, or a 20 line BASH script, so they think they're qualified to pass judgment about 1,000,000 line projects or about whole languages
(No offense intended to good programmers in either VB or various shell scripts. But there is a _massive_ and _fundamental_ difference between a 100 line program and a 100,000 line program. Stuff that works in the former, like, "bah, I wrote it just as well without all this fancy encapsulation and bogus design", might just cause the latter to never be finished or anywhere near working.)
Nah, I didn't mean I'll start charging them. I mean more like I'll tell them to fsck off, only of course in a _much_ more diplomatic manner.
It's not just about tax return forms, it's that I can do better with my time. Like write a program. Or play a game.
And yeah, I know that some time in the future I'll have a leaking pipe or whatnot. That's what I pay insurance for. It's still cheaper and _far_ more reliable than relying on bartering favours.
It's also that my definition of a friend is somewhat more... demanding, for lack of a better word. A friend is someone who still calls you or emails you some 5 years after you've moved to another town, even if you've never fixed anything for them. Someone who's a "friend" only as long as they can freeload some unpaid service work from you, is IMHO at most "barter" if they actually offer some service of their own in return. Or most often a "freeloader" because they don't really.
And I'm honestly surprised at how many nerds think they're _buying_ friendship. And how they aren't really. There's a whole caste or social strata of people whose main skill is acting like you're their best friend... as long as they can freeload something from you.
And to be entirely honest, this isn't even something new or speciffic to computers. Nerds just tend to be easier scammed that way, but the symptom existed long ago. E.g., people who were your best friend as long as you bought them free drinks, probably existed a few thousand years BC.
I come from a family of computer nerds, so half the family friends were nerds. (Half of the rest were medical doctors.) If there's one thing I had the privilege to witness first hand, it was precisely this kind of a warped "friendship" in action. Dad, for example, spent half his free time basically "having friends" by doing unpaid work for them.
Invariably the "bought" friends, promptly forgot you even existed when you could no longer provide the free service. Invariably the ones who still write and even offer help are the ones who hadn't needed free work to start with. Go figure.
I don't know what area of the world you people live in, and by now I'm curious. Because I thought most of the world has long ago dumped that kind of stone age barter model. We're no longer in the year 2100 BC, people, where the norm was "I'll give fix your thatched roof if you give me a clay pot and two breads", you know.
And, dunno how to say it nicely, but the examples I read are surrealistic. Lemme recap:
- a bottle of whine - a pizza - two beers - a home-cooked meal - an old half-working CD-ROM drive - he'll supposedly come fix my pipe if I ever need it
Etc.
Umm... hello? Are we talking Elbonia or East Bumfuckistan or something?
Because where I live I can just go buy my own bottle of wine, if I ever felt like it. Beer? Well, gee, so I'm suppose to fix a retard's computer for something worth less than 1 Euro? Pizza? I can order my own. Etc.
Dunno about you, but my time is worth more than that. Even if we're talking Indian manual labourer wages (no offense to citizens of India meant, just using it as a generic low wage country), two beers for 1-2 hours of work is a fucking sad joke.
Ditto about services. Dunno, maybe your house was built on an ancient cursed burrial ground, and pipes burst every morning. But where I live I've only needed a pipe fixed once in the last 6 years, and I once locked my keys in the house and needed a locksmith. That's it.
And you know what? It cost cheaper to just call a plumber and a locksmith, than waste hundreds of hours of my time fixing every retard's computer just in case I ever need them.
That's the whole problem with that stone-age barter and favours system, and why the road to real civilization meant dumping it like hot potato: it's bloody inefficient. A few hundreds of hours of my time don't even start to be compensated by "yeah, but I saved some 200 bucks on those repairs." Well, gee, that's like, what? Working for some 50 cents per hour?
It's just sad.
No, thanks. I'll pay for repairs when I need them, and they can call a proper service centre when they need repairs to their computer.
Ah, well, see, I'm just Joe Consumer here, not an investor or anything.
I.e., my concern isn't "how can they make money?" That, I'm sure they already have in mind, yes.
My concern is more along the lines of "are they trying to shaft me?"
Stuff at service level, I don't mind. As far as I'm concerned, if they can actually improve their service to _me_ with that data, I'm all for it. Sure, why not?
Stuff that, on the other hand, boils down to shafting their customers (e.g., by selling data to spammers), I'm against. I _don't_ see this as a legitimate business practice.
Sure, it makes money, but in a predatory way: they make their money at the cost of causing me a loss. Much like mugging does, for example.
In a nutshell, I believe that business is supposed to work in a way that creates value for _both_. E.g., if I'm a baker and you're hungry, buying a bread for me actually creates value for both. You need something to eat now more than you need the money (which you can't eat), while I need some money more than I need one of the tens of loaves I bake per day. That's the kind of transaction that's beneficial for society.
On the other hand, "business" of the kind where one makes their win by causing others a pure loss, I see at most as an abuse of the system. It's no better than theft.
Doubly so for the massively destructive kind of predatory "business". E.g., someone making some 100,000 bucks by selling addresses to spammers, and... contributing to the spam problem that causes 22 _billion_ per year lost productivity in the USA alone. On the whole of society, that's actually a big loss.
Sure, _they_ will probably see it as "bah, it makes us money, that's all that matters." _I_, however, see it as "there ought to be a law against this kind of predators."
Well, I figure I'm savvy enough to use a PC by now, seein' as I've been using and programming computers for some 22 years now.
Still, I like to play with new stuff. I've been considering a Mac, actually, and a few other options. Heck, I've even been considering getting a Sun workstation at home too, just to play with it.
Thing is, until recently, Macs were a bit too expensive. Well, maybe not as such, but you couldn't configure one without a bunch of extras I really didn't want to pay for. E.g., I didn't want to pay for a dual-CPU config to get the fastest CPU. Or I didn't want to pay for Apple's TFT as part of an iMac, since I have a better monitor already.
But now that the Mac Mini finally exists, I just have to get one. I'm just waiting for them to actually be available in an online shop here, that offers the 1 GB RAM option at half of Apple's price. In fact, pretty close to the price of just buying a RAM stick separately. Saves me the bother of opening the case to install it myself.
Yes, I have some vague clue on data mining. I'm not an expert by any means, mind you, but I've been asked to program that kinda stuff before.
What I'm trying to say, though, is that there's a level of granularity beyond which it becomes _trivia_ instead of a statistic.
For example, "How many games did this team win?" is a statistic. Gives you some idea of their performance. "How man games did they win on a rainy tuesday afternoon?" is garbage. It's trivia material, not anything useful.
Ditto for breaking down, say, sales statistics by street. Take for example The Sims, a game which had such an intrusive registration. How does that kind of fine granularity help them make a better game?
Grouping the buyers by country or state, now ok, I can see _some_ point in that. There are cultural differences which will be reflected. Now consider it finely grained, down to street and house number level. "How many people bought our game on Elm Street?" How the heck does that help them make a better game?
No, seriously. I want to know.
"that information has value to others trying to sell stuff to you- Sherman networks knows that you liked SNL with Ashly Simpson- so in theory they could sell your name / address to companies that sell SNL videos"
Bingo. That's why I made the distinction between "legitimate use", as in, stuff they need to provide a better service, and seling that data to spammers. That kind of fine granularity is useless for a legitimate aggregate statistic, but is valuable to spammers. (I do include spammers of the snail mail or phone kind.)
I.e., that detail of data mining just tells me "non-legitimate". It tells me that there was a _dishonest_ mind behind it all. That, yes, they do have a plan, even if a backup plan, to sell your data for money. In one word: lamers.
Unrelated, if Sherman planned to sell data back to the companies in RIAA, they're more stupid than I though. So they're accessories to something illegal, know it's illegal, make a recording of it, and... plan to sell the data to the ones they helped defraud? Geesh. It's last going to a bank and saying "wanna buy a list of your offices I drove robbers to?"
I can only hope that it wasn't their plan, because _that_ kind of massive stupidity would just be depressing.
I'm aware of hashes, yes, but it's still a case of "infinite monkeys on infinite keyboards". Well, more like "a few million monkeys on as many computers." Each will rip it to a different bit rate, set the ID fields differently, etc. Then there are different CDs containing that song. And if they're remastered from tape, god help you with that hash, 'cause even the original digital data _before_ encoding will be slightly different.
As was pointed out before, a bank is expected to be a bit more security minded than that.
E.g., the bank my money is at, first of all needs all online transactions to be validated with a one-time number. You get a pad with maybe 100 such numbers, and each can be used only _once_. That number is thereafter recorded as invalid and can't be used again.
And, oh, you can't do a brute force attack through all combinations either, because after the third failed attempt they lock the account.
So even if someone recorded your keystrokes, and even if they had complete remote control of your computer, they'd have a pretty damn hard time impersonating you and transferring money out of your account online. (Which is what happened to this guy.) Even if they recorded one such single-use number, they can't use it.
There is also a limit on online money transfer per day and per week. They can set it higher or lower for you, but the safeguard exists. _And_ there's a limit on how far below zero the account can get. There is no way in heck someone can just transfer 90,000$ out of my account in one go.
See, that's what real security is about. Thinking _how_ can you prevent something from happening, even if you live in an imperfect world. In fact, _because_ you live in an imperfect world.
E.g., that one-time pad is there precisely _because_ someone might record your keystrokes.
Shrugging and blaming the victim ("If the victim in this case used Microsoft Windows, with all its well-know and well-publicised security flaws, he only has himself to blame.") is the nemesis of security. That-a-way lies just madness and making a piss-poor product.
Well, the recording part is the part that's really sad. It's such massive lack of clue, it's... well, come to think of it, probably standard for management.
And wth is with all these companies and collecting data about their users? Everyone must track you, profile you, and make you go through an intrusive registration just to (for example) download a patch to a product you've bought.
Now I _know_ that you're not really anonymous on the Internet, they can collect a ton of data about you, bla, bla, bla, Sure, they _can_. But do they even have a _legitimate_ use for that data? I.e., one that doesn't boil down to "we can sell the list to spammers later."
Most of the collected data nowadays (and again I don't only mean Kazaa) is plain useless for anything even resembling an aggregate statistic.
E.g., in Kazaa's case can they even do an automated aggregate statistic over the filenames? How? There must be hundreds of different ways to write the same filename, so good luck telling whether more people download Britney Spears or Eminem. Or which genre do people download more. And even if (ad absurdum) they could get an aggregate statistic, what would they do with that data?
E.g., in the case of some companies' intrusive registration forms and out-of-hand data collection, wth are they gonna do with such pieces of trivia as my house number or telephone number? _How_ does one use that in an agregate statistic?
I mean, "How many people bought our product in Europe vs USA?" is a statistic. "How many people with an even house number bought our product?" is at most useless trivia. There is _no_ useful information in there.
Dunno, reminds me of dogs chasing a car. They have no idea what they'd do with it if they caught one, but they just must do it anyway.
"So when are all the diehard M$ fans finally going to get the message"
About the time there will be a real alternative to it.
Fact is, most people aren't really "fans" of any one OS. Noone except the Linux fanboys (been one myself, believe it or not) actually gives a damn about the _OS_. It's like having a flame war about whether brown seat covers are more evil than blue seat covers in a car. It's that stupid.
The OS is just a necessary evil you need to load the _applications_. _That_'s what matters. Most of us could live just as happily without an OS at all, if the apps could be loaded otherwise. No, seriously. The OS is just a necessary evil, no more.
So until Linux actually starts having some more useful apps, it's just not a competitor. It doesn't matter how good the OS is.
So the sad choice really is, do I:
A) get Linux, spend weeks coaking Wine/WineX/CrossoverOffice into running each program. And recompile half the.so libraries on the system in the process. (And don't even get me started about what that means if that app is a copy-protected game _and_ you have an ATI graphics card.)
B) get Linux, spend weeks learning some half-arsed dysfunctional equivalent to even the most common apps, or
C) Get windows.
Took me about two years of messing with Linux (and ranting on newsgroups about how the evil MS will never again see a cent from me) to realize that I was in fact increasingly often giving up and taking route C. Which is to say, booting my Windows partition.
"And I do tend to stay up with security fixes unlike the windows sheeple who's probably running a windows box with a generated serial number"
Ah, the usual "if they don't want Linux for free, they must be running a warezed version of Windows" fallacy. How refreshing. I hadn't read that fallacy in, oh, about two days, and was starting to get withdrawal syndrome;)
Reality is more complex than that. Even by BSA statistics -- and BSA is _paid_ to cry wolf and exaggerate -- piracy isn't _that_ wide spread in the Western world. The fact is, like it or not, most of us have knowingly paid for Windows.
In my case, I can even tell you why I went back to it. Because, as they say, "Linux is for free only if your time is worth nothing." Dunno about you, but if I put even a minimum wage price on my time, Windows has practically paid for itself by now.
"There's no way in hell a windows box can survive long enough to grab and install all the fixes when its been re-imaged by the distribution cd that came with the machine."
Again, yes, there is. Go to the TCP/IP properties, tell IPSEC to allow only outgoing connections. It's been built in at least since NT 4.0, maybe earlier.
No, it's not a full-featured firewall, but it will keep you safe enough while you download the patches.
And here's the fun part: it takes less time than whining about how Microsoft sucks. Now it may not be as fashionable as whining about MS on Slashdot, but it will keep your computer safe.
Because what I've said is that Windows has buit in packet filtering (sort of a poor man's firewall) at least since NT 4.0. Probably even earlier.
So you _can_ connect a computer to the Internet long enough to download the patches _without_ getting virused.
But that would require having a brain. Something that's actually lacking among most of the whining crowd. Because otherwise 90% of the complaints about Windows wouldn't boil down to "I'm too incompetent to configure it."
There are also other solutions, all of which takes less time than whining. E.g., downloading a firewall on your own computer.
For all the geek whining about how Windows sucks, and spending hours in vi and obsolete man pages is fun, you'd think they can at least RTFM.
E.g., you don't even need to buy a router or whatever to keep your Windows safe until you download the patches. Just go to the TCP/IP properties and activate IPSEC.
No, it's not a full fledged firewall, but it'll keep you safe as houses until you download a patch.
Now it's not something that's on the first page or activated by default, but for anyone claiming to be a die-hard Linux geek, here's the deal: it takes less time to fucking look at the IP properties, than to write a whine on a blog or Slashdot.
But, nah, whining about Windows is _fashionable_. It's cool. Makes one feel like one belongs to a big family.
That's the problem. Just reading the docs, or god forbid actually taking the time to configure it right, that's soo unfashionable. Just gets one branded as a "windows luser" or worse. Nah, better let her get virused instead, so we can fashionably whine about Redmond.
*sigh*
Look, folks, I'm not saying windows is perfect. Or even that good. But clueless whining and mis-presenting one's own complete incompetence as definitive proof that Windows sucks, that's just sad. It doesn't even do anyone a favour.
Slashdot Mirror
The thing about cars is that they can kill or maim. _Far_ more people die or end up crippled in car accidents yearly than died in the 9/11 terrorist attack. More die or end up crippled in car accidents than in violent crimes.
That's why those laws are there, and that's why those cameras are there. I'd hardly discount that as "enforcing laws that are easily mechanized, not laws that are most critical to public safety." It _is_ critical to public safety, and if it can be easily mechanized, I for one am all for it.
And here's my take on all those "waah, the police is evil because they don't let me go 'only' 20mph over the speed limit" morons: do the maths folks.
Kinetic energy is proportional to the _square_ of the speed. Friction however can only dissipate that energy _linearly_ with the braking distance. So the braking distance is increases literally with the _square_ of the speed.
A 40% increase in speed _doubles_ the braking distance.
Here's a _fact_: if you have two identical cars, car A going at 50 km/h (the speed limit in cites here), and car B doing 'only' 70 km/h, car B needs _double_ the braking distance to stop. In fact, at the point where car A stopped, car B is still going at 50 km/h.
So when that moron goes at 20mph out of parking, or when that idiot jock on the bike goes in front of you, the 50 km/h car might stop and save a human life where the 70 km/h will kill or cripple.
And for what?
Most of the time streetlights are synchronized anyway. Someone who obeyed the speed limit will just go through the streetlights with less stress (on themselves _and_ the car), while the 70 km/h macho cretin will just have to brake and accelerate all the time... and still not get home any faster.
So all that endangering others' lives was for... nothing whatsoever.
So here's my take. Forget revenue generation. I'd like to see some public executions. Yes, I'm talking death penalty. Have them swinging by the neck from the streetlight pole. That would serve as a better warning to others than the cameras.
Very good advice, but if I'm allowed two minor comments:
1. Personally I wouldn't say that trimming the serialized form is breaking OO design. The way I see it, even OO itself is built upon the concepts of "class" and "instance". The instance doesn't have a complete copy of the class's code, nor the constants, but just what's different: the actual variables. For the rest, there's the pointer to the actual class code.
Dunno, I found it just natural to apply the same thinking to serializing objects, game or no game. E.g., if in the game you have an upgradeable H&K MP5 SMG, I'd think of it as "a weapon object with a mile long list of stuff like range, burst size, etc" but rather as "an instance of the H&K MP5 SMG 'class'".
Well, not a "class" in the sense of a code block, but a game object definition "class". There is a master definition of a H&K MP5, and the actual objects in the game are instances thereof. All that needs to be saved is what can be _different_ from the master object: ammo remaining in clip, upgrades (e.g., a silencer), status (e.g., if it's jammed) and such. For the rest, there's a pointer (or id) to the master H&K MP5 "class".
E.g., for the RTS example, you can treat the map as a "class", and only need to save what can be different from that definition. E.g., buildings.
Seems to me like it cuts down the saved size a lot, without breaking OO design at all. In fact, it's IMHO just a natural extension of it.
2. In all that comment, you haven't actually proven his professor wrong. In fact, if anything, your approach just says that his professor _is_ right and he is wrong.
Blindly saving a block of global variables, which is what he wanted to do, just prevents all those optimizations. _And_ almost prevents versioning.
What I'm trying to say is that, ok, his professor is technically wrong about the "never ever" part, but it's still not a bad thing to teach those students. Even if one ends up cutting corners, it's better to start with a good idealized design and then cut corners, than to start with an unstructured turd and try to polish it.
It's easier to implement those good optimizations you've written there, when one starts from a good OO design, than when one starts with a block of global variables written en masse to disk.
E.g., the trimming of data is actually quite easy to do when each kind of object is a class that knows what it can trim. (E.g., a weapon class can know what upgrades a weapon can have, compared to the master definition, while a map class can know that scorch marks aren't needed.) Whereas if one started with a huge block of global variables, implementing those optimizations will mean rewriting most of it from scratch.
Keyword being: premature.
Let me tell you a story: I've actually written game engines, in the days of Doom, before accelerated 3D graphics cards were anywhere near common. I've actually had to optimize stuff lots.
You had to calculate and paint every pixel in a 320x200 pixel image. Assuming an overdraw factor as low as 2, that's 128,000 pixels written per frame. You want 30 frames per second? Good, that's some 3,740,000 pixels drawn per second.
So you wrote assembly, counted cycles to optimize by hand, and unrolled loops by hand like there's no tomorrow. Yep, that was a different beast. (It was also fun.)
But here's the other side of the coin: optimizing stuff that's _not_ the bottleneck is just plain old stupid. "Optimizing" it in a way that ties your hands in another area, is double-plus stupid.
And "optimizing" without even measuring is downright lobotomized. _The_ worst code, including worst performing, code I've seen so far was invariably code that someone thought they "optimized" but never measured it. You'd be surprised in how many ways reality can differ from what you think as "the fastest way."
E.g., at one point we thought that getting rid of compression for the resources (ought to speed level loading up. I mean, it's logical enough, right? You save the time to decompress those files, right?
Turns out that it actually loaded faster with the compression in place. The CPU time saved for decompression was actually a spit in the bucket compared to the extra time used by the HDD to read the uncompressed data. Go figure.
So to get back to the topic at hand, I find the claim _very_ suspect that saving a raw block of RAM is needed nowadays.
It has a _ton_ of disadvantages, it's fragile, and for what? Even if we're talking coding for a console and their slow memory cards (in fact _especially_ for consoles) a well written serialization can actually write less data than blindly dumping a huge static block where you pre-allocated the largest arrays you can possibly ever need during the game.
All your 5 points are very insightful, but if I may be allowed to add one from experience:
6. Blindly writing a block of memory prevents using _any_ kind of pointer, not just virtual function table pointers. _Any_ kind of a linked list, hash table, dynamically sized array, etc, suddenly becomes taboo.
For example, how's a fixed memory block going to accomodate the inventory in an RPG? Have a fixed buffer for every single object in the game, for example, saying how much of each you've got?
Sounds good until you realize that this prevents any kind of mod, and you can't even make an official expansion pack that doesn't require starting the game from scratch. You can't add a new object, because you don't have space for it in that fixed buffer.
Oops.
How about objects that take modifications? E.g., a rifle that can be added a sniper scope, or a pistol which can take a silencer? Or a SMG that can take _both_? Suddenly you can't just add a linked list that points at the augmentations added, because those don't work well with the save-whole-memory-block technique.
Etc.
No offense, but you seem to make two of them yourself.
1. Basically "if we don't have 100% consistency, we should go for 0% instead". Or, if you will, "bah, you already had a change of look-and-feel some 5 years ago, so suck it up and accept one daily, for each program."
Sorry, no. The real world isn't that clear-cut black-and-white. Sometimes you have to settle for "good enough" instead of "perfect".
2. More importantly, the underlying fallacy is "looks are all that matters." Seein' as what you came up with is flat buttons or different icons.
And that's not just a fallacy, it's also _the_ number one _failure_ of GUIs designed by programmers, graphics artists, marketting, etc. (Though each of them for very different reasons.) Generally anyone else who really has _zero_ clue about usability, and just thinks anything graphical will do.
What I'm more concerned with isn't "waaah, but they changed the 'new folder' icon in XP!" I'm more concerned with how things work. Which is why my point explicitly said "reusing skills" not "reusing graphics."
Take the Windows file open dialog for example. Sure, some apps might add a preview field next to it, or a couple of extra fields, but by and large it stayed the same since Windows '95. You can still do the same things (e.g., creating or renaming a folder right in the list), in the same way, in all apps that use it.
The important thing is: Once you've learned to use it once, you can do it mechanically, without even thinking about it. Even if you just bought/downloaded/compiled/whatever a brand new app, you already know how its file dialog works. That's one less thing to go through a learning curve about.
Now kindly open a GTK dialog box in Windows. E.g., open a file in Gimp. Ugh. WTF is that box? What was wrong with the "normal" box, that needed replacing? Or try it with a Swing app. Ugh. Why does everything look and act differently?
Try to answer those questions _without_ going into technical details about widget sets and libraries. Pretend I'm Joe Average, who doesn't even know what GTK is. And more importantly, who doesn't _care_ about such details. I just want to use the program, with a minimum of learning curve or thinking.
What was wrong, from a _functionality_ point of view, with the old dialog? What end-user functionality absolutely wasn't available through it, so that it needed a completely different dialog?
Writing perfectly portable code is possible, but as they say "there ain't no such thing as a free meal." Let's take your DirectX vs OpenGL example, just as a random example, to illustrate the problems.
1. It costs extra time and money.
And it costs time and money to also _test_ it on the new platform. Otherwise you won't even know what functions don't exactly work the same. Or you won't even know that the widget sizes are different on the other platform, and the whole GUI is a disfunctional piece of junk with truncated texts and buttons falling completely out of the dialog box.
(Writing the code is not the alpha and the omega, as you undoubtedly already know. Testing and debugging can easily account for 10 times more time.)
The promised DirectX-vs-OpenGL example: Now _Direct3D_ is pretty much an equivalent of OpenGL. No, not the same function calls, but you can get the same results.
But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.
2. Performance problems, here we come.
Of course, you could just use a wrapper that encapsulates, abstracts and emulates everything. Proper software engineering, right? The problem is: it costs performance.
DirectX-vs-OpenGL fits nicely here too: as fate would have it, Matrox already tried handling that via a wrapper. Back in the days of the G100 and G200, Matrox thought the're smart. No use writing two different 3D libraries that do the same, right? So they actually wrote their OpenGL implementation as a wrapper around DirectX.
The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.
Just in case you wonder why no games are written using one of those wrapper libraries, now you know why. Because noone wants to make a game that looks like classic ass (low polygon count) or gets single digit FPS. Or both.
3. Those pesky users.
There's one thing that all these emulation and one-lib-to-rule-them-all apologists just don't get: reusing existing skills is good.
When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app. No, I don't want it to look like Swing, I don't want it to look like QT, and I sure don't want Mozilla's skinned idiocy, and I'm gonna puke if I have to use another idiotic GTK file dialog in _Windows_, etc. I want it to look and _act_ exactly like one thing: the Win32 widgets. Nothing else.
And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.
It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.
Believe it or not, that was the whole fundamental difference I was talking about between 100 lines and 100,000 lines. At 100,000 lines you have to have clearly defined structure, clearly separated modules modules and clear interfaces to find your own ass with a map and a compass.
, obviously even fewer.
:P
So you're arguing... what? That you want to call "programs" what I call "modules"? Sure, fine by me. As long as it still walks like a duck, and quacks like a duck... Then what I meant is "a 100,000 line _project_" (composed of more of those things you call "programs") instead "a 100,000 line program."
That surely noone but you can write a subroutine? Bit of an arrogant assumption, isn't it?
Well, we can easily aggree that _most_ people hired as "programmers" nowadays don't have that skill. A study here said that only about 1 out of 4 programmers can program at all. Writing a _structured_ program/project/module/whatever-you-wanna-call-it
But assuming that basically _everyone_ but you can't possibly write a subroutine... well, that's a helluva lot more arrogance even than _I_ have. And god knows I'm a pretty arrogant bastard
"You learn software engineering by not writing 100,000 line programs."
is at most another fine example of hubris. If you never wrote programs that had to go over 100,000 lines of code, mighty fine for you, but that's hardly something you can make into a rule.
Some programs never have to be that large, true. E.g., most web applications. On the other hand, other stuff _has_ to grow 10 times larger by sheer scope of the problem to be solved.
E.g. if you think you can write something like MS Office or OOo in 10,000 lines of code, you've got to be kidding.
E.g., even as intranet programs go, not all the world means basically a simple bulletin board. One Swing application we coded had to cover basically the whole range of database stuff the company employees had to do.
Including a _ton_ of forms: each frame was a tab pane with at _least_ five different forms. No, not a wizard with 5 simple pages, but actually 5 full forms, a lot of them with tables and filters in them. The data model objects alone accounted for a lot more more than 10,000 lines. Data validation adds more than that too. Add some data entry helpers too: for example finding the Zip code or region by city, or viceversa.
And including reports with templates they can edit themselves, previews, statistics (think: data mining) over that data, etc. And a completely customized look and feel, with bitmaps splatered across the tabs, and custom shapes for every control. (One of the company directors was an ex-graphics-artist. They like visual stuff.)
Now also add more internal stuff like custom caching of the database data. Heck one module even took apart basic SQL statements for the tables, and added the filters, the fetching only a certain row range, etc, and optimized the result for Oracle based on some rules and lots of experimenting. Because the users don't want to wait ad nauseam to scroll through 3 million records in a table.
Sure, you can split it all into modules, you can reuse code or libraries, etc. In fact, at that complexity level you _must_. All mighty fine practices, and all helpful, no doubt. But no ammount of engineering, and no language ever invented, will keep that under 100,000 lines.
That's one symptom of poor morale, yes, and one of the ways in which poor morale screws up productivity.
If that's what you think, you might be in for a _very_ nasty surprise at some point.
:P
That nobody at the workplace cares about you in a good way, that's probably not a bad frame of mind. Cynical, that's true, but most of the time it's accurate.
But you might be surprised who cares about you in a _bad_ way. Who's out on a personal quest to prove to the boss that your code is utter crap and you should be fired. Or at least he should be promoted before you.
I've already posted one such true story on Slashdot (I fondly called it "Jack and Jill up corporate hill), where a marketeer-turned-programmer I know (and to my shame, which I've helped get into programming) made it a personal quest to get both female programmers on his floor fired. He succeeded too.
He'd run with snippets of those programmers code to every single guy in the building, to show everyone what bad code they wrote. Invariably he was wrong, and just showed _massive_ incompetence, and their code was good. He didn't even know the most elementary _basics_ of Java, the language he's paid to program in. But obviously it wasn't obvious to the boss, seein' as he did get them both fired, and he got promoted.
A more sad case was someone who couldn't program at all. No, not just "not a top programmer." He just couldn't write code that even compiled. At all.
So a couple of co-workers took pity and started helping him. Well, not as much "helping", as outright writing his modules for him.
So what does he do? Make it his personal quest to bad-mouth them to the boss behind their backs, and "prove" that they just interfere with his work and he surely would have done better if they hadn't edited his files. (Never mind that he had actually asked for their help to start with.)
There's one important lesson in corporate cynicism there, grasshopper. The person you helped might be not a friend, and not even indifferent: you might have actually made an _enemy_. You're one of those who know he's incompetent, and that makes you dangerous. Worse yet, you might be seen as a good programmer, and as such in his mind (and usually _only_ in his mind) someone who might get promoted before him. You're an obstacle to be taken out of the way.
How's that for being even more cynical?
Aggreed. That's exactly the difference and phenomenon I was talking about.
I left a larger interval there because everyone has their own limits. The point where I myself actually noticed that I was swapping something out of my brains each time I was swapping a new module in, was around 13,000 lines. Probably it had started earlier, though, and the 13,000 line mark is just were it got to _really_ bug me.
Piling tons of extra work upon your programmers, and unrealistic deadlines, comes back to bite you in the ass in various forms. Of course, a true PHB won't see it, and can pat themselves on the back for "getting the most out of the people". When in fact they're getting the least.
1. Bad code.
The thing about programming is that there's at least 20 ways to achieve anything. About 18 of them involve cutting corners and making a bad product, just to keep that unrealistic schedule the boss gave you.
Making and implementing a good design takes time. Throwing together a piss-poor Write-Only hack takes a lot less time. Guess which one you get if you just mindlessly pile more work on people.
Sure, it looks like you're getting some extra work done at first... until it's time to debug or maintain it. Then you start finding gems like "oh dear, instead of making a proper connection manager class, they've just directly accessed and _changed_ internal variables in other modules and got their connection from there." Any change suddenly involves a lot more work, because instead of a clear orthogonal design, it's a spaghetti mess.
Oops. It bit you in the ass.
(And so far _twice_ I've not only encountered such messes, but had to deal with them because even the original coders didn't want to touch it any more.)
2. Lack of test cases, or even of manual testing.
_The_ more common excuse for lack of that is that there's no time for it. Pile enough work on someone to give them the idea "hmm... I could still make it if I dropped the test cases", and those will be the first to go.
And it only makes problem 1 suddenly cost 10 times more time. Because not only you never know which other module messes with the innards of your class, you can't even tell if you broke something when changing it.
True personal story: oops, changing the table model also caused all the reports to stop working. And it was only found after we delivered it to the client.
True personal story: oops, the program was packed by an overworked coleague with the test templates instead of the real templates. Some real business partners got bullshit emails as a result. (If you thought MS's inapropriate comments in code were fun, emailing stuff is more fun.)
3. Tired people are stupid people. (Not meant as an offense. I'm stupid when extremely tired too.)
Every notch you go above someone's limit, and every hour of overtime they have to do for more than 1-2 weeks in a row, soon starts reducing their productivity. They make more mistakes. They need more time to find them and to fix them. They see less of the picture, so each fix is more likely to break something else.
4. Lowered morale also lowers productivity dramatically.
Nerds are a funny breed. If you overworked a factory worker, they'd be more likely to tell you "no, sorry, this is as far as I'll go." Or just do as much as they can, and pack their bags cheerfully when the clock struck 5 PM.
Nerds tend to be more insecure. A lot are autistic too, so they can't even tell how bad or not bad the situation is. They'll go beyond their physical limits, rather than risk disappointing the boss.
Unfortunately, as they say, "there ain't no such thing as a free meal". The extra effort comes at the cost of tiredness and lowered morale. Either of which alone can count for up to an order of magnitude productivity, if brought to extreme levels.
Why engineers want info up front can be broken up roughly into the following problems. Usually it's a combination.
1. Bad management.
It's more common than you think to be blamed for not reading the client's mind. (You should have just known that when they explicitly wrote "save when exitting every field", they actually meant "we don't want the info to disappear, but we don't really want disk access every time we hit TAB." Whatever gave them the idea that info just disappears in a form. It's your fault when they come back complaining about performance.)
Or when it's not outright "you're to blame, you horrible monster", it's being asked to do overtime to "fix" it. Because the boss is too weak to tell a big client that those changes cost extra time to implement.
I can tell you that it doesn't take more than 1-2 such projects, to give one the idea "no, you don't. Not again. Give me a good spec up front this time." Because anything short of a full spec simply comes back to screw you with a chainsaw lately.
2. Bad management again: changing the same thing back and forth, just because the client can't make up his/her mind.
It's been said that the most depressive thing you can do for example to a prisoner is to just make him do not something that's hard work, but something that's obviously _useless_. Such as asking the prisoners to move a big pile of sand from here to there, and then back to the same point. That "I'm doing useless stuff" thought saps someone's self-esteem and ultimately even health faster than if you tortured them or made them break rocks with a pickaxe.
And the same applies to software projects.
I've _actually_ been in one project where for a whole _year_ the client manager couldn't make up his mind whether he wants the reports landscape or portrait. Never mind that the program included a report designer, where he can lay them out in whatever goddamn way he needs. No siree, bob. He's not gonna accept the program until the reports are landscape... then portrait... then landscape again... then portrait again. Repeat ad nauseam. For a year.
Going through something like this will make it _very_ tempting to say "screw this, I want a signed spec up front".
3. Bad design.
Most programs are basically Write-Only. People give no thought to maintenance later, and even the smallest change means rewriting half the stuff.
Now I'm not a fan of extreme programming as such. (And please, if anyone feels like taking it as an opportunty to preach, have mercy and spare both my time and yours.) But I do think that they did get the basic ideas right. (It's just the turning it all to the max that I disaggree with.) Programs should be written to be easily changed.
4. Lack of test-cases.
That's probably the worst anti-pattern. So you most often have not only a spaghetti program that's hard to change, but it's not even possible to be sure you didn't break something else.
I doubt that anyone would place comments in code that basically boil down to "I hate my job and my employer." At the next code review, or the next time a bored coleague looks into your code, it's just begging to be used against you.
/. screaming and waving it around as definitive proof MS can only write bad code.
If comments about the company or other co-workers are present, they'll more likely be a lot milder and kept to something you can sorta justify as just documenting code behaviour. E.g., "this is a work-around for Bug X in Function Y of the MSFC".
On the other hand, there is plenty of room for utterly inapropriate comments about other companies and products. Think along the lines of "unlike the utter crap we took from the BSD monkeys, this one is 40 times faster and uses 10 times less memory." Or "this is here only because the monkeys from are too stupid to do their own buffer checking before calling my function."
Excessive hubris is pretty much part of the job description for nerds. Remember kids, everyone else sucks and is an idiot luser. Only you can possibly know anything at all about computers. And only the skills you have (e.g., pushing the power button or typing "emerge kde") are l33t and cool, the rest is idiot luser stuff.
But my guess is more like MS is just playing defensively. There are a lot of people and has-been companies that are out for MS's blood. Comments that noone minds in the Linux kernel, if found in MS code would get those people screaming for blood and gathering a proper medieval crowd with pitchforks and torches.
I mean, look around. Even a comment as benign as "this is a work-around for bug X in function Y" would get half the MS-bashers on
Doubly so for those who:
A) never wrote any productive code in their entire life, but think they're uber-l33t because they can run someone else's scripts (e.g., "emerge kde"), or
B) wrote a 20 line program in BASIC once, or a 20 line BASH script, so they think they're qualified to pass judgment about 1,000,000 line projects or about whole languages
(No offense intended to good programmers in either VB or various shell scripts. But there is a _massive_ and _fundamental_ difference between a 100 line program and a 100,000 line program. Stuff that works in the former, like, "bah, I wrote it just as well without all this fancy encapsulation and bogus design", might just cause the latter to never be finished or anywhere near working.)
Nah, I didn't mean I'll start charging them. I mean more like I'll tell them to fsck off, only of course in a _much_ more diplomatic manner.
It's not just about tax return forms, it's that I can do better with my time. Like write a program. Or play a game.
And yeah, I know that some time in the future I'll have a leaking pipe or whatnot. That's what I pay insurance for. It's still cheaper and _far_ more reliable than relying on bartering favours.
It's also that my definition of a friend is somewhat more... demanding, for lack of a better word. A friend is someone who still calls you or emails you some 5 years after you've moved to another town, even if you've never fixed anything for them. Someone who's a "friend" only as long as they can freeload some unpaid service work from you, is IMHO at most "barter" if they actually offer some service of their own in return. Or most often a "freeloader" because they don't really.
And I'm honestly surprised at how many nerds think they're _buying_ friendship. And how they aren't really. There's a whole caste or social strata of people whose main skill is acting like you're their best friend... as long as they can freeload something from you.
And to be entirely honest, this isn't even something new or speciffic to computers. Nerds just tend to be easier scammed that way, but the symptom existed long ago. E.g., people who were your best friend as long as you bought them free drinks, probably existed a few thousand years BC.
I come from a family of computer nerds, so half the family friends were nerds. (Half of the rest were medical doctors.) If there's one thing I had the privilege to witness first hand, it was precisely this kind of a warped "friendship" in action. Dad, for example, spent half his free time basically "having friends" by doing unpaid work for them.
Invariably the "bought" friends, promptly forgot you even existed when you could no longer provide the free service. Invariably the ones who still write and even offer help are the ones who hadn't needed free work to start with. Go figure.
I don't know what area of the world you people live in, and by now I'm curious. Because I thought most of the world has long ago dumped that kind of stone age barter model. We're no longer in the year 2100 BC, people, where the norm was "I'll give fix your thatched roof if you give me a clay pot and two breads", you know.
And, dunno how to say it nicely, but the examples I read are surrealistic. Lemme recap:
- a bottle of whine
- a pizza
- two beers
- a home-cooked meal
- an old half-working CD-ROM drive
- he'll supposedly come fix my pipe if I ever need it
Etc.
Umm... hello? Are we talking Elbonia or East Bumfuckistan or something?
Because where I live I can just go buy my own bottle of wine, if I ever felt like it. Beer? Well, gee, so I'm suppose to fix a retard's computer for something worth less than 1 Euro? Pizza? I can order my own. Etc.
Dunno about you, but my time is worth more than that. Even if we're talking Indian manual labourer wages (no offense to citizens of India meant, just using it as a generic low wage country), two beers for 1-2 hours of work is a fucking sad joke.
Ditto about services. Dunno, maybe your house was built on an ancient cursed burrial ground, and pipes burst every morning. But where I live I've only needed a pipe fixed once in the last 6 years, and I once locked my keys in the house and needed a locksmith. That's it.
And you know what? It cost cheaper to just call a plumber and a locksmith, than waste hundreds of hours of my time fixing every retard's computer just in case I ever need them.
That's the whole problem with that stone-age barter and favours system, and why the road to real civilization meant dumping it like hot potato: it's bloody inefficient. A few hundreds of hours of my time don't even start to be compensated by "yeah, but I saved some 200 bucks on those repairs." Well, gee, that's like, what? Working for some 50 cents per hour?
It's just sad.
No, thanks. I'll pay for repairs when I need them, and they can call a proper service centre when they need repairs to their computer.
Ah, well, see, I'm just Joe Consumer here, not an investor or anything.
I.e., my concern isn't "how can they make money?" That, I'm sure they already have in mind, yes.
My concern is more along the lines of "are they trying to shaft me?"
Stuff at service level, I don't mind. As far as I'm concerned, if they can actually improve their service to _me_ with that data, I'm all for it. Sure, why not?
Stuff that, on the other hand, boils down to shafting their customers (e.g., by selling data to spammers), I'm against. I _don't_ see this as a legitimate business practice.
Sure, it makes money, but in a predatory way: they make their money at the cost of causing me a loss. Much like mugging does, for example.
In a nutshell, I believe that business is supposed to work in a way that creates value for _both_. E.g., if I'm a baker and you're hungry, buying a bread for me actually creates value for both. You need something to eat now more than you need the money (which you can't eat), while I need some money more than I need one of the tens of loaves I bake per day. That's the kind of transaction that's beneficial for society.
On the other hand, "business" of the kind where one makes their win by causing others a pure loss, I see at most as an abuse of the system. It's no better than theft.
Doubly so for the massively destructive kind of predatory "business". E.g., someone making some 100,000 bucks by selling addresses to spammers, and... contributing to the spam problem that causes 22 _billion_ per year lost productivity in the USA alone. On the whole of society, that's actually a big loss.
Sure, _they_ will probably see it as "bah, it makes us money, that's all that matters." _I_, however, see it as "there ought to be a law against this kind of predators."
Well, I figure I'm savvy enough to use a PC by now, seein' as I've been using and programming computers for some 22 years now.
Still, I like to play with new stuff. I've been considering a Mac, actually, and a few other options. Heck, I've even been considering getting a Sun workstation at home too, just to play with it.
Thing is, until recently, Macs were a bit too expensive. Well, maybe not as such, but you couldn't configure one without a bunch of extras I really didn't want to pay for. E.g., I didn't want to pay for a dual-CPU config to get the fastest CPU. Or I didn't want to pay for Apple's TFT as part of an iMac, since I have a better monitor already.
But now that the Mac Mini finally exists, I just have to get one. I'm just waiting for them to actually be available in an online shop here, that offers the 1 GB RAM option at half of Apple's price. In fact, pretty close to the price of just buying a RAM stick separately. Saves me the bother of opening the case to install it myself.
Yes, I have some vague clue on data mining. I'm not an expert by any means, mind you, but I've been asked to program that kinda stuff before.
What I'm trying to say, though, is that there's a level of granularity beyond which it becomes _trivia_ instead of a statistic.
For example, "How many games did this team win?" is a statistic. Gives you some idea of their performance. "How man games did they win on a rainy tuesday afternoon?" is garbage. It's trivia material, not anything useful.
Ditto for breaking down, say, sales statistics by street. Take for example The Sims, a game which had such an intrusive registration. How does that kind of fine granularity help them make a better game?
Grouping the buyers by country or state, now ok, I can see _some_ point in that. There are cultural differences which will be reflected. Now consider it finely grained, down to street and house number level. "How many people bought our game on Elm Street?" How the heck does that help them make a better game?
No, seriously. I want to know.
"that information has value to others trying to sell stuff to you- Sherman networks knows that you liked SNL with Ashly Simpson- so in theory they could sell your name / address to companies that sell SNL videos"
Bingo. That's why I made the distinction between "legitimate use", as in, stuff they need to provide a better service, and seling that data to spammers. That kind of fine granularity is useless for a legitimate aggregate statistic, but is valuable to spammers. (I do include spammers of the snail mail or phone kind.)
I.e., that detail of data mining just tells me "non-legitimate". It tells me that there was a _dishonest_ mind behind it all. That, yes, they do have a plan, even if a backup plan, to sell your data for money. In one word: lamers.
Unrelated, if Sherman planned to sell data back to the companies in RIAA, they're more stupid than I though. So they're accessories to something illegal, know it's illegal, make a recording of it, and... plan to sell the data to the ones they helped defraud? Geesh. It's last going to a bank and saying "wanna buy a list of your offices I drove robbers to?"
I can only hope that it wasn't their plan, because _that_ kind of massive stupidity would just be depressing.
I'm aware of hashes, yes, but it's still a case of "infinite monkeys on infinite keyboards". Well, more like "a few million monkeys on as many computers." Each will rip it to a different bit rate, set the ID fields differently, etc. Then there are different CDs containing that song. And if they're remastered from tape, god help you with that hash, 'cause even the original digital data _before_ encoding will be slightly different.
So in a nutshell even that doesn't say much.
As was pointed out before, a bank is expected to be a bit more security minded than that.
E.g., the bank my money is at, first of all needs all online transactions to be validated with a one-time number. You get a pad with maybe 100 such numbers, and each can be used only _once_. That number is thereafter recorded as invalid and can't be used again.
And, oh, you can't do a brute force attack through all combinations either, because after the third failed attempt they lock the account.
So even if someone recorded your keystrokes, and even if they had complete remote control of your computer, they'd have a pretty damn hard time impersonating you and transferring money out of your account online. (Which is what happened to this guy.) Even if they recorded one such single-use number, they can't use it.
There is also a limit on online money transfer per day and per week. They can set it higher or lower for you, but the safeguard exists. _And_ there's a limit on how far below zero the account can get. There is no way in heck someone can just transfer 90,000$ out of my account in one go.
See, that's what real security is about. Thinking _how_ can you prevent something from happening, even if you live in an imperfect world. In fact, _because_ you live in an imperfect world.
E.g., that one-time pad is there precisely _because_ someone might record your keystrokes.
Shrugging and blaming the victim ("If the victim in this case used Microsoft Windows, with all its well-know and well-publicised security flaws, he only has himself to blame.") is the nemesis of security. That-a-way lies just madness and making a piss-poor product.
Well, the recording part is the part that's really sad. It's such massive lack of clue, it's... well, come to think of it, probably standard for management.
And wth is with all these companies and collecting data about their users? Everyone must track you, profile you, and make you go through an intrusive registration just to (for example) download a patch to a product you've bought.
Now I _know_ that you're not really anonymous on the Internet, they can collect a ton of data about you, bla, bla, bla, Sure, they _can_. But do they even have a _legitimate_ use for that data? I.e., one that doesn't boil down to "we can sell the list to spammers later."
Most of the collected data nowadays (and again I don't only mean Kazaa) is plain useless for anything even resembling an aggregate statistic.
E.g., in Kazaa's case can they even do an automated aggregate statistic over the filenames? How? There must be hundreds of different ways to write the same filename, so good luck telling whether more people download Britney Spears or Eminem. Or which genre do people download more. And even if (ad absurdum) they could get an aggregate statistic, what would they do with that data?
E.g., in the case of some companies' intrusive registration forms and out-of-hand data collection, wth are they gonna do with such pieces of trivia as my house number or telephone number? _How_ does one use that in an agregate statistic?
I mean, "How many people bought our product in Europe vs USA?" is a statistic. "How many people with an even house number bought our product?" is at most useless trivia. There is _no_ useful information in there.
Dunno, reminds me of dogs chasing a car. They have no idea what they'd do with it if they caught one, but they just must do it anyway.
Sad.
"So when are all the diehard M$ fans finally going to get the message"
.so libraries on the system in the process. (And don't even get me started about what that means if that app is a copy-protected game _and_ you have an ATI graphics card.)
;)
About the time there will be a real alternative to it.
Fact is, most people aren't really "fans" of any one OS. Noone except the Linux fanboys (been one myself, believe it or not) actually gives a damn about the _OS_. It's like having a flame war about whether brown seat covers are more evil than blue seat covers in a car. It's that stupid.
The OS is just a necessary evil you need to load the _applications_. _That_'s what matters. Most of us could live just as happily without an OS at all, if the apps could be loaded otherwise. No, seriously. The OS is just a necessary evil, no more.
So until Linux actually starts having some more useful apps, it's just not a competitor. It doesn't matter how good the OS is.
So the sad choice really is, do I:
A) get Linux, spend weeks coaking Wine/WineX/CrossoverOffice into running each program. And recompile half the
B) get Linux, spend weeks learning some half-arsed dysfunctional equivalent to even the most common apps, or
C) Get windows.
Took me about two years of messing with Linux (and ranting on newsgroups about how the evil MS will never again see a cent from me) to realize that I was in fact increasingly often giving up and taking route C. Which is to say, booting my Windows partition.
"And I do tend to stay up with security fixes unlike the windows sheeple who's probably running a windows box with a generated serial number"
Ah, the usual "if they don't want Linux for free, they must be running a warezed version of Windows" fallacy. How refreshing. I hadn't read that fallacy in, oh, about two days, and was starting to get withdrawal syndrome
Reality is more complex than that. Even by BSA statistics -- and BSA is _paid_ to cry wolf and exaggerate -- piracy isn't _that_ wide spread in the Western world. The fact is, like it or not, most of us have knowingly paid for Windows.
In my case, I can even tell you why I went back to it. Because, as they say, "Linux is for free only if your time is worth nothing." Dunno about you, but if I put even a minimum wage price on my time, Windows has practically paid for itself by now.
"There's no way in hell a windows box can survive long enough to grab and install all the fixes when its been re-imaged by the distribution cd that came with the machine."
Again, yes, there is. Go to the TCP/IP properties, tell IPSEC to allow only outgoing connections. It's been built in at least since NT 4.0, maybe earlier.
No, it's not a full-featured firewall, but it will keep you safe enough while you download the patches.
And here's the fun part: it takes less time than whining about how Microsoft sucks. Now it may not be as fashionable as whining about MS on Slashdot, but it will keep your computer safe.
Because what I've said is that Windows has buit in packet filtering (sort of a poor man's firewall) at least since NT 4.0. Probably even earlier.
So you _can_ connect a computer to the Internet long enough to download the patches _without_ getting virused.
But that would require having a brain. Something that's actually lacking among most of the whining crowd. Because otherwise 90% of the complaints about Windows wouldn't boil down to "I'm too incompetent to configure it."
There are also other solutions, all of which takes less time than whining. E.g., downloading a firewall on your own computer.
For all the geek whining about how Windows sucks, and spending hours in vi and obsolete man pages is fun, you'd think they can at least RTFM.
E.g., you don't even need to buy a router or whatever to keep your Windows safe until you download the patches. Just go to the TCP/IP properties and activate IPSEC.
No, it's not a full fledged firewall, but it'll keep you safe as houses until you download a patch.
Now it's not something that's on the first page or activated by default, but for anyone claiming to be a die-hard Linux geek, here's the deal: it takes less time to fucking look at the IP properties, than to write a whine on a blog or Slashdot.
But, nah, whining about Windows is _fashionable_. It's cool. Makes one feel like one belongs to a big family.
That's the problem. Just reading the docs, or god forbid actually taking the time to configure it right, that's soo unfashionable. Just gets one branded as a "windows luser" or worse. Nah, better let her get virused instead, so we can fashionably whine about Redmond.
*sigh*
Look, folks, I'm not saying windows is perfect. Or even that good. But clueless whining and mis-presenting one's own complete incompetence as definitive proof that Windows sucks, that's just sad. It doesn't even do anyone a favour.