Of course, if you never take some of those younger people and train them, you eventually run out of qualified people. Experience doesn't occur magically.
It's worse than that. I remember about 5 or 6 years ago reading about HURD. They were trying to get people to use it, but one of the bugs was it didn't support a disc bigger than 4 GB. Why 4 GB? Because they mem mapped the disks, and that was the size of a 32 bit pointer (I did say this was a few years ago). Rather than fixing their bad design, they decided to gimp their OS instead.
That's the real problem with GNU these days. They care about abstract CS philosophy points more than practical working code. In this case, they have someone with a hardon for functional languages, without paying attention to the fact that nobody outside of academia uses functional languages, and that no functional language has ever been a success, rather than using one of a dozen common scripting languages.
I believe my US postal mail is private, and it's handled by intermediaries and in clear text. Just because something could be intercepted does not mean you have no expectations of privacy.
If you think managed code has no leaks, you've either never written anything beyond hello world or you're completely oblivious. It's trivial to leak memory in Java and C#. In fact, if you don't program defensively to avoid it your programs leak like a sieve.
Yes, because managed code has no memory leaks. Please. I work on a mixed C++/Java Android codebase. I haven't found a memory leak on the C++ side in months. The Android framework decides to hold onto random references every new version.
Quite frankly, memory management is not hard. If you don't understand the simple idea of allocate, use, release, then you are a complete incompetent and should not be programming professionally. I'll go so far as to say it's better for a language NOT to automatically manage your memory- in general the first sign of a bad or failing architecture is that object life cycles and memory allocation start to be non-trivial. Managing your own memory catches those architecture bugs and leads to cleaner, easier to understand code. And the cost is absolutely minimal, I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.
If you have a possibility of a NUL, you shouldn't use string functions- you should use the memxxx functions (memcpy, memcmp, etc). Because at that point it isn't a string- it's a data format that can contain strings and other things. Trying to handle it as a string can be a quick way of getting up and running, but it'll cause breaks as you can see. You're better off thinking of serial communication as a byte stream, and parsing it into strings as needed.
Because everyone gets C strings, and introducing it would be no gain. C provides a minimal library on purpose. If you want a new string type, roll your own or use one of dozens of already written libraries.
Since NUL is an unprintable character with no meaning, there's no reason to do that. Now you may have needed a byte pointer with NULs in it, but that's not the same as needing a string with it.
No it wasn't. The computer I'm on now is XP, it doesn't have native zip support- I needed to install good old WinZip.
As for your other features- I don't use any of them, or need any of them. The vast majority of users don't, other than the eye candy. So nope, I can't think of anything 7 or Vista do that XP doesn't.
Really? Other than built in zip recognition, I can't even think of a feature in 7 that isn't in XP. I suppose there's more eye candy, but I turn that shit off anyway
And then you ha0ve a use case change. Or need to interface with an app written in another language. Or find that *shock* while a certain object is very effective for holding some information, it's a horrible way of storing for query. An object should be designed for the use case at hand, the database should be designed for efficient retrieval for that and future use cases. The two are damned near never the same. Persistence frameworks are a mistake.
Pharmecutical companies spend more than twice as much on advertising as they do on research. And much of their research is on updating drugs about to move out of patent protection to get them another 20 year monopoly. And even then their total annual research is less than 30 billion. We'd get more bang for our buck by removing their patents and spending 30 billion on grants for targetted medicines. Then maybe we'd get cures for real diseases, and not another 13 erection pills and non-existant diseases like restless leg syndrome.
The universities, where most of the research comes from today. 99% of R&D budgets are pure D, research just doesn't happen in the private sector anymore.
The biggest tell of all is betting history. Betting history trumps any physical tell you can see, and is just as available (even more so in fact, you can cache it in a db) via the internet.
Scares? Those sound like legit concerns to me. The last thing you need is to MRI someone with a metal plate in their head, or to give pennicilin to someone with an allergy. While there needs to be strict criminal liability for providing non-emergency access without permission, sticking with paper records is asinine.
A bit is a mutex if your processor has an atomic test and set instruction. Which these days they all do. A semaphore is an integer protected by a mutex. He oversimplified a bit, but if you know what you're doing it is that simple.
The real problem with the tax system is not in its complexity, its just how high our taxes truly are.
We're the lowest taxed generation since WWII. The highest rate now is 35%, and few pay it. The highest tax bracket in the 90s was 39.6. The highest tax bracket under most of Regan was 50%. Under Nixon was 70%. Kenedy was 91%. Eisenhower was also 91%. The rate coming out of WWII was 94%.
Try doing actual research before spitting out far right talking points.
Slashdot Mirror
Of course, if you never take some of those younger people and train them, you eventually run out of qualified people. Experience doesn't occur magically.
And this is why scheme fails. It's so la king that even people who *want* to use it instead decide to use it to emulate better languages.
Just use a real language with actual users instead. Functional languages are dead, deal with it.
It's worse than that. I remember about 5 or 6 years ago reading about HURD. They were trying to get people to use it, but one of the bugs was it didn't support a disc bigger than 4 GB. Why 4 GB? Because they mem mapped the disks, and that was the size of a 32 bit pointer (I did say this was a few years ago). Rather than fixing their bad design, they decided to gimp their OS instead.
That's the real problem with GNU these days. They care about abstract CS philosophy points more than practical working code. In this case, they have someone with a hardon for functional languages, without paying attention to the fact that nobody outside of academia uses functional languages, and that no functional language has ever been a success, rather than using one of a dozen common scripting languages.
I believe my US postal mail is private, and it's handled by intermediaries and in clear text. Just because something could be intercepted does not mean you have no expectations of privacy.
If you think managed code has no leaks, you've either never written anything beyond hello world or you're completely oblivious. It's trivial to leak memory in Java and C#. In fact, if you don't program defensively to avoid it your programs leak like a sieve.
Yes, because managed code has no memory leaks. Please. I work on a mixed C++/Java Android codebase. I haven't found a memory leak on the C++ side in months. The Android framework decides to hold onto random references every new version.
Quite frankly, memory management is not hard. If you don't understand the simple idea of allocate, use, release, then you are a complete incompetent and should not be programming professionally. I'll go so far as to say it's better for a language NOT to automatically manage your memory- in general the first sign of a bad or failing architecture is that object life cycles and memory allocation start to be non-trivial. Managing your own memory catches those architecture bugs and leads to cleaner, easier to understand code. And the cost is absolutely minimal, I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.
If you have a possibility of a NUL, you shouldn't use string functions- you should use the memxxx functions (memcpy, memcmp, etc). Because at that point it isn't a string- it's a data format that can contain strings and other things. Trying to handle it as a string can be a quick way of getting up and running, but it'll cause breaks as you can see. You're better off thinking of serial communication as a byte stream, and parsing it into strings as needed.
Because everyone gets C strings, and introducing it would be no gain. C provides a minimal library on purpose. If you want a new string type, roll your own or use one of dozens of already written libraries.
Since NUL is an unprintable character with no meaning, there's no reason to do that. Now you may have needed a byte pointer with NULs in it, but that's not the same as needing a string with it.
No it wasn't. The computer I'm on now is XP, it doesn't have native zip support- I needed to install good old WinZip.
As for your other features- I don't use any of them, or need any of them. The vast majority of users don't, other than the eye candy. So nope, I can't think of anything 7 or Vista do that XP doesn't.
Really? Other than built in zip recognition, I can't even think of a feature in 7 that isn't in XP. I suppose there's more eye candy, but I turn that shit off anyway
And then you ha0ve a use case change. Or need to interface with an app written in another language. Or find that *shock* while a certain object is very effective for holding some information, it's a horrible way of storing for query. An object should be designed for the use case at hand, the database should be designed for efficient retrieval for that and future use cases. The two are damned near never the same. Persistence frameworks are a mistake.
No Reagan? In a much better place.
But I think they're mostly afraid of Stephen Colbert deciding he wants to be their nominee.
Pharmecutical companies spend more than twice as much on advertising as they do on research. And much of their research is on updating drugs about to move out of patent protection to get them another 20 year monopoly. And even then their total annual research is less than 30 billion. We'd get more bang for our buck by removing their patents and spending 30 billion on grants for targetted medicines. Then maybe we'd get cures for real diseases, and not another 13 erection pills and non-existant diseases like restless leg syndrome.
The universities, where most of the research comes from today. 99% of R&D budgets are pure D, research just doesn't happen in the private sector anymore.
Seeing as I haven't had a telemarketer calling in most of a decade, it worked pretty damn well. Of course, that has federal law backing it.
The biggest tell of all is betting history. Betting history trumps any physical tell you can see, and is just as available (even more so in fact, you can cache it in a db) via the internet.
Scares? Those sound like legit concerns to me. The last thing you need is to MRI someone with a metal plate in their head, or to give pennicilin to someone with an allergy. While there needs to be strict criminal liability for providing non-emergency access without permission, sticking with paper records is asinine.
There's a lot of Java-ites who claim that Java is just as fast. They're idiots, but they're vocal.
Contractors? Consultants maybe, but not contractors. Most contracts I've been offered pay within 5% of what I make as an employee, with no benefits.
But not in our lifetimes. So no, we don't.
Every Nintendo console has turned a day 1 profit. Only Sony and MS do the razor blade mechanism.
A bit is a mutex if your processor has an atomic test and set instruction. Which these days they all do. A semaphore is an integer protected by a mutex. He oversimplified a bit, but if you know what you're doing it is that simple.
Funny, I was there from 98-01, and everyone I knew used ICQ. Must have had totally different sets of friends.
We're the lowest taxed generation since WWII. The highest rate now is 35%, and few pay it. The highest tax bracket in the 90s was 39.6. The highest tax bracket under most of Regan was 50%. Under Nixon was 70%. Kenedy was 91%. Eisenhower was also 91%. The rate coming out of WWII was 94%.
Try doing actual research before spitting out far right talking points.