H1-B abuses are well documented. You also forgot to mention how they also inflict downward pressure on everyone else in the industry, so even if you're not directly competing with H1-B folks they are indirectly (and notably) negatively impacting your wages. I won't bother citing references, just look through Slashdot comments along this pops up about every month. The ruling class has fiscal incentives to overlook the problems. Trump may be a lot of things, but if he does win the election it'll be interesting to see if he actually calls a spade a spade and pushes to change the H1-B rigging of the game.
C++ doesn't really have compile-time encapsulation
You mean BINARY encapsulation. C++ doesn't have an ABI, or strong guarantees about source-to-binary
compatibility; never did.
C++ also doesn't have run-time encapsulation or really any serious run-time error checking
that you don't do yourself
You're talking about bounds-checking and the like. That's not run-time encapsulation.
some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")
C++ isn't a great APPLICATION language. Never was. But it beat the alternatives. Java arose as a 'modern COBOL' (essentially) which is one reason it's so widespread - most people build APPLICATIONS, they don't so SYSTEMS programming. Nowadays you have options, of which C++ is but one.
(if it doesn't have encapsulation, why do they call it "object oriented?")
Are you a Smalltalk developer?
Clearly not, or you'd be railing instead of inquiring...
C++'s exception support is hilariously broken. 1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore
What are you smoking? What's allocated, the exception or the surrounding object?
If the exception, why are you throwing something involving the heap?
If the surrounding code, learn what try{} and catch{} are for.
implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection.
Wow. You're clearly not an experienced C++ programmer.
* RAII means using constructors and (more importantly) destructors for auto-magic cleanup on exit of
scope. Java can't do this due to lack of DETERMINISTIC destruction. C# can do it with Disposing. Python can (now, sorta) do this with 'with'. Other languages can do the idiom too. RAII != Garbage Collection.
* reference-counting GC? Well, OK, if you say "refcnt=1". Kinda perverse way to put it.
2) You can't throw exceptions in destructors.
Yes. C++ supports EH, but has some weaknesses if you try to use it pervasively. The Standard C++ Library tries to compensate, but it's hard to live in a pure-EH C++ world (for non-trivial code). Shrug. Nothing's perfect. Which language would you hold up as the pinnacle of EH, and has no other compensating warts? Java? C#? Perl? Eiffel? Smalltalk? D?
3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make
EH blocks are cheap to construct (try), they're costly to use (catch). This is universally true of pretty much every language supporting EH. That's why you use EH for *exceptional* conditions and not normal control flow. If EH is slowing down every function call, you're using it wrong.
I mean you can't even get a goddamn stack trace out of them
You can. I've done it. But not with just the stock compiler; you need some platform-specific support.
OTOH, you don't pay the perf overhead of tracking stack frames so you an provide a call stack, in case the developer wants to get at one.
You can throw arbitrary objects, but the catcher can't figure out what the hell the object is because of C++'s lack of reflection.
Ever hear of RTTI? dynamic_cast?
You betray your ignorance.
C++, in an effort to be sort-of compatible with C (except where it's not compatible with C, which makes you wonder why they bothered in the first place)
You obviously are rather new the programming. C compatibility was (and is) important for C++ success, to
>We've never ranked anything above backwards compatibility.
Bollocks.
2 words: Visual Fred.
How many excuses did Microsoft give why, in their opinion, there was no choice but to break backwards compatibility? Inheritance. Multithreading. Yadda yadda yadda.
Yes, in the past Microsoft typically valued backwards compatibility. Wisely so, IMO.
VB7 was a severe break with that history. To Microsoft's detriment.
It's as if all the developers were gathered into a room, "Everyone who's ever used Visual Basic raise your hand", and those people were escorted out the door, leaving the rest to create the next version.
Bollocks.
VB apps of any realistic size required a near-rewrite to move to VB7.
At which point, you ask, why use VB7 when everyone at MS only talks about using C#, C# and the CLR were co-designed so it's a better fit, and VB.NET is just C# with uglier syntax.
And then you wonder, if I'm looking at a rewrite and retooling anyway, let's go check out what this 'Java' fuss is all about...
Microsoft _encouraged_ their installed base to move elsewhere.
This also had a seriously strategic wound for Office.
VBA was now effectively dead with an equally ugly future.
So now what -- all those folks who bought into Office-as-a-platform and built apps on top of Excel or Word, which means non-trivial VBA - no problem, just rewrite it all in a similar but different...
And we're talking Office. You've just encouraged your installed base to sit-on-its-ass and not upgrade, hoping for a magic solution - or at least milk every last penny out of your existing investment while you can.
Microsoft deserves high praise for its historical bias towards backwards compatibility. When migrating a non-trivial application from VB4->VB5 there were only 2 lines to change - and then only because of a 3rd party naming conflict - that's a good thing. For the customer, as well as Microsoft.
Visual Fred was the beginning of the end.
Never? Not quite.
Not exactly going to snarf up the kind of talent you're looking for (or need).
Microsoft prides itself on paying at the 67th percentile. In case you haven't looked, the stock price has been FLAT for 7 years now. Not a growth stock, and no (regular) dividends like a value stock.
Even if the work life is reasonable (and it can be, in some divisions), you're not going to find bright, driven, capable and experienced people at those rates.
Forget about college pukes. Be deathly afraid at your poor and declining ability to hire and retain people with 5, 10 or 15 years experience.
The senior, experienced, savvy developers.
Forget being millionaires. How about being able to pay the mortgage?
No. Unless Microsoft radically changes compensation (upward) for those who truly deserve and aid (and not merely politicos who appear to), Microsoft's declining market presence is heading on a downward and accelerating slope.
>You're planning to need more than 3GB of resident memory in a single process on your new computer?
Don't available memory with address space.
The latter is FAR more critical, at least on servers doing even non-trivial work, and desktops are starting to get there.
MSXML's XSLT engine is highly optimized, for speed. Not resource consumption. Feed it a 100M input document and perform a trivial XSL transform (e.g. convert every 'X' to 'O') and watch memory usage in PerfMon -- it peaks at >1GB! If you're doing in memory transforms not not i/o, I've seen this routinely fail on real world servers with as little as 30M input - plenty of virtual memory to go around, but not enough contiguous address space to handle the request.
I for one can't wait for 64bit to be available and practical (that means comparable quality drivers and such).
You also forgot to cite the practical considerations -- when things fail (and they will), the more spectacular errors will make that 5-car pile-up on the highway look like a warm sunny day in the park...
And that's merely human error and wear'n'tear. Throw in a little healthy malice and you've got a primo recipe for doom.
See the 3rd Matrix? What would it take for that automated controlled highway of air-cars to become a terrorists dream "fist of death"...
>you dont suddenly stop because some wankers give you a bloody nose.
Here here!
Why were traffic lights instituted?
Anyone ever see photos or stories of cities in early 1900's? My god, the lack of control is staggering! People could get hurt! [Never mind the Chicago gunfights, police corruption, near complete lack of 'civil injury' legal staff and let's not even talk about those blacks and hispanics. But at least they're better than the Irish and...]
Bah. A few loonies put forth a little forethought, show some initiative and display the willpower to carry thru on their convictions, and every lambasts them as "terrorists". Why, there was a time when people were *lauded* for such attitudes. Bah. Kids these days......
The first rule of Ximian Connector Club is you do not talk about Ximian Connector Club.
You cannot talk about the second rule of Ximian Connector Club.
The problem isn't the selection of the "Default" installation.
The problem is the 'Default' installation had non-trivial, non-obvious repercussions and the, what was the word? Ah, yes...fucktard installation developer didn't make this clear during the install.
Don't blame the user for failing to dissassemble the chassis, burn his own eproms and debug the BIOS source code at the machine level.
Slashdot Mirror
You assume foodstamps aren't the next to go
H1-B abuses are well documented. You also forgot to mention how they also inflict downward pressure on everyone else in the industry, so even if you're not directly competing with H1-B folks they are indirectly (and notably) negatively impacting your wages. I won't bother citing references, just look through Slashdot comments along this pops up about every month. The ruling class has fiscal incentives to overlook the problems. Trump may be a lot of things, but if he does win the election it'll be interesting to see if he actually calls a spade a spade and pushes to change the H1-B rigging of the game.
C++ doesn't really have compile-time encapsulation
You mean BINARY encapsulation. C++ doesn't have an ABI, or strong guarantees about source-to-binary compatibility; never did.
C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself
You're talking about bounds-checking and the like. That's not run-time encapsulation.
some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")
C++ isn't a great APPLICATION language. Never was. But it beat the alternatives. Java arose as a 'modern COBOL' (essentially) which is one reason it's so widespread - most people build APPLICATIONS, they don't so SYSTEMS programming. Nowadays you have options, of which C++ is but one.
(if it doesn't have encapsulation, why do they call it "object oriented?")
Are you a Smalltalk developer? Clearly not, or you'd be railing instead of inquiring...
C++'s exception support is hilariously broken. 1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore
What are you smoking? What's allocated, the exception or the surrounding object? If the exception, why are you throwing something involving the heap? If the surrounding code, learn what try{} and catch{} are for.
implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection.
Wow. You're clearly not an experienced C++ programmer. * RAII means using constructors and (more importantly) destructors for auto-magic cleanup on exit of scope. Java can't do this due to lack of DETERMINISTIC destruction. C# can do it with Disposing. Python can (now, sorta) do this with 'with'. Other languages can do the idiom too. RAII != Garbage Collection. * reference-counting GC? Well, OK, if you say "refcnt=1". Kinda perverse way to put it.
2) You can't throw exceptions in destructors.
Yes. C++ supports EH, but has some weaknesses if you try to use it pervasively. The Standard C++ Library tries to compensate, but it's hard to live in a pure-EH C++ world (for non-trivial code). Shrug. Nothing's perfect. Which language would you hold up as the pinnacle of EH, and has no other compensating warts? Java? C#? Perl? Eiffel? Smalltalk? D?
3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make
EH blocks are cheap to construct (try), they're costly to use (catch). This is universally true of pretty much every language supporting EH. That's why you use EH for *exceptional* conditions and not normal control flow. If EH is slowing down every function call, you're using it wrong.
I mean you can't even get a goddamn stack trace out of them
You can. I've done it. But not with just the stock compiler; you need some platform-specific support. OTOH, you don't pay the perf overhead of tracking stack frames so you an provide a call stack, in case the developer wants to get at one.
You can throw arbitrary objects, but the catcher can't figure out what the hell the object is because of C++'s lack of reflection.
Ever hear of RTTI? dynamic_cast? You betray your ignorance.
C++, in an effort to be sort-of compatible with C (except where it's not compatible with C, which makes you wonder why they bothered in the first place)
You obviously are rather new the programming. C compatibility was (and is) important for C++ success, to
Shouldn't the copyright on something published in 1920 have expired by now?
Copyright expires?
American? We started making steel again?
>Thankfully those who get all hot and bothered by an arbitrarily-judged "offensive" word are a dying breed.
One can fucking hope so.
>We've never ranked anything above backwards compatibility. Bollocks. 2 words: Visual Fred. How many excuses did Microsoft give why, in their opinion, there was no choice but to break backwards compatibility? Inheritance. Multithreading. Yadda yadda yadda. Yes, in the past Microsoft typically valued backwards compatibility. Wisely so, IMO. VB7 was a severe break with that history. To Microsoft's detriment. It's as if all the developers were gathered into a room, "Everyone who's ever used Visual Basic raise your hand", and those people were escorted out the door, leaving the rest to create the next version. Bollocks. VB apps of any realistic size required a near-rewrite to move to VB7. At which point, you ask, why use VB7 when everyone at MS only talks about using C#, C# and the CLR were co-designed so it's a better fit, and VB.NET is just C# with uglier syntax. And then you wonder, if I'm looking at a rewrite and retooling anyway, let's go check out what this 'Java' fuss is all about... Microsoft _encouraged_ their installed base to move elsewhere. This also had a seriously strategic wound for Office. VBA was now effectively dead with an equally ugly future. So now what -- all those folks who bought into Office-as-a-platform and built apps on top of Excel or Word, which means non-trivial VBA - no problem, just rewrite it all in a similar but different... And we're talking Office. You've just encouraged your installed base to sit-on-its-ass and not upgrade, hoping for a magic solution - or at least milk every last penny out of your existing investment while you can. Microsoft deserves high praise for its historical bias towards backwards compatibility. When migrating a non-trivial application from VB4->VB5 there were only 2 lines to change - and then only because of a 3rd party naming conflict - that's a good thing. For the customer, as well as Microsoft. Visual Fred was the beginning of the end. Never? Not quite.
First rate talent at Third rate prices.
Not exactly going to snarf up the kind of talent you're looking for (or need).
Microsoft prides itself on paying at the 67th percentile. In case you haven't looked, the stock price has been FLAT for 7 years now. Not a growth stock, and no (regular) dividends like a value stock.
Even if the work life is reasonable (and it can be, in some divisions), you're not going to find bright, driven, capable and experienced people at those rates.
Forget about college pukes. Be deathly afraid at your poor and declining ability to hire and retain people with 5, 10 or 15 years experience.
The senior, experienced, savvy developers.
Forget being millionaires. How about being able to pay the mortgage?
No. Unless Microsoft radically changes compensation (upward) for those who truly deserve and aid (and not merely politicos who appear to), Microsoft's declining market presence is heading on a downward and accelerating slope.
You don't get good talent at shit prices.
>You're planning to need more than 3GB of resident memory in a single process on your new computer? Don't available memory with address space. The latter is FAR more critical, at least on servers doing even non-trivial work, and desktops are starting to get there. MSXML's XSLT engine is highly optimized, for speed. Not resource consumption. Feed it a 100M input document and perform a trivial XSL transform (e.g. convert every 'X' to 'O') and watch memory usage in PerfMon -- it peaks at >1GB! If you're doing in memory transforms not not i/o, I've seen this routinely fail on real world servers with as little as 30M input - plenty of virtual memory to go around, but not enough contiguous address space to handle the request. I for one can't wait for 64bit to be available and practical (that means comparable quality drivers and such).
I'm getting visions of Back to the Future 2.
You also forgot to cite the practical considerations -- when things fail (and they will), the more spectacular errors will make that 5-car pile-up on the highway look like a warm sunny day in the park...
And that's merely human error and wear'n'tear.
Throw in a little healthy malice and you've got a primo recipe for doom.
See the 3rd Matrix?
What would it take for that automated controlled highway of air-cars to become a terrorists dream "fist of death"...
Besides, cars can't fly unless they're atomic powered!
>you dont suddenly stop because some wankers give you a bloody nose. Here here! Why were traffic lights instituted? Anyone ever see photos or stories of cities in early 1900's? My god, the lack of control is staggering! People could get hurt! [Never mind the Chicago gunfights, police corruption, near complete lack of 'civil injury' legal staff and let's not even talk about those blacks and hispanics. But at least they're better than the Irish and...] Bah. A few loonies put forth a little forethought, show some initiative and display the willpower to carry thru on their convictions, and every lambasts them as "terrorists". Why, there was a time when people were *lauded* for such attitudes. Bah. Kids these days......
The first rule of Ximian Connector Club is you do not talk about Ximian Connector Club. You cannot talk about the second rule of Ximian Connector Club.
The problem is the 'Default' installation had non-trivial, non-obvious repercussions and the, what was the word? Ah, yes...fucktard installation developer didn't make this clear during the install.
Don't blame the user for failing to dissassemble the chassis, burn his own eproms and debug the BIOS source code at the machine level.
Come back in 32 months.
Or 34 months if even a lame duck presidency worries you.