In the high performance computing and physical simulation world, Fortran and C are still king. In large part this is because of the BLAS, LAPACK, MPI and OpenMP libraries which are the standard libraries to use for linear algebra and parallel programming and upon which most physical simulation software is built. These libraries started out in Fortran but C ports are also widely available. Thus a new engineering graduate is much more likely to need to work with Fortran and these libraries than with Python.
Also while most code written by scientists/engineers isn't written very efficient (because they don't know algorithm design and analysis), it needs to be written in a language where someone (usually a CS person) can come in a cleanup/tune the critical bottlenecks. At that point the efficiency of the language does become important. In this field, a 3% improvement in performance can make or break you. (Yes, you can mix C and Python, but its easier to stick to one language rather than having to keep marshaling back and forth.)
Yeah, and the GP is pointing out that it is a weak analogy.
For example the sig could have been: "Atheism is a belief system to the same extent that not collecting stamps is a hobby." But I think most people would see that as an absurd analogy.
I could imagine some important laws like those relating to treason or war-time crimes might not get used much but they still need to be on the books. You'll have to figure something out to handle those cases in your sunset law.
Also keep in mind that most modern law is really a delta/patch that gets applied to the United States Code (USC), so automatically repealing a law gets tricky if other laws have later amended or reference it.
(Laws older than about 50(?) years are generally not in the USC, but there is a current government project to repeal those laws and pass replacements into the USC. My understanding is that they annually send a bill with their latest work through congress and the bill almost always passes. Nevertheless, they still have quite a backlog. A project to remove unneeded laws could work the same way but would likely have the same slow pace and backlog. It would also be more politically charged (i.e. who gets to choose what laws are "unneeded").)
Finally, I wonder we could get some inspiration from the mechanisms the military uses for keeping the Uniform Military Code of Justice (UMCJ) up to date. My understanding is that the UMCJ is remarkably un-crufty due to the military revising it as needed.
Which is worse, the internet developing an emergent technology based sentience (e.g. skynet) or the internet developing an emergent crowed based sentience like in these examples?
Personally I'm not sure which would scare me more.
if their students are constantly getting DMCA notices, the university might get into trouble
The DMCA doesn't work like that. The DMCA gives the university immunity.
Unless if you happen to be a random genius at network security (and if you're asking us, you aren't), you will not outsmart your school's IT department.
Huh, I used to(*) outsmart the IT department on a regular basis. I guess I should thank you for the complement.
(*) Now I don't have to, but those were fun times. Remind me to tell you about them once the statute of limitations expires;-).
It's not that I don't trust you. I don't trust the software to not significantly slow down my machine or expose me to more attack vectors or break and interact badly with the rest of my machine or change settings that I've tweaked. I've had all these happen before with required security software.
This content is worth nothing without an audience, and our intention is to make it widely available - but at the right price, a price that rewards the labour of people who are producing those great works.
Your content has no value without them...
Sounds like standard economics to me. The product you sell has no value except by the fact that people are willing to pay for it (i.e. there is demand for it). You want to charge a high enough price to make it worth your while, but also a low enough price to not destroy the demand.
Does anyone have a link to the actual decision or know on what ground the case was dismissed?
Depending on the details this case could be a indicator of some sanity returning to copyright law or just a case that was won on ancillary technicalities.
US law says otherwise. As defined by 17 USC 101, a "copy" is a physical instance of the physical media (game cartage, CD, etc.). Under 17 USC 117, ownership of a "copy" of software confers the right to install and use the software on that copy. As long as the transaction at the store counter relative to the physical media is a physical property purchase, then you get the intellectual property rights to install and use the intellectual property contained in that physical property.
So is every program written in such a language going to include a JIT compiler?
No! None of these features require a JIT. (e.g. Haskell/GHC compiled programs do not include a JIT.)
Which of these features do you think requires a JIT? If you want, I can explain how it can be implemented without one. (Frankly implementing them with a JIT would be a silly way to do things.)
Can you explain how C++ does not support parametric polymorphism in its entirety?
Sure! There are two main differences.
The form of polymorphism defined by templates in C++ is based on expanding and compiling a separate copy of the template code for each and every type that the template gets instantiated with. This is different than Standard ML, OCaml and Haskell where only one copy of the code gets compiled.
As an example, try to compile the following in C++: #include <utility.h> #include <iostream> using namespace std; template<typename a> a foo(int n, a x) {
if (n == 0) return x;
else return foo(n-1, make_pair(x, 17)).first; } int main(int argc, char** argv) {
cout << foo(argc, argv[0]);
return 0; }
If I constructed that example right, you C++ compiler will either reject that program or go into an infinite loop trying to compile it. This is because depending on the value of argc, the foo template must be instantiated for string and pair<string,int> and pair<pair<string, int>, int>, etc.
On the other hand the equivalent Haskell program poses no problem to the compiler:
import System
foo:: Int -> a -> a foo n x =
if n == 0
then x
else fst (foo (n-1) (x, 17))
main = do
args <- getArgs
print (foo (length args) (head args))
The second difference is that in the implementations of parametric polymorphism seen in languages like Haskell, the parametric argument must be treated opaquely. In C++ the template argument types are known at compile time and the language allows your program to use that knowledge (e.g. template based type dispatch). This can be seen as either an advantage (yea! I can do more things) or a disadvantage (boo! the template/function type doesn't express all the assumptions about the type that the template/function makes). Regardless of whether it is an advantage or disadvantage, it is a natural consequence of whether or not the code gets expanded for each and every type.
At the end of the day C++ template polymorphism is to parametric polymorphism as macros are to functions. Both templates and macros are based on expanding code(*) and thus may inspect their arguments at compile time. On the other hand parametric polymorphism and functions do not expand code and at compile time must treat their arguments as opaque.
P.S. Some things said here may change with the introduction of "concepts" in C++0x.
(*) Except templates keep a cache of recent expansions to ruse where macros usually do not.
At least half the things I mentioned cannot be easily implemented as libs in C. E.g. I'm guessing your polymorphic array isn't statically type checked which is what is usually meant with parametric polymorphism.
You could build them with layers on top of C (e.g. "cfront" the original C++ compiler), but you could say that about any Turing complete language. After all a compiler is just a front-end for machine code. The question isn't what features could be added, but rather what features it has.
I actually agree without about the problems of getting everything given to you. Which is why everyone should implement their own compiler or even interpreter for a high level language early in their carrier. (Take a class or read a book on it though. If you try to invent it on your own, you won't get as much out of it because you would have learned how you would implement it and not how it is actually implemented by the experts.)
First-class functions most definately do not require reflection or run-time compileation. I know because I've implemented them in two different compilers I've written. If you don't believe me, look in any compiler book that covers the implementation of closures.
C being a natively compiled language is no excuse for it not having first-class functions with proper closures. (Technically C already has first-class functions, but they carry no dynamic closures.)
In all of these features you mention (e.g. polymorphism in C++, higher-order functions in C), their implementations are broken half implementations of the full ideas. Even if they are technically present, they don't fulfill the spirit of the ideas.
And yes, "the metal" is feature poor when it comes to expressiveness. It's not a question of whether I can make the machine do what I want, but rather how hard I have to work to make the machine do what I want.
Ha ha. Good joke. You've forgotten the most important feature "needed in a great programming lang": higher-order and first-class functions with proper closures. Oh wait, C doesn't have that.
Any truly great statically typed language will also have at least algebraic data types, parametric polymorphism (even C++ only has ad-hoc polymorphism), type constructors and functions, maybe even a Turing complete type system (heh). C doesn't have any of those.
Now don't get me wrong. C is a great portable assembly language. It's close to the metal, widely known and easy to read. But as far as programming languages go, C feature poor.
I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.
At least that's what the study claimed.
(*) Assuming you don't "cheat" by not breaking your lines where normal programmers would.
If you would like APL to be on the list, then submit benchmarks for APL to the Shootout (the blog got its data fro there). The Shootout is mainly driven by user submissions. They do have some fairly strict rules about how to submit. However, if you can name an implementation (along with enough guidelines to make installing it easy) and provide a reasonably full set of benchmarks, then the language will generally be added.
One tip about submitting though: try to make life as easy as possible for the guy who runs it. He doesn't have time to figure out typos or to fix "easy" bugs in some programming language they he may not even know.
ML, Haskell, Scheme, Fortran and Common Lisp are on the list. You probably didn't notice them because they are listed by their implementation name (e.g. mlton/O'Caml, GHC, Stalin/Gambit/Ikarus/Chicken, G95, SBCL/CMUCL, etc.). The Shootout front page lists which implementations implement which languages.
I disagree. Mocking is a rhetorical tool without(*) logical content. It is primarily an emotional appeal (i.e. pathos). It has little place(**) in an honest discussion. Manipulating peoples emotions in this way to make them arrive at conclusions non-logically is one of the reasons that people dislike Scientology(***).
Consider for example the mocking statement "Smart, intellectually honest and Scientolist: you can be any two but not all three". It might sound like a great zinger, but it can be applied to any intelectual group you don't like: Conservative, Liberal, Christian, Buddhist, you name it. Just watch any comedian or "mock-umentary" director and you will quickly realize that anything can be mocked regardless of how good or bad it is.
Finally, mocking runs a significant risk of alienating the very people you might be trying to reach. If a person is pro-Scientology, then mocking is likely to make them hunker down and be disposed to blow-off the rest of your argument. On the other hand if a person is neutral on the subject, then mocking makes your side look childish and mean spirited and thus the person is again more likely to blow-off the rest of your argument.
(*) Even when mocking wraps a kernel of logic, the mocking is only a wrapper that adds no logic of its own
(**) I believe it is possible to sparingly use mocking in a constructive way when properly balanced by the other aspects of the rhetorical triangle, but that is a far cry from "It's hard to go wrong with mocking"
(***) Admittedly though, there are big differences in degree
On the last page of the court order why is the motion to suppress evidence denied? Isn't evidence from an illegal search warrant usually suppressed? Is there some technical distinction between quashing a warrant(*) and suppressing the evidence that I am missing?
(*) And why did the judge order the motion to quash be allowed instead of just ordering the warrant quashed?
I think the problem hinges on the use in the law (17 USC 512) of the phrase "material that is claimed to be infringing or to be the subject of infringing activity" (emphasis mine).
The rtmpdump does not infringe on any of Adobe's rtmp copyrights and Adobe don't claim it does (see section (a) of the letter). Thus Adobe must be claiming that rtmpdump is the subject of infringing activity. However this raises two issues.
First, does Adobe own the copyright on any of the works mentioned in part (a) of the letter (e.g. Catch Up, The Daily Show, The West Wing, etc.)? If Adobe doesn't own the copyright for any of those works, then Adobe has no standing to file a DMCA take-down for infringement of those works.
Second, supposing Adobe has standing and given that rtmpdump doesn't infringe Adobe's copyrights, could rtmpdump be classified as "the subject of infringing activity"? If it cannot, then the take-down is improperly formed and should be ignored by SourceForge.
Unfortunately I can't find anything that clarifies the meaning of the wording "subject of infringing activity". It could mean anything from "tool that could be used to infringe" to "material that is being copied in an infringing manner even if it isn't infringing". The former reading would make this a valid take-down while the latter reading would make this an invalidly formed take-down. The former reading however has problems because it not only makes every web-browser the "subject of infringing activity" but is also makes it impossible to determine whether any infringing activity occurred. This is because the wording is not "subject of potential infringing activity". Adobe provides and likely has no evidence that rtmpdump was ever actually used to infringe on the claimed works.
Can anyone shed light on precedent for interpreting the phrase "subject of infringing activity"?
IIUC, DMCA take-down notices only apply to copyright infringement. They are not applicable to "circumvention devices". That is a different part of the DMCA.
I say again this is not a take-down notice. It is more likely a cease and desist. (I can't find a copy of the letter so I can't be sure about that.)
Slashdot Mirror
In the high performance computing and physical simulation world, Fortran and C are still king. In large part this is because of the BLAS, LAPACK, MPI and OpenMP libraries which are the standard libraries to use for linear algebra and parallel programming and upon which most physical simulation software is built. These libraries started out in Fortran but C ports are also widely available. Thus a new engineering graduate is much more likely to need to work with Fortran and these libraries than with Python.
Also while most code written by scientists/engineers isn't written very efficient (because they don't know algorithm design and analysis), it needs to be written in a language where someone (usually a CS person) can come in a cleanup/tune the critical bottlenecks. At that point the efficiency of the language does become important. In this field, a 3% improvement in performance can make or break you. (Yes, you can mix C and Python, but its easier to stick to one language rather than having to keep marshaling back and forth.)
Yeah, and the GP is pointing out that it is a weak analogy.
For example the sig could have been: "Atheism is a belief system to the same extent that not collecting stamps is a hobby." But I think most people would see that as an absurd analogy.
I could imagine some important laws like those relating to treason or war-time crimes might not get used much but they still need to be on the books. You'll have to figure something out to handle those cases in your sunset law.
Also keep in mind that most modern law is really a delta/patch that gets applied to the United States Code (USC), so automatically repealing a law gets tricky if other laws have later amended or reference it.
(Laws older than about 50(?) years are generally not in the USC, but there is a current government project to repeal those laws and pass replacements into the USC. My understanding is that they annually send a bill with their latest work through congress and the bill almost always passes. Nevertheless, they still have quite a backlog. A project to remove unneeded laws could work the same way but would likely have the same slow pace and backlog. It would also be more politically charged (i.e. who gets to choose what laws are "unneeded").)
Finally, I wonder we could get some inspiration from the mechanisms the military uses for keeping the Uniform Military Code of Justice (UMCJ) up to date. My understanding is that the UMCJ is remarkably un-crufty due to the military revising it as needed.
RIAA only needs preponderence of evidence because it is civil. Law enforcement needs beyond reasonable doubt because its criminal.
Which is worse, the internet developing an emergent technology based sentience (e.g. skynet) or the internet developing an emergent crowed based sentience like in these examples?
Personally I'm not sure which would scare me more.
if their students are constantly getting DMCA notices, the university might get into trouble
The DMCA doesn't work like that. The DMCA gives the university immunity.
Unless if you happen to be a random genius at network security (and if you're asking us, you aren't), you will not outsmart your school's IT department.
Huh, I used to(*) outsmart the IT department on a regular basis. I guess I should thank you for the complement.
(*) Now I don't have to, but those were fun times. Remind me to tell you about them once the statute of limitations expires ;-).
It's not that I don't trust you. I don't trust the software to not significantly slow down my machine or expose me to more attack vectors or break and interact badly with the rest of my machine or change settings that I've tweaked. I've had all these happen before with required security software.
This content is worth nothing without an audience, and our intention is to make it widely available - but at the right price, a price that rewards the labour of people who are producing those great works.
Your content has no value without them ...
Sounds like standard economics to me. The product you sell has no value except by the fact that people are willing to pay for it (i.e. there is demand for it). You want to charge a high enough price to make it worth your while, but also a low enough price to not destroy the demand.
Does anyone have a link to the actual decision or know on what ground the case was dismissed?
Depending on the details this case could be a indicator of some sanity returning to copyright law or just a case that was won on ancillary technicalities.
US law says otherwise. As defined by 17 USC 101, a "copy" is a physical instance of the physical media (game cartage, CD, etc.). Under 17 USC 117, ownership of a "copy" of software confers the right to install and use the software on that copy. As long as the transaction at the store counter relative to the physical media is a physical property purchase, then you get the intellectual property rights to install and use the intellectual property contained in that physical property.
So is every program written in such a language going to include a JIT compiler?
No! None of these features require a JIT. (e.g. Haskell/GHC compiled programs do not include a JIT.)
Which of these features do you think requires a JIT? If you want, I can explain how it can be implemented without one. (Frankly implementing them with a JIT would be a silly way to do things.)
Can you explain how C++ does not support parametric polymorphism in its entirety?
Sure! There are two main differences.
The form of polymorphism defined by templates in C++ is based on expanding and compiling a separate copy of the template code for each and every type that the template gets instantiated with. This is different than Standard ML, OCaml and Haskell where only one copy of the code gets compiled.
As an example, try to compile the following in C++:
#include <utility.h>
#include <iostream>
using namespace std;
template<typename a>
a foo(int n, a x) {
if (n == 0) return x;
else return foo(n-1, make_pair(x, 17)).first;
}
int main(int argc, char** argv) {
cout << foo(argc, argv[0]);
return 0;
}
If I constructed that example right, you C++ compiler will either reject that program or go into an infinite loop trying to compile it. This is because depending on the value of argc, the foo template must be instantiated for string and pair<string,int> and pair<pair<string, int>, int>, etc.
On the other hand the equivalent Haskell program poses no problem to the compiler:
import System
foo :: Int -> a -> a
foo n x =
if n == 0
then x
else fst (foo (n-1) (x, 17))
main = do
args <- getArgs
print (foo (length args) (head args))
The second difference is that in the implementations of parametric polymorphism seen in languages like Haskell, the parametric argument must be treated opaquely. In C++ the template argument types are known at compile time and the language allows your program to use that knowledge (e.g. template based type dispatch). This can be seen as either an advantage (yea! I can do more things) or a disadvantage (boo! the template/function type doesn't express all the assumptions about the type that the template/function makes). Regardless of whether it is an advantage or disadvantage, it is a natural consequence of whether or not the code gets expanded for each and every type.
At the end of the day C++ template polymorphism is to parametric polymorphism as macros are to functions. Both templates and macros are based on expanding code(*) and thus may inspect their arguments at compile time. On the other hand parametric polymorphism and functions do not expand code and at compile time must treat their arguments as opaque.
P.S. Some things said here may change with the introduction of "concepts" in C++0x.
(*) Except templates keep a cache of recent expansions to ruse where macros usually do not.
Do you remember Moore because of his law or because he co-founded Intel?
At least half the things I mentioned cannot be easily implemented as libs in C. E.g. I'm guessing your polymorphic array isn't statically type checked which is what is usually meant with parametric polymorphism.
You could build them with layers on top of C (e.g. "cfront" the original C++ compiler), but you could say that about any Turing complete language. After all a compiler is just a front-end for machine code. The question isn't what features could be added, but rather what features it has.
I actually agree without about the problems of getting everything given to you. Which is why everyone should implement their own compiler or even interpreter for a high level language early in their carrier. (Take a class or read a book on it though. If you try to invent it on your own, you won't get as much out of it because you would have learned how you would implement it and not how it is actually implemented by the experts.)
First-class functions most definately do not require reflection or run-time compileation. I know because I've implemented them in two different compilers I've written. If you don't believe me, look in any compiler book that covers the implementation of closures.
C being a natively compiled language is no excuse for it not having first-class functions with proper closures. (Technically C already has first-class functions, but they carry no dynamic closures.)
In all of these features you mention (e.g. polymorphism in C++, higher-order functions in C), their implementations are broken half implementations of the full ideas. Even if they are technically present, they don't fulfill the spirit of the ideas.
And yes, "the metal" is feature poor when it comes to expressiveness. It's not a question of whether I can make the machine do what I want, but rather how hard I have to work to make the machine do what I want.
Ha ha. Good joke. You've forgotten the most important feature "needed in a great programming lang": higher-order and first-class functions with proper closures. Oh wait, C doesn't have that.
Any truly great statically typed language will also have at least algebraic data types, parametric polymorphism (even C++ only has ad-hoc polymorphism), type constructors and functions, maybe even a Turing complete type system (heh). C doesn't have any of those.
Even aside from types, great languages should include tail-call optimization, pattern matching and hygienic macros (CPP macros are a bad joke).
Now don't get me wrong. C is a great portable assembly language. It's close to the metal, widely known and easy to read. But as far as programming languages go, C feature poor.
I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.
At least that's what the study claimed.
(*) Assuming you don't "cheat" by not breaking your lines where normal programmers would.
If you would like APL to be on the list, then submit benchmarks for APL to the Shootout (the blog got its data fro there). The Shootout is mainly driven by user submissions. They do have some fairly strict rules about how to submit. However, if you can name an implementation (along with enough guidelines to make installing it easy) and provide a reasonably full set of benchmarks, then the language will generally be added.
One tip about submitting though: try to make life as easy as possible for the guy who runs it. He doesn't have time to figure out typos or to fix "easy" bugs in some programming language they he may not even know.
ML, Haskell, Scheme, Fortran and Common Lisp are on the list. You probably didn't notice them because they are listed by their implementation name (e.g. mlton/O'Caml, GHC, Stalin/Gambit/Ikarus/Chicken, G95, SBCL/CMUCL, etc.). The Shootout front page lists which implementations implement which languages.
It's hard to go wrong with mocking someone
I disagree. Mocking is a rhetorical tool without(*) logical content. It is primarily an emotional appeal (i.e. pathos). It has little place(**) in an honest discussion. Manipulating peoples emotions in this way to make them arrive at conclusions non-logically is one of the reasons that people dislike Scientology(***).
Consider for example the mocking statement "Smart, intellectually honest and Scientolist: you can be any two but not all three". It might sound like a great zinger, but it can be applied to any intelectual group you don't like: Conservative, Liberal, Christian, Buddhist, you name it. Just watch any comedian or "mock-umentary" director and you will quickly realize that anything can be mocked regardless of how good or bad it is.
Finally, mocking runs a significant risk of alienating the very people you might be trying to reach. If a person is pro-Scientology, then mocking is likely to make them hunker down and be disposed to blow-off the rest of your argument. On the other hand if a person is neutral on the subject, then mocking makes your side look childish and mean spirited and thus the person is again more likely to blow-off the rest of your argument.
(*) Even when mocking wraps a kernel of logic, the mocking is only a wrapper that adds no logic of its own
(**) I believe it is possible to sparingly use mocking in a constructive way when properly balanced by the other aspects of the rhetorical triangle, but that is a far cry from "It's hard to go wrong with mocking"
(***) Admittedly though, there are big differences in degree
By that definition North American humans and European humans were difference species until the 15th century.
On the last page of the court order why is the motion to suppress evidence denied? Isn't evidence from an illegal search warrant usually suppressed? Is there some technical distinction between quashing a warrant(*) and suppressing the evidence that I am missing?
(*) And why did the judge order the motion to quash be allowed instead of just ordering the warrant quashed?
Thanks for the link, but is it a proper takedown?
I think the problem hinges on the use in the law (17 USC 512) of the phrase "material that is claimed to be infringing or to be the subject of infringing activity" (emphasis mine).
The rtmpdump does not infringe on any of Adobe's rtmp copyrights and Adobe don't claim it does (see section (a) of the letter). Thus Adobe must be claiming that rtmpdump is the subject of infringing activity. However this raises two issues.
First, does Adobe own the copyright on any of the works mentioned in part (a) of the letter (e.g. Catch Up, The Daily Show, The West Wing, etc.)? If Adobe doesn't own the copyright for any of those works, then Adobe has no standing to file a DMCA take-down for infringement of those works.
Second, supposing Adobe has standing and given that rtmpdump doesn't infringe Adobe's copyrights, could rtmpdump be classified as "the subject of infringing activity"? If it cannot, then the take-down is improperly formed and should be ignored by SourceForge.
Unfortunately I can't find anything that clarifies the meaning of the wording "subject of infringing activity". It could mean anything from "tool that could be used to infringe" to "material that is being copied in an infringing manner even if it isn't infringing". The former reading would make this a valid take-down while the latter reading would make this an invalidly formed take-down. The former reading however has problems because it not only makes every web-browser the "subject of infringing activity" but is also makes it impossible to determine whether any infringing activity occurred. This is because the wording is not "subject of potential infringing activity". Adobe provides and likely has no evidence that rtmpdump was ever actually used to infringe on the claimed works.
Can anyone shed light on precedent for interpreting the phrase "subject of infringing activity"?
IIUC, DMCA take-down notices only apply to copyright infringement. They are not applicable to "circumvention devices". That is a different part of the DMCA.
I say again this is not a take-down notice. It is more likely a cease and desist. (I can't find a copy of the letter so I can't be sure about that.)
Yes, people still say this. We need a good counter slogan.
Ideas: