I have to lol at the "constant win api changes" statement. The Win API bends over backwards for backwards compatibility. In Unix, especially Linux, outside of POSIX (which is fairly limited in functionality), backwards compatibility is almost a 4 letter word.
The article messed up in a number of places as you surmise. You can use auto in for-loops. I don't know why the example didn't show that properly (I was scratching my head).
As for the swap example, what ends up happening is that with move semantics, you can go back to using the naive version, but it will actually be efficient because under the hood, it uses the rvalue references instead of copying. It will behave is if it were written using all that "pseudo-code" (don't know why he called actual code "pseudo-code"), but without all the horror.
What's the patent FUD, specifically? I'm not talking about some obscure part of the Winforms API, I mean in the core language itself.
And you forget that C++ has a giant environment to install as well, but due to age, that is generally part of the OS as is. In time, modern generation languages will end up in the same category. In fact, Windows Vista and 7 already come with.NET pre-installed, so there's no need to download anything to run a.NET app.
The solution to what problem, exactly? TLDs are already semantic defunct. They weren't really necessary in the first place. As others here have pointed out, there's no point in artificially limiting TLDs to meaningless TLAs like "com" or "net".
I'm pretty sure that free() doesn't send pages back to the OS until the heap can definitely be shrunk enough to make it worthwhile. Fragmentation would, for example, prevent shrinking the heap.
Why do you assume that all disabled people are that way because they made some stupid decision? Oftentimes, it's because some other person, like a drunk driver, made a stupid decision, but these people have to pay for it. But there's otherwise nothing wrong with them and there's no reason why they should be removed from the gene pool or made to suffer even more than they already are.
Also, you seriously misunderstand how evolution works. Removing a couple of obvious failures from the system doesn't necessarily produce a better gene pool. The genes for stupid behaviors are complex and varied, if they even exist at all, and many, if not most of us, are probably carriers. Furthermore, the stupid are themselves carriers for good genes. By only explicitly selecting the "good" and getting rid of all the undesirables, we not only fail to solve the problem, but we also destroy good genes as well as genetic diversity.
Social Darwinism doesn't work. Never did, never will.
We've been eating frankenfoods for a long time and live with frankenanimals, like dogs and cats, which were bred to be amenable to humans and their needs.
Okay, admittedly, I've only used yum from the command line. I'll agree the synaptic and aptitude are great frontends. I'll recuse myself from further discussion on this topic.
Except for the part about where it's not. Who is being programmed by John Stewart? FFS, he makes fun of the "liberal" media as much or more than he does of Fox News. No doubt he's a liberal, but it's hardly the same desk-pounding rhetoric and righteous indignation that flows forth from Beck and Rush. MSNBC is a little bit closer, but nobody watches them, so it's a moot point.
I think he's referring to the x86 task feature, whereby the hardware would actually handle a context-switch instead of having the software set everything up manually. Neither Linux, nor Windows, nor the BSDs (and thus Mac OS X) use this feature, although the very earliest versions of Linux did. It's faster and less error-prone to do it in software.
Call gates are also not used, if they indeed ever really were. Old days: interrupts for system calls. These days: syscall or sysenter instructions, which are specially designed to transfer to ring 0 and do it fast.
All coffee shops I've been to use some system like that. I think it's probably set up by a service (they've all used Wandering Wifi), so they probably don't have to do much except part with some money.
You are missing the forest for the trees. It's not just about a few extra instructions in front of main(). Yes, technically there are a "few" extra instructions in front of main(). But the reality is that there is actually an entire framework defined by both the OS (kernel and userspace) and the C runtime that calls into main() and also manages other aspects of the operation of your program. I don't think the argument that "by your description, every single program...is part of a framework" is valid. For one, the argument does not rest on the fact that there are a few instructions before main() (see above) and secondly, if it turns out that every single program is running as part of a framework, then so be it. After all, every single program we have today, whether written in C, assembly or brainfuck does, in fact, run on a computer. Is that a problem? No. That's just the reality of things. These days, we have powerful and rich environments and programs simply fit into those environments. Some environments (platforms) are smaller and less intrusive than others, I'll grant that. But at the end of the day, there is always a framework and it generally does a great deal of work. That's where we are. Deal with it. Either that, or go program on embedded where you don't have a runtime environment, per se. And I'm not knocking that either. Just stating facts.
Yes, we know that in embedded environments, things are different. Thanks for repeating yourself five times. However, on the big 3 OSes, and certainly many more, there is a whole lot of user-space activity that takes place before getting to main(). On standard glibc Linux, for example, after the fork completes, the real entry point is in ld.so, which loads dynamic libraries, calls any constructors, initializes stdio, initializes malloc, initializes threads, etc. Finally, the standard stack is setup before calling main(). Yes, with the right arguments to gcc, you can skip all that stuff. The point is, however, for most non-embedded software, your program, even if it's a simple C program, is actually embedded within a framework (glibc on Linux, Win32 on Windows, etc.) and main() is not the entry point for your program.
Is understanding assembly going to make you produce PHP code that's faster and lower on memory usage? Probably not a whole lot. PHP is bloated and if you are using it, your stuff will be bloated one way or another. The best you can do is make efficient use of PHP to reduce that footprint. Knowing assembly tricks won't help you at all.
Modular, for example, is necessary because software is not just about getting something once that works, it's also about maintainability, extensibility and the like. There are other requirements that must be factored in when architecting a piece of software. For embedded software on, e.g., memory constrained devices, you might have to use hacks and other weird tricks just to get it to work. It wouldn't be considered good programming in other contexts, but given the constraints and requirements of the software, it's the optimal solution.
You are still probably doing OO on some level even in C. OO is not a whole different paradigm, but is rather an institutionalization, so to speak, of a variety of patterns that are already used in procedural programming, with its own additional "enhancements" (for better or for worse).
I don't think the difference in job markets between C and Java really has a lot to do with OO as a methodology. It probably has more to do with what's available on what platform and what companies are using those platforms (more importantly, what *kind* of companies are using those platforms).
Slashdot Mirror
I have to lol at the "constant win api changes" statement. The Win API bends over backwards for backwards compatibility. In Unix, especially Linux, outside of POSIX (which is fairly limited in functionality), backwards compatibility is almost a 4 letter word.
The article messed up in a number of places as you surmise. You can use auto in for-loops. I don't know why the example didn't show that properly (I was scratching my head).
As for the swap example, what ends up happening is that with move semantics, you can go back to using the naive version, but it will actually be efficient because under the hood, it uses the rvalue references instead of copying. It will behave is if it were written using all that "pseudo-code" (don't know why he called actual code "pseudo-code"), but without all the horror.
What's the patent FUD, specifically? I'm not talking about some obscure part of the Winforms API, I mean in the core language itself.
And you forget that C++ has a giant environment to install as well, but due to age, that is generally part of the OS as is. In time, modern generation languages will end up in the same category. In fact, Windows Vista and 7 already come with .NET pre-installed, so there's no need to download anything to run a .NET app.
The last thing I want is Apple owning the ISP infrastructure. Imagine how locked down the internet would be then.
The solution to what problem, exactly? TLDs are already semantic defunct. They weren't really necessary in the first place. As others here have pointed out, there's no point in artificially limiting TLDs to meaningless TLAs like "com" or "net".
I really hope it's not called "keepass".
I'm pretty sure that free() doesn't send pages back to the OS until the heap can definitely be shrunk enough to make it worthwhile. Fragmentation would, for example, prevent shrinking the heap.
Why do you assume that all disabled people are that way because they made some stupid decision? Oftentimes, it's because some other person, like a drunk driver, made a stupid decision, but these people have to pay for it. But there's otherwise nothing wrong with them and there's no reason why they should be removed from the gene pool or made to suffer even more than they already are.
Also, you seriously misunderstand how evolution works. Removing a couple of obvious failures from the system doesn't necessarily produce a better gene pool. The genes for stupid behaviors are complex and varied, if they even exist at all, and many, if not most of us, are probably carriers. Furthermore, the stupid are themselves carriers for good genes. By only explicitly selecting the "good" and getting rid of all the undesirables, we not only fail to solve the problem, but we also destroy good genes as well as genetic diversity.
Social Darwinism doesn't work. Never did, never will.
No, it's called "I'm an idiot", produced, written and directed by siride.
We've been eating frankenfoods for a long time and live with frankenanimals, like dogs and cats, which were bred to be amenable to humans and their needs.
This is close to the worst way to make a government in the modern era.
This looks like a conversation the poster made up to be funny. If it's real, than disregard my remark.
This must be a joke post. Even Stallman wouldn't require calling it the "GNU/Linux kernel".
These made up conversations are never funny. I see people post them regularly and I never even crack a smile. Come on, Slashdot.
It hasn't used that system for a while, as even the Wikipedia article you linked to says.
Okay, admittedly, I've only used yum from the command line. I'll agree the synaptic and aptitude are great frontends. I'll recuse myself from further discussion on this topic.
Except for the part about where it's not. Who is being programmed by John Stewart? FFS, he makes fun of the "liberal" media as much or more than he does of Fox News. No doubt he's a liberal, but it's hardly the same desk-pounding rhetoric and righteous indignation that flows forth from Beck and Rush. MSNBC is a little bit closer, but nobody watches them, so it's a moot point.
I think he's referring to the x86 task feature, whereby the hardware would actually handle a context-switch instead of having the software set everything up manually. Neither Linux, nor Windows, nor the BSDs (and thus Mac OS X) use this feature, although the very earliest versions of Linux did. It's faster and less error-prone to do it in software.
Call gates are also not used, if they indeed ever really were. Old days: interrupts for system calls. These days: syscall or sysenter instructions, which are specially designed to transfer to ring 0 and do it fast.
All coffee shops I've been to use some system like that. I think it's probably set up by a service (they've all used Wandering Wifi), so they probably don't have to do much except part with some money.
Now THAT's irony!
You are missing the forest for the trees. It's not just about a few extra instructions in front of main(). Yes, technically there are a "few" extra instructions in front of main(). But the reality is that there is actually an entire framework defined by both the OS (kernel and userspace) and the C runtime that calls into main() and also manages other aspects of the operation of your program. I don't think the argument that "by your description, every single program...is part of a framework" is valid. For one, the argument does not rest on the fact that there are a few instructions before main() (see above) and secondly, if it turns out that every single program is running as part of a framework, then so be it. After all, every single program we have today, whether written in C, assembly or brainfuck does, in fact, run on a computer. Is that a problem? No. That's just the reality of things. These days, we have powerful and rich environments and programs simply fit into those environments. Some environments (platforms) are smaller and less intrusive than others, I'll grant that. But at the end of the day, there is always a framework and it generally does a great deal of work. That's where we are. Deal with it. Either that, or go program on embedded where you don't have a runtime environment, per se. And I'm not knocking that either. Just stating facts.
Yes, we know that in embedded environments, things are different. Thanks for repeating yourself five times. However, on the big 3 OSes, and certainly many more, there is a whole lot of user-space activity that takes place before getting to main(). On standard glibc Linux, for example, after the fork completes, the real entry point is in ld.so, which loads dynamic libraries, calls any constructors, initializes stdio, initializes malloc, initializes threads, etc. Finally, the standard stack is setup before calling main(). Yes, with the right arguments to gcc, you can skip all that stuff. The point is, however, for most non-embedded software, your program, even if it's a simple C program, is actually embedded within a framework (glibc on Linux, Win32 on Windows, etc.) and main() is not the entry point for your program.
Is understanding assembly going to make you produce PHP code that's faster and lower on memory usage? Probably not a whole lot. PHP is bloated and if you are using it, your stuff will be bloated one way or another. The best you can do is make efficient use of PHP to reduce that footprint. Knowing assembly tricks won't help you at all.
Modular, for example, is necessary because software is not just about getting something once that works, it's also about maintainability, extensibility and the like. There are other requirements that must be factored in when architecting a piece of software. For embedded software on, e.g., memory constrained devices, you might have to use hacks and other weird tricks just to get it to work. It wouldn't be considered good programming in other contexts, but given the constraints and requirements of the software, it's the optimal solution.
You are still probably doing OO on some level even in C. OO is not a whole different paradigm, but is rather an institutionalization, so to speak, of a variety of patterns that are already used in procedural programming, with its own additional "enhancements" (for better or for worse).
I don't think the difference in job markets between C and Java really has a lot to do with OO as a methodology. It probably has more to do with what's available on what platform and what companies are using those platforms (more importantly, what *kind* of companies are using those platforms).