Christmas present sometime around 1975 when I was 9 and had just been bitten by the computer bug. It really was beyond me at the time, but I didn't care.
It was quite probably copied from one of the Lisp systems. I used UTILISP many years ago and it had an sexpr structure editor available for code use. However, it still wrote out the code into files. The big stumbling block was comments, which are defined in most language syntaxes as a purely textual element that can go wherever you can put whitespace. And a simple rule for binding comments to parse nodes (such as bind-to-preceding) doesn't usually work because of varying commenting styles.
The blue book doesn't really describe how code is stored...that was more the domain of the orange book. I know from experience that the version of ST-80 I used in '85 used a.sources and.changes file. Given the hardware they had to run it on I think the reliance on old fashioned files is excusable. Contemporary systems, however, should be reconsidering how to approach this.
Is this ST version you use available for public use? What is its name (is it Zoku ST?) and where do you work? I'd love to try rewriting my syntax macros for it. I suspect it would make IDE integration much simpler than what I had facing me in VW.
A data point in this discussion is that it is traditional for Smallltalk implementations to use proportional fonts as the default for code editing. I've been programming in Smalltalk since 1985 and I think I've only encountered a couple of people who changed the default to anything but a proportional font. Some Smalltalks allow for rich text code, and then you'll see ASCII art done as a monospaced font section embedded in a larger proportional method or comment. But I've not seen it that often. Maybe I've led a sheltered life.
Another data point is the book "Human Factors and Typography for More Readable Programs" by Ronald Baecker and Aaron Marcus ( http://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457 ). In this outstanding volume they build a framework for understanding program legibility and an approach to formatting C programs that utilizes this framework. Recommended to anyone who wants to have a better understanding of the issues in this area.
Well, the problem really is storing code as text. Smalltalk code is usually stored as a serialised parse tree. When you edit the code, you dump a method as text through a pretty-printer, edit it, and parse it again. None of these issues apply because the stored representation doesn't contain whitespace at all, and you can automatically insert whitespace wherever you want it.
Squeak Smalltalk stores it's code in the.sources and.changes files as either a String (for plain text and similar to how ST-80 did it) or as a serialized object of class Text (for rich text). VisualWorks was similar to Squeak in the storage format but now uses an XML format for the.sources and.changes that stores the method text as a chunk of plain unicode. Gnu ST is not image based and uses normal text files so it doesn't do what you describe. ISTR that VisualAge ST works pretty much the same way as VW. Gemstone/S is slightly different in that the plain text Strings that make up the source code are stored in the Gemstone object database (along with everything else) and not in a separate file. These are the ST versions I've used enough to know offhand how their code storage works. Which version of Smalltalk have you been using that stores serialized parse trees?
Are you referring to the code formatter in Squeak that auto-reformats a method on accept? That does use the parse tree to generate the source text, but the tree is thrown away after the operation. It does have the neat feature of supporting an alternate syntax.
I think doing what you describe could be an excellent idea as long as some details such as associating comments with parse nodes are dealt with. There was some work done in Squeak to do this in order to make the.changes and.sources less necessary (and save disk space) but it has not made it into the mainstream releases. I've also written a crude Common Lisp style syntax macro package for VW (it's in the public StORE)....and that would be a lot more efficient and useful if the parse trees were persistent.
You forgot one: 13) The first guy to realize "I'm going to be spending the rest of my life fixing errors in my own programs!" - the debugging moment
"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." --Maurice Wilkes
If you look at Doug Engelbart's biography, you'll see he spent much of his career dealing with military sponsors. The language he uses seems to be designed to be intelligible to military funding authorities more than business 'consultant-speak'.
The writer of the session notes seems to be well educated and is using precise words from a large vocabulary, probably with a target reading level around college graduate, maybe as high as postdoc. It is mostly standard english with few words that I would label as 'consultant-speak' and those that are are clearly denoted as such by capitalization and quotation.
Translated, the first session is a statement of the problem. The problem is that the world is becoming, at an exponential rate, a much more complex place and our organizations cannot handle the ever increasing rate of change and the problems for individuals and society that this change brings. (Any slashdotter has witnessed this in the area of computers with various orgaizations flailing around trying to handle the implications of new developments, such as the Internet itself.)
The second session is about how the organizations can improve their adaptability regarding change, without the use of new technology, but keeping aware that new technology will arise and change the problems and solutions. This is done ahead of the actual need, so as to ease the transition when the time does come.
My translations aren't quite right, but that's partly a consequence of not using the "right" words and partly a consequence of it being 4:07 am here and I've been awake for too long...
--john dougan
The difference between the right word and the almost right word is like the difference between lightning and the lightning bug. --Mark Twain
I feel the problem with implementing Xanadu was that the implementation technology of the late 80's simply wasn't up to the task. The hardware wasn't up to it, the Internet hadn't taken off yet (At one time they were planning to set up their own network), OO tools were crude and not yet performance optimized, and the cathedral style of development meant that there were never enough minds at work on it. Also the problem was partially Ted homself. He's not a programmer, but a designer. He is at the mercy of other peoples implementation and *funding* since he's not capable of hacking it out himself. He's a great designer, but he seems to think sideways from most other people and has a love of inventing new terminology which makes it difficult to convey his ideas and designs to others. So he's had a very difficult time getting financial support to build this stuff. Add in a little bit of bad luck here and there and you have a 20 year delay.
Hopefully open sourceing it will help. I know some of the Squeak Smalltalk hackers (including myself) are interested in moving the Udanax Gold code to Squeak and already a preliminary reformatting and analysis of the code has been done. Apparantly Mark Miller has also expressed interest in a Squeak port.
As I understand it the reason that the C version is preferred initially is simply because it is in a more complete state, being an older design and implementation. Some people are going to have trouble conceptualizing what Xanadu is capable of, so having something they can see in operation, even if it is missing some of the features of the more recent design, is going to be a big win.
The Network extensible Window System. Boy, do I miss NeWS. Not the cruddy widgets and look and feel of OpenLook, but rather the beautiful architecture and capabilities I got to use for a fleeting moment before Sun dropped it. This is a ripe candidate to be open sourced. James Gosling, if you're out there, could you please convince Sun to release the NeWS source tree?
For those who've never heard of it, it was a network window system (duh) that was based around a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, and with an object oriented programming facility. Unlike DPS it was designed as client server (like X) from the ground up with a much more efficient and customizeable wire protocol. In the version shipped with OpenWindows 3.0 it was integrated with an X server.
The beauty of it was because you communicated with it in PostScript you could offload processing on either the client or the server side depending on where it was most appropriate and by creative use of definitions on the server significantly cut the amount of data that would have to go across the wire. This can include implementing the window manager entirely inside the display server.
"Myth: X Is "Customizable"...And so is a molten blob of pig iron. But it's getting better; at least now you don't hasve to use your bare hands. Hewlett-Packard's Visual User Environment is so cutting-edge that it even has an icon you can click on to bring up the resource manager: it pops up a vi on your.Xdefaults file! Quite a labor-saving contraption, as long as you're omniscient enough to understand X defaults and archaic enough to use vi. The following message describes the awesome flexibility and unbounded freedom of expression that X defaults fail to provide."
Some of the problems have sinced been fixed (particularly window manager issues), but the basic architectural and political issues remain.
Slashdot Mirror
That cartridge did indeed exist, but it was very rare.
https://www.atariage.com/softw...
As seen at http://www.samstoybox.com/toys...
Christmas present sometime around 1975 when I was 9 and had just been bitten by the computer bug. It really was beyond me at the time, but I didn't care.
It was quite probably copied from one of the Lisp systems. I used UTILISP many years ago and it had an sexpr structure editor available for code use. However, it still wrote out the code into files. The big stumbling block was comments, which are defined in most language syntaxes as a purely textual element that can go wherever you can put whitespace. And a simple rule for binding comments to parse nodes (such as bind-to-preceding) doesn't usually work because of varying commenting styles.
The blue book doesn't really describe how code is stored...that was more the domain of the orange book. I know from experience that the version of ST-80 I used in '85 used a .sources and .changes file. Given the hardware they had to run it on I think the reliance on old fashioned files is excusable. Contemporary systems, however, should be reconsidering how to approach this.
Is this ST version you use available for public use? What is its name (is it Zoku ST?) and where do you work? I'd love to try rewriting my syntax macros for it. I suspect it would make IDE integration much simpler than what I had facing me in VW.
A data point in this discussion is that it is traditional for Smallltalk implementations to use proportional fonts as the default for code editing. I've been programming in Smalltalk since 1985 and I think I've only encountered a couple of people who changed the default to anything but a proportional font. Some Smalltalks allow for rich text code, and then you'll see ASCII art done as a monospaced font section embedded in a larger proportional method or comment. But I've not seen it that often. Maybe I've led a sheltered life.
Another data point is the book "Human Factors and Typography for More Readable Programs" by Ronald Baecker and Aaron Marcus ( http://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457 ). In this outstanding volume they build a framework for understanding program legibility and an approach to formatting C programs that utilizes this framework. Recommended to anyone who wants to have a better understanding of the issues in this area.
Well, the problem really is storing code as text. Smalltalk code is usually stored as a serialised parse tree. When you edit the code, you dump a method as text through a pretty-printer, edit it, and parse it again. None of these issues apply because the stored representation doesn't contain whitespace at all, and you can automatically insert whitespace wherever you want it.
Squeak Smalltalk stores it's code in the .sources and .changes files as either a String (for plain text and similar to how ST-80 did it) or as a serialized object of class Text (for rich text). VisualWorks was similar to Squeak in the storage format but now uses an XML format for the .sources and .changes that stores the method text as a chunk of plain unicode. Gnu ST is not image based and uses normal text files so it doesn't do what you describe. ISTR that VisualAge ST works pretty much the same way as VW. Gemstone/S is slightly different in that the plain text Strings that make up the source code are stored in the Gemstone object database (along with everything else) and not in a separate file. These are the ST versions I've used enough to know offhand how their code storage works. Which version of Smalltalk have you been using that stores serialized parse trees?
Are you referring to the code formatter in Squeak that auto-reformats a method on accept? That does use the parse tree to generate the source text, but the tree is thrown away after the operation. It does have the neat feature of supporting an alternate syntax.
I think doing what you describe could be an excellent idea as long as some details such as associating comments with parse nodes are dealt with. There was some work done in Squeak to do this in order to make the .changes and .sources less necessary (and save disk space) but it has not made it into the mainstream releases. I've also written a crude Common Lisp style syntax macro package for VW (it's in the public StORE)....and that would be a lot more efficient and useful if the parse trees were persistent.
You forgot one:
13) The first guy to realize "I'm going to be spending the rest of my life fixing errors in my own programs!" - the debugging moment
"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." --Maurice Wilkes
This strikes me as strange. Somebody has to have figured out this before Rambus.
/. hardware hackers know of any prior art in this?
Anybody of the
If you look at Doug Engelbart's biography, you'll see he spent much of his career dealing with military sponsors. The language he uses seems to be designed to be intelligible to military funding authorities more than business 'consultant-speak'.
The writer of the session notes seems to be well educated and is using precise words from a large vocabulary, probably with a target reading level around college graduate, maybe as high as postdoc. It is mostly standard english with few words that I would label as 'consultant-speak' and those that are are clearly denoted as such by capitalization and quotation.
Translated, the first session is a statement of the problem. The problem is that the world is becoming, at an exponential rate, a much more complex place and our organizations cannot handle the ever increasing rate of change and the problems for individuals and society that this change brings. (Any slashdotter has witnessed this in the area of computers with various orgaizations flailing around trying to handle the implications of new developments, such as the Internet itself.)
The second session is about how the organizations can improve their adaptability regarding change, without the use of new technology, but keeping aware that new technology will arise and change the problems and solutions. This is done ahead of the actual need, so as to ease the transition when the time does come.
My translations aren't quite right, but that's partly a consequence of not using the "right" words and partly a consequence of it being 4:07 am here and I've been awake for too long...
--john dougan
The difference between the right word and the almost right word is like the difference between lightning and the lightning bug. --Mark Twain
I feel the problem with implementing Xanadu was that the implementation technology of the late 80's simply wasn't up to the task. The hardware wasn't up to it, the Internet hadn't taken off yet (At one time they were planning to set up their own network), OO tools were crude and not yet performance optimized, and the cathedral style of development meant that there were never enough minds at work on it. Also the problem was partially Ted homself. He's not a programmer, but a designer. He is at the mercy of other peoples implementation and *funding* since he's not capable of hacking it out himself. He's a great designer, but he seems to think sideways from most other people and has a love of inventing new terminology which makes it difficult to convey his ideas and designs to others. So he's had a very difficult time getting financial support to build this stuff. Add in a little bit of bad luck here and there and you have a 20 year delay.
Hopefully open sourceing it will help. I know some of the Squeak Smalltalk hackers (including myself) are interested in moving the Udanax Gold code to Squeak and already a preliminary reformatting and analysis of the code has been done. Apparantly Mark Miller has also expressed interest in a Squeak port.
As I understand it the reason that the C version is preferred initially is simply because it is in a more complete state, being an older design and implementation. Some people are going to have trouble conceptualizing what Xanadu is capable of, so having something they can see in operation, even if it is missing some of the features of the more recent design, is going to be a big win.
The Network extensible Window System. Boy, do I miss NeWS. Not the cruddy widgets and look and feel of OpenLook, but rather the beautiful architecture and capabilities I got to use for a fleeting moment before Sun dropped it. This is a ripe candidate to be open sourced. James Gosling, if you're out there, could you please convince Sun to release the NeWS source tree?
For those who've never heard of it, it was a network window system (duh) that was based around a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, and with an object oriented programming facility. Unlike DPS it was designed as client server (like X) from the ground up with a much more efficient and customizeable wire protocol. In the version shipped with OpenWindows 3.0 it was integrated with an X server.
The beauty of it was because you communicated with it in PostScript you could offload processing on either the client or the server side depending on where it was most appropriate and by creative use of definitions on the server significantly cut the amount of data that would have to go across the wire. This can include implementing the window manager entirely inside the display server.
If you want to see some of what it could do, Don Hopkins has a page on NeWS at:
Some of the problems have sinced been fixed (particularly window manager issues), but the basic architectural and political issues remain.http://catalog.com/hopkins/lang/NeWS.html
Also for a good look (now a bit dated) on why X sucks see:
http://catalog.com/h opkins/unix-haters/x-windows/disaster.html
A sample from this page:
--john dougan