No it doesn't. The fixed cost auction system doesn't do either. It encourages replacement at the high end because the fixed cost isn't going to be big enough to be a discouragement and doesn't allow for rare skills at the low end. A percentage based system does both.
The C++ object model was basically that a simple inheritance model. Classes were union structures that had a self pointer. Methods were just offsets against that pointer in assembly. Inheritance was effectively a code copy. How can you be more simple that that?
FWIW LISPs can be written which run very close to the metal. The Apply / Eval structure works with metal. Apply uses a memory frame (like you see in x86 assembler) and eval breaks down into CPU primitives. In the 1970s and early 1980s there were even LISP based CPUs.
A world of LISP based hardware is a road not taken not a road that couldn't have been taken.
I always liked Forth. Concatenative programming tends to lead to some great "ground up" designs. As a successor to Forth, PostScript was actually a quite good programming language but almost no one knew it (they just had computers put out PostScript code). One of the things I like about Haskell is how it encourages Concatenative programming like Forth did while offering better control structures.
Safe and secure are two factors that are important. Here are some others:
a) Code can be written quickly b) Code is portable c) Debugging times are low d) Code is reliable, i.e. factors of the execution environment don't effect computed results e) Problem domain is large f) Has a huge range of specialized libraries g) Has a following so that it is easy to hire in the problem domain h) Can be learned quickly i) Has a set of primitives that pair well with the problem domain j) Code executes quickly k) Code makes efficient use of system resources etc...
Any decent language is going to excel at some aspects in exchange for being dreadful at others. Popular languages are popular because they excel at particular problem domains. C excels in 2014 where safety isn't a major concern because most C programs don't have a complex API, or where execution speed is paramount.
Well to go off topic for a second. What is the news with Rust? I know Samsung was backing it, but I haven't heard anything in well over a year. Anything happening exciting on the Rust from?
First off I'd consider C++ and Objective-C to both be variants of C. And you can make a fairly good case that Java is also a variant of C.
That being said there is a good use case for C by itself. Lots of algorithms execution times are of forms like R*n^2 + S*n + T. For N large, A is all that matters. For N small T can often be the dominant factor. The C language, like assembly excels at getting the execution times for T down. However for most business processing execution time isn't really all that important since n isn't large nor is T particularly big. In which case programmer efficiency matters a great deal.
That hits the top of the market pretty hard. You'd have lots of H1B executives, lawyers, doctors... That just eliminates H1B below a certain threshold.
Because that's too hard to regulate. By fudging around you can make the H1B still cheaper. It is much harder to do that with a 50% surcharge on top. Besides there is no advantage to Americans in driving up the wages of non-Americans.
How is that better than a tax? The issue btw is not market clearing the H1Bs but rather that tech companies want the number of H1Bs expanded. You are optimizing the opposite problem.
gwolf the IRS already figures out comparatives: company, position,... We have a pretty good idea of the prevailing wages for most jobs. But even if we did have a situation where a $100k slot is being replaced by a $40k slot the 50% tax means that $20k of that goes towards the public. The public also benefits somewhat from the $40k and somewhat from the $40k in savings. That $20k in raw public benefit does a lot of good.
They can always sue but if they have little chance of winning and / or there is very little money at stake may simply let it ride.
Most likely they would let it slide. Most contract breaches people let it slide. As for enforceability I think it likely is so I'm disagreeing with your lawyer.
If it were me and a client wanted to hire me as an employee and not a contractor, I'd let the client know I need to discuss this with the agency due to my employment contract and then reach out to the agency. That way I'd be completely up front with everyone and have the client watching out for my back as well. Chances are the agency doesn't want to upset a client and may already have contractual agreements to deal with such a circumstance.
That's what the contract obligates you to do. They get a referral fee from your hire often.
There are limited advantage to Americans in H1Bs getting higher wages. There is a clear advantage to Americans in taxes being offset. Tax displacement helps boost underlying standard of livings and thus redistributes wealth to the people being harmed.
I think the point of the H1B system should be highly specialized skill sets that aren't readily available. For example specialists in an obscure aspect of an obscure technology. The solution to getting more competent people in general should be training and education. As far as why make it a tax, is because the H1B system creates economic dislocation i.e. generalized harm. The tax offsets the harm by creating a generalized good. It also offsets the lower wage incentive.
As far as creating categories of workers, remember with a large tax the government's incentives flip. They are likely to be rather strict in how the tax is applied once this is a meaningful source of revenue.
I was made to sign a document wherein I could not negotiate employment with a client company directly. A lawyer told me that document does not hold up in court because no one can stop you from looking for work.
That one I'd check on. They can't stop you from looking for work, but they can hold you liable for the costs to the recruiting firm of replacing a temp worker and you were in breach of contract. So you might have to pay tens of thousands in damages to the temp agency.
I'd get rid of the proof and just use a tax. Require a tax of 50% of the prevailing USA citizen wage for similar technology workers on top of what gets paid to the H1B. Then allow unlimited H1Bs. That makes sure the incentive isn't economic.
Almost no one signed a non disparagement clause. To sign that sort of thing you generally get severance. There are plenty is displaced workers available to get interviews from. Tech workers don't get interviewed mostly for the same reason steel workers or book editors don't get interviewed they don't have anything particularly insightful to say.
Moreover H1B has nothing to do with offshore outsourcing those are entirely different programs. H1B is allowing people to come to the USA to work, offshoring is part of having low tariffs, and often incentives.
Yes and no. Google and Facebook want an accurate picture of their user's interests. They want you to freely send them data. Which means they can't be doing anything which causes you to become cautious. Always being logged in, having only one account...
Oracle as a company has been moving up market. A trusted vendor to the fortune 100, state and federal government. They still have clients below that level but they are going after big money clients. They've been disrupted from below.
Oracle the product gets criticism I think mainly from people who have never admin a complex database.
Why would "the IT guy" by which I assume you mean helpdesk have access to server level encryption at all? He doesn't know it, the end users don't know it.
a) The limited amount of cooperation the tech firms provided b) The heavy amount of cooperation the telco firms provided c) The NSA successfully breaking some encryption systems because they are good at their job and (b).
Silicon Valley companies were not eager participants but rather reluctant participants. However they can't fully disclose the extent of their involvement because of secrecy laws. Yes encryption systems have been attacked in ways that are complex. Yes they are likely to be attacked. But that is far different from them being worthless. The situation is far better today than it would be if there were no encryption at all.
Then you break keys apart. No one has the full key other than the target. A system can easily have have 5 underlying private keys where you need any 4 of the 5 of decrypt and any entity only has one.
Slashdot Mirror
No it doesn't. The fixed cost auction system doesn't do either. It encourages replacement at the high end because the fixed cost isn't going to be big enough to be a discouragement and doesn't allow for rare skills at the low end. A percentage based system does both.
BTW just to add another example Haskell's original design did that as well. GHC originally compiled to C/GCC.
The C++ object model was basically that a simple inheritance model. Classes were union structures that had a self pointer. Methods were just offsets against that pointer in assembly. Inheritance was effectively a code copy. How can you be more simple that that?
In terms of a JIT... https://gcc.gnu.org/wiki/JIT
FWIW LISPs can be written which run very close to the metal. The Apply / Eval structure works with metal. Apply uses a memory frame (like you see in x86 assembler) and eval breaks down into CPU primitives. In the 1970s and early 1980s there were even LISP based CPUs.
A world of LISP based hardware is a road not taken not a road that couldn't have been taken.
I always liked Forth. Concatenative programming tends to lead to some great "ground up" designs. As a successor to Forth, PostScript was actually a quite good programming language but almost no one knew it (they just had computers put out PostScript code). One of the things I like about Haskell is how it encourages Concatenative programming like Forth did while offering better control structures.
No reason to duck.
Safe and secure are two factors that are important. Here are some others:
a) Code can be written quickly
b) Code is portable
c) Debugging times are low
d) Code is reliable, i.e. factors of the execution environment don't effect computed results
e) Problem domain is large
f) Has a huge range of specialized libraries
g) Has a following so that it is easy to hire in the problem domain
h) Can be learned quickly
i) Has a set of primitives that pair well with the problem domain
j) Code executes quickly
k) Code makes efficient use of system resources
etc...
Any decent language is going to excel at some aspects in exchange for being dreadful at others. Popular languages are popular because they excel at particular problem domains. C excels in 2014 where safety isn't a major concern because most C programs don't have a complex API, or where execution speed is paramount.
Well to go off topic for a second. What is the news with Rust? I know Samsung was backing it, but I haven't heard anything in well over a year. Anything happening exciting on the Rust from?
First off I'd consider C++ and Objective-C to both be variants of C. And you can make a fairly good case that Java is also a variant of C.
That being said there is a good use case for C by itself. Lots of algorithms execution times are of forms like R*n^2 + S*n + T. For N large, A is all that matters. For N small T can often be the dominant factor. The C language, like assembly excels at getting the execution times for T down. However for most business processing execution time isn't really all that important since n isn't large nor is T particularly big. In which case programmer efficiency matters a great deal.
Obvious a guild / professional association like the bar association or AMA would be great. I'm just solving the smaller problem.
That hits the top of the market pretty hard. You'd have lots of H1B executives, lawyers, doctors... That just eliminates H1B below a certain threshold.
Oh, you right, Whoosh. You got me.
Because that's too hard to regulate. By fudging around you can make the H1B still cheaper. It is much harder to do that with a 50% surcharge on top. Besides there is no advantage to Americans in driving up the wages of non-Americans.
How is that better than a tax? The issue btw is not market clearing the H1Bs but rather that tech companies want the number of H1Bs expanded. You are optimizing the opposite problem.
gwolf the IRS already figures out comparatives: company, position, ... We have a pretty good idea of the prevailing wages for most jobs. But even if we did have a situation where a $100k slot is being replaced by a $40k slot the 50% tax means that $20k of that goes towards the public. The public also benefits somewhat from the $40k and somewhat from the $40k in savings. That $20k in raw public benefit does a lot of good.
Most likely they would let it slide. Most contract breaches people let it slide. As for enforceability I think it likely is so I'm disagreeing with your lawyer.
That's what the contract obligates you to do. They get a referral fee from your hire often.
There are limited advantage to Americans in H1Bs getting higher wages. There is a clear advantage to Americans in taxes being offset. Tax displacement helps boost underlying standard of livings and thus redistributes wealth to the people being harmed.
I think the point of the H1B system should be highly specialized skill sets that aren't readily available. For example specialists in an obscure aspect of an obscure technology. The solution to getting more competent people in general should be training and education. As far as why make it a tax, is because the H1B system creates economic dislocation i.e. generalized harm. The tax offsets the harm by creating a generalized good. It also offsets the lower wage incentive.
As far as creating categories of workers, remember with a large tax the government's incentives flip. They are likely to be rather strict in how the tax is applied once this is a meaningful source of revenue.
That one I'd check on. They can't stop you from looking for work, but they can hold you liable for the costs to the recruiting firm of replacing a temp worker and you were in breach of contract. So you might have to pay tens of thousands in damages to the temp agency.
I'd get rid of the proof and just use a tax. Require a tax of 50% of the prevailing USA citizen wage for similar technology workers on top of what gets paid to the H1B. Then allow unlimited H1Bs. That makes sure the incentive isn't economic.
Almost no one signed a non disparagement clause. To sign that sort of thing you generally get severance. There are plenty is displaced workers available to get interviews from. Tech workers don't get interviewed mostly for the same reason steel workers or book editors don't get interviewed they don't have anything particularly insightful to say.
Moreover H1B has nothing to do with offshore outsourcing those are entirely different programs. H1B is allowing people to come to the USA to work, offshoring is part of having low tariffs, and often incentives.
Yes and no. Google and Facebook want an accurate picture of their user's interests. They want you to freely send them data. Which means they can't be doing anything which causes you to become cautious. Always being logged in, having only one account...
Oracle as a company has been moving up market. A trusted vendor to the fortune 100, state and federal government. They still have clients below that level but they are going after big money clients. They've been disrupted from below.
Oracle the product gets criticism I think mainly from people who have never admin a complex database.
Why would "the IT guy" by which I assume you mean helpdesk have access to server level encryption at all? He doesn't know it, the end users don't know it.
I think the article is conflating three things:
a) The limited amount of cooperation the tech firms provided
b) The heavy amount of cooperation the telco firms provided
c) The NSA successfully breaking some encryption systems because they are good at their job and (b).
Silicon Valley companies were not eager participants but rather reluctant participants. However they can't fully disclose the extent of their involvement because of secrecy laws. Yes encryption systems have been attacked in ways that are complex. Yes they are likely to be attacked. But that is far different from them being worthless. The situation is far better today than it would be if there were no encryption at all.
Then you break keys apart. No one has the full key other than the target. A system can easily have have 5 underlying private keys where you need any 4 of the 5 of decrypt and any entity only has one.