That's a pretty pathetic argument. Firstly, that's like saying guns aren't capable of killing people, as long as you don't use them. That they can kill people, regardless of whether they are used or not, is an inheirant potential in them. So saying C++ is typesafe by telling people not to use any unsafe operations is similarly incorrect.
Secondly, it is possible to crash C++ programs even if you never use any unsafe constructs. For example,
int* foo; std::cout << foo[0] << std::endl;
Oops, I segfaulted. Okay, so I used a pointer, let me give you another example:
Theorem proving in most cases has never been a part of AI research. It is possible to implement a theorem prover using AI principles, but most real theorem provers work through applied a rigerously developed formal system, which is very much unlike how a human generally tries to solve the same sorts of problems.
That wasn't my point. The poster said you could do logic programming *in* Perl. Of course you can implement a logic programming system in Perl, but that's not the same as what the original poster implied.
How many of you use ML, Prolog, Lisp or Scheme in your everyday life? But these languages have their own purpose, their own market niche, mainly AI R&D.
I've never actually heard of ML being particularly popular for AI applications. It was originally developed for theorem proving applications (which if you stretch it, might be considered AI), and remains popular in that area, and has also gained considerable popularity with programming language theorists.
Okay, I've seen the first three done, but I'm curious to see one does logic programming in Perl? Of course, you could write the code to implement it, but that's not quite the same.
As cheesy as this post may sound (and trollish, for that matter)
I wasn't aiming for a troll, more like an informative look on how ridiculious Unisys is taking this. If they were even trying to be remotely cooperative with smaller software developers who simply want to incorporate their technology, I think people would be a lot less critical of their ownership of this patent.
So I have this graphics library for novice programmers I have developed. I recently begain work on a new version, and many of my users have request GIF support. I've mostly told them that PNG is really what they want, but to give myself more ammunition, I actually decided to see if I could get Unisys to give me a license for using LZW in my library.
As my library is freely available and the entire project is non-profit, I figured I might be able to get a license at no cost, as the Unisys page on LZW implies this is possible. So I e-mail off my license request. They send me back a questionaire about the nature of my software. I fill out and send it back. They e-mail me back, saying yeah we can license it to you for a fee, just tell us where to fax the forms. I reiterate the non-profit nature of my software and ask just how much the licensing fee actually is. They e-mail back 5000$, and that a) they can't license it to me anyway as they are only allowed to license to companies, not individuals and b) that users of my library, in order to be legal, would also need to license their use of LZW seperately (most likely for another 5000$).
So there you have it. Unisys is evil and this damn patent nonsense must stop.
GTK suffers a bit from not-invented-here syndrome, and ignores existing standards like.Xdefaults and the X resources mechanism. I thought we liked standards around here? Yes, I know it's somehow possible through GTK's own customization files to accomplish these tasks, but why not use the existing standard mechanisms to accomplish the same task?
Standards are good if they aren't completely borked. If they are, they simply make life intolerable. The following URL explains how this applies to X in more detail than I could: The X-Windows Disaster
By your own statements, abstraction then is a tradeoff between larger programs (i.e. compiler creating a for loop for the abstraction) and slower programs (compiler putting runtime code to figure out what to do with the abstraction, i.e. RTTI). Some of the results of tradeoffs may be insignificant but for code that requires speed, a programmer must know what performance he will expect from what he writes.
You are missing the point. The point was that there should be a simpler way to express the addition of arrays or lists. If you have to add two lists, making an abstraction such as C = A + B to do so adds no overhead, the computer still has to use the for loop no matter what. It is completely notational.
In other words, your just trading divide by zero generating an exception for addition/subtraction generating an exception... not really a big win, is it?
No, you need to understand how types work. The compiler would not allow you to compile this code, because it would know at compile time that you are breaking the invariant. In cases where it couldn't prove that you were doing something bad, it would then insert a runtime check.
His C=A+B argument is a good example. The function which adds an element of A to an element of B incurs overhead because it is a function. If you make special allowances for the list-of cases then you have just undid the abstraction. Yes, optimizers can do good things, but they only work so far.
Uh, if your compiler and language are reasonably modern, this will incur no overhead whatsover. For example, the compiler will know that all these variables are arrays (or lists) and will generate the correct code to add them. No extra overhead is required over using a for loop instead.
Slashdot Mirror
That's a pretty pathetic argument. Firstly, that's like saying guns aren't capable of killing people, as long as you don't use them. That they can kill people, regardless of whether they are used or not, is an inheirant potential in them. So saying C++ is typesafe by telling people not to use any unsafe operations is similarly incorrect.
Secondly, it is possible to crash C++ programs even if you never use any unsafe constructs. For example,
int* foo;
std::cout << foo[0] << std::endl;
Oops, I segfaulted. Okay, so I used a pointer, let me give you another example:
vector<int> foo;
std::cout << foo[10] << std::endl;
Segfault, you lose.
No, you're the incompetent stupid fuck. Not all recovery CDs work as Windows CDs. The recovery CD for my Vaio is just one big binary image.
Theorem proving in most cases has never been a part of AI research. It is possible to implement a theorem prover using AI principles, but most real theorem provers work through applied a rigerously developed formal system, which is very much unlike how a human generally tries to solve the same sorts of problems.
That wasn't my point. The poster said you could do logic programming *in* Perl. Of course you can implement a logic programming system in Perl, but that's not the same as what the original poster implied.
How many of you use ML, Prolog, Lisp or Scheme in your everyday life? But these languages have their own purpose, their own market niche, mainly AI R&D.
I've never actually heard of ML being particularly popular for AI applications. It was originally developed for theorem proving applications (which if you stretch it, might be considered AI), and remains popular in that area, and has also gained considerable popularity with programming language theorists.
Okay, I've seen the first three done, but I'm curious to see one does logic programming in Perl? Of course, you could write the code to implement it, but that's not quite the same.
As cheesy as this post may sound (and trollish, for that matter)
I wasn't aiming for a troll, more like an informative look on how ridiculious Unisys is taking this. If they were even trying to be remotely cooperative with smaller software developers who simply want to incorporate their technology, I think people would be a lot less critical of their ownership of this patent.
Use MNG then. It allows for animation.
So I have this graphics library for novice programmers I have developed. I recently begain work on a new version, and many of my users have request GIF support. I've mostly told them that PNG is really what they want, but to give myself more ammunition, I actually decided to see if I could get Unisys to give me a license for using LZW in my library.
As my library is freely available and the entire project is non-profit, I figured I might be able to get a license at no cost, as the Unisys page on LZW implies this is possible. So I e-mail off my license request. They send me back a questionaire about the nature of my software. I fill out and send it back. They e-mail me back, saying yeah we can license it to you for a fee, just tell us where to fax the forms. I reiterate the non-profit nature of my software and ask just how much the licensing fee actually is. They e-mail back 5000$, and that a) they can't license it to me anyway as they are only allowed to license to companies, not individuals and b) that users of my library, in order to be legal, would also need to license their use of LZW seperately (most likely for another 5000$).
So there you have it. Unisys is evil and this damn patent nonsense must stop.
GTK suffers a bit from not-invented-here syndrome, and ignores existing standards like .Xdefaults and the X resources mechanism. I thought we liked standards around here? Yes, I know it's somehow possible through GTK's own customization files to accomplish these tasks, but why not use the existing standard mechanisms to accomplish the same task?
Standards are good if they aren't completely borked. If they are, they simply make life intolerable. The following URL explains how this applies to X in more detail than I could: The X-Windows Disaster
By your own statements, abstraction then is a tradeoff between larger programs (i.e. compiler creating a for loop for the abstraction) and slower programs (compiler putting runtime code to figure out what to do with the abstraction, i.e. RTTI). Some of the results of tradeoffs may be insignificant but for code that requires speed, a programmer must know what performance he will expect from what he writes.
You are missing the point. The point was that there should be a simpler way to express the addition of arrays or lists. If you have to add two lists, making an abstraction such as C = A + B to do so adds no overhead, the computer still has to use the for loop no matter what. It is completely notational.
In other words, your just trading divide by zero generating an exception for addition/subtraction generating an exception... not really a big win, is it?
No, you need to understand how types work. The compiler would not allow you to compile this code, because it would know at compile time that you are breaking the invariant. In cases where it couldn't prove that you were doing something bad, it would then insert a runtime check.
His C=A+B argument is a good example. The function which adds an element of A to an element of B incurs overhead because it is a function. If you make special allowances for the list-of cases then you have just undid the abstraction. Yes, optimizers can do good things, but they only work so far.
Uh, if your compiler and language are reasonably modern, this will incur no overhead whatsover. For example, the compiler will know that all these variables are arrays (or lists) and will generate the correct code to add them. No extra overhead is required over using a for loop instead.