I liked this quote - "I think the essential way to do anything great, you have to have some incremental development philosophy because you're just going to be wrong with your grand design that you don't iterate on."
Telescript is still something that intuitively seems like a good idea for a certain class of problem. In some ways, while it's a bit of a stretch, I would argue that Map/Reduce is a different encoding of this idea -- that the code should be mobile because the data isn't. Clearly Java was inspired by this concept and has been quite successful, but people aren't running applets for the most part anymore, so the one of the fundamental ideas motivating Java turned out to be irrelevant to its success. And yet on the other hand we have ReactNative and its equivalents sending JavaScript code off to the computers in our pockets. Even GMail and the original AJAX concepts are a re-creation of the Telescript concepts.<p>I hope Andy realizes that this idea isn't wrong so much as it was bad timing (like the rest of what General Magic was doing). The world today has transposed the ideas, but they're still recognizable in very successful platforms with significant mindshare.
Andy is the principal author of the posts on <a href="https://www.folklore.org/" rel="nofollow">https://www.folklore.org/</a> , which is all about the development of the mac. Definitely worth going through in an afternoon, if you're interested in that era.
My question for developers and engineers (on HN) today is this.<p>Do you think that people like Hertzfeld, Atkinson, Wozniak etc were super special in the way they are portrayed? Or were they simply around at a time when there was little competition in terms of competition? (Not saying they don't have talent just is it godlike?<p>I am reminded of what I thought was 'smart' based on people in my own local school. Then you get out in the world and you realize there are so many people that probably have much more ability, drive etc and they appear to far exceed what I thought was 'great'.<p>I think about this any time I see a field that is sparsely populated. Things like fighting wild fires or observing things in Antartica. Not like there are hundreds of thousands of people doing that but then from that small group you end up with 'experts'. (And maybe they are but usually a larger number would yield more qualified 'experts', right?)
I disagree that history proves them wrong about Telescript. They just had the client/server relationship backwards (and asymmetrical).<p>Andy Hertzfeld: "You didn't really need to do that. Just the remote procedure paradigm was good enough. Which is really what the web is based on. You don't inject code into the web to do you work for you and come back to you. You just ask a server with an http request."<p>It doesn't take Yakov Smirnoff to observe that now the web injects code into you.<p>The remote procedure paradigm isn't good enough. That just leads to the X-Windows Disaster.<p><a href="https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47" rel="nofollow">https://medium.com/@donhopkins/the-x-windows-disaster-128d39...</a><p>I'll argue that injecting code both ways is quite useful and extremely powerful.<p>Whenever you add a script or extension to Google Sheets or Google Docs or Gmail, you're injecting JavaScript code into a server running in the cloud.<p>Here's another example of how clients can inject code into servers: NFS 3.0 aka NeFS was a proposed version of NFS that put a PostScript interpreter into the kernel, so you could download code into your file server to efficiently perform file system operations, minimizing network traffic and even eliminating context switching.<p><a href="http://donhopkins.com/home/nfs3_0.pdf" rel="nofollow">http://donhopkins.com/home/nfs3_0.pdf</a><p><a href="https://news.ycombinator.com/item?id=9271578" rel="nofollow">https://news.ycombinator.com/item?id=9271578</a><p>>You might get a kick out of Sun's proposal for "NFS 3.0" aka "NeFS". The basic idea was to put a PostScript interpreter in the kernel for extensibly and efficiently executing distributed and even local file system operations. It not only cuts down on network transactions for the same reason NeWS and AJAX does, but even locally you can avoid billions of context switches by executing "find" and tasks like that in the kernel, for example.<p>NeFS was a great idea, but too radical for its time (Feb. 1990, soon before Telescript), but people are finally starting to rediscover the technique with other languages like JavaScript and Java.<p><a href="https://news.ycombinator.com/item?id=7958194" rel="nofollow">https://news.ycombinator.com/item?id=7958194</a><p>>Runtime.JS – Operating system kernel built on V8 (runtimejs.org)<p><a href="https://news.ycombinator.com/item?id=17060395" rel="nofollow">https://news.ycombinator.com/item?id=17060395</a><p>>pjmlp 55 days ago | on: Extending Tcl<p>>Yes, Sun played with idea of putting a JVM on the Solaris kernel.<p>>DonHopkins 55 days ago<p>>Even 16 or so years earlier in 1990, Sun played with the idea of putting a PostScript interpreter in the SunOS kernel.<p>>Like NeWS was the Network extensible Window System, so NeFS was the Network extensible File System, or NFS 3.0.<p>>It was actually a great idea, just a wee bit before its time, and very poorly named and positioned!<p>>This comparison of NeWS to AJAX also applies NeFS, which is like kernel NeWS with file operations instead of a graphics library -- it also saves you lots of user/kernel context switches even if you're not doing any networking:<p><a href="https://en.wikipedia.org/wiki/NeWS" rel="nofollow">https://en.wikipedia.org/wiki/NeWS</a><p>>NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:<p>>- used PostScript code instead of JavaScript for programming.<p>>- used PostScript graphics instead of DHTML and CSS for rendering.<p>>- used PostScript data instead of XML and JSON for data representation.<p>>It didn't go over very well because the unenlightened philistines of the time couldn't get their head around an API to the file system that wasn't compatible with creat open close read write and ioctl.