3 ms·
> Anyway, my take on all this hyper-crap is that it's useless without a good scripting language. I think that's why Emacs was so successful, why HyperCard was s
by tannhaeuser 9y ago
> Anyway, my take on all this hyper-crap is that it's useless without a good scripting language. I think that's why Emacs was so successful, why HyperCard was so important, what made NeWS so interesting, why HyperLook was so powerful, why Director has been so successful, how it's possible for you to read this discussion board served by Frontier, and what made the World Wide Web what it is today: they all had extension languages built into them.
I'm wondering what your wiser, older self has to say about this 20 years on. Isn't it useful that documents you wrote 20 years ago can still be read?
From my memories, the Web craze started well before JavaScript, and JavaScript really only jumped on the bandwagon; so how could it be the critical success factor for the Web?
The success of the Web and JavaScript in the last two decades speaks for itself; but in 2018, JavaScript and the procedural Web could very well be its undoing when considering the original goals of the Web, couldn't it?
- dvanduzer 9y agoI don't think Don meant that JS was the critical success factor for the Web. But that extensible scripting is crucial to the kind of Web Ted Nelson wanted in the first place. From my lived experience, the Web craze would be better termed the Modem craze. And the critical success factor that turned it into the Web, was NSF removing the restrictions on commerce in 1995. JavaScript is just what got HTML closer to some ideals of Xanadu. Not close enough for Ted's vision, but that is a broad sociopolitical vision.
- DonHopkins 9y agoServer side scripting languages were critical to the success of the web, before browser side JavaScript was available and matured. Simple stateless perl cgi scripts forked from apache that talk to text databases or mysql were the first simplest step, but things got much more interesting with long running stateful application servers like Zope (Python), Java, Radio UserLand, HyperCard, node, etc. My favorite thing about node is that it lets you use the same language and libraries and data on both the client and server side. That's an enormous advantage that far outweighs JavaScript's disadvantages. But some people just can't see or believe that, for whatever reason, and they're fine with flipping and flopping back and forth between different languages, and hiring different people to write multiple subtly divergent versions of everything in different languages. Face it: for all its faults, JavaScript won. I will always have a place in my heart for FORTH, PostScript, MockLisp, ScriptX, TCL, Python, HyperTalk, UserTalk, CFML, Java, and all those other weird obsolete scripting languages, but it's soooo much easier to program in one language without switching context all the time, even if it's not the best language in the universe. And TypeScript is a pretty darn good way of writing JavaScript. You're right, the web was held back until it was finally considered "ok" to use it for commercial activity! I'd say JavaScript is just what got HTML closer to implementing any ideal you want, and there's no reason Xanadu couldn't be implemented on top of current web technologies (except that Ted doesn't want to). But I don't think extensibility and scripting itself was part of Ted's original vision or implementation. Just as so much has happened since MVC was invented (yet it's still religiously applied by cargo-cult programmers), also so much has happened since Xanadu was invented (like distributed source code control, for example), which requires a total rethinking from basic principles. We also have the benefit of a lot of really terrible examples and disasterous experiments to learn from (wikipedia markup language, wordpress, etc). Many of Ted's principles should be among those basic principles considered, but they're not the only ones.
- dvanduzer 9y agoHmm, HyperCard in the same list as Zope and node? Interesting. :-) The idea that JavaScript "won" is a little controversial to me. I think it's huge and important, but the world is still changing. Embedded Python goes places that Node still can't. I absolutely see the value you describe in sticking to one ecosystem, but I don't think JavaScript/TypeScript/Node is the only way to get those benefits. (See also: Transcrypt) I really enjoyed the PyCon 2014 talk on the general subject: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... The most recent conversation I had with Ted was after someone had just demonstrated the HoloLens for him and a few others. Ted had some feedback for the UI developer, and it didn't have anything to do with JavaScript or that level of implementation detail at all. It was all about the user experience. I don't want to put words into his mouth, but like he says in this recent interview, this is all hard to talk about because it really has changed so quickly. I do think you're right that a lot of what Ted wanted to see could be implemented today in JavaScript and Git. But I think about the technical meat of that vision to be about data-driven interfaces. I am simply not old enough to really understand how notions of "scripting" changed between the 60s and the 80s. But the fact that Xanadu was started in SmallTalk suggests to me that scripting was part of the vision, even if a notion like "browser extensions" might not have been in mind. Completely agree that there are other voices to learn from, and other important mistakes that have been made since Xanadu! (I think Ted would agree, too.)
- DonHopkins 9y agoReading documents from 20 years ago is a mixed bag. Links usually fail horribly, which was something Xanadu was trying to solve, but I'm not convinced they could have solved it so well that 20-year-old links would still actually work in practice. I've always tried to write documents in a simple format that's easy to translate to newer formats, and minimizes noise and scaffolding and boilerplate. When we were developing the HyperTIES hypermedia browser in 1988 [1] at the UMD HCIL, we considered using SGML as the markup language, but decided against it, because we were focusing on designing a system that made it easy for normal people to author documents, and working with SGML took a lot of tooling at the time. (It was great for publishing Boeing's 747 reference manual, but not for publishing poetry and cat pictures.) So we designed our own markup language. [2] [1] Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser: http://www.donhopkins.com/drupal/node/102 http://www.donhopkins.com/drupal/node/102 [2] HyperTIES documentation directory: http://donhopkins.com/home/ties/doc/ http://donhopkins.com/home/ties/doc/ typical document files: http://donhopkins.com/home/ties/doc/whyanew.st0 http://donhopkins.com/home/ties/doc/whyanew.st0 http://donhopkins.com/home/ties/doc/formatcommand.st0 http://donhopkins.com/home/ties/doc/formatcommand.st0 It's not which scripting language you have, it's that you have a scripting language at all that's important. HyperTIES was actually implemented in C, plus 3 different scripting languages: FORTH for the markup language interpreter and formatter [3], PostScript for the user interface and display driver and embedded applets [4], and Emacs MockLisp for the authoring tool [5]. [3] HyperTIES Forth code: http://donhopkins.com/home/ties/doc/formatter.st0 http://donhopkins.com/home/ties/doc/formatter.st0 http://donhopkins.com/home/ties/fmt.f http://donhopkins.com/home/ties/fmt.f [4] HyperTIES PostScript code: http://donhopkins.com/home/ties/doc/tnformat.st0 http://donhopkins.com/home/ties/doc/tnformat.st0 http://donhopkins.com/home/ties/fmt.ps http://donhopkins.com/home/ties/fmt.ps http://donhopkins.com/home/ties/target.ps http://donhopkins.com/home/ties/target.ps [5] HyperTIES MockLisp code: http://donhopkins.com/home/ties/yahtittie.ml http://donhopkins.com/home/ties/yahtittie.ml When you try to design something from the start without a scripting language, like a hypermedia browser or authoring tool, or even a window system or user interface toolkit, you end up getting fucked by Greenspun's Tenth Rule [6] [6] Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule But when you start from day one with a scripting language, you can relegate all the flexible scripty stuff to that language, and don't have to implement a bunch of incoherent lobotomized almost-but-not-quite-turing-complete kludgy mechanisms (like using X Resources for event handler bindings and state machines, or the abomination that is XSLT, etc). TCL/Tk really hit the nail on the head in that respect. TCL isn't a great language design (although it does have its virtues: clean simple C API, excellent for string processing, and a well written implementation of a mediocre language design), but its ubiquitous presence made the design of the Tk user interface toolkit MUCH simpler yet MUCH more extensible, by orders of magnitude compared to all existing X11 toolkits of the time, since it can just seamlessly call back into TCL with strings as event handlers and data, and there is no need for any of the ridiculous useless brittle contraptions that the X Toolkit Intrinsics tried to provide. The web was pretty crippled before JavaScript and DHTML came along. Before there was client side JavaScript, there were server side scripting languages, like Perl, PHP, Python, Frontier (Radio Userland) [7], HyperTalk, etc. Frontier / Manilla / Radio Userland was a programmable authoring tool, content management system, web server, with a build-in scripting language (UserTalk, integrated with an outliner and object database). That scriptability enabled Dave Winer and others to rapidly prototype and pioneer technologies such as blogging, RSS, podcasting, XML/RPC, SOAP, OPML, serving dynamic web sites and services, exporting static web sites and content, etc. [7] Frontier: https://en.wikipedia.org/wiki/UserLand_Software#Frontier https://en.wikipedia.org/wiki/UserLand_Software#Frontier Manilla: https://en.wikipedia.org/wiki/UserLand_Software#Manila https://en.wikipedia.org/wiki/UserLand_Software#Manila Radio Userland: https://en.wikipedia.org/wiki/Radio_UserLand https://en.wikipedia.org/wiki/Radio_UserLand One of the coolest early applications of server side scripting was integrating HyperCard with MacHTTP/WebStar, such that you could publish live interactive HyperCard stacks on the web! Since it was based on good old HyperCard, it was one of the first scriptable web authoring tools that normal people and even children could actually use! [8] [8] MacHTTP / WebStar from StarNine by Chuck Shotton, and LiveCard HyperCard stack publisher: https://news.ycombinator.com/item?id=7865263 https://news.ycombinator.com/item?id=7865263 CGI and AppleScript: http://www.drdobbs.com/web-development/cgi-and-applescript/184409741 http://www.drdobbs.com/web-development/cgi-and-applescript/1... That inspired me to do some similar stuff with another ill-fated scripting language, Kaleida ScriptX. [9] [9] ScriptX and the World Wide Web: "Link Globally, Interact Locally": http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.html http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.htm... Demo by Don Hopkins of DreamScape on Kaleida Labs ScriptX presented at the 1995 Apple World Wide Developer Conference. https://www.youtube.com/watch?v=5NytloOy7WM https://www.youtube.com/watch?v=5NytloOy7WM Kaleida ScriptX: https://en.wikipedia.org/wiki/Kaleida_Labs#ScriptX https://en.wikipedia.org/wiki/Kaleida_Labs#ScriptX