6 ms·

Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces. This was followed by a vision of a window system built on

Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces. This was followed by a vision of a window system built on ROFF.

mhd 7y ago
Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision. Hope something like that will never see the light of day.
- Jailbird 7y ago
  Perhaps all that will be implemented is character cell windowing systems. And Doom. Definitely Doom.
  - DonHopkins 7y ago
    Hurray for the MGR window system! https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR >ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore. >MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent. >Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software. >The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2] MGR was the largest posting to ever appear in comp.sources.unix: https://groups.google.com/forum/#!topic/comp.sources.unix/GGMq2FNEI1A https://groups.google.com/forum/#!topic/comp.sources.unix/GG... Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones. https://www.donhopkins.com/home/code/display.c.txt https://www.donhopkins.com/home/code/display.c.txt Maryland Windows source code: http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/XGsf97m7fA0J https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/... Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.
    - sedachv 7y ago
      > Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux. There is an X window manager written entirely in elisp for GNU Emacs, EXWM, that was started in 2015: https://github.com/ch11ng/exwm https://github.com/ch11ng/exwm I have been using it exclusively on my machines for the past three years. By far the best computing environment I have used. In 2018 I stumbled on XWEM, an X window manager in elisp for XEmacs that was developed from 2003 to 2004: http://www.nongnu.org/xwem/ http://www.nongnu.org/xwem/
  - mixmastamyk 7y ago
    I enjoyed TurboVision back in the day.
DonHopkins 7y ago
Even worse would be a window system or browser built on SGML or one of its mutant derivatives. Imagine a world where servers download tag soups of structured text with angled brackets and attributes to define formatted text, styles, and interactive users interfaces! It could only be worse if nobody could agree on which mutant derivative of SGML to use, so there were several different ones, and then a totally different style language that was completely syntactically unique, so you could not use the same syntax and tools to write and edit all the almost-but-not-quite-entirely-unlike-SGML syntaxes mish-mashed together. Oh wait. That IS what we have today! Never mind.
- shaunxcode 7y ago
  That said imagine if the SGML working group had held their ground and used s-expressions! At least the soup would be easy to slurp. (I can’t find a reference right now so maybe I just had a fever dream once?)
  - sedachv 7y ago
    You are probably thinking about DSSSL: https://en.wikipedia.org/wiki/DSSSL https://en.wikipedia.org/wiki/DSSSL "Sometime in or before 1994, Opera Software began drafting a "DSSSL Lite" specification for the consideration of the World Wide Web Consortium"
    - DonHopkins 7y ago
      Speaking of DSSSL, I love the Doctor Dobb's Journal interview with James Clark, who helped design and implement DSSSL and many other SGML and XML technologies. https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-... >A Triumph of Simplicity: James Clark on Markup Languages and XML >By Eugene Eric Kim, July 01, 2001 >If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade. >Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center ( http://www.thaiopensource.com/ http://www.thaiopensource.com/ ). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity. https://news.ycombinator.com/item?id=16227249 https://news.ycombinator.com/item?id=16227249 >The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex / RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people's minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler. >James Clark: http://www.jclark.com/ http://www.jclark.com/ https://en.wikipedia.org/wiki/James_Clark_(programmer) https://en.wikipedia.org/wiki/James_Clark_(programmer) >There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly. >A Triumph of Simplicity: James Clark on Markup Languages and XML: http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o... >I think it's safe to say that SGML and DSSSL fell short of that sought-after simplicity, and XML and XSLT were the answer to that. >"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark https://news.ycombinator.com/item?id=20384206 https://news.ycombinator.com/item?id=20384206 >He's not that famous outside of hard core geek circles, but I am a huge fan of James Clark (not the SGI guy, but he's awesome too for different reasons), who wrote the Expat XML parser, Relax/NG XML schema language, and many other widely used standards and bodies of code that drive the Internet. [...] >DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works? >JC: Having a reference implementation that's too good can actually be a negative in some ways. >DDJ: Why is that? >JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate. >You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation. >DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same? >JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.
PaulDavisThe1st 7y ago
In 1992/3, right after I got the University of Washington's Computer Science & Engineering dept. onto the web (after faculty outrage based on a NYT article about physics departments and this cool new thing) ... I wrote an extension for Netscape that allowed it to display DVI files natively :) Just think what could have been!

Your post prompted me imagine a nightmare/utopia in which TeX was used for building user interfaces. This was followed by a vision of a window system built on ROFF.

mhd 7y ago

Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision. Hope something like that will never see the light of day.

Jailbird 7y ago
Perhaps all that will be implemented is character cell windowing systems. And Doom. Definitely Doom.
- DonHopkins 7y ago
  Hurray for the MGR window system! https://hack.org/mc/mgr/ https://hack.org/mc/mgr/ https://en.wikipedia.org/wiki/ManaGeR https://en.wikipedia.org/wiki/ManaGeR >ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore. >MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent. >Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software. >The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2] MGR was the largest posting to ever appear in comp.sources.unix: https://groups.google.com/forum/#!topic/comp.sources.unix/GGMq2FNEI1A https://groups.google.com/forum/#!topic/comp.sources.unix/GG... Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones. https://www.donhopkins.com/home/code/display.c.txt https://www.donhopkins.com/home/code/display.c.txt Maryland Windows source code: http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/XGsf97m7fA0J https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/... Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.
  - sedachv 7y ago
    > Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux. There is an X window manager written entirely in elisp for GNU Emacs, EXWM, that was started in 2015: https://github.com/ch11ng/exwm https://github.com/ch11ng/exwm I have been using it exclusively on my machines for the past three years. By far the best computing environment I have used. In 2018 I stumbled on XWEM, an X window manager in elisp for XEmacs that was developed from 2003 to 2004: http://www.nongnu.org/xwem/ http://www.nongnu.org/xwem/
- mixmastamyk 7y ago
  I enjoyed TurboVision back in the day.

DonHopkins 7y ago

Even worse would be a window system or browser built on SGML or one of its mutant derivatives. Imagine a world where servers download tag soups of structured text with angled brackets and attributes to define formatted text, styles, and interactive users interfaces! It could only be worse if nobody could agree on which mutant derivative of SGML to use, so there were several different ones, and then a totally different style language that was completely syntactically unique, so you could not use the same syntax and tools to write and edit all the almost-but-not-quite-entirely-unlike-SGML syntaxes mish-mashed together. Oh wait. That IS what we have today! Never mind.

shaunxcode 7y ago
That said imagine if the SGML working group had held their ground and used s-expressions! At least the soup would be easy to slurp. (I can’t find a reference right now so maybe I just had a fever dream once?)
- sedachv 7y ago
  You are probably thinking about DSSSL: https://en.wikipedia.org/wiki/DSSSL https://en.wikipedia.org/wiki/DSSSL "Sometime in or before 1994, Opera Software began drafting a "DSSSL Lite" specification for the consideration of the World Wide Web Consortium"
  - DonHopkins 7y ago
    Speaking of DSSSL, I love the Doctor Dobb's Journal interview with James Clark, who helped design and implement DSSSL and many other SGML and XML technologies. https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-... >A Triumph of Simplicity: James Clark on Markup Languages and XML >By Eugene Eric Kim, July 01, 2001 >If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade. >Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center ( http://www.thaiopensource.com/ http://www.thaiopensource.com/ ). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity. https://news.ycombinator.com/item?id=16227249 https://news.ycombinator.com/item?id=16227249 >The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex / RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people's minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler. >James Clark: http://www.jclark.com/ http://www.jclark.com/ https://en.wikipedia.org/wiki/James_Clark_(programmer) https://en.wikipedia.org/wiki/James_Clark_(programmer) >There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly. >A Triumph of Simplicity: James Clark on Markup Languages and XML: http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o... >I think it's safe to say that SGML and DSSSL fell short of that sought-after simplicity, and XML and XSLT were the answer to that. >"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark https://news.ycombinator.com/item?id=20384206 https://news.ycombinator.com/item?id=20384206 >He's not that famous outside of hard core geek circles, but I am a huge fan of James Clark (not the SGI guy, but he's awesome too for different reasons), who wrote the Expat XML parser, Relax/NG XML schema language, and many other widely used standards and bodies of code that drive the Internet. [...] >DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works? >JC: Having a reference implementation that's too good can actually be a negative in some ways. >DDJ: Why is that? >JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate. >You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation. >DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same? >JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.

PaulDavisThe1st 7y ago

In 1992/3, right after I got the University of Washington's Computer Science & Engineering dept. onto the web (after faculty outrage based on a NYT article about physics departments and this cool new thing) ... I wrote an extension for Netscape that allowed it to display DVI files natively :) Just think what could have been!