There are also many pieces of semantic information which the computer would have to understand. It woud have to know that your ex-wife is a person, and therefore not the desk in the background of the picture. It would have to understand that your wife is female, and therefore not the other guy in the picture. It has to know that 'whom' only refers to people, so the loathing refers to the person in the picture rather than the picture itself.
I think that you are right about the picture you draw. It is the holy grail of AI.
Therefore, it seems that the goal is both grander than the grandparent thinks and simpler than you think.
Personally, I don't think that solving the AI problem is likely within this century. But I'd be happy to be proved wrong.
Well, speaking to the Egyptian statement above... If the Pharoahs had decided to spend their money on defense, they might not have been conquered by the Persians, Macedonians, Romans, Arabs, etc. and been under the subjugation of foreign powers for a couple millenia.
Hopefully space travel will not turn out like the pyramids did.
Are you sure it can't create functions on the fly, or is that just something you don't know how to do in Java? That's a pretty serious accusation to level at a language, almost as bad as saying it can't allocate extra memory on the fly.
Java can't create functions on the fly as LISP or Scheme can do. It does have runtime reflection and class loading. This means that classes (and therefore the methods in those classes) can be loaded at runtime. But it would be quite a bit of work to use this facility to generate new functions from inside a program.
I'm more curious as to why you are so adamant that generating functions at runtime is such an important capability. Many people avoid runtime code generation because they find it harder to reason about. Could you give me some examples where you have used runtime function-generation to good effect?
This is a very useful idiom, and I am glad to hear that it is implemented in Ruby. There is a way to make this idiom even more powerful. In C++, an obect defines the ownership. Object copying is also allowed. Which means that transfer of ownership is also allowed.
For instance, suppose we have an object called foo which uses a particular resource. foo might have a method which an outsider can use to change which resource class foo uses. Because ownership is defined by an object, that object can be passed into the method, and ownership changes hands.
In Ruby, is there an analagous operation? How do you use it?
You make a number of good points. I agree that the instances where garbage collection is infinitely better than any other tool. However, there are also places where ownership is the better tool. I am not going to make the specious 'it is faster' argument here, because usually it doesn't matter.
An ideal language for me would be one where there is a GC (possibly as a default), but that also allowed ownership semantics where that is applicable. Now I am going to talk about situations that I have run across where GC wasn't that useful. Note that I am not making an argument that GC is bad (it is usually very good), but that there is a case to be made for a language where GC isn't required in all cases.
There are many cases where order of destruction is very important. There are cases where this is implicit. For instance, it is best that a 'successful completion' message is written to the log file before the log file is closes.
But there are cases where an elegant solution can depend on it. A good example of this would be streams. Streams, for the sake of argument, are objects that take in a variety of data, turn that data into bytes, and send those bytes someplace else.
Often, a stream will have attributes defining how it processes the incoming data. If the incoming is a bool and true, does it turn it into the character '1', the sequence of characters "true", or the byte 0x01? Floats (how many sig figs?), signed integers (put a sign at the front if its positive?), etc. also have choices to be made.
But if a caller sends a stream to a method for output and the method changes the state for some reason, later output might be unexpected. This is where a stack-based allocation could come in handy. A new kind of object can be created which saves the stream in its constructor and restores the stream in its destructor. If these happen at known points in the program, then all is well. If the destructor (or finalizer) is called at an undefined point, badness results.
Such a stream-state-saver object can be used by the caller to make sure that the method doesn't screw with the state. Or it could be used by the method to make sure that it doesn't step on the callers toes.
The other case where a GC might not be a help is if one were trying to develop a new kind of GC. There is no way in Java, for instance, for me to develop my new "tyrecius' patented GC" as a Java library in any kind of transparent way. I'd have to go in and modify the guts of the compiler/VM.
Finally, memory is just one kind of resource. GC's generally don't make dealing with other resources very easy. The best that one can do is to put the release of the resource in a finalizer of some kind and hope that the resource will be released in a timely manner. File Descriptors, network Sockets, database connections, etc. are all harder to deal with in an efficient and brainless way in a GC-only language.
Let me reiterate that GC is great to have in a language. But I tend to be nervous about a language if there is not a way to bypass it in the few instances when it becomes a problem.
The trivial example given is certainly fine, but why not just put pfoo on the stack if it's that trivial. Reference counting has problems with circular references; most other garbage collection schemes do not. Note: any doubly-linked list or both-way parent-child relationship is circular.
This is just silly. First of all, quite a bit of dynamic memory allocation is 0/1. You need 0 of them or you need 1 of them. In such a case, auto_ptr is great.
Second, though there are certainly cases in which auto_ptr is not suited, your examples don't hold water. In both doubly-linked lists and tree structures, one uses an auto_ptr as an owner to your eldest child and a normal pointer as a handle to your parent. Likewise, in a linked list, the auto_ptr points forward and a handle points back.
A case where auto_ptr's are completely inadequate is in a data structure representing a vertex in a generalized graph.
There are limits to any tool, but a hammer is still useful even if it cannot chop wood.
Let me get this straight. On the one hand I can declare the contained type once at declaration time. On the other hand, I can declare the contained type every time it is used.
Speaking from personal experience, objects are used at least several times after being declared.
Forth is unlike most other languages. Also, it was designed (like LISP, every scripting language, and others) to avoid the debug, recompile cycle that is to common.
This is one of the reasons why I love my ISP. They have specific, known, per week bandwidth (3 gb/week). And they amortize it over a month so that if you go over a bit one week you aren't in trouble. If you need more, just call then up and pay little more for it. They even give you a place to log in and track your bandwidth usage.
Speaking of which. I used to worked at a collection agency. Apparently, a debtor once sent in as many M&Ms as dollars they owed. Even had the count notarized.
A very important point that the author misses here is the fact that most people are pretty bad at literacy. This usually isn't very much of a problem. Even if I'm a bad writer I can usually get my point across to a co-operative reader.
But a computer is anything but co-operative. Being a bad programmer in the computer realm is a much more serious handicap than being a bad writer in the literature realm. Computers are much less forgiving of mistakes. And there tends to be a lot more complexity engendered in computer programs than in the day to day things that people need to write down.
One of the reasons that literacy is widespread is that in general, each level of better writing/reading makes you better off than the previous one. Even if I can only write at a grade school level, that is more useful than not being able to write at all. Those who read can see through the grammatical mistakes and the crude vocabulary and get my intent. Learning to read at a high school provides a marginal increase in the utility of my skill.
But this represents a key difference with programming. Computer programming provides almost no practical usefulness until one reaches the college level (and arguably beyond). I look back at the programs I wrote in grade school and there was none of the robustness or correctness that is needed in a generally useful program. It was still the programming equivalent of the Dick and Jane books.
It wasn't until I got into college that I started doing interesting stuff. Even then, there are few uses in day to day life for the things that I write.
To sum up, the Dick and Jane book phase, where one is reading/writing simply to learn the skill rather than to actually do something with it, is much longer with computer programming than with normal literacy. This raises the bar to near impossible heights for the general population.
Exponential up, logarithmic down. They are opposites, like plus and minus. If a progression is exponential, it is logarithmic, and vice versa.
That said, such progressions are generally said to be logarithmic. It is just a convention. Like the fact that geometric and arithmetic series can be thought of as division and subtraction respectively, but we generally don't.
Slashdot Mirror
There are also many pieces of semantic information which the computer would have to understand. It woud have to know that your ex-wife is a person, and therefore not the desk in the background of the picture. It would have to understand that your wife is female, and therefore not the other guy in the picture. It has to know that 'whom' only refers to people, so the loathing refers to the person in the picture rather than the picture itself.
I think that you are right about the picture you draw. It is the holy grail of AI.
Therefore, it seems that the goal is both grander than the grandparent thinks and simpler than you think.
Personally, I don't think that solving the AI problem is likely within this century. But I'd be happy to be proved wrong.
Well, speaking to the Egyptian statement above... If the Pharoahs had decided to spend their money on defense, they might not have been conquered by the Persians, Macedonians, Romans, Arabs, etc. and been under the subjugation of foreign powers for a couple millenia.
Hopefully space travel will not turn out like the pyramids did.
Are you sure it can't create functions on the fly, or is that just something you don't know how to do in Java? That's a pretty serious accusation to level at a language, almost as bad as saying it can't allocate extra memory on the fly.
Java can't create functions on the fly as LISP or Scheme can do. It does have runtime reflection and class loading. This means that classes (and therefore the methods in those classes) can be loaded at runtime. But it would be quite a bit of work to use this facility to generate new functions from inside a program.
I'm more curious as to why you are so adamant that generating functions at runtime is such an important capability. Many people avoid runtime code generation because they find it harder to reason about. Could you give me some examples where you have used runtime function-generation to good effect?
I agree that there are many flaws with the syntax of C++ (especially variable declaration syntax).
What in particular do you abhor? What would you replace it with? Do you favor LISP/Scheme syntax? Do you favor ML syntax? Do you favor C#/Java syntax?
This is a very useful idiom, and I am glad to hear that it is implemented in Ruby. There is a way to make this idiom even more powerful. In C++, an obect defines the ownership. Object copying is also allowed. Which means that transfer of ownership is also allowed.
For instance, suppose we have an object called foo which uses a particular resource. foo might have a method which an outsider can use to change which resource class foo uses. Because ownership is defined by an object, that object can be passed into the method, and ownership changes hands.
In Ruby, is there an analagous operation? How do you use it?
Thanks for pointing this out to me. I don't know all that much about D apart from the feature list they posted.
One thing you mentioned in passing was that you revile auto_ptr. auto_ptr definitely has its limits, but I'm curious as to why you detest it.
You make a number of good points. I agree that the instances where garbage collection is infinitely better than any other tool. However, there are also places where ownership is the better tool. I am not going to make the specious 'it is faster' argument here, because usually it doesn't matter.
An ideal language for me would be one where there is a GC (possibly as a default), but that also allowed ownership semantics where that is applicable. Now I am going to talk about situations that I have run across where GC wasn't that useful. Note that I am not making an argument that GC is bad (it is usually very good), but that there is a case to be made for a language where GC isn't required in all cases.
There are many cases where order of destruction is very important. There are cases where this is implicit. For instance, it is best that a 'successful completion' message is written to the log file before the log file is closes.
But there are cases where an elegant solution can depend on it. A good example of this would be streams. Streams, for the sake of argument, are objects that take in a variety of data, turn that data into bytes, and send those bytes someplace else.
Often, a stream will have attributes defining how it processes the incoming data. If the incoming is a bool and true, does it turn it into the character '1', the sequence of characters "true", or the byte 0x01? Floats (how many sig figs?), signed integers (put a sign at the front if its positive?), etc. also have choices to be made.
But if a caller sends a stream to a method for output and the method changes the state for some reason, later output might be unexpected. This is where a stack-based allocation could come in handy. A new kind of object can be created which saves the stream in its constructor and restores the stream in its destructor. If these happen at known points in the program, then all is well. If the destructor (or finalizer) is called at an undefined point, badness results.
Such a stream-state-saver object can be used by the caller to make sure that the method doesn't screw with the state. Or it could be used by the method to make sure that it doesn't step on the callers toes.
The other case where a GC might not be a help is if one were trying to develop a new kind of GC. There is no way in Java, for instance, for me to develop my new "tyrecius' patented GC" as a Java library in any kind of transparent way. I'd have to go in and modify the guts of the compiler/VM.
Finally, memory is just one kind of resource. GC's generally don't make dealing with other resources very easy. The best that one can do is to put the release of the resource in a finalizer of some kind and hope that the resource will be released in a timely manner. File Descriptors, network Sockets, database connections, etc. are all harder to deal with in an efficient and brainless way in a GC-only language.
Let me reiterate that GC is great to have in a language. But I tend to be nervous about a language if there is not a way to bypass it in the few instances when it becomes a problem.
The trivial example given is certainly fine, but why not just put pfoo on the stack if it's that trivial. Reference counting has problems with circular references; most other garbage collection schemes do not. Note: any doubly-linked list or both-way parent-child relationship is circular.
This is just silly. First of all, quite a bit of dynamic memory allocation is 0/1. You need 0 of them or you need 1 of them. In such a case, auto_ptr is great.
Second, though there are certainly cases in which auto_ptr is not suited, your examples don't hold water. In both doubly-linked lists and tree structures, one uses an auto_ptr as an owner to your eldest child and a normal pointer as a handle to your parent. Likewise, in a linked list, the auto_ptr points forward and a handle points back.
A case where auto_ptr's are completely inadequate is in a data structure representing a vertex in a generalized graph.
There are limits to any tool, but a hammer is still useful even if it cannot chop wood.
Let me get this straight. On the one hand I can declare the contained type once at declaration time. On the other hand, I can declare the contained type every time it is used.
Speaking from personal experience, objects are used at least several times after being declared.
What you mean is:
Forth is unlike most other languages. Also, it was designed (like LISP, every scripting language, and others) to avoid the debug, recompile cycle that is to common.
RPC causes untold security/authentication headaches and is often hard to program with besides.
See ESR
Hey. I think you've hit upon a new motto for Open Office: "We give you every feature but Clippy."
This is one of the reasons why I love my ISP. They have specific, known, per week bandwidth (3 gb/week). And they amortize it over a month so that if you go over a bit one week you aren't in trouble. If you need more, just call then up and pay little more for it. They even give you a place to log in and track your bandwidth usage.
www.xmission.com in Utah and Las Vegas
Speaking of which. I used to worked at a collection agency. Apparently, a debtor once sent in as many M&Ms as dollars they owed. Even had the count notarized.
The compiler would flag an error with that code. Sometimes known as a compile-time error or compiler error.
Because that'd cause a compiler error.
A very important point that the author misses here is the fact that most people are pretty bad at literacy. This usually isn't very much of a problem. Even if I'm a bad writer I can usually get my point across to a co-operative reader.
But a computer is anything but co-operative. Being a bad programmer in the computer realm is a much more serious handicap than being a bad writer in the literature realm. Computers are much less forgiving of mistakes. And there tends to be a lot more complexity engendered in computer programs than in the day to day things that people need to write down.
One of the reasons that literacy is widespread is that in general, each level of better writing/reading makes you better off than the previous one. Even if I can only write at a grade school level, that is more useful than not being able to write at all. Those who read can see through the grammatical mistakes and the crude vocabulary and get my intent. Learning to read at a high school provides a marginal increase in the utility of my skill.
But this represents a key difference with programming. Computer programming provides almost no practical usefulness until one reaches the college level (and arguably beyond). I look back at the programs I wrote in grade school and there was none of the robustness or correctness that is needed in a generally useful program. It was still the programming equivalent of the Dick and Jane books.
It wasn't until I got into college that I started doing interesting stuff. Even then, there are few uses in day to day life for the things that I write.
To sum up, the Dick and Jane book phase, where one is reading/writing simply to learn the skill rather than to actually do something with it, is much longer with computer programming than with normal literacy. This raises the bar to near impossible heights for the general population.
Exponential up, logarithmic down. They are opposites, like plus and minus. If a progression is exponential, it is logarithmic, and vice versa.
That said, such progressions are generally said to be logarithmic. It is just a convention. Like the fact that geometric and arithmetic series can be thought of as division and subtraction respectively, but we generally don't.
See Blitz++. Its amazing what one can do with turing complete templates.