Although I totally agree with you, let's not forget that behind professional sports, there are gazillions of dollars. So it's not 'professional sports vs freedom', it's 'megabucks vs freedom', and we all know who wins when the word 'bucks' appear in a sentence...
The reason is that the graphical output of a browser is not the result of a Turing complete program. If HTML was Turing-complete, output would be the same in all browsers, because they would all run the same program (provided that the browser itself implements a set of minimal standards correctly).
I have said it many times, and I will say it again: the world needs a distributed programming platform, where the GUI is the output of a distributed program, not a textual description of graphics. HTML, HTML5, CSS, XHTML, Forms, are all redundant solutions to the very same problem.
Isn't it funny that the best GUI ever invented is now part of history?
NeWS was not only networked like the X-Window system, but it also had its own postscript-like programming language that it allowed programs to be transmitted to the display server for execution...which means that heavy stuff like CAD drawings could be really fast.
NeWS was very beautiful; it had very nice UI elements, fonts and colors, and it was even animated. During my service in the navy, I once saw the UI of a tactical system, and it was all in NeWS. Extremely rich UI, very responsive, very impressive...
"If spirituality offers guidance as to WHY we're here, then science attempts to explain HOW."
Ok then. Since you are a spiritual person, and you have understood that spirituality offers guidance as to WHY we are here, please enlighten us: WHY ARE WE HERE?
"Oh, another "halting problem" bogus answer. There are languages where the compiler knows what's locked at compile time. The Ada "rendezvous" approach knows, for example."
It's not bogus. Consider the following pseudo code:
int main() { cout << "enter a number: "; int i; cin >> i; cout << "creating tree of depth " << i << endl; someNode = createTree(i); cout << "pick a node number\n"; int n; cin >> n; someNode = getRandomNode(n); CreateThread(threadProc1); }
In the above piece of code, there is no way for the compiler to know where someNode points to, because its completely random, i.e. it depends on the input data.
The Ada rendezvous mechanism does not synchronize over data, it synchronizes on control flow. It's the responsibility of the programmer to provide the appropriate data. In other words, it's nothing else than the Java's synchronized keyword.
Yes. And that's a good thing. Deadlocks show up early in debugging; race conditions show up late. This is, in fact, a classic source of programming problems - lack of a clear understanding of when control is "inside" an object. Java has the problem that there's no way to say that control is temporarily leaving an object. The Microsoft Spec# team, which is doing proofs of correctness for C#, has addressed this, though.
You never know when a deadlock will hit you. Sometimes you may run the same program 100s of times, and there is no deadlock, and then there are 100 times that it deadlocks. Again, due to the halting problem, there can be no definitive decision about which data of the program might have deadlocks; the same is valid for race conditions.
"Predefined places"? I know there's a cult of "lockless programming", but that approach is very difficult to debug.
No, it is not. I have written a small Actor implementation where the only locking is when a message is placed in an object's queue and when a thread is being placed on a future's waiting list. In my implementation, no thread is suspended, they all spin using Interlocked functions, so there can be no deadlock.
That's why compilers need to know more about what locks what. Tracing dependency issues is better done by programs than by people.
Don't insist on things that can't be done. Please go study the halting problem carefully. I used to think like you ("why is the compiler so stupid?"), but there is a reason behind all the problems. It's a property of the universe that there can be no proof by a Turing machine that another Turing machine can terminate; you see, all Turing machines are equivalent, so you can't prove something by itself (you need a higher system which provides proofs for the axioms of the subsystem).
Oh, a "compare and swap" fan. Actually, most of the better databases accumulate a list of what objects have been touched by a transaction, and if there's an intersection between the lists for two transactions, one of them has to be backed out. Even MySQL does this now. There's a proposal to provide similar transaction-like semantics for C++, and that might be a promising idea. It's more idiot-proof than most other approaches.
That's optimistic locking, and lockless thread synchronization is the same: a tr
It's been 2,800 years from the Troi war. You'd think the "who's got the biggest cock" race would be over by now. Well, don't tell that to Iranians, Palestinians, Somalians etc.
The problem with Windows is that it's not modular...you can't just replace the graphics subsystem, for example, because lots of other things depend on it.
For example, you can't use another graphical technology with Windows apps, because win32 applications depend on message WM_QUIT, transmitted through the GUI message queue. On Unix, if you don't like one window system, you can replace it with another, provided that they follow the same standard.
This little 'problem' forces Microsoft to update everything at once, instead of updating small parts of the O/S each time...and that leads to situations like Vista, where you need 5 years to lock down everything to a working state.
If it happened to us, we would consider it the wrath of God and fulfillment of the prophecies. Now that it did not happen to us, it's just a space phenomenon.
I don't believe that it can be done, at least on 80x86. At the very least, an atomic test and set is required to avoid concurrency issues.
If you mean that you don't need spinlocks at every case, yeap, that's true: a thread can write to the end of the queue while another thread can read from the queue, as long as the two threads manage unrelated data.
"I did this in Objective-C, which has some advantages over C++. The first is that messages (method calls) are first-class objects, and so can be passed across threads transparently (i.e. the code is identical when calling a method in an object in its own thread and calling a local object, the only difference is the constructor you use when creating the object)."
It's no big deal in c++ as well. All you have to do is write some classes which wrap method pointers. I wrote a 20-line program which automatically produced the code for const, non-const, void and non-void methods.
"I also implemented futures using this mechanism. If your method returns an object, then it is replaced by a proxy object which blocks when you send it any messages"
I did the same, but I replaced blocking with message processing, so as that I can't have any deadlocks.
"(if you read Lambda the Ultimate, you might have seen this already)."
I am sorry, but the people at LtU are a bunch of morons. No wonder their pet languages go nowhere. And I call them morons in the scientific meaning of the word: they can never justify the reasons why pure functional programming is the best there is, or why state is the root of all evil. I have put so many arguments against theirs, and when they can't answer, they change the subject. I strongly believe that state is not the root of all evil, undisciplined use of state is (just like undisciplined use of everything else is bad as well). And the so called advantages of functional programming are not advantages of functional programming at all, because the very same advantages can exist in imperative languages. They conveniently ignore the facts that imperative programming is way simpler in real life, and they have never taken the challenge of proving their claims: they never showed me, for example, despite my numerous calls, purely functional code that does the model-view-controller paradigm, or a pure functional sorting algorithm as quick as in-place quicksort. Good luck sorting a database table of thousands of records with functional quicksort. And they have not yet recognized the fact that their languages can't catch logical bugs, just like imperative languages can't (I had once a professor that insisted his purely functional ML multithreaded code did not block...but when I run the program, it blocked randomly after a set of iterations. Yeah, thanks a lot), and that's where the problem is.
"Of course, you can't really do this properly in an imperative language. A functional language with built-in support for message passing and process creation (like Erlang) is the way to go, long-term."
Bullshit. I've done it in c++, using Boehm's gc and pthreads, and the code was less than 100 lines of code (excluding the code for the method wrappers). Actually, 95% of the code was about a parallel operator new which returned a future instead of a pointer, and a class which managed threads (so I can reuse them easily).
I apologize for the harsh tone, but I am extremely frustrated by comments like 'language X can't do this' or 'only this can do that' without any proof...and the web is full of that.
First of all, no language knows what data is locked at compile time. The problem of deciding what is locked and what is not is undecidable, just like everything else that submits to the halting problem. There is no compiler that can decide when something happens in a program and when it does not.
Secondly, a keyword like 'synchronized' does not buy you anything: it's just syntax sugar for pthread_mutex_lock/pthread_mutex_unlock, and it can easily be emulated with a macro in c++:
Thirdly, it's very easy to make a Java program deadlock using the 'synchronized' keyword. For example, let's say we have two classes that recursively call each other from different threads...instant deadlock.
The key to multithreading programming is to avoid locking altogether. It's possible to do it, using atomic functions at predefined places.
Forthly, your solution on declaring items within a critical section does not work (see #1 for explanation). For example, what if you declare a pointer inside the critical section, and then deep in an algorithm, or worse, deep in a dll loaded at run-time, the pointer is assigned a value which points to a non-synchronized object?
#5, in databases, what is the most common approach is optimistic locking: you tell the database that you want to update X if Y's value is Z. That's the solution for multithreading as well...it's called acquire semantics, and PowerPC CPUs even support it at hardware level. Atomic test and set instructions are a similar approach.
In databases, in 99% of cases, locking happens only in batch procedures within the database. Outside of it, locking something (a row, or, even worse, a table), is just asking for trouble.
Finally, the question 'who owns what' in a programming language shouldn't exist: nobody should own anything, freeing the programmer from worrying about ownership. This can happen only with garbage collection.
It's not misleading at all, if you have ever studied the subject you would see how things are.
First of all, allocating an object on the stack can work only if we are sure that the address of this object will not escape the stack frame it is declared into. If we are not sure (perhaps because the algorithm we have at our hands is complex), then we have no choice but allocating the object on the heap.
Secondly, by adding garbage collection to c++, it does not mean that you can't allocate objects on the stack any more. Garbage collection for c++ exists (Boehm's gc), but it is way more inefficient and problematic than it ought to be.
Thirdly, raw data copying is a very quick operation. Even the raw PCI bus can move 133 MB/second...this means that, for most programs where the actual live set is very small (usually under 64 MB), copying takes very little time to be executed.
Forthly, c++ has the advantage over languages that do not have stack allocation and templates. In c++, the amount of heap objects is much smaller.
As the situation is right now, Java comes on top in many benchmarks against c++, and one of the advantages is garbage collection. The execution of a Java program might be slower than the corresponding c++ program, but overall Java wins because of optimizations applied in run-time, and the collector helps in that.
Finally, the greatest advantage of garbage collection is that it saves tremendous amounts of money off debugging memory management issues. There is no c++ application that has not crashed, at least once, from a memory management problem. In Java, there is no such thing.
Slashdot Mirror
Don't tell it to me buddy, tell it to those that do it. I am not supporting the idea.
It's not a proposal, it's a comment. And the megabucks are not about athletes' wages, but about advertising, stocks, transfers, TV etc
Why doesn't Firefox use the Boehm's gc? it's free, mature, and very fast.
Although I totally agree with you, let's not forget that behind professional sports, there are gazillions of dollars. So it's not 'professional sports vs freedom', it's 'megabucks vs freedom', and we all know who wins when the word 'bucks' appear in a sentence...
vi vs emacs
The reason is that the graphical output of a browser is not the result of a Turing complete program. If HTML was Turing-complete, output would be the same in all browsers, because they would all run the same program (provided that the browser itself implements a set of minimal standards correctly).
I have said it many times, and I will say it again: the world needs a distributed programming platform, where the GUI is the output of a distributed program, not a textual description of graphics. HTML, HTML5, CSS, XHTML, Forms, are all redundant solutions to the very same problem.
Isn't it funny that the best GUI ever invented is now part of history?
NeWS was not only networked like the X-Window system, but it also had its own postscript-like programming language that it allowed programs to be transmitted to the display server for execution...which means that heavy stuff like CAD drawings could be really fast.
NeWS was very beautiful; it had very nice UI elements, fonts and colors, and it was even animated. During my service in the navy, I once saw the UI of a tactical system, and it was all in NeWS. Extremely rich UI, very responsive, very impressive...
Hey, the first thing that came to mind when reading this article is exactly what you side. Isn't life funny?
And what you describe may be perhaps the only way to colonize the universe...
It would also be about the spectacular areas you can visit, the clever puzzles, the awesome bosses...
Perhaps the game is so good that after making it, the guys at 3d Realms spend all their time playing it, and they don't have time to release it...
I am not touching Perl for any purpose. I'd rather do it in machine code than Perl... :-)
Isn't this law invalid in the world of Quantum Physics, where a particle can be HERE and THERE at the same time?
"If spirituality offers guidance as to WHY we're here, then science attempts to explain HOW."
Ok then. Since you are a spiritual person, and you have understood that spirituality offers guidance as to WHY we are here, please enlighten us: WHY ARE WE HERE?
Unless a computer knows things the way a human does, it's not possible for natural language queries to ever work.
It's not bogus. Consider the following pseudo code:
In the above piece of code, there is no way for the compiler to know where someNode points to, because its completely random, i.e. it depends on the input data.
The Ada rendezvous mechanism does not synchronize over data, it synchronizes on control flow. It's the responsibility of the programmer to provide the appropriate data. In other words, it's nothing else than the Java's synchronized keyword.
You never know when a deadlock will hit you. Sometimes you may run the same program 100s of times, and there is no deadlock, and then there are 100 times that it deadlocks. Again, due to the halting problem, there can be no definitive decision about which data of the program might have deadlocks; the same is valid for race conditions.
No, it is not. I have written a small Actor implementation where the only locking is when a message is placed in an object's queue and when a thread is being placed on a future's waiting list. In my implementation, no thread is suspended, they all spin using Interlocked functions, so there can be no deadlock.
Don't insist on things that can't be done. Please go study the halting problem carefully. I used to think like you ("why is the compiler so stupid?"), but there is a reason behind all the problems. It's a property of the universe that there can be no proof by a Turing machine that another Turing machine can terminate; you see, all Turing machines are equivalent, so you can't prove something by itself (you need a higher system which provides proofs for the axioms of the subsystem).
That's optimistic locking, and lockless thread synchronization is the same: a tr
there is a problem with GC_INIT() which prevents threads from being correctly initialized. The collector works ok without threads.
.gz file that can be grabbed from the homepage. It has been corrected in the CVS (I just found this out this afternoon).
The bug is in the
It's been 2,800 years from the Troi war. You'd think the "who's got the biggest cock" race would be over by now. Well, don't tell that to Iranians, Palestinians, Somalians etc.
The problem with Windows is that it's not modular...you can't just replace the graphics subsystem, for example, because lots of other things depend on it.
For example, you can't use another graphical technology with Windows apps, because win32 applications depend on message WM_QUIT, transmitted through the GUI message queue. On Unix, if you don't like one window system, you can replace it with another, provided that they follow the same standard.
This little 'problem' forces Microsoft to update everything at once, instead of updating small parts of the O/S each time...and that leads to situations like Vista, where you need 5 years to lock down everything to a working state.
If it happened to us, we would consider it the wrath of God and fulfillment of the prophecies. Now that it did not happen to us, it's just a space phenomenon.
"You don't need spinlocks for the message queues"
I don't believe that it can be done, at least on 80x86. At the very least, an atomic test and set is required to avoid concurrency issues.
If you mean that you don't need spinlocks at every case, yeap, that's true: a thread can write to the end of the queue while another thread can read from the queue, as long as the two threads manage unrelated data.
"I did this in Objective-C, which has some advantages over C++. The first is that messages (method calls) are first-class objects, and so can be passed across threads transparently (i.e. the code is identical when calling a method in an object in its own thread and calling a local object, the only difference is the constructor you use when creating the object)."
It's no big deal in c++ as well. All you have to do is write some classes which wrap method pointers. I wrote a 20-line program which automatically produced the code for const, non-const, void and non-void methods.
"I also implemented futures using this mechanism. If your method returns an object, then it is replaced by a proxy object which blocks when you send it any messages"
I did the same, but I replaced blocking with message processing, so as that I can't have any deadlocks.
"(if you read Lambda the Ultimate, you might have seen this already)."
I am sorry, but the people at LtU are a bunch of morons. No wonder their pet languages go nowhere. And I call them morons in the scientific meaning of the word: they can never justify the reasons why pure functional programming is the best there is, or why state is the root of all evil. I have put so many arguments against theirs, and when they can't answer, they change the subject. I strongly believe that state is not the root of all evil, undisciplined use of state is (just like undisciplined use of everything else is bad as well). And the so called advantages of functional programming are not advantages of functional programming at all, because the very same advantages can exist in imperative languages. They conveniently ignore the facts that imperative programming is way simpler in real life, and they have never taken the challenge of proving their claims: they never showed me, for example, despite my numerous calls, purely functional code that does the model-view-controller paradigm, or a pure functional sorting algorithm as quick as in-place quicksort. Good luck sorting a database table of thousands of records with functional quicksort. And they have not yet recognized the fact that their languages can't catch logical bugs, just like imperative languages can't (I had once a professor that insisted his purely functional ML multithreaded code did not block...but when I run the program, it blocked randomly after a set of iterations. Yeah, thanks a lot), and that's where the problem is.
"Of course, you can't really do this properly in an imperative language. A functional language with built-in support for message passing and process creation (like Erlang) is the way to go, long-term."
Bullshit. I've done it in c++, using Boehm's gc and pthreads, and the code was less than 100 lines of code (excluding the code for the method wrappers). Actually, 95% of the code was about a parallel operator new which returned a future instead of a pointer, and a class which managed threads (so I can reuse them easily).
I apologize for the harsh tone, but I am extremely frustrated by comments like 'language X can't do this' or 'only this can do that' without any proof...and the web is full of that.
Not a CPU problem, but a programming model problem, which forces the programmers to avoid using parallelism.
When Boehm fixes the bugs in his gc (version 7.0, Windows), I will make an open source library.
No, no, no, you got it all wrong!
First of all, no language knows what data is locked at compile time. The problem of deciding what is locked and what is not is undecidable, just like everything else that submits to the halting problem. There is no compiler that can decide when something happens in a program and when it does not.
Secondly, a keyword like 'synchronized' does not buy you anything: it's just syntax sugar for pthread_mutex_lock/pthread_mutex_unlock, and it can easily be emulated with a macro in c++:
#define synchronized for(Lock l; l.isLocked(); i.unlock())
Thirdly, it's very easy to make a Java program deadlock using the 'synchronized' keyword. For example, let's say we have two classes that recursively call each other from different threads...instant deadlock.
The key to multithreading programming is to avoid locking altogether. It's possible to do it, using atomic functions at predefined places.
Forthly, your solution on declaring items within a critical section does not work (see #1 for explanation). For example, what if you declare a pointer inside the critical section, and then deep in an algorithm, or worse, deep in a dll loaded at run-time, the pointer is assigned a value which points to a non-synchronized object?
#5, in databases, what is the most common approach is optimistic locking: you tell the database that you want to update X if Y's value is Z. That's the solution for multithreading as well...it's called acquire semantics, and PowerPC CPUs even support it at hardware level. Atomic test and set instructions are a similar approach.
In databases, in 99% of cases, locking happens only in batch procedures within the database. Outside of it, locking something (a row, or, even worse, a table), is just asking for trouble.
Finally, the question 'who owns what' in a programming language shouldn't exist: nobody should own anything, freeing the programmer from worrying about ownership. This can happen only with garbage collection.
It's not misleading at all, if you have ever studied the subject you would see how things are.
First of all, allocating an object on the stack can work only if we are sure that the address of this object will not escape the stack frame it is declared into. If we are not sure (perhaps because the algorithm we have at our hands is complex), then we have no choice but allocating the object on the heap.
Secondly, by adding garbage collection to c++, it does not mean that you can't allocate objects on the stack any more. Garbage collection for c++ exists (Boehm's gc), but it is way more inefficient and problematic than it ought to be.
Thirdly, raw data copying is a very quick operation. Even the raw PCI bus can move 133 MB/second...this means that, for most programs where the actual live set is very small (usually under 64 MB), copying takes very little time to be executed.
Forthly, c++ has the advantage over languages that do not have stack allocation and templates. In c++, the amount of heap objects is much smaller.
As the situation is right now, Java comes on top in many benchmarks against c++, and one of the advantages is garbage collection. The execution of a Java program might be slower than the corresponding c++ program, but overall Java wins because of optimizations applied in run-time, and the collector helps in that.
Finally, the greatest advantage of garbage collection is that it saves tremendous amounts of money off debugging memory management issues. There is no c++ application that has not crashed, at least once, from a memory management problem. In Java, there is no such thing.