a real programmer will have had to implement a Webserver compiler to run on an actual microprocessor, and that programmer will probably have used C.
... your code eventually boils down to machine language
A person who can agree with both statements has clearly accepted one intermediate language (in this case C) as a firewall between the programmer and the machine language. The same person may also be aware that the machine language is yet another proxy, this time hiding the circuitry within the microprocessor. At any rate the person has rightfully dismissed the direct, exclusive use of the machine language --- or even electronics --- as realistic for providing web services.
If you can accept being one or two layers removed from the bare hardware, the next step is inevitable. Pending on a demand from the complexity of the system to be built, there are no problems and only benefits adding a third layer. (Of course if the system is trivial, like Hello World, anyone can write it in the machine language and have it correct, optimal, and maintainable.)
Indeed a web server has been written in Haskell [link]. Haskell, in turn, has compile-to-C compilers. This example happens to use the machine-C-Haskell layering; the idea is the same with other languages and numbers of layers.
To debug the system, the C compiler team debugs the C compiler, the Haskell compiler team debugs the Haskell-to-C compiler, and finally the webserver author debugs the 2000 lines of Haskell code he writes. If the system is large enough, this partitioning of labour is the only way (the monolithic, one-man alternative is out of the question).
To optimize the system, there is the theoretically optimal way of optimizing a web server written entirely and directly in the machine language, or the practical, sub-optimal way of asking the C compiler team, the Haskell compiler team, and the webserver author to do their respective parts in writing good-enough code or generating good-enough translations. It is clear which one is realistic when the system is extremely large.
The hard work put into the compilers benefits many projects, and the cost is amortized.
So then the perfect language is one where all the real programmers have done all the work for you, and you're just a little script monkey.
To that I answer by quoting Dijkstra: "if we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." (EWD1036, page 11)
And so for example even your 10-line, 40-token launcher is too long; its information content can be expressed succintly as "new Webserver(80)" or even "Webserver 80" in any properly designed language.
When electronic calculators came out, accountants did not say "the calculators do all the arithmetic for you, and you are not a real accountant" (or did they?) Similarly for spreadsheet. The reality is, each time they are relieved of a chore, they find a more worthwhile thing to spend their time on, such as analysing various what-if scenerios, which had been intractible until the advent of spreadsheets --- a fine programming language in its own right. I now quote Asimov on the general idea: "The Machines are only a tool after all, which can help humanity progress faster by taking some of the burdens of calculations and interpretations off its back. The task of the human brain remains what it has always been; that of discovering new data to be analyzed, and of devising new concepts to be tested.... I notice that capable men are still at a premium in our society; we still need the man who is intelligent enough to think of the proper question to ask." (The Evitable Conflict, can be found in I, Robot or other collections)
Although Python, Scheme, Lisp, and Erlang do not perform static (compile-time) type checking, they perform dynamic (run-time) type checking that is equally stringent. This is why these languages can be considered almost as reliable as statically typed ones such as Haskell and ML. A program written in such languages do not crash; or they crash at the very first sign of trouble, which is the next best thing.
The same cannot be said about Perl, TCL, and C. They intentionally allow you to confuse strings with numbers with window handles with file descriptors with pointers. This is just asking for confusions and mistakes that are hard to trouble-shoot. A program written in such languages usually goes nuts and corrupts data without crashing; or by the time it crashes, it is no longer possible to identify the problem by looking at core dumps. This happens to many a student: the C program segfaults at malloc, and it is because of a memory corruption in a function that has returned several hundred steps ago. And this is just a 200-line toy program for a school assignment.
My take at the issue is not whether the program crashes or not, but how much damage it has done before it crashes and how quickly I can identify the problem. It is from the perspectives of damage control and diagnosis.
I personally prefer static typing, though I accept dynamic typing as equally useful and possibly easier to work with. But I reject weak typing. If your Perl script doesn't crash, you'd better pray that it isn't pulling your leg.
The vast number of comments posted to discuss various solutions to and aspects of this puzzle shows that mathematical reasoning is useful, or at least interesting, if only for mental recreation and exercise.
The mathematical reasoning I mention is not to be confused with school classes labelled ``math''. As you have found out, they are not very interesting.
I can easily complain about English classes like you do about Mathematics classes. Whereas you ask why we are taught angle bisection and not cheque book balancing, I can equally ask why we are made to know Shakespear and not practice on writing résumés.
Some people argue that literature is intellectually interesting and important to an advance civilization, whether it is directly useful or not. The same can be said about mathematics. Provided it is taught and learned right. The problem is that mathematics is not conveyed right by schools.
Please give mathematics a second consideration. Do not look at it as something that should be used -- any area is useful only to a small niché. Look at it as a possible pastime, an interesting art, an interesting science, a way of thinking (the insistence on precision and proofs is certainly a viable philosophy), and a framework for solving puzzles.
What was that step and why did it require a Cray[...]
That is Gaussian elimination, not unlike the task to find the `row echelon form' of matrices in your linear algebra class, except that:
the entries are 0's and 1's, and they are considered numbers in the modulo-2 system (i.e., 1+1 mod 2 = 0)
the matrix is sparse
the matrix is so large that even though its entries are just 0's and 1's (so you can use 1 bit per entry) and it is sparse (so you can use less memory in principle), it still takes GB's of memory to store
Although specialized algorithms are invented to just deal with this special case, it still takes a fast computer with fast memory access, due to the sheer size of the task; worse, no one has been able to parallelize it successfully yet, as far as I know.
Cray computers are suitable for this mainly due to its technical merits that some of you have mentioned. In addition, many of the previous factoring projects also used Cray computers for this task as well, which probably means they could use existing, proven code (and they did).
More technical and mathematical details (e.g., why need Gaussian elimination, how large is the matrix) can be found in the references of the Usenet announcement.
So why should you still bother ? Well,if you want the latest about AMD's future K7..
Or if you want to show off the size and resolution of your monitor by displaying ultra-wide paragraphs...
Or if you want to show off the colors of your monitor and the pixel depth of your display card by demonstrating that turquoise4 text on turquoise3 background is readable...
And you have the webmaster's personal guarantee: you won't find those things at Tom's hardware!
On the positive side, the initiative to report on non-x86 hardware (such as sparcs and alpha) and the idea of having a forum are novel.
Slashdot Mirror
I saw "Java 1.5 Tiger: A Developer's Notebook", O'Reilly, by David Flanagan and Brett McLaughlin. I have not looked into it in depth.
A person who can agree with both statements has clearly accepted one intermediate language (in this case C) as a firewall between the programmer and the machine language. The same person may also be aware that the machine language is yet another proxy, this time hiding the circuitry within the microprocessor. At any rate the person has rightfully dismissed the direct, exclusive use of the machine language --- or even electronics --- as realistic for providing web services.
If you can accept being one or two layers removed from the bare hardware, the next step is inevitable. Pending on a demand from the complexity of the system to be built, there are no problems and only benefits adding a third layer. (Of course if the system is trivial, like Hello World, anyone can write it in the machine language and have it correct, optimal, and maintainable.)
Indeed a web server has been written in Haskell [link]. Haskell, in turn, has compile-to-C compilers. This example happens to use the machine-C-Haskell layering; the idea is the same with other languages and numbers of layers.
To debug the system, the C compiler team debugs the C compiler, the Haskell compiler team debugs the Haskell-to-C compiler, and finally the webserver author debugs the 2000 lines of Haskell code he writes. If the system is large enough, this partitioning of labour is the only way (the monolithic, one-man alternative is out of the question).
To optimize the system, there is the theoretically optimal way of optimizing a web server written entirely and directly in the machine language, or the practical, sub-optimal way of asking the C compiler team, the Haskell compiler team, and the webserver author to do their respective parts in writing good-enough code or generating good-enough translations. It is clear which one is realistic when the system is extremely large.
The hard work put into the compilers benefits many projects, and the cost is amortized.
So then the perfect language is one where all the real programmers have done all the work for you, and you're just a little script monkey.
... I notice that capable men are still at a premium in our society; we still need the man who is intelligent enough to think of the proper question to ask." (The Evitable Conflict, can be found in I, Robot or other collections)
To that I answer by quoting Dijkstra: "if we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." (EWD1036, page 11)
And so for example even your 10-line, 40-token launcher is too long; its information content can be expressed succintly as "new Webserver(80)" or even "Webserver 80" in any properly designed language.
When electronic calculators came out, accountants did not say "the calculators do all the arithmetic for you, and you are not a real accountant" (or did they?) Similarly for spreadsheet. The reality is, each time they are relieved of a chore, they find a more worthwhile thing to spend their time on, such as analysing various what-if scenerios, which had been intractible until the advent of spreadsheets --- a fine programming language in its own right. I now quote Asimov on the general idea: "The Machines are only a tool after all, which can help humanity progress faster by taking some of the burdens of calculations and interpretations off its back. The task of the human brain remains what it has always been; that of discovering new data to be analyzed, and of devising new concepts to be tested.
Although Python, Scheme, Lisp, and Erlang do not perform static (compile-time) type checking, they perform dynamic (run-time) type checking that is equally stringent. This is why these languages can be considered almost as reliable as statically typed ones such as Haskell and ML. A program written in such languages do not crash; or they crash at the very first sign of trouble, which is the next best thing.
The same cannot be said about Perl, TCL, and C. They intentionally allow you to confuse strings with numbers with window handles with file descriptors with pointers. This is just asking for confusions and mistakes that are hard to trouble-shoot. A program written in such languages usually goes nuts and corrupts data without crashing; or by the time it crashes, it is no longer possible to identify the problem by looking at core dumps. This happens to many a student: the C program segfaults at malloc, and it is because of a memory corruption in a function that has returned several hundred steps ago. And this is just a 200-line toy program for a school assignment.
My take at the issue is not whether the program crashes or not, but how much damage it has done before it crashes and how quickly I can identify the problem. It is from the perspectives of damage control and diagnosis.
I personally prefer static typing, though I accept dynamic typing as equally useful and possibly easier to work with. But I reject weak typing. If your Perl script doesn't crash, you'd better pray that it isn't pulling your leg.
The mathematical reasoning I mention is not to be confused with school classes labelled ``math''. As you have found out, they are not very interesting.
I can easily complain about English classes like you do about Mathematics classes. Whereas you ask why we are taught angle bisection and not cheque book balancing, I can equally ask why we are made to know Shakespear and not practice on writing résumés.
Some people argue that literature is intellectually interesting and important to an advance civilization, whether it is directly useful or not. The same can be said about mathematics. Provided it is taught and learned right. The problem is that mathematics is not conveyed right by schools.
Please give mathematics a second consideration. Do not look at it as something that should be used -- any area is useful only to a small niché. Look at it as a possible pastime, an interesting art, an interesting science, a way of thinking (the insistence on precision and proofs is certainly a viable philosophy), and a framework for solving puzzles.
I say Knuth doesn't give a damn.
That is Gaussian elimination, not unlike the task to find the `row echelon form' of matrices in your linear algebra class, except that:
- the entries are 0's and 1's, and they are considered numbers in the modulo-2 system (i.e., 1+1 mod 2 = 0)
- the matrix is sparse
- the matrix is so large that even though its entries are just 0's and 1's (so you can use 1 bit per entry) and it is sparse (so you can use less memory in principle), it still takes GB's of memory to store
Although specialized algorithms are invented to just deal with this special case, it still takes a fast computer with fast memory access, due to the sheer size of the task; worse, no one has been able to parallelize it successfully yet, as far as I know.Cray computers are suitable for this mainly due to its technical merits that some of you have mentioned. In addition, many of the previous factoring projects also used Cray computers for this task as well, which probably means they could use existing, proven code (and they did).
More technical and mathematical details (e.g., why need Gaussian elimination, how large is the matrix) can be found in the references of the Usenet announcement.
Yes, partially polarizing sunglasses will let you partially view it, i.e., the contrast is not great but you still get the picture.
Well,if you want the latest about AMD's future K7..
Or if you want to show off the size and resolution of your monitor by displaying ultra-wide paragraphs...
Or if you want to show off the colors of your monitor and the pixel depth of your display card by demonstrating that turquoise4 text on turquoise3 background is readable...
And you have the webmaster's personal guarantee: you won't find those things at Tom's hardware!
On the positive side, the initiative to report on non-x86 hardware (such as sparcs and alpha) and the idea of having a forum are novel.