Some here are warning you that major changes always require a total rewrite; yet in real life, total rewrites result in inability to compete (look how long the Netscape rewrite paralysed Netscape, unable to meet Microsoft's challenge!). There's some good discussion of the danger of rewriting at a former MS software engineer's site, and some limited advice about how to get away without doing it.
But you've decided to rework rather than rewrite, you say, so I have no doubt you'll ignore the naysayers here. So what CAN you do? After all, as you recognise, reworking is dangerous!
The following rules have worked for me; I've refined my own experience with advice from Fowler's Refactoring, a book as useful as Design Patterns, and with study of Extreme Programming, a design methodology forged in the traditions of Smalltalk, and in the knowledge that maintainance, the most important and expensive part of software engineering, is also the least studied.
First, do the simplest thing that could possibly work. Don't EVER take your program out of commission for more than a day; make sure it runs at the end of each day. If you're doing something and at the end of the day your code base is broken, STRONGLY consider throwing away your changes and going back to the design stages.
Second, rely on unit tests extensively. Start every change by writing as extensive of a unit test as possible. Unit test every function you touch, BEFORE you touch it, and after. Unit test every change you make, and run the unit test BEFORE you make the change to ensure that it fails (i.e. it detects the change). Write your unit tests BEFORE you write code, whenever possible; you'll objectively know your code is done when your unit tests pass.
Third, don't design too far ahead; you don't know what tricks the old code is going to throw at you. Implement one feature at a time, bringing the code into compliance. Once everything has a unit test (thanks to your following the above principles), THEN you can safely embark on larger design changes -- and in the meantime, you have working code with new features, a win even if your customer/boss/manager decides not to continue.
Fourth, don't be afraid to redesign your own code. The stuff you wrote has more tests, so it's safer to change, but it's more likely than the old code to lack some critical understanding only age can give.
Fifth, use the principles of refactoring. Whenever possible split each code change into two parts: first, a part which changes the structure of the code without changing its function (and which therefore allows you to run the same unit tests); and second, a part which uses the new structure to perform a new function (thereby requiring new unit tests).
I'm puzzled by your answer, since it seems you do follow my logic quite well -- you state very clearly that "it's unlikely that we'd be able to find efficient algorithms... even if P=NP were known."
So go back to my post and read it that way:
1. I know an efficient algorithm, thereby proving P=NP.
2. I know a proof but no algorithm.
3. I know both a proof and an algorithm, and the algorithm can't plausibly be derived from the proof (I probably used the algorithm to derive the proof).
It's interesting how most of the answers here fail to look at the actual question. The question wasn't so much, "what will break;" the question was, "what should one do."
Although it's interesting and even essential to review what parts of computer science or our economy would be toppled by such a discovery, doing so doesn't answer the question.
Let me rephrase the question for any who missed it: "Suppose you discover that P=NP. What is the right thing to do?" Do I cover it up, or do I release? What if I proved that P=NP, but I don't know of an algorithm to actually convert any known problem? Or, what if I did know the algorithm and the proof, and I believed that the algorithm couldn't be reconstructed from the proof -- should I release the proof?
This is a powerful question!
My feeling is that the truth should be known, but experience shows that information without knowledge, and knowledge without understanding, can be deadly. (I'm afraid you can't affect whether people will get understanding without wisdom, so we'll stop the natural progression before we reach that point.) A little survey of the literature (please see the other posts here; they've got GREAT info) shows that the practical benefits of this discovery would be IMMENSE. The drawbacks seem huge, too; but if a particular algorithm has become easier to destroy, so also do new algorithms open up. Look around -- identify as many existing things which are harmed by your discovery, and try to provide a discussion of how to recover from the harm.
Even if you're not altruistic you want to do this; the person who is most essential in the new world isn't the person who discovered the info, since once the secret's out it's not under his control; it's the person on whom people are depending. Be that person -- but don't be selfish about it. Too selfish ruins the game too; there's always someone with enough power to take your position away from you.
So that's my knee-jerk answer, with a bit of reasoning: research the discovery, find who it hurts, and prepare to help them. Then make it public.
There's another question which is implied by the first one: to whom do I release info about my discovery? I can't answer that. Does anyone have an answer? I can say that you'll HAVE to release some information before you're ready to release it all; for example, you might want to found a corporation, and you'll almost certainly need library assistance. What can I say about that? Pick people you can trust, and don't trust them with too much.
Just because the price of some OSS is $0.00 doesn't mean someone isn't selling it. The makers are hobbyists, but write products to be used beyond the hobbyist segment.
Hmm. My impression was that the makers were (perhaps) hobbyists, and wrote the product, like all hobbies, for the sake of writing it. Getting use "beyond the hobbyist segment" would be a marvelous bonus, but not the goal of any hobbyist.
Other open source projects are NOT written for the sake of writing them; they aren't hobbies. They're written for the sake of usefulness to the author, and released because releasing doesn't hurt and can sometimes help (by getting other people to improve the product).
I wasn't describing instructions, by the way, although I did mention a recipie; I was intending the analogy to be to paint, not the recipie for the paint. If I paint my house, you like the results, and I give you the paint I used, am I responsible for whether you choose to paint your house with that paint? Okay, if the paint damages your house and I didn't warn or disclaim, yes. But otherwise, NO.
This little disclaimer looks like a great example of a hobbyist telling the truth: we're doing this because it's fun, not because it's useful. Don't expect any more from it, unless you can help contribute the "more". Now, after reading this I would still conclude that there are/some/ people working on AbiWord because they need it; those are the people I would trust to/want/ it to work.
In this letter, regardless of what's been said in the past, the group is asking people to readjust their expectations. They're not demanding that people take them "seriously as an alternative to Microsoft;" on the contrary, they're asking that people think less of them.
And about advancing the Linux cause, isn't truth and honesty a little more effective in the long run than false expectations? And if it isn't, who cares about the Linux Cause?
That's an incredibly silly analogy; painting someone else's house doesn't line up with open source in any way I can see.
Perhaps one could make the analogy that open source is making your own paint to paint your own house, and then giving away the paint (or the recipie). If someone complains about the color of their house, you tell them to complain to whoever selected the paint and color, not you.
OTOH, if you DID paint their house for them, then you are to some degree responsible for the results -- and if you install Linux on someone's computer, you'd better be sure it'll meet their needs. But Linus isn't responsible if it doesn't; you are.
To what would this hypothetical adaptive space telescope adapt? The adaptive ground-based telescopes adapt to the atmosphere; but there's no atmosphere in space.
I just don't see how adaptive technology could improve a space telescope.
Facinating stories -- I was an OS/2 user back when Object Desktop (whoops, I forgot their real name -- Stardock?) was trying to rescue OS/2. I was really disappointed when they failed. They did a REALLY good job in all their other work, though.
Question: I see a new feature in the next version of eComStation, network boot. In this, the entire OS is stored on the disk of one machine, and the other machines boot entirely from it -- all config files, everything. All processing is done on the clients, but the files are stored on the server. That's convenient!
I know X can do part of this, but it still puts the processing on the server; NFS can do another part, but it's enormously slow and bulky (and VERY odd to work with).
So is there any complete solution I can install on a 'terminal' PC so that all booting, storage, and so on is done on a central system, but all processing and running is done on my system -- and it all just works, whether I'm using console or X, svgamode or KDE?
I'm sure that when MOSIX is done that'll be easy:-). That would be the ultimate solution, I suppose -- but on the other hand, this would make a MOSIX cluster much easier to set up, since the individual machines couldn't be independantly misconfigured.
Some of the transport solutions, such as HyperTransport, can be used between CPU and memory. This is how nVidia's new 'nForce' chipset works; it hooks up an Athlon to DDR RAM via HyperTransport links.
RDRAM (Rambus) got all of its speed by using a bus rather similar to these (although with some odd tradeoffs). These are essentially public versions of what Rambus was trying to make proprietary.
If only they made standard keyboards with that little nub for pointing.
They do. I have two; one at home, and one at the office. It's called a 'Trackpoint' keyboard; it's very expensive ($160, according to epinions, although someone's selling one for $70 on half.com). I got mine for $115 or so a long time ago.
I'm eagerly awaiting the gesture-sensitive keyboard from FingerWorks; of course, at that price I'll wait for a review, since I've used a membrane keyboard in the past; this isn't a membrane keyboard, but it does look faintly like one, and that makes me a little bit uncomfortable:-).
Yes, Unix piping is in a sense concatenative, although unix command lines definitely are not.
Until just recently, everyone seems to have thought as you do about type checking. Including myself. To our surprise, Dr. Becher, while trying to write a simple memory handler for an complex embedded system, wrote a complete, strong, polymorphic, static typing system (with plenty of room for dynamic types). Amazingly, this system required absolutely no syntax changes or compiler modifications; the resulting language is unmistakably Forth! (Although in practice, you want to redefine all words so that they can use the typing, and the result of THAT is not ANSI standard Forth.)
How he did it is amazingly simple, efficient, and natural; check it out at his homepage.
His system appears to have some limitations compared to a generic concatenative language (for example, a word can't have a variable stack effect); however, I've come up with a simple solution which makes his system have the full abilities of any other concatenative language. I haven't written it up because right now, my prototype requires a small runtime component, and I'm sure that I can make it entirely static (so that it'll be comparable to Becher's system).
Someone else has also designed an ML-style inferencer for a Joy-like language, but I'm not aware of it actually having been built. At any rate, I have some doubts about its usefulness; Becher's system is so simple and elegant that I don't think I want all the complexity and overhead of ML type inference for the tiny advantage of sometimes not having to declare types.
However, earlier you state that "this behavior doesn't come without a cost." Your specific example was incorrect, but in general you're correct. There's a time to use applicativity, and a time to use concatenativity. Every computer scientist should know Forth and understand concatenativity, but every computer scientist should also know the other, different languages.
I simply find concatenativity interesting because I've never studied it before.
I can't clarify this one, but I can perhaps shed a little light on the cesium experiment. No pun intended.
It didn't involve FTL transmission. Not at all. What happened was that they observed a wavefront travelling FTL. Wavefronts aren't information by themselves; they're merely the conincidental addition of light waves of different wavelengths.
For a concrete demonstration of this, together with a better explanation than I could ever give, please point your Java-enabled browser at this page.
A moderator just moderated my above post as a "troll". Why? I'm posting directly on topic, using logic, and not bringing in any inflammatory issues. This moderation is preposterous.
Is an armed citizenry. And the most powerful weapon is information (so no, I'm not going to go off about the second amendment this time;-).
As we know, the plane in PA crashed short of its goal because a couple of its passengers made cell-phone calls, and realised that they needed to resist. They were able to make those calls because they had cell phones; they had cell phones because it was economically reasonable to do so; and it was economically reasonable to do so specifically because (most people believe that) it's possible to communicate business information securely using the phones. (It's not relevant to my argument whether or not most people are correct; only what they choose to do.) Entrepreneurial information is by its nature very sensitive, and drives much of our economy.
If information cannot be secured, then people will have much less of a demand for it to travel, and cell phones (and all other vulnerable communication devices) could well become uneconomical. In the long run, the government will be increasing the danger of its citezens, while hurting their economic security and destroying their rights.
OOP is a design methodology, not a language feature!
OOD is a design methodology. OOP is how you implement that. And although you can do OOP in a non-OOP language, OOP is also most definitely a language feature.
If you code OOP in a language which doesn't support it, you'll have to obfuscate your solution with OOP implementation.
According to this logic, we would never have moved to C from assembly language.
Yes, taken strictly and applied to all cases, it means that. But only a great fool would do so. You are clearly not a great fool; therefore, I cannot take the glass in front of you. Sorry. I mean that I can't assume that Chuck meant that generality.
C is not a huge step up from assembly language is bug-freeness. It's an improvement in consistency of code, and it makes structure easier to discern, but there's a reason it's called "portable assembly".
Very good question. This is fundamentally different from OO. For example, Forth is not an OO language, but if your problem fits OO, you can easily tranform Forth into OO. Forth isn't aspect-oriented, either, but again, it can be made so.
In Forth you don't merely define new types that model the solution domain; rather, you define a new _language_ in which the solution domain can be expressed naturally.
A common and desired result is that the solution portion of your program (as opposed to the part in which you're defining your language) can be read by an expert in the solution domain who knows NOTHING about computers. Nothing; not even how to read pseudocode. The final result may look like English; more often it looks like the formal terms appropriate to the solution.
Forth people are proud of their almost total lack of syntax; even so, sometimes the problem requires syntax. In those cases too Forth has been extended; there are at least two Fortran/BASIC style parsers, and one general-purpose parser generator.
You're largely right. The lessons you learn in Forth can sometimes be applied to C and Scheme. But in spite of the lesson we've all heard, that all languages are essentially the same, practical experience shows that they're NOT. Refactorings which are easy in Java are horribly painful in C (because of the lack of classes, for example). Code which looks natural in C looks bad in Java.
The reason? Java uses object orientation. C doesn't.
So does Forth have anything that C doesn't? Yes. In fact, Forth has a characteristic which permeates the entire language and which is shared by only a few other languages: I call that characteristic "concatenativity". Let me explain.
The languages you're used to are probably all "applicative": you apply parameters to functions using the syntax of the language. In Forth parameters are nonexistant as far as the language is concerned; there is no application operator, implicit or explicit. Instead, a Forth program is defined as the concatenation of a series of primitive operations on a stack. Mathematically, this could be modelled as having "Forth words" be functions of one input and one output, and a "Forth program" be the composition of the functions, in the order of their appearance.
But that's all windy and theoretical. I have a more useful definition of what it means for a language to be "concatenative", and it's the reason I chose that name. A language is concatenative if the concatenation of any two valid programs is a valid program, and if the splitting of any valid program along token boundaries produces two valid programs.
Suppose you have the program "2 3 +." (add two and three and display the result). Split it any way you like: "2 3" is a program which leaves two integers on the stack, and "+." is a program which takes two integers, adds them, and displays the result.
Thus we see that your statement "Forth forces you to use small functions" isn't quite true. You can write functions as large as you want; the language doesn't care, and I've never heard of an implementation which would have any problems. The trick is that in Forth, if your definition gets too big, you can simply cut part of it out (arbitrarily), give that section a name, and call that name from your code. Bingo -- you've just performed a complete refactoring "Extract Method". And there was no trace of danger -- no need for a refactoring browser.
If you've survived my exposition this long, congrats. Sorry.:-) Check out the Joy page for a possibly more survivable introduction.
And BTW, you list the claim "Forth is small" as a dubious advantage of Forth. Yet I would say that's a definite advantage. Forth is small because it uses Forthlike implementation techniques; it's easy to manually compress a Forth application by refactoring its methods. Forth is small, and your application in Forth can also be small.
Your incredulity shows your almost unspeakable insularity. Your use of a Unix-based, system-specific command to provide evidence against me is solid proof of that insularity.
Not all the world is a desktop or workstation. Not all systems run Unix. This will ALWAYS be true, because Unix isn't appropriate for most systems.
Yes, lack of memory protection is entirely inappropriate for systems with a variable number of multiple users. But it's entirely appropriate for users with multiple systems. Chuck's chip is supposed to cost $1 in production quantities. One dollar for 25 processors. I tell you one thing for sure: I'm not sharing mine with anyone else. I may even buy the x36 or x49 or x64. Chuck thinks he might even be able to stretch it up to 100 chips on a side, for ten thousand processors on one chip (although the resulting chip will be as big as a Pentium III).
What would you run on this? I see you're wanting to run Apache and Beowulf. I think that's stupid; those are designed for desktops. I'd want to run neural networks and simulated annealing. I'd want to build a wristwatch which can transcribe to ASCII all speech which it hears, with identities for the seperate speakers. I'd build a PDA which recognises commands and takes dictation subvocally (in other words, it reads lips).
The applications for this kind of power and speed are astounding -- even with only 256K of memory and 18-bit processors.
Ah, I bet you didn't notice that, did you. 18 bit! 256K address space! Total. ALL of the processors share that 256K. That's tons of elbow room for a fixed-purpose system (although not enough for many algorithms; reimplementing Deep Blue will have to wait until Chuck simulates at LEAST a 24-bit chip).
Seriously, can you see any point in memory-protecting a system with a total of 256K of memory?
He effectively said there was a conspiracy to perpetrate bugs, which there isn't.
He most certainly did NOT say that. He said that there is a common interest in keeping to the current ways of doing things, and further that the current way is less efficient than his way. His first statement is obviously true; he doesn't infer from this that there's any conspiracy, nor does he need to. His second statement is not obviously true, and in fact I believe it misses the point. It may be true that his way is actually more efficient, but the costs of converting everything to work his way would be very high indeed. When you add in the fact that the theory behind Forth isn't completely understood and is only beginning to be explored, it's very clear that now isn't the time to switch to Forth, and even more clear the 1980 was worse.
This is not to say that you can't write code in other languages that is just as incomprehensible, but I find that I can pick up a perl script I wrote 2 years ago and read it right away.
What can I say? You know Perl, and you know how to write clear code in it. Try reading a hardware engineer's Perl code (i.e. someone who didn't grow up writing software), and see how far you get.
I can't do that with Forth.
Odds are that you can -- I certainly can, and I don't have an immense amount of experience with Forth. You simply have to realise that Forth is different, and you have to learn how those differences affect the ideal coding style.
For example, you're used to a vertical code layout:
function1
function2
function3
In Forth, the ideal code layout is horizontal:
function1 function2 function3
You're also used to keeping your routine size down to a page or two -- any bigger, and it gets too hard to maintain, and any smaller and the parameters take up too much space to type and too much time to pass to the function. In Forth the ideal routine size is about 50 characters.
In both Perl and Forth, you can write unit tests to check your code. In Forth, you're encouraged to keep them in the same source file, and run them as part of compilation. There are tools to help -- one of my favorites defines the words "testing", "{", "--", and "}".
Include a section like that after every word definition, and update it regularly whenever you try to use the word in a different manner, and you'll have a much easier time maintaining the word when it has to be changed.
(I'm not claiming that unit testing is new to Forth, although Forth was one of the first languages to use it heavily as part of the language. Perl and Python in particular can be used very effectively for unit tests, since they're interactive.)
Anyhow, my point is that the rules for programming in Forth are very different than those for other languages.
He's worked with a lot of teams as well. Memory protection is NOT a way to get bugs out of your system (that's STUPID; there's no protection inside a process); rather, it's a way to emulate an air-gap between programs (in other words, for security). When you have multiple processors for that cheap, it's far more secure to just set up a seperate processor.
The trouble with stack machines is that they have a worse Von Neumann bottleneck than register machines. Everything has to go through the top of the stack.
At the same time, though, because you don't have a register file, you don't have to have an instruction decode stage. As a result, your instruction cycle time goes down.
The cycle time needed for these machines is truly amazing. I built one back in college, and outperformed every other chip in the class.
(Why are boldface, italic, and roman not appropriate analogues for red green and yellow, anyway?)
They are, of course -- he said they were. He's using color now because that's what he started with; you can't deny that it's easier to work with than multiple typefaces.
Slashdot Mirror
Some here are warning you that major changes always require a total rewrite; yet in real life, total rewrites result in inability to compete (look how long the Netscape rewrite paralysed Netscape, unable to meet Microsoft's challenge!). There's some good discussion of the danger of rewriting at a former MS software engineer's site, and some limited advice about how to get away without doing it.
But you've decided to rework rather than rewrite, you say, so I have no doubt you'll ignore the naysayers here. So what CAN you do? After all, as you recognise, reworking is dangerous!
The following rules have worked for me; I've refined my own experience with advice from Fowler's Refactoring, a book as useful as Design Patterns, and with study of Extreme Programming, a design methodology forged in the traditions of Smalltalk, and in the knowledge that maintainance, the most important and expensive part of software engineering, is also the least studied.
First, do the simplest thing that could possibly work. Don't EVER take your program out of commission for more than a day; make sure it runs at the end of each day. If you're doing something and at the end of the day your code base is broken, STRONGLY consider throwing away your changes and going back to the design stages.
Second, rely on unit tests extensively. Start every change by writing as extensive of a unit test as possible. Unit test every function you touch, BEFORE you touch it, and after. Unit test every change you make, and run the unit test BEFORE you make the change to ensure that it fails (i.e. it detects the change). Write your unit tests BEFORE you write code, whenever possible; you'll objectively know your code is done when your unit tests pass.
Third, don't design too far ahead; you don't know what tricks the old code is going to throw at you. Implement one feature at a time, bringing the code into compliance. Once everything has a unit test (thanks to your following the above principles), THEN you can safely embark on larger design changes -- and in the meantime, you have working code with new features, a win even if your customer/boss/manager decides not to continue.
Fourth, don't be afraid to redesign your own code. The stuff you wrote has more tests, so it's safer to change, but it's more likely than the old code to lack some critical understanding only age can give.
Fifth, use the principles of refactoring. Whenever possible split each code change into two parts: first, a part which changes the structure of the code without changing its function (and which therefore allows you to run the same unit tests); and second, a part which uses the new structure to perform a new function (thereby requiring new unit tests).
Good luck. If you want more advice, read up on Extreme Programming.
-Billy
I'm puzzled by your answer, since it seems you do follow my logic quite well -- you state very clearly that "it's unlikely that we'd be able to find efficient algorithms ... even if P=NP were known."
So go back to my post and read it that way:
1. I know an efficient algorithm, thereby proving P=NP.
2. I know a proof but no algorithm.
3. I know both a proof and an algorithm, and the algorithm can't plausibly be derived from the proof (I probably used the algorithm to derive the proof).
What do you do?
-Billy
When you say "all Turing machines" I assume you mean "all algorithms", of course.
Yes, that's the canonical P=NP solution. It's also completely useless (it may not even be implementable), thus bringing us back to my original point.
-Billy
It's interesting how most of the answers here fail to look at the actual question. The question wasn't so much, "what will break;" the question was, "what should one do."
Although it's interesting and even essential to review what parts of computer science or our economy would be toppled by such a discovery, doing so doesn't answer the question.
Let me rephrase the question for any who missed it: "Suppose you discover that P=NP. What is the right thing to do?" Do I cover it up, or do I release? What if I proved that P=NP, but I don't know of an algorithm to actually convert any known problem? Or, what if I did know the algorithm and the proof, and I believed that the algorithm couldn't be reconstructed from the proof -- should I release the proof?
This is a powerful question!
My feeling is that the truth should be known, but experience shows that information without knowledge, and knowledge without understanding, can be deadly. (I'm afraid you can't affect whether people will get understanding without wisdom, so we'll stop the natural progression before we reach that point.) A little survey of the literature (please see the other posts here; they've got GREAT info) shows that the practical benefits of this discovery would be IMMENSE. The drawbacks seem huge, too; but if a particular algorithm has become easier to destroy, so also do new algorithms open up. Look around -- identify as many existing things which are harmed by your discovery, and try to provide a discussion of how to recover from the harm.
Even if you're not altruistic you want to do this; the person who is most essential in the new world isn't the person who discovered the info, since once the secret's out it's not under his control; it's the person on whom people are depending. Be that person -- but don't be selfish about it. Too selfish ruins the game too; there's always someone with enough power to take your position away from you.
So that's my knee-jerk answer, with a bit of reasoning: research the discovery, find who it hurts, and prepare to help them. Then make it public.
There's another question which is implied by the first one: to whom do I release info about my discovery? I can't answer that. Does anyone have an answer? I can say that you'll HAVE to release some information before you're ready to release it all; for example, you might want to found a corporation, and you'll almost certainly need library assistance. What can I say about that? Pick people you can trust, and don't trust them with too much.
-Billy
Just because the price of some OSS is $0.00 doesn't mean someone isn't selling it. The makers are hobbyists, but write products to be used beyond the hobbyist segment.
/some/ people working on AbiWord because they need it; those are the people I would trust to /want/ it to work.
Hmm. My impression was that the makers were (perhaps) hobbyists, and wrote the product, like all hobbies, for the sake of writing it. Getting use "beyond the hobbyist segment" would be a marvelous bonus, but not the goal of any hobbyist.
Other open source projects are NOT written for the sake of writing them; they aren't hobbies. They're written for the sake of usefulness to the author, and released because releasing doesn't hurt and can sometimes help (by getting other people to improve the product).
I wasn't describing instructions, by the way, although I did mention a recipie; I was intending the analogy to be to paint, not the recipie for the paint. If I paint my house, you like the results, and I give you the paint I used, am I responsible for whether you choose to paint your house with that paint? Okay, if the paint damages your house and I didn't warn or disclaim, yes. But otherwise, NO.
This little disclaimer looks like a great example of a hobbyist telling the truth: we're doing this because it's fun, not because it's useful. Don't expect any more from it, unless you can help contribute the "more". Now, after reading this I would still conclude that there are
-Billy
The #debian IRC channel is astoundingly good for that sort of thing. I'm sure other distros have exact equivalents.
In this letter, regardless of what's been said in the past, the group is asking people to readjust their expectations. They're not demanding that people take them "seriously as an alternative to Microsoft;" on the contrary, they're asking that people think less of them.
And about advancing the Linux cause, isn't truth and honesty a little more effective in the long run than false expectations? And if it isn't, who cares about the Linux Cause?
-Billy
That's an incredibly silly analogy; painting someone else's house doesn't line up with open source in any way I can see.
Perhaps one could make the analogy that open source is making your own paint to paint your own house, and then giving away the paint (or the recipie). If someone complains about the color of their house, you tell them to complain to whoever selected the paint and color, not you.
OTOH, if you DID paint their house for them, then you are to some degree responsible for the results -- and if you install Linux on someone's computer, you'd better be sure it'll meet their needs. But Linus isn't responsible if it doesn't; you are.
-Billy
To what would this hypothetical adaptive space telescope adapt? The adaptive ground-based telescopes adapt to the atmosphere; but there's no atmosphere in space.
I just don't see how adaptive technology could improve a space telescope.
-Billy
Facinating stories -- I was an OS/2 user back when Object Desktop (whoops, I forgot their real name -- Stardock?) was trying to rescue OS/2. I was really disappointed when they failed. They did a REALLY good job in all their other work, though.
:-). That would be the ultimate solution, I suppose -- but on the other hand, this would make a MOSIX cluster much easier to set up, since the individual machines couldn't be independantly misconfigured.
Question: I see a new feature in the next version of eComStation, network boot. In this, the entire OS is stored on the disk of one machine, and the other machines boot entirely from it -- all config files, everything. All processing is done on the clients, but the files are stored on the server. That's convenient!
I know X can do part of this, but it still puts the processing on the server; NFS can do another part, but it's enormously slow and bulky (and VERY odd to work with).
So is there any complete solution I can install on a 'terminal' PC so that all booting, storage, and so on is done on a central system, but all processing and running is done on my system -- and it all just works, whether I'm using console or X, svgamode or KDE?
I'm sure that when MOSIX is done that'll be easy
-Billy
Some of the transport solutions, such as HyperTransport, can be used between CPU and memory. This is how nVidia's new 'nForce' chipset works; it hooks up an Athlon to DDR RAM via HyperTransport links.
RDRAM (Rambus) got all of its speed by using a bus rather similar to these (although with some odd tradeoffs). These are essentially public versions of what Rambus was trying to make proprietary.
If only they made standard keyboards with that little nub for pointing.
:-).
They do. I have two; one at home, and one at the office. It's called a 'Trackpoint' keyboard; it's very expensive ($160, according to epinions, although someone's selling one for $70 on half.com). I got mine for $115 or so a long time ago.
I'm eagerly awaiting the gesture-sensitive keyboard from FingerWorks; of course, at that price I'll wait for a review, since I've used a membrane keyboard in the past; this isn't a membrane keyboard, but it does look faintly like one, and that makes me a little bit uncomfortable
http://www.fingerworks.com/products_frame.html
-Billy
Thank you very much for your kind words!
Yes, Unix piping is in a sense concatenative, although unix command lines definitely are not.
Until just recently, everyone seems to have thought as you do about type checking. Including myself. To our surprise, Dr. Becher, while trying to write a simple memory handler for an complex embedded system, wrote a complete, strong, polymorphic, static typing system (with plenty of room for dynamic types). Amazingly, this system required absolutely no syntax changes or compiler modifications; the resulting language is unmistakably Forth! (Although in practice, you want to redefine all words so that they can use the typing, and the result of THAT is not ANSI standard Forth.)
How he did it is amazingly simple, efficient, and natural; check it out at his homepage.
His system appears to have some limitations compared to a generic concatenative language (for example, a word can't have a variable stack effect); however, I've come up with a simple solution which makes his system have the full abilities of any other concatenative language. I haven't written it up because right now, my prototype requires a small runtime component, and I'm sure that I can make it entirely static (so that it'll be comparable to Becher's system).
Someone else has also designed an ML-style inferencer for a Joy-like language, but I'm not aware of it actually having been built. At any rate, I have some doubts about its usefulness; Becher's system is so simple and elegant that I don't think I want all the complexity and overhead of ML type inference for the tiny advantage of sometimes not having to declare types.
However, earlier you state that "this behavior doesn't come without a cost." Your specific example was incorrect, but in general you're correct. There's a time to use applicativity, and a time to use concatenativity. Every computer scientist should know Forth and understand concatenativity, but every computer scientist should also know the other, different languages.
I simply find concatenativity interesting because I've never studied it before.
-Billy
I can't clarify this one, but I can perhaps shed a little light on the cesium experiment. No pun intended.
It didn't involve FTL transmission. Not at all. What happened was that they observed a wavefront travelling FTL. Wavefronts aren't information by themselves; they're merely the conincidental addition of light waves of different wavelengths.
For a concrete demonstration of this, together with a better explanation than I could ever give, please point your Java-enabled browser at this page.
-Billy
A moderator just moderated my above post as a "troll". Why? I'm posting directly on topic, using logic, and not bringing in any inflammatory issues. This moderation is preposterous.
-Billy
Is an armed citizenry. And the most powerful weapon is information (so no, I'm not going to go off about the second amendment this time ;-).
As we know, the plane in PA crashed short of its goal because a couple of its passengers made cell-phone calls, and realised that they needed to resist. They were able to make those calls because they had cell phones; they had cell phones because it was economically reasonable to do so; and it was economically reasonable to do so specifically because (most people believe that) it's possible to communicate business information securely using the phones. (It's not relevant to my argument whether or not most people are correct; only what they choose to do.) Entrepreneurial information is by its nature very sensitive, and drives much of our economy.
If information cannot be secured, then people will have much less of a demand for it to travel, and cell phones (and all other vulnerable communication devices) could well become uneconomical. In the long run, the government will be increasing the danger of its citezens, while hurting their economic security and destroying their rights.
Restricting crypto is INCREDIBLY short sighted.
-Billy
OOP is a design methodology, not a language feature!
OOD is a design methodology. OOP is how you implement that. And although you can do OOP in a non-OOP language, OOP is also most definitely a language feature.
If you code OOP in a language which doesn't support it, you'll have to obfuscate your solution with OOP implementation.
-Billy
According to this logic, we would never have moved to C from assembly language.
Yes, taken strictly and applied to all cases, it means that. But only a great fool would do so. You are clearly not a great fool; therefore, I cannot take the glass in front of you. Sorry. I mean that I can't assume that Chuck meant that generality.
C is not a huge step up from assembly language is bug-freeness. It's an improvement in consistency of code, and it makes structure easier to discern, but there's a reason it's called "portable assembly".
-Billy
Very good question. This is fundamentally different from OO. For example, Forth is not an OO language, but if your problem fits OO, you can easily tranform Forth into OO. Forth isn't aspect-oriented, either, but again, it can be made so.
In Forth you don't merely define new types that model the solution domain; rather, you define a new _language_ in which the solution domain can be expressed naturally.
A common and desired result is that the solution portion of your program (as opposed to the part in which you're defining your language) can be read by an expert in the solution domain who knows NOTHING about computers. Nothing; not even how to read pseudocode. The final result may look like English; more often it looks like the formal terms appropriate to the solution.
Forth people are proud of their almost total lack of syntax; even so, sometimes the problem requires syntax. In those cases too Forth has been extended; there are at least two Fortran/BASIC style parsers, and one general-purpose parser generator.
-Billy
You're largely right. The lessons you learn in Forth can sometimes be applied to C and Scheme. But in spite of the lesson we've all heard, that all languages are essentially the same, practical experience shows that they're NOT. Refactorings which are easy in Java are horribly painful in C (because of the lack of classes, for example). Code which looks natural in C looks bad in Java.
." (add two and three and display the result). Split it any way you like: "2 3" is a program which leaves two integers on the stack, and "+ ." is a program which takes two integers, adds them, and displays the result.
:-) Check out the Joy page for a possibly more survivable introduction.
The reason? Java uses object orientation. C doesn't.
So does Forth have anything that C doesn't? Yes. In fact, Forth has a characteristic which permeates the entire language and which is shared by only a few other languages: I call that characteristic "concatenativity". Let me explain.
The languages you're used to are probably all "applicative": you apply parameters to functions using the syntax of the language. In Forth parameters are nonexistant as far as the language is concerned; there is no application operator, implicit or explicit. Instead, a Forth program is defined as the concatenation of a series of primitive operations on a stack. Mathematically, this could be modelled as having "Forth words" be functions of one input and one output, and a "Forth program" be the composition of the functions, in the order of their appearance.
But that's all windy and theoretical. I have a more useful definition of what it means for a language to be "concatenative", and it's the reason I chose that name. A language is concatenative if the concatenation of any two valid programs is a valid program, and if the splitting of any valid program along token boundaries produces two valid programs.
Suppose you have the program "2 3 +
Thus we see that your statement "Forth forces you to use small functions" isn't quite true. You can write functions as large as you want; the language doesn't care, and I've never heard of an implementation which would have any problems. The trick is that in Forth, if your definition gets too big, you can simply cut part of it out (arbitrarily), give that section a name, and call that name from your code. Bingo -- you've just performed a complete refactoring "Extract Method". And there was no trace of danger -- no need for a refactoring browser.
If you've survived my exposition this long, congrats. Sorry.
And BTW, you list the claim "Forth is small" as a dubious advantage of Forth. Yet I would say that's a definite advantage. Forth is small because it uses Forthlike implementation techniques; it's easy to manually compress a Forth application by refactoring its methods. Forth is small, and your application in Forth can also be small.
-Billy
Your incredulity shows your almost unspeakable insularity. Your use of a Unix-based, system-specific command to provide evidence against me is solid proof of that insularity.
Not all the world is a desktop or workstation. Not all systems run Unix. This will ALWAYS be true, because Unix isn't appropriate for most systems.
Yes, lack of memory protection is entirely inappropriate for systems with a variable number of multiple users. But it's entirely appropriate for users with multiple systems. Chuck's chip is supposed to cost $1 in production quantities. One dollar for 25 processors. I tell you one thing for sure: I'm not sharing mine with anyone else. I may even buy the x36 or x49 or x64. Chuck thinks he might even be able to stretch it up to 100 chips on a side, for ten thousand processors on one chip (although the resulting chip will be as big as a Pentium III).
What would you run on this? I see you're wanting to run Apache and Beowulf. I think that's stupid; those are designed for desktops. I'd want to run neural networks and simulated annealing. I'd want to build a wristwatch which can transcribe to ASCII all speech which it hears, with identities for the seperate speakers. I'd build a PDA which recognises commands and takes dictation subvocally (in other words, it reads lips).
The applications for this kind of power and speed are astounding -- even with only 256K of memory and 18-bit processors.
Ah, I bet you didn't notice that, did you. 18 bit! 256K address space! Total. ALL of the processors share that 256K. That's tons of elbow room for a fixed-purpose system (although not enough for many algorithms; reimplementing Deep Blue will have to wait until Chuck simulates at LEAST a 24-bit chip).
Seriously, can you see any point in memory-protecting a system with a total of 256K of memory?
-Billy
He effectively said there was a conspiracy to perpetrate bugs, which there isn't.
He most certainly did NOT say that. He said that there is a common interest in keeping to the current ways of doing things, and further that the current way is less efficient than his way. His first statement is obviously true; he doesn't infer from this that there's any conspiracy, nor does he need to. His second statement is not obviously true, and in fact I believe it misses the point. It may be true that his way is actually more efficient, but the costs of converting everything to work his way would be very high indeed. When you add in the fact that the theory behind Forth isn't completely understood and is only beginning to be explored, it's very clear that now isn't the time to switch to Forth, and even more clear the 1980 was worse.
This is not to say that you can't write code in other languages that is just as incomprehensible, but I find that I can pick up a perl script I wrote 2 years ago and read it right away.
What can I say? You know Perl, and you know how to write clear code in it. Try reading a hardware engineer's Perl code (i.e. someone who didn't grow up writing software), and see how far you get.
I can't do that with Forth.
Odds are that you can -- I certainly can, and I don't have an immense amount of experience with Forth. You simply have to realise that Forth is different, and you have to learn how those differences affect the ideal coding style.
For example, you're used to a vertical code layout:
function1
function2
function3
In Forth, the ideal code layout is horizontal:
function1 function2 function3
You're also used to keeping your routine size down to a page or two -- any bigger, and it gets too hard to maintain, and any smaller and the parameters take up too much space to type and too much time to pass to the function. In Forth the ideal routine size is about 50 characters.
In both Perl and Forth, you can write unit tests to check your code. In Forth, you're encouraged to keep them in the same source file, and run them as part of compilation. There are tools to help -- one of my favorites defines the words "testing", "{", "--", and "}".
testing addition
{ 3 4 + -- 7 }
testing distributive property of addition
{ 3 4 5 + + -- 3 4 + 5 + }
Include a section like that after every word definition, and update it regularly whenever you try to use the word in a different manner, and you'll have a much easier time maintaining the word when it has to be changed.
(I'm not claiming that unit testing is new to Forth, although Forth was one of the first languages to use it heavily as part of the language. Perl and Python in particular can be used very effectively for unit tests, since they're interactive.)
Anyhow, my point is that the rules for programming in Forth are very different than those for other languages.
-Billy
He's worked with a lot of teams as well. Memory protection is NOT a way to get bugs out of your system (that's STUPID; there's no protection inside a process); rather, it's a way to emulate an air-gap between programs (in other words, for security). When you have multiple processors for that cheap, it's far more secure to just set up a seperate processor.
-Billy
The trouble with stack machines is that they have a worse Von Neumann bottleneck than register machines. Everything has to go through the top of the stack.
At the same time, though, because you don't have a register file, you don't have to have an instruction decode stage. As a result, your instruction cycle time goes down.
The cycle time needed for these machines is truly amazing. I built one back in college, and outperformed every other chip in the class.
-Billy
(Why are boldface, italic, and roman not appropriate analogues for red green and yellow, anyway?)
They are, of course -- he said they were. He's using color now because that's what he started with; you can't deny that it's easier to work with than multiple typefaces.
-Billy