The most important part of Forth isn't a tool -- it's a concept. And most of you HAVE used it, although you deny it; most of you use the concept which powers Forth every time you print something. The same concept that powers Forth also powers Postscript.
You're taking him badly out of context. His Colorforth is indeed inaccessible to you, but as he's repeatedly stated, color isn't the important things -- he mentions tone, font, and emphasis as alternatives here.
He's only working with color right now, because that's what he needs; why should he do extra work to solve a problem nobody has? Hire him (or have him hire you), and he'll find a way for you to use ColorForth.
To be honest, to me this invalidates everything else he said. If you have to depend on a conspiracy to figure out why your pet language is not universally adopted, then you are not living in reality.
Read again. He did NOT claim any form of conspiracy; he simply identified common interest. There IS a common interest in all those sectors in staying employed.
At the same time, there's a more powerful common interest at stake: making money. It's better to make money than to stay employed (in a corporation which refuses to change to a more efficient concept, and which will therefore soon lose business).
So it's clear to me that Chuck's analysis is simplistic. But so is yours -- at least he's correctly identified a problem.
The real problem with Forth is that it achieves its successes by being fundamentally different. The theory behind Forth is totally at odds with the theory behind all other languages, with the exception of Postscript and Joy. And until the last couple of years, nobody had done ANY work on understanding that theory, and from that understanding coming up with simple ways to explain what makes a Forth program "good" or "bad".
Thankfully, we now have some work done on that, and I believe that the clear result is that all modern Forths are screwy. They encourage writing code which is bad, and therefore hard to maintain. This isn't the fault of Forth; it's the fault of the vocabulary Forth now has. The success of C wasn't due to the language (although it was good, it was only a minor improvement over previous languages); it was the teaming of the language with the library and runtime (AKA Unix).
As for APL... We have one APL "zealot" (your word) on the concatenative languages list. He's an excellent help; he can see right through many of the trivial differences in syntax to the problem actually being solved. There's no doubt that APL is a great language, and provides a marvelous "transform", converting a problem from one domain (its native domain) to another domain (the array programming domain) in which it can sometimes more easily be solved. It's like a laplace transform -- a wonderful tool for problem solving. One doesn't maintain a laplacian transform when the problem changes; one simply reworks the math.
Forth is different; in Forth you don't transform the problem into a form which fits the language; instead, you transform the language into a form that fits the solution domain.
algebraic notation is much easier for humans to comprehend than reverse polish notation
I guess you haven't taught or tutored any algebra classes? So many programmers imagine that they way they've learned to think so well is the only way to think. Both forms are hard to work with; however, the Forthlike form is easier to express action in (since it's chronologically ordered, with no execution occuring out of order) and easier to refactor (since most refactorings require only cut'n'paste, with no possibility of code breakage); the Algol or Lisp-like form is easier to do certain other transformations (since the arguments of a function are 'tied' or applied to the function by hard syntax).
The theory of Forthlike languages is brand new, in spite of Forth's age and Postscript's overwhelming success; it's discussed at the Joy page.
will Forth's general weirdness make it harder to find an apply good algorithms?
Forth's wierdness is explicitly tailored to help the programmer find and apply good algorithms. Let me list some ways:
interactive, to encourage experimentation
fast compile/run cycle, to encourage testing
programmer can write code to execute at any time: while editing, while compiling, while defining a word, while parsing, while generating code, and (of course) at runtime. This allows unit tests to be run as part of the compilation process.
syntax is infinitely mutable: if your problem requires BASIC or FORTRAN notation, just write (or load in) a parser and use it. To write an application in Forth, you first write a language in which the problem appears natural; then you naturally solve the problem.
refactoring is trivial, natural, and mostly free of the possibility of error.
Am I biased?
You have an awesome list of languages, but all of them operate on the same basic system: functions syntactically take parameters. Forth, together with Postscript and Joy, is/completely/ different; its functions aren't syntactically tied to its parameters. This causes it to behave completely differently from the "applicative" languages you list. The author of the Joy page I linked to earlier calls the set of Forth-like languages "concatenative", since any concatenation of valid programs is also a valid program, AND any dissection of a valid program along token boundaries is also a valid program.
Read the Joy page -- I found it mind-stretching. It's good for a programmer to know some truly _different_ languages, which encourage truly different thinking.
The compiler cannot come close to the human for the whole program, but it far defeats the human for local optimizations.
The compiler should understand machine limitations, data and code cache sizes, and all the other things that vary from machine to machine and which can be optimised locally; the programmer should understand what data is going to be needed when, and he should be able to tell that to the compiler. THAT is the big advantage of dataflow languages like Forth, APL, and so on (although I'm only aware of optimizing compilers for Forth, not for the other dataflow languages).
How about a PDA which gets input by reading your lips -- and perhaps even allows you to do text searches on everything that's been said to you by a specific person? A map utility which can map an optimal route from one point to another, taking into account traffic and time of day? A general scientific system which solves large systems quickly by massively parallel simulated annealing? A computer which could actually solve the trade difficulties of the Poictsome system, and perhaps predict in advance the fall of the Federation and its replacement by Empire?
A computer which, when asked whether there is a God, would simply answer, "present.";-)
You reversed the two -- stack based architectures are simpler to optimise and allocate for than register based ones.
In a register-based architecture, you don't know which register is going to be used next, and which ones are seldom used; in a stack, you know that stuff near the top is coming sooner than stuff near the bottom. Because all of the data is ordered in terms of urgency, a caching system can make very intelligent decisions.
This is even more powerful when the programmer (not the compiler) is the one who arranged the data in order on the stack -- the programmer has an optimiser in his head which by FAR defeats all currently possible software optimisers.
Your philosophy of coding emphasises (or seems to me to emphasise) many of the same things recently elaborated by the new "fad", Extreme Programming. What's your opinion on this rediscovery? How strong is the correspondance?
How, if at all, does Forth help you to do things like refactoring and unit testing in ways that other languages don't?
Just FYI, Forth doesn't use true postfix -- it uses a sophisticated superset of postfix. Far from being dated, its technical capabilities are only beginning to be explored. For more info, read the Joy language page.
As someone else mentioned, the glove has a re-center button. Personally, I think this sort of thing is just what gesture recognition was made for; and I know just what gesture I intend to assign to "re-center because I ran out of movement space".
I do a lot of sharing, and have for a long time in several languages. I've never spent much time correcting tabs, but I don't get these problems. In particular, I've never seen anything as bad as what you're saying -- the worst I get is seeing 8-space tabs when the file was formatted for 4-space.
The standard solution in Python is to NEVER use tabs. It's also possible to get away with never using spaces in front of tabs; if you make a mistake that way, you'll see it immediately, and Python will produce an error.
If you DO wind up with spaces in front of your tabs, get rid of your editor -- it's not worth the hassle. Then run Python with the tabnanny option (I think that's -t or -tt) to show you where the mistakes are.
But again, I've never had any of this happen to me. I've never talked to any Python users who have. Python coders just don't ALLOW their code to get so sloppy, any more than C users would allow their code to contain misspelled function names. Why? Because the resulting code wouldn't compile.
Whitespace _by itself_ doesn't affect Python; only indentation does. The difference is that indentation is something that's done to visible stuff. It's almost impossible to hide an indentation.
It's not completely impossible, though; that's why Python's unofficial rule is: "no tabs, and if you want to use tabs, never put spaces before a tab." This is good human advice anyhow.
So in summary, there's nothing about Python's formatting which is invisible.
Hope that helps.
The post to which you're replying is claiming that tools should conform to the language rather than the language to the tools -- I'm a Python fan, but even I don't buy that. Python IS a tool, as is any language. If you're stuck with vi and Python makes it hard to indent using vi, then either Python, vi, or automatic indentation MUST GO. Personally, I've never had a problem, but to those who have, I completely respect their decision to toss out any of the three, even my favorite one.
Of course, that doesn't mean I have to agree when they start badmouthing Python because they chose to toss it out in their one narrow case.
Hardly surprisingly, your claims about me are almost universally false -- your habit of assuming (and stating as fact) naughty things about people who disagree with you simply MUST be curbed if you expect to participate in further public debate.
Until then -- bye. And don't expect me to do research at your beck and call. Yes, I have numbers (regarding post-abortion emotional trauma); no, I'm not going to look them up simply to further an argument with an idiot such as yourself.
I definitely admire XP, and have practiced a few permutations of it. Unlike many here, I think the whole thing is good and useful when practiced together. Yes, including PairProgramming and SimplestPossible:-).
However, the Slashdot header implied that XP is good for larger projects. In fact, it's never been tried for large projects, and its creators claim that it's possibly not a good idea to attempt it.
Of course, I'm sure the author was thinking of "larger than one person" projects, but he didn't explicitly say so. So I thought I'd throw out the warning.
I agree. Even if my posting were entirely correct (and I assert that it almost certainly is), it FAR from excuses the fundies who HAVE killed abortion doctors. In fact, it EMPHASISES their guilt. They're blatant hypocrites, and my message DEFINITELY was in error in not calling them on that.
Now, put your rudeness back in:
I disagree. I'm not spewing shit, I'm telling it like it is. The simple fact that you hate christians and disagree with them doesn't make them ALL murderers, and it doesn't remove any guilt from anyone else.
Back On Topic: I believe that this judgement was a mistake. "Free Speech" is intended to be political speech, not violence or personal slams; this ruling does NOTHING to protect free speech. I believe the list was properly shut down, since it was NOT a political expression, but rather was a reckless endangerment and a violation of privacy.
and I totall disagree with you - the only reason the pro-lifers are willing to go so far as to kill someone they disagree with is BECAUSE they are fundamentalist christians.
That's preposterous. Millions of people have killed for less reasons when they weren't fundies; I'd be willing to bet that most of the people who killed abortion doctors didn't do so because they opposed abortion, but rather because they were angry at the doctor for some other reason.
I wouldn't be surprised if some of them were pro-aborts who were angry at the doctor for performing an abortion on their wife or daughter without their "permission" or something -- or who were shocked at the grief trauma their wife was going through after they (the husband) forced her to get an abortion.
Forced abortions are all too common. Too many people still see abortion as less stigmatising than pregnancy.
Chuck Moore (the guy who invented Forth way back when) has built several minimalistic chips which have a lot of asynchrony. The way they do it is very different form dataflow -- instead of having functional units notify each other when they're ready, the hardware is generally designed to/assume/ readiness, and in fact to/be/ ready.
For example, in traditional processor design the first stage of execution is decoding, and the second is register lookup; in Chuck's chip there is no register lookup, because he uses a stack. Because of this, instruction decoding proceeds in parallel with all the ALU computations and result accesses, and when the instruction is decoded the result is simply to gate a result into the TopOfStack register (and sometimes to pop the stack, if the instruction was supposed to consume two values).
The only exception in the current design is the ADD instruction, which he's implemented as a ripple-carry; that can sometimes take more than one cycle to compute, so if there's a possibility of a large carry the programmer is responsible to insert up to 3 NOPs.
The URL is http://www.ultratechnology.com.
In my microprocessor design class a few years back, I built my processor around these concepts. It was an unqualified success; it was easy to build, easy to program, much less resource-constrained than any of the other designs in the class, and ran all the required programs much faster than anything else. Almost everyone else was following the party line and building a RISC-style two-operand machine; since we only had eight bits per instruction, this was suicidal. The few who weren't completely toeing the line were building accumulator machines, which worked well but didn't have the sheer flexibility.
First of all....if there is a god, it would be sexless, so in all theory, you know nothing of what would constitute a supreme being...
It makes sense that a God would be sexless, since there's only one (no reproduction). It doesn't follow that such a God would be genderless.
and as far as "scientific" perhaps, you would have to think outside the box to put "science" and "god" in the same sentence.
True. Same with "Science" and "Person" in the same sentence, and for the same reason. Ditto "history" and "science".
why would a supreme being be the pinnacle of creation? Of Life?...is it not a common theme in stories that the created eventually become as powerful or evolve to the same level as their creator?
A supreme being could by definition NOT be the pinnacle of creation -- if it were the pinnacle of creation, then something must have created it, and it therefore could not be supreme. A supreme being is outside of creation.
A God, in addition, to being outside of creation, is uncreated and infinite. Finite cannot possibly grow to become infinite.
Furthermore, a supreme being would have no reason to create different living things at once...no, instead they would create the environment that would be conducive to the creation of living things...
Quaint speculation, but hardly interesting.
which brings us, are humans going to eventually "play god"? in a way we already do, but we will, and rightfully so, be able to create life from nothing...because being able to do so is in a way the created having the same powers as the creator...the pinnacle of evolution..
To create life from nothing you have to first create a universe. At that point you would be a supreme being -- even a god. But not a God, unless you find a way to become infinite with respect to that universe. If so, you do become God for that universe. But not for the one you started in... That would require revolution, not evolution.
-Billy (random philosophy)
Re:Another case of too little, too late?
on
ESR On XML-RPC
·
· Score: 2
Well, as I recall, XML-RPC was the origin of SOAP. So hopefully SOAP will replace it, but that just means that XML-RPC did its job well.
Actually, I hope that XML-RPC will wind up being a proper subset of SOAP. That would be convenient.
Nice. However, first things first: any replacement for the current system has to start by doing all the things the current system does, at least as simply. This is the main reason I think 'cd' is a good command to include.
It's BAD to try for too much with the first release. If you'd like an 'object system', by all means prototype one using conventional directories; you'll decide quickly that it's little different from modern Unix (remember ioctl!). In other words, an overly complex solution.
We need a true file system, one in which ioctl isn't needed. See the latest plan9 OS for details.
You're absolutely right that a prototype could be built using current file systems, but said prototype would be SLOW and eat a LOT of space. It's better to use appropriate data structures and algorithms.
And yes, file systems are databases; they're merely inflexible databases using ANCIENT technology. Not all databases are created equal.
I'm not sure what you mean when you say 'staticly' or 'dynamicly'. I suspect, however, that you're assuming that the foundation of a fluid file system is a set of files, directories, and links. It's not. It's almost certainly a relational database, one optimised for the task of getting a set of items (objects, files, whatever) which are categorised under a given set of categories.
I also don't know what you mean by 'number of possible categories'. I think you're mistaking 'categories' for 'sets of categories'. In my example, "/etc/wtanksle" is a set of two categories; "etc" is a category. I could see some reason to cache the results of category queries; that's an optimization concern, and not my specialty. I don't see any reason to try to precache all possible queries, as you seem to imply.
Its speed will be almost irrelevant; I predict that it'll be about as fast as the current system, but even if it's hundreds of times slower it'll still be fast enough, since caching is trivial and looking up a file based on a full filespec is almost never done.
This is exciting on a number of levels, even if the specific database being used isn't my choice; I've been looking for a suitable base for some of my ideas regarding a "fluid file system" (someone else generated a good writeup, calling their ideas a liquid file system, but my name is better:-).
In my vision, 'documents' would be categorised, and the categories could be viewed in a manner very similar to how we now view directories, except that a file is in more than one folder at a time. A file which is named/etc/wtanksle/ppp.conf could also be referred to as/wtanksle/etc/ppp.conf, or if it's unambiguous,/etc/ppp.conf./dev/removable gives the list of all removable devices;/dev/scsi gives the SCSI devices (including the removable ones).
The potential uses are many -- I think it would make a lot of common computer tasks a lot easier.
I'm not sure what you mean by "new low level functions", but I'm certain Forth can compile them:-). Forth has the ability to compile compiler and normal words (IMMEDIATE versus non-IMMEDIATE), and words can be written in Forth or CODE (assembler).
Most of the OSes written in Forth are called "Forth", and behave very much like this. I like the looks of this one, of course.
Slashdot Mirror
The most important part of Forth isn't a tool -- it's a concept. And most of you HAVE used it, although you deny it; most of you use the concept which powers Forth every time you print something. The same concept that powers Forth also powers Postscript.
-Billy
You're taking him badly out of context. His Colorforth is indeed inaccessible to you, but as he's repeatedly stated, color isn't the important things -- he mentions tone, font, and emphasis as alternatives here.
He's only working with color right now, because that's what he needs; why should he do extra work to solve a problem nobody has? Hire him (or have him hire you), and he'll find a way for you to use ColorForth.
-Billy
To be honest, to me this invalidates everything else he said. If you have to depend on a conspiracy to figure out why your pet language is not universally adopted, then you are not living in reality.
Read again. He did NOT claim any form of conspiracy; he simply identified common interest. There IS a common interest in all those sectors in staying employed.
At the same time, there's a more powerful common interest at stake: making money. It's better to make money than to stay employed (in a corporation which refuses to change to a more efficient concept, and which will therefore soon lose business).
So it's clear to me that Chuck's analysis is simplistic. But so is yours -- at least he's correctly identified a problem.
The real problem with Forth is that it achieves its successes by being fundamentally different. The theory behind Forth is totally at odds with the theory behind all other languages, with the exception of Postscript and Joy. And until the last couple of years, nobody had done ANY work on understanding that theory, and from that understanding coming up with simple ways to explain what makes a Forth program "good" or "bad".
Thankfully, we now have some work done on that, and I believe that the clear result is that all modern Forths are screwy. They encourage writing code which is bad, and therefore hard to maintain. This isn't the fault of Forth; it's the fault of the vocabulary Forth now has. The success of C wasn't due to the language (although it was good, it was only a minor improvement over previous languages); it was the teaming of the language with the library and runtime (AKA Unix).
Work is ongoing... See the concatenative languages group for more discussion and a very informative link.
As for APL... We have one APL "zealot" (your word) on the concatenative languages list. He's an excellent help; he can see right through many of the trivial differences in syntax to the problem actually being solved. There's no doubt that APL is a great language, and provides a marvelous "transform", converting a problem from one domain (its native domain) to another domain (the array programming domain) in which it can sometimes more easily be solved. It's like a laplace transform -- a wonderful tool for problem solving. One doesn't maintain a laplacian transform when the problem changes; one simply reworks the math.
Forth is different; in Forth you don't transform the problem into a form which fits the language; instead, you transform the language into a form that fits the solution domain.
-Billy
I guess you haven't taught or tutored any algebra classes? So many programmers imagine that they way they've learned to think so well is the only way to think. Both forms are hard to work with; however, the Forthlike form is easier to express action in (since it's chronologically ordered, with no execution occuring out of order) and easier to refactor (since most refactorings require only cut'n'paste, with no possibility of code breakage); the Algol or Lisp-like form is easier to do certain other transformations (since the arguments of a function are 'tied' or applied to the function by hard syntax).
The theory of Forthlike languages is brand new, in spite of Forth's age and Postscript's overwhelming success; it's discussed at the Joy page.
will Forth's general weirdness make it harder to find an apply good algorithms?
Forth's wierdness is explicitly tailored to help the programmer find and apply good algorithms. Let me list some ways:
Am I biased?
You have an awesome list of languages, but all of them operate on the same basic system: functions syntactically take parameters. Forth, together with Postscript and Joy, is
Read the Joy page -- I found it mind-stretching. It's good for a programmer to know some truly _different_ languages, which encourage truly different thinking.
-Billy
The compiler cannot come close to the human for the whole program, but it far defeats the human for local optimizations.
The compiler should understand machine limitations, data and code cache sizes, and all the other things that vary from machine to machine and which can be optimised locally; the programmer should understand what data is going to be needed when, and he should be able to tell that to the compiler. THAT is the big advantage of dataflow languages like Forth, APL, and so on (although I'm only aware of optimizing compilers for Forth, not for the other dataflow languages).
-Billy
How about a PDA which gets input by reading your lips -- and perhaps even allows you to do text searches on everything that's been said to you by a specific person? A map utility which can map an optimal route from one point to another, taking into account traffic and time of day? A general scientific system which solves large systems quickly by massively parallel simulated annealing? A computer which could actually solve the trade difficulties of the Poictsome system, and perhaps predict in advance the fall of the Federation and its replacement by Empire?
;-)
A computer which, when asked whether there is a God, would simply answer, "present."
The possibilities are boundless. Seriously.
-Billy
You reversed the two -- stack based architectures are simpler to optimise and allocate for than register based ones.
In a register-based architecture, you don't know which register is going to be used next, and which ones are seldom used; in a stack, you know that stuff near the top is coming sooner than stuff near the bottom. Because all of the data is ordered in terms of urgency, a caching system can make very intelligent decisions.
This is even more powerful when the programmer (not the compiler) is the one who arranged the data in order on the stack -- the programmer has an optimiser in his head which by FAR defeats all currently possible software optimisers.
-Billy
Your philosophy of coding emphasises (or seems to me to emphasise) many of the same things recently elaborated by the new "fad", Extreme Programming. What's your opinion on this rediscovery? How strong is the correspondance?
How, if at all, does Forth help you to do things like refactoring and unit testing in ways that other languages don't?
-Billy
Just FYI, Forth doesn't use true postfix -- it uses a sophisticated superset of postfix. Far from being dated, its technical capabilities are only beginning to be explored. For more info, read the Joy language page.
-Billy
As someone else mentioned, the glove has a re-center button. Personally, I think this sort of thing is just what gesture recognition was made for; and I know just what gesture I intend to assign to "re-center because I ran out of movement space".
See figure one.
-Billy
Keep in mind that Python's indentation/blocking rules are _totally_ different from MUMPS'. They don't have the same problems or benefits.
-Billy
I do a lot of sharing, and have for a long time in several languages. I've never spent much time correcting tabs, but I don't get these problems. In particular, I've never seen anything as bad as what you're saying -- the worst I get is seeing 8-space tabs when the file was formatted for 4-space.
The standard solution in Python is to NEVER use tabs. It's also possible to get away with never using spaces in front of tabs; if you make a mistake that way, you'll see it immediately, and Python will produce an error.
If you DO wind up with spaces in front of your tabs, get rid of your editor -- it's not worth the hassle. Then run Python with the tabnanny option (I think that's -t or -tt) to show you where the mistakes are.
But again, I've never had any of this happen to me. I've never talked to any Python users who have. Python coders just don't ALLOW their code to get so sloppy, any more than C users would allow their code to contain misspelled function names. Why? Because the resulting code wouldn't compile.
-Billy
Good concerns.
Whitespace _by itself_ doesn't affect Python; only indentation does. The difference is that indentation is something that's done to visible stuff. It's almost impossible to hide an indentation.
It's not completely impossible, though; that's why Python's unofficial rule is: "no tabs, and if you want to use tabs, never put spaces before a tab." This is good human advice anyhow.
So in summary, there's nothing about Python's formatting which is invisible.
Hope that helps.
The post to which you're replying is claiming that tools should conform to the language rather than the language to the tools -- I'm a Python fan, but even I don't buy that. Python IS a tool, as is any language. If you're stuck with vi and Python makes it hard to indent using vi, then either Python, vi, or automatic indentation MUST GO. Personally, I've never had a problem, but to those who have, I completely respect their decision to toss out any of the three, even my favorite one.
Of course, that doesn't mean I have to agree when they start badmouthing Python because they chose to toss it out in their one narrow case.
-Billy
Hardly surprisingly, your claims about me are almost universally false -- your habit of assuming (and stating as fact) naughty things about people who disagree with you simply MUST be curbed if you expect to participate in further public debate.
Until then -- bye. And don't expect me to do research at your beck and call. Yes, I have numbers (regarding post-abortion emotional trauma); no, I'm not going to look them up simply to further an argument with an idiot such as yourself.
-Billy
I definitely admire XP, and have practiced a few permutations of it. Unlike many here, I think the whole thing is good and useful when practiced together. Yes, including PairProgramming and SimplestPossible :-).
However, the Slashdot header implied that XP is good for larger projects. In fact, it's never been tried for large projects, and its creators claim that it's possibly not a good idea to attempt it.
Of course, I'm sure the author was thinking of "larger than one person" projects, but he didn't explicitly say so. So I thought I'd throw out the warning.
-Billy
All your rudeness aside:
I agree. Even if my posting were entirely correct (and I assert that it almost certainly is), it FAR from excuses the fundies who HAVE killed abortion doctors. In fact, it EMPHASISES their guilt. They're blatant hypocrites, and my message DEFINITELY was in error in not calling them on that.
Now, put your rudeness back in:
I disagree. I'm not spewing shit, I'm telling it like it is. The simple fact that you hate christians and disagree with them doesn't make them ALL murderers, and it doesn't remove any guilt from anyone else.
Back On Topic: I believe that this judgement was a mistake. "Free Speech" is intended to be political speech, not violence or personal slams; this ruling does NOTHING to protect free speech. I believe the list was properly shut down, since it was NOT a political expression, but rather was a reckless endangerment and a violation of privacy.
-Billy
That's preposterous. Millions of people have killed for less reasons when they weren't fundies; I'd be willing to bet that most of the people who killed abortion doctors didn't do so because they opposed abortion, but rather because they were angry at the doctor for some other reason.
I wouldn't be surprised if some of them were pro-aborts who were angry at the doctor for performing an abortion on their wife or daughter without their "permission" or something -- or who were shocked at the grief trauma their wife was going through after they (the husband) forced her to get an abortion.
Forced abortions are all too common. Too many people still see abortion as less stigmatising than pregnancy.
-Billy
Chuck Moore (the guy who invented Forth way back when) has built several minimalistic chips which have a lot of asynchrony. The way they do it is very different form dataflow -- instead of having functional units notify each other when they're ready, the hardware is generally designed to /assume/ readiness, and in fact to /be/ ready.
For example, in traditional processor design the first stage of execution is decoding, and the second is register lookup; in Chuck's chip there is no register lookup, because he uses a stack. Because of this, instruction decoding proceeds in parallel with all the ALU computations and result accesses, and when the instruction is decoded the result is simply to gate a result into the TopOfStack register (and sometimes to pop the stack, if the instruction was supposed to consume two values).
The only exception in the current design is the ADD instruction, which he's implemented as a ripple-carry; that can sometimes take more than one cycle to compute, so if there's a possibility of a large carry the programmer is responsible to insert up to 3 NOPs.
The URL is http://www.ultratechnology.com.
In my microprocessor design class a few years back, I built my processor around these concepts. It was an unqualified success; it was easy to build, easy to program, much less resource-constrained than any of the other designs in the class, and ran all the required programs much faster than anything else. Almost everyone else was following the party line and building a RISC-style two-operand machine; since we only had eight bits per instruction, this was suicidal. The few who weren't completely toeing the line were building accumulator machines, which worked well but didn't have the sheer flexibility.
-Billy
First of all....if there is a god, it would be sexless, so in all theory, you know nothing of what would constitute a supreme being...
It makes sense that a God would be sexless, since there's only one (no reproduction). It doesn't follow that such a God would be genderless.
and as far as "scientific" perhaps, you would have to think outside the box to put "science" and "god" in the same sentence.
True. Same with "Science" and "Person" in the same sentence, and for the same reason. Ditto "history" and "science".
why would a supreme being be the pinnacle of creation? Of Life?...is it not a common theme in stories that the created eventually become as powerful or evolve to the same level as their creator?
A supreme being could by definition NOT be the pinnacle of creation -- if it were the pinnacle of creation, then something must have created it, and it therefore could not be supreme. A supreme being is outside of creation.
A God, in addition, to being outside of creation, is uncreated and infinite. Finite cannot possibly grow to become infinite.
Furthermore, a supreme being would have no reason to create different living things at once...no, instead they would create the environment that would be conducive to the creation of living things...
Quaint speculation, but hardly interesting.
which brings us, are humans going to eventually "play god"? in a way we already do, but we will, and rightfully so, be able to create life from nothing...because being able to do so is in a way the created having the same powers as the creator...the pinnacle of evolution..
To create life from nothing you have to first create a universe. At that point you would be a supreme being -- even a god. But not a God, unless you find a way to become infinite with respect to that universe. If so, you do become God for that universe. But not for the one you started in... That would require revolution, not evolution.
-Billy (random philosophy)
Well, as I recall, XML-RPC was the origin of SOAP. So hopefully SOAP will replace it, but that just means that XML-RPC did its job well.
Actually, I hope that XML-RPC will wind up being a proper subset of SOAP. That would be convenient.
-Billy
Nice. However, first things first: any replacement for the current system has to start by doing all the things the current system does, at least as simply. This is the main reason I think 'cd' is a good command to include.
It's BAD to try for too much with the first release. If you'd like an 'object system', by all means prototype one using conventional directories; you'll decide quickly that it's little different from modern Unix (remember ioctl!). In other words, an overly complex solution.
We need a true file system, one in which ioctl isn't needed. See the latest plan9 OS for details.
-Billy
You're absolutely right that a prototype could be built using current file systems, but said prototype would be SLOW and eat a LOT of space. It's better to use appropriate data structures and algorithms.
And yes, file systems are databases; they're merely inflexible databases using ANCIENT technology. Not all databases are created equal.
-Billy
I'm not sure what you mean when you say 'staticly' or 'dynamicly'. I suspect, however, that you're assuming that the foundation of a fluid file system is a set of files, directories, and links. It's not. It's almost certainly a relational database, one optimised for the task of getting a set of items (objects, files, whatever) which are categorised under a given set of categories.
I also don't know what you mean by 'number of possible categories'. I think you're mistaking 'categories' for 'sets of categories'. In my example, "/etc/wtanksle" is a set of two categories; "etc" is a category. I could see some reason to cache the results of category queries; that's an optimization concern, and not my specialty. I don't see any reason to try to precache all possible queries, as you seem to imply.
Its speed will be almost irrelevant; I predict that it'll be about as fast as the current system, but even if it's hundreds of times slower it'll still be fast enough, since caching is trivial and looking up a file based on a full filespec is almost never done.
-Billy
In my vision, 'documents' would be categorised, and the categories could be viewed in a manner very similar to how we now view directories, except that a file is in more than one folder at a time. A file which is named /etc/wtanksle/ppp.conf could also be referred to as /wtanksle/etc/ppp.conf, or if it's unambiguous, /etc/ppp.conf. /dev/removable gives the list of all removable devices; /dev/scsi gives the SCSI devices (including the removable ones).
The potential uses are many -- I think it would make a lot of common computer tasks a lot easier.
Oh well -- anyhow. :-)
-Billy
I'm not sure what you mean by "new low level functions", but I'm certain Forth can compile them :-). Forth has the ability to compile compiler and normal words (IMMEDIATE versus non-IMMEDIATE), and words can be written in Forth or CODE (assembler).
Most of the OSes written in Forth are called "Forth", and behave very much like this. I like the looks of this one, of course.
-Billy