Professor Bernard Hodson (now based in Ottawa) has developed a programming system called Genetix. It is claimed that this is more efficient than any software currently used, and differs radically from everything done in the last fifty years by drawing on Turing's original concepts. [...]
[...] At present the work is apparently bound by commercial secrecy, but I hope that soon these surprising claims will be opened to general scientific discussion. Until then they will be hard to evaluate.
However, my business on this website is to explain what Alan Turing said and did; and I do think I can say that Hodson and Bloor are on doubtful territory in claiming that the Genetix programming ideas derive directly from Turing's writings. They quote quite general statements made by Turing in advancing the ideas of a universal machine, of the stack, and of program libraries, when all these ideas were completely fresh. They go on to interpret them in what seem to me much more specific modern terms, in support of the Genetix approach. I am sceptical as to whether the Genetix system actually derives from anything Turing had in mind.
To illustrate my point, note that the Genetix prospectus rests upon distinguishing the Universal Turing Machine concept from the stored-program concept. Turing himself, however, made no such distinction, and in 1948 clearly referred to all the digital computers then under construction as 'practical universal computing machines.'
Two possible confusions
As far as I can see there is no connection between Genetix and 'genetic programs' which improve themselves by means analogous to biological evolution by selection. (Turing might in fact be credited with the basic idea of such programs. Right from the start he emphasised the idea that the stored-program computer can modify its own instructions, suggesting that this capacity could be developed into the ability to learn from experience.)
Also, this Genetix has no connection with the Genetix which campaigns against the development of genetically modified organisms."
Proving a program correct only means that it conforms to its design, not that the design is correct. Proving designs correct is much harder, if not impossible. Most bugs that aren't just trivial syntactic errors are actually problems with the design, and programming languages that can be "proven" correct don't prevent those.
That article you cite is a load of stale moldy mediocre bullshit, not even as good as real fresh hot steaming bullshit, which at least holds together better thanks to its own internal roughage and grass fiber.
So what if... So what if... So what if...
So what if they have their head stuck up their ass? So what if they lie about having the first 8 bit Java? So what if they lie about having the smallest Java implementation? So what if they brush questions of performance under the rug? As long as their bullshit benefits the Greater Glory of Java, we love them. Let the blowjobs begin!
After all that bullshit about Java, and all of Sun's bullshit about "write once run anywhere", why are you so willing to give ORIGIN the benefit of the doubt that maybe they're not even slightly exagerating or omiting parts of the whole story, even if they don't have a demo you can download and test out for yourself. Have you already fallen for so many outlandish lies about Java that these wee little fabrications don't even register on the logarithmic Richter scale any more?
(Well, now that I think about it, you're right: I suppose it's best for Java in the long run, if we lie about how great it is, and make lots of promises we know we'll never be able to keep, and pretend to believe other pro-java liars. After all, Java was designed as a tool in the war against Microsoft. And there's nothing more important than going to war. Just explain to the families of the vets who were poisoned by depleted uranium shells and agent orange that the ends justify the means.)
I'll repeat: Java totally sucks ass for game programming. Now how does ORIGIN improve Java so much that it doesn't suck ass?
I'm a professional game programmer. I helped develop The Sims for Maxis/EA. Nobody in the computer game industry would ever suggest developing a "sophisticated" computer game in Java (except as a drunken joke at a christmas party), because they would be the laughing stock, and fired for incompetence if they were actually serious. Must I put it so gently, or should I be more blunt? Welcome to the real world.
As you say: Java wasn't designed for game programming. But since you already know that, I don't understand why you appearently don't agree with me.
Can't you see their utter contept for reality when they claim ORIGIN could "theoretically" handle any application, including "sophisticated" computer games, because it's "Turing Complete". Come on, these guys are blowing smoke out their ass.
Well, you asked. Let me say that I like Forth, and I'm embarrased for this guy hyping Forth up as being "Turing Complete", and hope it doesn't reflect badly on all Forth programmers. Forth is great, but I don't think it's the solution to everything, nor is Java.
One thing that makes Forth different than other languages like C, but similar to PostScript, is that it has separate return stacks and operand stacks. PostScript also has a separate dictionary stack, for scoping. Forth uses a linked list of vocabularies for scoping. PostScript uses marks on the stack (it has a special "mark" data type) but Forth doesn't, because the objects on the Forth stacks are not typed (you can't tell a zero from a mark), as they are with PostScript (or Lisp or JavaScript). PostScript is kind of like a cross between Lisp and Forth. Once I had a PostScript interpreter that could draw on the screen, I basically abandoned Forth, but still I like it.
There are different ways of implementing Forth "threading", that are all valid, but the essential thing is that there are just a few primitives, and the rest is built on top through a "threaded" interpreter, through named layers of indirection called "words".
The usual setup is "indirect threading," where a Forth word is compiled as a series of pointers to pointers to code, the indirect "Code Field Address" of each word to call in succession. At the cfa there is a pointer to the actual machine code to jump to. Primitives are implemented as machine code immediately following the code field address, so cfa points to cfa + wordsize.
High level Forth words all have the same cfa pointer to the heart of the Forth interpreter, which pushes the return stack and loops over interpreting the pointers following the cfa one by one.
The Forth compiler is written in Forth itself. Programmers are meant to be able to extend the compiler to implement specialized control and data structures, by writing "immediate" words that are executed at compile time, like Lisp macros, that can compile code and data into the word being defined.
Control flow is implemented by immediate words like "if", "then", "else", "begin", "while", "do", "loop", ";" etc, which are Forth words that compile calls to other low level run-time primitives like "(?branch)", "(branch)", "(loop)", "(exit)", etc: usually compiled words that muck around with the Forth return stack and registers.
You can move numbers between the return and operand stacks with ">r" and "r>". Literal data is pushed onto the operand stack by the word "lit" followed by an inline word sized bit literal, or the ever popular "clit" followed by an 8 bit character literal.
The words "create" and ";code" let you write Forth words for defining other words (or data types) that are implemented by machine code (that you enter in reverse polish notation).
The high level version is "<builds" and "does>" which let you write your own constructors and interpreters in Forth.
Some Forth systems use "direct threading", in that the code field address contains actual code to jump to, instead of a pointer to code. Forth words can then be compiled into a series of machine language subroutine calls (or whatever it takes), or they can be a more compact series of pointers to code, interpreted by the Forth main loop.
The Novix Forth Engine was a microprocessor designed to execute Forth, that had a separate bus to the return stack, operand stack, and main memory, that it could access all at the same time. The Forth compiler optimized Forth code, collapsing a sequence of parallelizable instructions into one bitslice-like instruction that did them all at once, like using the alu, pushing a number on the operand stack, and popping the return stack.
Java uses a totally different kind of VM than a pure Forth system, although it's similar to Forth in a lot of ways. It's a byte code interpreter. Some Forth systems are byte code interpreters (like Open Firmware on Mac PowerPCs and the L1-A Sun boot prom Forth), but not necessarily nor usually. Threaded does not equal byte coded. Byte code interpreters have been around for a long time before Java in many forms, like SCUD Pascal.
The best thing about the 1802 microprocessor is that it had a "GET HIGH" instruction.
The simplest approach to representing numbers with a Turing machine is in unary -- the number of sequential "1" marks on the tape is the value of the number, with a "0" to mark the end. (Like null terminated strings, but strlen() returns the value!)
You can also store data in the state of the machine, instead of writing it on the tape. Turing machines don't have registers, nor stacks, nor random access memory, but they can be in any number of different states. So to do anything non-trivial, you end up with a heck of a lot of machine states, connected together in a complex network.
In order to copy a number, you have to suck up some of that number into the machine state "temporary storage", then go into a state that moves the read/write head to the destination while remembering the temporary state, and then go through a series of states that writes the machine state out onto the tape while moving the head. So you could write a program that copied a number one bit at a time by moving back and forth between source and destination, using relatively few machine states. Or a program that copied numbers more efficiently n bits at a time with 2^n and then some machine states. To do anything non-trivial, you end up with zillions of machine states, representing a network of all possible values of temporary storage connected by tape seeking and writing instructions, and you also require infinite amounts of tape to execute the program.
Think of it like an Adventure (MUD) game with one deterministic player, who is carrying a tape and read/write head. The state of the machine is which room you're in, plus the state of the tape and position of the head. Each room has a door labeled for each possible token on the tape, and when you walk through correct door, it can write a token on the tape, and move the head up or down. A program is a set of interconnected rooms.
You have to double the number of rooms (states) to represent one bit of information in the machine state, like the Star Trek episode when they were beamed aboard an exact duplicate of the Enterprise, that represented one bit (the answer to the question "Is this real?").
It's hard for me to believe that they're using a Turing machine model for efficiency's sake.
I respectfully submit these slogans for use in your advertising campaign:
"Special instruction that sets P = NP in 1 clockcycle!"
"Now, with Patented Order(1 Click) [TM]-Complete (R)-Rated (C)-Plus-Plus E-Commerce Algorithms."
"Offering the world's first fully optimized totally integrated long term zeroth order solution to the halting problem!"
"Write once, halt anywhere."
"We believe our own hype." Oops -- I sold all rights to that one to Sun, so you'll have to negotiate a license for that slogan with Sun directly. There's a special discount for Java VM licensees.
Yes, the white paper was definitely written by somebody who just barely grasped the concept of Turing Machines, and didn't realize (or believe the implication) that the fantastic computational abilities he claimed was unique to their system was actually widely applicable to ALL modern computers.
Funny how they have the nerve in the faq to pose themselves straw man questions like "Can it interoperate with system XYZ?" and answer "Of course, since our system is Turing complete!". Well FYI systems XYZ and ABC and 123 and A to Z are all Turing Complete -- It's No Big Deal, and they're making a worthless and facitious statement, like "oh, that's just a simple matter of programming". At least Spinal Tap had enough self delusional integrity to claim something UNIQUE: that their amplifier "went to eleven".
Next thing we know they'll be suing every computer company on Earth for violating their "Turing Machine" patent.
Does anyone else see a big steaming load of BS, designed to bilk investors?
The white paper was ridiculously trivial, devoid of real content, yet demeaningly explaining the most basic computer science 101 concepts as if the real innovations they weren't revealing were far to complex for anyone in the industry to grasp.
And then we have straw man questions and answers in the FAQ like:
"Isn't ORIGIN a proprietary technology, like Windows?
The internal procedures are proprietary and need to remain so in order to ensure the efficiency of the software."
Oh yeah, their software runs faster if nobody knows how it works or is allowed to observe it. Sounds like some kind of quantum computer, huh? More like an investor scam.
Looks to me like the old codger in charge is trying to exploit the good name of Alan Turing, his former co-worker. So where was he when Mr. Turing was on trial and needed a character witness to testify about his outstanding contributions to computer science and the defeat of Adolf Hitler?
(It's so rare I get the chance to use a legitimate ad swasticum attack.)
"Could ORIGIN be used to program sophisticated computer games?
There is no reason why not. In theory it can handle any application. There is nothing specific to games programming that it would find problematic."
After that pedantic lecture on Turing machines, this vaguely reassuring "theoretical" answer does not impress me. The lack of speed may not seem "problematic" to an academic who doesn't know anything specific about game programming.
But how about answering a more specific question: "For the practical programming of even simple computer games, is ORIGIN any better than Java, which totally sucks ass?"
Rule one: Don't bullshit.
Rule two: Don't believe your own bullshit.
Rule three: The purpose should be the service of the users, not the self aggrandization of the authors.
Believe me: You don't want to end up with as bad a reputation as Mark Pesche!
You really have missed the point.
But you just go on missing it: that leaves all the great opportunities to people who have been paying attention.
-Don
UniPress Emacs version 2.20 for NeWS shipped with "tab windows" and "pie menus", that I implemented using the "Lite Toolkit", which ran on Sun NeWS 1.1 and SGI 4Sight. I published the source code for tab windows and pie menus on the internet for free and unrestricted use (before the term "open source" was popular).
I later used Emacs with tab windows to implement an authoring tool for HyperTIES, a hypermedia browsing/authoring research project developed in Ben Shneiderman's Human Computer Interaction Lab, at the University of Maryland College Park.
Later on I wrote and freely published several different implementations of "tab windows", using The NeWS Toolkit version 1.0, 2.0, and 3.0. They allowed you to drag the tab around to any edge of the window, lay the windows out sequentially so they overlapped and each of their tabs was visible, and you could bring any window to the top by clicking on the tab, move the windows by dragging the tab, etc.
Sound familiar? It's called prior art. I believe it makes Adobe's patent invalid.
Here's the reference to and a quote from a paper we published in 1991, although we performed the research a few years before that (which explains the words "Look Back" in the title).
-Don
Designing to Facilitate Browsing: a Look Back at the HyperTIES Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, and William Weiland.
Hypermedia, V3 #2, 1991
Page 115.
The more recent NeWS version of Hyperties on the SUN workstation uses two large windows that partition the screen vertically. Each window can have links and users can decide whether to put the destination article on top of the current window or on thee other window. The pie menus make it rapid and easy to permit such a selection. When users click on a selectable target a pie menu appears (Fig. 1) and allows users to specify in which window the destination article should be displayed (practically users merely click then move the mouse in direction of the desired window). This strategy is easy to explain to visitors and satisfying to use. An early pilot study with four subjects was run, but the appeal of this strategy is very strong and we have not conducted more rigorous usability tests.
In the author tool, we employ a more elaborate window strategy to manage the 15-25 articles that an author may want to keep close at hand. We assume that authors on the SUN/Hyperties will be quite knowledgeable in UNIX and Emacs and therefore would be eager to have a richer set of window management features, even if the perceptual, cognitive, and motor load were greater. Tab windows have their title bars extending to the right of the window, instead of at the top. When even 15 or 20 windows are open, the tabs may still all be visible for reference or selection, even though the contents of the windows are obscured. This is a convenient strategy for many auithoring tasks, and it may be effective in other applications as well.
CONCLUSIONS
The documents written with Hyperties have been used by hundreds of users at demonstrations, and some components have been studied in controlled experiments. A full usability study with a realistic application to compare Hyperties/SUN documents with other electronic forms or paper is a desirable goal. We believe that the components are important contributions and encourage other developers to try them and refine them further.
We see further opportunities for improving the hypertext browsing environment with ideas such as multiple indexes to permit partitioning of lar5ge databases, graphic browsing capabilities (not a node-link diagram, but a higher level representation), various bookmarks, and still larger, sharper, and faster displays. Improved search facilities would include flexible string searching, search for graphic images, search within a restricted distance from the current node, weighted search results, intersections/unions of searches, and search by node-link structures. Our recent efforts have been to develop structural analysis software tools and metrics to provide authors with suitable feedback to better guide the document creation process. The future of hypertext will be brighter if the user interface for browsing can be made more attractive and effective.
Re:A lovely summary of all that's wrong with X
on
X Windows Must Die!
·
· Score: 5
You're wrong about your "Windows-convert/Machophile" accusation. I wrote it long before I learned to program Windows or the Mac. (Or did you really mean Mach?) At the time, I was a disgruntled ex Sun employee. "Slowlaris: So bad I left the company."
Nobody's blaming X itself for the mistakes of its designers. I'm blaming ignorant hypsters like yourself for all the insincere uninformed cheerleading that led to the widespread adoption of X11, in spite of all of its severe technical problems. Stop being such an appologist for bad design and poor execution.
I tried to make constructive criticism in that chapter, comparing it to NeWS's downloadable code and extensible protocols. NeWS was certainly not perfect, but X11 had a lot to learn from it, and people like you still refuse to open your eyes to that fact.
The software we're using today has evolved into a model much closer to NeWS than X11. Web servers are like NeWS clients (the program that runs an application remotely). The web browser is like the NeWS server (the program running on the user's machine), that controls the display. The web server can download html and javascript to the browser, that interacts locally with the user, much in the same way that NeWS clients download PostScript code to the NeWS server.
So before you tell me that NeWS's model of downloadable extensibility sucks and nobody uses it, you should do some research and check out that new craze that everybody's been talking about recently, called the world wide web. If you have never heard of the web, and can't find a book about it in the library or your local book store, just search for "www" on yahoo.
-Don
Re:Uhh. . .pass the crack pipe this way. . .
on
X Windows Must Die!
·
· Score: 3
See "Eraserhead" for a vivid illustration of the state of X11.
The componentization of the window manager was in the abstract a good idea, but the execution (ICCCM) was an abortion. You say that X wouldn't have survived as long without it. But if X had died because it was stuck with one bad window manager, then we wouldn't be in this dead end prediciment that we're stuck with today!
X should have been designed to self destruct. Like shareware that expires after a few months. I wish somebody would patent X11, and sue everyone who tries to use it. Where are SGI's lawyers when we need them?
The ICCCM window manager protocol is like an emergency tracheotomy performed with a rusty crowbar, that's been inflamed and oozing infected pus for the last decade. ICCCM is the scab on a stigmata that will never heal. But people keep trying to fix the problem by enlarging the hole in the neck and sticking tubes down it! Isn't it about time to just cut the head off and bury the body?
There's nothing clean nor extensible about the X protocol, and to make such a statement ignores reality and history, and promulgates bad taste. NeWS had an truly extensible protocol that allowed clients to dynamically download code to the server at run time. X extensions just don't cut it. You could just as well call Perl a clean simple well designed language with an easy to learn syntax, if you're going to distort the facts so grossly.
If you think of users as morons, then you should not design user interfaces, because only a moron would want to use an interface designed by somebody who has no respect for the user.
The first pie menus I implemented were for the X10 version of UWM, by Mike Gancarz et all. The X11 window manager I modified for pie menus was tvtwm, if I remember correctly. I believe Russell Nelson has been maintaining it.
Pie menus are not new. But they are different. Not for cosmetic reasons though. Fitts' law applies to linear menus, as well as pie menus, and it correctly predicts that linear menus will be slower to use and have a higher error rate than pie menus, because their items are further from the cursor and smaller. Pie menus signifigantly increased the speed and decreased the error rates of menu selection. See the CHI'88 pie menu paper by Callahan, Shneiderman, Weiser and Hopkins, for proof.
Because linear menus are based on distance instead of direction, you are required to look at the screen to see when you've moved the cursor far enough, so you can know when to stop moving and release the button.
Pie menus do not require the feedback loop of looking at the screen and moving your hand until you visually recognise that you're pointing at the right item. That feedback loop is extremely demanding on your attention, and downright annoying. Eliminate the unnecessary requirement of looking at the screen to determine the menu selection, and you eliminate the feedback loop.
Pie menus of 8 items allow you to reliably select any slice, without looking at the screen. Your visual attention can be somewhere else, or your eyes closed, and you can still make reliable pie menu selections.
This enables mouse-ahead. Once you know the directions, you make a quick gesture in the direction you want, and you can be very sure you've made the right choice, even if you're busy looking somewhere else on the screen, or the computer is lagging behind slowly responding to mouse events.
Not sure if you moved in the right direction? Move out further! The further out you move the cursor from the menu center, the more leverage and finer control you have over the angle of selection.
Mouse-ahead works so well with pie menus, that good implementations actually supress the display of the menu window, whenever you mouse ahead, since it happens so often. Lightweight cursor and audio feedback is quite helpful during mouse-ahead, but the menus just get in the way. You can even mouse ahead reliably through nested pie submenus! Window managers that use a well designed set of nested pie menus can be extremely efficient thanks to mouse-ahead.
The other thing about pie menus, is that they're as easy for the novice as the expert. The thing about them that makes them good for the expert, does not get in the way of the novice, and the other way around. The novice clicks the menu up, looks at it, and moves in the chosen direction. This is actually a rehersal for the expert's gesture. Once you remember the direction associated with the command (that careful menu layout can help, by exploiting natural symetries and spatial relationships between commands, like up for "raise" and down for "lower"), you can make the same gesture that a novice would have made, only faster. The rehersal you did as a novice quickly moves you up the smooth learning curve until you're an expert without realizing it.
There's an interesting stage between novice and expert. The novice will click, looking at the menu to determine the direction, move the cursor in that direction, then click to select the item. The expert will know the direction, so they just click, move, click without waiting for the menu, and the computer can act on the command without even displaying the menu. The intermediate user remembers the direction, but is not sure of it, so they click up the menu, move in the direction they think is correct, then stop moving and wait for the menu to pop up to be sure they've selected the right item, before releasing the mouse.
So there's a smooth progression from novice to intermediate to expert, with no steep jumps on the learning curve, so people learn to mouse ahead without even realizing it.
Contrast this with the keyboard shortcuts of linear menus. In order to learn the keyboard shortcuts, you have to pull down the linear menus and look at the legend on the menus. That act has NOTHING to do with the act of typing one of those keyboard shortcuts. So the act of pulling down a linear menu and looking at the legend is NOT rehersal for the act of using the keyboard shortcut. The two acts require your hands to flap between two completely different input devices! With pie menus, the way a novice uses the menu IS rehersal for the way an expert uses the menu. The shortcuts don't take a totally different route.
Pie menus can use keyboard shortcuts too. The ActiveX pie menus I wrote are fully navigable from the keyboard: use the arrows or directional keys on the numeric keypad to select items by direction, use the tab and shift tab to select items in order, type a letter to cycle between items beginning with that letter, use page up/down/home/end to scroll back and forth between clusters of menu items, backspace to go back one submenu, escape to cancel, return to select, etc.
Slashdot Mirror
http://www.turing.org.uk/turing/scrapbook/bs.html
"The Gene Machine
Professor Bernard Hodson (now based in Ottawa) has developed a programming system called Genetix. It is claimed that this is more efficient than any software currently used, and differs radically from everything done in the last fifty years by drawing on Turing's original concepts. [...]
[...] At present the work is apparently bound by commercial secrecy, but I hope that soon these surprising claims will be opened to general scientific discussion. Until then they will be hard to evaluate.
However, my business on this website is to explain what Alan Turing said and did; and I do think I can say that Hodson and Bloor are on doubtful territory in claiming that the Genetix programming ideas derive directly from Turing's writings. They quote quite general statements made by Turing in advancing the ideas of a universal machine, of the stack, and of program libraries, when all these ideas were completely fresh. They go on to interpret them in what seem to me much more specific modern terms, in support of the Genetix approach. I am sceptical as to whether the Genetix system actually derives from anything Turing had in mind.
To illustrate my point, note that the Genetix prospectus rests upon distinguishing the Universal Turing Machine concept from the stored-program concept. Turing himself, however, made no such distinction, and in 1948 clearly referred to all the digital computers then under construction as 'practical universal computing machines.'
Two possible confusions
As far as I can see there is no connection between Genetix and 'genetic programs' which improve themselves by means analogous to biological evolution by selection. (Turing might in fact be credited with the basic idea of such programs. Right from the start he emphasised the idea that the stored-program computer can modify its own instructions, suggesting that this capacity could be developed into the ability to learn from experience.)
Also, this Genetix has no connection with the Genetix which campaigns against the development of genetically modified organisms."
-Don
So what if... So what if... So what if...
So what if they have their head stuck up their ass? So what if they lie about having the first 8 bit Java? So what if they lie about having the smallest Java implementation? So what if they brush questions of performance under the rug? As long as their bullshit benefits the Greater Glory of Java, we love them. Let the blowjobs begin!
After all that bullshit about Java, and all of Sun's bullshit about "write once run anywhere", why are you so willing to give ORIGIN the benefit of the doubt that maybe they're not even slightly exagerating or omiting parts of the whole story, even if they don't have a demo you can download and test out for yourself. Have you already fallen for so many outlandish lies about Java that these wee little fabrications don't even register on the logarithmic Richter scale any more?
(Well, now that I think about it, you're right: I suppose it's best for Java in the long run, if we lie about how great it is, and make lots of promises we know we'll never be able to keep, and pretend to believe other pro-java liars. After all, Java was designed as a tool in the war against Microsoft. And there's nothing more important than going to war. Just explain to the families of the vets who were poisoned by depleted uranium shells and agent orange that the ends justify the means.)
-Don
I'm a professional game programmer. I helped develop The Sims for Maxis/EA. Nobody in the computer game industry would ever suggest developing a "sophisticated" computer game in Java (except as a drunken joke at a christmas party), because they would be the laughing stock, and fired for incompetence if they were actually serious. Must I put it so gently, or should I be more blunt? Welcome to the real world.
As you say: Java wasn't designed for game programming. But since you already know that, I don't understand why you appearently don't agree with me.
Can't you see their utter contept for reality when they claim ORIGIN could "theoretically" handle any application, including "sophisticated" computer games, because it's "Turing Complete". Come on, these guys are blowing smoke out their ass.
-Don
One thing that makes Forth different than other languages like C, but similar to PostScript, is that it has separate return stacks and operand stacks. PostScript also has a separate dictionary stack, for scoping. Forth uses a linked list of vocabularies for scoping. PostScript uses marks on the stack (it has a special "mark" data type) but Forth doesn't, because the objects on the Forth stacks are not typed (you can't tell a zero from a mark), as they are with PostScript (or Lisp or JavaScript). PostScript is kind of like a cross between Lisp and Forth. Once I had a PostScript interpreter that could draw on the screen, I basically abandoned Forth, but still I like it.
There are different ways of implementing Forth "threading", that are all valid, but the essential thing is that there are just a few primitives, and the rest is built on top through a "threaded" interpreter, through named layers of indirection called "words".
The usual setup is "indirect threading," where a Forth word is compiled as a series of pointers to pointers to code, the indirect "Code Field Address" of each word to call in succession. At the cfa there is a pointer to the actual machine code to jump to. Primitives are implemented as machine code immediately following the code field address, so cfa points to cfa + wordsize.
High level Forth words all have the same cfa pointer to the heart of the Forth interpreter, which pushes the return stack and loops over interpreting the pointers following the cfa one by one.
The Forth compiler is written in Forth itself. Programmers are meant to be able to extend the compiler to implement specialized control and data structures, by writing "immediate" words that are executed at compile time, like Lisp macros, that can compile code and data into the word being defined.
Control flow is implemented by immediate words like "if", "then", "else", "begin", "while", "do", "loop", ";" etc, which are Forth words that compile calls to other low level run-time primitives like "(?branch)", "(branch)", "(loop)", "(exit)", etc: usually compiled words that muck around with the Forth return stack and registers.
You can move numbers between the return and operand stacks with ">r" and "r>". Literal data is pushed onto the operand stack by the word "lit" followed by an inline word sized bit literal, or the ever popular "clit" followed by an 8 bit character literal.
The words "create" and ";code" let you write Forth words for defining other words (or data types) that are implemented by machine code (that you enter in reverse polish notation).
The high level version is "<builds" and "does>" which let you write your own constructors and interpreters in Forth.
Some Forth systems use "direct threading", in that the code field address contains actual code to jump to, instead of a pointer to code. Forth words can then be compiled into a series of machine language subroutine calls (or whatever it takes), or they can be a more compact series of pointers to code, interpreted by the Forth main loop.
The Novix Forth Engine was a microprocessor designed to execute Forth, that had a separate bus to the return stack, operand stack, and main memory, that it could access all at the same time. The Forth compiler optimized Forth code, collapsing a sequence of parallelizable instructions into one bitslice-like instruction that did them all at once, like using the alu, pushing a number on the operand stack, and popping the return stack.
Java uses a totally different kind of VM than a pure Forth system, although it's similar to Forth in a lot of ways. It's a byte code interpreter. Some Forth systems are byte code interpreters (like Open Firmware on Mac PowerPCs and the L1-A Sun boot prom Forth), but not necessarily nor usually. Threaded does not equal byte coded. Byte code interpreters have been around for a long time before Java in many forms, like SCUD Pascal.
The best thing about the 1802 microprocessor is that it had a "GET HIGH" instruction.
-Don
You can also store data in the state of the machine, instead of writing it on the tape. Turing machines don't have registers, nor stacks, nor random access memory, but they can be in any number of different states. So to do anything non-trivial, you end up with a heck of a lot of machine states, connected together in a complex network. In order to copy a number, you have to suck up some of that number into the machine state "temporary storage", then go into a state that moves the read/write head to the destination while remembering the temporary state, and then go through a series of states that writes the machine state out onto the tape while moving the head. So you could write a program that copied a number one bit at a time by moving back and forth between source and destination, using relatively few machine states. Or a program that copied numbers more efficiently n bits at a time with 2^n and then some machine states. To do anything non-trivial, you end up with zillions of machine states, representing a network of all possible values of temporary storage connected by tape seeking and writing instructions, and you also require infinite amounts of tape to execute the program.
Think of it like an Adventure (MUD) game with one deterministic player, who is carrying a tape and read/write head. The state of the machine is which room you're in, plus the state of the tape and position of the head. Each room has a door labeled for each possible token on the tape, and when you walk through correct door, it can write a token on the tape, and move the head up or down. A program is a set of interconnected rooms. You have to double the number of rooms (states) to represent one bit of information in the machine state, like the Star Trek episode when they were beamed aboard an exact duplicate of the Enterprise, that represented one bit (the answer to the question "Is this real?").
It's hard for me to believe that they're using a Turing machine model for efficiency's sake.
-Don
I respectfully submit these slogans for use in your advertising campaign:
"Special instruction that sets P = NP in 1 clockcycle!"
"Now, with Patented Order(1 Click) [TM]-Complete (R)-Rated (C)-Plus-Plus E-Commerce Algorithms."
"Offering the world's first fully optimized totally integrated long term zeroth order solution to the halting problem!"
"Write once, halt anywhere."
"We believe our own hype." Oops -- I sold all rights to that one to Sun, so you'll have to negotiate a license for that slogan with Sun directly. There's a special discount for Java VM licensees.
-Don
Funny how they have the nerve in the faq to pose themselves straw man questions like "Can it interoperate with system XYZ?" and answer "Of course, since our system is Turing complete!". Well FYI systems XYZ and ABC and 123 and A to Z are all Turing Complete -- It's No Big Deal, and they're making a worthless and facitious statement, like "oh, that's just a simple matter of programming". At least Spinal Tap had enough self delusional integrity to claim something UNIQUE: that their amplifier "went to eleven".
Next thing we know they'll be suing every computer company on Earth for violating their "Turing Machine" patent.
-Don
Oh yeah, their software runs faster if nobody knows how it works or is allowed to observe it. Sounds like some kind of quantum computer, huh? More like an investor scam.
Looks to me like the old codger in charge is trying to exploit the good name of Alan Turing, his former co-worker. So where was he when Mr. Turing was on trial and needed a character witness to testify about his outstanding contributions to computer science and the defeat of Adolf Hitler?
(It's so rare I get the chance to use a legitimate ad swasticum attack.)
After that pedantic lecture on Turing machines, this vaguely reassuring "theoretical" answer does not impress me. The lack of speed may not seem "problematic" to an academic who doesn't know anything specific about game programming. But how about answering a more specific question: "For the practical programming of even simple computer games, is ORIGIN any better than Java, which totally sucks ass?"-Don
-Don
Believe me: You don't want to end up with as bad a reputation as Mark Pesche!
-Don
-Don
You really have missed the point. But you just go on missing it: that leaves all the great opportunities to people who have been paying attention. -Don
"At Sun, we never let Microsoft tell us what to do, we just imitate them." -Don
Then post that documentation, please. -Don
I later used Emacs with tab windows to implement an authoring tool for HyperTIES, a hypermedia browsing/authoring research project developed in Ben Shneiderman's Human Computer Interaction Lab, at the University of Maryland College Park.
Later on I wrote and freely published several different implementations of "tab windows", using The NeWS Toolkit version 1.0, 2.0, and 3.0. They allowed you to drag the tab around to any edge of the window, lay the windows out sequentially so they overlapped and each of their tabs was visible, and you could bring any window to the top by clicking on the tab, move the windows by dragging the tab, etc.
Sound familiar? It's called prior art. I believe it makes Adobe's patent invalid.
Here's the reference to and a quote from a paper we published in 1991, although we performed the research a few years before that (which explains the words "Look Back" in the title).
-Don
Designing to Facilitate Browsing: a Look Back at the HyperTIES Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, and William Weiland.
Hypermedia, V3 #2, 1991
Page 115.
The more recent NeWS version of Hyperties on the SUN workstation uses two large windows that partition the screen vertically. Each window can have links and users can decide whether to put the destination article on top of the current window or on thee other window. The pie menus make it rapid and easy to permit such a selection. When users click on a selectable target a pie menu appears (Fig. 1) and allows users to specify in which window the destination article should be displayed (practically users merely click then move the mouse in direction of the desired window). This strategy is easy to explain to visitors and satisfying to use. An early pilot study with four subjects was run, but the appeal of this strategy is very strong and we have not conducted more rigorous usability tests.
In the author tool, we employ a more elaborate window strategy to manage the 15-25 articles that an author may want to keep close at hand. We assume that authors on the SUN/Hyperties will be quite knowledgeable in UNIX and Emacs and therefore would be eager to have a richer set of window management features, even if the perceptual, cognitive, and motor load were greater. Tab windows have their title bars extending to the right of the window, instead of at the top. When even 15 or 20 windows are open, the tabs may still all be visible for reference or selection, even though the contents of the windows are obscured. This is a convenient strategy for many auithoring tasks, and it may be effective in other applications as well.
CONCLUSIONS
The documents written with Hyperties have been used by hundreds of users at demonstrations, and some components have been studied in controlled experiments. A full usability study with a realistic application to compare Hyperties/SUN documents with other electronic forms or paper is a desirable goal. We believe that the components are important contributions and encourage other developers to try them and refine them further.
We see further opportunities for improving the hypertext browsing environment with ideas such as multiple indexes to permit partitioning of lar5ge databases, graphic browsing capabilities (not a node-link diagram, but a higher level representation), various bookmarks, and still larger, sharper, and faster displays. Improved search facilities would include flexible string searching, search for graphic images, search within a restricted distance from the current node, weighted search results, intersections/unions of searches, and search by node-link structures. Our recent efforts have been to develop structural analysis software tools and metrics to provide authors with suitable feedback to better guide the document creation process. The future of hypertext will be brighter if the user interface for browsing can be made more attractive and effective.
Nobody's blaming X itself for the mistakes of its designers. I'm blaming ignorant hypsters like yourself for all the insincere uninformed cheerleading that led to the widespread adoption of X11, in spite of all of its severe technical problems. Stop being such an appologist for bad design and poor execution.
I tried to make constructive criticism in that chapter, comparing it to NeWS's downloadable code and extensible protocols. NeWS was certainly not perfect, but X11 had a lot to learn from it, and people like you still refuse to open your eyes to that fact.
The software we're using today has evolved into a model much closer to NeWS than X11. Web servers are like NeWS clients (the program that runs an application remotely). The web browser is like the NeWS server (the program running on the user's machine), that controls the display. The web server can download html and javascript to the browser, that interacts locally with the user, much in the same way that NeWS clients download PostScript code to the NeWS server.
So before you tell me that NeWS's model of downloadable extensibility sucks and nobody uses it, you should do some research and check out that new craze that everybody's been talking about recently, called the world wide web. If you have never heard of the web, and can't find a book about it in the library or your local book store, just search for "www" on yahoo.
-Don
The X-Windows Disaster
What happens to XCalc when you resize it too many times?
Official Notice, Post Immediately!
The ICCCM Sucks
jojo on UI
Motif Angst Page
XBugTool Horror Stories
-Don
The componentization of the window manager was in the abstract a good idea, but the execution (ICCCM) was an abortion. You say that X wouldn't have survived as long without it. But if X had died because it was stuck with one bad window manager, then we wouldn't be in this dead end prediciment that we're stuck with today!
X should have been designed to self destruct. Like shareware that expires after a few months. I wish somebody would patent X11, and sue everyone who tries to use it. Where are SGI's lawyers when we need them?
The ICCCM window manager protocol is like an emergency tracheotomy performed with a rusty crowbar, that's been inflamed and oozing infected pus for the last decade. ICCCM is the scab on a stigmata that will never heal. But people keep trying to fix the problem by enlarging the hole in the neck and sticking tubes down it! Isn't it about time to just cut the head off and bury the body?
There's nothing clean nor extensible about the X protocol, and to make such a statement ignores reality and history, and promulgates bad taste. NeWS had an truly extensible protocol that allowed clients to dynamically download code to the server at run time. X extensions just don't cut it. You could just as well call Perl a clean simple well designed language with an easy to learn syntax, if you're going to distort the facts so grossly.
-Don
-Don
PS: I'm not quoting the ISP, I'm quoting the guy who started the ISP that he named after himself.
PPS: Quake sucks. It's as tasteless as Perl.
-Don
-Don
-Don
-Don
Because linear menus are based on distance instead of direction, you are required to look at the screen to see when you've moved the cursor far enough, so you can know when to stop moving and release the button.
Pie menus do not require the feedback loop of looking at the screen and moving your hand until you visually recognise that you're pointing at the right item. That feedback loop is extremely demanding on your attention, and downright annoying. Eliminate the unnecessary requirement of looking at the screen to determine the menu selection, and you eliminate the feedback loop.
Pie menus of 8 items allow you to reliably select any slice, without looking at the screen. Your visual attention can be somewhere else, or your eyes closed, and you can still make reliable pie menu selections.
This enables mouse-ahead. Once you know the directions, you make a quick gesture in the direction you want, and you can be very sure you've made the right choice, even if you're busy looking somewhere else on the screen, or the computer is lagging behind slowly responding to mouse events.
Not sure if you moved in the right direction? Move out further! The further out you move the cursor from the menu center, the more leverage and finer control you have over the angle of selection.
Mouse-ahead works so well with pie menus, that good implementations actually supress the display of the menu window, whenever you mouse ahead, since it happens so often. Lightweight cursor and audio feedback is quite helpful during mouse-ahead, but the menus just get in the way. You can even mouse ahead reliably through nested pie submenus! Window managers that use a well designed set of nested pie menus can be extremely efficient thanks to mouse-ahead.
The other thing about pie menus, is that they're as easy for the novice as the expert. The thing about them that makes them good for the expert, does not get in the way of the novice, and the other way around. The novice clicks the menu up, looks at it, and moves in the chosen direction. This is actually a rehersal for the expert's gesture. Once you remember the direction associated with the command (that careful menu layout can help, by exploiting natural symetries and spatial relationships between commands, like up for "raise" and down for "lower"), you can make the same gesture that a novice would have made, only faster. The rehersal you did as a novice quickly moves you up the smooth learning curve until you're an expert without realizing it.
There's an interesting stage between novice and expert. The novice will click, looking at the menu to determine the direction, move the cursor in that direction, then click to select the item. The expert will know the direction, so they just click, move, click without waiting for the menu, and the computer can act on the command without even displaying the menu. The intermediate user remembers the direction, but is not sure of it, so they click up the menu, move in the direction they think is correct, then stop moving and wait for the menu to pop up to be sure they've selected the right item, before releasing the mouse.
So there's a smooth progression from novice to intermediate to expert, with no steep jumps on the learning curve, so people learn to mouse ahead without even realizing it.
Contrast this with the keyboard shortcuts of linear menus. In order to learn the keyboard shortcuts, you have to pull down the linear menus and look at the legend on the menus. That act has NOTHING to do with the act of typing one of those keyboard shortcuts. So the act of pulling down a linear menu and looking at the legend is NOT rehersal for the act of using the keyboard shortcut. The two acts require your hands to flap between two completely different input devices! With pie menus, the way a novice uses the menu IS rehersal for the way an expert uses the menu. The shortcuts don't take a totally different route.
Pie menus can use keyboard shortcuts too. The ActiveX pie menus I wrote are fully navigable from the keyboard: use the arrows or directional keys on the numeric keypad to select items by direction, use the tab and shift tab to select items in order, type a letter to cycle between items beginning with that letter, use page up/down/home/end to scroll back and forth between clusters of menu items, backspace to go back one submenu, escape to cancel, return to select, etc.
-Don