Seconded. You can't beat designed for the task.
It's got an extremely low learning curve, immediate feedback, and lends itself nicely to exploration. And contrary to popular belief, it's not exactly limited.
Brian Harvey at UCB has 3 downloadable books suitable for varying skill levels here.
He has a point, well made through his manufactuing analogy, but he doesn't carry it far enough.
When a machinist makes a part on a lathe (s)he takes the blueprint (engineering's contribution) and machines the part to specifications then takes a micrometer and checks it (testing phase) and then passes it along to the QA dept. for final testing. Engineers who are also machinists (though ususally not qualified as either -- ie hackers and inventors) often make prototypes and say just what the author said: "Here it is. The documentation is in front of you. Yes, there, in that piece of metal."
The problem that the author is exposing here is, imo, that there is in fact no such thing, as yet, as a mature software engineering discipline. Think about the two hundred and fifty year gap between John Harrison's first accurate chronometer and the golden age of modern steam turbines -- both incredibly complicated, critical, mature designs. Harrison is the genius programmer / software engineer of today, but he was, like today's programmers, operating without an engineering map.
A good set of blueprints and engineering specifications lets an astute and experienced outsider, in only a few minutes, grasp the entire operation of the machine; any particular minutae he cares to focus in on are exposed as well. No such method of documentation, afaik, exists today for complex software designs.
The reason this distinction is critical is not evident in the actual product under consideration. It comes later, in the design of the second product, and the thirtieth, and in the repair of the product (think Y2K), thirty or fifty years later. Solid engineering produces long term benefits, and a lack of an engineering discipline only becomes apparent when people start bitching about how the field is becoming stagnant, a complaint I've been hearing quite regularly about software design.
I went. Straight out of high school, and against the advice of my father (who obviously knew me better than I knew myself).
And that first year I spent skipping classes just because I could, and I never had, cost me around $50K in scholarships and the opportunity to graduate from one of the best engineering colleges in the country (CWRU in Cleveland).
So instead I spent the last seven or eight years as a machinist -- good blue collar job, decent pay, and _lots_ of exposure to "non-uni" types. And lots of resentment built toward academia et al. And multiple cancelled (re)start dates.
So if you're at risk of this sort of behavior, my advice is take the time you need now, because if you need it you _will_ take it regardless, and at least now you can defer, which is about as consequence free as it gets:)
maybe when deitel & deitel start publishing exploits you'll see more of this...
actual working code is probably the cleanest way to communicate with your average programmer or sysadmin. programmers who follow the whole top down development with stepwise refinement and flow charts EVERY TIME and psuedocode process and somehow always manage to remain platform and language independent are called computer scientists and software engineers and they deserve their titles and their stock options.
but most security alerts are going to come from average hackers (dammit -- i had to say it) and are going to be kinda kludgy and thrown together and the exploit code really ends up being the heart of the whole thing.
Slashdot Mirror
You were probably thinking of passenger pigeons, which most certainly are extinct.
Seconded. You can't beat designed for the task. It's got an extremely low learning curve, immediate feedback, and lends itself nicely to exploration. And contrary to popular belief, it's not exactly limited. Brian Harvey at UCB has 3 downloadable books suitable for varying skill levels here.
False.
He has a point, well made through his manufactuing analogy, but he doesn't carry it far enough.
When a machinist makes a part on a lathe (s)he takes the blueprint (engineering's contribution) and machines the part to specifications then takes a micrometer and checks it (testing phase) and then passes it along to the QA dept. for final testing. Engineers who are also machinists (though ususally not qualified as either -- ie hackers and inventors) often make prototypes and say just what the author said: "Here it is. The documentation is in front of you. Yes, there, in that piece of metal."
The problem that the author is exposing here is, imo, that there is in fact no such thing, as yet, as a mature software engineering discipline. Think about the two hundred and fifty year gap between John Harrison's first accurate chronometer and the golden age of modern steam turbines -- both incredibly complicated, critical, mature designs. Harrison is the genius programmer / software engineer of today, but he was, like today's programmers, operating without an engineering map.
A good set of blueprints and engineering specifications lets an astute and experienced outsider, in only a few minutes, grasp the entire operation of the machine; any particular minutae he cares to focus in on are exposed as well. No such method of documentation, afaik, exists today for complex software designs.
The reason this distinction is critical is not evident in the actual product under consideration. It comes later, in the design of the second product, and the thirtieth, and in the repair of the product (think Y2K), thirty or fifty years later. Solid engineering produces long term benefits, and a lack of an engineering discipline only becomes apparent when people start bitching about how the field is becoming stagnant, a complaint I've been hearing quite regularly about software design.
however, will not be free...
*snickers*
I went. Straight out of high school, and against the advice of my father (who obviously knew me better than I knew myself).
:)
And that first year I spent skipping classes just because I could, and I never had, cost me around $50K in scholarships and the opportunity to graduate from one of the best engineering colleges in the country (CWRU in Cleveland).
So instead I spent the last seven or eight years as a machinist -- good blue collar job, decent pay, and _lots_ of exposure to "non-uni" types. And lots of resentment built toward academia et al. And multiple cancelled (re)start dates.
So if you're at risk of this sort of behavior, my advice is take the time you need now, because if you need it you _will_ take it regardless, and at least now you can defer, which is about as consequence free as it gets
Best of luck to you,
after my heart dropped out of my mouth when i read this ... a quick search and
7 0, 2814259,00.html
http://gamespot.com/gamespot/stories/news/0,108
and it's _upcoming_ and it's on ps2 &c -- not DC
damn.
maybe when deitel & deitel start publishing exploits you'll see more of this...
actual working code is probably the cleanest way to communicate with your average programmer or sysadmin. programmers who follow the whole top down development with stepwise refinement and flow charts EVERY TIME and psuedocode process and somehow always manage to remain platform and language independent are called computer scientists and software engineers and they deserve their titles and their stock options.
but most security alerts are going to come from average hackers (dammit -- i had to say it) and are going to be kinda kludgy and thrown together and the exploit code really ends up being the heart of the whole thing.
so there's my tuppence...