I wonder if anyone has done any "econometric" research on how many people would be deterred from writing silly articles for on-line publications were we, as a society, willing to execute the worst offenders.
Seriously, though, if there's anybody out there who thinks the ideas in this article are meant to be taken seriously, i'd say skip the Emerson and read Jonathan Swift's
A Modest Proposal
Perhaps Im jaded, but why, exactly, cant we economically synthesize fuel?
Yes, it goes against the laws of thermodynamics. You can't synthesize something that produces more energy than the amount of energy that you need to synthesize it, roughly speaking.
About the only hope there is for synthesizing fuel is to use some free/cheap energy source (solar/wind) to create a more readily utilized form of energy (for example, hydrogen gas).
A friend of mine did some work on the website of a local bike shop in exchange for a custom titanium/carbon frame from Seven bicycles. Might not sound that exciting, but it's about a $3500 frame.
Bike geeks are almost as bad as computer geeks, though they tend to be thinner.
I have a variation of this question. I've noticed recently that companies have begun to outsource core competency areas rather than just support and maintenance activities. I'm curious to know if the outsourcing companies now realize that if they're producing the product then it's ridiculous to be micro-managed by overpaid foreign executives and project managers. In other words, are the outsourcing companies starting to transition into first-source companies that sell to US and other foreign markets?
I tend to agree that you should avoid the armband MP3 players and GPS watches, but if you're really planning on becoming a regular runner there are a few items i don't think you'd want to live without.
First, real performance apparel. If you're running for more than 30 minutes, don't wear a t-shirt. Get a decent running shirt from a running store. You only need a couple and they're worth the extra money.
Second, if you're running significant miles (like training for a marathon) then get some BodyGlide. There's nothing quite so disturbing as having your nipples start to bleed.
Third, though it's a bit of a luxury, i'd recommend a heart-rate monitor if you are training to race. Even though it's an imprecise science, heart-rate targeted training will make a major difference if your goal is to train optimally. If your goal is to lose some weight and feel more relaxed, then don't even wear a watch. Just run at a comfortable for however long feels good.
However, given the very nature of the project, I feel I may be walking into a bit of a minefield regarding the legalities of such a project, since, as I'm sure you can imagine, this project could easily benefit hostile nations was well as relatively peaceful ones!
Actually, i don't think a missile guidance system would be of much use to a peaceful nation.
Nope, the hard part of developing an open-source defense project is not the legality or even the morality. It's not even the top secret/SCI clearances you'd have to get for everybody who worked on the project. It's the money. Not the cost, since it's presumed you'd do the work for free and give the software away. It's the fact that a defense project isn't a defense project unless you are spending a lot of money. So what i'd suggest is that you draft a *proposal* to develop an open source project for some branch of the military, then form an alliance with Northrop-Grumman or some other big-time defense contractor. Ask for *at least* 50 million dollars, and don't call your project open source, but rather network-centric symbolic code acquisition system (and make sure you thereafter abbreviate it as NCSCAS). Then go off and develop your guidance system, and spend the money however you want. Trust me, nobody will ever know the difference
This is very similar to my own situation. I've been programming for almost 20 years, in environments as diverse as Fortran on Crays, C and C++ on Unix, COM on Windows, and currently J2EE stuff. So i don't think i can complain about lack of diversity or opportunity, and i get paid fairly well. So i've been asking myself often recently why i no longer get any joy from programming.
The only answers i've been able to come up with are 1) programming is no longer valued as an activity by itself, and 2) there are relatively few new problems to handle in industrial/commercial setting. When i first started programming back in the dark ages, programming itself was regarded as a fairly high-skill occupation. There wasn't an API for every imaginable task, and you had to carefully craft your own data structures and be aware of performance and memory usage. The people who really thrived in this environment were people who could "design in their head" so to speak. I'd equate the process to writing-- it was often hard and required numerous attempts, but the end product could have a sort of beauty that your peers could recognize.
The high-value task these days is design. I don't really agree with this viewpoint (see Paul Graham's articles for a more eloquent viewpoint on the role of hacking), but i've got the shelf full of UML books and i can churn artifacts with the best of them. It's just not nearly as fun because you can't execute a design and watch things work.
The second issue is the lack of new problems. I am sometimes convinced that everybody in the world is working on the exact same application integration project. Do you use the word "metadata" 10 times a day? Are you trying to build a query service? Are you trying to untangle message-oriented architectures? Yeah, me too.
Yeah, i know i sound like a sour old bastard, but i miss the days when you could sit down at your computer and write an actual application.
Most programmers that i know who have an interest in security have already set up Windows or Linux boxes with known vulnerabilities and attempted to duplicate known exploits. But knowledge is, at best, half of the picture. In most commercial software endeavors, what's really important is convincing everyone along the chain of command that security is important. This seems like it should be simple, but security is one of those horizontal aspects of software development that adds considerably to the expense of system development, but doesn't add many new features.
Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance. Until threat modeling and code inspections with an eye on security become commonplace, this problem will persist.
I think it's a good idea in comp. sci. *because* it's a pain in the ass. I certainly agree that assembly language is not the easiest or most efficient language for implementing certain algorithms and data structures. I also think it's very instructive to understand why.
I did learn assembly language first. I wouldn't claim to be a wizard (although i'm certainly an old-timer); but i concur with the premise that learning assembly language makes you a better programmer *and* computer scientist. Assembly language exposes you to the basic architecture of the computers that most of work with, and i believe that helps one to understand everything from why certain data structures are preferable in certain situations to basic computational complexity.
I disagree. I think there are clear parallels between poetry and coding (and more tenuously between literature and software systems). I have two arguments for this opinion. The first is that two pieces of code can accomplish the same task, but one may be judged more elegant or beautiful by another coder. This suggests to me that there is a sense of style in code that is in part subjective.
The second argument is that i think both code and poetry more directly reflect the thought of the creator than other forms of language. Shelley said that poetry is "imagining that which we know". Writing code is creating language, but it's also imagining what will happen when that code executes. Basically, i'd say that both poetry and code are very close to thought.
Actually, i've found considerable insight in certain works on software economics, especially the books by Boehm. One of these insights is that the upper limit on software reuse is *not* the cost of rebuilding the same functionality from scratch. Because of certain non-linear factors related to re-design and re-coding, and the extent of the group's familiarity with the code, cost models predict that reusing a given code base can actually cost more than starting from scratch.
This seems well in keeping with real-world experience to me. The bigger problem with the article here is that it claims that code forking does not happen in commercial settings because of cost/market forces. That's nonsense. That might happen in some project manager's fantasy, but it doesn't reflect reality well, imo.
Gee, i know you have to be a bit of dick-swinger to be the CEO, but this is some pretty impressive arrogance.
Seriously though, i can see his point. I can see great potential in this philosophy. For example, every time that a program crashes on my Windows XP machine, Microsoft can sell add space on that dialog that asks if i want to send an error report. When i exit a program without saving, it could say something like "This opportunity to save your data is brought to you by Purina Dog Chow". Thawte could sell fields inside the free e-mail certificates that they distribute so that every time you send a signed message the recipient will see an advertisement. Really, the possibilities are endless. It's "services" like this that make computers the valuable tools they are.
I haven't read comics for about 20 years now, but i don't think that's relevant to determining whether or not i'd like the book being reviewed. I haven't read this book yet, but i read Chabon's novel, and i'd say it was some of the best fiction i'd read in years. The first part of the book, which takes place in the early days of the comic book era, is fascinating-- not because i'm a comic book geek but because the author does a great job conveying the enthusiasm of people creating a new thing (it actually gave me a bit of nostalgia for the internet boom days).
At least this was less offensive than the article that appeared in the employment section of my paper a few weeks ago by an employment consultant who explained how he had to teach all of his high-tech clients basic social skills. He also insisted that they learn some Shakespeare, because this is the sort of thing that geek types don't grok. Of course, the suits all keep copies of "The Tempest" tucked inside their Franklin Planners.
Although i'm sure it's old to this audience, i still prefer Orson Scott Card's take on managing programmers like bees. I found the text of it here
I did a search a couple of months ago to find an open source OLAP, but i couldn't find one. This could simply mean that i didn't look hard enough. About the best thing i came up with was TM/1, which is now owned by Applix . I've done a little probing to see if they ever plan an open source release, but i've found nothing.
I think that Erik Thomsen's book "OLAP Solutions" comes with an evaluation version of TM/1.
Although the use of the smaller Phantom is new, i think the connection of a force feedback device to an STM dates back a while at UNC. I remember seeing a project at the Foresight Nanotech conference in about '93 or '94 that used the Argonne Remote Manipulator (ARM), a one of a kind device that would have been *much* more expensive to recreate than the 15K or so a Phantom runs.
I have an aquaintance who used to work for the NSA. He was an EE who got involved in networks and ending up working on the fiber-optic ATM network that the NSA used in their facility. He treats the spook stuff sort of ironically, referring to the NSA as "The Northern Agency"-- which i think is from some book or movie-- and ocassionally trotting out the "i'd tell you but then i'd have to kill you" line. (i think he's kidding). He did apparently get to ride on one of those jet-assisted cargo planes (C-130?), but he never gives details.
Basically, he's a regular guy whose seen a few more Crays than your average geek. He is into guns and other weapons, but only as a hobby.
Of course, you realize this is all being monitored.
I believe that the problem with pre-emptive patenting is that there is no such legal concept. In other words, a company might claim to be filing a patent pre-emptively, but the law doesn't care. There's nothing that prevents that company, possibly under new management with different ideas, from attempting to enforce the patent.
And, without naming names, this does happen. Even if a company doesn't feel that they can really afford the cost of litigation to enforce a patent, they can still use the patent as a threat (because the other company probably can't afford the lawyers either).
This is not meant to be an insult, but i suspect that some of your disdain for architectural analysis will disappear when you work on bigger projects. I'm personally a hacker at heart, but it simply doesn't work when you get into projects that involve many people, multiple sites, and millions of lines of code. In big projects, like many open source projects, you might never even meet most of the people that you work with. As for the re-factoring book, i think it's about time. There's an old engineering aphorism that goes "if you don't have the time to do it right, when will you find the time to do it over"? I think the opposite is true with Software. There will never be enough time to do it optimally from the start, so refactoring and review is crucial.
Slashdot Mirror
Seriously, though, if there's anybody out there who thinks the ideas in this article are meant to be taken seriously, i'd say skip the Emerson and read Jonathan Swift's A Modest Proposal
Yes, it goes against the laws of thermodynamics. You can't synthesize something that produces more energy than the amount of energy that you need to synthesize it, roughly speaking.
About the only hope there is for synthesizing fuel is to use some free/cheap energy source (solar/wind) to create a more readily utilized form of energy (for example, hydrogen gas).
Bike geeks are almost as bad as computer geeks, though they tend to be thinner.
Then again, maybe the government doesn't have enough money for the better-quality commercial IDS.
I have a variation of this question. I've noticed recently that companies have begun to outsource core competency areas rather than just support and maintenance activities. I'm curious to know if the outsourcing companies now realize that if they're producing the product then it's ridiculous to be micro-managed by overpaid foreign executives and project managers. In other words, are the outsourcing companies starting to transition into first-source companies that sell to US and other foreign markets?
First, real performance apparel. If you're running for more than 30 minutes, don't wear a t-shirt. Get a decent running shirt from a running store. You only need a couple and they're worth the extra money.
Second, if you're running significant miles (like training for a marathon) then get some BodyGlide. There's nothing quite so disturbing as having your nipples start to bleed.
Third, though it's a bit of a luxury, i'd recommend a heart-rate monitor if you are training to race. Even though it's an imprecise science, heart-rate targeted training will make a major difference if your goal is to train optimally. If your goal is to lose some weight and feel more relaxed, then don't even wear a watch. Just run at a comfortable for however long feels good.
Actually, i don't think a missile guidance system would be of much use to a peaceful nation.
Nope, the hard part of developing an open-source defense project is not the legality or even the morality. It's not even the top secret/SCI clearances you'd have to get for everybody who worked on the project. It's the money. Not the cost, since it's presumed you'd do the work for free and give the software away. It's the fact that a defense project isn't a defense project unless you are spending a lot of money. So what i'd suggest is that you draft a *proposal* to develop an open source project for some branch of the military, then form an alliance with Northrop-Grumman or some other big-time defense contractor. Ask for *at least* 50 million dollars, and don't call your project open source, but rather network-centric symbolic code acquisition system (and make sure you thereafter abbreviate it as NCSCAS). Then go off and develop your guidance system, and spend the money however you want. Trust me, nobody will ever know the difference
Virtual flash mob?
The only answers i've been able to come up with are 1) programming is no longer valued as an activity by itself, and 2) there are relatively few new problems to handle in industrial/commercial setting. When i first started programming back in the dark ages, programming itself was regarded as a fairly high-skill occupation. There wasn't an API for every imaginable task, and you had to carefully craft your own data structures and be aware of performance and memory usage. The people who really thrived in this environment were people who could "design in their head" so to speak. I'd equate the process to writing-- it was often hard and required numerous attempts, but the end product could have a sort of beauty that your peers could recognize.
The high-value task these days is design. I don't really agree with this viewpoint (see Paul Graham's articles for a more eloquent viewpoint on the role of hacking), but i've got the shelf full of UML books and i can churn artifacts with the best of them. It's just not nearly as fun because you can't execute a design and watch things work.
The second issue is the lack of new problems. I am sometimes convinced that everybody in the world is working on the exact same application integration project. Do you use the word "metadata" 10 times a day? Are you trying to build a query service? Are you trying to untangle message-oriented architectures? Yeah, me too.
Yeah, i know i sound like a sour old bastard, but i miss the days when you could sit down at your computer and write an actual application.
Most programmers that i know who have an interest in security have already set up Windows or Linux boxes with known vulnerabilities and attempted to duplicate known exploits. But knowledge is, at best, half of the picture. In most commercial software endeavors, what's really important is convincing everyone along the chain of command that security is important. This seems like it should be simple, but security is one of those horizontal aspects of software development that adds considerably to the expense of system development, but doesn't add many new features.
Further complicating the problem is that even if someone were to develop an environment that attempted to prevent all of the problems caused by programmer errors, it would be horrendously complex and would likely kill performance. Until threat modeling and code inspections with an eye on security become commonplace, this problem will persist.
I did learn assembly language first. I wouldn't claim to be a wizard (although i'm certainly an old-timer); but i concur with the premise that learning assembly language makes you a better programmer *and* computer scientist. Assembly language exposes you to the basic architecture of the computers that most of work with, and i believe that helps one to understand everything from why certain data structures are preferable in certain situations to basic computational complexity.
The second argument is that i think both code and poetry more directly reflect the thought of the creator than other forms of language. Shelley said that poetry is "imagining that which we know". Writing code is creating language, but it's also imagining what will happen when that code executes. Basically, i'd say that both poetry and code are very close to thought.
This seems well in keeping with real-world experience to me. The bigger problem with the article here is that it claims that code forking does not happen in commercial settings because of cost/market forces. That's nonsense. That might happen in some project manager's fantasy, but it doesn't reflect reality well, imo.
Based on my own experience with MS software, i think the quote could have been shortened to "We haven't talked to a single user".
Gee, i know you have to be a bit of dick-swinger to be the CEO, but this is some pretty impressive arrogance.
Seriously though, i can see his point. I can see great potential in this philosophy. For example, every time that a program crashes on my Windows XP machine, Microsoft can sell add space on that dialog that asks if i want to send an error report. When i exit a program without saving, it could say something like "This opportunity to save your data is brought to you by Purina Dog Chow". Thawte could sell fields inside the free e-mail certificates that they distribute so that every time you send a signed message the recipient will see an advertisement. Really, the possibilities are endless. It's "services" like this that make computers the valuable tools they are.
I haven't read comics for about 20 years now, but i don't think that's relevant to determining whether or not i'd like the book being reviewed. I haven't read this book yet, but i read Chabon's novel, and i'd say it was some of the best fiction i'd read in years. The first part of the book, which takes place in the early days of the comic book era, is fascinating-- not because i'm a comic book geek but because the author does a great job conveying the enthusiasm of people creating a new thing (it actually gave me a bit of nostalgia for the internet boom days).
Although i'm sure it's old to this audience, i still prefer Orson Scott Card's take on managing programmers like bees. I found the text of it here
I think that Erik Thomsen's book "OLAP Solutions" comes with an evaluation version of TM/1.
Basically, he's a regular guy whose seen a few more Crays than your average geek. He is into guns and other weapons, but only as a hobby.
Of course, you realize this is all being monitored.
And, without naming names, this does happen. Even if a company doesn't feel that they can really afford the cost of litigation to enforce a patent, they can still use the patent as a threat (because the other company probably can't afford the lawyers either).
This is not meant to be an insult, but i suspect that some of your disdain for architectural analysis will disappear when you work on bigger projects. I'm personally a hacker at heart, but it simply doesn't work when you get into projects that involve many people, multiple sites, and millions of lines of code. In big projects, like many open source projects, you might never even meet most of the people that you work with. As for the re-factoring book, i think it's about time. There's an old engineering aphorism that goes "if you don't have the time to do it right, when will you find the time to do it over"? I think the opposite is true with Software. There will never be enough time to do it optimally from the start, so refactoring and review is crucial.