Resource cleanup is definitely part of generality. I would argue even part of type safety. Just because it's overlooked doesn't mean it isn't a crucial part of it. Clean generic programming is only really possible with value semantics, and value semantics means resource cleanup for non-trivial types.
Darwin's work heavily depended on Lyell's ideas of geology, including the idea that geological time is slow. So it doesn't matter if it doesn't get a mention until later chapters. The book was written to make a convincing argument so that it was hard to deny (hence starting of with artificial selection), not list things in order of importance.
Random mutation is long-term. But when a selection event happens, the "hidden" trait isn't created, but selected for. There is no "evolution", but a selection pressure that reveals the previous mutation as a preferential trait
That IS evolution. What else do you think is meant by evolution by natural selection?
Senior author Professor Greger Larson said: 'Our observations reveal that evolution is always moving quickly but we tend not to see it because we typically measure it over longer time periods. Our study shows that evolution can move much faster in the short term than we had believed from fossil-based estimates. Previously, estimates put the rate of change in a mitochondrial genome at about 2% per million years. At this pace, we should not have been able to spot a single mutation in just 50 years, but in fact we spotted two.'
The reason why mitchondrial measurements used long time frames was because of the mindset carried over from fossil estimates. The senior author himself says so in this quote from the article.
Well considering that for the longest time, fossils were our main source of viewing evolution through time, of course it would seem to be slow. Who knows how many speciation events happen and die off before being able to leave a mark in the fossil record.
In Java, references are pointers. Just because you call them something different doesn't mean they aren't the same. Hell, you can get a "reference" to null in Java. The only difference is that you can't do pointer arithmetic.
Garbage collection has nothing to do with whether something is a reference or a pointer. C++ has garbage collection in the form of scope based destruction of non-pointer owned objects.
In the context of C++, how does bringing Java into it relevant at all? Any idiot could tell I wasn't talking about all languages in general - but that I was talking about modern usage of C++.
Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.
C doesn't let you understand why people's code has terrible performance. C has the same problems that make code slow - reference semantics. It's a mistake to conflate low level with "performance". For example, std::sort is faster than qsort, and you can't understand why just by understanding C.
C++ is only a large language if you are looking to implement something very generic, like the STL. If you're just using a library like the STL, it is not large. In fact it is quite a small library, in terms of surface area, and all of the "advanced" language stuff is there for the library implementers to squeeze the last bits of performance out of a generic library.
The C++ devs you've worked with you claim are "the best" probably are the ones trying to use C++ as C with classes or learned C++ from university that teaches even pre-1998 C++. In modern C++, the "strict subset" is about letting the compiler do the work (through RAII, algorithms and type deduction), rather than the C subset of C++. That is what it means to "know" C++.
Yes, runtime errors that are environmental cannot be caught at compile time. But many other runtime errors are the result of design errors - designs that lead to more possible mistakes. When given a bit of thought, you can make those errors get flagged at compile time.
For example, the classic criticism of C++'s resource management. C++ doesn't have those problems if people used the RAII that's provided by default. You don't need to analyze for leaks or null pointers if those cost-free features (which are also semantic signals) are used. And by leaks, even stuff like managing database resources can be taken care of by RAII, leading to reduced environmental errors that may lead to things like duplicate primary keys being created.
Static analysis tools are okay if it comes to snippets of code changes, but can't tell you much about design flaws. I too often see people making local changes to "fix" the error when they should have given more thought about reorganizing even just the code of that function a bit. The other thing that is popular these days in C++ are generic algorithms. The properties of generic algorithms are known, including the elimination of most range errors. Static analysis doesn't tell you that you should replace your hand-crafted for loop (or thread synchronization) to use a more suitable higher level construct. In Java, that may as well be a good thing, since high level implies efficiency cost in a way C++ generic high level constructs don't.
If I remember correctly, there was a recent analysis done on popular open source C projects that showed most people don't abuse language features, so such examples simply do not warrant the hysteria surrounding the use of C features like macros.
I'm currently writing something using Javascript and WebGL. I spent a lot of time actually writing code. But "actually writing code" doesn't make me more productive. I think there's a tendency to conflate productivity with writing code. Certainly, the relationship between writing code and testing/debugging code is also forgotten. I find using templates (and their errors) eliminates the need for a lot of tests, especially those surrounding polymorphic aspects of design. I don't have to run the program in debug and step through if I can get the compiler to do that for me.
Slashdot Mirror
Resource cleanup is definitely part of generality. I would argue even part of type safety. Just because it's overlooked doesn't mean it isn't a crucial part of it. Clean generic programming is only really possible with value semantics, and value semantics means resource cleanup for non-trivial types.
Where's the automatic resource cleanup?
Darwin's work heavily depended on Lyell's ideas of geology, including the idea that geological time is slow. So it doesn't matter if it doesn't get a mention until later chapters. The book was written to make a convincing argument so that it was hard to deny (hence starting of with artificial selection), not list things in order of importance.
I already explained why you are wrong. Twice. You're the one who tried to deflect with your previous comment.
No, you have clear misconceptions about evolution. The article is fine.
There's nothing about evolution that says any trait must "dominate". The very minimum it needs to be is non-recessive.
How do you measure whiteness of people (not necessarily skin colour)?
Random mutation is long-term. But when a selection event happens, the "hidden" trait isn't created, but selected for. There is no "evolution", but a selection pressure that reveals the previous mutation as a preferential trait
That IS evolution. What else do you think is meant by evolution by natural selection?
Senior author Professor Greger Larson said: 'Our observations reveal that evolution is always moving quickly but we tend not to see it because we typically measure it over longer time periods. Our study shows that evolution can move much faster in the short term than we had believed from fossil-based estimates. Previously, estimates put the rate of change in a mitochondrial genome at about 2% per million years. At this pace, we should not have been able to spot a single mutation in just 50 years, but in fact we spotted two.'
The reason why mitchondrial measurements used long time frames was because of the mindset carried over from fossil estimates. The senior author himself says so in this quote from the article.
Still not relevant to the point I'm making.
Irrelevant to the point I'm making.
Well considering that for the longest time, fossils were our main source of viewing evolution through time, of course it would seem to be slow. Who knows how many speciation events happen and die off before being able to leave a mark in the fossil record.
In Java, references are pointers. Just because you call them something different doesn't mean they aren't the same. Hell, you can get a "reference" to null in Java. The only difference is that you can't do pointer arithmetic.
Garbage collection has nothing to do with whether something is a reference or a pointer. C++ has garbage collection in the form of scope based destruction of non-pointer owned objects.
In the context of C++, how does bringing Java into it relevant at all? Any idiot could tell I wasn't talking about all languages in general - but that I was talking about modern usage of C++.
Unless you're dealing with hardware directly, you don't need pointers at all.
Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.
C doesn't let you understand why people's code has terrible performance. C has the same problems that make code slow - reference semantics. It's a mistake to conflate low level with "performance". For example, std::sort is faster than qsort, and you can't understand why just by understanding C.
The 90s called. They want their joke back.
Name 5 complexities which are needless.
C++ is only a large language if you are looking to implement something very generic, like the STL. If you're just using a library like the STL, it is not large. In fact it is quite a small library, in terms of surface area, and all of the "advanced" language stuff is there for the library implementers to squeeze the last bits of performance out of a generic library.
The C++ devs you've worked with you claim are "the best" probably are the ones trying to use C++ as C with classes or learned C++ from university that teaches even pre-1998 C++. In modern C++, the "strict subset" is about letting the compiler do the work (through RAII, algorithms and type deduction), rather than the C subset of C++. That is what it means to "know" C++.
Uh no, you only have to check one. A's class' assignment operator.
Your imagined problem exists with C functions that uses handrolled (or macro rolled) vtables just the same.
Magnetized protoplanetary matter, how do they work?
Yes, runtime errors that are environmental cannot be caught at compile time. But many other runtime errors are the result of design errors - designs that lead to more possible mistakes. When given a bit of thought, you can make those errors get flagged at compile time.
For example, the classic criticism of C++'s resource management. C++ doesn't have those problems if people used the RAII that's provided by default. You don't need to analyze for leaks or null pointers if those cost-free features (which are also semantic signals) are used. And by leaks, even stuff like managing database resources can be taken care of by RAII, leading to reduced environmental errors that may lead to things like duplicate primary keys being created.
Static analysis tools are okay if it comes to snippets of code changes, but can't tell you much about design flaws. I too often see people making local changes to "fix" the error when they should have given more thought about reorganizing even just the code of that function a bit. The other thing that is popular these days in C++ are generic algorithms. The properties of generic algorithms are known, including the elimination of most range errors. Static analysis doesn't tell you that you should replace your hand-crafted for loop (or thread synchronization) to use a more suitable higher level construct. In Java, that may as well be a good thing, since high level implies efficiency cost in a way C++ generic high level constructs don't.
If I remember correctly, there was a recent analysis done on popular open source C projects that showed most people don't abuse language features, so such examples simply do not warrant the hysteria surrounding the use of C features like macros.
I'm pretty sure the "Turing complete preprocess macro system" was aimed specifically at templates. I don't think C macros are Turing complete.
I'm currently writing something using Javascript and WebGL. I spent a lot of time actually writing code. But "actually writing code" doesn't make me more productive. I think there's a tendency to conflate productivity with writing code. Certainly, the relationship between writing code and testing/debugging code is also forgotten. I find using templates (and their errors) eliminates the need for a lot of tests, especially those surrounding polymorphic aspects of design. I don't have to run the program in debug and step through if I can get the compiler to do that for me.