Actually, it's pretty easy to talk your way out of that. You just hire H1B's at a lower level of seniority and, hence, they would naturally receive lower pay.
I've worked at Microsoft and though I'm not really sure how much salary H1B folks receive, I know that Microsoft has standardized pay brackets regardless of whether or not you're an H1B. Hence, you could argue that Microsoft, and probably others, already pay the same salaries to H1Bs as they do to American citizens in the same level of seniority.
The issue is that foreign workers are often willing to take a demotion in their seniority for the chance to come to the USA.
We don't need to put blame on anything. A kid cannot really learn to drive from GTA. I'm sure he learned a lot more from watching his parents drive; but we're not gonna say it's somehow wrong for a kid to watch someone drive, are we?
It's ridiculous that they would single out GTA when thee are so many REAL LIFE places where he could have learned to drive. It's just a damn excuse to blame video games again.
I'm not sure what you're driving at here because: a.) I never said Ruby will kill PHP b.) I didn't say Ruby will appeal to everyone
As for "fads," Ruby and PHP have both been around for about 13 years now. Ruby is not some new kid on the block. Rails came along later and really popularized Ruby in the web world, but Ruby as a language is hardly a fad.
Dude, comon, it's not about books or making money. I am a former PHP programmer who has switched to Rails; and as far as I'm concerned, it *is* the better platform (that said, if you like PHP, I think it's a fine platform too).
I not only like the elegance of the Rails framework, but I like many things about Ruby including the easy use of anonymous functions. Now you may discount anonymous functions as syntactic sugar, but it comes in very useful in so many situations to the point where I don't understand how I lived without it. You could argue it's even a critical part to many applications and even the foundation of Google's Map-Reduce algorithm (Joel on Software has an excellent blog entry about functional programming here: http://www.joelonsoftware.com/items/2006/08/01.html)
As for Twitter, that is not a good example because they had a bunch of other issues going on. I happen to work personally at times with the guys from Powerset.com (who use Ruby + Rails extensively). As it turns out, they had a discussion with the head developers at Twitter when they went with Rails and they found out that Twitter's issues were not a result of Ruby or Rails. Don't believe me? Check out point #3 here http://glu.ttono.us/articles/2007/06/21/powerset-to-launch-front-end-on-ruby.
"high level" enough is a relative term. For me, PHP is not enough unless you put it together with one of the MVC frameworks like CakePHP or Symfony.
In any case, there are a ton of people (including myself) who like Ruby better for a variety of reasons and we don't have problems with it being too slow (though faster speed is always a welcome improvement).
Point is: if you want to use PHP, do it. I don't really care to "persuade" you otherwise. But it's always annoying to see such comparison on a thread like this 'cause this thread has nothing to do with PHP and no one really cares if you like it better:-)
We'll we've beat this horse to death, but here's the thing about DOS... the gold standard changed after the product became all but useless.
If vendor lock-in is the primary concern, then I'm not comfortable going with App Engine when low level parts are closed source; especially I have so many other options available for deploying my web site (yes, maybe those other options will require more work to scale than App Engine, but that's a price I'd pay).
Well the only point I'm making is that a Windows-only app is as much lock in as a Google App Engine app. Which to me is too much lock-in.
As for you assertion that I think "everything" is vendor lock-in, that's not true. I think anything with an open source "gold standard" is not vendor lock-in. The reason is simply because you have the ability to use a starting point that is really viable if you want to fork. You don't get that when the gold standard itself is closed source.
Also, not to mention the fact that the very title of this article is "Windows Azure Offers Developers Iron-Clad Lock-In". I mean the bias is apparent even from the article titles:-)
By the way, I should point out that your argument is essentially saying that DOS was not vendor lock-in and neither is Windows; since both of them have open source reimplementations.
If this is what you really believe, then I would just say that your belief is likely not shared by the majority of people and I won't bother to argue any further.
You need a dictionary. Badly.
Wine is a reimplementation of Windows. Windows itself has not been released as open source. It has, however, been reimplemented in Wine, and in ReactOS. And Wine absolutely is open source, as is ReactOS.
Yes, and Hadoop is a reimplementation of Big Table. That's the whole point: just because a reimplementation exists, doesn't make the original project open source. That's exactly what I'm saying.
The reason it is lock-in is because the original implementation by Google is considered the gold standard and they can change that standard at any time without you knowing what happened behind the scenes. This is in contrast to PHP, Ruby, Perl, etc where you can easily fork their implementation.
And yes, DOS is also vendor lock-in for the same reason just as Windows is and just as.NET is. Wine and Mono are not real alternatives to the original, closed source, un-forkable gold standard.
You need a dictionary. Badly.
Wow, very childish. This may be Slashdot, but we can have a discussion without resorting to personal insults.
I will concede that the posts are not as positive as I remembered them to be, but I think the bias is still evident if you compare this thread to the one on App Engine.
AppDrop is that particular Ruby on Rails application you're looking at on the site, not Google App Engine itself. That whole thing is probably barely even half a meg of source code. It's just a way to upload files to App Engine and has nothing to do with the App Engine platform code itself.
Hell, just looking at the source code, I could have written that myself in probably 20 minutes.
I didn't say "released", I said "reimplemented".
What does that mean? How can something by reimplemented as open source without being released as open source? If you don't have access to the source code, then by definition it is not open source.
By your logic, every Microsoft product is implemented as open source because the team creating it has the source code, but they don't release it to anyone else.
And Hadoop has done exactly that. [apache.org]
Hadoop doesn't claim any compatibility with Big Table, it is just their best-guess copy of Hadoop based on the white paper published by Google. If that is what passes for "open source" then DOS should be considered open source since FreeDOS was based off it. Hell, even Windows should be since Wine is modeled after it.
Microsoft publishes hundreds of papers on functionality in Windows internals, but just because someone can build a "best-guess copy" of it doesn't make the Microsoft product open source.
I'm mostly with you on this, but Microsoft does have a bit of a head start on this. I cam almost guarantee that much (all?) of the API's for this platform will be based on.NET. Given how much traction.NET already has, it's definitely a head start compared to, say, learning Salesforce's syntax.
I call B.S. Please enlighten us on exactly how it has been reimplemented as open source? All of your storage is still done using Google's Big Table and the GQL query language. If you can find me the source for Big Table, please show it to me.
Forget iPhone, let's do a real apples-to-apples comparison and ask if this is any different from Google's App Engine which is another cloud computing platform.
I, for one, never cease to be amazed at the unabashed fanboy nature that happens on some of these topics. I mean as much as I love Google, App Engine was total vendor lock-in. Crippled Python + Google's own custom libraries (not all open source either) + big table dependency = vendor lock-in. Yet, when Google released, I saw nothing but praise on these forums.
Now somehow it's different just because Microsoft is doing it.
Jeez, who cares. It's just an EULA you have to accept once. Stop f'n whining about it.
Re:It's nice for little things.
on
Rails Recipes
·
· Score: 1
It's a fact that I know a guy who can program perfectly in x86 assembly, but did horribly in programming Visual Basic. Ok, so what does that prove? The answer is nothing.
Because you saw some guys who can program Rails, but not PHP doesn't mean anything. It's a fact, but doesn't really mean anything. My post about Beust is also a fact. So I guess we both have facts that have diverging implications.
In other words, the fact that you "witnessed" it or that it is a "fact" doesn't mean anything. Unless you can give me some broad consensus or some study on ability and productivity of Rails programmers vs others, you should just be content with saying that you and I are presenting opposing viewpoints.
-Aamer
Re:It's nice for little things.
on
Rails Recipes
·
· Score: 1
People who were never able to write programs in, say, CGI, PHP, or servlets/JSP, are writing Rails apps without much difficulty. Funny, Google engineer Cedric Beust has almost the exact opposite viewpoint.
According to Beust, "(Ruby is) a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb."
Also he says "Ruby on Rails is just too advanced. I'm serious... For talented developers, these features are a dream come true... (but) sometimes, too much magic is too much magic, and it can definitely be the case that the flow of code is too direct or too clever to be understandable by regular developers."
Re:It's nice for little things.
on
Rails Recipes
·
· Score: 4, Interesting
Because it's not compiled, it seems like it's not a good idea for really large projects either. You wanna bet? Look at 37signals which successfully runs large projects on Rails. It's not compiled, but neither is PHP. Since Rails runs as a persistent app, in a production environment, it only loads most of the application into memory once. At that point, in all practicality, you will hardly ever run into performance bottlenecks that can't be fixed by scaling out.
Admittedly, Rails debugging tools cannot compare to those of.NET or J2EE, but the issue of being compiled will hardly ever come up in practicality.
really couldn't find any reason why I'd want to use it above PHP Cause it's a fully integrated framework. Try using plain, vanilla PHP and see how much boilerplate code you write to connect to your database, to retrieve data, to implement Ajax. Then tell me how easy it keep your code clean and modularized when you start to build up your site. And don't even get me started on building automated tests into your application. I used use PHP exclusively, but I've never looked back.
As a side note, there are some frameworks in PHP now that can compare to the Rails way of doing things (like CakePHP or Symphony). I still prefer Ruby as a language, but those frameworks seem pretty decent. However, I don't think you can compare pure vanilla PHP to Rails.
Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Yeah, the whole thing about writing good, clean code is pretty annoying. If you're ok with writing shitty code, then by all means, don't ever use Rails:-)
Agreed. I don't respect the guy, but I wouldn't make the comments that have been made on this thread after the man's death either. Just browsing through the replies to your post reassures me of the immaturity of (most) people on this forum.
Slashdot Mirror
"The common threat is ... China"
So much for not painting things as "black and white."
... don't forget to look at the hidden title text on that one. I think that sums it up pretty accurately.
Actually, it's pretty easy to talk your way out of that. You just hire H1B's at a lower level of seniority and, hence, they would naturally receive lower pay.
I've worked at Microsoft and though I'm not really sure how much salary H1B folks receive, I know that Microsoft has standardized pay brackets regardless of whether or not you're an H1B. Hence, you could argue that Microsoft, and probably others, already pay the same salaries to H1Bs as they do to American citizens in the same level of seniority.
The issue is that foreign workers are often willing to take a demotion in their seniority for the chance to come to the USA.
We don't need to put blame on anything. A kid cannot really learn to drive from GTA. I'm sure he learned a lot more from watching his parents drive; but we're not gonna say it's somehow wrong for a kid to watch someone drive, are we?
It's ridiculous that they would single out GTA when thee are so many REAL LIFE places where he could have learned to drive. It's just a damn excuse to blame video games again.
I'm not sure what you're driving at here because:
a.) I never said Ruby will kill PHP
b.) I didn't say Ruby will appeal to everyone
As for "fads," Ruby and PHP have both been around for about 13 years now. Ruby is not some new kid on the block. Rails came along later and really popularized Ruby in the web world, but Ruby as a language is hardly a fad.
Dude, comon, it's not about books or making money. I am a former PHP programmer who has switched to Rails; and as far as I'm concerned, it *is* the better platform (that said, if you like PHP, I think it's a fine platform too). I not only like the elegance of the Rails framework, but I like many things about Ruby including the easy use of anonymous functions. Now you may discount anonymous functions as syntactic sugar, but it comes in very useful in so many situations to the point where I don't understand how I lived without it. You could argue it's even a critical part to many applications and even the foundation of Google's Map-Reduce algorithm (Joel on Software has an excellent blog entry about functional programming here: http://www.joelonsoftware.com/items/2006/08/01.html) As for Twitter, that is not a good example because they had a bunch of other issues going on. I happen to work personally at times with the guys from Powerset.com (who use Ruby + Rails extensively). As it turns out, they had a discussion with the head developers at Twitter when they went with Rails and they found out that Twitter's issues were not a result of Ruby or Rails. Don't believe me? Check out point #3 here http://glu.ttono.us/articles/2007/06/21/powerset-to-launch-front-end-on-ruby.
"high level" enough is a relative term. For me, PHP is not enough unless you put it together with one of the MVC frameworks like CakePHP or Symfony. In any case, there are a ton of people (including myself) who like Ruby better for a variety of reasons and we don't have problems with it being too slow (though faster speed is always a welcome improvement). Point is: if you want to use PHP, do it. I don't really care to "persuade" you otherwise. But it's always annoying to see such comparison on a thread like this 'cause this thread has nothing to do with PHP and no one really cares if you like it better :-)
Out of curiosity, why are you not eligible?
We'll we've beat this horse to death, but here's the thing about DOS ... the gold standard changed after the product became all but useless.
If vendor lock-in is the primary concern, then I'm not comfortable going with App Engine when low level parts are closed source; especially I have so many other options available for deploying my web site (yes, maybe those other options will require more work to scale than App Engine, but that's a price I'd pay).
Well the only point I'm making is that a Windows-only app is as much lock in as a Google App Engine app. Which to me is too much lock-in. As for you assertion that I think "everything" is vendor lock-in, that's not true. I think anything with an open source "gold standard" is not vendor lock-in. The reason is simply because you have the ability to use a starting point that is really viable if you want to fork. You don't get that when the gold standard itself is closed source.
You didn't answer the second post I made. According to you, nothing is vendor-lockin since even reimplementations of DOS and Windows exist.
Also, not to mention the fact that the very title of this article is "Windows Azure Offers Developers Iron-Clad Lock-In". I mean the bias is apparent even from the article titles :-)
By the way, I should point out that your argument is essentially saying that DOS was not vendor lock-in and neither is Windows; since both of them have open source reimplementations.
If this is what you really believe, then I would just say that your belief is likely not shared by the majority of people and I won't bother to argue any further.
You need a dictionary. Badly. Wine is a reimplementation of Windows. Windows itself has not been released as open source. It has, however, been reimplemented in Wine, and in ReactOS. And Wine absolutely is open source, as is ReactOS.
Yes, and Hadoop is a reimplementation of Big Table. That's the whole point: just because a reimplementation exists, doesn't make the original project open source. That's exactly what I'm saying. The reason it is lock-in is because the original implementation by Google is considered the gold standard and they can change that standard at any time without you knowing what happened behind the scenes. This is in contrast to PHP, Ruby, Perl, etc where you can easily fork their implementation. And yes, DOS is also vendor lock-in for the same reason just as Windows is and just as .NET is. Wine and Mono are not real alternatives to the original, closed source, un-forkable gold standard.
You need a dictionary. Badly.
Wow, very childish. This may be Slashdot, but we can have a discussion without resorting to personal insults.
I will concede that the posts are not as positive as I remembered them to be, but I think the bias is still evident if you compare this thread to the one on App Engine.
Right here. [appdrop.com]
AppDrop is that particular Ruby on Rails application you're looking at on the site, not Google App Engine itself. That whole thing is probably barely even half a meg of source code. It's just a way to upload files to App Engine and has nothing to do with the App Engine platform code itself. Hell, just looking at the source code, I could have written that myself in probably 20 minutes.
I didn't say "released", I said "reimplemented".
What does that mean? How can something by reimplemented as open source without being released as open source? If you don't have access to the source code, then by definition it is not open source. By your logic, every Microsoft product is implemented as open source because the team creating it has the source code, but they don't release it to anyone else.
And Hadoop has done exactly that. [apache.org]
Hadoop doesn't claim any compatibility with Big Table, it is just their best-guess copy of Hadoop based on the white paper published by Google. If that is what passes for "open source" then DOS should be considered open source since FreeDOS was based off it. Hell, even Windows should be since Wine is modeled after it. Microsoft publishes hundreds of papers on functionality in Windows internals, but just because someone can build a "best-guess copy" of it doesn't make the Microsoft product open source.
I'm mostly with you on this, but Microsoft does have a bit of a head start on this. I cam almost guarantee that much (all?) of the API's for this platform will be based on .NET. Given how much traction .NET already has, it's definitely a head start compared to, say, learning Salesforce's syntax.
I call B.S. Please enlighten us on exactly how it has been reimplemented as open source? All of your storage is still done using Google's Big Table and the GQL query language. If you can find me the source for Big Table, please show it to me.
Forget iPhone, let's do a real apples-to-apples comparison and ask if this is any different from Google's App Engine which is another cloud computing platform. I, for one, never cease to be amazed at the unabashed fanboy nature that happens on some of these topics. I mean as much as I love Google, App Engine was total vendor lock-in. Crippled Python + Google's own custom libraries (not all open source either) + big table dependency = vendor lock-in. Yet, when Google released, I saw nothing but praise on these forums. Now somehow it's different just because Microsoft is doing it.
Jeez, who cares. It's just an EULA you have to accept once. Stop f'n whining about it.
It's a fact that I know a guy who can program perfectly in x86 assembly, but did horribly in programming Visual Basic. Ok, so what does that prove? The answer is nothing.
Because you saw some guys who can program Rails, but not PHP doesn't mean anything. It's a fact, but doesn't really mean anything. My post about Beust is also a fact. So I guess we both have facts that have diverging implications.
In other words, the fact that you "witnessed" it or that it is a "fact" doesn't mean anything. Unless you can give me some broad consensus or some study on ability and productivity of Rails programmers vs others, you should just be content with saying that you and I are presenting opposing viewpoints.
-Aamer
According to Beust, "(Ruby is) a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb."
Also he says "Ruby on Rails is just too advanced. I'm serious
Source: http://beust.com/weblog/archives/000382.html
Admittedly, Rails debugging tools cannot compare to those of
As a side note, there are some frameworks in PHP now that can compare to the Rails way of doing things (like CakePHP or Symphony). I still prefer Ruby as a language, but those frameworks seem pretty decent. However, I don't think you can compare pure vanilla PHP to Rails. Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Yeah, the whole thing about writing good, clean code is pretty annoying. If you're ok with writing shitty code, then by all means, don't ever use Rails
-Aamer
... as well as North Korea
Agreed. I don't respect the guy, but I wouldn't make the comments that have been made on this thread after the man's death either. Just browsing through the replies to your post reassures me of the immaturity of (most) people on this forum.