I don't see how my portrayal is innacurate. Theorectical and experimental physicists regularly disparrage each other (mostly in good fun but occasionally seriously). The gap between CS students turned programmers and CS students become pure computer scientists is similar.
Also, unlike physics, a solid proof is a *proof*. Pure CS is an extension of logic which is (I believe) an extension of math. Much of CS doesn't require experiments since it is built on proofs.
CS has forked in the same ways that physics has. It's forked in so many ways that "CS" (like engineering) should be a dozen fields of study. CS is largely uncategorizable for this exact reason.
Edsger Dijkstra, winner of a Turing Award and a contributor to the field of Computer Science in many many crucial areas (proofs, path finding, semaphores, etc...), does his 'computing' with a pen and paper.
Pure computer science doesn't focus on tools, methodologies, or implementation. It focuses on proofs and design.
Hence the famous quote by Donald Knuth, "Beware of the above code; I have only proved it correct, not tried it."
I happen to dislike much of this way of thinking. However, without pure CS the rest of the programming community would be far less enabled. Think of it as the difference between experimental and theoretical physicists.
This is why every programmer should read a book like Code Complete. It teaches *agressive* defect catching in your code. Most programmers are too afraid of their code. They want it to run so badly that when it runs correctly once they are happy to sign off on it.
That makes no sense. That's a horrible mentality and it's far too prevalent in the field. Anwyays, any new programmers should read the book, it explains things far better than I could.
btw: Ironically, when I started programming all I ever did was use a debugger (Turbo Pascal 7 was excellent)... nowadays I prefer to read code. This avoids a problem I grew up with... hack and slash debugging. Often I would get an off by one error and do a quick fix and then run it through and it would pass. Often other bugs would slip by me or I'd forget to change affected variables, etc. By reading I am forced to take more time to verify the code integrity. Oh, and most studies show that code reading reveals about 3 times more bugs than does stress testing.
Not disagreeing with you. Just adding to your comment.
This is because most programmers hate testing. Programmers see testers the way sysadmins view the first level tech support staff. As a direct result testing rarely gets a lot of attention. One of the basic rules of testing is that the extreme odd cases are the most important to check (and often the simplest). One of the signs of a really good programmer is how well they debug and test their code. The very best have lots of neat debugging techniques (like this one).
btw: Thanks for the breakpoint thingy. I usually check every branch but (as you discovered) the breakpoints will confirm test coverage. I expect similar results.
...and if you don't have a debugger put a unique print statement in each and check em off on paper until you hit em all.
See, I agree but this, like all CS departments I know, glosses over an *extremely* important point which I'm sure you're aware of but failed to mention:
A crappy looking but correct solution to a problem isn't a good solution. One aspect of proper programming is using proper style, proper tools, and proper documentation. While problem solving skills vary drastically amongst people (face it, some people should never be 'programmers') you can at least enforce good practices in these things. Of course, it doesn't help worth crap when you lack both good problem solving and programming techniques.
I've met countless intelligent people who could do circles around me at proofs and complex problem solving but whose actual code made sense to only one person.
This is a huge weakness in both the high school and college education system.
Could you, for my edification, please tell me what part it was. I played the whole tihng through with no cheats and no hints and I'd like to see if I remember the section.
I respectfully disagree. It's just that I have a vast preference for games that let me *experience* their wonderful adventure. I don't mind playing pure MP games (Action Quake 2 is one of my all-time favorites), but my favorite, most beloved games are plot heavy with carefully crafted action and gameplay. Also, I don't think comparing MP to single player can be taken as a valid comaprison.
Thief, Thief2, System Shock2, Half-Life, Starcraft...
These all combined above average gameplay with above average plots. They also, for the most part, avoid tedium. Take Quake, no plot, all action. Extremely forgettable. The only stuff people remember is the multiplayer (which is a completey different matter)
On the other extreme you have games like Wing Commander IV, which was a movie diguised as a game, and games like 7th Guest or Myst where the gameplay is there more to further the story.
After about a qurter of the way through a game you understand the kind of thought that went into the game. Was the plot the driving force? The action? The new technology? Did they really try to get the plot in but it is too weak?
I find the best games have more than just balance.... they have a unique intertwining of both the plot and action so that one cannot be remmebered without the other.
By being enveloped in the ambience and pseudo-reality of the story I experience the kind of lasting memories that make these games wonderful to me. This is exactly what a good book or movie does to me.
I leave one caveat. The nature of video games and production schedules often means that an otherwise engrossing game and story often degenerates as the 'end game' approaches. It's apparent in the original Thief and even Half-Life. Books certainly avoid this easily... movies usually too.
Ironic isn't it that DOS was chosen over CPM for almost this exact reason. The 'hacker' was too busy trying to manage his life and his project and told IBM to go look for Gates.
He's twisting IP to mean commercial solutions. ie: vendor A comes out with neat product B. A month later there is a functional open source clone of the program. Also, the natural sharing of information spills over into gray/black areas (mp3s, movies, etc). This is a legitimate point but he'd just as well have the whole OSS philosophy be blackmarked.
Heck they use it internally in some departments for work purposes. I've asked some friends who've worked or interned in Redmond. I recall one of them being asked on his first day, "So, KDE or Gnome?".
Well, just take the mean time to failure of a drive. Divide by the number of drives you have. Granted this doesn't really hold up if you just baught 5 new drives.
As for me. I've dealt with 7 HDs going bad in the 7 years that I've worked with computers. Only one was actually mine but that's about 7 in 50 HDs. Only one was a spectacular crash (nice gouge), but sectors going bad qualifies.
Perhaps there are good ones but winmodems are notorious for being trouble makers among ISP techs. I know, I was one.
The MWave in particular is hated. Newer versions may suck less but one of the original problems was that since it doubled as a sound card you couldn't be online and listening to sounds/gaming at the same time. It also had nasty problems connecting.
IBM had extremely poort support for the product and indeed had a lawsuit brought up against them. No idea what happened to that.
On the other hand there was a tech next to me that played Jedi Knight with his Supra winmodem and never had a disconnection.
Re:How about Annoyed enough
on
Is BSD Dying?
·
· Score: 1
You can use pkg_version to see what difference you have between installed packages and your up to date ports. In fact you could automate it via a script but that's is *heavily* discouraged.
Yes, it's not as simple as Debian's method.
You can check out htpp://www.freebsddiary.org/ and poke around for info on upgrading installed ports.
I really hope the ports project get's this in. "make upgrade" would be sweet.
You also need to factor in time for regular empoyees to check the validity of code/information. Not to mention the time they have lost. (This applies to hacker/cracker breakins as well)
Say you're developing the next Boeing aircraft and a virus sweeps through:
Maybe it has infected all machines. Maybe only some groups. You have to verify that the virus did not damage any critical files. Factor in the time that employees spend not working (even if all you do is a global backup restore) and the costs grow large. Imagine paying a few hundred engineers to do nothing for a couple days.
Slashdot Mirror
I can't wait till the same people can tool on personal space entry vehicles.
I don't see how my portrayal is innacurate. Theorectical and experimental physicists regularly disparrage each other (mostly in good fun but occasionally seriously). The gap between CS students turned programmers and CS students become pure computer scientists is similar.
Also, unlike physics, a solid proof is a *proof*. Pure CS is an extension of logic which is (I believe) an extension of math. Much of CS doesn't require experiments since it is built on proofs.
CS has forked in the same ways that physics has. It's forked in so many ways that "CS" (like engineering) should be a dozen fields of study. CS is largely uncategorizable for this exact reason.
Edsger Dijkstra, winner of a Turing Award and a contributor to the field of Computer Science in many many crucial areas (proofs, path finding, semaphores, etc...), does his 'computing' with a pen and paper.
Pure computer science doesn't focus on tools, methodologies, or implementation. It focuses on proofs and design.
Hence the famous quote by Donald Knuth, "Beware of the above code; I have only proved it correct, not tried it."
I happen to dislike much of this way of thinking. However, without pure CS the rest of the programming community would be far less enabled. Think of it as the difference between experimental and theoretical physicists.
Wth? Who the heck moderates this up as interesting?! This has troll and flamebait and overrated written all over it.
... is one turn-based game that will far outlive the rest of the real-time games. I don't see chess dying in the near century.
This is why every programmer should read a book like Code Complete. It teaches *agressive* defect catching in your code. Most programmers are too afraid of their code. They want it to run so badly that when it runs correctly once they are happy to sign off on it.
That makes no sense. That's a horrible mentality and it's far too prevalent in the field. Anwyays, any new programmers should read the book, it explains things far better than I could.
btw: Ironically, when I started programming all I ever did was use a debugger (Turbo Pascal 7 was excellent)... nowadays I prefer to read code. This avoids a problem I grew up with... hack and slash debugging. Often I would get an off by one error and do a quick fix and then run it through and it would pass. Often other bugs would slip by me or I'd forget to change affected variables, etc. By reading I am forced to take more time to verify the code integrity. Oh, and most studies show that code reading reveals about 3 times more bugs than does stress testing.
Not disagreeing with you. Just adding to your comment.
This is because most programmers hate testing. Programmers see testers the way sysadmins view the first level tech support staff. As a direct result testing rarely gets a lot of attention. One of the basic rules of testing is that the extreme odd cases are the most important to check (and often the simplest). One of the signs of a really good programmer is how well they debug and test their code. The very best have lots of neat debugging techniques (like this one).
btw: Thanks for the breakpoint thingy. I usually check every branch but (as you discovered) the breakpoints will confirm test coverage. I expect similar results.
...and if you don't have a debugger put a unique print statement in each and check em off on paper until you hit em all.
See, I agree but this, like all CS departments I know, glosses over an *extremely* important point which I'm sure you're aware of but failed to mention:
A crappy looking but correct solution to a problem isn't a good solution. One aspect of proper programming is using proper style, proper tools, and proper documentation. While problem solving skills vary drastically amongst people (face it, some people should never be 'programmers') you can at least enforce good practices in these things. Of course, it doesn't help worth crap when you lack both good problem solving and programming techniques.
I've met countless intelligent people who could do circles around me at proofs and complex problem solving but whose actual code made sense to only one person.
This is a huge weakness in both the high school and college education system.
SourceForge just ponied up $500,000 in upgrades and new equipment as well as triping the size of their staff... read what you will.
1 0651
1 1883
The SF manager had this to say: http://sourceforge.net/forum/message.php?msg_id=1
and this regarding making money: http://sourceforge.net/forum/message.php?msg_id=1
In hindsight that seems rather silly as well. At the time it made perfect sense to me... all the clues pointed towards that action.
I should add that I generally agree with your original post about no non-sequitors.
Could you, for my edification, please tell me what part it was. I played the whole tihng through with no cheats and no hints and I'd like to see if I remember the section.
I respectfully disagree. It's just that I have a vast preference for games that let me *experience* their wonderful adventure. I don't mind playing pure MP games (Action Quake 2 is one of my all-time favorites), but my favorite, most beloved games are plot heavy with carefully crafted action and gameplay. Also, I don't think comparing MP to single player can be taken as a valid comaprison.
Thief, Thief2, System Shock2, Half-Life, Starcraft...
These all combined above average gameplay with above average plots. They also, for the most part, avoid tedium. Take Quake, no plot, all action. Extremely forgettable. The only stuff people remember is the multiplayer (which is a completey different matter)
On the other extreme you have games like Wing Commander IV, which was a movie diguised as a game, and games like 7th Guest or Myst where the gameplay is there more to further the story.
After about a qurter of the way through a game you understand the kind of thought that went into the game. Was the plot the driving force? The action? The new technology? Did they really try to get the plot in but it is too weak?
I find the best games have more than just balance.... they have a unique intertwining of both the plot and action so that one cannot be remmebered without the other.
By being enveloped in the ambience and pseudo-reality of the story I experience the kind of lasting memories that make these games wonderful to me. This is exactly what a good book or movie does to me.
I leave one caveat. The nature of video games and production schedules often means that an otherwise engrossing game and story often degenerates as the 'end game' approaches. It's apparent in the original Thief and even Half-Life. Books certainly avoid this easily... movies usually too.
Ironic isn't it that DOS was chosen over CPM for almost this exact reason. The 'hacker' was too busy trying to manage his life and his project and told IBM to go look for Gates.
Actually they do change people's submissions. They cut and paste for effect and created their own headlines as well.
Trust *nothing* that comes from slashdot until you can verify it.
You might be infringing on someone elses *EXISTING* project.
2 02 47&cid=167
http://slashdot.org/comments.pl?sid=01/02/14/11
and
http://freshmeat.net/projects/fressh/
He's twisting IP to mean commercial solutions. ie: vendor A comes out with neat product B. A month later there is a functional open source clone of the program. Also, the natural sharing of information spills over into gray/black areas (mp3s, movies, etc). This is a legitimate point but he'd just as well have the whole OSS philosophy be blackmarked.
Heck they use it internally in some departments for work purposes. I've asked some friends who've worked or interned in Redmond. I recall one of them being asked on his first day, "So, KDE or Gnome?".
Ignorance? or Troll?
The BSD license is written explicitly to allow this to happen. No one who understands BSD is crying foul over this.
But wait... this is open source. Standards can be revised. Version 2.0 upgrade anyone?
I'd rather have most everything work one way and have a few quirks than have a half-dozen quirky methods.
This already exists. Check on Freshmeat
http://freshmeat.net/projects/fressh/
well, an extra s but whatever.
Well, just take the mean time to failure of a drive. Divide by the number of drives you have. Granted this doesn't really hold up if you just baught 5 new drives.
As for me. I've dealt with 7 HDs going bad in the 7 years that I've worked with computers. Only one was actually mine but that's about 7 in 50 HDs. Only one was a spectacular crash (nice gouge), but sectors going bad qualifies.
Perhaps there are good ones but winmodems are notorious for being trouble makers among ISP techs. I know, I was one.
The MWave in particular is hated. Newer versions may suck less but one of the original problems was that since it doubled as a sound card you couldn't be online and listening to sounds/gaming at the same time. It also had nasty problems connecting.
IBM had extremely poort support for the product and indeed had a lawsuit brought up against them. No idea what happened to that.
On the other hand there was a tech next to me that played Jedi Knight with his Supra winmodem and never had a disconnection.
You can use pkg_version to see what difference you have between installed packages and your up to date ports. In fact you could automate it via a script but that's is *heavily* discouraged.
Yes, it's not as simple as Debian's method.
You can check out htpp://www.freebsddiary.org/ and poke around for info on upgrading installed ports.
I really hope the ports project get's this in. "make upgrade" would be sweet.
... but then you'd have Kruo5hin.org
Well, that's not entirely a bad thing.
You also need to factor in time for regular empoyees to check the validity of code/information. Not to mention the time they have lost. (This applies to hacker/cracker breakins as well)
Say you're developing the next Boeing aircraft and a virus sweeps through:
Maybe it has infected all machines. Maybe only some groups. You have to verify that the virus did not damage any critical files. Factor in the time that employees spend not working (even if all you do is a global backup restore) and the costs grow large. Imagine paying a few hundred engineers to do nothing for a couple days.