Legally H1Bs MUST be paid the prevailing wage. I'm not sure how much enforcement the DOL does on this, and despite horror stories from Sun Microsystems, this is in fact the law.
I know in my workplace which has both H1Bs and GC/citizens, the rate of pay is the same. In fact the H1Bs cost the company more because of the immigration and relocation costs. At least for my company I think we'd rather hire locals, but as I mentioned elsewhere in this thread, it turns out to be very difficult to hire locals - they just aren't up to the snuff. The nice thing about hiring foreign born talent is all the preselection has been done.
The US is about immigration and building a better life for everyone, I think the H1B program should be more focused on turning 'temporary' workers into permanent residents. I think the biggest flaw in the H1B is training all these foreign engineers then kicking them out after 6 years - why not keep them in the country, it just enriches everyone.
The biggest problem comes when H1Bs are treated like revolving door visas - this is where the salary undercut, the excessive overtime (we can fire you and kick you out of the country!) abuses come into play. If you build a future for these people in the country they take part of civics better and are more resistant to employer abuses.
I have found that the quality of the candidates that reach me (after our recruiters have filtered resumes!) for phone screens tends to be pretty pathetic. For example we generally pass 1 in 10 phone screens. Obviously we hold our candidates to high standards (wouldn't you?), but we certainly aren't looking for anything more than smarts, knows programming well (I've seen candidates misuse subclassing so many times) and can problem solve. This has nothing to do with salary because we can't even get to the phase where we'd tell them how much they'd get paid.
I'm not advocating any increases in immigration caps or anything, but I'm just pointing out that from a recruitment point of view the job market sucks.
Ironically the people who suffer the most in the US are those making between like $15-$40k/yr, especially families. Medicaid doesn't cover people who make too much, and insurance is not affordable for all.
The other trend is the discontinuation of medical insurance programs by various companies. Fewer employees get insurance, and those who do get it pay more than ever before. Benefits may be reduced even. Furthermore with the disappearance of the manufacturing sector, many people are getting jobs at much lower pay scales than before. That is someone who used to make $60,000 as a Boeing employee is now making $11.43/hr as a private security guard. These situations are becoming more and more common.
Of course you got yours, congrats. That was always the motto in the 80s, right? I got mine, you get yours too? Of course the big deal was that the economy wasn't a 0 sum game. In the end the economy isnt entirely a 0 sum game, but there isn't as much slack as we all hoped and thought, no?
Of course considering the average wage in the US is not that high, I think like $45k (you're only making 2.2x the average, so your experience is not really typical is it?). For an alternative explanation see this.
The American health care system routinely denies patients coverage. This is usually after the fact, so people survive the immediate problem, but go into a debt spiral. A Harvard study indicated that 50% of bankruptcies in the US are either directly or indirectly caused by health issues. The stress of dealing with financial issues causes quite a bit of health problems, although they are usually absorbed by businesses in terms of loss productivity.
The assumption belying your statements is that the privately run American healthcare system offers good coverage. This is not true. The first problem is co-pays. If you have any sort of chronic illness, these can really take you down. Usually you aren't getting income because you can't work, and secondly you are seeing specialists at at least $25 each doctor visit (plus anything the insurance company doesn't cover, which is SUBSTANTIAL - the best coverage you can get is 90%). Meanwhile you aren't getting short term disability coverage because those companies routinely deny chronically ill people coverage, so now you are going into debt. This scenario happens to people making a good middle class wage too. I personally know someone who was making over $40k/year and yet fell into debt because of the 'almost-but-not-quite' coverage of even the best corporate sponsored health plans! Some non-corporately sponsored plans don't cover so-called 'pre-existing conditions'. Yep, your child who has had asthma may never get covered under non-governmental or corporate healthcare sponsored plans.
Healthcare costs can take down people who are making well over $100k a year no problem.
For the record, I am a Canadian who has been living in the US for over 3 years. I have seen both systems, and seen the faults of both, but I still think universal coverage is the right thing to do.
I read a reason for this once, and it makes kinda sense. The idea is that by putting it into syspref, you need a new syspref (system preferences) icon for each kind of 'thing', like one for email, one for web browser, etc... instead by making the individual programs responsible for indicating whom will be called by the os to do things, you don't have to expose lots of things in the syspref. having said that, i think it is confusing, and it should probably stay or move back to the sysprefs.
A study recently said that 50% of bankruptcies are either directly related to health costs, or are indirectly related. There is also just plain old 'bad luck' as you experienced.
The idea that tons of bankruptcies is due to irresponsible spending is not backed by the facts.
We have to remember that these laws were created in response to the debtors prisons and other cruel punishments. To dismantle them seems foolish.
Of course credit card companies are purely evil, the whole 'over your (arbitrary) credit limit fee' thing is a backdoor interest. I'm sure that the combined real interest rate and the backdoor 'fee' combined is criminal. I'm not sure what an ursury law it, but I recall being told as a child there were laws to prevent banks and other institutions from charging unreasonable interest rates.
I find it unlikely that CC interest rates will go down because of this bill. At first it will be because "it takes a few years for the effects to kick in", then later on the credit-card companies/banks will raise rates because the prime rate has gone up. Ultimately the extra they saved from this bill will just increase profits.
Having lived in both places, I'd definitely say that Canada has a far superior health care system. Lets just put it this way, if you are in the USA, you are only one major health issue from bankruptcy - even if you are making 6 figures.
I know you were probably joking, but why let an opportunity to correct a misconception slip by?
If your comment is in the first 10-20 top level 2 or rated higher comments, you stand a MUCH better chance of getting mod attention and getting modded up. Thus if you spend time and read a large essay such as this one, you won't be one of those people and thus you wont be a +5 mod comment that thousands of people read. The other way to go is to write something that is controversial to slashdot (eg: see my posting to the recent perl thread), so it gets modded down. Then you get tons of meta-discussion on your top level comment about this and that. Like I said, yesterday's story about Perl gems/wisdom I put something in which got modded from 2 (neutral) -> 0 (offtopic) -> 1 with lots of discussion children.
And they failed... but from my analysis of the film, not because they spent too much money. But because of the following reasons:
- they overestimated the size of the market. - they overestimated the desire of their customers. - They failed to execute.
I think these are the killer 3. I believe their plan was to have customers pay a small fee to pay a parking ticket online. If I already have to pay the city, why would I want to pay even more?
Even if that was not the case, I still remember a key portion of the film where they realized their product was inferior to their competitor's website. This was the killer right here... Since the business model was to put forth convenience, if you don't have the best user interface, then you are screwed. I suspect the root cause of their problems in this area was a lack of skilled individuals who could bring this particular area (UI) to perfect/fruition.
And now I have read some of the essay. Having read the above mentioned book it was too boring to continue on Paul's essay. I'm not sure what Paul knows about starting companies, but I do know that Guy knows a few things.
At one point of the book, Guy points out, with a supporting reference (I don't have the book in front of me now, I lent it to someone doing a new business) that most startups fail not because they don't spend money frugally, but because they fail to execute. He said that if all it took to be successful is to not spend money, then everyone would be working on doors and sawhorse desks.
I completely believe that. To that end, Paul's advice would in fact be wrong. Not spending money (especially where it counts) is not a way to success. Building a product customers want is obviously important, but consider a product like the iPod or original Mac, there was no existing customer base, and customers literally did not know what they wanted. I think Paul's advice while it seems good, is oversimplified to the point that it is essentially useless as a general start-up guide.
A book called 'The Art of the Start'. Written by Guy Kawasaki, who is (in)famous for being apple's chief platform evangelist back in the 80s.
The book is much more detailed based on his experiences at Apple and as his job as CEO of Garage.com - a venture type firm which helps inventors do start ups.
The book is much more detailed than the 'basics' that Paul outlines. It is essentially the old stock market "wisdom" - "buy low sell high". But this is not an operating plan, or a philosophy of starting a business, etc.
Of course I haven't read the essay yet, but if I read the essay I wouldn't be able to post early enough so my comment would be read by a reasonable number of users. Ah, the slashdot paradox.
I used to do small scripts in perl and I originated a fairly complex system in Perl which was written as if it was C++ (no direct access of object values, only methods, etc).
However having said that, I also later inherited a system written in Perl. Thousands of lines, lots of complex data structures. This experience permanently soured me on Perl. While it is possible to write good code in Perl, this doesn't always happen. Especially with the sense that perl is a scripting language that you use to develop hacks or short scripts. The temptation to do a shortcut is too great.
This leads me to another annoyance: Magic. Perl is too magical. To be truly effective in Perl you must know most or all of the magic. If you are unfamiliar with an idiom you have to resort to the manual/books. This means there is not a simple guiding principle (ie: abstraction) you can take and apply to problem solve any situation. The movement to exceptional magical cases is backwards thinking.
None of this matters if you're sitting at home writing one-off cgi-scripts (which is how perl became most famous), but once you move into the area of "professional" development, or at least large scale coordination, you quickly see the value in simple readable code.
In the end, most people who get paid to write code are rewriting and enhancing existing code. If it takes a week to understand a 500 line perl script, the code has probably delivered negative value to your team and company!
Here is a great reason for using a non-locking system such as SVN or CVS... when you use automated refactoring such as available in eclipse and intellij, it touches many files to fix up the code. With a lock-style mechanism it prevents these auto-actions being taken.
One argument I can already hear is 'by minimizing changes we can ensure quality/safety/etc/etc'... this is a false sense of safety. We know that minimal changes really never are safe, the classic 'one line fix' which breaks the world.
The only real solution is frequent and aggressive testing.
I think this split between 'we must control changes' to 'don't slow me down' is the difference between what I call 'old school developers' and newer-style developers. Agile development style vs 'software engineering' which has been proven to not work anymore.
Depends on where you look, C/C++ is _not_ the dominant languages. In middleware/business logic situations (which is a extremely high amount of code being written today), Java is extremely popular. There is an extremely large and well supported library set for doing j2ee/java development. Same with the size of the community (look at the Jakarta project).
The disadvantages of C++/C has been expounded by many, so I won't repeat most of them, but one problem with C++ is what I call the 'hungus links' - for large software projects which have grown organically, links tend to get really large as people followed the 'reuse code' doctrine (not a good idea in an enterprise setting - your code reuse policy has to be unusually strict). Eg: my app takes 970 MB RSS (physical ram) and 1.7 GB VSS (total virtual address) to compile. That takes about 15 minutes to complete.
Fixing it is fairly difficult considering that you could break quite a bit of things and certain types of code-reuse is very difficult to break. The only solution in some cases is to duplicate code to remove functional dependencies between inappropriate component sets.
For the purported design goals of C and C++, they are not inherently flawed - but for a modern business logic development environment they are not the best choice either. Being able to develop faster and safer is usually the goal.
re: meta programming.... aka template metaprogramming...
my co-worker thinks, and i tend to agree, that template meta-programming is a step in the wrong direction for programming. Using advanced compile time templates to achieve certain things do not improve code readability. And if you say that is not important, then please let me know who you are so I can make sure you never get hired at my work. I also don't like Perl for large projects for this reason as well.
The things that are possible in a language such as Objective C with Cocoa (The nextstep AppKit/FoundationKit on OS X) are really impressive - it makes you wonder if we really need more compile-time staticism. Being able to dynamically handle the world is a major plus, and template meta programs aren't really giving us the explicit ability to handle run-time dynamicism. You can build a while layer of run-time dynamism, but that doesn't necessarily write my core-project faster.
I'm in a similar boat as you, and one major productivity loss is crashes due to lame things like segvs. When you are trying to support a production environment where developer time and long term batch-speed is the bigger problem, a system like Java works out great.
At work we are just about to make the switch from C++ to Java. It helps tons that our C++ platform is really crufty and sucky - Oracle accessors which use %-style specification strings and a lame-ass C++ MFC-looking object library. The switch is a no-brainer, plus the refactoring support that Eclipse and Intellij sports really make the whole deal even better.
Modern business software development is about agility (or at least it should be) and minimising development time. A $7000 Mac workstatin with 8 gb ram is cheap compared to the average software developer salary.
This sounds similar to the ActiveX permissons system which did not work so well. Users click on 'ok' over and over until the program runs to their satisfaction.
To call it the user's fault is an unsophisticated view. The better view is to recognise user's motivations and psychological underpinnings and work with it. If this means designing a system with less flexibility then so be it.
The problem with computer companies such as Microsoft and others, is they are so heavily concentrated on technology and only technology - they forget their users. The classic example is to provide flexibility at the expense of usability. Some people might argue the entire office suite embodies this concept.
Slashdot Mirror
Legally H1Bs MUST be paid the prevailing wage. I'm not sure how much enforcement the DOL does on this, and despite horror stories from Sun Microsystems, this is in fact the law.
I know in my workplace which has both H1Bs and GC/citizens, the rate of pay is the same. In fact the H1Bs cost the company more because of the immigration and relocation costs. At least for my company I think we'd rather hire locals, but as I mentioned elsewhere in this thread, it turns out to be very difficult to hire locals - they just aren't up to the snuff. The nice thing about hiring foreign born talent is all the preselection has been done.
The US is about immigration and building a better life for everyone, I think the H1B program should be more focused on turning 'temporary' workers into permanent residents. I think the biggest flaw in the H1B is training all these foreign engineers then kicking them out after 6 years - why not keep them in the country, it just enriches everyone.
The biggest problem comes when H1Bs are treated like revolving door visas - this is where the salary undercut, the excessive overtime (we can fire you and kick you out of the country!) abuses come into play. If you build a future for these people in the country they take part of civics better and are more resistant to employer abuses.
Sounds like we work at the same place... blue badge or yellow badge?
I have found that the quality of the candidates that reach me (after our recruiters have filtered resumes!) for phone screens tends to be pretty pathetic. For example we generally pass 1 in 10 phone screens. Obviously we hold our candidates to high standards (wouldn't you?), but we certainly aren't looking for anything more than smarts, knows programming well (I've seen candidates misuse subclassing so many times) and can problem solve. This has nothing to do with salary because we can't even get to the phase where we'd tell them how much they'd get paid.
I'm not advocating any increases in immigration caps or anything, but I'm just pointing out that from a recruitment point of view the job market sucks.
Ironically the people who suffer the most in the US are those making between like $15-$40k/yr, especially families. Medicaid doesn't cover people who make too much, and insurance is not affordable for all.
The other trend is the discontinuation of medical insurance programs by various companies. Fewer employees get insurance, and those who do get it pay more than ever before. Benefits may be reduced even. Furthermore with the disappearance of the manufacturing sector, many people are getting jobs at much lower pay scales than before. That is someone who used to make $60,000 as a Boeing employee is now making $11.43/hr as a private security guard. These situations are becoming more and more common.
Of course you got yours, congrats. That was always the motto in the 80s, right? I got mine, you get yours too? Of course the big deal was that the economy wasn't a 0 sum game. In the end the economy isnt entirely a 0 sum game, but there isn't as much slack as we all hoped and thought, no?
Of course considering the average wage in the US is not that high, I think like $45k (you're only making 2.2x the average, so your experience is not really typical is it?). For an alternative explanation see this.
What about the people who make less than $15k a year?
I guess there is really 2 ways of looking at things:
- how can we provide the best for the best?
- how can we provide for everyone?
I invoke Godwin's law. You have lost this online discussion.
Thanks for the lack of civility.
-ryan
The American health care system routinely denies patients coverage. This is usually after the fact, so people survive the immediate problem, but go into a debt spiral. A Harvard study indicated that 50% of bankruptcies in the US are either directly or indirectly caused by health issues. The stress of dealing with financial issues causes quite a bit of health problems, although they are usually absorbed by businesses in terms of loss productivity.
The assumption belying your statements is that the privately run American healthcare system offers good coverage. This is not true. The first problem is co-pays. If you have any sort of chronic illness, these can really take you down. Usually you aren't getting income because you can't work, and secondly you are seeing specialists at at least $25 each doctor visit (plus anything the insurance company doesn't cover, which is SUBSTANTIAL - the best coverage you can get is 90%). Meanwhile you aren't getting short term disability coverage because those companies routinely deny chronically ill people coverage, so now you are going into debt. This scenario happens to people making a good middle class wage too. I personally know someone who was making over $40k/year and yet fell into debt because of the 'almost-but-not-quite' coverage of even the best corporate sponsored health plans! Some non-corporately sponsored plans don't cover so-called 'pre-existing conditions'. Yep, your child who has had asthma may never get covered under non-governmental or corporate healthcare sponsored plans.
Healthcare costs can take down people who are making well over $100k a year no problem.
For the record, I am a Canadian who has been living in the US for over 3 years. I have seen both systems, and seen the faults of both, but I still think universal coverage is the right thing to do.
I read a reason for this once, and it makes kinda sense. The idea is that by putting it into syspref, you need a new syspref (system preferences) icon for each kind of 'thing', like one for email, one for web browser, etc... instead by making the individual programs responsible for indicating whom will be called by the os to do things, you don't have to expose lots of things in the syspref. having said that, i think it is confusing, and it should probably stay or move back to the sysprefs.
-ryan
A study recently said that 50% of bankruptcies are either directly related to health costs, or are indirectly related. There is also just plain old 'bad luck' as you experienced.
The idea that tons of bankruptcies is due to irresponsible spending is not backed by the facts.
We have to remember that these laws were created in response to the debtors prisons and other cruel punishments. To dismantle them seems foolish.
Of course credit card companies are purely evil, the whole 'over your (arbitrary) credit limit fee' thing is a backdoor interest. I'm sure that the combined real interest rate and the backdoor 'fee' combined is criminal. I'm not sure what an ursury law it, but I recall being told as a child there were laws to prevent banks and other institutions from charging unreasonable interest rates.
I find it unlikely that CC interest rates will go down because of this bill. At first it will be because "it takes a few years for the effects to kick in", then later on the credit-card companies/banks will raise rates because the prime rate has gone up. Ultimately the extra they saved from this bill will just increase profits.
Hey, guess what? SHUT UP!!!
:-)
The best part is since I'm in the most populous western Time Zone is I can afford to be a jerk, since I have millions of people on my side.
Anyways, don't you mean
02-04-2005 ?
Having lived in both places, I'd definitely say that Canada has a far superior health care system. Lets just put it this way, if you are in the USA, you are only one major health issue from bankruptcy - even if you are making 6 figures.
I know you were probably joking, but why let an opportunity to correct a misconception slip by?
If your comment is in the first 10-20 top level 2 or rated higher comments, you stand a MUCH better chance of getting mod attention and getting modded up. Thus if you spend time and read a large essay such as this one, you won't be one of those people and thus you wont be a +5 mod comment that thousands of people read. The other way to go is to write something that is controversial to slashdot (eg: see my posting to the recent perl thread), so it gets modded down. Then you get tons of meta-discussion on your top level comment about this and that. Like I said, yesterday's story about Perl gems/wisdom I put something in which got modded from 2 (neutral) -> 0 (offtopic) -> 1 with lots of discussion children.
It's all about causing discussion and arguments.
And they failed... but from my analysis of the film, not because they spent too much money. But because of the following reasons:
- they overestimated the size of the market.
- they overestimated the desire of their customers.
- They failed to execute.
I think these are the killer 3. I believe their plan was to have customers pay a small fee to pay a parking ticket online. If I already have to pay the city, why would I want to pay even more?
Even if that was not the case, I still remember a key portion of the film where they realized their product was inferior to their competitor's website. This was the killer right here... Since the business model was to put forth convenience, if you don't have the best user interface, then you are screwed. I suspect the root cause of their problems in this area was a lack of skilled individuals who could bring this particular area (UI) to perfect/fruition.
Good movie though.
And now I have read some of the essay. Having read the above mentioned book it was too boring to continue on Paul's essay. I'm not sure what Paul knows about starting companies, but I do know that Guy knows a few things.
At one point of the book, Guy points out, with a supporting reference (I don't have the book in front of me now, I lent it to someone doing a new business) that most startups fail not because they don't spend money frugally, but because they fail to execute. He said that if all it took to be successful is to not spend money, then everyone would be working on doors and sawhorse desks.
I completely believe that. To that end, Paul's advice would in fact be wrong. Not spending money (especially where it counts) is not a way to success. Building a product customers want is obviously important, but consider a product like the iPod or original Mac, there was no existing customer base, and customers literally did not know what they wanted. I think Paul's advice while it seems good, is oversimplified to the point that it is essentially useless as a general start-up guide.
A book called 'The Art of the Start'. Written by Guy Kawasaki, who is (in)famous for being apple's chief platform evangelist back in the 80s.
The book is much more detailed based on his experiences at Apple and as his job as CEO of Garage.com - a venture type firm which helps inventors do start ups.
The book is much more detailed than the 'basics' that Paul outlines. It is essentially the old stock market "wisdom" - "buy low sell high". But this is not an operating plan, or a philosophy of starting a business, etc.
Of course I haven't read the essay yet, but if I read the essay I wouldn't be able to post early enough so my comment would be read by a reasonable number of users. Ah, the slashdot paradox.
I used to do small scripts in perl and I originated a fairly complex system in Perl which was written as if it was C++ (no direct access of object values, only methods, etc).
However having said that, I also later inherited a system written in Perl. Thousands of lines, lots of complex data structures. This experience permanently soured me on Perl. While it is possible to write good code in Perl, this doesn't always happen. Especially with the sense that perl is a scripting language that you use to develop hacks or short scripts. The temptation to do a shortcut is too great.
This leads me to another annoyance: Magic. Perl is too magical. To be truly effective in Perl you must know most or all of the magic. If you are unfamiliar with an idiom you have to resort to the manual/books. This means there is not a simple guiding principle (ie: abstraction) you can take and apply to problem solve any situation. The movement to exceptional magical cases is backwards thinking.
None of this matters if you're sitting at home writing one-off cgi-scripts (which is how perl became most famous), but once you move into the area of "professional" development, or at least large scale coordination, you quickly see the value in simple readable code.
In the end, most people who get paid to write code are rewriting and enhancing existing code. If it takes a week to understand a 500 line perl script, the code has probably delivered negative value to your team and company!
ok, what have they invented in the last 1500 years?!
Thanks for the post, I have held the position that China hasn't invented anything recently, and this seems to support my position.
Here is a great reason for using a non-locking system such as SVN or CVS... when you use automated refactoring such as available in eclipse and intellij, it touches many files to fix up the code. With a lock-style mechanism it prevents these auto-actions being taken.
One argument I can already hear is 'by minimizing changes we can ensure quality/safety/etc/etc'... this is a false sense of safety. We know that minimal changes really never are safe, the classic 'one line fix' which breaks the world.
The only real solution is frequent and aggressive testing.
I think this split between 'we must control changes' to 'don't slow me down' is the difference between what I call 'old school developers' and newer-style developers. Agile development style vs 'software engineering' which has been proven to not work anymore.
Depends on where you look, C/C++ is _not_ the dominant languages. In middleware/business logic situations (which is a extremely high amount of code being written today), Java is extremely popular. There is an extremely large and well supported library set for doing j2ee/java development. Same with the size of the community (look at the Jakarta project).
The disadvantages of C++/C has been expounded by many, so I won't repeat most of them, but one problem with C++ is what I call the 'hungus links' - for large software projects which have grown organically, links tend to get really large as people followed the 'reuse code' doctrine (not a good idea in an enterprise setting - your code reuse policy has to be unusually strict). Eg: my app takes 970 MB RSS (physical ram) and 1.7 GB VSS (total virtual address) to compile. That takes about 15 minutes to complete.
Fixing it is fairly difficult considering that you could break quite a bit of things and certain types of code-reuse is very difficult to break. The only solution in some cases is to duplicate code to remove functional dependencies between inappropriate component sets.
For the purported design goals of C and C++, they are not inherently flawed - but for a modern business logic development environment they are not the best choice either. Being able to develop faster and safer is usually the goal.
re: meta programming.... aka template metaprogramming...
my co-worker thinks, and i tend to agree, that template meta-programming is a step in the wrong direction for programming. Using advanced compile time templates to achieve certain things do not improve code readability. And if you say that is not important, then please let me know who you are so I can make sure you never get hired at my work. I also don't like Perl for large projects for this reason as well.
The things that are possible in a language such as Objective C with Cocoa (The nextstep AppKit/FoundationKit on OS X) are really impressive - it makes you wonder if we really need more compile-time staticism. Being able to dynamically handle the world is a major plus, and template meta programs aren't really giving us the explicit ability to handle run-time dynamicism. You can build a while layer of run-time dynamism, but that doesn't necessarily write my core-project faster.
I'm in a similar boat as you, and one major productivity loss is crashes due to lame things like segvs. When you are trying to support a production environment where developer time and long term batch-speed is the bigger problem, a system like Java works out great.
At work we are just about to make the switch from C++ to Java. It helps tons that our C++ platform is really crufty and sucky - Oracle accessors which use %-style specification strings and a lame-ass C++ MFC-looking object library. The switch is a no-brainer, plus the refactoring support that Eclipse and Intellij sports really make the whole deal even better.
Modern business software development is about agility (or at least it should be) and minimising development time. A $7000 Mac workstatin with 8 gb ram is cheap compared to the average software developer salary.
Aspects seem like a clean way to handle this.
I'm not an expert in AspectJ (yet...) so I can't say for certainty, but it seems like this might work out very nicely.
This sounds similar to the ActiveX permissons system which did not work so well. Users click on 'ok' over and over until the program runs to their satisfaction.
To call it the user's fault is an unsophisticated view. The better view is to recognise user's motivations and psychological underpinnings and work with it. If this means designing a system with less flexibility then so be it.
The problem with computer companies such as Microsoft and others, is they are so heavily concentrated on technology and only technology - they forget their users. The classic example is to provide flexibility at the expense of usability. Some people might argue the entire office suite embodies this concept.
ups == teh sux!!!
I can't wait until amazon starts using DHL (airborne's infrastructure in the US) and avoids the mega-hub problem that UPS and FedEx have.
Go DHL!! Kick ass on UPS (their tracking sucks damnit)