As you well know, CPython is the single implementation by which the language is defined. All the others are measured by how closely they match the behaviour of CPython. None of them get 100%.
I love Python, but it is a perfectly reasonable thing to say that it is not as fast as C. Keep your fingers crossed that the PyPy folks can pull off a miracle!
He made the Sea of cast metal, circular in shape, measuring ten cubits from rim to rim and five cubits high. It took a line of thirty cubits to measure around it.
Not exactly a lesson in euclidean geometry, but not the word of an infallible being either.
It is common practice for young children to pee or poop on the street in China. All the young children have special trousers/pants with a split between the legs that reaches all the way from back to front... That sort of thing can happing in parts of rural China (for those thinking the parent might have been pure troll), but I don't think there is any habit of public defecation in the major cities such as Beijing. Certainly none that I ever saw. Anywhere that would have dogs as pets instead of strays is likely to be safe from having to dodge human turds. But everything you hear about the state of public restrooms in China is true. The best rule for using public restrooms in China is "Don't be desperate." Sometime you just have to turn around and get out of there, as fast as you can.
The comment about lack of pointers in FORTRAN made by the grandparent doesn't mean what you think it does. It refers to indirect access to values and goes for references just as well as pointers. It has nothing to do with garbage collection and little to do with pointer arithmetic. The statement that "computer scientists find the lack of pointers terrible" is likely to refer to the algorithmic benefits of indirection, not a desire to shoot themselves in the foot with pointer arithmetic or the like.
The reason it might be seen as a strength is that since FORTRAN doesn't have pointers, FORTRAN compilers generally don't have to deal with something called 'pointer aliasing' (which could just as easily be called reference aliasing, again it has to do with inderection and is nothing to do with GC or pointer arithmetic) and so can often assume that two different variables must have independent values and can make many low-level optimizations that other languages cannot make so easily.
This includes pulling values from memory into registers and changing their values in the register without having to worry about the potiential other references to this memory (the aliases) becoming being out of date.
It also includes being able to use hardware vectorisation without having to make as many checks that memory does not overlap in two array sequences.
It probably includes other things as well, but you would have to ask a compiler writer or maybe a FORTRAN programmer, sadly I am neither.
(PS I think this all refers to older versions of FORTRAN; I am pretty sure recent versions do in fact have pointers to allow enough indirection to keep the computer scientists happy.)
"Twenty-six percent of English citizens -- roughly one-quarter of the population -- have been victimized by violent crime. Australia led the list with more than 30 percent of its population victimized."
I cannot speak for the UK, but I live in Australia and I can tell you that the 30% figure is utter crap - unless it includes getting wedgies in the school yard.
As for the gun lobby myth that violent crime exploded in Australia after gun controls were introduced, check out this bar chart of homicide rates for the period 1989 - 2000. The homicide rate is pretty much constant before and after gun control laws were introduced in 1996 (you can see when the laws were introduced because of the large spike in the homicide rate in Tasmania in 1996, due to the Port Arthur massacre. The gun control laws were introduced immediately after the massacre).
Maybe you will try to claim that the rates went up after 2000, however these figures show that it remained constant until 2004, the latest normalised figures I could find.
You should try getting your information from somewhere that doesn't have ads for books about the duty of self armament on its front page.
Gun control laws may not have done much to reduce crime in Australia, but they certainly haven't done anything to increase it, despite a great deal of misinformation from the US gun lobby to the contrary.
This is a commercialization of C-Store by the same guys. It remains to be seen what commercial development would be fed back to the original open source version.
The.net runtime comes with the standard c# and vb.net compilers so they have addressed this to a degree, since the runtime will be installed with the OS in future versions.
The whole point of AOP is to provide a means of modularisation for code that is logically related but would otherwise be sprinkled all over the code-base.
Most of the standard examples heavily employ side effects, because they are being used in the context of imperative programs.
AOP was originally invented in a LISP environment and while LISP is not as pure as Haskell etc, many of the original LISP examples are much more in an FP style than an imperative one.
There is huge scope for modifying the behaviour of a functional program by changing the arguments passed to functions. It is limited only by your imagination.
Having multiple aspects operation of a single area (join point in AOP speak) does indeed add complications, but these compilications are easily handled (e.g. by defining priorities for order-of-application) in an imperative/OOP environment, and I cannot see why a functional environment would be any different.
A functional language does have a richer set of tools for solving these kinds of problems, making AOP perhaps less appealing for functional languages, but that does not imply that AOP has to be inherently 'unclean' from a functional point of view.
This is not true at all. It is true that AOP as implemented in OOP evironments (e.g. AspectJ in Java) is usually used to add side-effects to existing code, but that is just because side-effects are the most common way of doing things in OO programs.
If AOP was to be implemented in a pure functional evironment, then it would not require side-effects.
For example, if the original code had a function call like this:
foo( bar(1), 2, 3) then the aspect could modify the function call to be:
foo( 2, bar(1), 3) or whatever, no side effects required. If side-effects were to be used, then monads could be employed as per a pure FP approach.
AOP is about providing flexibility in where logic exists in the source code (in fact potentially you do not even need the source code), so that if you want to change the behaviour of a function/method then you do not have to actually modify the definition of that function/method. It has no requirement to employ any programming style, imperative, OO, or otherwise.
I have found Fortify to be a very helpful memory debugger. It supports both new/delete and malloc/free memory management. It traps memory leaks,
writes beyond and before memory blocks, writes to freed memory, free twice,
freeing memory never allocated, amongst others. It's performance hit is certainly noticeable, but should scale well under heavy use. I have only ever used it on one platform, but it claims to be very portable.
It is free and includes source code, but does not have an open source license.
It is a good thing they reserved judgement on reliability, because MSVC's optimisations are anything but reliable. Aren't buggy optimisations worse than no optimisations at all?
Have a look at these MSDN items to see what I mean:
Slashdot Mirror
As you well know, CPython is the single implementation by which the language is defined. All the others are measured by how closely they match the behaviour of CPython. None of them get 100%.
I love Python, but it is a perfectly reasonable thing to say that it is not as fast as C. Keep your fingers crossed that the PyPy folks can pull off a miracle!
Well the first is much better than the second. I'll refrain from speculating which is which though!
The comment about lack of pointers in FORTRAN made by the grandparent doesn't mean what you think it does. It refers to indirect access to values and goes for references just as well as pointers. It has nothing to do with garbage collection and little to do with pointer arithmetic. The statement that "computer scientists find the lack of pointers terrible" is likely to refer to the algorithmic benefits of indirection, not a desire to shoot themselves in the foot with pointer arithmetic or the like.
The reason it might be seen as a strength is that since FORTRAN doesn't have pointers, FORTRAN compilers generally don't have to deal with something called 'pointer aliasing' (which could just as easily be called reference aliasing, again it has to do with inderection and is nothing to do with GC or pointer arithmetic) and so can often assume that two different variables must have independent values and can make many low-level optimizations that other languages cannot make so easily.
This includes pulling values from memory into registers and changing their values in the register without having to worry about the potiential other references to this memory (the aliases) becoming being out of date.
It also includes being able to use hardware vectorisation without having to make as many checks that memory does not overlap in two array sequences.
It probably includes other things as well, but you would have to ask a compiler writer or maybe a FORTRAN programmer, sadly I am neither.
(PS I think this all refers to older versions of FORTRAN; I am pretty sure recent versions do in fact have pointers to allow enough indirection to keep the computer scientists happy.)
The linked article includes this statement:
"Twenty-six percent of English citizens -- roughly one-quarter of the population -- have been victimized by violent crime. Australia led the list with more than 30 percent of its population victimized."
I cannot speak for the UK, but I live in Australia and I can tell you that the 30% figure is utter crap - unless it includes getting wedgies in the school yard.
As for the gun lobby myth that violent crime exploded in Australia after gun controls were introduced, check out this bar chart of homicide rates for the period 1989 - 2000. The homicide rate is pretty much constant before and after gun control laws were introduced in 1996 (you can see when the laws were introduced because of the large spike in the homicide rate in Tasmania in 1996, due to the Port Arthur massacre. The gun control laws were introduced immediately after the massacre).
Maybe you will try to claim that the rates went up after 2000, however these figures show that it remained constant until 2004, the latest normalised figures I could find.
You should try getting your information from somewhere that doesn't have ads for books about the duty of self armament on its front page. Gun control laws may not have done much to reduce crime in Australia, but they certainly haven't done anything to increase it, despite a great deal of misinformation from the US gun lobby to the contrary.
This is a commercialization of C-Store by the same guys. It remains to be seen what commercial development would be fed back to the original open source version.
You have a warped view of poverty.
The vast majority of poor people in the world have never set their eyes on a big screen TV.
The .net runtime comes with the standard c# and vb.net compilers so they have addressed this to a degree, since the runtime will be installed with the OS in future versions.
NT-based kernels have the concept of named pipes, although not using the posix api:
= /library/en-us/ipc/base/named_pipes.asp/
http://msdn.microsoft.com/library/default.asp?url
I have found the solution, but we need to come to an arrangement about my other $19,000, don't you think?
The whole point of AOP is to provide a means of modularisation for code that is logically related but would otherwise be sprinkled all over the code-base.
Most of the standard examples heavily employ side effects, because they are being used in the context of imperative programs.
AOP was originally invented in a LISP environment and while LISP is not as pure as Haskell etc, many of the original LISP examples are much more in an FP style than an imperative one.
There is huge scope for modifying the behaviour of a functional program by changing the arguments passed to functions. It is limited only by your imagination.
Having multiple aspects operation of a single area (join point in AOP speak) does indeed add complications, but these compilications are easily handled (e.g. by defining priorities for order-of-application) in an imperative/OOP environment, and I cannot see why a functional environment would be any different.
A functional language does have a richer set of tools for solving these kinds of problems, making AOP perhaps less appealing for functional languages, but that does not imply that AOP has to be inherently 'unclean' from a functional point of view.
This is not true at all. It is true that AOP as implemented in OOP evironments (e.g. AspectJ in Java) is usually used to add side-effects to existing code, but that is just because side-effects are the most common way of doing things in OO programs.
If AOP was to be implemented in a pure functional evironment, then it would not require side-effects.
For example, if the original code had a function call like this:
foo( bar(1), 2, 3)
then the aspect could modify the function call to be:
foo( 2, bar(1), 3)
or whatever, no side effects required.
If side-effects were to be used, then monads could be employed as per a pure FP approach.
AOP is about providing flexibility in where logic exists in the source code (in fact potentially you do not even need the source code), so that if you want to change the behaviour of a function/method then you do not have to actually modify the definition of that function/method. It has no requirement to employ any programming style, imperative, OO, or otherwise.
Really?
It is free and includes source code, but does not have an open source license.
Have a look at these MSDN items to see what I mean:
BUG: Bad Result If Call Inline Function Twice in Expression
BUG: Optimization Causes Code Generation Error In a Conditional Statement
BUG: Compiling with the In-Line Function Expansion Optimizations (/Ob1 and /Ob2 ) Fails to Generate C4716
BUG: Bad Code Generation with Global Optimization
BUG: Incorrect Code Generated with /Og Optimization
BUG: Try/Catch Block May Fail when Global Optimizations (/Og) Are Enabled
BUG: /Og Generates Bad Code for a Compare/Branch