I once heard that it was based on an older convention about numbers of slashes. Using multiple slashes eats your way to be root until you meet something else with more slashes (or was it at least as many? I forget)
So if you're in a context like///foo//bar/f
and you append a//onion/cow/patty
the resulting///foo//bar/f//onion/cow/patty
reduces to///foo/onion/cow/patty
(or was it///foo//bar//onion/cow/patty ? I forget)
So the number of slashes was a way of indicating what level of the naming hierarchy you were replacing.
But the more general concept was forgotten somewhere along the line.
How about a platform-independent programming language complete with systems programming features, garbage collection, object-inheritance, type-safety and a way to bypass it when necessary?
Have a look at Modula 3 and its libraries: http://en.wikipedia.org/wiki/Modula-3
In case it wasn't clear, my point was that a hypothetical intelligent (human-level or higher) compiler can extract the purpose/behavior of a program from its source code, and generate optimal (or very close to optimal) machine code for the task.
Close to optimal, maybe. Optimal, no. That problem is unsolvable in general.
I'm not sure what you mean by "first place". Algol 68 had definitely reached that level of reliability while Ada was still being designed. And the initial Ada design had a lot of problems making data structures involving pointers reliable. I'm not familiar with what happened to the language after the 80's, though.
Modula 3, Eiffel, and Algol 68 are garbage-collected and statically strongly typed. They are the only languages in which I've written programs of over a thousand lines and had them run correctly the first time I managed to get them through the compiler without error messages. Thes programs involved complicated data structures with dynamic storage allocation.
I suspect Eiffel would pass this test, too, but I haven't yet had the experience of writing anything that large in Eiffel.
I have never used Ada. I was involved in some of the WG2.4 consultations on its design.
Testing backups is nontrivial art, too. I once created a magnetic-tape backup of critical files, then later in the day went to the trouble of reading the tape. It read just fine.
A month later, when I needed it, I tried reading it. It turns out all the blocks had been truncated, apparently because I had forgotten to specify some obscure parameter when writing the tape. Why had it read back correctly the same day? Because the OS had obligingly cached the entire tape contents on disk in case I wanted to mount it again later.
I'm using monotone. What I like about it is its utter paranoia about data loss. Even data loss because of lost bits on a hard disk. You just can't symc a broken repository with a working one; bit failures will not spread.
That said, it's designed for use in development against a test suite -- there's a procedure whereby automated tests can be used to "certify" particular revisions, so that an actual user of the software under development can just automatically download the last certified revision and use that.
monotone -- a distributed revision control system -- everyone has a copy of the entire repository. The style of use is to commit frequently, even before any kind of code review, sync frequently, and decide which of the things committed and synced are in the final system later, after discussion, by certifying the revisions you decide to use.
This is a joke. It is funny to us experienced programmers, but it is misleading to the original questioner, who may not have the experience to realize that he's being advised to do wrongs.
Back in the days before carbon nanotubes, I seem to remember hearing that if they made it of diamond, which apparently had a high tensile strength for those taye, the cable would bave to be about two kilometres thick at its bulge.
Have a look at "How to design programs".
It's based on the language Scheme, which makes it easy to deal with topics that would be "advanced" in other languages, but easy in others. Scheme is a fairly good first language -- simple concepts, great generality of principles, and not a lot of obstructive details dictated by the limitations of historical machines. And it has a lot of implementations, most of them free. In my place, we use PLT scheme.
There was a system called Mathspad a while ago. It's a mix between a word processor and a tree editor. With the tree structure it was possible to specify how it was to be written in an output file -- so although Mathspad had its internal data structure, it could export to Latex, or whatever else you specified.
Wasn't all that done on the CM* system (16 processors) in the 70's. That system even had a programming language designed so that almost any expression could easily be dispatched to a separate processor.
Photons do have mass, since they have energy. But they have zero rest mass. If you stop a photon, it has no remaining mass. When you accelerate something to the speed of light, its mass increases infinitely. So unless the photon starts with no mass at all, you'd never get to the speed of light.
Slashdot Mirror
I once heard that it was based on an older convention about numbers of slashes. Using multiple slashes eats your way to be root until you meet something else with more slashes (or was it at least as many? I forget) So if you're in a context like ///foo//bar/f
and you append a //onion/cow/patty
the resulting ///foo//bar/f//onion/cow/patty
reduces to ///foo/onion/cow/patty
(or was it ///foo//bar//onion/cow/patty ? I forget)
So the number of slashes was a way of indicating what level of the naming hierarchy you were replacing.
But the more general concept was forgotten somewhere along the line.
How about a platform-independent programming language complete with systems programming features, garbage collection, object-inheritance, type-safety and a way to bypass it when necessary? Have a look at Modula 3 and its libraries: http://en.wikipedia.org/wiki/Modula-3
Did everyone miss that the article says that the countries where the children spend *less* hours in school do *better* in scinece and math?
Close to optimal, maybe. Optimal, no. That problem is unsolvable in general.
One of the currently available Eiffels is a variant called smarteiffel. It's free software.
Modula 3, Eiffel, and Algol 68 are garbage-collected and statically strongly typed. They are the only languages in which I've written programs of over a thousand lines and had them run correctly the first time I managed to get them through the compiler without error messages. Thes programs involved complicated data structures with dynamic storage allocation.
I suspect Eiffel would pass this test, too, but I haven't yet had the experience of writing anything that large in Eiffel.
I have never used Ada. I was involved in some of the WG2.4 consultations on its design.
In terms of not shooting oneself in the foot, Algol 68 and Modula 3 have much to recommend them.
Except that with Linux the utilities provided by someone other than the OS vendor are included with the OS.
Thanks for the Clarke reference.
Testing backups is nontrivial art, too. I once created a magnetic-tape backup of critical files, then later in the day went to the trouble of reading the tape. It read just fine. A month later, when I needed it, I tried reading it. It turns out all the blocks had been truncated, apparently because I had forgotten to specify some obscure parameter when writing the tape. Why had it read back correctly the same day? Because the OS had obligingly cached the entire tape contents on disk in case I wanted to mount it again later.
I'm using monotone. What I like about it is its utter paranoia about data loss. Even data loss because of lost bits on a hard disk. You just can't symc a broken repository with a working one; bit failures will not spread. That said, it's designed for use in development against a test suite -- there's a procedure whereby automated tests can be used to "certify" particular revisions, so that an actual user of the software under development can just automatically download the last certified revision and use that.
What are the specs for comic-writing software? It might even be fun to write same for Linux.
monotone -- a distributed revision control system -- everyone has a copy of the entire repository. The style of use is to commit frequently, even before any kind of code review, sync frequently, and decide which of the things committed and synced are in the final system later, after discussion, by certifying the revisions you decide to use.
This is a joke. It is funny to us experienced programmers, but it is misleading to the original questioner, who may not have the experience to realize that he's being advised to do wrongs.
Back in the days before carbon nanotubes, I seem to remember hearing that if they made it of diamond, which apparently had a high tensile strength for those taye, the cable would bave to be about two kilometres thick at its bulge.
I meant. "easy in Scheme", not "easy in pthers"
Have a look at "How to design programs". It's based on the language Scheme, which makes it easy to deal with topics that would be "advanced" in other languages, but easy in others. Scheme is a fairly good first language -- simple concepts, great generality of principles, and not a lot of obstructive details dictated by the limitations of historical machines. And it has a lot of implementations, most of them free. In my place, we use PLT scheme.
There was a system called Mathspad a while ago. It's a mix between a word processor and a tree editor. With the tree structure it was possible to specify how it was to be written in an output file -- so although Mathspad had its internal data structure, it could export to Latex, or whatever else you specified.
Screwing counterclockwise unscrews.
This one nounless.
Wasn't all that done on the CM* system (16 processors) in the 70's. That system even had a programming language designed so that almost any expression could easily be dispatched to a separate processor.
Photons do have mass, since they have energy. But they have zero rest mass. If you stop a photon, it has no remaining mass. When you accelerate something to the speed of light, its mass increases infinitely. So unless the photon starts with no mass at all, you'd never get to the speed of light.