I totally agree that there's an unfortunate clash between keyboard/console and mouse/GUI input at present. It's silly that I can form vastly more powerful commands at a prompt than with a mouse, and yet it's so hard to just select a list of arbitrary files to operate on in that command line (or, for those who prefer the mouse, to highlight *.bak to move elsewhere).
I think the fundamental problem with today's GUIs is the way they receive input. Sure, you can have your super-3D-funky-translucency-skinned-configurable-w idgets, but ultimately they just display the same stuff slightly differently. When I can
use the mouse and keyboard together, effectively
script everything properly
then we'll be getting somewhere. I rate the second point almost as important as the first, BTW. Serious people don't like repeating themselves, they use scripts. Today's GUI front-ends are absurdly hard to script, which is kinda silly since most of them fundamentally use a messaging architecture underneath, and the technology to do it has been around for years.
Once I've got sensible input, from whatever devices, then I think the desktop metaphor is getting a little tired and we could do better now, but that's way down the list of things I'd like to see improved.
...if it's a better product than the alternatives. But hey, I make my living doing this stuff, so maybe I can't afford to prefer OS as a requirement over performance, stability and other such trivia.
Frankly, I couldn't give a **** if it's OS or not, because I'm never going to have time to read all the source and make sure I agree with it. I bet you aren't either. However, rather than assuming that anything closed source will be worse than the OS competition, I'm prepared to take a look at how it performs, evaluate it using meaningful criteria, and base my choices on the results.
I give up. You're either much better informed about the exact details of this than the rest of us, or just incredibly stupid (or naive).
If I agree to let someone else use my code for some compensation, then I generally have some sort of licence agreement or other contract that specifies how they may use it. It is that agreement that governs whether or not they may GPL it, distribute it, or whatever. The fact that I haven't checked their whole business out (as if I had any right or ability to do that anyway) does not mean they are exempt from the agreement, nor that they may use my code in ways not specified in that agreement (or otherwise allowed to them in law). If this were not the case, the whole software business would fall apart, as no-one could afford to sell their code to a wide market since they'd have to check out every single buyer's intent.
You are arguing that the complete opposite is true, that the obligation to understand how things are used rests with the seller and not the buyer. You have totally failed to justify your position based on any legal references anywhere, and you are arguing for a position that would be totally impractical if you actually tried to implement it. Why do you bother?
It amazes me that nobody else has pointed out the obvious yet. We already have this model. In fact, in the US, there's even a provision in the Constitution for it. It's called intellectual property. Y'know, the thing that says you can't copy stuff, or use a patented technique, for a while after it's first created, and then everyone can have it? (Readers planning to rant about Disney and the extension of copyright dates may save their fingers; we all thought it, and it doesn't change my point.)
Before anyone asks me to go RTFA, yes, I realize that this does not make provision for also releasing the code when a certain amount of money has been raised, but this has happened regardless in some cases. (See, for example, iD's release of the code for their earlier games well before it would have been out of copyright. They were ahead of the game on shareware, and on that, too.)
It was a specific agreement they negotiated, and they were either aware or should have been aware that the other company incorporated GPL'ed code.
So you keep saying, but if there was a specific agreement, did it allow for the release of source code under terms compatible with the GPL? And why were they aware or should they have been aware of the relevance of the GPL here? What do you know about this case that the rest of us don't?
How does that follow at all? Every time a major vendor sells a product with a licence agreement, they enter into a contract with the buyer. Are they assumed to be aware of how that buyer intends to use the product, and to give up all rights they would otherwise have over it? You are basically arguing that not only to EULAs have no legal validity -- which we all know is a largely untested area of law anyway -- but that it is the vendor's responsibility to be aware of the wishes of every buyer, which turns established practice on its head. Where is the legal or moral basis for this?
If [the third parties] decide to sue, use the GPL as a defense.
Summary finding against the defendant who breaches the rights of the third parties, I'm guessing. You just lost.
The fact that the people making the derived product gave it to you under a licence agreement they had no right to agree does not automatically excuse you from any obligations you have if you're in posession of code that belongs to third parties. If those parties have also actually told you that you are breaching their rights, and a court finds that you have persisted in doing so, I don't think you have much of a leg to stand on in any major Western legal system, even those that might allow a defence of ignorance initially.
Big big difference here, in that these other corporations ALLOWED their code to be incorporated into the code by this other company. If they wanted their code not to be GPL'ed, they had the OBLIGATION to make sure that that other company wasn't integrating/mixing their code with GPL'ed code in a way in which the GPL doesn't allow (unless you distribute it under the GPL). Again, THEIR responsibility.
Suppose I write a library, which I choose to distribute under some licence that forbids giving away the source code. Are you saying that I must check the intentions of everyone buying my library, to make sure that they aren't planning to GPL it and give away the code, and that if I fail to do so, my code automatically becomes GPL'd?
Could you please cite even the slightest shred of copyright law in your chosen jurisdiction or even common sense that supports this claim?
While the advantages of exposing functionality to the outside world are beyond debate...
Um... No. The advantages of exposing systems currently implemented in some in-house client-server way to the outside world are far from proven in most cases.
Exposing things to the outside world guarantees only one thing in itself: you will be subject to more security vulnerabilities than you ever had before.
Yes, but company T ALLOWED company D to integrate company T's code with company D's GPL-modified code. Thus, company T agreed to allow their code to be GPL'ed.
I'm sorry, but that sounds like the hopeful philosophy of a GPL fan, not the legal advice of an informed lawyer. There are so many holes in that argument that even I can spot, I can't believe it would -- or should -- ever hold up in court.
I'm no expert in US law (I don't live there), but even with my basic knowledge of how it works and reading the obviously simplified summary here, I can see that most of the posts offering legal advice here are way off base. The scary thing is that equally off-base people are clearly moderating them up because they sound convincing, regardless of their legal correctness!
It seems to me that the only sensible action for the original poster to take immediately (aside from speaking to a lawyer again) can be some sort of legal move to force those who derived from his GPL'd work to either GPL the derivative (if they can) or stop distributing it. If the derived work cannot be GPL'd because it also includes indepently licensed third-party bits, then that narrows the options to one.
I don't understand why the OP is so keen to host the derived now-supposedly-GPL'd work using his own resources, though. He gains no obvious benefit from doing so, and if US law allows for penalties for distributing code contrary to its licence, it seems to leave him open to action by the third parties if they are being ripped off. If US law actually says that the OP can distribute something just because someone told him it was GPL'd, even though it actually wasn't, it would be about the only legal system in the Western world that did...
Bullshit. They may have the copyright to their work, but they can don't get to choose whether or not to GPL their software (if its based on GPL'ed software). They can choose to distribute it and GPL it, or not to distribute it at all.
But by the sounds of it, the third parties' code was never based on GPL'd code.
As I read this, the poster made a GPL app, call it G. Someone else took this, and made another app derived from it, D. In D was also included some third party code, call it T. G is GPL'd, and the copyright holder for G therefore has the right to go after the makers of D for licence infringement. However, it sounds as though the makers of D have tried to GPL it. If they don't own the rights to the other third party code in it (from T) then they would not normally have that right (which would belong to the copyright holders of T, if they chose to do it). There is no way that the original poster can force the third party authors of T to release their code under the GPL if it isn't derived from GPL code itself.
What this seems to come down to is that the authors of the derived app D are screwed, because they've got GPL'd stuff they can't make proprietary and proprietary stuff they can't GPL in their code, and thus they can't distribute it at all under any licence.
But, of course, this is just a speculation based on the summary here, and it should go without saying that the OP needs to contact someone who can actually make a proper appraisal of the legal situation.
I realise that this isn't what you want to hear, but I think you're being a little overdramatic here.
As I argued previously, even with low figures for engineering school intakes, the industry as a whole will not suffer greatly in the long run. There are a lot more engineers out there with a few years of experience than there are new grads, and most of them will still be there in five years as well. The market won't suddenly get crowded again, it'll ramp up slowly, and during that period, it will attract back those who've left the field, and a new generation of grads. Failing all else, they'll just recruit skilled labour from overseas. It certainly won't suddenly all stop because a few new graduates got above themselves and stormed off to sulk elsewhere.
Also, a recent graduate does not necessarily have zero experience.
No, but they will have fairly minimal experience. The best you could hope for would normally be something like a year out doing a relevant full time job before or during university (unlikely in this field) or good vacation experience (which helps, but usually isn't anything like the real thing).
I've also been keeping up on my own projects, trying to increase my knowledge of C++, and have real experience taking a product from concept to completion. I had to learn Visual C++, assembly, Java, TCP programming, USB interfacing, and PCB design within a six month period, while attending classes with their own projects and demands.
Here we see exactly the problem. If you came to me, and claimed you'd learned VC++, Java, an assembly language and a few other skills to a professional standard, all in six months, I would file you under "deluded" and move on. It probably takes six months of full time work with good guidance and training to get up to speed with one of those skills to a professional standard, and even then you'll only be at the bottom of the scale. In the real world, you don't get bonus points for writing lots of buzzwords on a resume, you get bonus points for actually knowing your stuff. Your efforts are to your credit and very commendedable, but it won't help to overstate what you've learned.
The older engineers I know, for the most part, aren't willing to devote more time than necessary to a project.... They are invaluable for their guidance and know-how, but it's the engineers in their mid-20's who will order some pizzas and hack on a problem until 11:00 PM, just because they want to succeed and are genuinely interested in their work.
It's also those same engineers who will, at 11pm, be adding those nasty little bugs that are going to get fixed by the older and wiser the following week. Working absurd hours isn't impressive, it's stupid and error-prone. It might impress a crappy manager, but it certainly won't impress a skilled and experienced engineer. The reason the older and wiser don't do this -- families and such or not -- is because they have learned that it does more harm than good. As you said yourself, they don't devote more time than is necessary to a project. Doing so is... well... unnecessary.
I'm not sure about the C++ GC stuff. AFAICS, there's nothing to stop you writing your own full-blown GC, as long as your platform supports suitable multithreading and sync'ing protocols to let you co-ordinate between a GC'd pointer and a GC thread. You give up the portability and deterministic destruction, but such will always be the price of a GC system in a language with low-level features anyway.
I'm in two minds about OCaml as well, but I don't really know enough of it to have a well-informed opinion. I like the elegance and simplicity of SML, and somehow the OO and non-declarative parts of OCaml seem out of place in a functional language, powerful as they may be. Perhaps that's just because I mentally draw an inappropriate line between your average procedural/OO language and the declarative/functional world of ML, though.
I know exactly where you're coming from -- I graduated around four years ago, and I've seen much the same in software development. OTOH, I've learned that new graduates frequently over-rate themselves.
The companies you mention aren't hiring new grads because they're a liability. They are unknowns, whereas taking on someone with a couple years experience means you get a known quantity. Yes, you pay more for them, but in all probability, they will also be much more effective, and justify the higher salary. It simply makes good commercial sense to do this when times are hard.
I'm afraid your argument about running out of engineers doesn't really hold water, either. If demand is down at present, the fact that fewer people are going into training is not a problem. If the demand starts to rise again in a few years, there will still be all the engineers who've been working in the field, plus all the graduates arriving at that point (in increasing numbers, for the same reason they're decreasing now).
If today's new engineers choose to walk away, rather than keeping their hand in, then they will be the ones who lose out in five years, not the established guys or the newbies. If they keep their skills up-to-date, though, even if that means taking a lower paid or less than ideal job for now, then they'll be prime hiring material when the market picks up again further down the line.
One reason our economy is generally so strong relative to other countries is that companies have the flexibility to hire and layoff as economic times change. Even in this time of distress, our economy is still doing better than most.
Really? I'm not in the US, but all the feedback we're seeing in Europe has you guys taking this much harder than most.
And there is no reason that my friend who is having these issue should have to change....if he was once worth $60K(actually he was worth alot more)...he should still be worth that...
On the contrary, in this business things do change, and fast. Cutting edge skills that made you highly valuable three or four years ago are now out of date. If your friend hasn't changed to match, he simply isn't worth $60K any more. You can dislike this fact as much as you like, but it's still a fact.
Also, it must be noted that the industry was doing much better than average at that stage, and it paid accordingly. That was never going to continue indefinitely, and expecting salaries to continue as far ahead of the working average as they were was always silly. If your friend failed to plan for that, I'm afraid that again, he has no-one to blame but himself.
I agree with much of what you write, but I'd place the emphasis differently. I don't think the access to low-level features in C++ is a problem. Rather, the problem is that they are used by default by most C++ programmers, probably because of the way the C++ community developed from the C one, and the fact that even today most C++ textbooks and tutors aren't good at de-emphasizing this. C++ itself provides high level equivalents to all of the things you mention, which are usually substituted trivially for the dangerous low-level ones. There should be no reason, in typical high-level C++ code, to ever use a raw pointer, unchecked array or unsafe cast; you have smart pointers, vector, dynamic_cast and such instead.
Oh, and don't even get me started on Java's generics. A whole new generation of ill-informed Java evangelists is about to rise up and tell us how C++'s templates are no longer an advantage, because they haven't noticed that in C++ you can do more than write generic containers with them.:-(
Oh, and I agree that functional languages are nice, BTW. I would be very happy programming in a language that has the elegance of functional languages and the raw power of things like C and C++. Now if only some clever programmer would invent it...
I think the argument that open source implies better security is overrated. While it is possible for anyone to check the source code, almost no-one actually has the technical expertise, time and inclination to do so. Everyone else just trusts that other people will do so, which makes them every bit as vulnerable as those who installed a closed source system in the first place. The same goes for creating and distributing a patch: even in the Linux world, a high proportion of the development work in this area is actually done by the big distro vendors, not by the OSS community as a whole.
Compare and contrast with a closed source product from a good company. As others have noted elsewhere in this thread, Apple has turned out security fixes within nine hours from being notified of a vulnerability in the past. I'm betting you can't make that claim of many Linux patches.
Please don't equate Microsoft with closed source and Linux with open source. If you do, your comparisons will always be fundamentally flawed. I agree that security through obscurity is not the way forward, but just disclosing something (when that something is millions of lines of source code) is not, in itself, enough to provide security either.
I only mean to point out Java as a *language* that has better abstraction properties than C++.
I'm curious about why you say this, because I would have said that C++'s single biggest strength was precisely that you can write software at a reasonably high level of abstraction most of the time, but also go to a lower level as and when necessary.
Surely Java's big strength relative to C++ is its vast and reasonably portable standard libraries, rather than the expressive power of the language itself? In the latter respect, C++ offers several considerably stronger features in the OO area (most significantly, probably, deterministic destruction), and of course there's all the whizzy stuff you can do with templates now that compilers are supporting them close to fully.
In contrast, most of Java's oft-cited "advantages" are simply features that are missing, and which you're at liberty to ignore in C++ as well. The only two big things that come to mind otherwise are the garbage collection and the provision of a finally keyword, and both of these are readily countered by that deterministic destruction, as long as you have someone smart enough to use it (which, bizarrely, many C++ programmers don't seem to be).
C++'s template wizardry may never be quite as smooth and efficient as native language features for things like closures, discriminated unions and pattern matching, but today's libraries are getting close enough to be very useful in practice. The lack of such things in Java is one of its major weaknesses in terms of abstraction tools, IMHO. I've worked on several large (well, >1MLOC, anyway) C++ projects that have been made very much nicer by the use of such things.
Then there is all of this HTML-mail javascript exploit crap. Now you are getting closer to the point -- this shit is fundementally flawed sandboxing and has to be fixed or trashed -- but it still has nothing to do with system-level APIs and script langugages.
I think you just made my point for me. There is no reason any content of any e-mail message should be passed through any script engine. The fact that it can be effectively creates a whole new set of APIs for anyone sending an e-mail message, and those APIs are being abused to spread viruses. The prosecution rests, your honour.
No problem. MS do indeed have many shady practices regarding upgrades, and I'll be right behind you in the queue to bash them for it. It's just that they finally put in something potentially useful in this particular case.;-)
I don't like to criticise, but I'd hesitate to recommend your rewritten resume as an example. Since CV writing is quite a personal thing, I'll just list my reservations below with the most serious first, and let anyone else look at both and decide for themselves whether they agree.
It's much too long. The reason that many people advocate a single page CV for new graduates is that most people can only usefully fill a single page at that stage in their career. To me, most resumes at any stage in a career should probably be two pages long. No-one needs all those little details of previous experience on a CV. It's only there to get you the interview, where you can discuss the details if they're relevant.
It doesn't scan easily. Most humans screening a CV will scan for 15-20 seconds looking for vital information (level of education, rough idea of previous experience, most relevant skills). They will then ditch anything that hasn't caught them by that time. After that, you've got about two more minutes as they check some details before they make a final decision. I cannot, in 15-20 seconds, confidently establish any of the three big things mentioned above from this resume.
The unusual layout doesn't help. Stick with standard formats unless you've got a good reason to be creative (perhaps applying for a job as a graphic designer). Either go for skills-centric, or chronological, or a sensible combination of both, depending on what strengths you want to highlight.
Slashdot Mirror
I totally agree that there's an unfortunate clash between keyboard/console and mouse/GUI input at present. It's silly that I can form vastly more powerful commands at a prompt than with a mouse, and yet it's so hard to just select a list of arbitrary files to operate on in that command line (or, for those who prefer the mouse, to highlight *.bak to move elsewhere).
I think the fundamental problem with today's GUIs is the way they receive input. Sure, you can have your super-3D-funky-translucency-skinned-configurable-w idgets, but ultimately they just display the same stuff slightly differently. When I can
then we'll be getting somewhere. I rate the second point almost as important as the first, BTW. Serious people don't like repeating themselves, they use scripts. Today's GUI front-ends are absurdly hard to script, which is kinda silly since most of them fundamentally use a messaging architecture underneath, and the technology to do it has been around for years.
Once I've got sensible input, from whatever devices, then I think the desktop metaphor is getting a little tired and we could do better now, but that's way down the list of things I'd like to see improved.
...if it's a better product than the alternatives. But hey, I make my living doing this stuff, so maybe I can't afford to prefer OS as a requirement over performance, stability and other such trivia.
Frankly, I couldn't give a **** if it's OS or not, because I'm never going to have time to read all the source and make sure I agree with it. I bet you aren't either. However, rather than assuming that anything closed source will be worse than the OS competition, I'm prepared to take a look at how it performs, evaluate it using meaningful criteria, and base my choices on the results.
I give up. You're either much better informed about the exact details of this than the rest of us, or just incredibly stupid (or naive).
If I agree to let someone else use my code for some compensation, then I generally have some sort of licence agreement or other contract that specifies how they may use it. It is that agreement that governs whether or not they may GPL it, distribute it, or whatever. The fact that I haven't checked their whole business out (as if I had any right or ability to do that anyway) does not mean they are exempt from the agreement, nor that they may use my code in ways not specified in that agreement (or otherwise allowed to them in law). If this were not the case, the whole software business would fall apart, as no-one could afford to sell their code to a wide market since they'd have to check out every single buyer's intent.
You are arguing that the complete opposite is true, that the obligation to understand how things are used rests with the seller and not the buyer. You have totally failed to justify your position based on any legal references anywhere, and you are arguing for a position that would be totally impractical if you actually tried to implement it. Why do you bother?
It amazes me that nobody else has pointed out the obvious yet. We already have this model. In fact, in the US, there's even a provision in the Constitution for it. It's called intellectual property. Y'know, the thing that says you can't copy stuff, or use a patented technique, for a while after it's first created, and then everyone can have it? (Readers planning to rant about Disney and the extension of copyright dates may save their fingers; we all thought it, and it doesn't change my point.)
Before anyone asks me to go RTFA, yes, I realize that this does not make provision for also releasing the code when a certain amount of money has been raised, but this has happened regardless in some cases. (See, for example, iD's release of the code for their earlier games well before it would have been out of copyright. They were ahead of the game on shareware, and on that, too.)
So you keep saying, but if there was a specific agreement, did it allow for the release of source code under terms compatible with the GPL? And why were they aware or should they have been aware of the relevance of the GPL here? What do you know about this case that the rest of us don't?
How does that follow at all? Every time a major vendor sells a product with a licence agreement, they enter into a contract with the buyer. Are they assumed to be aware of how that buyer intends to use the product, and to give up all rights they would otherwise have over it? You are basically arguing that not only to EULAs have no legal validity -- which we all know is a largely untested area of law anyway -- but that it is the vendor's responsibility to be aware of the wishes of every buyer, which turns established practice on its head. Where is the legal or moral basis for this?
Summary finding against the defendant who breaches the rights of the third parties, I'm guessing. You just lost.
The fact that the people making the derived product gave it to you under a licence agreement they had no right to agree does not automatically excuse you from any obligations you have if you're in posession of code that belongs to third parties. If those parties have also actually told you that you are breaching their rights, and a court finds that you have persisted in doing so, I don't think you have much of a leg to stand on in any major Western legal system, even those that might allow a defence of ignorance initially.
Suppose I write a library, which I choose to distribute under some licence that forbids giving away the source code. Are you saying that I must check the intentions of everyone buying my library, to make sure that they aren't planning to GPL it and give away the code, and that if I fail to do so, my code automatically becomes GPL'd?
Could you please cite even the slightest shred of copyright law in your chosen jurisdiction or even common sense that supports this claim?
Um... No. The advantages of exposing systems currently implemented in some in-house client-server way to the outside world are far from proven in most cases.
Exposing things to the outside world guarantees only one thing in itself: you will be subject to more security vulnerabilities than you ever had before.
It does?
Web services != web browsing.
The only connection, aside from a convenient and hypeworthy similarity in the name, is that both use HTTP as the protocol.
As others have noted, web services are just another version of client/server, which happen to use things like HTTP for the communications.
I'm sorry, but that sounds like the hopeful philosophy of a GPL fan, not the legal advice of an informed lawyer. There are so many holes in that argument that even I can spot, I can't believe it would -- or should -- ever hold up in court.
I'm no expert in US law (I don't live there), but even with my basic knowledge of how it works and reading the obviously simplified summary here, I can see that most of the posts offering legal advice here are way off base. The scary thing is that equally off-base people are clearly moderating them up because they sound convincing, regardless of their legal correctness!
It seems to me that the only sensible action for the original poster to take immediately (aside from speaking to a lawyer again) can be some sort of legal move to force those who derived from his GPL'd work to either GPL the derivative (if they can) or stop distributing it. If the derived work cannot be GPL'd because it also includes indepently licensed third-party bits, then that narrows the options to one.
I don't understand why the OP is so keen to host the derived now-supposedly-GPL'd work using his own resources, though. He gains no obvious benefit from doing so, and if US law allows for penalties for distributing code contrary to its licence, it seems to leave him open to action by the third parties if they are being ripped off. If US law actually says that the OP can distribute something just because someone told him it was GPL'd, even though it actually wasn't, it would be about the only legal system in the Western world that did...
But by the sounds of it, the third parties' code was never based on GPL'd code.
As I read this, the poster made a GPL app, call it G. Someone else took this, and made another app derived from it, D. In D was also included some third party code, call it T. G is GPL'd, and the copyright holder for G therefore has the right to go after the makers of D for licence infringement. However, it sounds as though the makers of D have tried to GPL it. If they don't own the rights to the other third party code in it (from T) then they would not normally have that right (which would belong to the copyright holders of T, if they chose to do it). There is no way that the original poster can force the third party authors of T to release their code under the GPL if it isn't derived from GPL code itself.
What this seems to come down to is that the authors of the derived app D are screwed, because they've got GPL'd stuff they can't make proprietary and proprietary stuff they can't GPL in their code, and thus they can't distribute it at all under any licence.
But, of course, this is just a speculation based on the summary here, and it should go without saying that the OP needs to contact someone who can actually make a proper appraisal of the legal situation.
Noooooooo! Now you've spawned a whole new generation of bad jokes...
Karma: xcellent (ostly affcted by oderationdone to yur commens and subequent dcimation)
I realise that this isn't what you want to hear, but I think you're being a little overdramatic here.
As I argued previously, even with low figures for engineering school intakes, the industry as a whole will not suffer greatly in the long run. There are a lot more engineers out there with a few years of experience than there are new grads, and most of them will still be there in five years as well. The market won't suddenly get crowded again, it'll ramp up slowly, and during that period, it will attract back those who've left the field, and a new generation of grads. Failing all else, they'll just recruit skilled labour from overseas. It certainly won't suddenly all stop because a few new graduates got above themselves and stormed off to sulk elsewhere.
No, but they will have fairly minimal experience. The best you could hope for would normally be something like a year out doing a relevant full time job before or during university (unlikely in this field) or good vacation experience (which helps, but usually isn't anything like the real thing).
Here we see exactly the problem. If you came to me, and claimed you'd learned VC++, Java, an assembly language and a few other skills to a professional standard, all in six months, I would file you under "deluded" and move on. It probably takes six months of full time work with good guidance and training to get up to speed with one of those skills to a professional standard, and even then you'll only be at the bottom of the scale. In the real world, you don't get bonus points for writing lots of buzzwords on a resume, you get bonus points for actually knowing your stuff. Your efforts are to your credit and very commendedable, but it won't help to overstate what you've learned.
It's also those same engineers who will, at 11pm, be adding those nasty little bugs that are going to get fixed by the older and wiser the following week. Working absurd hours isn't impressive, it's stupid and error-prone. It might impress a crappy manager, but it certainly won't impress a skilled and experienced engineer. The reason the older and wiser don't do this -- families and such or not -- is because they have learned that it does more harm than good. As you said yourself, they don't devote more time than is necessary to a project. Doing so is... well... unnecessary.
I'm not sure about the C++ GC stuff. AFAICS, there's nothing to stop you writing your own full-blown GC, as long as your platform supports suitable multithreading and sync'ing protocols to let you co-ordinate between a GC'd pointer and a GC thread. You give up the portability and deterministic destruction, but such will always be the price of a GC system in a language with low-level features anyway.
I'm in two minds about OCaml as well, but I don't really know enough of it to have a well-informed opinion. I like the elegance and simplicity of SML, and somehow the OO and non-declarative parts of OCaml seem out of place in a functional language, powerful as they may be. Perhaps that's just because I mentally draw an inappropriate line between your average procedural/OO language and the declarative/functional world of ML, though.
I know exactly where you're coming from -- I graduated around four years ago, and I've seen much the same in software development. OTOH, I've learned that new graduates frequently over-rate themselves.
The companies you mention aren't hiring new grads because they're a liability. They are unknowns, whereas taking on someone with a couple years experience means you get a known quantity. Yes, you pay more for them, but in all probability, they will also be much more effective, and justify the higher salary. It simply makes good commercial sense to do this when times are hard.
I'm afraid your argument about running out of engineers doesn't really hold water, either. If demand is down at present, the fact that fewer people are going into training is not a problem. If the demand starts to rise again in a few years, there will still be all the engineers who've been working in the field, plus all the graduates arriving at that point (in increasing numbers, for the same reason they're decreasing now).
If today's new engineers choose to walk away, rather than keeping their hand in, then they will be the ones who lose out in five years, not the established guys or the newbies. If they keep their skills up-to-date, though, even if that means taking a lower paid or less than ideal job for now, then they'll be prime hiring material when the market picks up again further down the line.
Really? I'm not in the US, but all the feedback we're seeing in Europe has you guys taking this much harder than most.
On the contrary, in this business things do change, and fast. Cutting edge skills that made you highly valuable three or four years ago are now out of date. If your friend hasn't changed to match, he simply isn't worth $60K any more. You can dislike this fact as much as you like, but it's still a fact.
Also, it must be noted that the industry was doing much better than average at that stage, and it paid accordingly. That was never going to continue indefinitely, and expecting salaries to continue as far ahead of the working average as they were was always silly. If your friend failed to plan for that, I'm afraid that again, he has no-one to blame but himself.
I agree with much of what you write, but I'd place the emphasis differently. I don't think the access to low-level features in C++ is a problem. Rather, the problem is that they are used by default by most C++ programmers, probably because of the way the C++ community developed from the C one, and the fact that even today most C++ textbooks and tutors aren't good at de-emphasizing this. C++ itself provides high level equivalents to all of the things you mention, which are usually substituted trivially for the dangerous low-level ones. There should be no reason, in typical high-level C++ code, to ever use a raw pointer, unchecked array or unsafe cast; you have smart pointers, vector, dynamic_cast and such instead.
Oh, and don't even get me started on Java's generics. A whole new generation of ill-informed Java evangelists is about to rise up and tell us how C++'s templates are no longer an advantage, because they haven't noticed that in C++ you can do more than write generic containers with them. :-(
Oh, and I agree that functional languages are nice, BTW. I would be very happy programming in a language that has the elegance of functional languages and the raw power of things like C and C++. Now if only some clever programmer would invent it...
I think the argument that open source implies better security is overrated. While it is possible for anyone to check the source code, almost no-one actually has the technical expertise, time and inclination to do so. Everyone else just trusts that other people will do so, which makes them every bit as vulnerable as those who installed a closed source system in the first place. The same goes for creating and distributing a patch: even in the Linux world, a high proportion of the development work in this area is actually done by the big distro vendors, not by the OSS community as a whole.
Compare and contrast with a closed source product from a good company. As others have noted elsewhere in this thread, Apple has turned out security fixes within nine hours from being notified of a vulnerability in the past. I'm betting you can't make that claim of many Linux patches.
Please don't equate Microsoft with closed source and Linux with open source. If you do, your comparisons will always be fundamentally flawed. I agree that security through obscurity is not the way forward, but just disclosing something (when that something is millions of lines of source code) is not, in itself, enough to provide security either.
I'm curious about why you say this, because I would have said that C++'s single biggest strength was precisely that you can write software at a reasonably high level of abstraction most of the time, but also go to a lower level as and when necessary.
Surely Java's big strength relative to C++ is its vast and reasonably portable standard libraries, rather than the expressive power of the language itself? In the latter respect, C++ offers several considerably stronger features in the OO area (most significantly, probably, deterministic destruction), and of course there's all the whizzy stuff you can do with templates now that compilers are supporting them close to fully.
In contrast, most of Java's oft-cited "advantages" are simply features that are missing, and which you're at liberty to ignore in C++ as well. The only two big things that come to mind otherwise are the garbage collection and the provision of a finally keyword, and both of these are readily countered by that deterministic destruction, as long as you have someone smart enough to use it (which, bizarrely, many C++ programmers don't seem to be).
C++'s template wizardry may never be quite as smooth and efficient as native language features for things like closures, discriminated unions and pattern matching, but today's libraries are getting close enough to be very useful in practice. The lack of such things in Java is one of its major weaknesses in terms of abstraction tools, IMHO. I've worked on several large (well, >1MLOC, anyway) C++ projects that have been made very much nicer by the use of such things.
I think you just made my point for me. There is no reason any content of any e-mail message should be passed through any script engine. The fact that it can be effectively creates a whole new set of APIs for anyone sending an e-mail message, and those APIs are being abused to spread viruses. The prosecution rests, your honour.
No problem. MS do indeed have many shady practices regarding upgrades, and I'll be right behind you in the queue to bash them for it. It's just that they finally put in something potentially useful in this particular case. ;-)
I don't like to criticise, but I'd hesitate to recommend your rewritten resume as an example. Since CV writing is quite a personal thing, I'll just list my reservations below with the most serious first, and let anyone else look at both and decide for themselves whether they agree.